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

autofs4 - fix missed case when changing to use struct path

2009-09-01T03:44:05+00:00

In the recent change by Al Viro that changes verious subsystems
to use "struct path" one case was missed in the autofs4 module
which causes mounts to no longer expire.

Signed-off-by: Ian Kent 
Signed-off-by: Linus Torvalds

headers: smp_lock.h redux

2009-07-12T19:22:34+00:00

* Remove smp_lock.h from files which don't need it (including some headers!)
* Add smp_lock.h to files which do need it
* Make smp_lock.h include conditional in hardirq.h
  It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT

  This will make hardirq.h inclusion cheaper for every PREEMPT=n config
  (which includes allmodconfig/allyesconfig, BTW)

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Linus Torvalds

switch follow_down()

2009-06-12T01:36:01+00:00

Signed-off-by: Al Viro

switch follow_up() to struct path

2009-06-12T01:36:00+00:00

Signed-off-by: Al Viro

Get rid of path_lookup in autofs4

2009-06-12T01:35:58+00:00

Signed-off-by: Al Viro

autofs4: remove hashed check in validate_wait()

2009-06-09T23:59:03+00:00

The recent ->lookup() deadlock correction required the directory inode
mutex to be dropped while waiting for expire completion.  We were
concerned about side effects from this change and one has been identified.

I saw several error messages.

They cause autofs to become quite confused and don't really point to the
actual problem.

Things like:

handle_packet_missing_direct:1376: can't find map entry for (43,1827932)

which is usually totally fatal (although in this case it wouldn't be
except that I treat is as such because it normally is).

do_mount_direct: direct trigger not valid or already mounted
/test/nested/g3c/s1/ss1

which is recoverable, however if this problem is at play it can cause
autofs to become quite confused as to the dependencies in the mount tree
because mount triggers end up mounted multiple times.  It's hard to
accurately check for this over mounting case and automount shouldn't need
to if the kernel module is doing its job.

There was one other message, similar in consequence of this last one but I
can't locate a log example just now.

When checking if a mount has already completed prior to adding a new mount
request to the wait queue we check if the dentry is hashed and, if so, if
it is a mount point.  But, if a mount successfully completed while we
slept on the wait queue mutex the dentry must exist for the mount to have
completed so the test is not really needed.

Mounts can also be done on top of a global root dentry, so for the above
case, where a mount request completes and the wait queue entry has already
been removed, the hashed test returning false can cause an incorrect
callback to the daemon.  Also, d_mountpoint() is not sufficient to check
if a mount has completed for the multi-mount case when we don't have a
real mount at the base of the tree.

Signed-off-by: Ian Kent 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

autofs4: fix incorrect return in autofs4_mount_busy()

2009-05-02T22:36:09+00:00

Fix an obvious incorrect return status in autofs4_mount_busy().

Signed-off-by: Ian Kent 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

autofs4: use memchr() in invalid_string()

2009-04-21T03:02:50+00:00

Signed-off-by: Al Viro

Fix AUTOFS_DEV_IOCTL_REQUESTER_CMD

2009-04-21T03:01:15+00:00

Missing conversion from kernel to userland dev_t; this sucker
breaks as soon as we get sufficiently many autofs mounts for
new_encode_dev(s_dev) != s_dev.

Note: this is the minimal fix.

Signed-off-by: Al Viro

autofs4: fix lookup deadlock

2009-04-01T15:59:23+00:00

A deadlock can occur when user space uses a signal (autofs version 4 uses
SIGCHLD for this) to effect expire completion.

The order of events is:

Expire process completes, but before being able to send SIGCHLD to it's parent
...

Another process walks onto a different mount point and drops the directory
inode semaphore prior to sending the request to the daemon as it must ...

A third process does an lstat on on the expired mount point causing it to wait
on expire completion (unfortunately) holding the directory semaphore.

The mount request then arrives at the daemon which does an lstat and,
deadlock.

For some time I was concerned about releasing the directory semaphore around
the expire wait in autofs4_lookup as well as for the mount call back.  I
finally realized that the last round of changes in this function made the
expiring dentry and the lookup dentry separate and distinct so the check and
possible wait can be done anywhere prior to the mount call back.  This patch
moves the check to just before the mount call back and inside the directory
inode mutex release.

Signed-off-by: Ian Kent 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds