[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <DF4A1130-84CD-4083-92B4-6DEA2D633753@linuxhacker.ru>
Date: Sat, 4 Jun 2016 12:12:14 -0400
From: Oleg Drokin <green@...uxhacker.ru>
To: Al Viro <viro@...IV.linux.org.uk>
Cc: Jeff Layton <jlayton@...chiereds.net>,
"<linux-kernel@...r.kernel.org> Mailing List"
<linux-kernel@...r.kernel.org>,
"<linux-fsdevel@...r.kernel.org>" <linux-fsdevel@...r.kernel.org>,
linux-nfs@...r.kernel.org
Subject: Re: Dcache oops
On Jun 3, 2016, at 8:56 PM, Al Viro wrote:
> On Fri, Jun 03, 2016 at 07:58:37PM -0400, Oleg Drokin wrote:
>
>>> EOPENSTALE, that is... Oleg, could you check if the following works?
>>
>> Yes, this one lasted for an hour with no crashing, so it must be good.
>> Thanks.
>> (note, I am not equipped to verify correctness of NFS operations, though).
>
> I suspect that Jeff Layton might have relevant regression tests. Incidentally,
> we really need a consolidated regression testsuite, including the tests you'd
> been running. Right now there's some stuff in xfstests, LTP and cthon; if
> anything, this mess shows just why we need all of that and then some in
> a single place. Lustre stuff has caught a 3 years old NFS bug (missing
> d_drop() in nfs_atomic_open()) and a year-old bug in handling of EOPENSTALE
> retries on the last component of a trailing non-embedded symlink. Neither
> is hard to trigger; it's just that relevant tests hadn't been run on NFS,
> period.
BTW, the nets also have brought in another use after free in nfs4 state
tracking code (this is the one I was trying to hunt down from the start).
I'll submit a patch shortly.
And also there's a mysterious ext4 data corruption that I do not really fully
understand but only hit once so far.
Powered by blists - more mailing lists