lkml.org 
[lkml]   [2013]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] autofs4 - fix device ioctl mount lookup
On Wed, Sep 04, 2013 at 02:03:02AM +0100, Al Viro wrote:

> Ewwww... NAK in that form. Just what will happen if the last component
> given to that sucker will be . or .., for starters? Or a symlink, with
> '/' added to it to force following the damn thing?

OK, in more details:
* we are changing a user-visible ABI here - kern_path() with
LOOKUP_FOLLOW had been there since the introduction of that misc
device (OK, it used to be path_lookup(), but that changes nothing).
IOW, we used to follow symlinks there, now we do not.
* pathname may end on more than one slash. Modified that
way, the code won't do anything good (not to mention that d_lookup()
on an empty string is an interesting torture test for fs/dcache.c;
probably you'll just find nothing, but normally the function is never
called with such arguments, so...). In any case it's an ABI change.
* pathname may end with something/. or something/..; again,
d_lookup() won't find you anything now, so we have an ABI change.

That aside, I'm really not happy with this kind of games; this stuff clearly
belongs in fs/namei.c where we can simply see the last component. Doing that
on the level of "let's scan the pathname for slashes, etc." is just plain
wrong. Let's step back for a minute here; what are you trying to do?
You have a pathname that should resolve to a mountpoint, without triggering
automount (or crossing into the mountpoint, for that matter) and you want
struct path for the bottom of that mount stack? Or is it something
completely different?


\
 
 \ /
  Last update: 2013-09-04 04:21    [W:1.198 / U:0.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site