Hi,
On 06/20/2016 10:08 AM, Al Viro wrote:
> On Mon, Jun 20, 2016 at 09:25:12AM -0400, Oleg Drokin wrote:
>> It looks like this patch was totally forgotten?
>> I don't see it in neither vfs nor nfs trees and yet it fixes a very easy to
>> cause
>> crash in nfs code. And I think it's unrelated to
> On Jun 20, 2016, at 11:43, Anna Schumaker wrote:
>
> Hi,
>
> On 06/20/2016 10:08 AM, Al Viro wrote:
>> On Mon, Jun 20, 2016 at 09:25:12AM -0400, Oleg Drokin wrote:
>>> It looks like this patch was totally forgotten?
>>> I don't see it in neither vfs nor nfs trees and yet it fixes a very easy
On Jun 20, 2016, at 11:43 AM, Anna Schumaker wrote:
> Hi,
>
> On 06/20/2016 10:08 AM, Al Viro wrote:
>> On Mon, Jun 20, 2016 at 09:25:12AM -0400, Oleg Drokin wrote:
>>> It looks like this patch was totally forgotten?
>>> I don't see it in neither vfs nor nfs trees and yet it fixes a very easy to
On Mon, Jun 20, 2016 at 02:54:36PM +, Trond Myklebust wrote:
>
> > On Jun 20, 2016, at 10:08, Al Viro wrote:
> >
> > On Mon, Jun 20, 2016 at 09:25:12AM -0400, Oleg Drokin wrote:
> >> It looks like this patch was totally forgotten?
> >> I don't see it in neither vfs nor nfs trees and yet it f
> On Jun 20, 2016, at 10:08, Al Viro wrote:
>
> On Mon, Jun 20, 2016 at 09:25:12AM -0400, Oleg Drokin wrote:
>> It looks like this patch was totally forgotten?
>> I don't see it in neither vfs nor nfs trees and yet it fixes a very easy to
>> cause
>> crash in nfs code. And I think it's unrelate
On Mon, Jun 20, 2016 at 09:25:12AM -0400, Oleg Drokin wrote:
> It looks like this patch was totally forgotten?
> I don't see it in neither vfs nor nfs trees and yet it fixes a very easy to
> cause
> crash in nfs code. And I think it's unrelated to the other parallel case too.
I assumed it would g
It looks like this patch was totally forgotten?
I don't see it in neither vfs nor nfs trees and yet it fixes a very easy to
cause
crash in nfs code. And I think it's unrelated to the other parallel case too.
On Jun 3, 2016, at 1:56 AM, Al Viro wrote:
> On Fri, Jun 03, 2016 at 12:58:10AM -0400, O
On Jun 9, 2016, at 9:33 PM, Oleg Drokin wrote:
>
> On Jun 6, 2016, at 7:36 PM, Oleg Drokin wrote:
>
>> Well, I have some bad news.
>>
>> This patch does not fix the issue 100% of the time apparently, I just hit it
>> again.
>
> Ok, so now finally a piece of good news.
> Whatever was causing
On Jun 6, 2016, at 7:36 PM, Oleg Drokin wrote:
> Well, I have some bad news.
>
> This patch does not fix the issue 100% of the time apparently, I just hit it
> again.
Ok, so now finally a piece of good news.
Whatever was causing this other much harder to hit crash is gone in -rc2, gone
are
so
Well, I have some bad news.
This patch does not fix the issue 100% of the time apparently, I just hit it
again.
Only this time it's much harder to trigger, but stack is the same
(looks a bit different due to a compiler change). Must be some much narrower
race now.
I still don't have a crashdum
On Fri, Jun 03, 2016 at 12:58:10AM -0400, Oleg Drokin wrote:
> This one cures the insta-crash I was having, and I see no other ill-effects
> so far.
OK... I can take it through vfs.git, but I think it'd be better off in
NFS tree. Is everyone OK with something like the following?
make nfs_atom
On Jun 3, 2016, at 12:26 AM, Al Viro wrote:
> On Thu, Jun 02, 2016 at 11:43:59PM -0400, Oleg Drokin wrote:
>
>>> Which of the call sites had that been and how does one reproduce that fun?
>>> If you feel that posting a reproducer in the open is a bad idea, just send
>>> it off-list...
>>
>> Thi
On Fri, Jun 03, 2016 at 05:42:53AM +0100, Al Viro wrote:
> On Fri, Jun 03, 2016 at 05:26:48AM +0100, Al Viro wrote:
>
> > Looks like the right thing to do would be to do d_drop() at no_open:,
> > just before we call nfs_lookup(). If not earlier, actually... How
> > about the following?
>
> A bi
On Fri, Jun 03, 2016 at 05:26:48AM +0100, Al Viro wrote:
> Looks like the right thing to do would be to do d_drop() at no_open:,
> just before we call nfs_lookup(). If not earlier, actually... How
> about the following?
A bit of rationale: dentry in question is negative and attempt to open
it h
On Thu, Jun 02, 2016 at 11:43:59PM -0400, Oleg Drokin wrote:
> > Which of the call sites had that been and how does one reproduce that fun?
> > If you feel that posting a reproducer in the open is a bad idea, just send
> > it off-list...
>
> This is fs/nfs/dir.c::nfs_lookup() right after no_entry
On Jun 2, 2016, at 11:37 PM, Al Viro wrote:
> On Thu, Jun 02, 2016 at 06:46:08PM -0400, Oleg Drokin wrote:
>> Hello!
>>
>> I just came across a bug (trying to run some Lustre test scripts against
>> NFS, while hunting for another nfsd bug)
>> that seems to be present since at least 2014 tha
On Fri, Jun 03, 2016 at 04:26:25AM +0100, Al Viro wrote:
> On Thu, Jun 02, 2016 at 08:54:06PM -0400, Oleg Drokin wrote:
>
> > > Al, I’ve been distracted by personal matters in the past 6 months. What
> > > is there to guarantee exclusion of the readdirplus dentry instantiation
> > > and the NFSv
On Thu, Jun 02, 2016 at 06:46:08PM -0400, Oleg Drokin wrote:
> Hello!
>
>I just came across a bug (trying to run some Lustre test scripts against
> NFS, while hunting for another nfsd bug)
>that seems to be present since at least 2014 that lets users crash nfs
> client locally.
> > * C
On Fri, Jun 03, 2016 at 12:44:51AM +, Trond Myklebust wrote:
> That would have to be a really tight race, since the code in
> _nfs4_open_and_get_state() currently reads:
>
> d_drop(dentry);
> alias = d_exact_alias(dentry, state->inode);
> if (!
On Thu, Jun 02, 2016 at 08:54:06PM -0400, Oleg Drokin wrote:
> > Al, I’ve been distracted by personal matters in the past 6 months. What is
> > there to guarantee exclusion of the readdirplus dentry instantiation and
> > the NFSv4 atomic open in the brave new world of VFS, June 2016 vintage?
d_
On Jun 2, 2016, at 8:44 PM, Trond Myklebust wrote:
> That would have to be a really tight race, since the code in
> _nfs4_open_and_get_state() currently reads:
>
> d_drop(dentry);
> alias = d_exact_alias(dentry, state->inode);
> if (!alias)
> alias = d_splice_alias(igrab(state->inode), dentry);
On 6/2/16, 18:46, "linux-nfs-ow...@vger.kernel.org on behalf of Oleg Drokin"
wrote:
>Hello!
>
> I just came across a bug (trying to run some Lustre test scripts against
> NFS, while hunting for another nfsd bug)
> that seems to be present since at least 2014 that lets users crash nfs
> c
22 matches
Mail list logo
