headers
Sasha Levin | 1 Apr 2012 01:26
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)

Permalink | Reply | 10 comments |
headers
Tetsuo Handa | 1 Apr 2012 05:21
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)

Permalink | Reply | 7 comments |
headers
Shmulik Ladkani | 1 Apr 2012 08:18
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.
Permalink | Reply | 2 comments |
headers
Eric Dumazet | 1 Apr 2012 09:03
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 ?
Permalink | Reply | 1 comment |
headers
Or Gerlitz | 1 Apr 2012 09:04
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.
Permalink | Reply | 3 comments |
headers
Shmulik Ladkani | 1 Apr 2012 09:28
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
Permalink | Reply | 0 comments |
headers
roy.qing.li | 1 Apr 2012 10:45
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
Permalink | Reply | 4 comments |
headers
Shmulik Ladkani | 1 Apr 2012 16:03
Picon

[PATCHv1] ipv6: Fix RTM_GETROUTE's interpretation of RTA_IIF to be consistent with ipv4

In IPv4, if an RTA_IIF attribute is specified within an RTM_GETROUTE
message, then a route is searched as if a packet was received on the
specified 'iif' interface.

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.

Fix 'inet6_rtm_getroute()' so that RTA_IIF is interpreted as "lookup a
route as if a packet was received on the specified interface", similar
to IPv4's 'inet_rtm_getroute()' interpretation.

Reported-by: Ami Koren <amikoren <at> yahoo.com>
Signed-off-by: Shmulik Ladkani <shmulik.ladkani <at> gmail.com>
---

Tested on v3.2.6. Patch applies to v3.3.

Few points to review:

1) An alternative: construction of an skb within 'inet6_rtm_getroute()'
   and then calling 'ip6_route_input()' with the skb as an argument.
   Thus, no need to split common code of 'ip6_route_input()'.
   Less elegant IMO.

2) Better name for the new common function 'ip6_route_input_lookup()'
   Will happily accept any better suggestions.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Changli Gao | 1 Apr 2012 17:04
Picon

[PATCH] netfilter: don't do window scaling for a picked up connection

For a picked up connection, the window scaling option is also lost, because this
option is only valid in SYN or SYN/ACK segments. We should remove the useless
expression to save the CPU power.

Signed-off-by: Changli Gao <xiaosuo <at> gmail.com>
---
 net/netfilter/nf_conntrack_proto_tcp.c |    1 -
 1 file changed, 1 deletion(-)
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index 361eade..22f0500 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
 <at>  <at>  -584,7 +584,6  <at>  <at>  static bool tcp_in_window(const struct nf_conn *ct,
 			 * Let's try to use the data from the packet.
 			 */
 			sender->td_end = end;
-			win <<= sender->td_scale;
 			sender->td_maxwin = (win == 0 ? 1 : win);
 			sender->td_maxend = end + sender->td_maxwin;
 			/*
Permalink | Reply | 2 comments |
headers
Richard Cochran | 1 Apr 2012 17:19
Picon
Gravatar

[PATCH V2 net-next 12/28] e100: Support the get_ts_info ethtool method.

Signed-off-by: Richard Cochran <richardcochran <at> gmail.com>
---
 drivers/net/ethernet/intel/e100.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/ethernet/intel/e100.c b/drivers/net/ethernet/intel/e100.c
index 8a1ba85..eb6b97d 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
 <at>  <at>  -2735,6 +2735,7  <at>  <at>  static const struct ethtool_ops e100_ethtool_ops = {
 	.set_phys_id		= e100_set_phys_id,
 	.get_ethtool_stats	= e100_get_ethtool_stats,
 	.get_sset_count		= e100_get_sset_count,
+	.get_ts_info		= ethtool_op_get_ts_info,
 };

 static int e100_do_ioctl(struct net_device *netdev, struct ifreq *ifr, int cmd)
--

-- 
1.7.2.5
Permalink | Reply | 0 comments |

Gmane