* xt_hashlimit.c race?
From: "Oleg A. Arkhangelsky" @ 2012-09-18 13:22 UTC (permalink / raw)
To: netdev
Hello,
Looking at the net/netfilter/xt_hashlimit.c revealed one question. As far as
I can understand hashlimit_mt() code under rcu_read_lock_bh() can be
executed simultaneously by more than one CPU. So what if we have two
packets with the same new dst value that processed in parallel by different
CPUs? In both cases dh is NULL and both CPUs tries to create new
entry in hash table. This is not what we want and can lead to undefined
behavior in the future.
Or maybe I'm wrong? Could anyone tell me is this situation possible?
Thank you!
--
wbr, Oleg.
^ permalink raw reply
* Re: [PATCH 1/4] ipv6: add a new namespace for nf_conntrack_reasm
From: Cong Wang @ 2012-09-18 10:44 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, Herbert Xu, Michal Kubeček,
David Miller, Patrick McHardy
In-Reply-To: <20120918073756.GA18206@1984>
On Tue, 2012-09-18 at 09:37 +0200, Pablo Neira Ayuso wrote:
> > +#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV6)
> > + struct netns_nf_ct nf_ct;
> > +#endif
>
> There's above one "struct netns_ct" that already encapsulates
> netfilter conntrack netns parameters.
>
> However, I'd prefer if, while at it, you define some struct
> netns_nf_frag instead.
>
> In net/ipv6/netfilter/Makefile, it says:
>
> # defrag
> nf_defrag_ipv6-y := nf_defrag_ipv6_hooks.o nf_conntrack_reasm.o
>
> Note that nf defragmentation is not glued to conntrack anymore. So I'd
> go for one netns_nf_frag for this in include/net/net_namespace.h
>
Sure, I will rename that struct to 'struct netns_nf_frag'.
Thanks for review!
^ permalink raw reply
* Re: HTB vs CoDel performance
From: Eric Dumazet @ 2012-09-18 10:15 UTC (permalink / raw)
To: Lin Ming; +Cc: networking
In-Reply-To: <CAF1ivSYweQgxbCd_ejHmDi5w7puRkE7MbpV_hczhXXDca5DJ7A@mail.gmail.com>
On Tue, 2012-09-18 at 17:56 +0800, Lin Ming wrote:
> I need traffic priority/traffic shaping/rate control ... actually all
> QoS features on the router.
> And if I just set the rate to gigabit(no other settings), for example,
>
> # tc qdisc add dev eth10 root handle 20: htb default 1
> # tc class add dev eth10 parent 20 classid 20:1 htb prio 2 rate
> 1024Mbit ceil 1024Mbit burst 1281408b cburst 1281408b
>
> it should gain similar performance as pfifo_fast.
>
> codel has no rate control. So seems I have to find way to optimize htb?
Are you really cpu limited ? You might hit some clocks artifacts.
rate limiting to 1Gbps probably need high resolution timers.
HTB is not the only way to rate limit.
^ permalink raw reply
* Re: HTB vs CoDel performance
From: Lin Ming @ 2012-09-18 9:56 UTC (permalink / raw)
To: Eric Dumazet; +Cc: networking
In-Reply-To: <1347961511.26523.216.camel@edumazet-glaptop>
On Tue, Sep 18, 2012 at 5:45 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2012-09-18 at 17:28 +0800, Lin Ming wrote:
>> Hi,
>>
>> I'm testing htb performance on a gigabit router running 2.6.32 kernel.
>> Packet path: PC1 ---> Router LAN port ---> Router WAN port ---> PC2
>>
>> pfifo_fast: 920Mbps
>> htb: 750Mbps, ~20% drops compared to pfifo_fast
>>
>> htb tc commands as below,
>> # tc qdisc add dev eth10 root handle 20: htb default 1
>> # tc class add dev eth10 parent 20 classid 20:1 htb prio 2 rate
>> 1024Mbit ceil 1024Mbit burst 1281408b cburst 1281408b
>>
>> The performance drop seems caused by the complex htb enqueue/dequeue algorithm.
>>
>> I had a quick look at CoDel code, seems it does not have so complex
>> data structure as HTB.
>> I'm going to backport CoDel. Is this a good choice?
>> Can I gain similar performance as pfifo_fast?
>
> codel is quite different than HTB : It has no rate control, so its very
> fast. (But it has no prio differentiation as pfifo_fast with its 3
> bands)
>
> So what are your exact needs ?
I need traffic priority/traffic shaping/rate control ... actually all
QoS features on the router.
And if I just set the rate to gigabit(no other settings), for example,
# tc qdisc add dev eth10 root handle 20: htb default 1
# tc class add dev eth10 parent 20 classid 20:1 htb prio 2 rate
1024Mbit ceil 1024Mbit burst 1281408b cburst 1281408b
it should gain similar performance as pfifo_fast.
codel has no rate control. So seems I have to find way to optimize htb?
^ permalink raw reply
* Re: HTB vs CoDel performance
From: Eric Dumazet @ 2012-09-18 9:45 UTC (permalink / raw)
To: Lin Ming; +Cc: networking
In-Reply-To: <CAF1ivSZPpBkKk6mfhEu01bz6yP4KgJU8kK6cmeZ9e+kwH=EtiQ@mail.gmail.com>
On Tue, 2012-09-18 at 17:28 +0800, Lin Ming wrote:
> Hi,
>
> I'm testing htb performance on a gigabit router running 2.6.32 kernel.
> Packet path: PC1 ---> Router LAN port ---> Router WAN port ---> PC2
>
> pfifo_fast: 920Mbps
> htb: 750Mbps, ~20% drops compared to pfifo_fast
>
> htb tc commands as below,
> # tc qdisc add dev eth10 root handle 20: htb default 1
> # tc class add dev eth10 parent 20 classid 20:1 htb prio 2 rate
> 1024Mbit ceil 1024Mbit burst 1281408b cburst 1281408b
>
> The performance drop seems caused by the complex htb enqueue/dequeue algorithm.
>
> I had a quick look at CoDel code, seems it does not have so complex
> data structure as HTB.
> I'm going to backport CoDel. Is this a good choice?
> Can I gain similar performance as pfifo_fast?
codel is quite different than HTB : It has no rate control, so its very
fast. (But it has no prio differentiation as pfifo_fast with its 3
bands)
So what are your exact needs ?
^ permalink raw reply
* HTB vs CoDel performance
From: Lin Ming @ 2012-09-18 9:28 UTC (permalink / raw)
To: Eric Dumazet; +Cc: networking
Hi,
I'm testing htb performance on a gigabit router running 2.6.32 kernel.
Packet path: PC1 ---> Router LAN port ---> Router WAN port ---> PC2
pfifo_fast: 920Mbps
htb: 750Mbps, ~20% drops compared to pfifo_fast
htb tc commands as below,
# tc qdisc add dev eth10 root handle 20: htb default 1
# tc class add dev eth10 parent 20 classid 20:1 htb prio 2 rate
1024Mbit ceil 1024Mbit burst 1281408b cburst 1281408b
The performance drop seems caused by the complex htb enqueue/dequeue algorithm.
I had a quick look at CoDel code, seems it does not have so complex
data structure as HTB.
I'm going to backport CoDel. Is this a good choice?
Can I gain similar performance as pfifo_fast?
Thanks,
Lin Ming
^ permalink raw reply
* Re: [PATCH] asix: Support DLink DUB-E100 H/W Ver C1
From: Søren Holm @ 2012-09-18 8:40 UTC (permalink / raw)
To: Christian Riesch; +Cc: netdev, stable
In-Reply-To: <CABkLObq3jQG_KMRrNpYGsseJrCYQ08cJfQFD5fpTmYDyDMGROA@mail.gmail.com>
Tirsdag den 18. september 2012 10:21:17 skrev Christian Riesch:
> IIRC this is not how it works. Your patch must go into the current
> mainline kernel first (via net or net-next) before, then it will be
> backported to the stable series.Therefore you must always send patches
> that apply to net, or net-next...
> Christian
I'm aware of that now, thanks :)
--
Søren Holm
^ permalink raw reply
* [PATCH] xfrm: fix a rcu_read_lock() imbalance in make_blackhole
From: roy.qing.li @ 2012-09-18 8:40 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
if xfrm_policy_get_afinfo returns 0, it has already called rcu_read_unlock,
xfrm_policy_put_afinfo should not be called again.
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/xfrm/xfrm_policy.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 741a32a..878835b 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1780,7 +1780,7 @@ static struct dst_entry *make_blackhole(struct net *net, u16 family,
if (!afinfo) {
dst_release(dst_orig);
- ret = ERR_PTR(-EINVAL);
+ return ERR_PTR(-EINVAL);
} else {
ret = afinfo->blackhole_route(net, dst_orig);
}
--
1.7.4.1
^ permalink raw reply related
* Re: [V4 PATCH 0/8] csiostor: Chelsio FCoE offload driver submission
From: James Bottomley @ 2012-09-18 8:36 UTC (permalink / raw)
To: Naresh Kumar Inna
Cc: linux-scsi@vger.kernel.org, Dimitrios Michailidis, Casey Leedom,
netdev@vger.kernel.org, Chethan Seshadri
In-Reply-To: <5057F791.8020702@chelsio.com>
On Tue, 2012-09-18 at 09:54 +0530, Naresh Kumar Inna wrote:
> Hi James,
>
> Could you please consider merging version V4 of the driver patches, if
> you think they are in good shape now?
Well, definitely not yet; you seem to have missed the memo on readq:
CC [M] drivers/scsi/cxgbi/cxgb4i/cxgb4i.o
drivers/scsi/csiostor/csio_hw.c: In function ‘csio_hw_mc_read’:
drivers/scsi/csiostor/csio_hw.c:194:3: error: implicit declaration of
function ‘readq’ [-Werror=implicit-function-declaration]
It's only defined on platforms which can support an atomic 64 bit
operation (which is mostly not any 32 bit platforms) ... so this could
do with compile testing on those.
To see how to handle readq/writeq in the 32 bit case, see the uses in
fnic or qla2xxx
You also have a couple of unnecessary version.h includes.
Since you're a new driver, could you not do a correctly unlocked
queuecommand routine? You'll find the way you've currently got it coded
(holding the host lock for the entire queuecommand routine) is very
performance detrimental.
You have a lot of locking statements which aren't easy to audit by hand
because there are multiple unlocks. Things like this:
csio_scan_finished(struct Scsi_Host *shost, unsigned long time)
{
struct csio_lnode *ln = shost_priv(shost);
int rv = 0;
spin_lock_irq(shost->host_lock);
if (!ln->hwp || csio_list_deleted(&ln->sm.sm_list)) {
spin_unlock_irq(shost->host_lock);
return 1;
}
rv = csio_scan_done(ln, jiffies, time, csio_max_scan_tmo * HZ,
csio_delta_scan_tmo * HZ);
spin_unlock_irq(shost->host_lock);
return rv;
}
Are better coded as
csio_scan_finished(struct Scsi_Host *shost, unsigned long time)
{
struct csio_lnode *ln = shost_priv(shost);
int rv = 1;
spin_lock_irq(shost->host_lock);
if (!ln->hwp || csio_list_deleted(&ln->sm.sm_list))
goto out;
rv = csio_scan_done(ln, jiffies, time, csio_max_scan_tmo * HZ,
csio_delta_scan_tmo * HZ);
out:
spin_unlock_irq(shost->host_lock);
return rv;
}
It's shorter and the unlock clearly matches the lock. You could even
invert the if logic and just make the csio_scan_done() conditional on it
avoiding the goto.
I'd also really like the people who understand FC to take a look over
this as well.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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
* Re: Regarding group_forward_mask in bridge in 3.4 kernel
From: Ajith Adapa @ 2012-09-18 8:30 UTC (permalink / raw)
To: John Fastabend; +Cc: netdev, Stephen Hemminger
In-Reply-To: <505740C1.9080706@intel.com>
Thanks for the reply John.
Then in the case of Link Aggregation whose mac-address is
01-80-c2-00-00-02 I should do
echo 4 >> /sys/class/net/...
But value 4 is not getting accepted. why ?
Regards,
Ajith
--------------------------------------------
codingfreak.in
On Mon, Sep 17, 2012 at 8:54 PM, John Fastabend
<john.r.fastabend@intel.com> wrote:
> wrong value see the logic you quoted use 1 << 8
>
> echo 256 > /sys/class/net/...
>
> Your example fwds non-TPMR addresses 01-80-c2-00-00-03.
^ permalink raw reply
* Re: [PATCH v2] tcp: fix regression in urgent data handling
From: Stephan Springl @ 2012-09-18 8:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Alexander Duyck
In-Reply-To: <1347954850.26523.211.camel@edumazet-glaptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1980 bytes --]
Works here on top of 3.5.4, so
Tested-by: Stephan Springl <springl-k@bfw-online.de>
On Tue, 18 Sep 2012, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Stephan Springl found that commit 1402d366019fed "tcp: introduce
> tcp_try_coalesce" introduced a regression for rlogin
>
> It turns out problem comes from TCP urgent data handling and
> a change in behavior in input path.
>
> rlogin sends two one-byte packets with URG ptr set, and when next data
> frame is coalesced, we lack sk_data_ready() calls to wakeup consumer.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Stephan Springl <springl-k@bfw-online.de>
> Cc: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
> v2: Changed Stephan Springl email address in changelog/CC
>
> net/ipv4/tcp_input.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 6e38c6c..d377f48 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -4661,7 +4661,7 @@ queue_and_out:
>
> if (eaten > 0)
> kfree_skb_partial(skb, fragstolen);
> - else if (!sock_flag(sk, SOCK_DEAD))
> + if (!sock_flag(sk, SOCK_DEAD))
> sk->sk_data_ready(sk, 0);
> return;
> }
> @@ -5556,8 +5556,7 @@ no_ack:
> #endif
> if (eaten)
> kfree_skb_partial(skb, fragstolen);
> - else
> - sk->sk_data_ready(sk, 0);
> + sk->sk_data_ready(sk, 0);
> return 0;
> }
> }
>
>
>
Freundliche Grüße
BFW Werner Völk GmbH
ppa. Stephan Springl
--
Stephan Springl BFW Werner Völk GmbH
Tel.: +49 89 82917-452 Energiemesstechnik & Service
Fax: +49 89 82917-599 Pasinger Str. 20 - 22
Mail: springl@bfw-online.de D-82166 Gräfelfing
Web: http://www.novamess.de Geschäftsführer: Georg F. Völk
HRB 44779 Amtsgericht München
USt.-ID: DE129301566
^ permalink raw reply
* Re: [PATCH] asix: Support DLink DUB-E100 H/W Ver C1
From: Christian Riesch @ 2012-09-18 8:21 UTC (permalink / raw)
To: Søren Holm; +Cc: netdev, stable
In-Reply-To: <1377162.WNQkapDPaD@koontz>
On Tue, Sep 18, 2012 at 9:49 AM, Søren Holm <sgh@sgh.dk> wrote:
> Tirsdag den 18. september 2012 07:41:11 skrev Christian Riesch:
>>
>> This will not apply to recent kernels, drivers/net/usb/asix.c has been
>> split into several files, please make these changes in
>> drivers/net/usb/asix_devices.c.
>
> I'll do that. The previous patch applies to the 3.5.x stable series if it get
> accepted there.
IIRC this is not how it works. Your patch must go into the current
mainline kernel first (via net or net-next) before, then it will be
backported to the stable series.Therefore you must always send patches
that apply to net, or net-next...
Christian
^ permalink raw reply
* Re: [PATCH 24/24] net: seeq: use __iomem pointers for MMIO
From: Arnd Bergmann @ 2012-09-18 8:14 UTC (permalink / raw)
To: David Miller
Cc: linux, linux-arm-kernel, linux-kernel, will.deacon, nico, netdev
In-Reply-To: <20120915.000059.636218745264773259.davem@davemloft.net>
On Saturday 15 September 2012, David Miller wrote:
> From: Russell King - ARM Linux <linux@arm.linux.org.uk>
> Date: Sat, 15 Sep 2012 00:56:07 +0100
>
> > On Fri, Sep 14, 2012 at 11:34:52PM +0200, Arnd Bergmann wrote:
> >> ARM is moving to stricter checks on readl/write functions,
> >> so we need to use the correct types everywhere.
> >
> > Same comment as for eesox. const void __iomem * is not a problem on
> > x86, so it should not be a problem on ARM.
>
> Agreed.
As discussed in the thread for the same patch on the scsi eesox driver,
x86 allows reads on const __iomem pointers, but not writes, and the patch
to asm/io.h that Russell has queued up changes ARM to do the same.
My patch on seeq/ether3.c is still needed to avoid this warning in
linux-next:
drivers/net/ethernet/seeq/ether3.c: In function 'ether3_outb':
drivers/net/ethernet/seeq/ether3.c:104:2: error: passing argument 2 of '__raw_writeb' discards 'const' qualifier from pointer target type
arch/arm/include/asm/io.h:81:91: note: expected 'volatile void *' but argument is of type 'const void *'
Arnd
^ permalink raw reply
* Re: [PATCH] asix: Support DLink DUB-E100 H/W Ver C1
From: Søren Holm @ 2012-09-18 7:49 UTC (permalink / raw)
To: Christian Riesch; +Cc: netdev, stable
In-Reply-To: <CABkLObpU3P84AHTBG1hkrHt_HdaPzdTiRU1ACnJv=Qhb+wYPbQ@mail.gmail.com>
Tirsdag den 18. september 2012 07:41:11 skrev Christian Riesch:
>
> This will not apply to recent kernels, drivers/net/usb/asix.c has been
> split into several files, please make these changes in
> drivers/net/usb/asix_devices.c.
I'll do that. The previous patch applies to the 3.5.x stable series if it get
accepted there.
Thanks for the feedback.
--
Søren Holm
^ permalink raw reply
* [PATCH] asix: Support DLink DUB-E100 H/W Ver C1
From: Søren Holm @ 2012-09-18 7:50 UTC (permalink / raw)
To: netdev; +Cc: Søren Holm, stable
In-Reply-To: <CABkLObpU3P84AHTBG1hkrHt_HdaPzdTiRU1ACnJv=Qhb+wYPbQ@mail.gmail.com>
Signed-off-by: Søren Holm <sgh@sgh.dk>
Cc: stable@vger.kernel.org
---
drivers/net/usb/asix_devices.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 4fd48df..32e31c5 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -962,6 +962,10 @@ static const struct usb_device_id products [] = {
USB_DEVICE (0x2001, 0x3c05),
.driver_info = (unsigned long) &ax88772_info,
}, {
+ // DLink DUB-E100 H/W Ver C1
+ USB_DEVICE (0x2001, 0x1a02),
+ .driver_info = (unsigned long) &ax88772_info,
+}, {
// Linksys USB1000
USB_DEVICE (0x1737, 0x0039),
.driver_info = (unsigned long) &ax88178_info,
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2] tcp: fix regression in urgent data handling
From: Eric Dumazet @ 2012-09-18 7:54 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Stephan Springl, Alexander Duyck
In-Reply-To: <1347922299.26523.198.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
Stephan Springl found that commit 1402d366019fed "tcp: introduce
tcp_try_coalesce" introduced a regression for rlogin
It turns out problem comes from TCP urgent data handling and
a change in behavior in input path.
rlogin sends two one-byte packets with URG ptr set, and when next data
frame is coalesced, we lack sk_data_ready() calls to wakeup consumer.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Stephan Springl <springl-k@bfw-online.de>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>
---
v2: Changed Stephan Springl email address in changelog/CC
net/ipv4/tcp_input.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 6e38c6c..d377f48 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4661,7 +4661,7 @@ queue_and_out:
if (eaten > 0)
kfree_skb_partial(skb, fragstolen);
- else if (!sock_flag(sk, SOCK_DEAD))
+ if (!sock_flag(sk, SOCK_DEAD))
sk->sk_data_ready(sk, 0);
return;
}
@@ -5556,8 +5556,7 @@ no_ack:
#endif
if (eaten)
kfree_skb_partial(skb, fragstolen);
- else
- sk->sk_data_ready(sk, 0);
+ sk->sk_data_ready(sk, 0);
return 0;
}
}
^ permalink raw reply related
* Re: [PATCH 1/4] ipv6: add a new namespace for nf_conntrack_reasm
From: Pablo Neira Ayuso @ 2012-09-18 7:37 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, netfilter-devel, Herbert Xu, Michal Kubeček,
David Miller, Patrick McHardy
In-Reply-To: <1347942582-23962-2-git-send-email-amwang@redhat.com>
On Tue, Sep 18, 2012 at 12:29:39PM +0800, Cong Wang wrote:
> As pointed by Michal, it is necessary to add a new
> namespace for nf_conntrack_reasm code, this prepares
> for the second patch.
This looks good to me, but there are some comestical changes I have to
request.
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Michal Kubeček <mkubecek@suse.cz>
> Cc: David Miller <davem@davemloft.net>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Pablo Neira Ayuso <pablo@netfilter.org>
> Cc: netfilter-devel@vger.kernel.org
> Signed-off-by: Cong Wang <amwang@redhat.com>
> ---
> include/net/net_namespace.h | 3 +
> include/net/netns/conntrack.h | 6 ++
> net/ipv6/netfilter/nf_conntrack_reasm.c | 135 +++++++++++++++++++++----------
> 3 files changed, 102 insertions(+), 42 deletions(-)
>
> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index 5ae57f1..5c467bb 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -93,6 +93,9 @@ struct net {
> #if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
> struct netns_ct ct;
> #endif
> +#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV6)
> + struct netns_nf_ct nf_ct;
> +#endif
There's above one "struct netns_ct" that already encapsulates
netfilter conntrack netns parameters.
However, I'd prefer if, while at it, you define some struct
netns_nf_frag instead.
In net/ipv6/netfilter/Makefile, it says:
# defrag
nf_defrag_ipv6-y := nf_defrag_ipv6_hooks.o nf_conntrack_reasm.o
Note that nf defragmentation is not glued to conntrack anymore. So I'd
go for one netns_nf_frag for this in include/net/net_namespace.h
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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
* re: mlx4_en: fix endianness with blue frame support
From: Dan Carpenter @ 2012-09-18 7:34 UTC (permalink / raw)
To: cascardo; +Cc: netdev
Hello Thadeu Lima de Souza Cascardo,
The patch c5d6136e10d6: "mlx4_en: fix endianness with blue frame
support" from Oct 10, 2011, leads to the following warning:
drivers/net/ethernet/mellanox/mlx4/en_tx.c:720 mlx4_en_xmit()
warn: potential memory corrupting cast. 4 vs 2 bytes
That patch introduced a call to cpu_to_be32() and added some endian
notation.
*(__be32 *) (&tx_desc->ctrl.vlan_tag) |= cpu_to_be32(ring->doorbell_qpn);
But it doesn't make sense because the data type is declared as u16 in
the header and we would be corrupting the next elements in the struct
which are ins_vlan and fence_size.
struct mlx4_wqe_ctrl_seg {
__be32 owner_opcode;
__be16 vlan_tag;
u8 ins_vlan;
u8 fence_size;
I guess the reason we get away with it is that the ->doorbell_qpn is
normally less that 65k. But doorbell_qpn is a u32 type so I think there
is a risk here.
regards,
dan carpenter
^ permalink raw reply
* [Patch net-next] netpoll: call ->ndo_select_queue() in tx path
From: Cong Wang @ 2012-09-18 6:16 UTC (permalink / raw)
To: netdev; +Cc: Sylvain Munaut, David S. Miller, Eric Dumazet, Cong Wang
In netpoll tx path, we miss the chance of calling ->ndo_select_queue(),
thus could cause problems when bonding is involved.
This patch makes dev_pick_tx() extern (and rename it to netdev_pick_tx())
to let netpoll call it in netpoll_send_skb_on_dev().
Reported-by: Sylvain Munaut <s.munaut@whatever-company.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Cong Wang <amwang@redhat.com>
Tested-by: Sylvain Munaut <s.munaut@whatever-company.com>
---
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index ae3153c0..72661f6 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1403,6 +1403,9 @@ static inline void netdev_for_each_tx_queue(struct net_device *dev,
f(dev, &dev->_tx[i], arg);
}
+extern struct netdev_queue *netdev_pick_tx(struct net_device *dev,
+ struct sk_buff *skb);
+
/*
* Net namespace inlines
*/
diff --git a/net/core/dev.c b/net/core/dev.c
index dcc673d..b13317a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2381,8 +2381,8 @@ static inline int get_xps_queue(struct net_device *dev, struct sk_buff *skb)
#endif
}
-static struct netdev_queue *dev_pick_tx(struct net_device *dev,
- struct sk_buff *skb)
+struct netdev_queue *netdev_pick_tx(struct net_device *dev,
+ struct sk_buff *skb)
{
int queue_index;
const struct net_device_ops *ops = dev->netdev_ops;
@@ -2556,7 +2556,7 @@ int dev_queue_xmit(struct sk_buff *skb)
skb_update_prio(skb);
- txq = dev_pick_tx(dev, skb);
+ txq = netdev_pick_tx(dev, skb);
q = rcu_dereference_bh(txq->qdisc);
#ifdef CONFIG_NET_CLS_ACT
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index dd67818..77a0388 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -328,7 +328,7 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct sk_buff *skb,
if (skb_queue_len(&npinfo->txq) == 0 && !netpoll_owner_active(dev)) {
struct netdev_queue *txq;
- txq = netdev_get_tx_queue(dev, skb_get_queue_mapping(skb));
+ txq = netdev_pick_tx(dev, skb);
/* try until next clock tick */
for (tries = jiffies_to_usecs(1)/USEC_PER_POLL;
^ permalink raw reply related
* Re: [patch net] sky2: fix rx filter setup on link up
From: Jiri Pirko @ 2012-09-18 6:15 UTC (permalink / raw)
To: Mirko Lindner
Cc: Stephen Hemminger, netdev@vger.kernel.org, davem@davemloft.net,
linux-kernel@vger.kernel.org
In-Reply-To: <175CCF5F49938B4D99B2E3EF7F558EBE1B63898F0B@SC-VEXCH4.marvell.com>
Tue, Sep 18, 2012 at 02:38:52AM CEST, mlindner@marvell.com wrote:
>>Mon, Sep 17, 2012 at 06:12:14PM CEST, shemminger@vyatta.com wrote:
>>>On Mon, 17 Sep 2012 17:10:17 +0200
>>>Jiri Pirko <jiri@resnulli.us> wrote:
>>>
>>>> In my case I have following problem. sky2_set_multicast() sets registers
>>>> GM_MC_ADDR_H[1-4] correctly to:
>>>> 0000 0800 0001 0410
>>>> However, when adapter gets link and sky2_link_up() is called, the values
>>>> are for some reason different:
>>>> 0000 0800 0016 0410
>>>
>>>Rather than papering over the problem, it would be better to
>>>trace back what is setting those registers and fix that code.
>
>>Yes, I did that. No code at sky2.[ch] is writing to this registers other
>>than sky2_set_multicast() and sky2_gmac_reset() (I hooked on sky2_write*()).
>>So I strongly believe this is a HW issue (maybe only issue of my revision
>>"Yukon-2 EC chip revision 2")
>
>I would like to check the registers as soon as I'm back in my office next week and report my findings.
Okay, I'll wait for you. If you need more info from my side, please do
not hesitate to ask. Thanks!
>Could you also please check the hint from Stephen?
^ permalink raw reply
* Re: [patch net] sky2: fix rx filter setup on link up
From: Jiri Pirko @ 2012-09-18 6:13 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem, mlindner, linux-kernel
In-Reply-To: <20120917141507.7528b3ee@nehalam.linuxnetplumber.net>
Mon, Sep 17, 2012 at 11:15:07PM CEST, shemminger@vyatta.com wrote:
>On Mon, 17 Sep 2012 22:47:24 +0200
>Jiri Pirko <jiri@resnulli.us> wrote:
>
>> Mon, Sep 17, 2012 at 06:12:14PM CEST, shemminger@vyatta.com wrote:
>> >On Mon, 17 Sep 2012 17:10:17 +0200
>> >Jiri Pirko <jiri@resnulli.us> wrote:
>> >
>> >> In my case I have following problem. sky2_set_multicast() sets registers
>> >> GM_MC_ADDR_H[1-4] correctly to:
>> >> 0000 0800 0001 0410
>> >> However, when adapter gets link and sky2_link_up() is called, the values
>> >> are for some reason different:
>> >> 0000 0800 0016 0410
>> >
>> >Rather than papering over the problem, it would be better to
>> >trace back what is setting those registers and fix that code.
>>
>> Yes, I did that. No code at sky2.[ch] is writing to this registers other
>> than sky2_set_multicast() and sky2_gmac_reset() (I hooked on sky2_write*()).
>> So I strongly believe this is a HW issue (maybe only issue of my revision
>> "Yukon-2 EC chip revision 2")
>>
>> >
>> >> This in my case prevents iface to be able to receive packets with dst mac
>> >> 01:80:C2:00:00:02 (LACPDU dst mac), which I set up previously by
>> >> SIOCADDMULTI.
>> >>
>> >> So remember computed rx_filter data and write it to GM_MC_ADDR_H[1-4] on
>> >> link_up.
>> >>
>> >
>> >Please do some more root cause analysis. Just save/restoring the
>> >registers is just a temporary workaround.
>
>Are you sure it isn't IPv6 or something else setting additional mulitcast
>addresses. You may need to instrument the set_multicast call.
I'm very sure that no code in sky2 is writing to GM_MC_ADDR_H[1-4] the
change I see in sky2_link_up(). When sky2_set_multicast() is called
again for any reason, the issue goes away and lacpdus are coming in.
I also experimentally used sky2_set_multicast() called from
sky2_link_up() and it helped as well.
^ permalink raw reply
* Re: [net] e1000: Small packets may get corrupted during padding by HW
From: Alexander Duyck @ 2012-09-18 5:55 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, alexander.h.duyck, tushar.n.dave, john.r.fastabend,
mirqus, jeffrey.t.kirsher, netdev, gospo, sassmann
In-Reply-To: <1347947120.26523.207.camel@edumazet-glaptop>
On 9/17/2012 10:45 PM, Eric Dumazet wrote:
> On Mon, 2012-09-17 at 20:27 -0700, Alexander Duyck wrote:
>
>> It also just occurred to me that there might be some benefit in cache
>> aligning the max header size. It seems like doing something like that
>> should reduce the overall memory footprint and would probably improve
>> performance.
> Given that most ACK packets are 66 bytes (14 ethernet + 20 IP + 32 TCP),
> I am not sure we need to make any tweak on alignment ?
I'm honestly not sure myself. I will probably spend a few hours
tomorrow tweaking a few things to test and see if there is any gain to
be had there. The only reason why it occurred to me is that it really
isn't too far off from what we did back on the Rx side, except for there
we were aligning at the start of the buffer and working our way up.
Thanks,
Alex
^ permalink raw reply
* [Patch net-next] l2tp: fix compile error when CONFIG_IPV6=m and CONFIG_L2TP=y
From: Cong Wang @ 2012-09-18 5:54 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Cong Wang
When CONFIG_IPV6=m and CONFIG_L2TP=y, I got the following compile error:
LD init/built-in.o
net/built-in.o: In function `l2tp_xmit_core':
l2tp_core.c:(.text+0x147781): undefined reference to `inet6_csk_xmit'
net/built-in.o: In function `l2tp_tunnel_create':
(.text+0x149067): undefined reference to `udpv6_encap_enable'
net/built-in.o: In function `l2tp_ip6_recvmsg':
l2tp_ip6.c:(.text+0x14e991): undefined reference to `ipv6_recv_error'
net/built-in.o: In function `l2tp_ip6_sendmsg':
l2tp_ip6.c:(.text+0x14ec64): undefined reference to `fl6_sock_lookup'
l2tp_ip6.c:(.text+0x14ed6b): undefined reference to `datagram_send_ctl'
l2tp_ip6.c:(.text+0x14eda0): undefined reference to `fl6_sock_lookup'
l2tp_ip6.c:(.text+0x14ede5): undefined reference to `fl6_merge_options'
l2tp_ip6.c:(.text+0x14edf4): undefined reference to `ipv6_fixup_options'
l2tp_ip6.c:(.text+0x14ee5d): undefined reference to `fl6_update_dst'
l2tp_ip6.c:(.text+0x14eea3): undefined reference to `ip6_dst_lookup_flow'
l2tp_ip6.c:(.text+0x14eee7): undefined reference to `ip6_dst_hoplimit'
l2tp_ip6.c:(.text+0x14ef8b): undefined reference to `ip6_append_data'
l2tp_ip6.c:(.text+0x14ef9d): undefined reference to `ip6_flush_pending_frames'
l2tp_ip6.c:(.text+0x14efe2): undefined reference to `ip6_push_pending_frames'
net/built-in.o: In function `l2tp_ip6_destroy_sock':
l2tp_ip6.c:(.text+0x14f090): undefined reference to `ip6_flush_pending_frames'
l2tp_ip6.c:(.text+0x14f0a0): undefined reference to `inet6_destroy_sock'
net/built-in.o: In function `l2tp_ip6_connect':
l2tp_ip6.c:(.text+0x14f14d): undefined reference to `ip6_datagram_connect'
net/built-in.o: In function `l2tp_ip6_bind':
l2tp_ip6.c:(.text+0x14f4fe): undefined reference to `ipv6_chk_addr'
net/built-in.o: In function `l2tp_ip6_init':
l2tp_ip6.c:(.init.text+0x73fa): undefined reference to `inet6_add_protocol'
l2tp_ip6.c:(.init.text+0x740c): undefined reference to `inet6_register_protosw'
net/built-in.o: In function `l2tp_ip6_exit':
l2tp_ip6.c:(.exit.text+0x1954): undefined reference to `inet6_unregister_protosw'
l2tp_ip6.c:(.exit.text+0x1965): undefined reference to `inet6_del_protocol'
net/built-in.o:(.rodata+0xf2d0): undefined reference to `inet6_release'
net/built-in.o:(.rodata+0xf2d8): undefined reference to `inet6_bind'
net/built-in.o:(.rodata+0xf308): undefined reference to `inet6_ioctl'
net/built-in.o:(.data+0x1af40): undefined reference to `ipv6_setsockopt'
net/built-in.o:(.data+0x1af48): undefined reference to `ipv6_getsockopt'
net/built-in.o:(.data+0x1af50): undefined reference to `compat_ipv6_setsockopt'
net/built-in.o:(.data+0x1af58): undefined reference to `compat_ipv6_getsockopt'
make: *** [vmlinux] Error 1
This is due to l2tp uses symbols from IPV6, so when l2tp is
builtin, IPV6 has to be builtin too.
Cc: David Miller <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
diff --git a/net/l2tp/Kconfig b/net/l2tp/Kconfig
index 4b1e717..3f3c514 100644
--- a/net/l2tp/Kconfig
+++ b/net/l2tp/Kconfig
@@ -4,6 +4,7 @@
menuconfig L2TP
tristate "Layer Two Tunneling Protocol (L2TP)"
+ select IPV6 if L2TP=y
depends on INET
---help---
Layer Two Tunneling Protocol
^ permalink raw reply related
* Re: [net] e1000: Small packets may get corrupted during padding by HW
From: Eric Dumazet @ 2012-09-18 5:45 UTC (permalink / raw)
To: Alexander Duyck
Cc: David Miller, alexander.h.duyck, tushar.n.dave, john.r.fastabend,
mirqus, jeffrey.t.kirsher, netdev, gospo, sassmann
In-Reply-To: <5057EA05.8020005@gmail.com>
On Mon, 2012-09-17 at 20:27 -0700, Alexander Duyck wrote:
> It also just occurred to me that there might be some benefit in cache
> aligning the max header size. It seems like doing something like that
> should reduce the overall memory footprint and would probably improve
> performance.
Given that most ACK packets are 66 bytes (14 ethernet + 20 IP + 32 TCP),
I am not sure we need to make any tweak on alignment ?
^ permalink raw reply
* Re: [net-next.git 3/8 (V2)] stmmac: add the initial tx coalesce schema
From: Giuseppe CAVALLARO @ 2012-09-18 5:41 UTC (permalink / raw)
To: David Miller, bhutchings; +Cc: netdev
In-Reply-To: <5052DE7E.8070704@st.com>
Hello David, Ben,
On 9/14/2012 9:36 AM, Giuseppe CAVALLARO wrote:
> On 9/13/2012 10:23 PM, David Miller wrote:
>> From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
>> Date: Tue, 11 Sep 2012 08:55:09 +0200
>>
>>> + unsigned long flags;
>>> +
>>> + spin_lock_irqsave(&priv->tx_lock, flags);
>>>
>>> - spin_lock(&priv->tx_lock);
>>> + priv->xstats.tx_clean++;
>>
>> You are changing the locking here for the sake of the new timer.
>>
>> But timers run in software interrupt context, so this change is
>> completely unnecessary since NAPI runs in software interrupt context
>> as well, and neither timers nor NAPI run in hardware interrupts
>> context.
>
> Indeed It can be called by the ISR too in this new implementation.
> I have added the spin_lock_irqsave/restore otherwise, testing with
> CONFIG_PROVE_LOOKING, I get the following warning on ARM SMP.
sorry if I disturb you again, any news on these patches?
Please, let me know.
Regards
Peppe
>
> [ 8.030000]
> [ 8.030000] =================================
> [ 8.030000] [ INFO: inconsistent lock state ]
> [ 8.030000] 3.4.7_stm24_0302-b2000+ #103 Not tainted
> [ 8.030000] ---------------------------------
> [ 8.030000] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> [ 8.030000] swapper/0/1 [HC1[1]:SC0[0]:HE0:SE1] takes:
> [ 8.030000] (&(&priv->tx_lock)->rlock){?.-...}, at: [<802651d8>]
> stmmac_tx+0x1c/0x388
> [ 8.030000] {HARDIRQ-ON-W} state was registered at:
> [ 8.030000] [<800562b4>] __lock_acquire+0x638/0x179c
> [ 8.030000] [<80057884>] lock_acquire+0x60/0x74
> [ 8.030000] [<80428a08>] _raw_spin_lock+0x40/0x50
> [ 8.030000] [<802651d8>] stmmac_tx+0x1c/0x388
> [ 8.030000] [<80026be0>] run_timer_softirq+0x180/0x23c
> [ 8.030000] [<80020ccc>] __do_softirq+0xa0/0x114
> [ 8.030000] [<80021204>] irq_exit+0x58/0x7c
> [ 8.030000] [<8000dc80>] handle_IRQ+0x7c/0xb8
> [ 8.030000] [<80008464>] gic_handle_irq+0x34/0x58
> [ 8.030000] [<80429684>] __irq_svc+0x44/0x78
> [ 8.030000] [<8001c3f4>] vprintk+0x41c/0x480
> [ 8.030000] [<8042097c>] printk+0x18/0x24
> [ 8.030000] [<805aef6c>] prepare_namespace+0x1c/0x1a4
> [ 8.030000] [<805ae980>] kernel_init+0x1c8/0x20c
> [ 8.030000] [<8000deb8>] kernel_thread_exit+0x0/0x8
> [ 8.030000] irq event stamp: 254745
> [ 8.030000] hardirqs last enabled at (254744): [<80429240>]
> _raw_spin_unlock_irqrestore+0x3c/0x6c
> [ 8.030000] hardirqs last disabled at (254745): [<80429674>]
> __irq_svc+0x34/0x78
> [ 8.030000] softirqs last enabled at (254741): [<8035d964>]
> dev_queue_xmit+0x6a4/0x724
> [ 8.030000] softirqs last disabled at (254737): [<8035d2d4>]
> dev_queue_xmit+0x14/0x724
> [ 8.030000]
> [ 8.030000] other info that might help us debug this:
> [ 8.030000] Possible unsafe locking scenario:
> [ 8.030000]
> [ 8.030000] CPU0
> [ 8.030000] ----
> [ 8.030000] lock(&(&priv->tx_lock)->rlock);
> [ 8.030000] <Interrupt>
> [ 8.030000] lock(&(&priv->tx_lock)->rlock);
> [ 8.030000]
> [ 8.030000] *** DEADLOCK ***
>
>> Therefore, disabling hardware interrupts for this lock is unnecessary
>> and will decrease performance.
>> --
>> 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
>>
>
> --
> 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
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