From: Jan Glauber <Jan.Glauber@cavium.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: dcache_readdir NULL inode oops
Date: Sat, 10 Nov 2018 11:17:03 +0000 [thread overview]
Message-ID: <20181110111656.GA16667@hc> (raw)
In-Reply-To: <20181109155856.GC2091@brain-police>
On Fri, Nov 09, 2018 at 03:58:56PM +0000, Will Deacon wrote:
> On Fri, Nov 09, 2018 at 02:37:51PM +0000, Jan Glauber wrote:
> > I'm seeing the following oops reproducible with upstream kernel on arm64
> > (ThunderX2):
>
> [...]
>
> > It happens after 1-3 hours of running 'stress-ng --dev 128'. This testcase
> > does a scandir of /dev and then calls random stuff like ioctl, lseek,
> > open/close etc. on the entries. I assume no files are deleted under /dev
> > during the testcase.
> >
> > The NULL pointer is the inode pointer of next. The next dentry->d_flags is
> > DCACHE_RCUACCESS when this happens.
> >
> > Any hints on how to further debug this?
>
> Can you reproduce the issue with vanilla -rc1 and do you have a "known good"
> kernel?
I can try out -rc1, but IIRC this wasn't bisectible as the bug was present at
least back to 4.14. I need to double check that as there were other issues
that are resolved now so I may confuse things here. I've defintely seen
the same bug with 4.18.
Unfortunately I lost access to the machine as our data center seems to be
moving currently so it might take some days until I can try -rc1.
thanks,
Jan
next prev parent reply other threads:[~2018-11-10 21:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-09 14:37 dcache_readdir NULL inode oops Jan Glauber
2018-11-09 15:58 ` Will Deacon
2018-11-10 11:17 ` Jan Glauber [this message]
2018-11-20 18:28 ` Will Deacon
2018-11-20 19:03 ` Will Deacon
2018-11-21 13:19 ` Jan Glauber
2018-11-23 18:05 ` Will Deacon
2018-11-28 20:08 ` Will Deacon
2018-11-29 19:25 ` Jan Glauber
2018-11-30 10:41 ` gregkh
2018-11-30 15:16 ` Eric W. Biederman
2018-11-30 16:08 ` Al Viro
2018-11-30 16:32 ` Will Deacon
2019-04-30 9:32 ` Jan Glauber
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=20181110111656.GA16667@hc \
--to=jan.glauber@cavium.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=will.deacon@arm.com \
/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.