Prev: [PATCH 1/1] perf archive: Explain how to use the generated tarball
Next: [Bug 15618] New: 2.6.18->2.6.32->2.6.33 huge regression in performance
From: Malli on 23 Mar 2010 13:50 On Mon, Mar 22, 2010 at 8:57 PM, Benjamin Herrenschmidt <benh(a)kernel.crashing.org> wrote: > On Mon, 2010-03-22 at 17:59 +0000, Linux Kernel Mailing List wrote: >> Gitweb: � � http://git.kernel.org/linus/fd3686a842717b890fbe3024b83a616c54d5dba0 >> Commit: � � fd3686a842717b890fbe3024b83a616c54d5dba0 >> Parent: � � 936332b8e00103fc20eb7e915c9a3bcb2835a11a >> Author: � � Mallikarjuna R Chilakala <mallikarjuna.chilakala(a)intel.com> >> AuthorDate: Fri Mar 19 04:41:33 2010 +0000 >> Committer: �David S. Miller <davem(a)davemloft.net> >> CommitDate: Fri Mar 19 21:00:44 2010 -0700 >> >> � � ixgbe: Set IXGBE_RSC_CB(skb)->DMA field to zero after unmapping the address >> >> � � As per Simon Horman's feedback set IXGBE_RSC_CB(skb)->dma to zero >> � � after unmapping HWRSC DMA address to avoid double freeing. >> > > Note that this whole code is bogus :-) You cannot just assume that 0 is > a invalid DMA address. It is not. In fact, while you can check if a > dma_addr_t is invalid using dma_mapping_error(), the generic APIs > don't provide you with a magic "bad" value you can use for what you are > trying to do. > > Granted, I think we should make our iommu code reserve the first page > for the sake of everybody's sanity and to avoid such pitfalls, but > this code is wrong with today iommu implementations. > > Cheers, > Ben. Yes. I just realized that i can't assign a zero magic "bad" value. It is only valid in x86/arm/m68k/alpha architecures and not in spark & PowerPC arch, (it should be ~0). In some other architecutres it throws a BUG() on with dma_mapping_error() checks. So the patch is not a total bogus in some architectures :(. May be it is best to create an internal FLAG in IXGBE_RSC_CB(skb) which can be used to avoid this double freeing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |