linux-kernel - Re: Important for fs devs: rcu-walk merged upstream

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1PdfI0-0005U7-LU@pomaz-ex.szeredi.hu>
Date:	Fri, 14 Jan 2011 09:45:44 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Nick Piggin <npiggin@...il.com>
CC:	miklos@...redi.hu, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Important for fs devs: rcu-walk merged upstream

On Fri, 14 Jan 2011, Nick Piggin wrote:
> On Fri, Jan 14, 2011 at 3:18 AM, Miklos Szeredi <miklos@...redi.hu> wrote:
> > On Thu, 13 Jan 2011, Miklos Szeredi wrote:
> >> On Sat, 8 Jan 2011, Nick Piggin wrote:
> >> > The vfs-scale branch is now upstream. If you haven't
> >> > looked yet, your filesystem is likely to have been
> >> > touched, so check it out.
> >> >
> >> > Also look at Documentation/filesystems/porting and
> >> > path-lookup.txt.
> >> >
> >> > The dcache_lock stuff should have been all done for you
> >> > (for in-tree filesystems, I can help out of tree fses with
> >> > conversions there if you ping me offline).
> >> >
> >> > The rcu-walk stuff can be more tricky for your filesystem
> >> > to take advantage of.
> >> >
> >> > If you supply a .d_revalidate, .permission, or .check_acl,
> >> > then path walking is going to be slow and unscalable for
> >> > you.
> >> >
> >> > Out of tree filesystems: you _have_ to at least add a line
> >> > of code to the above functions in order to specify that
> >> > you don't want to participate in rcu-walk.
> >> >
> >> > Otherwise, you don't have to care about rcu-walk if you
> >> > have a legacy or special filesystem like configfs then I'd
> >> > advise against anything fancy. But if you have a
> >> > userbase and you expect them to actually do any path
> >> > lookups into your filesystem, please take a look.
> >>
> >> One other thing: I know ECHILD is safe since no sane filesystem will
> >> return it in its permission or revalidate callbacks, and even if it
> >> does that's just a loss of optimization.
> >
> > And it's not entirely safe either.  A fuse filesystem returning ECHILD
> > would make nameidata_dentry_drop_rcu() to BUG.  So some sort of errno
> > filter is necessary in the fuse kernel module.
> 
> Surely you'd need some filtering anyway? I don't think any function
> involving path lookup could sanely return -ECHILD.

No, but not filtering doesn't normally hurt.  And it's not quite
trivial deciding what should be allowed and what shoudln't, and the
filter would have to be updated for each addition of a new errno.  So
I'm not sure I want to go there.

> That said, it probably is a good idea to have a new errno.

Yeah, that makes the fitering much easier.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/