From: Stanislav Kinsbursky <skinsbursky@parallels.com>
To: Simon Kirby <sim@hostway.ca>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: 3.3.0, 3.4-rc1 reproducible tun Oops
Date: Mon, 21 May 2012 18:51:32 +0400 [thread overview]
Message-ID: <4FBA5674.9050508@parallels.com> (raw)
In-Reply-To: <20120519010743.GA21427@hostway.ca>
On 19.05.2012 05:07, Simon Kirby wrote:
> On Wed, Apr 18, 2012 at 03:32:27PM +0400, Stanislav Kinsbursky wrote:
>
>> 17.04.2012 22:35, Simon Kirby ??????????:
>>> On Tue, Apr 17, 2012 at 04:18:53PM +0400, Stanislav Kinsbursky wrote:
>>>>
>>>> Hi, Simon.
>>>> Could you please try to apply the patch below on top of your the
>>>> tree (with 1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d applied) and
>>>> check does it fix the problem:
>>>>
>>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>>> index bb8c72c..1fc4622 100644
>>>> --- a/drivers/net/tun.c
>>>> +++ b/drivers/net/tun.c
>>>> @@ -1540,13 +1540,10 @@ static int tun_chr_close(struct inode
>>>> *inode, struct file *file)
>>>> if (dev->reg_state == NETREG_REGISTERED)
>>>> unregister_netdevice(dev);
>>>> rtnl_unlock();
>>>> - }
>>>> + } else
>>>> + sock_put(tun->socket.sk);
>>>> }
>>>>
>>>> - tun = tfile->tun;
>>>> - if (tun)
>>>> - sock_put(tun->socket.sk);
>>>> -
>>>> put_net(tfile->net);
>>>> kfree(tfile);
>>>
>>> (Whitespace-damaged patch, applied manually)
>>>
>>> Yes, I no longer see crashes with this applied. I haven't tried with
>>> kmemleak or similar, but it seems to work.
>>>
>>> Thanks,
>>>
>>
>> This bug looks like double free, but I can't understand how does this can happen...
>> Simon, would be really great, if you'll describe in details some
>> simple way, how to reproduce the bug.
>
> Oh, sorry, I did not see this until now. I just noticed it was still
> floating in my tree with no upstream changes yet, then found your email.
> I still have not seen any issues since applying your patch.
>
> I was definitely seeing the issue on 3.4-rc3. I can try and see if it
> still occurs with your patch removed, if that would help.
>
> Do you have a box on which you can set up an SSH tunnel? In my case, I
> can reproduce it easily with three boxes. From home, I run ssh to my work
> box to establish the layer 2 tunnel. This goes through a ProxyCommand to
> jump through an entry box, but I don't think that should matter. I use a
> cheap tunnel start script similar to this:
>
> work_net=10.0.0.0/8
> work_tun_ip=10.x.x.x
> home_tun_ip=10.x.x.x
> echo 1> /proc/sys/net/ipv4/conf/eth0/proxy_arp
> ssh -w any:any<work box> "ifconfig tun0 $work_tun_ip pointopoint
> $home_tun_ip; echo 'ifconfig tun0 $home_tun_ip pointopoint $work_tun_ip
> && ip route add $work_net via $work_tun_ip'; sleep 1d" | sh -v
>
> ...there's probably a better way, but it works. To reproduce, I log in
> to a third box over this tunnel, and start a "vmstat 1", so that packets
> keep coming back to the tunnel host. ^C on the SSH session will then
> produce an Oops within a second.
>
> With CONFIG_SLUB_DEBUG=y and booting with slub_debug=FZPU, I got the
> Redzone overwritten notice. Without it, the box usually Oopses and
> hangs immediately. Sometimes, I might have to reconnect the tunnel and
> ^C it once more. If I don't have that vmstat session open, it usually
> doesn't crash.
>
> Does this work for you?
>
Hello, Simon.
Thanks for details.
I still can't reproduce the issue.
Here is my configuration:
1) three nodes: A, B and C.
2) A and B connected with a tunnel (your script - slightly modified).
3) Packets to C from A are routed through the tunnel.
4) Node B has 3.4.0-rc2 based kernel. A and C - rhel6 kernel.
So, I login to C from A by ssh, run "vmstat 1" and then cut off (^C) the tunnel
between A and B. Connection hanged. No panic or oops occurred.
Is it the same you've done when panic occurred?
Or I'm doing something wrong?
> Simon-
--
Best regards,
Stanislav Kinsbursky
next prev parent reply other threads:[~2012-05-21 14:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-04 22:05 3.3.0, 3.4-rc1 reproducible tun Oops Simon Kirby
2012-04-05 2:41 ` Eric Dumazet
2012-04-05 5:58 ` Simon Kirby
2012-04-17 2:08 ` Simon Kirby
2012-04-17 12:18 ` Stanislav Kinsbursky
2012-04-17 18:35 ` Simon Kirby
2012-04-17 18:49 ` Stanislav Kinsbursky
2012-04-18 2:38 ` David Miller
2012-04-18 11:32 ` Stanislav Kinsbursky
2012-05-19 1:07 ` Simon Kirby
2012-05-21 14:51 ` Stanislav Kinsbursky [this message]
2012-04-18 6:51 Stanislav Kinsbursky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FBA5674.9050508@parallels.com \
--to=skinsbursky@parallels.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sim@hostway.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).