Hi Al,
On Fri, Nov 30, 2018 at 04:32:28PM +, Will Deacon wrote:
> On Fri, Nov 30, 2018 at 04:08:52PM +, Al Viro wrote:
> > On Fri, Nov 30, 2018 at 09:16:49AM -0600, Eric W. Biederman wrote:
> > > >> > + inode_lock(parent->d_inode);
> > > >> > dentry->d_fsdata = NULL;
> > > >>
On Fri, Nov 30, 2018 at 04:08:52PM +, Al Viro wrote:
> On Fri, Nov 30, 2018 at 09:16:49AM -0600, Eric W. Biederman wrote:
> > >> > + inode_lock(parent->d_inode);
> > >> > dentry->d_fsdata = NULL;
> > >> > drop_nlink(dentry->d_inode);
> > >> > d_delete(dentry);
> >
On Fri, Nov 30, 2018 at 09:16:49AM -0600, Eric W. Biederman wrote:
> >> > + inode_lock(parent->d_inode);
> >> > dentry->d_fsdata = NULL;
> >> > drop_nlink(dentry->d_inode);
> >> > d_delete(dentry);
> >> > + inode_unlock(parent->d_inode);
> >> > +
> >> > d
"gre...@linuxfoundation.org" writes:
> Adding Eric as he touched this code last :)
>
> On Thu, Nov 29, 2018 at 07:25:48PM +, Jan Glauber wrote:
>> On Wed, Nov 28, 2018 at 08:08:06PM +, Will Deacon wrote:
>> > I spent some more time looking at this today...
>> >
>> > On Fri, Nov 23, 2018
Adding Eric as he touched this code last :)
On Thu, Nov 29, 2018 at 07:25:48PM +, Jan Glauber wrote:
> On Wed, Nov 28, 2018 at 08:08:06PM +, Will Deacon wrote:
> > I spent some more time looking at this today...
> >
> > On Fri, Nov 23, 2018 at 06:05:25PM +, Will Deacon wrote:
> > > Do
On Wed, Nov 28, 2018 at 08:08:06PM +, Will Deacon wrote:
> I spent some more time looking at this today...
>
> On Fri, Nov 23, 2018 at 06:05:25PM +, Will Deacon wrote:
> > Doing some more debugging, it looks like the usual failure case is where
> > one CPU clears the inode field in the den
I spent some more time looking at this today...
On Fri, Nov 23, 2018 at 06:05:25PM +, Will Deacon wrote:
> Doing some more debugging, it looks like the usual failure case is where
> one CPU clears the inode field in the dentry via:
>
> devpts_pty_kill()
> -> d_delete() /
Hi all,
I've now managed to reproduce this on x86 (log below) but I'm out of my
depth with this one. Looping in Greg and Jiri because I fear this is
specific to the pty code. Rest of the thread is here:
http://lkml.kernel.org/r/20181109143744.GA12128@hc
On Wed, Nov 21, 2018 at 01:19:06PM +,
On Tue, Nov 20, 2018 at 07:03:17PM +, Will Deacon wrote:
> On Tue, Nov 20, 2018 at 06:28:54PM +, Will Deacon wrote:
> > On Sat, Nov 10, 2018 at 11:17:03AM +, Jan Glauber wrote:
> > > On Fri, Nov 09, 2018 at 03:58:56PM +, Will Deacon wrote:
> > > > On Fri, Nov 09, 2018 at 02:37:51PM
On Tue, Nov 20, 2018 at 06:28:54PM +, Will Deacon wrote:
> On Sat, Nov 10, 2018 at 11:17:03AM +, Jan Glauber wrote:
> > On Fri, Nov 09, 2018 at 03:58:56PM +, Will Deacon wrote:
> > > On Fri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> > > > I'm seeing the following oops repro
On Sat, Nov 10, 2018 at 11:17:03AM +, Jan Glauber wrote:
> On Fri, Nov 09, 2018 at 03:58:56PM +, Will Deacon wrote:
> > On Fri, Nov 09, 2018 at 02:37:51PM +, Jan Glauber wrote:
> > > I'm seeing the following oops reproducible with upstream kernel on arm64
> > > (ThunderX2):
> >
> > [..
On Fri, Nov 09, 2018 at 03:58:56PM +, Will Deacon wrote:
> On Fri, Nov 09, 2018 at 02:37:51PM +, 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'. Th
On Fri, Nov 09, 2018 at 02:37:51PM +, 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
13 matches
Mail list logo
