* Re: [PATCH 01/11] vxge: enable rxhash
From: Jon Mason @ 2010-11-08 22:53 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, Sivakumar Subramani, Sreenivasa Honnur,
Ramkrishna Vepa
In-Reply-To: <20101108.124452.115944240.davem@davemloft.net>
On Mon, Nov 08, 2010 at 12:44:52PM -0800, David Miller wrote:
>
> This patch set doesn't apply at all to the current tree, please
> respin them, thanks.
When I sent out the series on Thursday, the tree did not have
"vxge: make functions local and remove dead code". When that patch
was originally released (Oct 15), I asked for it to not be included as
it would break soon-to-be-released patch series. I did not see any
e-mail afterward, so I assumed this was acceptable to you. We then
ran the driver though our internal tests to verify its functionality,
which would need to be re-done if the patches are respun.
I have a reworked version of that patch which can be applied after
this patch series. Is it acceptable to you to revert the commit,
apply the series, then apply the modified version of the "local
functions" patch? I have already sniff tested it on our hardware
without issues.
Thanks,
Jon
^ permalink raw reply
* [PATCH v2 2/2] ipv6: Warn users if maximum number of routes is reached.
From: Ben Greear @ 2010-11-08 22:33 UTC (permalink / raw)
To: netdev; +Cc: Ben Greear
This gives users at least some clue as to what the problem
might be and how to go about fixing it.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
v1 -> v2: Put warning in correct place.
:100644 100644 a275c6e... 9d9d0e9... M net/ipv6/route.c
net/ipv6/route.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index a275c6e..9d9d0e9 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -1941,8 +1941,12 @@ struct rt6_info *addrconf_dst_alloc(struct inet6_dev *idev,
struct rt6_info *rt = ip6_dst_alloc(&net->ipv6.ip6_dst_ops);
struct neighbour *neigh;
- if (rt == NULL)
+ if (rt == NULL) {
+ if (net_ratelimit())
+ pr_warning("IPv6: Maximum number of routes reached,"
+ " consider increasing route/max_size.\n");
return ERR_PTR(-ENOMEM);
+ }
dev_hold(net->loopback_dev);
in6_dev_hold(idev);
--
1.6.2.5
^ permalink raw reply related
* [PATCH] Fix header size check for GSO case in recvmsg (af_packet)
From: Mariusz Kozlowski @ 2010-11-08 21:58 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: David S. Miller, netdev, linux-kernel, Mariusz Kozlowski
Parameter 'len' is size_t type so it will never get negative.
Signed-off-by: Mariusz Kozlowski <mk@lab.zgora.pl>
---
net/packet/af_packet.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 3616f27..3451191 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1610,9 +1610,11 @@ static int packet_recvmsg(struct kiocb *iocb, struct socket *sock,
err = -EINVAL;
vnet_hdr_len = sizeof(vnet_hdr);
- if ((len -= vnet_hdr_len) < 0)
+ if (len < vnet_hdr_len)
goto out_free;
+ len -= vnet_hdr_len;
+
if (skb_is_gso(skb)) {
struct skb_shared_info *sinfo = skb_shinfo(skb);
--
1.7.0.4
^ permalink raw reply related
* GIT: net-next-2.6 is now active...
From: David Miller @ 2010-11-08 22:05 UTC (permalink / raw)
To: netdev
I've started the net-next-2.6 tree going, and I'll push
out the initial set of changes (the ones that actually
compile, grumble...) shortly.
I could have started things up last week, but with kernel
summit and LPC there just wasn't much time or justification.
Probably the most interesting thing in this initial set are
the AF_UNIX poll optimizations from Eric Dumazet.
^ permalink raw reply
* Re: [net-next PATCH 1/2] qlge: Add firmware info to ethtool get regs.
From: David Miller @ 2010-11-08 21:49 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev, jitendra.kalsaria, ying.lok
In-Reply-To: <20101108.134302.102548897.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 08 Nov 2010 13:43:02 -0800 (PST)
> From: Ron Mercer <ron.mercer@qlogic.com>
> Date: Wed, 27 Oct 2010 07:58:26 -0700
>
>> By default we add firmware information to ethtool get regs.
>> Optionally firmware info can instead be sent to log.
>>
>> Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
>
> Applied.
Nevermind, reverted, can you please more carefully build test
your changes?
drivers/net/qlge/qlge_mpi.c:90:12: error: static declaration of 'ql_soft_reset_mpi_risc' follows non-static declaration
drivers/net/qlge/qlge.h:2224:5: note: previous declaration of 'ql_soft_reset_mpi_risc' was here
The line that added the extern declaration to qlge.h seems to be completely
unrelated to the rest of the patch, as if it's a mis-commit or something
from another change you were working on.
^ permalink raw reply
* Re: [PATCH 2/2] af_unix: optimize unix_dgram_poll()
From: David Miller @ 2010-11-08 21:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, davidel, alban.crequy
In-Reply-To: <1288539505.2660.41.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 31 Oct 2010 16:38:25 +0100
> unix_dgram_poll() is pretty expensive to check POLLOUT status, because
> it has to lock the socket to get its peer, take a reference on the peer
> to check its receive queue status, and queue another poll_wait on
> peer_wait. This all can be avoided if the process calling
> unix_dgram_poll() is not interested in POLLOUT status. It makes
> unix_dgram_recvmsg() faster by not queueing irrelevant pollers in
> peer_wait.
>
> On a test program provided by Alan Crequy :
>
> Before:
>
> real 0m0.211s
> user 0m0.000s
> sys 0m0.208s
>
> After:
>
> real 0m0.044s
> user 0m0.000s
> sys 0m0.040s
>
> Suggested-by: Davide Libenzi <davidel@xmailserver.org>
> Reported-by: Alban Crequy <alban.crequy@collabora.co.uk>
> Acked-by: Davide Libenzi <davidel@xmailserver.org>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] af_unix: unix_write_space() use keyed wakeups
From: David Miller @ 2010-11-08 21:44 UTC (permalink / raw)
To: davidel
Cc: eric.dumazet, alban.crequy, shemminger, gorcunov, adobriyan,
netdev, linux-kernel, pauli.nieminen, rweikusat
In-Reply-To: <alpine.DEB.2.00.1010300759580.9195@localhost6.localdomain6>
From: Davide Libenzi <davidel@xmailserver.org>
Date: Sat, 30 Oct 2010 08:03:15 -0700 (PDT)
> On Sat, 30 Oct 2010, Eric Dumazet wrote:
>
>> This patch is a specialization of commit 37e5540b3c9d (epoll keyed
>> wakeups: make sockets use keyed wakeups).
>
> Whoops, I must have missed AF_UNIX :)
> Looks good to me.
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] af_unix: fix unix_dgram_poll() behavior for EPOLLOUT event
From: David Miller @ 2010-11-08 21:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: alban.crequy, netdev, davidel
In-Reply-To: <1288539383.2660.38.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 31 Oct 2010 16:36:23 +0100
> [PATCH 1/2] af_unix: fix unix_dgram_poll() behavior for EPOLLOUT event
>
> Alban Crequy reported a problem with connected dgram af_unix sockets and
> provided a test program. epoll() would miss to send an EPOLLOUT event
> when a thread unqueues a packet from the other peer, making its receive
> queue not full.
>
> This is because unix_dgram_poll() fails to call sock_poll_wait(file,
> &unix_sk(other)->peer_wait, wait);
> if the socket is not writeable at the time epoll_ctl(ADD) is called.
>
> We must call sock_poll_wait(), regardless of 'writable' status, so that
> epoll can be notified later of states changes.
>
> Misc: avoids testing twice (sk->sk_shutdown & RCV_SHUTDOWN)
>
> Reported-by: Alban Crequy <alban.crequy@collabora.co.uk>
> Cc: Davide Libenzi <davidel@xmailserver.org>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] decnet: RCU conversion and get rid of dev_base_lock
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: steve; +Cc: eric.dumazet, netdev
In-Reply-To: <1288360479.9016.35.camel@dolmen>
From: Steven Whitehouse <steve@chygwyn.com>
Date: Fri, 29 Oct 2010 14:54:39 +0100
> Hi,
>
> On Fri, 2010-10-29 at 15:09 +0200, Eric Dumazet wrote:
>> While tracking dev_base_lock users, I found decnet used it in
>> dnet_select_source(), but for a wrong purpose:
>>
>> Writers only hold RTNL, not dev_base_lock, so readers must use RCU if
>> they cannot use RTNL.
>>
>> Adds an rcu_head in struct dn_ifaddr and handle proper RCU management.
>>
>> Adds __rcu annotation in dn_route as well.
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> I've not tested this, but I've read through it all and it seems good to
> me.
>
> Acked-by: Steven Whitehouse <swhiteho@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] bonding: remove dev_base_lock use
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, fubar
In-Reply-To: <1288353166.2560.22.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 29 Oct 2010 13:52:46 +0200
> bond_info_seq_start() uses a read_lock(&dev_base_lock) to make sure
> device doesn’t disappear. Same goal can be achieved using RCU.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] aoe: remove dev_base_lock use from aoecmd_cfg_pkts()
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ecashin
In-Reply-To: <1288350929.2560.16.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 29 Oct 2010 13:15:29 +0200
> dev_base_lock is the legacy way to lock the device list, and is planned
> to disappear. (writers hold RTNL, readers hold RCU lock)
>
> Convert aoecmd_cfg_pkts() to RCU locking.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ks8851: suspend resume support
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: x0066660; +Cc: netdev
In-Reply-To: <27F9C60D11D683428E133F85D2BB4A530468882D59@dlee03.ent.ti.com>
From: "Arce, Abraham" <x0066660@ti.com>
Date: Thu, 28 Oct 2010 23:57:20 -0500
> Add suspend/resume support using default open/stop interface methods
> to do hardware dependant operations.
>
> On suspend, same low power state (soft power mode) will be kept, the
> following blocks will be disabled:
>
> - Internal PLL Clock
> - Tx/Rx PHY
> - MAC
> - SPI Interface
>
> Signed-off-by: Abraham Arce <x0066660@ti.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 2/2] qlge: Version change to v1.00.00.27
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev, jitendra.kalsaria, ying.lok
In-Reply-To: <1288191507-1994-2-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Wed, 27 Oct 2010 07:58:27 -0700
> Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 1/2] qlge: Add firmware info to ethtool get regs.
From: David Miller @ 2010-11-08 21:43 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev, jitendra.kalsaria, ying.lok
In-Reply-To: <1288191507-1994-1-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Wed, 27 Oct 2010 07:58:26 -0700
> By default we add firmware information to ethtool get regs.
> Optionally firmware info can instead be sent to log.
>
> Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Applied.
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Eric Dumazet @ 2010-11-08 21:40 UTC (permalink / raw)
To: Ben Greear; +Cc: NetDev
In-Reply-To: <4CD86B4D.6020406@candelatech.com>
Le lundi 08 novembre 2010 à 13:27 -0800, Ben Greear a écrit :
> On 11/08/2010 03:02 AM, Eric Dumazet wrote:
> > Le samedi 06 novembre 2010 à 10:08 -0700, Ben Greear a écrit :
> >
> >> At least I don't see any percpu dumps in dmesg. I vaguely remember
> >> someone posting some ipv6 address scalability patches some time back.
> >> I think they had to hack on /proc fs as well. I'll see if I can
> >> dig those up.
> >>
> >>> Make sure udev / hotplug is not the problem, if you create your devices
> >>> very fast.
> >>
> >> We can create the macvlans w/out problem, though I'm sure that could
> >> be sped up. The problem is when we try to add IPv6 addresses to
> >> them.
> >
> > I see. Did you check /proc/sys/net/ipv6/ tunables ?
> >
> > For example, I bet you need to make route/max_size a bigger value than
> > default (4096)
>
> I'm having a hard time figuring out how this actually causes something
> to fail.
>
> It seems that having max_size too small would cause the garbage collector
> logic to happen more often, but I don't see any place it actually
> removes or limits entries, and I can't find any other references to
> ip6_rt_max_size.
>
> I must just be missing something..so if you have any ideas where to
> look, I'd love to hear it!
>
ipv6_add_addr() calls addrconf_dst_alloc
addrconf_dst_alloc() calls dst_alloc
dst_alloc() calls ip6_dst_gc
ip6_dst_gc() calls fib6_run_gc
fib6_run_gc() calls icmp6_dst_gc
fib6_run_gc() calls fib6_clean_all
a bit later, we return to ipv6_add_addr() (line 644) with an error
You want to add a warning in net/ipv6/route.c, line 1949
Thanks
^ permalink raw reply
* Re: OOM when adding ipv6 route: How to make available more per-cpu memory?
From: Ben Greear @ 2010-11-08 21:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: NetDev
In-Reply-To: <1289214131.2820.187.camel@edumazet-laptop>
On 11/08/2010 03:02 AM, Eric Dumazet wrote:
> Le samedi 06 novembre 2010 à 10:08 -0700, Ben Greear a écrit :
>
>> At least I don't see any percpu dumps in dmesg. I vaguely remember
>> someone posting some ipv6 address scalability patches some time back.
>> I think they had to hack on /proc fs as well. I'll see if I can
>> dig those up.
>>
>>> Make sure udev / hotplug is not the problem, if you create your devices
>>> very fast.
>>
>> We can create the macvlans w/out problem, though I'm sure that could
>> be sped up. The problem is when we try to add IPv6 addresses to
>> them.
>
> I see. Did you check /proc/sys/net/ipv6/ tunables ?
>
> For example, I bet you need to make route/max_size a bigger value than
> default (4096)
I'm having a hard time figuring out how this actually causes something
to fail.
It seems that having max_size too small would cause the garbage collector
logic to happen more often, but I don't see any place it actually
removes or limits entries, and I can't find any other references to
ip6_rt_max_size.
I must just be missing something..so if you have any ideas where to
look, I'd love to hear it!
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2.6.36 stable] vlan: Avoid hwaccel vlan packets when vid not used.
From: David Miller @ 2010-11-08 21:26 UTC (permalink / raw)
To: jesse; +Cc: stable, netdev
In-Reply-To: <1289251381-6671-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Mon, 8 Nov 2010 13:23:01 -0800
> Normally hardware accelerated vlan packets are quickly dropped if
> there is no corresponding vlan device configured. The one exception
> is promiscuous mode, where we allow all of these packets through so
> they can be picked up by tcpdump. However, this behavior causes a
> crash if we actually try to receive these packets. This fixes that
> crash by ignoring packets with vids not corresponding to a configured
> device in the vlan hwaccel routines and then dropping them before they
> get to consumers in the network stack.
>
> This patch applies only to 2.6.36 stable. The problem was introduced
> in that release and is already fixed by larger changes to the vlan
> code in 2.6.37.
>
> Reported-by: Ben Greear <greearb@candelatech.com>
> Tested-by: Nikola Ciprich <extmaillist@linuxbox.cz>
> Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: 2.6.36 vlans & bridge crash - status?
From: Jesse Gross @ 2010-11-08 21:25 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: netdev list, nikola.ciprich
In-Reply-To: <20101106071115.GA3264@nik-comp.lan>
On Sat, Nov 6, 2010 at 12:11 AM, Nikola Ciprich <extmaillist@linuxbox.cz> wrote:
> Hello Jesse,
> It really fixes the problem, thanks!
> Was the patch submitted to Greg for 2.6.36.y ?
Thanks for testing. I've submitted it to stable now.
^ permalink raw reply
* [PATCH 2.6.36 stable] vlan: Avoid hwaccel vlan packets when vid not used.
From: Jesse Gross @ 2010-11-08 21:23 UTC (permalink / raw)
To: stable; +Cc: netdev, David Miller
Normally hardware accelerated vlan packets are quickly dropped if
there is no corresponding vlan device configured. The one exception
is promiscuous mode, where we allow all of these packets through so
they can be picked up by tcpdump. However, this behavior causes a
crash if we actually try to receive these packets. This fixes that
crash by ignoring packets with vids not corresponding to a configured
device in the vlan hwaccel routines and then dropping them before they
get to consumers in the network stack.
This patch applies only to 2.6.36 stable. The problem was introduced
in that release and is already fixed by larger changes to the vlan
code in 2.6.37.
Reported-by: Ben Greear <greearb@candelatech.com>
Tested-by: Nikola Ciprich <extmaillist@linuxbox.cz>
Signed-off-by: Jesse Gross <jesse@nicira.com>
---
net/8021q/vlan_core.c | 3 +++
net/core/dev.c | 13 +++++++++++++
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 0eb96f7..2dcff0b 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -43,6 +43,9 @@ int vlan_hwaccel_do_receive(struct sk_buff *skb)
struct net_device *dev = skb->dev;
struct vlan_rx_stats *rx_stats;
+ if (unlikely(!is_vlan_dev(dev)))
+ return 0;
+
skb->dev = vlan_dev_info(dev)->real_dev;
netif_nit_deliver(skb);
diff --git a/net/core/dev.c b/net/core/dev.c
index 660dd41..dd72996 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2891,6 +2891,19 @@ static int __netif_receive_skb(struct sk_buff *skb)
ncls:
#endif
+ /* If we got this far with a hardware accelerated VLAN tag, it means
+ * that we were put in promiscuous mode but nobody is interested in
+ * this vid. Drop the packet now to prevent it from getting propagated
+ * to other parts of the stack that won't know how to deal with packets
+ * tagged in this manner.
+ */
+ if (unlikely(vlan_tx_tag_present(skb))) {
+ if (pt_prev)
+ ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+ kfree_skb(skb);
+ goto out;
+ }
+
/* Handle special case of bridge or macvlan */
rx_handler = rcu_dereference(skb->dev->rx_handler);
if (rx_handler) {
--
1.7.1
^ permalink raw reply related
* Re: [RFC v2] ipvs: allow transmit of GRO aggregated skbs
From: Simon Horman @ 2010-11-08 21:22 UTC (permalink / raw)
To: Herbert Xu; +Cc: Julian Anastasov, lvs-devel, netdev
In-Reply-To: <20101108141955.GA31649@gondor.apana.org.au>
On Mon, Nov 08, 2010 at 10:19:55PM +0800, Herbert Xu wrote:
> On Mon, Nov 08, 2010 at 08:45:42PM +0900, Simon Horman wrote:
> >
> > > Yes, I think we should check for !skb_is_gso(skb)
> > > as it looks as correct check to avoid FRAG_NEEDED after GRO
> > > but lets wait for confirmation from Herbert Xu.
> >
> > Yes, lets try and get a word from Herbert Xu on this.
>
> Yes skb_is_gso(skb) is the best for now. It isn't 100% correct
> as we should still be checking that the gso_size is less than
> the MTU but we need to fix that elsewhere first.
Thanks Herbert.
^ permalink raw reply
* Re: [PATCH 2/2] IPv6: Warn users when route/max_entries is reached.
From: David Miller @ 2010-11-08 21:22 UTC (permalink / raw)
To: greearb; +Cc: netdev
In-Reply-To: <4CD86709.5090906@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
Date: Mon, 08 Nov 2010 13:09:29 -0800
> On 11/08/2010 11:13 AM, Ben Greear wrote:
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
...
> Please don't apply this. I mis-read this code and that warning
> is useless at best in this place.
Ok.
^ permalink raw reply
* [PATCH] inet: fix ip_mc_drop_socket()
From: Eric Dumazet @ 2010-11-08 21:15 UTC (permalink / raw)
To: Markus Trippelsdorf, David Miller
Cc: paulmck, Miles Lane, ilpo.jarvinen, LKML, Len Brown, netdev
In-Reply-To: <20101108205511.GB1585@arch.trippelsdorf.de>
Hmm, I believe I found the bug.
Thanks guys !
[PATCH] inet: fix ip_mc_drop_socket()
commit 8723e1b4ad9be4444 (inet: RCU changes in inetdev_by_index())
forgot one call site in ip_mc_drop_socket()
We should not decrease idev refcount after inetdev_by_index() call,
since refcount is not increased anymore.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Reported-by: Miles Lane <miles.lane@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/igmp.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index c8877c6..3c53c2d 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -2306,10 +2306,8 @@ void ip_mc_drop_socket(struct sock *sk)
in_dev = inetdev_by_index(net, iml->multi.imr_ifindex);
(void) ip_mc_leave_src(sk, iml, in_dev);
- if (in_dev != NULL) {
+ if (in_dev != NULL)
ip_mc_dec_group(in_dev, iml->multi.imr_multiaddr.s_addr);
- in_dev_put(in_dev);
- }
/* decrease mem now to avoid the memleak warning */
atomic_sub(sizeof(*iml), &sk->sk_omem_alloc);
call_rcu(&iml->rcu, ip_mc_socklist_reclaim);
^ permalink raw reply related
* Re: [PATCH 2/2] IPv6: Warn users when route/max_entries is reached.
From: Ben Greear @ 2010-11-08 21:09 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <1289243629-20789-2-git-send-email-greearb@candelatech.com>
On 11/08/2010 11:13 AM, Ben Greear wrote:
> Signed-off-by: Ben Greear<greearb@candelatech.com>
> ---
> :100644 100644 a275c6e... 348b34c... M net/ipv6/route.c
> net/ipv6/route.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index a275c6e..348b34c 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -1060,8 +1060,12 @@ static int ip6_dst_gc(struct dst_ops *ops)
> unsigned long rt_last_gc = net->ipv6.ip6_rt_last_gc;
>
> if (time_after(rt_last_gc + rt_min_interval, now)&&
> - atomic_read(&ops->entries)<= rt_max_size)
> + atomic_read(&ops->entries)<= rt_max_size) {
> + if (net_ratelimit())
> + pr_warning("IPv6: Maximum number of routes reached,"
> + " consider increasing route/max_size.\n");
> goto out;
> + }
>
> net->ipv6.ip6_rt_gc_expire++;
> fib6_run_gc(net->ipv6.ip6_rt_gc_expire, net);
Please don't apply this. I mis-read this code and that warning
is useless at best in this place.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: 2.6.37-rc1-git5 -- WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
From: Markus Trippelsdorf @ 2010-11-08 20:55 UTC (permalink / raw)
To: Eric Dumazet; +Cc: paulmck, Miles Lane, ilpo.jarvinen, LKML, Len Brown, netdev
In-Reply-To: <1289249191.2790.3.camel@edumazet-laptop>
On Mon, Nov 08, 2010 at 09:46:31PM +0100, Eric Dumazet wrote:
> Le lundi 08 novembre 2010 à 21:42 +0100, Markus Trippelsdorf a écrit :
> > On Mon, Nov 08, 2010 at 09:29:26PM +0100, Eric Dumazet wrote:
> > > Le lundi 08 novembre 2010 à 12:06 -0800, Paul E. McKenney a écrit :
> > > > On Mon, Nov 08, 2010 at 02:56:06PM -0500, Miles Lane wrote:
> > > > > WARNING: at net/ipv4/devinet.c:137 in_dev_finish_destroy+0x3d/0x6e()
> > > >
> > > > Ilpo, thoughts?
> > > >
> > >
> > > Hmm...
> > >
> > > WARN_ON(idev->mc_list);
> > >
> > > Might be a problem with refcounts somewhere...
> >
> > I have similar warnings in my logs, although its at
> > net/ipv4/devinet.c:136 in my case. Happened altogether three times in
> > the last few days and they all look the same:
> >
> > Nov 5 17:31:35 arch kernel: WARNING: at net/ipv4/devinet.c:136 in_dev_finish_destroy+0x5c/0x90()
> > Nov 5 17:31:35 arch kernel: Hardware name: System Product Name
> > Nov 5 17:31:35 arch kernel: Pid: 0, comm: kworker/0:1 Not tainted 2.6.37-rc1-00027-gff8b16d-dirty #4
> > Nov 5 17:31:35 arch kernel: Call Trace:
> > Nov 5 17:31:35 arch kernel: <IRQ> [<ffffffff8105c9f6>] ? warn_slowpath_common+0x76/0xc0
> > Nov 5 17:31:35 arch kernel: [<ffffffff8141889c>] ? in_dev_finish_destroy+0x5c/0x90
> > Nov 5 17:31:35 arch kernel: [<ffffffff813c49e8>] ? dst_destroy+0x68/0x120
> > Nov 5 17:31:35 arch kernel: [<ffffffff813e888f>] ? dst_rcu_free+0x1f/0x30
> > Nov 5 17:31:35 arch kernel: [<ffffffff81090e0c>] ? __rcu_process_callbacks+0xfc/0x2f0
> > Nov 5 17:31:35 arch kernel: [<ffffffff8109103f>] ? rcu_process_callbacks+0x3f/0x70
> > Nov 5 17:31:35 arch kernel: [<ffffffff810621bc>] ? __do_softirq+0x9c/0x120
> > Nov 5 17:31:35 arch kernel: [<ffffffff81030fc9>] ? timer_interrupt+0x19/0x30
> > Nov 5 17:31:35 arch kernel: [<ffffffff8102ea4c>] ? call_softirq+0x1c/0x30
> > Nov 5 17:31:35 arch kernel: [<ffffffff8103080d>] ? do_softirq+0x4d/0x80
> > Nov 5 17:31:35 arch kernel: [<ffffffff8106232d>] ? irq_exit+0x8d/0x90
> > Nov 5 17:31:35 arch kernel: [<ffffffff810306c7>] ? do_IRQ+0x67/0xe0
> > Nov 5 17:31:35 arch kernel: [<ffffffff8144a153>] ? ret_from_intr+0x0/0xa
> > Nov 5 17:31:35 arch kernel: <EOI> [<ffffffff81035ba0>] ? default_idle+0x20/0x40
> > Nov 5 17:31:35 arch kernel: [<ffffffff81035c12>] ? c1e_idle+0x52/0xf0
> > Nov 5 17:31:35 arch kernel: [<ffffffff8102c12c>] ? cpu_idle+0x4c/0xa0
> > Nov 5 17:31:35 arch kernel: ---[ end trace 143683935de8f41f ]---
> > Nov 5 17:31:35 arch kernel: Freeing alive in_device ffff88011ffba600
> >
>
> Hmm....
>
> Is commit 1f1b9c9990205759aae31b7734b0ede41a867f32 present in your
> kernel ? (fib: fib_result_assign() should not change fib refcounts)
Yes, the last warning happend today on the lastest git kernel (from today).
>
> Could you provide some information ?
>
> ifconfig -a
dummy0 Link encap:Ethernet HWaddr 76:FE:79:D4:80:DF
BROADCAST NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth0 Link encap:Ethernet HWaddr 00:08:54:36:F2:2F
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1492 Metric:1
RX packets:1945 errors:0 dropped:0 overruns:0 frame:0
TX packets:1450 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1910343 (1.8 Mb) TX bytes:177533 (173.3 Kb)
Interrupt:20 Base address:0x6c00
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:18321 errors:0 dropped:0 overruns:0 frame:0
TX packets:18321 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2200368 (2.0 Mb) TX bytes:2200368 (2.0 Mb)
> ip ro
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2
default via 192.168.1.1 dev eth0
--
Markus
^ permalink raw reply
* Re: [PATCH] via-rhine: hardware VLAN support
From: Jesse Gross @ 2010-11-08 20:53 UTC (permalink / raw)
To: Roger Luethi; +Cc: netdev, David S. Miller
In-Reply-To: <20101108162132.GA32728@core.hellgate.ch>
On Mon, Nov 8, 2010 at 8:21 AM, Roger Luethi <rl@hellgate.ch> wrote:
> On Fri, 05 Nov 2010 11:31:56 -0700, Jesse Gross wrote:
>> On Fri, Nov 5, 2010 at 3:43 AM, Roger Luethi <rl@hellgate.ch> wrote:
>> > This patch adds VLAN hardware support for Rhine chips.
>>
>> This uses the old interfaces for vlan acceleration. We're working to
>> switch drivers over to use the new methods and the old ones will be
>> going away in the future. It would be great if we can avoid adding
>> more code that uses those interfaces.
>
> Can you point me to a driver that has been switched to use the new methods
> already? Is there some other form of documentation?
bnx2 is an example of a driver that has been converted. The commit
that actually made the change was
7d0fd2117e3d0550d7987b3aff2bfbc0244cf7c6, which should highlight the
differences. A key point is that drivers should no longer reference
vlan groups at all.
^ 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