Sasha Levin | 1 Apr 01:26 2012
Picon

Re: ipv6: tunnel: hang when destroying ipv6 tunnel

On Sat, Mar 31, 2012 at 11:43 PM, Sasha Levin <levinsasha928 <at> gmail.com> wrote:
> On Sat, Mar 31, 2012 at 11:34 PM, Oleg Nesterov <oleg <at> redhat.com> wrote:
>> On 03/31, Eric Dumazet wrote:
>>>
>>> On Sat, 2012-03-31 at 19:51 +0200, Sasha Levin wrote:
>>> > Hi all,
>>> >
>>> > It appears that a hang may occur when destroying an ipv6 tunnel, which
>>> > I've reproduced several times in a KVM vm.
>>
>> kernel version?
>
> latest linux-next
>
>>> > [ 1561.564172] INFO: task kworker/u:2:3140 blocked for more than 120 seconds.
>>
>> And nobody else?
>
> Some more messages follow a bit later which get stuck in vfs related code.
>
>> It would be nice to know what sysrq-t says, in particular the trace
>> of khelper thread is interesting.
>
> Sure, I'll get one when it happens again.

So here's the stack of the usermode thread:

[  336.614015] kworker/u:2     S ffff880062c13000  5176  4539   3031 0x00000000
[  336.614015]  ffff880062fb38d0 0000000000000082 ffff880062fb3860
0000000000000001
(Continue reading)

Indan Zupancic | 1 Apr 01:47 2012
Picon

Re: [PATCH] net: bpf_jit: fix BPF_S_ALU_AND_K compilation

On Sun, April 1, 2012 01:13, Greg KH wrote:
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
>
> </formletter>

Thanks for pointing that out. It won't happen again.

Greetings,

Indan

Tetsuo Handa | 1 Apr 05:21 2012
Picon

Re: ipv6: tunnel: hang when destroying ipv6 tunnel

Sasha Levin wrote:
> While it seems that 9p is the culprit, I have to point out that this
> bug is easily reproducible, and it happens each time due to a
> call_usermode_helper() call. Other than that 9p behaves perfectly and
> I'd assume that I'd be seeing other things break besides
> call_usermode_helper() related ones.

I think one of below two patches can catch the bug if this is a usermodehelper
related bug. Please try.

----- Patch 1 -----
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 01394b6..3e63319 100644
--- a/kernel/kmod.c
+++ b/kernel/kmod.c
 <at>  <at>  -571,7 +571,7  <at>  <at>  int call_usermodehelper_exec(struct subprocess_info *sub_info, int wait)
 	 * flag, for khelper thread is already waiting for the thread at
 	 * wait_for_completion() in do_fork().
 	 */
-	if (wait != UMH_NO_WAIT && current == kmod_thread_locker) {
+	if (WARN_ON(wait != UMH_NO_WAIT && current == kmod_thread_locker)) {
 		retval = -EBUSY;
 		goto out;
 	}

----- Patch 2 -----
diff --git a/include/linux/kmod.h b/include/linux/kmod.h
index 9efeae6..1350670 100644
--- a/include/linux/kmod.h
+++ b/include/linux/kmod.h
(Continue reading)

Eric Dumazet | 1 Apr 07:07 2012
Picon

Re: ipv6: tunnel: hang when destroying ipv6 tunnel

On Sun, 2012-04-01 at 01:26 +0200, Sasha Levin wrote:
> On Sat, Mar 31, 2012 at 11:43 PM, Sasha Levin <levinsasha928 <at> gmail.com> wrote:
> > On Sat, Mar 31, 2012 at 11:34 PM, Oleg Nesterov <oleg <at> redhat.com> wrote:
> >> On 03/31, Eric Dumazet wrote:
> >>>
> >>> On Sat, 2012-03-31 at 19:51 +0200, Sasha Levin wrote:
> >>> > Hi all,
> >>> >
> >>> > It appears that a hang may occur when destroying an ipv6 tunnel, which
> >>> > I've reproduced several times in a KVM vm.
> >>
> >> kernel version?
> >
> > latest linux-next
> >
> >>> > [ 1561.564172] INFO: task kworker/u:2:3140 blocked for more than 120 seconds.
> >>
> >> And nobody else?
> >
> > Some more messages follow a bit later which get stuck in vfs related code.
> >
> >> It would be nice to know what sysrq-t says, in particular the trace
> >> of khelper thread is interesting.
> >
> > Sure, I'll get one when it happens again.
> 
> So here's the stack of the usermode thread:
> 
> [  336.614015] kworker/u:2     S ffff880062c13000  5176  4539   3031 0x00000000
> [  336.614015]  ffff880062fb38d0 0000000000000082 ffff880062fb3860
(Continue reading)

Shmulik Ladkani | 1 Apr 08:18 2012
Picon

ipv6: RTM_GETROUTE inconsistent interpretation of RTA_IIF

(Bump)

Any reason not to submit a patch that fixes the below issue?

Regards,
Shmulik

On Thu, 29 Mar 2012 15:03:11 +0200 Shmulik Ladkani <shmulik.ladkani <at> gmail.com> wrote:
> Hi,
> 
> In IPv4, if the RTA_IIF attribute is specified in an RTM_GETROUTE
> message, then a route is searched as if a packet was received on the
> specified iif interface - i.e. 'inet_rtm_getroute()' calls
> 'ip_route_input()'.
> 
> However in IPv6, RTA_IIF is not interpreted in the same way:
> 'inet6_rtm_getroute()' always calls 'ip6_route_output()', regardless the
> RTA_IIF attribute.
> 
> As a result, in IPv6 there's no way to use RTM_GETROUTE in order to look
> for a route as if a packet was received on a specific interface.
> 
> I'd like to modify 'inet6_rtm_getroute()' so that RTA_IIF is interpreted
> in the same way as in IPv4's 'inet_rtm_getroute()'.
> 
> Before I come up with a patch, I'd like to know whether current
> interpretation of RTA_IIF in 'inet6_rtm_getroute()' is deliberate.
Eric Dumazet | 1 Apr 09:03 2012
Picon

Re: ipv6: RTM_GETROUTE inconsistent interpretation of RTA_IIF

On Sun, 2012-04-01 at 09:18 +0300, Shmulik Ladkani wrote:
> (Bump)
> 
> Any reason not to submit a patch that fixes the below issue?

Hi Shmulik

No reason I can think about. Are you planning to provide this yourself ?

Or Gerlitz | 1 Apr 09:04 2012
Picon

Re: [PATCH V4 8/8] net/mlx4_en: Set max rate-limit for a TC

On Fri, Mar 30, 2012 at 12:25 AM, David Miller <davem <at> davemloft.net> wrote:
>
> From: Amir Vadai <amirv <at> mellanox.com>
> Date: Thu, 29 Mar 2012 20:27:20 +0200
>
> > I was in a rush to send it on time and missed it (of course I tested
> > only tc 0 so didn't see it in my tests too).
>
> Being in a rush when you expect others to spend time reviewing your
> code is an extremely selfish act.

Hi Dave,

Yep, a mistake was done here, but as they say "only he who never does
never errs..."
so Amir will surely learn from that, and so am I - here wearing the
internal reviewer hat,
didn't review V4 deep enough. We spotted also some vzalloc calls in
the patches which
are under the HW QoS model debate and will fix there as well. V5 will
be also against
net-next but depending on your decision maybe it can still go to 3.4?

Or.
Shmulik Ladkani | 1 Apr 09:28 2012
Picon

Re: ipv6: RTM_GETROUTE inconsistent interpretation of RTA_IIF

On Sun, 01 Apr 2012 09:03:59 +0200 Eric Dumazet <eric.dumazet <at> gmail.com> wrote:
> On Sun, 2012-04-01 at 09:18 +0300, Shmulik Ladkani wrote:
> > (Bump)
> > 
> > Any reason not to submit a patch that fixes the below issue?
> 
> Hi Shmulik
> 
> No reason I can think about. Are you planning to provide this yourself ?

Yes.

Just wanted to make sure ipv6's RTA_IIF interpretation is not deliberate.

Regards,
Shmulik
Parav.Pandit | 1 Apr 10:36 2012

be2net: when can I expect roce support patch will be merged?

Hi,

Did you get chance to merge below be2net patch for supporing RoCE driver?
http://marc.info/?l=linux-rdma&m=133279326217836&w=2

Once this is done, Roland can merge ocrdma RoCE driver addition to his tree. This NIC driver patch is
required to merge ocrdma patch.
When can I expect this patch to be merged to net-next git tree?
Let me know if there any issue with the patch that I got to resolve.

Regards,
Parav Pandit

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

roy.qing.li | 1 Apr 10:45 2012
Picon

[PATCH] ipv6: fix array index in ip6_mc_add_src()

From: RongQing.Li <roy.qing.li <at> gmail.com>

Convert array index from the loop bound to the loop index.

Signed-off-by: RongQing.Li <roy.qing.li <at> gmail.com> 
---
 net/ipv6/mcast.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 16c33e3..c6378de 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
 <at>  <at>  -2044,7 +2044,7  <at>  <at>  static int ip6_mc_add_src(struct inet6_dev *idev, const struct in6_addr *pmca,
 		if (!delta)
 			pmc->mca_sfcount[sfmode]--;
 		for (j=0; j<i; j++)
-			(void) ip6_mc_del1_src(pmc, sfmode, &psfsrc[i]);
+			ip6_mc_del1_src(pmc, sfmode, &psfsrc[j]);
 	} else if (isexclude != (pmc->mca_sfcount[MCAST_EXCLUDE] != 0)) {
 		struct ip6_sf_list *psf;

--

-- 
1.7.1


Gmane