* Re: linux-next: manual merge of the net tree with the unicore32 tree
From: Jeff Kirsher @ 2011-08-23 9:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev@vger.kernel.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Guan Xuetao, Zhang Shu, Chu Xiaowei,
Su Yonggang
In-Reply-To: <20110823130210.766d466d689d60536f59340a@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]
On Mon, 2011-08-22 at 20:02 -0700, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net tree got conflicts in
> drivers/net/Kconfig and drivers/net/Makefile between commit
> e8787de6fa83
> ("unicore32: add pkunity-v3 mac/net driver (umal)") from the unicore32
> tree and the network driver rearrangement from the net tree.
>
> I just added the new driver from the unicore32 tree commit into each
> file
> (see below).
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
Hmm, well with the latest series of patches I sent out, I am pretty sure
this patch would not apply.
Is it best that this patch not be sent to netdev for driver
inclusion? :)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] net: sh_eth: fix the compile error
From: Yoshihiro Shimoda @ 2011-08-23 9:26 UTC (permalink / raw)
To: netdev; +Cc: SH-Linux
Fix the following build error:
CC drivers/net/sh_eth.o
drivers/net/sh_eth.c:1115: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘sh_eth_interrupt’
drivers/net/sh_eth.c: In function ‘sh_eth_open’:
drivers/net/sh_eth.c:1387: error: implicit declaration of function ‘request_irq’
drivers/net/sh_eth.c:1387: error: ‘sh_eth_interrupt’ undeclared (first use in this function)
drivers/net/sh_eth.c:1387: error: (Each undeclared identifier is reported only once
drivers/net/sh_eth.c:1387: error: for each function it appears in.)
drivers/net/sh_eth.c:1391: error: ‘IRQF_SHARED’ undeclared (first use in this function)
drivers/net/sh_eth.c:1424: error: implicit declaration of function ‘free_irq’
make[2]: *** [drivers/net/sh_eth.o] Error 1
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
drivers/net/sh_eth.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index ad35c21..f6de45b 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -30,6 +30,7 @@
#include <linux/phy.h>
#include <linux/cache.h>
#include <linux/io.h>
+#include <linux/interrupt.h>
#include <linux/pm_runtime.h>
#include <linux/slab.h>
#include <linux/ethtool.h>
--
1.7.1
^ permalink raw reply related
* Re: [PATCHv3 0/9] macb: add support for Cadence GEM
From: Jamie Iles @ 2011-08-23 9:34 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD; +Cc: Jamie Iles, netdev, linux-arm-kernel
In-Reply-To: <20110809145940.GP22213@game.jcrosoft.org>
Hi Jean-Christoph,
On Tue, Aug 09, 2011 at 04:59:40PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:16 Tue 09 Aug , Jamie Iles wrote:
> > This is largely a repost of the series I posted back in March. The only changes
> > since then are rebasing onto 3.1-rc1 and changing the gem conditionals from a
> > boolean in the macb structure to an inline helper as requested by
> > Jean-Christophe.
> >
> > This has been run-tested on picoxcell and compile tested for all AT91 platforms
> > but I couldn't get a working cross compiler for avr32.
> >
> > All patches are available in a git branch at
> >
> > git://github.com/jamieiles/linux-2.6-ji.git macb-gem
> >
> looks good except few comments
>
> I'll test it later this week
Have you had chance to test this series? I'd like to get it into Arnd's
tree and into next for a bit so we can get it into the next release if
possible.
Thanks,
Jamie
^ permalink raw reply
* [PATCH 0/4] skb fragment API: convert network core and protocols
From: Ian Campbell @ 2011-08-23 9:44 UTC (permalink / raw)
To: netdev
The following series converts the net core and protocol stacks to the
SKB pages fragment API introduced in 131ea6675c76.
This is part of my series to enable visibility into SKB paged fragment's
lifecycles, [0] contains some more background and rationale but
basically the completed series will allow entities which inject pages
into the networking stack to receive a notification when the stack has
really finished with those pages (i.e. including retransmissions,
clones, pull-ups etc) and not just when the original skb is finished
with, which is beneficial to many subsystems which wish to inject pages
into the network stack without giving up full ownership of those page's
lifecycle. It implements something broadly along the lines of what was
described in [1].
Cheers,
Ian.
[0] http://marc.info/?l=linux-netdev&m=131072801125521&w=2
[1] http://marc.info/?l=linux-netdev&m=130925719513084&w=2
^ permalink raw reply
* [PATCH 1/4] net: convert core to skb paged frag APIs
From: Ian Campbell @ 2011-08-23 9:44 UTC (permalink / raw)
To: netdev
Cc: Ian Campbell, David S. Miller, Eric Dumazet,
Michał Mirosław
In-Reply-To: <1314092683.10283.21.camel@zakaz.uk.xensource.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: netdev@vger.kernel.org
---
include/linux/skbuff.h | 4 ++--
net/core/datagram.c | 8 ++++----
net/core/dev.c | 16 +++++++++-------
net/core/kmap_skb.h | 2 +-
net/core/pktgen.c | 3 +--
net/core/skbuff.c | 29 +++++++++++++++--------------
net/core/sock.c | 12 +++++-------
net/core/user_dma.c | 2 +-
8 files changed, 38 insertions(+), 38 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 7b0e177..8d42628 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1898,12 +1898,12 @@ static inline int skb_add_data(struct sk_buff *skb,
}
static inline int skb_can_coalesce(struct sk_buff *skb, int i,
- struct page *page, int off)
+ const struct page *page, int off)
{
if (i) {
struct skb_frag_struct *frag = &skb_shinfo(skb)->frags[i - 1];
- return page == frag->page &&
+ return page == skb_frag_page(frag) &&
off == frag->page_offset + frag->size;
}
return 0;
diff --git a/net/core/datagram.c b/net/core/datagram.c
index 18ac112..6449bed 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -332,7 +332,7 @@ int skb_copy_datagram_iovec(const struct sk_buff *skb, int offset,
int err;
u8 *vaddr;
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
- struct page *page = frag->page;
+ struct page *page = skb_frag_page(frag);
if (copy > len)
copy = len;
@@ -418,7 +418,7 @@ int skb_copy_datagram_const_iovec(const struct sk_buff *skb, int offset,
int err;
u8 *vaddr;
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
- struct page *page = frag->page;
+ struct page *page = skb_frag_page(frag);
if (copy > len)
copy = len;
@@ -508,7 +508,7 @@ int skb_copy_datagram_from_iovec(struct sk_buff *skb, int offset,
int err;
u8 *vaddr;
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
- struct page *page = frag->page;
+ struct page *page = skb_frag_page(frag);
if (copy > len)
copy = len;
@@ -594,7 +594,7 @@ static int skb_copy_and_csum_datagram(const struct sk_buff *skb, int offset,
int err = 0;
u8 *vaddr;
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
- struct page *page = frag->page;
+ struct page *page = skb_frag_page(frag);
if (copy > len)
copy = len;
diff --git a/net/core/dev.c b/net/core/dev.c
index a4306f7..4053008 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1949,9 +1949,11 @@ static int illegal_highdma(struct net_device *dev, struct sk_buff *skb)
#ifdef CONFIG_HIGHMEM
int i;
if (!(dev->features & NETIF_F_HIGHDMA)) {
- for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
- if (PageHighMem(skb_shinfo(skb)->frags[i].page))
+ for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
+ skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+ if (PageHighMem(skb_frag_page(frag)))
return 1;
+ }
}
if (PCI_DMA_BUS_IS_PHYS) {
@@ -1960,7 +1962,8 @@ static int illegal_highdma(struct net_device *dev, struct sk_buff *skb)
if (!pdev)
return 0;
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
- dma_addr_t addr = page_to_phys(skb_shinfo(skb)->frags[i].page);
+ skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
+ dma_addr_t addr = page_to_phys(skb_frag_page(frag));
if (!pdev->dma_mask || addr + PAGE_SIZE - 1 > *pdev->dma_mask)
return 1;
}
@@ -3472,7 +3475,7 @@ pull:
skb_shinfo(skb)->frags[0].size -= grow;
if (unlikely(!skb_shinfo(skb)->frags[0].size)) {
- put_page(skb_shinfo(skb)->frags[0].page);
+ skb_frag_unref(skb, 0);
memmove(skb_shinfo(skb)->frags,
skb_shinfo(skb)->frags + 1,
--skb_shinfo(skb)->nr_frags * sizeof(skb_frag_t));
@@ -3536,10 +3539,9 @@ void skb_gro_reset_offset(struct sk_buff *skb)
NAPI_GRO_CB(skb)->frag0_len = 0;
if (skb->mac_header == skb->tail &&
- !PageHighMem(skb_shinfo(skb)->frags[0].page)) {
+ !PageHighMem(skb_frag_page(&skb_shinfo(skb)->frags[0]))) {
NAPI_GRO_CB(skb)->frag0 =
- page_address(skb_shinfo(skb)->frags[0].page) +
- skb_shinfo(skb)->frags[0].page_offset;
+ skb_frag_address(&skb_shinfo(skb)->frags[0]);
NAPI_GRO_CB(skb)->frag0_len = skb_shinfo(skb)->frags[0].size;
}
}
diff --git a/net/core/kmap_skb.h b/net/core/kmap_skb.h
index 283c2b9..81e1ed7 100644
--- a/net/core/kmap_skb.h
+++ b/net/core/kmap_skb.h
@@ -7,7 +7,7 @@ static inline void *kmap_skb_frag(const skb_frag_t *frag)
local_bh_disable();
#endif
- return kmap_atomic(frag->page, KM_SKB_DATA_SOFTIRQ);
+ return kmap_atomic(skb_frag_page(frag), KM_SKB_DATA_SOFTIRQ);
}
static inline void kunmap_skb_frag(void *vaddr)
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index e35a6fb..796044a 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2602,8 +2602,7 @@ static void pktgen_finalize_skb(struct pktgen_dev *pkt_dev, struct sk_buff *skb,
if (!pkt_dev->page)
break;
}
- skb_shinfo(skb)->frags[i].page = pkt_dev->page;
- get_page(pkt_dev->page);
+ skb_frag_set_page(skb, i, pkt_dev->page);
skb_shinfo(skb)->frags[i].page_offset = 0;
/*last fragment, fill rest of data*/
if (i == (frags - 1))
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index e27334e..296afd0 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -326,7 +326,7 @@ static void skb_release_data(struct sk_buff *skb)
if (skb_shinfo(skb)->nr_frags) {
int i;
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
- put_page(skb_shinfo(skb)->frags[i].page);
+ skb_frag_unref(skb, i);
}
/*
@@ -809,7 +809,7 @@ struct sk_buff *pskb_copy(struct sk_buff *skb, gfp_t gfp_mask)
}
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
skb_shinfo(n)->frags[i] = skb_shinfo(skb)->frags[i];
- get_page(skb_shinfo(n)->frags[i].page);
+ skb_frag_ref(skb, i);
}
skb_shinfo(n)->nr_frags = i;
}
@@ -901,7 +901,7 @@ int pskb_expand_head(struct sk_buff *skb, int nhead, int ntail,
skb_shinfo(skb)->tx_flags &= ~SKBTX_DEV_ZEROCOPY;
}
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
- get_page(skb_shinfo(skb)->frags[i].page);
+ skb_frag_ref(skb, i);
if (skb_has_frag_list(skb))
skb_clone_fraglist(skb);
@@ -1181,7 +1181,7 @@ drop_pages:
skb_shinfo(skb)->nr_frags = i;
for (; i < nfrags; i++)
- put_page(skb_shinfo(skb)->frags[i].page);
+ skb_frag_unref(skb, i);
if (skb_has_frag_list(skb))
skb_drop_fraglist(skb);
@@ -1350,7 +1350,7 @@ pull_pages:
k = 0;
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
if (skb_shinfo(skb)->frags[i].size <= eat) {
- put_page(skb_shinfo(skb)->frags[i].page);
+ skb_frag_unref(skb, i);
eat -= skb_shinfo(skb)->frags[i].size;
} else {
skb_shinfo(skb)->frags[k] = skb_shinfo(skb)->frags[i];
@@ -1609,7 +1609,8 @@ static int __skb_splice_bits(struct sk_buff *skb, struct pipe_inode_info *pipe,
for (seg = 0; seg < skb_shinfo(skb)->nr_frags; seg++) {
const skb_frag_t *f = &skb_shinfo(skb)->frags[seg];
- if (__splice_segment(f->page, f->page_offset, f->size,
+ if (__splice_segment(skb_frag_page(f),
+ f->page_offset, f->size,
offset, len, skb, spd, 0, sk, pipe))
return 1;
}
@@ -2154,7 +2155,7 @@ static inline void skb_split_no_header(struct sk_buff *skb,
* where splitting is expensive.
* 2. Split is accurately. We make this.
*/
- get_page(skb_shinfo(skb)->frags[i].page);
+ skb_frag_ref(skb, i);
skb_shinfo(skb1)->frags[0].page_offset += len - pos;
skb_shinfo(skb1)->frags[0].size -= len - pos;
skb_shinfo(skb)->frags[i].size = len - pos;
@@ -2229,7 +2230,8 @@ int skb_shift(struct sk_buff *tgt, struct sk_buff *skb, int shiftlen)
* commit all, so that we don't have to undo partial changes
*/
if (!to ||
- !skb_can_coalesce(tgt, to, fragfrom->page, fragfrom->page_offset)) {
+ !skb_can_coalesce(tgt, to, skb_frag_page(fragfrom),
+ fragfrom->page_offset)) {
merge = -1;
} else {
merge = to - 1;
@@ -2276,7 +2278,7 @@ int skb_shift(struct sk_buff *tgt, struct sk_buff *skb, int shiftlen)
to++;
} else {
- get_page(fragfrom->page);
+ __skb_frag_ref(fragfrom);
fragto->page = fragfrom->page;
fragto->page_offset = fragfrom->page_offset;
fragto->size = todo;
@@ -2298,7 +2300,7 @@ int skb_shift(struct sk_buff *tgt, struct sk_buff *skb, int shiftlen)
fragto = &skb_shinfo(tgt)->frags[merge];
fragto->size += fragfrom->size;
- put_page(fragfrom->page);
+ __skb_frag_unref(fragfrom);
}
/* Reposition in the original skb */
@@ -2543,8 +2545,7 @@ int skb_append_datato_frags(struct sock *sk, struct sk_buff *skb,
left = PAGE_SIZE - frag->page_offset;
copy = (length > left)? left : length;
- ret = getfrag(from, (page_address(frag->page) +
- frag->page_offset + frag->size),
+ ret = getfrag(from, skb_frag_address(frag) + frag->size,
offset, copy, 0, skb);
if (ret < 0)
return -EFAULT;
@@ -2696,7 +2697,7 @@ struct sk_buff *skb_segment(struct sk_buff *skb, u32 features)
while (pos < offset + len && i < nfrags) {
*frag = skb_shinfo(skb)->frags[i];
- get_page(frag->page);
+ __skb_frag_ref(frag);
size = frag->size;
if (pos < offset) {
@@ -2919,7 +2920,7 @@ __skb_to_sgvec(struct sk_buff *skb, struct scatterlist *sg, int offset, int len)
if (copy > len)
copy = len;
- sg_set_page(&sg[elt], frag->page, copy,
+ sg_set_page(&sg[elt], skb_frag_page(frag), copy,
frag->page_offset+offset-start);
elt++;
if (!(len -= copy))
diff --git a/net/core/sock.c b/net/core/sock.c
index 9997026..b29ab61 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1533,7 +1533,6 @@ struct sk_buff *sock_alloc_send_pskb(struct sock *sk, unsigned long header_len,
skb_shinfo(skb)->nr_frags = npages;
for (i = 0; i < npages; i++) {
struct page *page;
- skb_frag_t *frag;
page = alloc_pages(sk->sk_allocation, 0);
if (!page) {
@@ -1543,12 +1542,11 @@ struct sk_buff *sock_alloc_send_pskb(struct sock *sk, unsigned long header_len,
goto failure;
}
- frag = &skb_shinfo(skb)->frags[i];
- frag->page = page;
- frag->page_offset = 0;
- frag->size = (data_len >= PAGE_SIZE ?
- PAGE_SIZE :
- data_len);
+ __skb_fill_page_desc(skb, i,
+ page, 0,
+ (data_len >= PAGE_SIZE ?
+ PAGE_SIZE :
+ data_len));
data_len -= PAGE_SIZE;
}
diff --git a/net/core/user_dma.c b/net/core/user_dma.c
index 25d717e..34e9664 100644
--- a/net/core/user_dma.c
+++ b/net/core/user_dma.c
@@ -78,7 +78,7 @@ int dma_skb_copy_datagram_iovec(struct dma_chan *chan,
copy = end - offset;
if (copy > 0) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
- struct page *page = frag->page;
+ struct page *page = skb_frag_page(frag);
if (copy > len)
copy = len;
--
1.7.2.5
^ permalink raw reply related
* [PATCH 2/4] net: ipv4: convert to SKB frag APIs
From: Ian Campbell @ 2011-08-23 9:44 UTC (permalink / raw)
To: netdev
Cc: Ian Campbell, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <1314092683.10283.21.camel@zakaz.uk.xensource.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org
---
net/ipv4/inet_lro.c | 2 +-
net/ipv4/ip_output.c | 7 ++++---
net/ipv4/tcp.c | 3 ++-
net/ipv4/tcp_output.c | 2 +-
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/inet_lro.c b/net/ipv4/inet_lro.c
index ef7ae60..8e6be5a 100644
--- a/net/ipv4/inet_lro.c
+++ b/net/ipv4/inet_lro.c
@@ -433,7 +433,7 @@ static struct sk_buff *__lro_proc_segment(struct net_lro_mgr *lro_mgr,
if (!lro_mgr->get_frag_header ||
lro_mgr->get_frag_header(frags, (void *)&mac_hdr, (void *)&iph,
(void *)&tcph, &flags, priv)) {
- mac_hdr = page_address(frags->page) + frags->page_offset;
+ mac_hdr = skb_frag_address(frags);
goto out1;
}
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 8c65633..ae3bb14 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -989,13 +989,13 @@ alloc_new_skb:
if (page && (left = PAGE_SIZE - off) > 0) {
if (copy >= left)
copy = left;
- if (page != frag->page) {
+ if (page != skb_frag_page(frag)) {
if (i == MAX_SKB_FRAGS) {
err = -EMSGSIZE;
goto error;
}
- get_page(page);
skb_fill_page_desc(skb, i, page, off, 0);
+ skb_frag_ref(skb, i);
frag = &skb_shinfo(skb)->frags[i];
}
} else if (i < MAX_SKB_FRAGS) {
@@ -1015,7 +1015,8 @@ alloc_new_skb:
err = -EMSGSIZE;
goto error;
}
- if (getfrag(from, page_address(frag->page)+frag->page_offset+frag->size, offset, copy, skb->len, skb) < 0) {
+ if (getfrag(from, skb_frag_address(frag)+frag->size,
+ offset, copy, skb->len, skb) < 0) {
err = -EFAULT;
goto error;
}
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 46febca..5fe632c 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3035,7 +3035,8 @@ int tcp_md5_hash_skb_data(struct tcp_md5sig_pool *hp,
for (i = 0; i < shi->nr_frags; ++i) {
const struct skb_frag_struct *f = &shi->frags[i];
- sg_set_page(&sg, f->page, f->size, f->page_offset);
+ struct page *page = skb_frag_page(f);
+ sg_set_page(&sg, page, f->size, f->page_offset);
if (crypto_hash_update(desc, &sg, f->size))
return 1;
}
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 882e0b0..0377c06 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1095,7 +1095,7 @@ static void __pskb_trim_head(struct sk_buff *skb, int len)
k = 0;
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
if (skb_shinfo(skb)->frags[i].size <= eat) {
- put_page(skb_shinfo(skb)->frags[i].page);
+ skb_frag_unref(skb, i);
eat -= skb_shinfo(skb)->frags[i].size;
} else {
skb_shinfo(skb)->frags[k] = skb_shinfo(skb)->frags[i];
--
1.7.2.5
^ permalink raw reply related
* [PATCH 3/4] net: ipv6: convert to SKB frag APIs
From: Ian Campbell @ 2011-08-23 9:45 UTC (permalink / raw)
To: netdev
Cc: Ian Campbell, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy
In-Reply-To: <1314092683.10283.21.camel@zakaz.uk.xensource.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org
---
net/ipv6/ip6_output.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 4c882cf..835c04b 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1480,13 +1480,13 @@ alloc_new_skb:
if (page && (left = PAGE_SIZE - off) > 0) {
if (copy >= left)
copy = left;
- if (page != frag->page) {
+ if (page != skb_frag_page(frag)) {
if (i == MAX_SKB_FRAGS) {
err = -EMSGSIZE;
goto error;
}
- get_page(page);
skb_fill_page_desc(skb, i, page, sk->sk_sndmsg_off, 0);
+ skb_frag_ref(skb, i);
frag = &skb_shinfo(skb)->frags[i];
}
} else if(i < MAX_SKB_FRAGS) {
@@ -1506,7 +1506,8 @@ alloc_new_skb:
err = -EMSGSIZE;
goto error;
}
- if (getfrag(from, page_address(frag->page)+frag->page_offset+frag->size, offset, copy, skb->len, skb) < 0) {
+ if (getfrag(from, skb_frag_address(frag)+frag->size,
+ offset, copy, skb->len, skb) < 0) {
err = -EFAULT;
goto error;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCH 4/4] net: xfrm: convert to SKB frag APIs
From: Ian Campbell @ 2011-08-23 9:45 UTC (permalink / raw)
To: netdev; +Cc: Ian Campbell, David S. Miller
In-Reply-To: <1314092683.10283.21.camel@zakaz.uk.xensource.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
net/xfrm/xfrm_ipcomp.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/xfrm/xfrm_ipcomp.c b/net/xfrm/xfrm_ipcomp.c
index fc91ad7..f781b9a 100644
--- a/net/xfrm/xfrm_ipcomp.c
+++ b/net/xfrm/xfrm_ipcomp.c
@@ -70,26 +70,29 @@ static int ipcomp_decompress(struct xfrm_state *x, struct sk_buff *skb)
while ((scratch += len, dlen -= len) > 0) {
skb_frag_t *frag;
+ struct page *page;
err = -EMSGSIZE;
if (WARN_ON(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS))
goto out;
frag = skb_shinfo(skb)->frags + skb_shinfo(skb)->nr_frags;
- frag->page = alloc_page(GFP_ATOMIC);
+ page = alloc_page(GFP_ATOMIC);
err = -ENOMEM;
- if (!frag->page)
+ if (!page)
goto out;
+ __skb_frag_set_page(frag, page);
+
len = PAGE_SIZE;
if (dlen < len)
len = dlen;
- memcpy(page_address(frag->page), scratch, len);
-
frag->page_offset = 0;
frag->size = len;
+ memcpy(skb_frag_address(frag), scratch, len);
+
skb->truesize += len;
skb->data_len += len;
skb->len += len;
--
1.7.2.5
^ permalink raw reply related
* Assalam-o-alaikum!
From: Sabah Rabil @ 2011-08-23 9:46 UTC (permalink / raw)
Greetings. My name is Sabah Rahil , i'm in urgent need of your assistance please
respond to my email.
Regards
Sabah Rahil
^ permalink raw reply
* Re: IPv6 multicast snooping behaviour on 2.6.39-rc2 and later
From: Eric Dumazet @ 2011-08-23 9:57 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev, Linus Lüssing, Herbert Xu
In-Reply-To: <4E5367CA.3090005@sfc.wide.ad.jp>
Le mardi 23 août 2011 à 17:41 +0900, Ang Way Chuang a écrit :
> Hi all,
>
> Sorry for cross-posting. I have a testbed setup on my VM
> environment that needs to use MLDv2 report message. My PIM router
> which is connected to a port on the bridge relies upon MLDv2 message
> to work. However, the setup failed to work after 2.6.39-rc2 or later.
> MLDv2 won't be forwarded to any slave ports bound to the bridge
> interface. Specifically, I track the cause down to this commit id:
>
> ff9a57a62afbbe2d0f3a09af321f1fd7645f38a5
>
> However, as soon as I disable multicast snooping on sysfs, MLDv2
> message can be forwarded again.
>
> I am not knowledgeable on the subject of multicast snooping, but
> is this right behaviour for multicast snooping? IPv4 doesn't seem to
> suffer the same fate though, IGMP can be forwarded even if
> multicast_snooping is enabled. Thank you in advance.
>
Thanks very much for the report and your tracking.
Added some CC
I wonder if the ff9a57a62afb commit doesnt uncover a prior bug, could
you try the following patch ?
Thanks !
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 2d85ca7..51e3b2d 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1520,6 +1520,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
err = pskb_trim_rcsum(skb2, len);
if (err)
goto out;
+ icmp6h = icmp6_hdr(skb2);
}
switch (skb2->ip_summed) {
^ permalink raw reply related
* Re: [net-next 4/9] plip: Move the PLIP driver
From: Alan Cox @ 2011-08-23 10:12 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo, Niibe Yutaka
In-Reply-To: <1314089149-27205-5-git-send-email-jeffrey.t.kirsher@intel.com>
On Tue, 23 Aug 2011 01:45:44 -0700
Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> Move the Parallel Line Internet Protocol (PLIP) driver into
> drivers/net/plip/ and make the necessary Kconfig and Makefile changes.
Acked-by: Alan Cox <alan@linux.intel.com>
Alan
^ permalink raw reply
* Re: [net-next 5/9] slip: Move the SLIP drivers
From: Alan Cox @ 2011-08-23 10:13 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, netdev, gospo
In-Reply-To: <1314089149-27205-6-git-send-email-jeffrey.t.kirsher@intel.com>
On Tue, 23 Aug 2011 01:45:45 -0700
Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> Move the Serial Line Internet Protocol (SLIP) drivers into
> drivers/net/slip/ and make the necessary Kconfig and Makefile
> changes.
>
> CC: Alan Cox <alan@linux.intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* Re: IPv6 multicast snooping behaviour on 2.6.39-rc2 and later
From: Ang Way Chuang @ 2011-08-23 12:31 UTC (permalink / raw)
To: Eric Dumazet, netdev; +Cc: Linus Lüssing, Herbert Xu
In-Reply-To: <1314093424.2219.3.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Sorry for the blurb. I hope I've configured thunderbird properly to send in plain text. Hope you received my reply. I tried your patch on 3.0.3 and it didn't fix the problem.
Regards,
Ang
On 23/08/11 18:57, Eric Dumazet wrote:
> Le mardi 23 août 2011 à 17:41 +0900, Ang Way Chuang a écrit :
>> Hi all,
>>
>> Sorry for cross-posting. I have a testbed setup on my VM
>> environment that needs to use MLDv2 report message. My PIM router
>> which is connected to a port on the bridge relies upon MLDv2 message
>> to work. However, the setup failed to work after 2.6.39-rc2 or later.
>> MLDv2 won't be forwarded to any slave ports bound to the bridge
>> interface. Specifically, I track the cause down to this commit id:
>>
>> ff9a57a62afbbe2d0f3a09af321f1fd7645f38a5
>>
>> However, as soon as I disable multicast snooping on sysfs, MLDv2
>> message can be forwarded again.
>>
>> I am not knowledgeable on the subject of multicast snooping, but
>> is this right behaviour for multicast snooping? IPv4 doesn't seem to
>> suffer the same fate though, IGMP can be forwarded even if
>> multicast_snooping is enabled. Thank you in advance.
>>
> Thanks very much for the report and your tracking.
>
> Added some CC
>
> I wonder if the ff9a57a62afb commit doesnt uncover a prior bug, could
> you try the following patch ?
>
> Thanks !
>
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index 2d85ca7..51e3b2d 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -1520,6 +1520,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
> err = pskb_trim_rcsum(skb2, len);
> if (err)
> goto out;
> + icmp6h = icmp6_hdr(skb2);
> }
>
> switch (skb2->ip_summed) {
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] can: ti_hecc: Fix unintialized variable
From: Abhilash K V @ 2011-08-23 13:05 UTC (permalink / raw)
To: netdev; +Cc: wg, linux-kernel, =linux-omap, Abhilash K V
In ti_hecc_xmit(), local variable "data" is not initialized before
being used.
This initialization got inadvertently removed in the following patch:
can: Unify droping of invalid tx skbs and netdev stats
Acked-by: Anant Gole <anantgole@ti.com>
Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
---
drivers/net/can/ti_hecc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index f7bbde9..0b19a17 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -503,9 +503,9 @@ static netdev_tx_t ti_hecc_xmit(struct sk_buff *skb, struct net_device *ndev)
spin_unlock_irqrestore(&priv->mbx_lock, flags);
/* Prepare mailbox for transmission */
+ data = cf->can_dlc | (get_tx_head_prio(priv) << 8);
if (cf->can_id & CAN_RTR_FLAG) /* Remote transmission request */
data |= HECC_CANMCF_RTR;
- data |= get_tx_head_prio(priv) << 8;
hecc_write_mbx(priv, mbxno, HECC_CANMCF, data);
if (cf->can_id & CAN_EFF_FLAG) /* Extended frame format */
--
1.6.2.4
^ permalink raw reply related
* [PATCH] can: ti_hecc: Fix uninitialized spinlock in probe
From: Abhilash K V @ 2011-08-23 13:05 UTC (permalink / raw)
To: netdev; +Cc: wg, linux-kernel, =linux-omap, Abhilash K V
In ti_hecc_probe(), the spinlock priv->mbx_lock is not
inited, causing a spinlock lockup BUG.
Acked-by: Anant Gole <anantgole@ti.com>
Signed-off-by: Abhilash K V <abhilash.kv@ti.com>
---
drivers/net/can/ti_hecc.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index 0b19a17..a812492 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -923,6 +923,7 @@ static int ti_hecc_probe(struct platform_device *pdev)
priv->can.do_get_state = ti_hecc_get_state;
priv->can.ctrlmode_supported = CAN_CTRLMODE_3_SAMPLES;
+ spin_lock_init(&priv->mbx_lock);
ndev->irq = irq->start;
ndev->flags |= IFF_ECHO;
platform_set_drvdata(pdev, ndev);
--
1.6.2.4
^ permalink raw reply related
* Re: IPv6 multicast snooping behaviour on 2.6.39-rc2 and later
From: Eric Dumazet @ 2011-08-23 13:10 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev, Linus Lüssing, Herbert Xu
In-Reply-To: <4E539DA8.1070504@sfc.wide.ad.jp>
Le mardi 23 août 2011 à 21:31 +0900, Ang Way Chuang a écrit :
> Sorry for the blurb. I hope I've configured thunderbird properly to
> send in plain text. Hope you received my reply. I tried your patch on
> 3.0.3 and it didn't fix the problem.
Thanks for trying !
Ok could you please try following patch then ?
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 2d85ca7..e9b32a3 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1497,7 +1497,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
if (!pskb_may_pull(skb2, offset + sizeof(struct icmp6hdr)))
goto out;
- len -= offset - skb_network_offset(skb2);
+ len -= offset;
__skb_pull(skb2, offset);
skb_reset_transport_header(skb2);
@@ -1520,6 +1520,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
err = pskb_trim_rcsum(skb2, len);
if (err)
goto out;
+ icmp6h = icmp6_hdr(skb2);
}
switch (skb2->ip_summed) {
^ permalink raw reply related
* Re: r8169 hard-freezes the system on big network loads
From: Francois Romieu @ 2011-08-23 13:17 UTC (permalink / raw)
To: Michael Brade; +Cc: netdev, nic_swsd
In-Reply-To: <20110821221140.GA20696@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> :
[...]
> Yes. There is enough data for me to reproduce the bug with the
> exact same chipset.
I can not generate a single rx error and the driver refuses to crash :o/
Can you apply the patch below on top of 3.1.0-rc3 and see if it makes
a difference ?
Thanks.
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 02339b3..c54ed17 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -5326,10 +5326,6 @@ static int rtl8169_rx_interrupt(struct net_device *dev,
dev->stats.rx_length_errors++;
if (status & RxCRC)
dev->stats.rx_crc_errors++;
- if (status & RxFOVF) {
- rtl8169_schedule_work(dev, rtl8169_reset_task);
- dev->stats.rx_fifo_errors++;
- }
rtl8169_mark_to_asic(desc, rx_buf_sz);
} else {
struct sk_buff *skb;
^ permalink raw reply related
* Re: [PATCH 00/11] various fixes v3
From: Jason Baron @ 2011-08-23 13:54 UTC (permalink / raw)
To: Greg KH
Cc: gregkh, joe, jim.cromie, bvanassche, linux-kernel, davem,
aloisio.almeida, netdev
In-Reply-To: <20110823013224.GA7190@kroah.com>
On Mon, Aug 22, 2011 at 06:32:24PM -0700, Greg KH wrote:
> On Thu, Aug 11, 2011 at 02:36:17PM -0400, Jason Baron wrote:
> > Hi,
> >
> > Dynamic debug fixes and cleanups. Only changes from v2 are a re-base against
> > Linus's latest tree and the inclusion of the re-posted version for patch #11.
>
> I applied the first 8, as it seemed like there was lots of discussion
> about #9.
>
> Care to send the rest when you all have those worked out?
>
Hi Greg,
The comments on #9 were mostly around formatting. The 'take #2' version
is fine: https://lkml.org/lkml/2011/8/15/395. Do you need me to re-post
it? If not please also take 10, 11.
Thanks,
-Jason
^ permalink raw reply
* Re: [PATCH 0/2] pktgen: Clone skb to avoid corruption of skbs in ndo_start_xmit methods (v3)
From: Ben Hutchings @ 2011-08-23 14:01 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev
In-Reply-To: <20110822181420.GD12337@hmsreliant.think-freely.org>
On Mon, 2011-08-22 at 14:14 -0400, Neil Horman wrote:
> On Mon, Aug 22, 2011 at 05:17:37PM +0100, Ben Hutchings wrote:
> > On Sun, 2011-08-21 at 20:27 -0400, Neil Horman wrote:
> > > On Wed, Aug 17, 2011 at 04:07:17PM +0100, Ben Hutchings wrote:
> > > > On Tue, 2011-07-26 at 12:05 -0400, Neil Horman wrote:
> > > > > Ok, after considering all your comments, Dave suggested this as an alternate
> > > > > approach:
> > > > >
> > > > > 1) We create a new priv_flag, IFF_SKB_TX_SHARED, to identify drivers capable of
> > > > > handling shared skbs. Default is to not set this flag
> > > > >
> > > > > 2) Modify ether_setup to enable this flag, under the assumption that any driver
> > > > > calling this function is initalizing a real ethernet device and as such can
> > > > > handle shared skbs since they don't tend to store state in the skb struct.
> > > > > Pktgen can then query this flag when a user script attempts to issue the
> > > > > clone_skb command and decide if it is to be alowed or not.
> > > > [...]
> > > >
> > > > A bunch of Ethernet drivers do skb_pad() or skb_padto() in their
> > > > ndo_start_xmit implementations, either to avoid hardware bugs or because
> > > > the MAC doesn't automatically pad to the minimum frame length. This
> > > > presumably means they can't generally handle shared skbs, though in the
> > > > specific case of pktgen it should be safe as long as a single skb is not
> > > > submitted by multiple threads at once.
> > > >
> > > Agreed, given that pktgen is doing skb sharing in a serialized manner (i.e. one
> > > thread of execution increasing skb->users rather than in multiple threads), the
> > > skb_pad[to] cases are safe. Are there cases in which shared skbs are
> > > transmitted in parallel threads that we need to check for?
> >
> > Not that I'm aware of. However, you have defined the flag to mean 'safe
> > to send shared skbs', and this is not generally true for those drivers.
> >
> > So please decide whether:
> > a. The flag means 'safe to send shared skbs' (i.e. the TX path does not
> > modify the skb) and drivers which pad must clear it on their devices.
> > b. The flag means 'safe to send shared skbs in the way ptkgen does', and
> > the restrictions this places on the user and driver should be specified.
> >
>
> The flag means safe to send shared skbs.
>
> Actually looking closer at this, I don't think this is much of a problem at all.
> The flag is cleared on devices for which it is unsafe to send shared skbs, not
> because there are multiple users of the skb in parallel, but because the driver
> expects to have continued exclusive access to the skb after the drivers
> ndo_start_xmit method returns.
>
> In the pktgen case, skbs have skb->users > 1, but all users exist in the same
> execution context, making their transmission serialized.
[...]
So it is not *generally* safe to send shared skbs to drivers that make
idempotent changes to the skb. There is a restriction and while pktgen
operates within it today I don't want it to be an unwritten assumption.
> So even though drivers that call skb_pad[to] modify the skb, its perfectly ok to
> do so, as long as they don't assume that the struct skb will remain in that
> state after the driver is done with it.
>
> This works out perfectly well for skb_padto calls, since the function reduces to
> a no-op after the minimal tail size has been reached.
[...]
Right, that's what I want to be specified. Did you miss my own
follow-up? I proposed this description for the interface flag:
The ndo_start_xmit operation for this interface either does not
modify the given skb or modifies it idempotently. A single skb
may be transmitted repeatedly on a single queue of this
interface, but not on multiple queues or on multiple interfaces.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: IPv6 multicast snooping behaviour on 2.6.39-rc2 and later
From: Ang Way Chuang @ 2011-08-23 14:04 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Linus Lüssing, Herbert Xu
In-Reply-To: <1314105027.2219.7.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Tough luck :( Got no love from bridge. It still doesn't work with your latest patch. Please keep sending those patches.
On 23/08/11 22:10, Eric Dumazet wrote:
> Le mardi 23 août 2011 à 21:31 +0900, Ang Way Chuang a écrit :
>> Sorry for the blurb. I hope I've configured thunderbird properly to
>> send in plain text. Hope you received my reply. I tried your patch on
>> 3.0.3 and it didn't fix the problem.
>
> Thanks for trying !
>
> Ok could you please try following patch then ?
>
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index 2d85ca7..e9b32a3 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -1497,7 +1497,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
> if (!pskb_may_pull(skb2, offset + sizeof(struct icmp6hdr)))
> goto out;
>
> - len -= offset - skb_network_offset(skb2);
> + len -= offset;
>
> __skb_pull(skb2, offset);
> skb_reset_transport_header(skb2);
> @@ -1520,6 +1520,7 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
> err = pskb_trim_rcsum(skb2, len);
> if (err)
> goto out;
> + icmp6h = icmp6_hdr(skb2);
> }
>
> switch (skb2->ip_summed) {
>
>
>
^ permalink raw reply
* Re: [PATCH 0/2] pktgen: Clone skb to avoid corruption of skbs in ndo_start_xmit methods (v3)
From: Neil Horman @ 2011-08-23 15:13 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1314108084.2821.5.camel@bwh-desktop>
On Tue, Aug 23, 2011 at 03:01:24PM +0100, Ben Hutchings wrote:
> On Mon, 2011-08-22 at 14:14 -0400, Neil Horman wrote:
> > On Mon, Aug 22, 2011 at 05:17:37PM +0100, Ben Hutchings wrote:
> > > On Sun, 2011-08-21 at 20:27 -0400, Neil Horman wrote:
> > > > On Wed, Aug 17, 2011 at 04:07:17PM +0100, Ben Hutchings wrote:
> > > > > On Tue, 2011-07-26 at 12:05 -0400, Neil Horman wrote:
> > > > > > Ok, after considering all your comments, Dave suggested this as an alternate
> > > > > > approach:
> > > > > >
> > > > > > 1) We create a new priv_flag, IFF_SKB_TX_SHARED, to identify drivers capable of
> > > > > > handling shared skbs. Default is to not set this flag
> > > > > >
> > > > > > 2) Modify ether_setup to enable this flag, under the assumption that any driver
> > > > > > calling this function is initalizing a real ethernet device and as such can
> > > > > > handle shared skbs since they don't tend to store state in the skb struct.
> > > > > > Pktgen can then query this flag when a user script attempts to issue the
> > > > > > clone_skb command and decide if it is to be alowed or not.
> > > > > [...]
> > > > >
> > > > > A bunch of Ethernet drivers do skb_pad() or skb_padto() in their
> > > > > ndo_start_xmit implementations, either to avoid hardware bugs or because
> > > > > the MAC doesn't automatically pad to the minimum frame length. This
> > > > > presumably means they can't generally handle shared skbs, though in the
> > > > > specific case of pktgen it should be safe as long as a single skb is not
> > > > > submitted by multiple threads at once.
> > > > >
> > > > Agreed, given that pktgen is doing skb sharing in a serialized manner (i.e. one
> > > > thread of execution increasing skb->users rather than in multiple threads), the
> > > > skb_pad[to] cases are safe. Are there cases in which shared skbs are
> > > > transmitted in parallel threads that we need to check for?
> > >
> > > Not that I'm aware of. However, you have defined the flag to mean 'safe
> > > to send shared skbs', and this is not generally true for those drivers.
> > >
> > > So please decide whether:
> > > a. The flag means 'safe to send shared skbs' (i.e. the TX path does not
> > > modify the skb) and drivers which pad must clear it on their devices.
> > > b. The flag means 'safe to send shared skbs in the way ptkgen does', and
> > > the restrictions this places on the user and driver should be specified.
> > >
> >
> > The flag means safe to send shared skbs.
> >
> > Actually looking closer at this, I don't think this is much of a problem at all.
> > The flag is cleared on devices for which it is unsafe to send shared skbs, not
> > because there are multiple users of the skb in parallel, but because the driver
> > expects to have continued exclusive access to the skb after the drivers
> > ndo_start_xmit method returns.
> >
> > In the pktgen case, skbs have skb->users > 1, but all users exist in the same
> > execution context, making their transmission serialized.
> [...]
>
> So it is not *generally* safe to send shared skbs to drivers that make
> idempotent changes to the skb. There is a restriction and while pktgen
> operates within it today I don't want it to be an unwritten assumption.
>
It _is_ generally safe to make idempotent changes to an skb when their shared,
thats what I was explaining in my previous post. The only restriction we need
to concern ourselves with is the drivers assumption that any modifications
(idempotent or not) will be preserved after the return from ndo_start_xmit.
> > So even though drivers that call skb_pad[to] modify the skb, its perfectly ok to
> > do so, as long as they don't assume that the struct skb will remain in that
> > state after the driver is done with it.
> >
> > This works out perfectly well for skb_padto calls, since the function reduces to
> > a no-op after the minimal tail size has been reached.
> [...]
>
> Right, that's what I want to be specified. Did you miss my own
> follow-up? I proposed this description for the interface flag:
>
> The ndo_start_xmit operation for this interface either does not
> modify the given skb or modifies it idempotently. A single skb
> may be transmitted repeatedly on a single queue of this
> interface, but not on multiple queues or on multiple interfaces.
>
No, I read it, I just don't agree with it. :). Specifically I disagree with the
langauge indicating that you cannot transmit a shared skb on multiple queues or
on multiple interfaces. You can in fact do that sanely with shared skbs,
because to do so you are required to serialize their transmission anyway. By
definition they're shared, and you can't send them to multiple devices without
modifing data in the skb that may be read in parallel in an alternate execution
context.
In short, what I'm saying is that there is no way to safely send a shared skb in
parallel to multiple queues/interfaces without introducing other bugs orthogonal
to the one prevented by the flag I added. The only thing the flag indicates is
that the driver can't handle non-idempotent changes to skbs (like being added to
an sk_buff_head list)
I think if you really want to clarify the meaning of the flag, I would add
language to it like:
The ndo_start_xmit operation either makes no changes to the skb data,
or makes only idempotent changes, and does not expect any changes to
persist after the return from nod_start_xmit
Its really the expectation of persistence that we need to worry about here. If
a driver adds an skb to a list for deferred transmission, for example, it
assumes that it owns the skb, and that its state will remain unchanged after the
return from ndo_start_xmit, but in the shared case thats not a safe assumption
to make because in the shared case teh network stack is once again free to
modify the skb.
If you're ok with my language, I'll put a patch together for that.
Neil
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
>
^ permalink raw reply
* Re: [PATCH 00/11] various fixes v3
From: Greg KH @ 2011-08-23 15:15 UTC (permalink / raw)
To: Jason Baron
Cc: Greg KH, joe, jim.cromie, bvanassche, linux-kernel, davem,
aloisio.almeida, netdev
In-Reply-To: <20110823135452.GA2526@redhat.com>
On Tue, Aug 23, 2011 at 09:54:53AM -0400, Jason Baron wrote:
> On Mon, Aug 22, 2011 at 06:32:24PM -0700, Greg KH wrote:
> > On Thu, Aug 11, 2011 at 02:36:17PM -0400, Jason Baron wrote:
> > > Hi,
> > >
> > > Dynamic debug fixes and cleanups. Only changes from v2 are a re-base against
> > > Linus's latest tree and the inclusion of the re-posted version for patch #11.
> >
> > I applied the first 8, as it seemed like there was lots of discussion
> > about #9.
> >
> > Care to send the rest when you all have those worked out?
> >
>
> Hi Greg,
>
> The comments on #9 were mostly around formatting. The 'take #2' version
> is fine: https://lkml.org/lkml/2011/8/15/395. Do you need me to re-post
> it? If not please also take 10, 11.
As stated above, pleae resend what you want me to apply.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/2] pktgen: Clone skb to avoid corruption of skbs in ndo_start_xmit methods (v3)
From: Ben Hutchings @ 2011-08-23 15:53 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev
In-Reply-To: <20110823151354.GA21473@hmsreliant.think-freely.org>
On Tue, 2011-08-23 at 11:13 -0400, Neil Horman wrote:
> On Tue, Aug 23, 2011 at 03:01:24PM +0100, Ben Hutchings wrote:
[...]
> > Right, that's what I want to be specified. Did you miss my own
> > follow-up? I proposed this description for the interface flag:
> >
> > The ndo_start_xmit operation for this interface either does not
> > modify the given skb or modifies it idempotently. A single skb
> > may be transmitted repeatedly on a single queue of this
> > interface, but not on multiple queues or on multiple interfaces.
> >
> No, I read it, I just don't agree with it. :). Specifically I disagree with the
> langauge indicating that you cannot transmit a shared skb on multiple queues or
> on multiple interfaces. You can in fact do that sanely with shared skbs,
> because to do so you are required to serialize their transmission anyway. By
> definition they're shared, and you can't send them to multiple devices without
> modifing data in the skb that may be read in parallel in an alternate execution
> context.
>
> In short, what I'm saying is that there is no way to safely send a shared skb in
> parallel to multiple queues/interfaces without introducing other bugs orthogonal
> to the one prevented by the flag I added. The only thing the flag indicates is
> that the driver can't handle non-idempotent changes to skbs (like being added to
> an sk_buff_head list)
In fact the caller must commit to a particular queue by setting skb->dev
and skb->queue_mapping. So I really was talking nonsense.
> I think if you really want to clarify the meaning of the flag, I would add
> language to it like:
> The ndo_start_xmit operation either makes no changes to the skb data,
> or makes only idempotent changes, and does not expect any changes to
> persist after the return from nod_start_xmit
>
> Its really the expectation of persistence that we need to worry about here. If
> a driver adds an skb to a list for deferred transmission, for example, it
> assumes that it owns the skb, and that its state will remain unchanged after the
> return from ndo_start_xmit, but in the shared case thats not a safe assumption
> to make because in the shared case teh network stack is once again free to
> modify the skb.
The skb data (including padding) needs to persist until DMA is complete,
even if the driver ignores the actual struct sk_buff from then on. And
pktgen certainly doesn't want to modify it.
> If you're ok with my language, I'll put a patch together for that.
I don't think we're quite there yet.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH 1/2] bnx2x: resurrect RX hashing
From: Michal Schmidt @ 2011-08-23 16:15 UTC (permalink / raw)
To: netdev
Cc: Michal Schmidt, Vladislav Zolotarov, Eilon Greenstein,
Dmitry Kravkov, MichałMirosław
bnx2x used to be able to set rxhash, but this was lost in the conversion
to hw_features (commit 66371c441).
Restore it and enable it by default.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
CC: Vladislav Zolotarov <vladz@broadcom.com>
CC: Eilon Greenstein <eilong@broadcom.com>
CC: Dmitry Kravkov <dmitry@broadcom.com>
CC: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 7204789..85dd294 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -10285,8 +10285,8 @@ static int __devinit bnx2x_init_dev(struct pci_dev *pdev,
dev->priv_flags |= IFF_UNICAST_FLT;
dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
- NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6 |
- NETIF_F_RXCSUM | NETIF_F_LRO | NETIF_F_HW_VLAN_TX;
+ NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_LRO |
+ NETIF_F_RXCSUM | NETIF_F_RXHASH | NETIF_F_HW_VLAN_TX;
dev->vlan_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_HIGHDMA;
^ permalink raw reply related
* [PATCH 2/2] bnx2x: expose HW RX VLAN stripping toggle
From: Michal Schmidt @ 2011-08-23 16:15 UTC (permalink / raw)
To: netdev
Cc: Michal Schmidt, Vladislav Zolotarov, Eilon Greenstein,
Dmitry Kravkov
In-Reply-To: <20110823161530.24707.67923.stgit@dhcp-29-224.brq.redhat.com>
Allow disabling of HW RX VLAN stripping with ethtool.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
CC: Vladislav Zolotarov <vladz@broadcom.com>
CC: Eilon Greenstein <eilong@broadcom.com>
CC: Dmitry Kravkov <dmitry@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 1 +
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 18 ++++++++++++++----
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 10 +++++-----
3 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index f127768..dd43634 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1178,6 +1178,7 @@ struct bnx2x {
#define NO_MCP_FLAG (1 << 9)
#define BP_NOMCP(bp) (bp->flags & NO_MCP_FLAG)
+#define RX_VLAN_STRIP_FLAG (1 << 10)
#define MF_FUNC_DIS (1 << 11)
#define OWN_CNIC_IRQ (1 << 12)
#define NO_ISCSI_OOO_FLAG (1 << 13)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index 93bff08..340bff9 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -385,6 +385,10 @@ static inline u16 bnx2x_set_lro_mss(struct bnx2x *bp, u16 parsing_flags,
else /* IPv4 */
hdrs_len += sizeof(struct iphdr);
+ /* VLAN header present and not stripped by HW */
+ if ((parsing_flags & PARSING_FLAGS_VLAN) &&
+ !(bp->flags & RX_VLAN_STRIP_FLAG))
+ hdrs_len += VLAN_HLEN;
/* Check if there was a TCP timestamp, if there is it's will
* always be 12 bytes length: nop nop kind length echo val.
@@ -412,7 +416,7 @@ static int bnx2x_fill_frag_skb(struct bnx2x *bp, struct bnx2x_fastpath *fp,
frag_size = le16_to_cpu(cqe->pkt_len) - len_on_bd;
pages = SGE_PAGE_ALIGN(frag_size) >> SGE_PAGE_SHIFT;
- /* This is needed in order to enable forwarding support */
+ /* Doing LRO, let TCP know the receive MSS */
if (frag_size)
skb_shinfo(skb)->gso_size = bnx2x_set_lro_mss(bp,
tpa_info->parsing_flags, len_on_bd);
@@ -514,7 +518,8 @@ static void bnx2x_tpa_stop(struct bnx2x *bp, struct bnx2x_fastpath *fp,
skb->ip_summed = CHECKSUM_UNNECESSARY;
if (!bnx2x_fill_frag_skb(bp, fp, queue, skb, cqe, cqe_idx)) {
- if (tpa_info->parsing_flags & PARSING_FLAGS_VLAN)
+ if ((tpa_info->parsing_flags & PARSING_FLAGS_VLAN) &&
+ (bp->flags & RX_VLAN_STRIP_FLAG))
__vlan_hwaccel_put_tag(skb, tpa_info->vlan_tag);
napi_gro_receive(&fp->napi, skb);
} else {
@@ -757,8 +762,8 @@ reuse_rx:
skb_record_rx_queue(skb, fp->index);
- if (le16_to_cpu(cqe_fp->pars_flags.flags) &
- PARSING_FLAGS_VLAN)
+ if ((le16_to_cpu(cqe_fp->pars_flags.flags) &
+ PARSING_FLAGS_VLAN) && (bp->flags & RX_VLAN_STRIP_FLAG))
__vlan_hwaccel_put_tag(skb,
le16_to_cpu(cqe_fp->vlan_tag));
napi_gro_receive(&fp->napi, skb);
@@ -3431,6 +3436,11 @@ int bnx2x_set_features(struct net_device *dev, u32 features)
else
flags &= ~TPA_ENABLE_FLAG;
+ if (features & NETIF_F_HW_VLAN_RX)
+ flags |= RX_VLAN_STRIP_FLAG;
+ else
+ flags &= ~RX_VLAN_STRIP_FLAG;
+
if (features & NETIF_F_LOOPBACK) {
if (bp->link_params.loopback_mode != LOOPBACK_BMAC) {
bp->link_params.loopback_mode = LOOPBACK_BMAC;
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 85dd294..e444e7d 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -2722,9 +2722,8 @@ static inline unsigned long bnx2x_get_q_flags(struct bnx2x *bp,
__set_bit(BNX2X_Q_FLG_MCAST, &flags);
}
- /* Always set HW VLAN stripping */
- __set_bit(BNX2X_Q_FLG_VLAN, &flags);
-
+ if (bp->flags & RX_VLAN_STRIP_FLAG)
+ __set_bit(BNX2X_Q_FLG_VLAN, &flags);
return flags | bnx2x_get_common_flags(bp, fp, true);
}
@@ -10286,12 +10285,13 @@ static int __devinit bnx2x_init_dev(struct pci_dev *pdev,
dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_LRO |
- NETIF_F_RXCSUM | NETIF_F_RXHASH | NETIF_F_HW_VLAN_TX;
+ NETIF_F_RXCSUM | NETIF_F_RXHASH |
+ NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
dev->vlan_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_HIGHDMA;
- dev->features |= dev->hw_features | NETIF_F_HW_VLAN_RX;
+ dev->features |= dev->hw_features;
if (bp->flags & USING_DAC_FLAG)
dev->features |= NETIF_F_HIGHDMA;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox