linux-toradex.git/fs/autofs4, branch v2.6.27.23

[PATCH] fix ->llseek() for a bunch of directories

2008-08-25T05:18:09+00:00

Signed-off-by: Al Viro

autofs4: remove unused ioctls

2008-07-24T17:47:33+00:00

The ioctls AUTOFS_IOC_TOGGLEREGHOST and AUTOFS_IOC_ASKREGHOST were added
several years ago but what they were intended for has never been
implemented (as far as I'm aware noone uses them) so remove them.

Signed-off-by: Ian Kent 
Reviewed-by: Jeff Moyer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

autofs4: reorganize expire pending wait function calls

2008-07-24T17:47:32+00:00

This patch re-orgnirzes the checking for and waiting on active expires and
elininates redundant checks.

Signed-off-by: Ian Kent 
Cc: Jeff Moyer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

autofs4: fix direct mount pending expire race - correction

2008-07-24T17:47:32+00:00

Appologies, somehow I seem to have sent an out dated version of this
patch. Here is an additional patch that brings the patch up to date.

Signed-off-by: Ian Kent 
Cc: Jeff Moyer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

autofs4: fix direct mount pending expire race

2008-07-24T17:47:32+00:00

For direct and offset type mounts that are covered by another mount we
cannot check the AUTOFS_INF_EXPIRING flag during a path walk which leads
to lookups walking into an expiring mount while it is being expired.

For example, for the direct multi-mount map entry with a couple of
offsets:

/race/mm1  /      :/
           /om1   :/
           /om2   :/

an autofs trigger mount is mounted on /race/mm1 and when accessed it is
over mounted and trigger mounts made for /race/mm1/om1 and /race/mm1/om2.
So it isn't possible for path walks to see the expiring flag at all and
they happily walk into the file system while it is expiring.

When expiring these mounts follow_down() must stop at the autofs mount and
all processes must block in the ->follow_link() method (except the daemon)
until the expire is complete.  This is done by decrementing the d_mounted
field of the autofs trigger mount root dentry until the expire is
completed.  In ->follow_link() all processes wait on the expire and the
mount following is completed for the daemon until the expire is complete.

Signed-off-by: Ian Kent 
Cc: Jeff Moyer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

autofs4: fix indirect mount pending expire race

2008-07-24T17:47:32+00:00

The selection of a dentry for expiration and the setting of the
AUTOFS_INF_EXPIRING flag isn't done atomically which can lead to lookups
walking into an expiring mount.

What happens is that an expire is initiated by the daemon and a dentry is
selected for expire but, since there is no lock held between the selection
and setting of the expiring flag, a process may find the flag clear and
continue walking into the mount tree at the same time the daemon attempts
the expire it.

Signed-off-by: Ian Kent 
Reviewed-by: Jeff Moyer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

autofs4: fix pending checks

2008-07-24T17:47:32+00:00

There are two cases for which a dentry that has a pending mount request
does not wait for completion.  One is via autofs4_revalidate() and the
other via autofs4_follow_link().

In revalidate, after the mount point directory is created, but before the
mount is done, the check in try_to_fill_dentry() can can fail to send the
dentry to the wait queue since the dentry is positive and the lookup flags
may contain only LOOKUP_FOLLOW.  Although we don't trigger a mount for the
LOOKUP_FOLLOW flag, if ther's one pending we might as well wait and use
the mounted dentry for the lookup.

In autofs4_follow_link() the dentry is not checked to see if it is pending
so it may fail to call try_to_fill_dentry() and not wait for mount
completion.

A dentry that is pending must always be sent to the wait queue.

Signed-off-by: Ian Kent 
Reviewed-by: Jeff Moyer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

autofs4: cleanup redundant readir code

2008-07-24T17:47:32+00:00

The mount triggering functionality of readdir and related functions is no
longer used (and is quite broken as well).  The unused portions have been
removed.

Signed-off-by: Ian Kent 
Reviewed-by: Jeff Moyer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

autofs4: indirect dentry must almost always be positive

2008-07-24T17:47:32+00:00

We have been seeing mount requests comming to the automount daemon for
keys of the form "/" which are lookups for
invalid map keys.  But we can check for this in the kernel module and
return a fail immediately, without having to send a request to the daemon.

It is possible to recognise these requests are invalid based on whether
the request dentry is negative and its relation to the autofs file system
root.

For example, given the indirect multi-mount map entry:

idm1  \
    /mm1  :/
    /mm2  :/

For a request to mount idm1, IS_ROOT((idm1)->d_parent) will be always be
true and the dentry may be negative.  But directories idm1/mm1 and
idm1/mm2 will always be created as part of the mount request for idm1.  So
any mount request within idm1 itself must have a positive dentry otherwise
the map key is invalid.

In version 4 these multi-mount entries are all mounted and umounted as a
single request and in version 5 the directories idm1/mm1 and idm1/mm2 are
created and an autofs fs mounted on them to act as a mount trigger so the
above is also true.

This also holds true for the autofs version 4 pseudo direct mount feature.
 When this feature is used without the "--ghost" option automount(8) will
create internal submounts as we go down the map key paths which are
essentially normal indirect mounts for which the above holds.  If the
"--ghost" option is given the directories for map keys are created at
daemon startup so valid map entries correspond to postive dentries in the
autofs fs.

autofs version 5 direct mount maps are similar except that the IS_ROOT
check is not needed.  This has been addressed in a previous patch tittled
"autofs4 - detect invalid direct mount requests".

For example, given the direct multi-mount map entry:

/test/dm1  \
    /mm1  :/
    /mm2  :/

An autofs fs is mounted on /test/dm1 as a trigger mount and when a mount
is triggered for /test/dm1, the multi-mount offset directories
/test/dm1/mm1 and /test/dm1/mm2 are created and an autofs fs is mounted on
them to act as mount triggers.  So valid direct mount requests must always
have a positive dentry if they correspond to a valid map entry.

Signed-off-by: Ian Kent 
Acked-by: Jeff Moyer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

autofs4: detect invalid direct mount requests

2008-07-24T17:47:32+00:00

autofs v5 direct and offset mounts within an autofs filesystem are
triggered by existing autofs triger mounts so the mount point dentry must
be positive.  If the mount point dentry is negative then the trigger
doesn't exist so we can return fail immediately.

Signed-off-by: Ian Kent 
Cc: Jeff Moyer 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds