* Re: [PATCH] ipv6: gro: fix PV6_GRO_CB(skb)->proto problem
From: David Miller @ 2012-10-08 19:41 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, herbert
In-Reply-To: <1349725130.21172.3663.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 08 Oct 2012 21:38:50 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> It seems IPV6_GRO_CB(skb)->proto can be destroyed in skb_gro_receive()
> if a new skb is allocated (to serve as an anchor for frag_list)
>
> We copy NAPI_GRO_CB() only (not the IPV6 specific part) in :
>
> *NAPI_GRO_CB(nskb) = *NAPI_GRO_CB(p);
>
> So we leave IPV6_GRO_CB(nskb)->proto to 0 (fresh skb allocation) instead
> of IPPROTO_TCP (6)
>
> ipv6_gro_complete() isnt able to call ops->gro_complete()
> [ tcp6_gro_complete() ]
>
> Fix this by moving proto in NAPI_GRO_CB() and getting rid of
> IPV6_GRO_CB
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [RFC] napi: limit GRO latency
From: Eric Dumazet @ 2012-10-08 19:46 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, rick.jones2, herbert, netdev, jesse
In-Reply-To: <20121008124026.4057aba8@nehalam.linuxnetplumber.net>
On Mon, 2012-10-08 at 12:40 -0700, Stephen Hemminger wrote:
> On Mon, 08 Oct 2012 21:30:12 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > System is under stress, you dont want to increase load at this point,
> > but increase bandwidth.
> >
> > Really try this on a 40Gbe link and see how bad it is.
>
> Not everybody has 40Gbe hardware just lying around available for testing :-)
;)
In fact, the current strategy to flush napi_gro when napi completes
might be not good for moderate traffic (thats 99% of the linux machines
I believe). We could have a deferred flush instead...
I dont know what strategy is used by hardware. But surely hardware uses
timers.
^ permalink raw reply
* Re: [PATCH net 1/6] ipv4: fix sending of redirects
From: Julian Anastasov @ 2012-10-08 20:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20121008.151633.753185005887436197.davem@davemloft.net>
Hello,
On Mon, 8 Oct 2012, David Miller wrote:
> From: Julian Anastasov <ja@ssi.bg>
> Date: Sun, 7 Oct 2012 14:26:03 +0300
>
> > @@ -322,7 +322,8 @@ int fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
> > {
> > int r = secpath_exists(skb) ? 0 : IN_DEV_RPFILTER(idev);
> >
> > - if (!r && !fib_num_tclassid_users(dev_net(dev))) {
> > + if (!r && !fib_num_tclassid_users(dev_net(dev)) &&
> > + dev->ifindex != oif) {
> > *itag = 0;
> > return 0;
> > }
>
> Hmmm, won't this cause the slow path to be taken for locally
> destined traffic?
In this case idev=eth0 and oif=lo. The only case
where we can see same input and output device is for
forwarding and loopback (but only output routes where
there is no such validation).
Of course, it slows down on traffic that ignores
our redirects. We can save some cycles if IN_DEV_TX_REDIRECTS
is checked before setting RTCF_DOREDIRECT:
(dev->ifindex != oif || !IN_DEV_TX_REDIRECTS(idev)) {
RTCF_DOREDIRECT is used just to call ip_rt_send_redirect
where all depends on IN_DEV_TX_REDIRECTS.
The only difference can be that user space will
not see RTCF_DOREDIRECT flag if IN_DEV_TX_REDIRECTS is false.
But may be it is better to show "redirect" in ip route
only when IN_DEV_TX_REDIRECTS are enabled. The old way
is preferred only when there is routing cache and changes
in IN_DEV_TX_REDIRECTS do not flush cache in devinet_conf_proc().
> > + rt->rt_gateway ? : ip_hdr(skb)->daddr);
>
> Please use the rt_nexthop() helper.
>
> > + __be32 gw = rt->rt_gateway ? : ip_hdr(skb)->daddr;
Good idea.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH 0/3] virtio-net: inline header support
From: Michael S. Tsirkin @ 2012-10-08 20:41 UTC (permalink / raw)
To: Rusty Russell
Cc: kvm, netdev, linux-kernel, Sasha Levin, virtualization, avi,
Thomas Lendacky
In-Reply-To: <87vces2gxq.fsf@rustcorp.com.au>
On Wed, Oct 03, 2012 at 04:14:17PM +0930, Rusty Russell wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
> > Thinking about Sasha's patches, we can reduce ring usage
> > for virtio net small packets dramatically if we put
> > virtio net header inline with the data.
> > This can be done for free in case guest net stack allocated
> > extra head room for the packet, and I don't see
> > why would this have any downsides.
>
> I've been wanting to do this for the longest time... but...
>
> > Even though with my recent patches qemu
> > no longer requires header to be the first s/g element,
> > we need a new feature bit to detect this.
> > A trivial qemu patch will be sent separately.
>
> There's a reason I haven't done this. I really, really dislike "my
> implemention isn't broken" feature bits. We could have an infinite
> number of them, for each bug in each device.
>
> So my plan was to tie this assumption to the new PCI layout.
I don't object but old qemu has this limitation for s390 as well,
and that's not using PCI, right? So how do we detect
new hypervisor there?
--
MST
^ permalink raw reply
* Re: [PATCH net 1/6] ipv4: fix sending of redirects
From: David Miller @ 2012-10-08 20:41 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1210082259180.12172@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Mon, 8 Oct 2012 23:43:45 +0300 (EEST)
> On Mon, 8 Oct 2012, David Miller wrote:
>
>> From: Julian Anastasov <ja@ssi.bg>
>> Date: Sun, 7 Oct 2012 14:26:03 +0300
>>
>> > @@ -322,7 +322,8 @@ int fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
>> > {
>> > int r = secpath_exists(skb) ? 0 : IN_DEV_RPFILTER(idev);
>> >
>> > - if (!r && !fib_num_tclassid_users(dev_net(dev))) {
>> > + if (!r && !fib_num_tclassid_users(dev_net(dev)) &&
>> > + dev->ifindex != oif) {
>> > *itag = 0;
>> > return 0;
>> > }
>>
>> Hmmm, won't this cause the slow path to be taken for locally
>> destined traffic?
>
> In this case idev=eth0 and oif=lo. The only case
> where we can see same input and output device is for
> forwarding and loopback (but only output routes where
> there is no such validation).
Ok, now I understand. This added condition is fine.
Thanks.
^ permalink raw reply
* [PATCH resend] net, bluetooth: don't attempt to free a channel that wasn't created
From: Sasha Levin @ 2012-10-08 20:48 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg, davem
Cc: linux-bluetooth, davej, netdev, linux-kernel, levinsasha928,
Sasha Levin
We may currently attempt to free a channel which wasn't created due to
an error in the initialization path, this would cause a NULL ptr deref.
This would cause the following oops:
[ 12.919073] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
[ 12.919131] IP: [<ffffffff836645c4>] l2cap_chan_put+0x34/0x50
[ 12.919135] PGD 0
[ 12.919138] Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 12.919193] Dumping ftrace buffer:
[ 12.919242] (ftrace buffer empty)
[ 12.919314] Modules linked in:
[ 12.919318] CPU 1
[ 12.919319] Pid: 6210, comm: krfcommd Tainted: G W 3.6.0-next-20121004-sasha-00005-gb010653-dirty #30
[ 12.919374] RIP: 0010:[<ffffffff836645c4>] [<ffffffff836645c4>] l2cap_chan_put+0x34/0x50
[ 12.919377] RSP: 0000:ffff880066933c38 EFLAGS: 00010246
[ 12.919378] RAX: ffffffff8366c780 RBX: 0000000000000000 RCX: 6666666666666667
[ 12.919379] RDX: 0000000000000fa0 RSI: ffffffff84d3f79e RDI: 0000000000000010
[ 12.919381] RBP: ffff880066933c48 R08: ffffffff859989f8 R09: 0000000000000001
[ 12.919382] R10: 0000000000000000 R11: 7fffffffffffffff R12: 0000000000000000
[ 12.919383] R13: ffff88009b00a200 R14: ffff88009b00a200 R15: 0000000000000001
[ 12.919385] FS: 0000000000000000(0000) GS:ffff880033600000(0000) knlGS:0000000000000000
[ 12.919437] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 12.919440] CR2: 0000000000000010 CR3: 0000000005026000 CR4: 00000000000406e0
[ 12.919446] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 12.919451] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 12.919504] Process krfcommd (pid: 6210, threadinfo ffff880066932000, task ffff880065c4b000)
[ 12.919506] Stack:
[ 12.919510] ffff88009b00a200 ffff880032084000 ffff880066933c68 ffffffff8366c7bc
[ 12.919513] 7fffffffffffffff ffff880032084000 ffff880066933c98 ffffffff833ae0ae
[ 12.919516] ffff880066933ca8 0000000000000000 0000000000000000 ffff88009b00a200
[ 12.919517] Call Trace:
[ 12.919522] [<ffffffff8366c7bc>] l2cap_sock_destruct+0x3c/0x80
[ 12.919527] [<ffffffff833ae0ae>] __sk_free+0x1e/0x1f0
[ 12.919530] [<ffffffff833ae2f7>] sk_free+0x17/0x20
[ 12.919585] [<ffffffff8366ca4e>] l2cap_sock_alloc.constprop.5+0x9e/0xd0
[ 12.919591] [<ffffffff8366cb9e>] l2cap_sock_create+0x7e/0x100
[ 12.919652] [<ffffffff83a4f32a>] ? _raw_read_lock+0x6a/0x80
[ 12.919658] [<ffffffff836402c4>] ? bt_sock_create+0x74/0x110
[ 12.919660] [<ffffffff83640308>] bt_sock_create+0xb8/0x110
[ 12.919664] [<ffffffff833aa232>] __sock_create+0x282/0x3b0
[ 12.919720] [<ffffffff833aa0b0>] ? __sock_create+0x100/0x3b0
[ 12.919725] [<ffffffff836785b0>] ? rfcomm_process_sessions+0x17e0/0x17e0
[ 12.919779] [<ffffffff833aa37f>] sock_create_kern+0x1f/0x30
[ 12.919784] [<ffffffff83675714>] rfcomm_l2sock_create+0x44/0x70
[ 12.919787] [<ffffffff836785b0>] ? rfcomm_process_sessions+0x17e0/0x17e0
[ 12.919790] [<ffffffff836785fe>] rfcomm_run+0x4e/0x1f0
[ 12.919846] [<ffffffff836785b0>] ? rfcomm_process_sessions+0x17e0/0x17e0
[ 12.919852] [<ffffffff81138ee3>] kthread+0xe3/0xf0
[ 12.919908] [<ffffffff8117b12e>] ? put_lock_stats.isra.14+0xe/0x40
[ 12.919914] [<ffffffff81138e00>] ? flush_kthread_work+0x1f0/0x1f0
[ 12.919968] [<ffffffff83a5077c>] ret_from_fork+0x7c/0x90
[ 12.919973] [<ffffffff81138e00>] ? flush_kthread_work+0x1f0/0x1f0
[ 12.920161] Code: 83 ec 08 f6 05 ff 58 44 02 04 74 1b 8b 4f 10 48 89 fa 48 c7 c6 d9 d7 d4 84 48 c7 c7 80 9e aa 85 31 c0 e8 80
ac 3a fe 48 8d 7b 10 <f0> 83 6b 10 01 0f 94 c0 84 c0 74 05 e8 8b e0 ff ff 48 83 c4 08
[ 12.920165] RIP [<ffffffff836645c4>] l2cap_chan_put+0x34/0x50
[ 12.920166] RSP <ffff880066933c38>
[ 12.920167] CR2: 0000000000000010
[ 12.920417] ---[ end trace 5a9114e8a158ab84 ]---
Introduced in commit 61d6ef3e ("Bluetooth: Make better use of l2cap_chan
reference counting").
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
---
net/bluetooth/l2cap_sock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 083f2bf..66c295a 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -1083,7 +1083,8 @@ static void l2cap_sock_destruct(struct sock *sk)
{
BT_DBG("sk %p", sk);
- l2cap_chan_put(l2cap_pi(sk)->chan);
+ if (l2cap_pi(sk)->chan)
+ l2cap_chan_put(l2cap_pi(sk)->chan);
if (l2cap_pi(sk)->rx_busy_skb) {
kfree_skb(l2cap_pi(sk)->rx_busy_skb);
l2cap_pi(sk)->rx_busy_skb = NULL;
--
1.7.12
^ permalink raw reply related
* Re: [PATCH 0/3] virtio-net: inline header support
From: Michael S. Tsirkin @ 2012-10-08 21:31 UTC (permalink / raw)
To: Rusty Russell
Cc: kvm, netdev, linux-kernel, Sasha Levin, virtualization, avi,
Anthony Liguori, Thomas Lendacky
In-Reply-To: <87391u3o67.fsf@rustcorp.com.au>
On Thu, Oct 04, 2012 at 01:04:56PM +0930, Rusty Russell wrote:
> Anthony Liguori <anthony@codemonkey.ws> writes:
> > Rusty Russell <rusty@rustcorp.com.au> writes:
> >
> >> "Michael S. Tsirkin" <mst@redhat.com> writes:
> >>
> >>> Thinking about Sasha's patches, we can reduce ring usage
> >>> for virtio net small packets dramatically if we put
> >>> virtio net header inline with the data.
> >>> This can be done for free in case guest net stack allocated
> >>> extra head room for the packet, and I don't see
> >>> why would this have any downsides.
> >>
> >> I've been wanting to do this for the longest time... but...
> >>
> >>> Even though with my recent patches qemu
> >>> no longer requires header to be the first s/g element,
> >>> we need a new feature bit to detect this.
> >>> A trivial qemu patch will be sent separately.
> >>
> >> There's a reason I haven't done this. I really, really dislike "my
> >> implemention isn't broken" feature bits. We could have an infinite
> >> number of them, for each bug in each device.
> >
> > This is a bug in the specification.
> >
> > The QEMU implementation pre-dates the specification. All of the actual
> > implementations of virtio relied on the semantics of s/g elements and
> > still do.
>
> lguest fix is pending in my queue. lkvm and qemu are broken; lkvm isn't
> ever going to be merged, so I'm not sure what its status is? But I'm
> determined to fix qemu, and hence my torture patch to make sure this
> doesn't creep in again.
If you look at my patch you'll notice there's also a
comment in virtio_net.h that seems to be broken in this respect:
/* This is the first element of the scatter-gather list. If you don't
* specify GSO or CSUM features, you can simply ignore the header. */
There is a similar comment in virtio-blk.
^ permalink raw reply
* [PATCH net v2 1/6] ipv4: fix sending of redirects
From: Julian Anastasov @ 2012-10-08 21:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1349732480-19978-1-git-send-email-ja@ssi.bg>
After "Cache input routes in fib_info nexthops" (commit
d2d68ba9fe) and "Elide fib_validate_source() completely when possible"
(commit 7a9bc9b81a) we can not send ICMP redirects. It seems we
should not cache the RTCF_DOREDIRECT flag in nh_rth_input because
the same fib_info can be used for traffic that is not redirected,
eg. from other input devices or from sources that are not in same subnet.
As result, we have to disable the caching of RTCF_DOREDIRECT
flag and to force source validation for the case when forwarding
traffic to the input device. If traffic comes from directly connected
source we allow redirection as it was done before both changes.
Avoid setting RTCF_DOREDIRECT if IN_DEV_TX_REDIRECTS
is disabled, this can avoid source address validation and to
help caching the routes.
After the change "Adjust semantics of rt->rt_gateway"
(commit f8126f1d51) we should make sure our ICMP_REDIR_HOST messages
contain daddr instead of 0.0.0.0 when target is directly connected.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/ipv4/fib_frontend.c | 3 ++-
net/ipv4/route.c | 30 ++++++++++++++++--------------
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 68c93d1..825c608 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -322,7 +322,8 @@ int fib_validate_source(struct sk_buff *skb, __be32 src, __be32 dst,
{
int r = secpath_exists(skb) ? 0 : IN_DEV_RPFILTER(idev);
- if (!r && !fib_num_tclassid_users(dev_net(dev))) {
+ if (!r && !fib_num_tclassid_users(dev_net(dev)) &&
+ (dev->ifindex != oif || !IN_DEV_TX_REDIRECTS(idev))) {
*itag = 0;
return 0;
}
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 132e0df..b90da1b 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -802,7 +802,8 @@ void ip_rt_send_redirect(struct sk_buff *skb)
net = dev_net(rt->dst.dev);
peer = inet_getpeer_v4(net->ipv4.peers, ip_hdr(skb)->saddr, 1);
if (!peer) {
- icmp_send(skb, ICMP_REDIRECT, ICMP_REDIR_HOST, rt->rt_gateway);
+ icmp_send(skb, ICMP_REDIRECT, ICMP_REDIR_HOST,
+ rt_nexthop(rt, ip_hdr(skb)->daddr));
return;
}
@@ -827,7 +828,9 @@ void ip_rt_send_redirect(struct sk_buff *skb)
time_after(jiffies,
(peer->rate_last +
(ip_rt_redirect_load << peer->rate_tokens)))) {
- icmp_send(skb, ICMP_REDIRECT, ICMP_REDIR_HOST, rt->rt_gateway);
+ __be32 gw = rt_nexthop(rt, ip_hdr(skb)->daddr);
+
+ icmp_send(skb, ICMP_REDIRECT, ICMP_REDIR_HOST, gw);
peer->rate_last = jiffies;
++peer->rate_tokens;
#ifdef CONFIG_IP_ROUTE_VERBOSE
@@ -835,7 +838,7 @@ void ip_rt_send_redirect(struct sk_buff *skb)
peer->rate_tokens == ip_rt_redirect_number)
net_warn_ratelimited("host %pI4/if%d ignores redirects for %pI4 to %pI4\n",
&ip_hdr(skb)->saddr, inet_iif(skb),
- &ip_hdr(skb)->daddr, &rt->rt_gateway);
+ &ip_hdr(skb)->daddr, &gw);
#endif
}
out_put_peer:
@@ -1442,10 +1445,13 @@ static int __mkroute_input(struct sk_buff *skb,
goto cleanup;
}
- if (out_dev == in_dev && err &&
+ do_cache = res->fi && !itag;
+ if (out_dev == in_dev && err && IN_DEV_TX_REDIRECTS(out_dev) &&
(IN_DEV_SHARED_MEDIA(out_dev) ||
- inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res))))
+ inet_addr_onlink(out_dev, saddr, FIB_RES_GW(*res)))) {
flags |= RTCF_DOREDIRECT;
+ do_cache = false;
+ }
if (skb->protocol != htons(ETH_P_IP)) {
/* Not IP (i.e. ARP). Do not create route, if it is
@@ -1462,15 +1468,11 @@ static int __mkroute_input(struct sk_buff *skb,
}
}
- do_cache = false;
- if (res->fi) {
- if (!itag) {
- rth = rcu_dereference(FIB_RES_NH(*res).nh_rth_input);
- if (rt_cache_valid(rth)) {
- skb_dst_set_noref(skb, &rth->dst);
- goto out;
- }
- do_cache = true;
+ if (do_cache) {
+ rth = rcu_dereference(FIB_RES_NH(*res).nh_rth_input);
+ if (rt_cache_valid(rth)) {
+ skb_dst_set_noref(skb, &rth->dst);
+ goto out;
}
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH net v2 2/6] ipv4: fix forwarding for strict source routes
From: Julian Anastasov @ 2012-10-08 21:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1349732480-19978-1-git-send-email-ja@ssi.bg>
After the change "Adjust semantics of rt->rt_gateway"
(commit f8126f1d51) rt_gateway can be 0 but ip_forward() compares
it directly with nexthop. What we want here is to check if traffic
is to directly connected nexthop and to fail if using gateway.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/ipv4/ip_forward.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/ip_forward.c b/net/ipv4/ip_forward.c
index ab09b12..7f35ac2 100644
--- a/net/ipv4/ip_forward.c
+++ b/net/ipv4/ip_forward.c
@@ -85,7 +85,7 @@ int ip_forward(struct sk_buff *skb)
rt = skb_rtable(skb);
- if (opt->is_strictroute && opt->nexthop != rt->rt_gateway)
+ if (opt->is_strictroute && rt->rt_gateway)
goto sr_failed;
if (unlikely(skb->len > dst_mtu(&rt->dst) && !skb_is_gso(skb) &&
--
1.7.3.4
^ permalink raw reply related
* [PATCH net v2 0/6] ipv4: Changes for rt_gateway
From: Julian Anastasov @ 2012-10-08 21:41 UTC (permalink / raw)
To: netdev
This patchset fixes some problems for the routing caused
by the new rt_gateway semantics. What started as a fix for
IPVS-DR ended as fixes for more problems. To solve the IPVS
problem I decided to name the flag FLOWI_FLAG_KNOWN_NH, so that
we can even get route cached in FNHE or FIB NH.
Different flag FLOWI_FLAG_RT_NOCACHE could be equally good
for IPVS, we again would be able to use data from fnhe but working
with cached routes should be preferred. If there is no FNHE, the
common case is IPVS to get uncached route, of course, IPVS caches
it itself.
Patches 1-3 are fixes not related to IPVS problem,
4 and 5 add code that will be used by IPVS in patch 6.
Julian Anastasov (6):
ipv4: fix sending of redirects
ipv4: fix forwarding for strict source routes
ipv4: make sure nh_pcpu_rth_output is always allocated
ipv4: introduce rt_uses_gateway
ipv4: Add FLOWI_FLAG_KNOWN_NH
ipvs: fix ARP resolving for direct routing mode
include/net/flow.h | 1 +
include/net/route.h | 3 +-
net/ipv4/fib_frontend.c | 3 +-
net/ipv4/fib_semantics.c | 2 +
net/ipv4/inet_connection_sock.c | 4 +-
net/ipv4/ip_forward.c | 2 +-
net/ipv4/ip_output.c | 4 +-
net/ipv4/route.c | 102 ++++++++++++++++++++++----------------
net/ipv4/xfrm4_policy.c | 1 +
net/netfilter/ipvs/ip_vs_xmit.c | 6 ++-
10 files changed, 77 insertions(+), 51 deletions(-)
--
1.7.3.4
^ permalink raw reply
* [PATCH net v2 3/6] ipv4: make sure nh_pcpu_rth_output is always allocated
From: Julian Anastasov @ 2012-10-08 21:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1349732480-19978-1-git-send-email-ja@ssi.bg>
Avoid checking nh_pcpu_rth_output in fast path,
abort fib_info creation on alloc_percpu failure.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/ipv4/fib_semantics.c | 2 ++
net/ipv4/route.c | 3 ---
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 2677530..71b125c 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -840,6 +840,8 @@ struct fib_info *fib_create_info(struct fib_config *cfg)
change_nexthops(fi) {
nexthop_nh->nh_parent = fi;
nexthop_nh->nh_pcpu_rth_output = alloc_percpu(struct rtable __rcu *);
+ if (!nexthop_nh->nh_pcpu_rth_output)
+ goto failure;
} endfor_nexthops(fi)
if (cfg->fc_mx) {
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index b90da1b..5b0180f 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1207,8 +1207,6 @@ static bool rt_cache_route(struct fib_nh *nh, struct rtable *rt)
if (rt_is_input_route(rt)) {
p = (struct rtable **)&nh->nh_rth_input;
} else {
- if (!nh->nh_pcpu_rth_output)
- goto nocache;
p = (struct rtable **)__this_cpu_ptr(nh->nh_pcpu_rth_output);
}
orig = *p;
@@ -1223,7 +1221,6 @@ static bool rt_cache_route(struct fib_nh *nh, struct rtable *rt)
* unsuccessful at storing this route into the cache
* we really need to set it.
*/
-nocache:
rt->dst.flags |= DST_NOCACHE;
ret = false;
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH net v2 4/6] ipv4: introduce rt_uses_gateway
From: Julian Anastasov @ 2012-10-08 21:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1349732480-19978-1-git-send-email-ja@ssi.bg>
Add new flag to remember when route is via gateway.
We will use it to allow rt_gateway to contain address of
directly connected host for the cases when DST_NOCACHE is
used or when the NH exception caches per-destination route
without DST_NOCACHE flag, i.e. when routes are not used for
other destinations. By this way we force the neighbour
resolving to work with the routed destination but we
can use different address in the packet, feature needed
for IPVS-DR where original packet for virtual IP is routed
via route to real IP.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
include/net/route.h | 3 +-
net/ipv4/inet_connection_sock.c | 4 +-
net/ipv4/ip_forward.c | 2 +-
net/ipv4/ip_output.c | 4 +-
net/ipv4/route.c | 48 +++++++++++++++++++++-----------------
net/ipv4/xfrm4_policy.c | 1 +
6 files changed, 34 insertions(+), 28 deletions(-)
diff --git a/include/net/route.h b/include/net/route.h
index da22243..bc40b63 100644
--- a/include/net/route.h
+++ b/include/net/route.h
@@ -48,7 +48,8 @@ struct rtable {
int rt_genid;
unsigned int rt_flags;
__u16 rt_type;
- __u16 rt_is_input;
+ __u8 rt_is_input;
+ __u8 rt_uses_gateway;
int rt_iif;
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index f0c5b9c..d34ce29 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -406,7 +406,7 @@ struct dst_entry *inet_csk_route_req(struct sock *sk,
rt = ip_route_output_flow(net, fl4, sk);
if (IS_ERR(rt))
goto no_route;
- if (opt && opt->opt.is_strictroute && rt->rt_gateway)
+ if (opt && opt->opt.is_strictroute && rt->rt_uses_gateway)
goto route_err;
return &rt->dst;
@@ -442,7 +442,7 @@ struct dst_entry *inet_csk_route_child_sock(struct sock *sk,
rt = ip_route_output_flow(net, fl4, sk);
if (IS_ERR(rt))
goto no_route;
- if (opt && opt->opt.is_strictroute && rt->rt_gateway)
+ if (opt && opt->opt.is_strictroute && rt->rt_uses_gateway)
goto route_err;
rcu_read_unlock();
return &rt->dst;
diff --git a/net/ipv4/ip_forward.c b/net/ipv4/ip_forward.c
index 7f35ac2..694de3b 100644
--- a/net/ipv4/ip_forward.c
+++ b/net/ipv4/ip_forward.c
@@ -85,7 +85,7 @@ int ip_forward(struct sk_buff *skb)
rt = skb_rtable(skb);
- if (opt->is_strictroute && rt->rt_gateway)
+ if (opt->is_strictroute && rt->rt_uses_gateway)
goto sr_failed;
if (unlikely(skb->len > dst_mtu(&rt->dst) && !skb_is_gso(skb) &&
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 24a29a3..6537a40 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -193,7 +193,7 @@ static inline int ip_finish_output2(struct sk_buff *skb)
}
rcu_read_lock_bh();
- nexthop = rt->rt_gateway ? rt->rt_gateway : ip_hdr(skb)->daddr;
+ nexthop = (__force u32) rt_nexthop(rt, ip_hdr(skb)->daddr);
neigh = __ipv4_neigh_lookup_noref(dev, nexthop);
if (unlikely(!neigh))
neigh = __neigh_create(&arp_tbl, &nexthop, dev, false);
@@ -371,7 +371,7 @@ int ip_queue_xmit(struct sk_buff *skb, struct flowi *fl)
skb_dst_set_noref(skb, &rt->dst);
packet_routed:
- if (inet_opt && inet_opt->opt.is_strictroute && rt->rt_gateway)
+ if (inet_opt && inet_opt->opt.is_strictroute && rt->rt_uses_gateway)
goto no_route;
/* OK, we know where to send it, allocate and build IP header. */
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 5b0180f..3a116cb 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1126,7 +1126,7 @@ static unsigned int ipv4_mtu(const struct dst_entry *dst)
mtu = dst->dev->mtu;
if (unlikely(dst_metric_locked(dst, RTAX_MTU))) {
- if (rt->rt_gateway && mtu > 576)
+ if (rt->rt_uses_gateway && mtu > 576)
mtu = 576;
}
@@ -1177,7 +1177,9 @@ static bool rt_bind_exception(struct rtable *rt, struct fib_nh_exception *fnhe,
if (fnhe->fnhe_gw) {
rt->rt_flags |= RTCF_REDIRECTED;
rt->rt_gateway = fnhe->fnhe_gw;
- }
+ rt->rt_uses_gateway = 1;
+ } else if (!rt->rt_gateway)
+ rt->rt_gateway = daddr;
orig = rcu_dereference(fnhe->fnhe_rth);
rcu_assign_pointer(fnhe->fnhe_rth, rt);
@@ -1186,13 +1188,6 @@ static bool rt_bind_exception(struct rtable *rt, struct fib_nh_exception *fnhe,
fnhe->fnhe_stamp = jiffies;
ret = true;
- } else {
- /* Routes we intend to cache in nexthop exception have
- * the DST_NOCACHE bit clear. However, if we are
- * unsuccessful at storing this route into the cache
- * we really need to set it.
- */
- rt->dst.flags |= DST_NOCACHE;
}
spin_unlock_bh(&fnhe_lock);
@@ -1215,15 +1210,8 @@ static bool rt_cache_route(struct fib_nh *nh, struct rtable *rt)
if (prev == orig) {
if (orig)
rt_free(orig);
- } else {
- /* Routes we intend to cache in the FIB nexthop have
- * the DST_NOCACHE bit clear. However, if we are
- * unsuccessful at storing this route into the cache
- * we really need to set it.
- */
- rt->dst.flags |= DST_NOCACHE;
+ } else
ret = false;
- }
return ret;
}
@@ -1284,8 +1272,10 @@ static void rt_set_nexthop(struct rtable *rt, __be32 daddr,
if (fi) {
struct fib_nh *nh = &FIB_RES_NH(*res);
- if (nh->nh_gw && nh->nh_scope == RT_SCOPE_LINK)
+ if (nh->nh_gw && nh->nh_scope == RT_SCOPE_LINK) {
rt->rt_gateway = nh->nh_gw;
+ rt->rt_uses_gateway = 1;
+ }
dst_init_metrics(&rt->dst, fi->fib_metrics, true);
#ifdef CONFIG_IP_ROUTE_CLASSID
rt->dst.tclassid = nh->nh_tclassid;
@@ -1294,8 +1284,18 @@ static void rt_set_nexthop(struct rtable *rt, __be32 daddr,
cached = rt_bind_exception(rt, fnhe, daddr);
else if (!(rt->dst.flags & DST_NOCACHE))
cached = rt_cache_route(nh, rt);
- }
- if (unlikely(!cached))
+ if (unlikely(!cached)) {
+ /* Routes we intend to cache in nexthop exception or
+ * FIB nexthop have the DST_NOCACHE bit clear.
+ * However, if we are unsuccessful at storing this
+ * route into the cache we really need to set it.
+ */
+ rt->dst.flags |= DST_NOCACHE;
+ if (!rt->rt_gateway)
+ rt->rt_gateway = daddr;
+ rt_add_uncached_list(rt);
+ }
+ } else
rt_add_uncached_list(rt);
#ifdef CONFIG_IP_ROUTE_CLASSID
@@ -1363,6 +1363,7 @@ static int ip_route_input_mc(struct sk_buff *skb, __be32 daddr, __be32 saddr,
rth->rt_iif = 0;
rth->rt_pmtu = 0;
rth->rt_gateway = 0;
+ rth->rt_uses_gateway = 0;
INIT_LIST_HEAD(&rth->rt_uncached);
if (our) {
rth->dst.input= ip_local_deliver;
@@ -1432,7 +1433,6 @@ static int __mkroute_input(struct sk_buff *skb,
return -EINVAL;
}
-
err = fib_validate_source(skb, saddr, daddr, tos, FIB_RES_OIF(*res),
in_dev->dev, in_dev, &itag);
if (err < 0) {
@@ -1488,6 +1488,7 @@ static int __mkroute_input(struct sk_buff *skb,
rth->rt_iif = 0;
rth->rt_pmtu = 0;
rth->rt_gateway = 0;
+ rth->rt_uses_gateway = 0;
INIT_LIST_HEAD(&rth->rt_uncached);
rth->dst.input = ip_forward;
@@ -1658,6 +1659,7 @@ local_input:
rth->rt_iif = 0;
rth->rt_pmtu = 0;
rth->rt_gateway = 0;
+ rth->rt_uses_gateway = 0;
INIT_LIST_HEAD(&rth->rt_uncached);
if (res.type == RTN_UNREACHABLE) {
rth->dst.input= ip_error;
@@ -1826,6 +1828,7 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
rth->rt_iif = orig_oif ? : 0;
rth->rt_pmtu = 0;
rth->rt_gateway = 0;
+ rth->rt_uses_gateway = 0;
INIT_LIST_HEAD(&rth->rt_uncached);
RT_CACHE_STAT_INC(out_slow_tot);
@@ -2104,6 +2107,7 @@ struct dst_entry *ipv4_blackhole_route(struct net *net, struct dst_entry *dst_or
rt->rt_flags = ort->rt_flags;
rt->rt_type = ort->rt_type;
rt->rt_gateway = ort->rt_gateway;
+ rt->rt_uses_gateway = ort->rt_uses_gateway;
INIT_LIST_HEAD(&rt->rt_uncached);
@@ -2182,7 +2186,7 @@ static int rt_fill_info(struct net *net, __be32 dst, __be32 src,
if (nla_put_be32(skb, RTA_PREFSRC, fl4->saddr))
goto nla_put_failure;
}
- if (rt->rt_gateway &&
+ if (rt->rt_uses_gateway &&
nla_put_be32(skb, RTA_GATEWAY, rt->rt_gateway))
goto nla_put_failure;
diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
index 681ea2f..05c5ab8 100644
--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@ -91,6 +91,7 @@ static int xfrm4_fill_dst(struct xfrm_dst *xdst, struct net_device *dev,
RTCF_LOCAL);
xdst->u.rt.rt_type = rt->rt_type;
xdst->u.rt.rt_gateway = rt->rt_gateway;
+ xdst->u.rt.rt_uses_gateway = rt->rt_uses_gateway;
xdst->u.rt.rt_pmtu = rt->rt_pmtu;
INIT_LIST_HEAD(&xdst->u.rt.rt_uncached);
--
1.7.3.4
^ permalink raw reply related
* [PATCH net v2 5/6] ipv4: Add FLOWI_FLAG_KNOWN_NH
From: Julian Anastasov @ 2012-10-08 21:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1349732480-19978-1-git-send-email-ja@ssi.bg>
Add flag to request that output route should be
returned with known rt_gateway, in case we want to use
it as nexthop for neighbour resolving.
The returned route can be cached as follows:
- in NH exception: because the cached routes are not shared
with other destinations
- in FIB NH: when using gateway because all destinations for
NH share same gateway
As last option, to return rt_gateway!=0 we have to
set DST_NOCACHE.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
include/net/flow.h | 1 +
net/ipv4/route.c | 21 +++++++++++++++++----
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/include/net/flow.h b/include/net/flow.h
index e1dd508..628e11b 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -21,6 +21,7 @@ struct flowi_common {
__u8 flowic_flags;
#define FLOWI_FLAG_ANYSRC 0x01
#define FLOWI_FLAG_CAN_SLEEP 0x02
+#define FLOWI_FLAG_KNOWN_NH 0x04
__u32 flowic_secid;
};
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index 3a116cb..1a0da8d 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1762,6 +1762,7 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
struct in_device *in_dev;
u16 type = res->type;
struct rtable *rth;
+ bool do_cache;
in_dev = __in_dev_get_rcu(dev_out);
if (!in_dev)
@@ -1798,24 +1799,36 @@ static struct rtable *__mkroute_output(const struct fib_result *res,
}
fnhe = NULL;
+ do_cache = fi != NULL;
if (fi) {
struct rtable __rcu **prth;
+ struct fib_nh *nh = &FIB_RES_NH(*res);
- fnhe = find_exception(&FIB_RES_NH(*res), fl4->daddr);
+ fnhe = find_exception(nh, fl4->daddr);
if (fnhe)
prth = &fnhe->fnhe_rth;
- else
- prth = __this_cpu_ptr(FIB_RES_NH(*res).nh_pcpu_rth_output);
+ else {
+ if (unlikely(fl4->flowi4_flags &
+ FLOWI_FLAG_KNOWN_NH &&
+ !(nh->nh_gw &&
+ nh->nh_scope == RT_SCOPE_LINK))) {
+ do_cache = false;
+ goto add;
+ }
+ prth = __this_cpu_ptr(nh->nh_pcpu_rth_output);
+ }
rth = rcu_dereference(*prth);
if (rt_cache_valid(rth)) {
dst_hold(&rth->dst);
return rth;
}
}
+
+add:
rth = rt_dst_alloc(dev_out,
IN_DEV_CONF_GET(in_dev, NOPOLICY),
IN_DEV_CONF_GET(in_dev, NOXFRM),
- fi);
+ do_cache);
if (!rth)
return ERR_PTR(-ENOBUFS);
--
1.7.3.4
^ permalink raw reply related
* [PATCH net v2 6/6] ipvs: fix ARP resolving for direct routing mode
From: Julian Anastasov @ 2012-10-08 21:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <1349732480-19978-1-git-send-email-ja@ssi.bg>
After the change "Make neigh lookups directly in output packet path"
(commit a263b30936) IPVS can not reach the real server for DR mode
because we resolve the destination address from IP header, not from
route neighbour. Use the new FLOWI_FLAG_KNOWN_NH flag to request
output routes with known nexthop, so that it has preference
on resolving.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/netfilter/ipvs/ip_vs_xmit.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
index 56f6d5d..cc4c809 100644
--- a/net/netfilter/ipvs/ip_vs_xmit.c
+++ b/net/netfilter/ipvs/ip_vs_xmit.c
@@ -50,6 +50,7 @@ enum {
* local
*/
IP_VS_RT_MODE_CONNECT = 8, /* Always bind route to saddr */
+ IP_VS_RT_MODE_KNOWN_NH = 16,/* Route via remote addr */
};
/*
@@ -113,6 +114,8 @@ static struct rtable *do_output_route4(struct net *net, __be32 daddr,
fl4.daddr = daddr;
fl4.saddr = (rt_mode & IP_VS_RT_MODE_CONNECT) ? *saddr : 0;
fl4.flowi4_tos = rtos;
+ fl4.flowi4_flags = (rt_mode & IP_VS_RT_MODE_KNOWN_NH) ?
+ FLOWI_FLAG_KNOWN_NH : 0;
retry:
rt = ip_route_output_key(net, &fl4);
@@ -1061,7 +1064,8 @@ ip_vs_dr_xmit(struct sk_buff *skb, struct ip_vs_conn *cp,
if (!(rt = __ip_vs_get_out_rt(skb, cp->dest, cp->daddr.ip,
RT_TOS(iph->tos),
IP_VS_RT_MODE_LOCAL |
- IP_VS_RT_MODE_NON_LOCAL, NULL)))
+ IP_VS_RT_MODE_NON_LOCAL |
+ IP_VS_RT_MODE_KNOWN_NH, NULL)))
goto tx_error_icmp;
if (rt->rt_flags & RTCF_LOCAL) {
ip_rt_put(rt);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH net v2 0/6] ipv4: Changes for rt_gateway
From: David Miller @ 2012-10-08 21:43 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <1349732480-19978-1-git-send-email-ja@ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Tue, 9 Oct 2012 00:41:14 +0300
> This patchset fixes some problems for the routing caused
> by the new rt_gateway semantics. What started as a fix for
> IPVS-DR ended as fixes for more problems. To solve the IPVS
> problem I decided to name the flag FLOWI_FLAG_KNOWN_NH, so that
> we can even get route cached in FNHE or FIB NH.
>
> Different flag FLOWI_FLAG_RT_NOCACHE could be equally good
> for IPVS, we again would be able to use data from fnhe but working
> with cached routes should be preferred. If there is no FNHE, the
> common case is IPVS to get uncached route, of course, IPVS caches
> it itself.
>
> Patches 1-3 are fixes not related to IPVS problem,
> 4 and 5 add code that will be used by IPVS in patch 6.
This series looks great, applied, thanks Julian.
^ permalink raw reply
* [PATCH] vxlan: fix more sparse warnings
From: Stephen Hemminger @ 2012-10-08 21:55 UTC (permalink / raw)
To: Fengguang Wu, David Miller; +Cc: kernel-janitors, netdev
In-Reply-To: <20121007123635.GB24374@localhost>
Fix a couple harmless sparse warnings reported by Fengguang Wu.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
Later patches will fix the other warnings as a side effect of more substantial
changes.
--- a/drivers/net/vxlan.c 2012-10-08 13:41:36.920210233 -0700
+++ b/drivers/net/vxlan.c 2012-10-08 13:44:05.630729809 -0700
@@ -1084,13 +1084,13 @@ static int vxlan_fill_info(struct sk_buf
if (nla_put_u32(skb, IFLA_VXLAN_ID, vxlan->vni))
goto nla_put_failure;
- if (vxlan->gaddr && nla_put_u32(skb, IFLA_VXLAN_GROUP, vxlan->gaddr))
+ if (vxlan->gaddr && nla_put_be32(skb, IFLA_VXLAN_GROUP, vxlan->gaddr))
goto nla_put_failure;
if (vxlan->link && nla_put_u32(skb, IFLA_VXLAN_LINK, vxlan->link))
goto nla_put_failure;
- if (vxlan->saddr && nla_put_u32(skb, IFLA_VXLAN_LOCAL, vxlan->saddr))
+ if (vxlan->saddr && nla_put_be32(skb, IFLA_VXLAN_LOCAL, vxlan->saddr))
goto nla_put_failure;
if (nla_put_u8(skb, IFLA_VXLAN_TTL, vxlan->ttl) ||
^ permalink raw reply
* Re: [PATCH] vxlan: fix more sparse warnings
From: David Miller @ 2012-10-08 21:58 UTC (permalink / raw)
To: shemminger; +Cc: fengguang.wu, kernel-janitors, netdev
In-Reply-To: <20121008145530.54a56962@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 8 Oct 2012 14:55:30 -0700
> Fix a couple harmless sparse warnings reported by Fengguang Wu.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied, thanks Stephen.
^ permalink raw reply
* Re: [PATCH] compat-drivers: update ethernet driver alx in crap dir
From: Luis R. Rodriguez @ 2012-10-08 22:25 UTC (permalink / raw)
To: xiong
Cc: mcgrof, backports, nic-devel, Ren Cloud, Greg Kroah-Hartman,
linux-kernel, netdev, linux-wireless, qca_vkondrat
In-Reply-To: <1349400892-25315-1-git-send-email-xiong@qca.qualcomm.com>
On Thu, Oct 4, 2012 at 6:34 PM, <xiong@qca.qualcomm.com> wrote:
> From: xiong <xiong@qca.qualcomm.com>
>
> 1. support new device id (0x10A0/0x10A1).
> 2. add DEBUG_FS interface for diag/swoi functions.
>
> Signed-off-by: Ren Cloud <cjren@qca.qualcomm.com>
> Signed-off-by: xiong <xiong@qca.qualcomm.com>
Xiong,
-- Vladimir, just a heads up -- this applies to you as well for the
802.11ad wil6210 driver
-- Greg, some review on your preference on this would be appreciated
The original alx crap patch was added into compat-wireless on the
linux-3.5.y branch. Its been two kernel releases and alx is not yet
upstream and users can only get alx via compat-drivers (technically
compat-wireless as that was pre v3.7). v3.7 would be the *third*
release in which this would happen... This is unfair to users and
consumers of the Linux kernel and derails expectations and our
arrangements for Linux kernel development. I realize that the goal was
to get alx upstream ASAP but regardless of what the reason is, its not
yet upstream. If you cannot work on alx on a timely manner to get
upstream then please submit the driver to the staging area of the
Linux kernel that Greg maintains so that other developers who may be
able to help can submit patches to help you. Under staging your driver
should be accepted so long as it compiles.
I will update the documentation for crap/ patches for compat-drivers
to make it clear now that crap/ patches can be used for adding
components / pieces of code not yet ready for upstream but as far as
full new drivers are concerned you only get one kernel release cycle
for it to linger on crap/ under compat-drivers, if you haven't
addressed upstreaming yet then it should go to drivers/staging/. That
is crap/ should only be used as a shortcut because users exist that
can use the driver but you *do* have a team properly resourced to
address upstreaming properly in a timely manner.
Linus should soon release v3.7-rc1 and new drivers are allowed to be
merged during the RC cycles, as such my recommendation is instead of
getting users to consume alx only through compat-drivers you now
submit alx into staging to Greg in hopes that we can get it into
v3.7-rcX some time, and at that time we can remove the crap/ patch
from compat-drivers.
Users should be able to consume new drivers through kernel.org and
compat-drivers should only provide
the framework for backporting and also categorizing quick fixes. It
should not be used for ongoing
updates for new drivers that users need.
We must draw the line with crap/ patches somewhere.
I'll then take this patch for now but do expect you to get alx into
either staging or proper upstream for the v3.7-rcX. I welcome feedback
from other folks on the proposed arrangement for crap/ patches for
compat-drivers.
https://backports.wiki.kernel.org/index.php/Documentation/compat-drivers/additional-patches#crap_patches
Luis
^ permalink raw reply
* [ANNOUNCE] libnetfilter_acct 1.0.1 release
From: Pablo Neira Ayuso @ 2012-10-08 22:49 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
Hi!
The Netfilter project proudly presents:
libnetfilter_acct 1.0.1
This release adds the new flag NFACCT_SNPRINTF_T_XML for
nfacct_snprintf and several cleanups.
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/libnetfilter_acct/downloads.html
ftp://ftp.netfilter.org/pub/libnetfilter_acct/
Have fun!
[-- Attachment #2: changes-libnetfilter_acct-1.0.1.txt --]
[-- Type: text/plain, Size: 317 bytes --]
Jan Engelhardt (1):
build: remove unnecessary pkgconfig->config.status dependency
Pablo Neira Ayuso (4):
src: NFACCT_SNPRINTF_T_XML flag for nfacct_snprintf to output time
build: bump version to 1.0.1
src: remove unnecessary castings
src: NFACCT_PKTS and NFACCT_BYTES are MNL_TYPE_U64
^ permalink raw reply
* Re: [GIT PULL nf-next] IPVS for 3.7 #2
From: Pablo Neira Ayuso @ 2012-10-08 23:17 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David Miller, Simon Horman, lvs-devel, netdev, netfilter-devel,
Wensong Zhang, Julian Anastasov, Hans Schillstrom,
Hans Schillstrom
In-Reply-To: <1349721865.22194.53.camel@localhost>
Hi Jesper,
On Mon, Oct 08, 2012 at 08:44:25PM +0200, Jesper Dangaard Brouer wrote:
> Hey Pablo,
>
> These changes were intended for 3.7, but just checked you git tree...
> and it looks like you didn't pull in Simon's changes, and thus they have
> not hit DaveM's tree for the merge window :-(
Sorry, you sent this pull request by friday 28/09. Net-next was closed
on tuesday 02/10. That was tight. I don't like to push things too hard
to David by last time.
My intention is still to pass this to net-next once it gets opened
again, of course. So don't worry, we still have the chance to get this
in.
I see at least one fix in this patchset, we can still pass it that to
3.7 if you want.
Let me know what you prefer.
> --Jesper
>
>
> On Fri, 2012-09-28 at 11:54 +0900, Simon Horman wrote:
> > Hi Pablo,
> >
> > please consider the following enhancements to IPVS for inclusion in 3.7.
> >
> > ----------------------------------------------------------------
> > The following changes since commit 82c93fcc2e1737fede2752520f1bf8f4de6304d8:
> >
> > x86: bpf_jit_comp: add XOR instruction for BPF JIT (2012-09-24 16:54:35 -0400)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git master
> >
> > for you to fetch changes up to 92eec78d25aee6bbc9bd295f51c022ddfa80cdd9:
> >
> > ipvs: SIP fragment handling (2012-09-28 11:37:16 +0900)
> >
> > ----------------------------------------------------------------
> > Jesper Dangaard Brouer (7):
> > ipvs: Trivial changes, use compressed IPv6 address in output
> > ipvs: IPv6 extend ICMPv6 handling for future types
> > ipvs: Use config macro IS_ENABLED()
> > ipvs: Fix faulty IPv6 extension header handling in IPVS
> > ipvs: Complete IPv6 fragment handling for IPVS
> > ipvs: API change to avoid rescan of IPv6 exthdr
> > ipvs: SIP fragment handling
> >
> > include/net/ip_vs.h | 194 +++++++++++----
> > net/netfilter/ipvs/Kconfig | 7 +-
> > net/netfilter/ipvs/ip_vs_conn.c | 15 +-
> > net/netfilter/ipvs/ip_vs_core.c | 404 +++++++++++++++++--------------
> > net/netfilter/ipvs/ip_vs_dh.c | 2 +-
> > net/netfilter/ipvs/ip_vs_lblc.c | 2 +-
> > net/netfilter/ipvs/ip_vs_lblcr.c | 2 +-
> > net/netfilter/ipvs/ip_vs_pe_sip.c | 18 +-
> > net/netfilter/ipvs/ip_vs_proto.c | 6 +-
> > net/netfilter/ipvs/ip_vs_proto_ah_esp.c | 9 +-
> > net/netfilter/ipvs/ip_vs_proto_sctp.c | 42 ++--
> > net/netfilter/ipvs/ip_vs_proto_tcp.c | 40 ++-
> > net/netfilter/ipvs/ip_vs_proto_udp.c | 41 ++--
> > net/netfilter/ipvs/ip_vs_sched.c | 2 +-
> > net/netfilter/ipvs/ip_vs_sh.c | 2 +-
> > net/netfilter/ipvs/ip_vs_xmit.c | 73 +++---
> > net/netfilter/xt_ipvs.c | 4 +-
> > 17 files changed, 501 insertions(+), 362 deletions(-)
>
>
^ permalink raw reply
* Re: [PATCH net] e1000e: Change wthresh to 1 to avoid possible Tx stalls.
From: Frank Reppin @ 2012-10-09 0:25 UTC (permalink / raw)
To: netdev
In-Reply-To: <1339044752.2075.14.camel@jtkirshe-mobl>
Jeff Kirsher <jeffrey.t.kirsher <at> intel.com> writes:
>
> On Thu, 2012-06-07 at 06:24 +0200, Eric Dumazet wrote:
> > On Wed, 2012-06-06 at 17:59 -0700, Jeff Kirsher wrote:
> >
> > > After further internal review, NACK.
> > >
> > > This patch will cause unacceptable performance issues with non-ESB2
> > > parts.
> > >
> > > I am dropping this patch from my queue.
> > >
> >
> > I'd like you share your performance numbers before NACKing this patch.
> >
> > What is the alternative patch you guys have ?
> >
>
> Jesse did not share any performance numbers with me, I am sure he can
> give some background tomorrow when he is back online.
>
> I am working on an alternative patch now and should have something to
> share tomorrow.
Please allow me to ask if there's any progess here?
I've tried 3.5.4 a couple of days ago on a SuperMicro X8SIE-LN4 (82574L)
and could still observe severe latency (up to 3000ms) spikes.
Applying Hiroakis suggested patch did fix this for me as well.
[please note as well that I didn't had this issue in any 3.4.x kernel
before - so +1 for fixing the regression]
Thankyou!
Frank Reppin
--
^ permalink raw reply
* Re: [PATCH] compat-drivers: update ethernet driver alx in crap dir
From: Greg Kroah-Hartman @ 2012-10-09 0:42 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: xiong-A+ZNKFmMK5xy9aJCnZT0Uw, mcgrof-DgEjT+Ai2ygdnm+yROfE0A,
backports-u79uwXL29TY76Z2rM5mHXA,
nic-devel-zC7DfRvBq/JWk0Htik3J/w, Ren Cloud,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-wireless,
qca_vkondrat-A+ZNKFmMK5xy9aJCnZT0Uw
In-Reply-To: <CAB=NE6VotAu-cugsn4==3TPX0OGPEFtdn1J+5+Rd_YfLcg9YDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Oct 08, 2012 at 03:25:08PM -0700, Luis R. Rodriguez wrote:
> On Thu, Oct 4, 2012 at 6:34 PM, <xiong-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org> wrote:
> > From: xiong <xiong-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
> >
> > 1. support new device id (0x10A0/0x10A1).
> > 2. add DEBUG_FS interface for diag/swoi functions.
> >
> > Signed-off-by: Ren Cloud <cjren-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
> > Signed-off-by: xiong <xiong-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
>
> Xiong,
>
> -- Vladimir, just a heads up -- this applies to you as well for the
> 802.11ad wil6210 driver
> -- Greg, some review on your preference on this would be appreciated
Preference on what? I've never seen this driver before, why wasn't it
submitted to be in the staging tree in the first place?
> The original alx crap patch was added into compat-wireless on the
> linux-3.5.y branch.
What is "crap patch"? And is this the old driver with the dubios
history keeping it from ever being merged anywhere, or is this something
new?
> Its been two kernel releases and alx is not yet
> upstream and users can only get alx via compat-drivers (technically
> compat-wireless as that was pre v3.7). v3.7 would be the *third*
> release in which this would happen... This is unfair to users and
> consumers of the Linux kernel and derails expectations and our
> arrangements for Linux kernel development. I realize that the goal was
> to get alx upstream ASAP but regardless of what the reason is, its not
> yet upstream. If you cannot work on alx on a timely manner to get
> upstream then please submit the driver to the staging area of the
> Linux kernel that Greg maintains so that other developers who may be
> able to help can submit patches to help you. Under staging your driver
> should be accepted so long as it compiles.
>
> I will update the documentation for crap/ patches for compat-drivers
> to make it clear now that crap/ patches can be used for adding
> components / pieces of code not yet ready for upstream but as far as
> full new drivers are concerned you only get one kernel release cycle
> for it to linger on crap/ under compat-drivers, if you haven't
> addressed upstreaming yet then it should go to drivers/staging/. That
> is crap/ should only be used as a shortcut because users exist that
> can use the driver but you *do* have a team properly resourced to
> address upstreaming properly in a timely manner.
Why do you even need crap/ at all? What is keeping drivers like this
(if it isn't the legally dubious driver) from being merged into staging
today? And if it is the legally dubious driver, well, you had better
not be taking it in your tree either...
confused,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] compat-drivers: update ethernet driver alx in crap dir
From: Luis R. Rodriguez @ 2012-10-09 1:14 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: xiong, mcgrof, backports, nic-devel, Ren Cloud, linux-kernel,
netdev, linux-wireless, qca_vkondrat
In-Reply-To: <20121009004209.GC9068@kroah.com>
On Mon, Oct 8, 2012 at 5:42 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Mon, Oct 08, 2012 at 03:25:08PM -0700, Luis R. Rodriguez wrote:
>> On Thu, Oct 4, 2012 at 6:34 PM, <xiong@qca.qualcomm.com> wrote:
>> > From: xiong <xiong@qca.qualcomm.com>
>> >
>> > 1. support new device id (0x10A0/0x10A1).
>> > 2. add DEBUG_FS interface for diag/swoi functions.
>> >
>> > Signed-off-by: Ren Cloud <cjren@qca.qualcomm.com>
>> > Signed-off-by: xiong <xiong@qca.qualcomm.com>
>>
>> Xiong,
>>
>> -- Vladimir, just a heads up -- this applies to you as well for the
>> 802.11ad wil6210 driver
>> -- Greg, some review on your preference on this would be appreciated
>
> Preference on what? I've never seen this driver before, why wasn't it
> submitted to be in the staging tree in the first place?
Because the goal was to jump straight to proper upstream and this was
expected to happen rather easily.
>> The original alx crap patch was added into compat-wireless on the
>> linux-3.5.y branch.
>
> What is "crap patch"? And is this the old driver with the dubios
> history keeping it from ever being merged anywhere, or is this something
> new?
The driver never had any legal dubious issues. The issues with the alx
driver were purely technical.
>> Its been two kernel releases and alx is not yet
>> upstream and users can only get alx via compat-drivers (technically
>> compat-wireless as that was pre v3.7). v3.7 would be the *third*
>> release in which this would happen... This is unfair to users and
>> consumers of the Linux kernel and derails expectations and our
>> arrangements for Linux kernel development. I realize that the goal was
>> to get alx upstream ASAP but regardless of what the reason is, its not
>> yet upstream. If you cannot work on alx on a timely manner to get
>> upstream then please submit the driver to the staging area of the
>> Linux kernel that Greg maintains so that other developers who may be
>> able to help can submit patches to help you. Under staging your driver
>> should be accepted so long as it compiles.
>>
>> I will update the documentation for crap/ patches for compat-drivers
>> to make it clear now that crap/ patches can be used for adding
>> components / pieces of code not yet ready for upstream but as far as
>> full new drivers are concerned you only get one kernel release cycle
>> for it to linger on crap/ under compat-drivers, if you haven't
>> addressed upstreaming yet then it should go to drivers/staging/. That
>> is crap/ should only be used as a shortcut because users exist that
>> can use the driver but you *do* have a team properly resourced to
>> address upstreaming properly in a timely manner.
>
> Why do you even need crap/ at all? What is keeping drivers like this
> (if it isn't the legally dubious driver) from being merged into staging
> today? And if it is the legally dubious driver, well, you had better
> not be taking it in your tree either...
crap/ was invented for patches to existing code that people wrote that
they for whatever reason did not think would ever get upstream but yet
they *needed* to support for customer deliveries. Consider a feature
that won't be acceptable but yet a customer *needs* today. In such
case we know the developer should post it as it will get rejected. The
developer may also know that they have to adjust the code to meet
upstream criteria, and they might do that in 1 or 2 future kernel
releases. Without having a mechanism to allow these type of patches
folks go on a forking bandwagon and at times creates a slippery slope
to never go back upstream.
crap/ then was used later for alx as a full driver rather than
drivers/staging/ given that the developers believed they could address
upstream concerns within a release cycle and they needed a release
ASAP. The alx driver needed to be changed to remove atl1c device
support as per review and only support new generation devices. It was
a lot easier for the developers to address that internally rather than
working on drivers/staging. In the end alx is still not upstream as
more technical issues have have not yet been addressed.
I'm considering perhaps just not allowing full drivers through crap/
on compat-drivers and simply having developers bite the bullet and
have to go through staging if they really need a release ASAP and are
not yet ready for upstream.
At this point I am revisiting the policy of when / if to allow drivers
at all through crap/ and that's what I was asking for review for.
Luis
^ permalink raw reply
* RE: [PATCH] compat-drivers: update ethernet driver alx in crap dir
From: Huang, Xiong @ 2012-10-09 1:24 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
backports-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, nic-devel,
Ren, Cloud, Greg Kroah-Hartman,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-wireless,
qca_vkondrat
In-Reply-To: <CAB=NE6VotAu-cugsn4==3TPX0OGPEFtdn1J+5+Rd_YfLcg9YDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Luis
I'm refining the code, I try my best to make it upstream ASAP. Thanks !
-Xiong
> -----Original Message-----
> From: mcgrof@gmail.com [mailto:mcgrof@gmail.com] On Behalf Of Luis R.
> Rodriguez
> Sent: Tuesday, October 09, 2012 6:25
> To: Huang, Xiong
> Cc: mcgrof@kernel.org; backports@vger.kernel.org; nic-devel; Ren, Cloud;
> Greg Kroah-Hartman; linux-kernel@vger.kernel.org; netdev@vger.kernel.org;
> linux-wireless; qca_vkondrat
> Subject: Re: [PATCH] compat-drivers: update ethernet driver alx in crap dir
>
> On Thu, Oct 4, 2012 at 6:34 PM, <xiong@qca.qualcomm.com> wrote:
> > From: xiong <xiong@qca.qualcomm.com>
> >
> > 1. support new device id (0x10A0/0x10A1).
> > 2. add DEBUG_FS interface for diag/swoi functions.
> >
> > Signed-off-by: Ren Cloud <cjren@qca.qualcomm.com>
> > Signed-off-by: xiong <xiong@qca.qualcomm.com>
>
> Xiong,
>
> -- Vladimir, just a heads up -- this applies to you as well for the 802.11ad
> wil6210 driver
> -- Greg, some review on your preference on this would be appreciated
>
> The original alx crap patch was added into compat-wireless on the linux-3.5.y
> branch. Its been two kernel releases and alx is not yet upstream and users can
> only get alx via compat-drivers (technically compat-wireless as that was pre
> v3.7). v3.7 would be the *third* release in which this would happen... This is
> unfair to users and consumers of the Linux kernel and derails expectations and
> our arrangements for Linux kernel development. I realize that the goal was to
> get alx upstream ASAP but regardless of what the reason is, its not yet
> upstream. If you cannot work on alx on a timely manner to get upstream then
> please submit the driver to the staging area of the Linux kernel that Greg
> maintains so that other developers who may be able to help can submit
> patches to help you. Under staging your driver should be accepted so long as it
> compiles.
>
> I will update the documentation for crap/ patches for compat-drivers to make
> it clear now that crap/ patches can be used for adding components / pieces of
> code not yet ready for upstream but as far as full new drivers are concerned
> you only get one kernel release cycle for it to linger on crap/ under compat-
> drivers, if you haven't addressed upstreaming yet then it should go to
> drivers/staging/. That is crap/ should only be used as a shortcut because users
> exist that can use the driver but you *do* have a team properly resourced to
> address upstreaming properly in a timely manner.
>
> Linus should soon release v3.7-rc1 and new drivers are allowed to be merged
> during the RC cycles, as such my recommendation is instead of getting users to
> consume alx only through compat-drivers you now submit alx into staging to
> Greg in hopes that we can get it into v3.7-rcX some time, and at that time we
> can remove the crap/ patch from compat-drivers.
>
> Users should be able to consume new drivers through kernel.org and compat-
> drivers should only provide the framework for backporting and also
> categorizing quick fixes. It should not be used for ongoing updates for new
> drivers that users need.
>
> We must draw the line with crap/ patches somewhere.
>
> I'll then take this patch for now but do expect you to get alx into either staging
> or proper upstream for the v3.7-rcX. I welcome feedback from other folks on
> the proposed arrangement for crap/ patches for compat-drivers.
>
> https://backports.wiki.kernel.org/index.php/Documentation/compat-
> drivers/additional-patches#crap_patches
>
> Luis
^ permalink raw reply
* Re: [PATCH 08/16] ipvs: fix ip_vs_set_timeout debug messages
From: Simon Horman @ 2012-10-09 1:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Julian Anastasov, Krzysztof Halasa, linux-arm-kernel,
linux-kernel, arm, David S. Miller, netdev, netfilter-devel,
netfilter, coreteam
In-Reply-To: <201210060954.15831.arnd@arndb.de>
On Sat, Oct 06, 2012 at 09:54:15AM +0000, Arnd Bergmann wrote:
> On Saturday 06 October 2012, Julian Anastasov wrote:
> > On Sat, 6 Oct 2012, Arnd Bergmann wrote:
> > > > Are there any CONFIG_IP_VS_PROTO_xxx options in this
> > > > default config? It is a waste of memory if IPVS is compiled
> > > > without any protocols.
> > >
> > > They all appear to be turned off:
> > >
> > > $ grep CONFIG_IP_VS obj-tmp/.config
> > > CONFIG_IP_VS=m
> > > CONFIG_IP_VS_DEBUG=y
> > > CONFIG_IP_VS_TAB_BITS=12
> > > # CONFIG_IP_VS_PROTO_TCP is not set
> > > # CONFIG_IP_VS_PROTO_UDP is not set
> > > # CONFIG_IP_VS_PROTO_AH_ESP is not set
> > > # CONFIG_IP_VS_PROTO_ESP is not set
> > > # CONFIG_IP_VS_PROTO_AH is not set
> > > # CONFIG_IP_VS_PROTO_SCTP is not set
> >
> > Something should be changed here, may be at least
> > TCP/UDP, who knows.
>
> I don't try to read too much into our defconfigs. We have 140 of them
> on ARM, and they are mainly useful to give a reasonable build coverage,
> but I wouldn't expect them to be actually used on that hardware.
>
> I'll leave it up to Krzysztof to send a patch for this if he wants.
>
> > > --- a/net/netfilter/ipvs/ip_vs_ctl.c
> > > +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> > > @@ -2590,6 +2588,7 @@ __ip_vs_get_timeouts(struct net *net, struct ip_vs_timeout_user *u)
> > > #if defined(CONFIG_IP_VS_PROTO_TCP) || defined(CONFIG_IP_VS_PROTO_UDP)
> > > struct ip_vs_proto_data *pd;
> > > #endif
> >
> > That is what we want. If you plan another submission
> > you can add empty line before this memset and to replace
> > the __ip_vs_get_timeouts call in ip_vs_genl_set_config with
> > memset but they are cosmetic changes. Or may be Simon will
> > take care about the coding style when applying the change.
> >
> > Acked-by: Julian Anastasov <ja@ssi.bg>
>
> I'd prefer Simon to pick up the patch. He should also decide whether he wants
> to add it to stable. In theory, this is a small leak of kernel stack data
> to user space, but as you say in practice it should not happen because it
> only exists for silly configurations that nobody should be using.
>
> AFAICT, removing the call to __ip_vs_get_timeouts in do_ip_vs_get_ctl would
> be a semantic change for the case where a user sends a IPVS_CMD_SET_CONFIG
> message without without the complete set of attributes inside it. The current
> behavior is to leave the timeouts alone, replacing the __ip_vs_get_timeouts
> with a memset would zero them. I left this part alone then.
>
> Arnd
Hi,
sorry for being a bit slow, it was a long weekend here.
This patch looks reasonable and I think it is appropriate for stable.
I'll see about getting it merged accordingly.
>
> 8<-----
> ipvs: initialize returned data in do_ip_vs_get_ctl
>
> As reported by a gcc warning, the do_ip_vs_get_ctl does not initalize
> all the members of the ip_vs_timeout_user structure it returns if
> at least one of the TCP or UDP protocols is disabled for ipvs.
>
> This makes sure that the data is always initialized, before it is
> returned as a response to IPVS_CMD_GET_CONFIG or printed as a
> debug message in IPVS_CMD_SET_CONFIG.
>
> Without this patch, building ARM ixp4xx_defconfig results in:
>
> net/netfilter/ipvs/ip_vs_ctl.c: In function 'ip_vs_genl_set_cmd':
> net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.udp_timeout' may be used uninitialized in this function [-Wuninitialized]
> net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.udp_timeout' was declared here
> net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_fin_timeout' may be used uninitialized in this function [-Wuninitialized]
> net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_fin_timeout' was declared here
> net/netfilter/ipvs/ip_vs_ctl.c:2238:47: warning: 't.tcp_timeout' may be used uninitialized in this function [-Wuninitialized]
> net/netfilter/ipvs/ip_vs_ctl.c:3322:28: note: 't.tcp_timeout' was declared here
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Julian Anastasov <ja@ssi.bg>
> ---
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 2770f85..c4ee437 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -2591,6 +2589,8 @@ __ip_vs_get_timeouts(struct net *net, struct ip_vs_timeout_user *u)
> struct ip_vs_proto_data *pd;
> #endif
>
> + memset(u, 0, sizeof (*u));
> +
> #ifdef CONFIG_IP_VS_PROTO_TCP
> pd = ip_vs_proto_data_get(net, IPPROTO_TCP);
> u->tcp_timeout = pd->timeout_table[IP_VS_TCP_S_ESTABLISHED] / HZ;
> @@ -2768,7 +2768,6 @@ do_ip_vs_get_ctl(struct sock *sk, int cmd, void __user *user, int *len)
> {
> struct ip_vs_timeout_user t;
>
> - memset(&t, 0, sizeof(t));
> __ip_vs_get_timeouts(net, &t);
> if (copy_to_user(user, &t, sizeof(t)) != 0)
> ret = -EFAULT;
>
^ 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;
as well as URLs for NNTP newsgroup(s).