From: Anders Blomdell <anders.blomdell@control.lth.se>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: bfields@fieldses.org, linux-nfs@vger.kernel.org
Subject: Re: NULL pointer dereference in nfs_delegation_find_inode
Date: Fri, 23 Oct 2015 14:28:58 +0200 [thread overview]
Message-ID: <562A280A.7070205@control.lth.se> (raw)
In-Reply-To: <20151023072827.2861dd75@tlielax.poochiereds.net>
On 2015-10-23 13:28, Jeff Layton wrote:
> On Fri, 23 Oct 2015 10:00:51 +0200
> Anders Blomdell <anders.blomdell@control.lth.se> wrote:
>
>> We occasionally (about once every 2-4 weeks on 1 of a 100 machenes) get
>>
>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000548
>> IP: [<ffffffffa0651744>] nfs_delegation_find_inode+0x64/0x150 [nfsv4]
>>
>> the attached bug is from 4.1.8-100.fc21, but I have seen it on 4.1.5-100.fc21 as
>> well. Right now I have a realtime modified (xenomai.org) 3.8.13 system that exhibits
>> the problem more frequently, and that leads me to belive that the problem is
>> a data race problem, and by instrumenting fs/nfs/delegation.c (3.8.13) to:
>>
>>
>> static struct inode *
>> nfs_delegation_find_inode_server(struct nfs_server *server,
>> const struct nfs_fh *fhandle)
>> {
>> struct nfs_delegation *delegation;
>> struct inode *res = NULL;
>>
>> printk(KERN_ERR "server = %p\n", server);
>> list_for_each_entry_rcu(delegation, &server->delegations, super_list) {
>> printk(KERN_ERR "delegation = %p\n", delegation);
>> printk(KERN_ERR "delegation->lock = %p\n", delegation->lock);
>> spin_lock(&delegation->lock);
>> printk(KERN_ERR "delegation->inode = %p\n", delegation->inode);
>> if (delegation->inode != NULL) {
>> printk(KERN_ERR "NFS_I(delegation->inode) = %p", NFS_I(delegation->inode));
>> printk(KERN_ERR "NFS_I(delegation->inode)->fh = %p", NFS_I(delegation->inode)->fh);
>> }
>> if (delegation->inode != NULL &&
>> nfs_compare_fh(fhandle, &NFS_I(delegation->inode)->fh) == 0) {
>> res = igrab(delegation->inode);
>> }
>> spin_unlock(&delegation->lock);
>> if (res != NULL)
>> break;
>> }
>> return res;
>> }
>>
>> the system dies with (delegation.c compiled with -O0):
>>
>> server = ffff8803dee58458
>> delegation = (null)
>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
>> IP: [<ffffffffa08924ae>] nfs_delegation_find_inode_server+0x80/0x1e0 [nfsv4]
>>
>> Anybody thet can give me a hint how to write a program that gives rise to multiple
>> delegations to further investigate this issue?
>>
>> Regards
>>
>> Anders Blomdell
>>
>
> Huh. That delegation pointer really never be NULL.
^should
> I'm unclear on how
> that could even happen in the context of a list_for_each_entry_rcu
> loop. Oh, but super_list is the first struct member in nfs_delegation
> so it probably means that server->delegations was NULL.
>
> Maybe this is a use-after free of some sort or there's a memory
> scribble involved?
That is my guess, and the realtime patch used probably makes the window of opportunity
much larger (since the bug happens every few hours instead of every few years on average).
> You might want to consider turning up some memory
> debugging options while reproducing this.
Any hints on what options? Could/should they beturned on for the NFS module only
Any hints of what file operations to use to force delegations to happen?
Regards
Anders Blomdell
--
Anders Blomdell Email: anders.blomdell@control.lth.se
Department of Automatic Control
Lund University Phone: +46 46 222 4625
P.O. Box 118 Fax: +46 46 138118
SE-221 00 Lund, Sweden
next prev parent reply other threads:[~2015-10-23 16:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-23 8:00 NULL pointer dereference in nfs_delegation_find_inode Anders Blomdell
2015-10-23 11:28 ` Jeff Layton
2015-10-23 12:28 ` Anders Blomdell [this message]
2015-10-23 19:17 ` Jeff Layton
2015-10-23 19:21 ` J. Bruce Fields
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=562A280A.7070205@control.lth.se \
--to=anders.blomdell@control.lth.se \
--cc=bfields@fieldses.org \
--cc=jlayton@poochiereds.net \
--cc=linux-nfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox