* Re: [PATCH 0/3] net: mac80211: Neaten debugging
From: Johannes Berg @ 2012-05-16 15:30 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <1337181771.4818.0.camel@joe2Laptop>
On Wed, 2012-05-16 at 08:22 -0700, Joe Perches wrote:
> On Wed, 2012-05-16 at 09:59 +0200, Johannes Berg wrote:
> > I wonder if it makes sense to leave these under
> > #ifdef though? Why #ifdef something if it's going to be invisible most
> > of the time anyway?
>
> I don't understand your point.
> #ifdef removal is a good thing.
Yeah, but you left a lot of them under ifdef, and I'm wondering why you
didn't remove them, or if you should, or ...
johannes
^ permalink raw reply
* Re: [PATCH] drop_monitor: convert to modular building
From: Ben Hutchings @ 2012-05-16 15:34 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, David S. Miller
In-Reply-To: <20120516151932.GB30195@hmsreliant.think-freely.org>
On Wed, 2012-05-16 at 11:19 -0400, Neil Horman wrote:
> On Wed, May 16, 2012 at 04:01:45PM +0100, Ben Hutchings wrote:
> > On Wed, 2012-05-16 at 10:27 -0400, Neil Horman wrote:
> > > When I first wrote drop monitor I wrote it to just build monolithically. There
> > > is no reason it can't be built modularly as well, so lets give it that
> > > flexibiity.
[...]
> > > + /*
> > > + * Because of the module_get/put we do in the trace state change path
> > > + * we are guarnateed not to have any current users when we get here
> > > + * all we need to do is make sure that we don't have any running timers
> > > + * or pending schedule calls
> > > + */
> >
> > Surely you need to call set_all_monitor_traces(TRACE_OFF) first...
> >
> Nope, If you'll note the code higher up in the patch, I use try_module_get and
> module_put to prevent the module unload code from getting here while anyone is
> actually using the protocol. Once we are in the module remove routine here, we
> are guaranateed that there are no users of this protocol, and that the
> tracepoints are all unregistered.
[...]
Yes, of course.
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 0/3] net: mac80211: Neaten debugging
From: Joe Perches @ 2012-05-16 15:43 UTC (permalink / raw)
To: Johannes Berg
Cc: David Miller, linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <1337182220.18519.5.camel@jlt3.sipsolutions.net>
On Wed, 2012-05-16 at 17:30 +0200, Johannes Berg wrote:
> On Wed, 2012-05-16 at 08:22 -0700, Joe Perches wrote:
> > On Wed, 2012-05-16 at 09:59 +0200, Johannes Berg wrote:
> > > I wonder if it makes sense to leave these under
> > > #ifdef though? Why #ifdef something if it's going to be invisible most
> > > of the time anyway?
> >
> > I don't understand your point.
> > #ifdef removal is a good thing.
>
> Yeah, but you left a lot of them under ifdef, and I'm wondering why you
> didn't remove them, or if you should, or ...
Those mostly use other different
#ifdef CONFIG_SOME_OTHER_CONTROL elements.
There are I think 3 that I left because they do
not use printk/pr_level but use wiphy_<level> or
netdev_<level>.
^ permalink raw reply
* Re: [PATCH 0/3] net: mac80211: Neaten debugging
From: Johannes Berg @ 2012-05-16 15:56 UTC (permalink / raw)
To: Joe Perches; +Cc: David Miller, linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <1337183004.4818.2.camel@joe2Laptop>
On Wed, 2012-05-16 at 08:43 -0700, Joe Perches wrote:
> On Wed, 2012-05-16 at 17:30 +0200, Johannes Berg wrote:
> > On Wed, 2012-05-16 at 08:22 -0700, Joe Perches wrote:
> > > On Wed, 2012-05-16 at 09:59 +0200, Johannes Berg wrote:
> > > > I wonder if it makes sense to leave these under
> > > > #ifdef though? Why #ifdef something if it's going to be invisible most
> > > > of the time anyway?
> > >
> > > I don't understand your point.
> > > #ifdef removal is a good thing.
> >
> > Yeah, but you left a lot of them under ifdef, and I'm wondering why you
> > didn't remove them, or if you should, or ...
>
> Those mostly use other different
> #ifdef CONFIG_SOME_OTHER_CONTROL elements.
>
> There are I think 3 that I left because they do
> not use printk/pr_level but use wiphy_<level> or
> netdev_<level>.
Hmm, ok. I guess I need to just look at them and decide what should be
what. Thanks for the preparation work though :)
johannes
^ permalink raw reply
* [PATCH net-next] net: sock_flag() cleanup
From: Eric Dumazet @ 2012-05-16 15:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
- sock_flag() accepts a const pointer
- sock_flag() returns a boolean
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/sock.h | 2 +-
net/core/sock.c | 14 +++++++-------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index e613704..036f506 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -650,7 +650,7 @@ static inline void sock_reset_flag(struct sock *sk, enum sock_flags flag)
__clear_bit(flag, &sk->sk_flags);
}
-static inline int sock_flag(struct sock *sk, enum sock_flags flag)
+static inline bool sock_flag(const struct sock *sk, enum sock_flags flag)
{
return test_bit(flag, &sk->sk_flags);
}
diff --git a/net/core/sock.c b/net/core/sock.c
index 26ed27f..9d144ee 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -849,7 +849,7 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
break;
case SO_BROADCAST:
- v.val = !!sock_flag(sk, SOCK_BROADCAST);
+ v.val = sock_flag(sk, SOCK_BROADCAST);
break;
case SO_SNDBUF:
@@ -865,7 +865,7 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
break;
case SO_KEEPALIVE:
- v.val = !!sock_flag(sk, SOCK_KEEPOPEN);
+ v.val = sock_flag(sk, SOCK_KEEPOPEN);
break;
case SO_TYPE:
@@ -887,7 +887,7 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
break;
case SO_OOBINLINE:
- v.val = !!sock_flag(sk, SOCK_URGINLINE);
+ v.val = sock_flag(sk, SOCK_URGINLINE);
break;
case SO_NO_CHECK:
@@ -900,7 +900,7 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
case SO_LINGER:
lv = sizeof(v.ling);
- v.ling.l_onoff = !!sock_flag(sk, SOCK_LINGER);
+ v.ling.l_onoff = sock_flag(sk, SOCK_LINGER);
v.ling.l_linger = sk->sk_lingertime / HZ;
break;
@@ -1012,11 +1012,11 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
break;
case SO_RXQ_OVFL:
- v.val = !!sock_flag(sk, SOCK_RXQ_OVFL);
+ v.val = sock_flag(sk, SOCK_RXQ_OVFL);
break;
case SO_WIFI_STATUS:
- v.val = !!sock_flag(sk, SOCK_WIFI_STATUS);
+ v.val = sock_flag(sk, SOCK_WIFI_STATUS);
break;
case SO_PEEK_OFF:
@@ -1026,7 +1026,7 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
v.val = sk->sk_peek_off;
break;
case SO_NOFCS:
- v.val = !!sock_flag(sk, SOCK_NOFCS);
+ v.val = sock_flag(sk, SOCK_NOFCS);
break;
default:
return -ENOPROTOOPT;
^ permalink raw reply related
* Re: [PATCH RFC] tun: experimental zero copy tx support
From: Michael S. Tsirkin @ 2012-05-16 16:51 UTC (permalink / raw)
To: Shirley Ma
Cc: David S. Miller, Stephen Hemminger, Joe Perches, Jason Wang,
netdev, linux-kernel, Ian.Campbell, kvm
In-Reply-To: <1337181415.10741.18.camel@oc3660625478.ibm.com>
On Wed, May 16, 2012 at 08:16:55AM -0700, Shirley Ma wrote:
> On Mon, 2012-05-14 at 21:39 +0300, Michael S. Tsirkin wrote:
> > > Hello Mike,
> > >
> > > Have you tested this patch? I think the difference between macvtap
> > and
> > > tap is tap forwarding the packet to bridge. The zerocopy is disabled
> > in
> > > this case.
> > >
> > > Shirley
> >
> > Testing in progress, but the patchset I pointed to enables
> > zerocopy with bridge.
>
> Hello Mike,
>
> You meant this patch or another patchset for enabling bridge zerocopy?
>
> I remembered we disabled forward skb zerocopy since the user space
> program might hold the buffers too long or forever.
>
> In tap/bridge case, when the tx buffers will be released?
>
> Thanks
> Shirley
It still fails some tests for me but maybe I'll post the whole
patchset so you can see how it works.
^ permalink raw reply
* Re: [PATCH] ptp_pch: Add missing #include <linux/slab.h>
From: Richard Cochran @ 2012-05-16 17:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Takahiro Shimizu, David S. Miller, netdev, linux-kernel
In-Reply-To: <1337169017-15835-1-git-send-email-geert@linux-m68k.org>
On Wed, May 16, 2012 at 01:50:17PM +0200, Geert Uytterhoeven wrote:
> drivers/ptp/ptp_pch.c: In function 'pch_remove':
> drivers/ptp/ptp_pch.c:576:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
> drivers/ptp/ptp_pch.c: In function 'pch_probe':
> drivers/ptp/ptp_pch.c:587:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration]
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Richard Cochran <richardcochran@gmail.com>
Thanks,
Richard
> ---
> Not even compile-tested, as it fails on parisc only.
> http://kisskb.ellerman.id.au/kisskb/buildresult/6312813/
>
> drivers/ptp/ptp_pch.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
> index 375eb04..6fff680 100644
> --- a/drivers/ptp/ptp_pch.c
> +++ b/drivers/ptp/ptp_pch.c
> @@ -30,6 +30,7 @@
> #include <linux/module.h>
> #include <linux/pci.h>
> #include <linux/ptp_clock_kernel.h>
> +#include <linux/slab.h>
>
> #define STATION_ADDR_LEN 20
> #define PCI_DEVICE_ID_PCH_1588 0x8819
> --
> 1.7.0.4
>
^ permalink raw reply
* Re: [V2 PATCH 9/9] vhost: zerocopy: poll vq in zerocopy callback
From: Shirley Ma @ 2012-05-16 17:32 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jason Wang, eric.dumazet, netdev, linux-kernel, ebiederm, davem
In-Reply-To: <20120516151444.GC9934@redhat.com>
On Wed, 2012-05-16 at 18:14 +0300, Michael S. Tsirkin wrote:
> On Wed, May 16, 2012 at 08:10:27AM -0700, Shirley Ma wrote:
> > On Wed, 2012-05-16 at 10:58 +0800, Jason Wang wrote:
> > > >> drivers/vhost/vhost.c | 1 +
> > > >> 1 files changed, 1 insertions(+), 0 deletions(-)
> > > >>
> > > >> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > > >> index 947f00d..7b75fdf 100644
> > > >> --- a/drivers/vhost/vhost.c
> > > >> +++ b/drivers/vhost/vhost.c
> > > >> @@ -1604,6 +1604,7 @@ void vhost_zerocopy_callback(void *arg)
> > > >> struct vhost_ubuf_ref *ubufs = ubuf->arg;
> > > >> struct vhost_virtqueue *vq = ubufs->vq;
> > > >>
> > > >> + vhost_poll_queue(&vq->poll);
> > > >> /* set len = 1 to mark this desc buffers done DMA */
> > > >> vq->heads[ubuf->desc].len = VHOST_DMA_DONE_LEN;
> > > >> kref_put(&ubufs->kref, vhost_zerocopy_done_signal);
> > > > Doing so, we might have redundant vhost_poll_queue(). Do you
> know in
> > > > which scenario there might be missing of adding and signaling
> during
> > > > zerocopy?
> > >
> > > Yes, as we only do signaling and adding during tx work, if there's
> no
> > > tx
> > > work when the skb were sent, we may lose the opportunity to let
> guest
> > > know about the completion. It's easy to be reproduced with netperf
> > > test.
> >
> > The reason which host signals guest is to free guest tx buffers, if
> > there is no tx work, then it's not necessary to signal the guest
> unless
> > guest runs out of memory. The pending buffers will be released
> > virtio_net device gone.
> >
> > What's the behavior of netperf test when you hit this situation?
> >
> > Thanks
> > Shirley
>
> IIRC guest networking seems to be lost.
It seems vhost_enable_notify is missing in somewhere else?
Thanks
Shirley
^ permalink raw reply
* Re: [V2 PATCH 9/9] vhost: zerocopy: poll vq in zerocopy callback
From: Michael S. Tsirkin @ 2012-05-16 18:36 UTC (permalink / raw)
To: Shirley Ma
Cc: Jason Wang, eric.dumazet, netdev, linux-kernel, ebiederm, davem
In-Reply-To: <1337189525.10741.24.camel@oc3660625478.ibm.com>
On Wed, May 16, 2012 at 10:32:05AM -0700, Shirley Ma wrote:
> On Wed, 2012-05-16 at 18:14 +0300, Michael S. Tsirkin wrote:
> > On Wed, May 16, 2012 at 08:10:27AM -0700, Shirley Ma wrote:
> > > On Wed, 2012-05-16 at 10:58 +0800, Jason Wang wrote:
> > > > >> drivers/vhost/vhost.c | 1 +
> > > > >> 1 files changed, 1 insertions(+), 0 deletions(-)
> > > > >>
> > > > >> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > > > >> index 947f00d..7b75fdf 100644
> > > > >> --- a/drivers/vhost/vhost.c
> > > > >> +++ b/drivers/vhost/vhost.c
> > > > >> @@ -1604,6 +1604,7 @@ void vhost_zerocopy_callback(void *arg)
> > > > >> struct vhost_ubuf_ref *ubufs = ubuf->arg;
> > > > >> struct vhost_virtqueue *vq = ubufs->vq;
> > > > >>
> > > > >> + vhost_poll_queue(&vq->poll);
> > > > >> /* set len = 1 to mark this desc buffers done DMA */
> > > > >> vq->heads[ubuf->desc].len = VHOST_DMA_DONE_LEN;
> > > > >> kref_put(&ubufs->kref, vhost_zerocopy_done_signal);
> > > > > Doing so, we might have redundant vhost_poll_queue(). Do you
> > know in
> > > > > which scenario there might be missing of adding and signaling
> > during
> > > > > zerocopy?
> > > >
> > > > Yes, as we only do signaling and adding during tx work, if there's
> > no
> > > > tx
> > > > work when the skb were sent, we may lose the opportunity to let
> > guest
> > > > know about the completion. It's easy to be reproduced with netperf
> > > > test.
> > >
> > > The reason which host signals guest is to free guest tx buffers, if
> > > there is no tx work, then it's not necessary to signal the guest
> > unless
> > > guest runs out of memory. The pending buffers will be released
> > > virtio_net device gone.
> > >
> > > What's the behavior of netperf test when you hit this situation?
> > >
> > > Thanks
> > > Shirley
> >
> > IIRC guest networking seems to be lost.
>
> It seems vhost_enable_notify is missing in somewhere else?
>
> Thanks
> Shirley
Donnu. I see virtio sending packets but they do not get
to tun on host. debugging.
^ permalink raw reply
* Re: [PATCH 0/4] netfilter fixes for 3.4-rc7
From: Jozsef Kadlecsik @ 2012-05-16 18:41 UTC (permalink / raw)
To: David Miller; +Cc: Pablo Neira Ayuso, netfilter-devel, netdev
In-Reply-To: <20120514.185607.1967456974676336550.davem@davemloft.net>
Hi Dave,
On Mon, 14 May 2012, David Miller wrote:
> From: pablo@netfilter.org
> Date: Mon, 14 May 2012 13:46:59 +0200
>
> > * One fix for possible timeout overflow for ipset, from Jozsef
> > Kadlecsik.
> >
> > * One fix to ensure that hash size is correct, again for ipset
> > from Jozsef Kadlecsik.
> >
> > * Removal of redundant include in xt_CT from Eldad Zack.
> >
> > * Fix for wrong usage of MODULE_ALIAS_NFCT_HELPER in nf_ct_h323
> > helper from myself.
>
> I don't consider any of these appropriate this late in the -RC
> series.
>
> They don't fix major regressions seen by many users.
Could at least the patch with the subject
netfilter: ipset: fix hash size checking in kernel
The hash size must fit both into u32 (jhash) and the max value of
size_t. The missing checking could lead to kernel crash, bug reported
by Seblu.
be submitted into 3.4-rc7? Any non most-recent ipset package compiled with
gcc-4.7 or above can trigger the bug.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: [PATCH] ptp_pch: Add missing #include <linux/slab.h>
From: David Miller @ 2012-05-16 18:58 UTC (permalink / raw)
To: geert; +Cc: tshimizu818, richardcochran, netdev, linux-kernel
In-Reply-To: <1337169017-15835-1-git-send-email-geert@linux-m68k.org>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Wed, 16 May 2012 13:50:17 +0200
> drivers/ptp/ptp_pch.c: In function 'pch_remove':
> drivers/ptp/ptp_pch.c:576:2: error: implicit declaration of function 'kfree' [-Werror=implicit-function-declaration]
> drivers/ptp/ptp_pch.c: In function 'pch_probe':
> drivers/ptp/ptp_pch.c:587:2: error: implicit declaration of function 'kzalloc' [-Werror=implicit-function-declaration]
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Applied.
^ permalink raw reply
* Re: [V2 PATCH 9/9] vhost: zerocopy: poll vq in zerocopy callback
From: Shirley Ma @ 2012-05-16 19:08 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jason Wang, eric.dumazet, netdev, linux-kernel, ebiederm, davem
In-Reply-To: <20120516183629.GJ10769@redhat.com>
On Wed, 2012-05-16 at 21:36 +0300, Michael S. Tsirkin wrote:
> On Wed, May 16, 2012 at 10:32:05AM -0700, Shirley Ma wrote:
> > On Wed, 2012-05-16 at 18:14 +0300, Michael S. Tsirkin wrote:
> > > On Wed, May 16, 2012 at 08:10:27AM -0700, Shirley Ma wrote:
> > > > On Wed, 2012-05-16 at 10:58 +0800, Jason Wang wrote:
> > > > > >> drivers/vhost/vhost.c | 1 +
> > > > > >> 1 files changed, 1 insertions(+), 0 deletions(-)
> > > > > >>
> > > > > >> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > > > > >> index 947f00d..7b75fdf 100644
> > > > > >> --- a/drivers/vhost/vhost.c
> > > > > >> +++ b/drivers/vhost/vhost.c
> > > > > >> @@ -1604,6 +1604,7 @@ void vhost_zerocopy_callback(void
> *arg)
> > > > > >> struct vhost_ubuf_ref *ubufs = ubuf->arg;
> > > > > >> struct vhost_virtqueue *vq = ubufs->vq;
> > > > > >>
> > > > > >> + vhost_poll_queue(&vq->poll);
> > > > > >> /* set len = 1 to mark this desc buffers done DMA
> */
> > > > > >> vq->heads[ubuf->desc].len = VHOST_DMA_DONE_LEN;
> > > > > >> kref_put(&ubufs->kref,
> vhost_zerocopy_done_signal);
> > > > > > Doing so, we might have redundant vhost_poll_queue(). Do you
> > > know in
> > > > > > which scenario there might be missing of adding and
> signaling
> > > during
> > > > > > zerocopy?
> > > > >
> > > > > Yes, as we only do signaling and adding during tx work, if
> there's
> > > no
> > > > > tx
> > > > > work when the skb were sent, we may lose the opportunity to
> let
> > > guest
> > > > > know about the completion. It's easy to be reproduced with
> netperf
> > > > > test.
> > > >
> > > > The reason which host signals guest is to free guest tx buffers,
> if
> > > > there is no tx work, then it's not necessary to signal the guest
> > > unless
> > > > guest runs out of memory. The pending buffers will be released
> > > > virtio_net device gone.
> > > >
> > > > What's the behavior of netperf test when you hit this situation?
> > > >
> > > > Thanks
> > > > Shirley
> > >
> > > IIRC guest networking seems to be lost.
> >
> > It seems vhost_enable_notify is missing in somewhere else?
> >
> > Thanks
> > Shirley
>
> Donnu. I see virtio sending packets but they do not get
> to tun on host. debugging.
I looked at the code, if (zerocopy) check is needed for below code:
+ if (zerocopy) {
num_pends = likely(vq->upend_idx >= vq->done_idx) ?
(vq->upend_idx - vq->done_idx) :
(vq->upend_idx + UIO_MAXIOV - vq->done_idx);
if (unlikely(num_pends > VHOST_MAX_PEND)) {
tx_poll_start(net, sock);
vhost_poll_queue
set_bit(SOCK_ASYNC_NOSPACE, &sock->flags);
break;
}
+ }
if (unlikely(vhost_enable_notify(&net->dev, vq))) {
vhost_disable_notify(&net->dev, vq);
continue;
}
break;
Second, whether it's possible the problem comes from tx_poll_start()? In
some situation, vhost_poll_wakeup() is not being called?
Thanks
Shirley
^ permalink raw reply
* Re: [PATCH] bonding: only send arp monitor packets if no other traffic
From: Jay Vosburgh @ 2012-05-16 19:08 UTC (permalink / raw)
To: Chris Friesen; +Cc: netdev
In-Reply-To: <4FB3F67C.6000401@genband.com>
Chris Friesen <chris.friesen@genband.com> wrote:
>In order to minimize network traffic, when using load balancing modes
>only send out arp monitor packets if it's been more than delta_in_ticks
>jiffies since we either received or transmitted packets. The rationale
>behind this is that if there is a lot of other traffic going on we don't
>need the arp monitor packets to determine whether or not the link is
>working.
>
>This makes the most difference if you have a lot of hosts all arping
>the same target at high frequency.
This logic would not work for the active-backup case (it would
break arp_validate, for one thing), but might be ok for the loadbalance
(balance-xor, balance-rr) case.
This might adversely affect cases where the switch ports are not
configured into a port channel; in that case, the ARP broadcasts would
be sent to all slaves, but with this patch, will no longer be. That's
technically not a correct configuration, but seems to be in use
nevertheless.
I didn't think that the ARP monitor was particularly popular for
the loadbalance case, since it is not as reliable. It depends upon the
switch to insure that some traffic comes in to each slave, and low
traffic periods can result in false detection of link failures. Even
with the ARPs being sent out, if those are not evenly balanced by the
switch, false failure detections can occur.
-J
>Signed-off-by: Chris Friesen <chris.friesen@genand.com>
>---
> drivers/net/bonding/bond_main.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index bc13b3d..4c8459a 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -2885,8 +2885,12 @@ void bond_loadbalance_arp_mon(struct work_struct *work)
> * do - all replies will be rx'ed on same link causing slaves
> * to be unstable during low/no traffic periods
> */
>- if (IS_UP(slave->dev))
>- bond_arp_send_all(bond, slave);
>+ if (IS_UP(slave->dev)) {
>+ if (time_after_eq(jiffies, dev_trans_start(slave->dev) + delta_in_ticks) ||
>+ time_after_eq(jiffies, slave->dev->last_rx + delta_in_ticks)) {
>+ bond_arp_send_all(bond, slave);
>+ }
>+ }
> }
>
> if (do_failover) {
>
>--
>
>Chris Friesen
>Software Designer
>3500 Carling Avenue
>Ottawa, Ontario K2H 8E9
>www.genband.com
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [PATCH 0/4] netfilter fixes for 3.4-rc7
From: David Miller @ 2012-05-16 19:18 UTC (permalink / raw)
To: kadlec; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <alpine.DEB.2.00.1205162037110.2742@blackhole.kfki.hu>
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Date: Wed, 16 May 2012 20:41:51 +0200 (CEST)
> Could at least the patch with the subject
>
> netfilter: ipset: fix hash size checking in kernel
>
> The hash size must fit both into u32 (jhash) and the max value of
> size_t. The missing checking could lead to kernel crash, bug reported
> by Seblu.
>
> be submitted into 3.4-rc7? Any non most-recent ipset package compiled with
> gcc-4.7 or above can trigger the bug.
And only root can trigger it if he gives bogus parameters right?
If that's the case, the exposure is to privileged users committing an
operator error, so I don't see it as so important.
^ permalink raw reply
* [PATCH] bonding: only send arp monitor packets if no other traffic
From: Chris Friesen @ 2012-05-16 18:48 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In order to minimize network traffic, when using load balancing modes
only send out arp monitor packets if it's been more than delta_in_ticks
jiffies since we either received or transmitted packets. The rationale
behind this is that if there is a lot of other traffic going on we don't
need the arp monitor packets to determine whether or not the link is
working.
This makes the most difference if you have a lot of hosts all arping
the same target at high frequency.
Signed-off-by: Chris Friesen <chris.friesen@genand.com>
---
drivers/net/bonding/bond_main.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index bc13b3d..4c8459a 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2885,8 +2885,12 @@ void bond_loadbalance_arp_mon(struct work_struct *work)
* do - all replies will be rx'ed on same link causing slaves
* to be unstable during low/no traffic periods
*/
- if (IS_UP(slave->dev))
- bond_arp_send_all(bond, slave);
+ if (IS_UP(slave->dev)) {
+ if (time_after_eq(jiffies, dev_trans_start(slave->dev) + delta_in_ticks) ||
+ time_after_eq(jiffies, slave->dev->last_rx + delta_in_ticks)) {
+ bond_arp_send_all(bond, slave);
+ }
+ }
}
if (do_failover) {
--
Chris Friesen
Software Designer
3500 Carling Avenue
Ottawa, Ontario K2H 8E9
www.genband.com
^ permalink raw reply related
* Re: [PATCH net-next v2 0/2] 6lowpan: code updates
From: David Miller @ 2012-05-16 19:28 UTC (permalink / raw)
To: alex.bluesman.smirnov; +Cc: netdev
In-Reply-To: <1337153248-5779-1-git-send-email-alex.bluesman.smirnov@gmail.com>
From: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Date: Wed, 16 May 2012 11:27:26 +0400
> 6lowpan: rework data fetching from skb
This is not what we told you to do.
We told you that IF you were going to emit a warning message
for the pskb_may_pull() failure condition, you should use
WARN_ON_ONCE() so that it doesn't potentially flood the
logs.
But you must always, in every case, handle the error in some
reasonable way, not just when WARN_ON_ONCE() does that initial
one-and-only trigger.
^ permalink raw reply
* Re: [PATCH v2 0/8] mISDN: Fixes and enhancements for the data channels
From: David Miller @ 2012-05-16 19:28 UTC (permalink / raw)
To: kkeil; +Cc: netdev
In-Reply-To: <1337161868-19399-1-git-send-email-kkeil@linux-pingi.de>
From: Karsten Keil <kkeil@linux-pingi.de>
Date: Wed, 16 May 2012 11:51:00 +0200
> v2: All fixes from Dave Millers review
> - comment format
> - use bool type for boolean parameter
> - use (var == CONSTANT)
>
> This series improve the stability of streaming raw voice data when the
> system is under high load. With the fixes in place you can send and
> receive multiple faximilies (using SPANDSP) in parallel
> while compiling a kernel without a getting a transfer aborted.
>
> for net-next
All applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next] net: sock_flag() cleanup
From: David Miller @ 2012-05-16 19:30 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1337183827.8512.1215.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 May 2012 17:57:07 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> - sock_flag() accepts a const pointer
>
> - sock_flag() returns a boolean
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] fq_codel: should use qdisc backlog as threshold
From: David Miller @ 2012-05-16 19:30 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, nichols, dave.taht, van, codel, bloat
In-Reply-To: <1337179149.8512.1208.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 May 2012 16:39:09 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> codel_should_drop() logic allows a packet being not dropped if queue
> size is under max packet size.
>
> In fq_codel, we have two possible backlogs : The qdisc global one, and
> the flow local one.
>
> The meaningful one for codel_should_drop() should be the global backlog,
> not the per flow one, so that thin flows can have a non zero drop/mark
> probability.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [patch 0/2] s390: qeth patches for net-next
From: David Miller @ 2012-05-16 19:33 UTC (permalink / raw)
To: frank.blaschka; +Cc: netdev, linux-s390
In-Reply-To: <20120516112824.602200177@de.ibm.com>
From: frank.blaschka@de.ibm.com
Date: Wed, 16 May 2012 13:28:24 +0200
> here are 2 qeth patches for net-next
>
> shortlog:
>
> Ursula Braun (1)
> qeth: recognize vlan devices in layer3 mode
>
> Frank Blaschka (1)
> qeth: remove token ring part 2
All applied, thanks Frank.
^ permalink raw reply
* Re: [PATCH net-next v5 0/13] basic ieee802.15.4 mac support
From: David Miller @ 2012-05-16 19:34 UTC (permalink / raw)
To: alex.bluesman.smirnov; +Cc: netdev, dbaryshkov
In-Reply-To: <1337151031-5178-1-git-send-email-alex.bluesman.smirnov@gmail.com>
From: Alexander Smirnov <alex.bluesman.smirnov@gmail.com>
Date: Wed, 16 May 2012 10:50:18 +0400
> This is the 5-th version of patch series for IEEE 802.15.4 Medium Access
> Control layer support.
>
> Changes since the last post:
> - All the comments were polished to the same style
> - Some new extra comments were added
All applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/4] netfilter fixes for 3.4-rc7
From: Jozsef Kadlecsik @ 2012-05-16 19:34 UTC (permalink / raw)
To: David Miller; +Cc: pablo, netfilter-devel, netdev
In-Reply-To: <20120516.151836.786389543745557157.davem@davemloft.net>
On Wed, 16 May 2012, David Miller wrote:
> > Could at least the patch with the subject
> >
> > netfilter: ipset: fix hash size checking in kernel
> >
> > The hash size must fit both into u32 (jhash) and the max value of
> > size_t. The missing checking could lead to kernel crash, bug reported
> > by Seblu.
> >
> > be submitted into 3.4-rc7? Any non most-recent ipset package compiled with
> > gcc-4.7 or above can trigger the bug.
>
> And only root can trigger it if he gives bogus parameters right?
Yes, root can trigger it only, however it's a two sided bug: ipset < 6.12
compiled with gcc >= 4.7 is broken and sends bogus data to the kernel,
even when normal input parameters are supplied. And unpatched kernel can
crash when acting on the bogus data. :-(
> If that's the case, the exposure is to privileged users committing an
> operator error, so I don't see it as so important.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* [PATCH v3] xfrm: take iphdr size into account for esp payload size calculation
From: Benjamin Poirier @ 2012-05-16 19:35 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, linux-kernel,
Steffen Klassert
In-Reply-To: <20120514.183952.1459413342269893446.davem@davemloft.net>
Corrects the function that determines the esp payload size.
The calculations done in esp4_get_mtu lead to overlength frames in transport
mode for certain mtu values and suboptimal frames for others.
According to what is done, mainly in esp_output(), net_header_len aka
sizeof(struct iphdr) must be taken into account before doing the alignment
calculation.
Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
---
Changes since v2:
* rename l3_adj to net_adj
* fix indentation
Changes since v1:
* introduce l3_adj to preserve the same returned value as before for tunnel
mode
For example, with md5 AH and 3des ESP (transport mode):
mtu = 1499 leads to FRAGFAILS
mtu = 1500 the addition of padding in the esp header could be avoided
Tested with
* transport mode E
* transport mode EA
* transport mode E + ah
* tunnel mode E
Not tested with BEET, but it should be the same as transport mode
draft-nikander-esp-beet-mode-03.txt Section 5.2:
"The wire packet format is identical to the ESP transport mode"
---
net/ipv4/esp4.c | 24 +++++++++---------------
1 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 89a47b3..cb982a6 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -459,28 +459,22 @@ static u32 esp4_get_mtu(struct xfrm_state *x, int mtu)
struct esp_data *esp = x->data;
u32 blksize = ALIGN(crypto_aead_blocksize(esp->aead), 4);
u32 align = max_t(u32, blksize, esp->padlen);
- u32 rem;
-
- mtu -= x->props.header_len + crypto_aead_authsize(esp->aead);
- rem = mtu & (align - 1);
- mtu &= ~(align - 1);
+ unsigned int net_adj;
switch (x->props.mode) {
- case XFRM_MODE_TUNNEL:
- break;
- default:
case XFRM_MODE_TRANSPORT:
- /* The worst case */
- mtu -= blksize - 4;
- mtu += min_t(u32, blksize - 4, rem);
- break;
case XFRM_MODE_BEET:
- /* The worst case. */
- mtu += min_t(u32, IPV4_BEET_PHMAXLEN, rem);
+ net_adj = sizeof(struct iphdr);
break;
+ case XFRM_MODE_TUNNEL:
+ net_adj = 0;
+ break;
+ default:
+ BUG();
}
- return mtu - 2;
+ return ((mtu - x->props.header_len - crypto_aead_authsize(esp->aead) -
+ net_adj) & ~(align - 1)) + (net_adj - 2);
}
static void esp4_err(struct sk_buff *skb, u32 info)
--
1.7.7
^ permalink raw reply related
* Re: PROBLEM: Fragmentation issue with 1521 bytes ip packets
From: Omar Alhassane @ 2012-05-16 19:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1337094259.8512.1100.camel@edumazet-glaptop>
Thank you for explaining.
Omar
On Tue, May 15, 2012 at 11:04 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> On Tue, 2012-05-15 at 10:00 -0400, Omar Alhassane wrote:
> > Hello Folks,
> >
> > I think i may have found a problem with the linux networking stack.
> > Below is a description of the problem.
> >
> > [1.] One line summary of the problem:
> > No response to pings of certain sizes.
> >
> > [2.] Full description of the problem/report:
> > Using hping3, when i ping a linux machine with 1521 bytes ip packets i
> > get only one response.
> > But when i use 1482 bytes, everything works fine. I've tried this with
> > both tcp and udp. The MTU of my interface is 1500.
> > [3.] Keywords (i.e., modules, networking, kernel):
> > ip, udp, tcp, networking, fragmentation
> > [4.] Kernel version (from /proc/version):
> > 3.3.1
> > [5.] Output of Oops.. message (if applicable) with symbolic information
> > [6.] A small shell script or example program which triggers the
> > problem (if possible)
> > The following commands works only if the target has tcp port 22 open
> >
> > hping3 -d 1481 -S -P 22 10.0.30.225 (only one response)
> > hping3 -d 1482 -S -P 22 10.0.30.225 (works fine)
> >
> > Can somebody confirm if this is a problem?
>
> hping3 bug : All the fragments it sends have the same ID field.
>
> First 2 frags are reassembled by remote. Remote sends a SYNACK.
>
>
> Following frags are 'ignored' because they have same ID than previous
> packet.
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH net-next v4] be2net: Fix to allow get/set of debug levels in the firmware.
From: David Miller @ 2012-05-16 19:37 UTC (permalink / raw)
To: somnath.kotur; +Cc: netdev, bhutchings, suresh.reddy
In-Reply-To: <23cb36ad-2827-44bd-a91a-c6d8b01db70e@exht1.ad.emulex.com>
From: Somnath Kotur <somnath.kotur@emulex.com>
Date: Mon, 14 May 2012 21:59:28 +0530
> Fixed missing paranthesis warning
> Incorporated review comments by Ben Hutchings.
>
> Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com>
> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
Ben H., please review.
Thank you.
^ 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