From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: [PATCH/RESEND] drivers/net/ethernet: dev_alloc_skb to netdev_alloc_skb Date: Mon, 23 Jan 2012 16:53:29 -0500 (EST) Message-ID: <20120123.165329.738852681807240808.davem@davemloft.net> References: <1327348561.7527.0.camel@joe2Laptop> Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: joe@perches.com, netdev@vger.kernel.org, hch@lst.de, linux-kernel@vger.kernel.org, eric.dumazet@gmail.com To: netdev@pradeepdalvi.com Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org =46rom: "Pradeep A. Dalvi" Date: Tue, 24 Jan 2012 02:11:43 +0530 > On Tue, Jan 24, 2012 at 1:26 AM, Joe Perches wrote: >> On Tue, 2012-01-24 at 00:49 +0530, Pradeep A. Dalvi wrote: >>> On Tue, Jan 24, 2012 at 12:10 AM, Joe Perches wro= te: >>> > On Mon, 2012-01-23 at 23:58 +0530, Pradeep A. Dalvi wrote: >>> >> Replaced deprecating dev_alloc_skb with netdev_alloc_skb in driv= ers/net/ethernet >>> >> =A0 - Removed extra skb->dev =3D dev after netdev_alloc_skb >>> > [] >>> >> diff --git a/drivers/net/ethernet/amd/lance.c b/drivers/net/ethe= rnet/amd/lance.c >>> > [] >>> >> @@ -871,13 +871,12 @@ lance_init_ring(struct net_device *dev, gf= p_t gfp) >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct sk_buff *skb; >>> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 void *rx_buff; >>> >> >>> >> - =A0 =A0 =A0 =A0 =A0 =A0 skb =3D alloc_skb(PKT_BUF_SZ, GFP_DMA = | gfp); >>> >> + =A0 =A0 =A0 =A0 =A0 =A0 skb =3D netdev_alloc_skb(dev, PKT_BUF_= SZ); >>> > >>> > This change seems suspect. >>> Not really sure what made you suspect something in here. If you cou= ld >>> help me understand possibly broken scenarios, would essentially be >>> helpful. Thanks in advance! >> >> Where did the GFP_DMA go? >=20 > Aah! Is that really needed? Cause from my understanding, priority GFP > flag __GFP_DMA is anyway negated in __alloc_skb, in a way from all > sources i.e. netdev_alloc_skb or dev_alloc_skb or even alloc_skb. Am = I > missing something here? GFP_DATA is negated for the SKB metadata allocation, but preserved for the actual packet data allocation. Could you please back off a bit and take your time on these changes? Your transformations are adding bugs, and you make it clear that you don't even understand how the allocation functions work semantically. I don't really think you are knowledgable enough to make these transformations safely at this time, and this is needlessly wasting patch reviewer resources.