Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1197964
| From | Dominique Martinet <asmadeus@codewreck.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: v4.2-rc dcache regression, probably 75a6f82a0d10 |
| Date | 2015-08-01 12:20 +0200 |
| Message-ID | <pSC3v-1Jd-9@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <pSnxw-5Mb-1@gated-at.bofh.it> <pSotC-78K-71@gated-at.bofh.it> <pSpzl-hg-25@gated-at.bofh.it> <pSrrs-32C-7@gated-at.bofh.it> <pSzp0-6i2-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Al Viro wrote on Sat, Aug 01, 2015:
> And that has turned the check done to an inode that *was* ours at some
> point (i.e. fetching it had been followed by checking that ->d_seq had
> been still valid) into something completely unprotected. Suppose we
> are in lazy mode and somebody had evicted nd->path.dentry after we'd looked
> it up and before that check. Sure, its ->d_seq had been bumped by that,
> and we would've failed anyway. With ECHILD. Which, unlike ENOTDIR, is
> "repeat in non-lazy mode".
That sounds like a good find, I was looking at how to claim/protect the
entry somehow as well but I just have no idea...
> Folks, could you check if this fixes the problems you are seeing?
>
> diff --git a/fs/namei.c b/fs/namei.c
> index ae4e4c1..b16c3a7 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1954,7 +1954,11 @@ OK:
> continue;
> }
> }
> - if (unlikely(!d_can_lookup(nd->path.dentry)))
> + if (unlikely(!d_can_lookup(nd->path.dentry))) {
> + if (nd->flags & LOOKUP_RCU) {
> + if (unlazy_walk(nd, NULL, 0))
> + return -ECHILD;
> + }
> return -ENOTDIR;
> }
> }
Unfortunately, still happens for me.
I had to adapt a bit because using an old kernel (4bf46a272), will try
again with a recent master to doublecheck, but I had a break on
the "if (nd->flags & LOOKUP_RCU)" check:
- sometimes fails without ever hitting the check. I think this fixes
the "ENOTDIR" I had described, but there's at least another way to
fail?
- When we do hit it, we're into LOOKUP_RCU at this point alright,
unlazy_walk fails and we try again without RCU -- can confirm the
recovery process goes OK (well, that it went OK at least once)
Thanks,
--
Dominique
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: v4.2-rc dcache regression, probably 75a6f82a0d10 Dominique Martinet <asmadeus@codewreck.org> - 2015-08-01 12:20 +0200 Re: v4.2-rc dcache regression, probably 75a6f82a0d10 Dominique Martinet <asmadeus@codewreck.org> - 2015-08-01 13:00 +0200
csiph-web