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
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.
Here's some interesting comment quote first from d_obtain_alias:
> * Cluster
23 matches
Mail list logo
