From: Ben Greear <greearb@candelatech.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev <netdev@vger.kernel.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
Date: Tue, 22 Jan 2013 23:14:52 -0800 [thread overview]
Message-ID: <50FF8DEC.9070901@candelatech.com> (raw)
In-Reply-To: <1358921493.12374.737.camel@edumazet-glaptop>
On 01/22/2013 10:11 PM, Eric Dumazet wrote:
> On Tue, 2013-01-22 at 18:32 -0800, Ben Greear wrote:
>
>> diff --git a/net/core/dst.c b/net/core/dst.c
>> index ee6153e..234b168 100644
>> --- a/net/core/dst.c
>> +++ b/net/core/dst.c
>> @@ -245,6 +245,7 @@ again:
>> dst->ops->destroy(dst);
>> if (dst->dev)
>> dev_put(dst->dev);
>> + dst->input = dst->output = 0xdeadbeef;
>> kmem_cache_free(dst->ops->kmem_cachep, dst);
>
> Great !
>
> You could comment the kmem_cache_free() as well to get better chances to
> hit the bug, and maybe start a bisection to find the faulty commit ?
I suspect the bug goes back at least as far as 3.3. And since
I need the NFS patches for this test case, bisecting will be pure hell.
I'll work on some more code instrumentation tomorrow.
One thing that came to mind while I was looking at the code today:
How are the non-ref-counted dst objects used safely? Any chance
that tearing down the IP protocol on a device (or deleting a device)
could delete a dst that is referenced by an skb (and thus crashes as
I see)?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
WARNING: multiple messages have this Message-ID (diff)
From: Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
To: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: netdev <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic.
Date: Tue, 22 Jan 2013 23:14:52 -0800 [thread overview]
Message-ID: <50FF8DEC.9070901@candelatech.com> (raw)
In-Reply-To: <1358921493.12374.737.camel@edumazet-glaptop>
On 01/22/2013 10:11 PM, Eric Dumazet wrote:
> On Tue, 2013-01-22 at 18:32 -0800, Ben Greear wrote:
>
>> diff --git a/net/core/dst.c b/net/core/dst.c
>> index ee6153e..234b168 100644
>> --- a/net/core/dst.c
>> +++ b/net/core/dst.c
>> @@ -245,6 +245,7 @@ again:
>> dst->ops->destroy(dst);
>> if (dst->dev)
>> dev_put(dst->dev);
>> + dst->input = dst->output = 0xdeadbeef;
>> kmem_cache_free(dst->ops->kmem_cachep, dst);
>
> Great !
>
> You could comment the kmem_cache_free() as well to get better chances to
> hit the bug, and maybe start a bisection to find the faulty commit ?
I suspect the bug goes back at least as far as 3.3. And since
I need the NFS patches for this test case, bisecting will be pure hell.
I'll work on some more code instrumentation tomorrow.
One thing that came to mind while I was looking at the code today:
How are the non-ref-counted dst objects used safely? Any chance
that tearing down the IP protocol on a device (or deleting a device)
could delete a dst that is referenced by an skb (and thus crashes as
I see)?
Thanks,
Ben
--
Ben Greear <greearb-my8/4N5VtI7c+919tysfdA@public.gmane.org>
Candela Technologies Inc http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-01-23 7:14 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-21 21:07 3.7.3+: Bad paging request in ip_rcv_finish while running NFS traffic Ben Greear
2013-01-21 21:07 ` Ben Greear
2013-01-22 0:32 ` Ben Greear
2013-01-22 4:40 ` Eric Dumazet
2013-01-22 5:57 ` Ben Greear
2013-01-22 5:57 ` Ben Greear
2013-01-22 17:08 ` Ben Greear
2013-01-22 17:08 ` Ben Greear
2013-01-22 17:17 ` Eric Dumazet
2013-01-22 17:17 ` Eric Dumazet
2013-01-22 17:26 ` Ben Greear
2013-01-22 17:26 ` Ben Greear
2013-01-22 17:26 ` Eric Dumazet
2013-01-22 22:18 ` Ben Greear
2013-01-22 22:18 ` Ben Greear
2013-01-23 2:32 ` Ben Greear
2013-01-23 2:32 ` Ben Greear
2013-01-23 6:11 ` Eric Dumazet
2013-01-23 7:14 ` Ben Greear [this message]
2013-01-23 7:14 ` Ben Greear
2013-01-23 13:35 ` Eric Dumazet
2013-01-23 13:35 ` Eric Dumazet
2013-01-23 18:15 ` Ben Greear
2013-01-23 18:15 ` Ben Greear
2013-01-23 21:43 ` Eric Dumazet
2013-01-23 14:42 ` Eric Dumazet
2013-01-23 14:42 ` Eric Dumazet
2013-01-23 21:53 ` Ben Greear
2013-01-23 21:53 ` Ben Greear
2013-01-23 23:55 ` Ben Greear
2013-01-23 23:55 ` Ben Greear
2013-01-24 0:01 ` Eric Dumazet
2013-01-24 0:01 ` Eric Dumazet
2013-01-24 0:13 ` Ben Greear
2013-01-24 0:13 ` Ben Greear
2013-01-24 0:23 ` Eric Dumazet
2013-01-24 0:23 ` Eric Dumazet
2013-01-24 0:38 ` Ben Greear
2013-01-24 0:45 ` Eric Dumazet
2013-01-24 0:51 ` Ben Greear
2013-01-24 1:00 ` Eric Dumazet
2013-01-24 1:06 ` Ben Greear
2013-01-24 1:10 ` Eric Dumazet
2013-01-24 1:45 ` Eric Dumazet
2013-01-24 4:26 ` Ben Greear
2013-01-24 5:39 ` Eric Dumazet
2013-01-24 20:03 ` Ben Greear
2013-01-24 20:59 ` Eric Dumazet
2013-01-24 21:01 ` Ben Greear
2013-01-25 17:44 ` [PATCH] net: loopback: fix a dst refcounting issue Eric Dumazet
2013-01-27 6:32 ` David Miller
2013-01-27 17:25 ` Eric Dumazet
2013-01-28 0:26 ` David Miller
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=50FF8DEC.9070901@candelatech.com \
--to=greearb@candelatech.com \
--cc=eric.dumazet@gmail.com \
--cc=linux-nfs@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.