In trying to reproduce another bug, I managed to uncover a memory leak in
autofs.  The test case is as follows:

setup autofs with a timeout of 1 second
run the following shell script in two xterms:

#!/bin/sh
while true; do
        for n in `seq 1 48`; do
                ls /test/$n
        done
        sleep 2
done

watch the size-256 slab cache grow

Within 4 minutes, I had the size-256 cache grow to 384k.  With the patched
kernel, size-256 remained at 75 for 45 minutes (so far).

It's a fairly straight-forward fix.  If there are multiple events for a
single path, say two processes doing an ls of a not-yet-mounted directory,
then they will share a wait queue.  from fs/autofs4/waitq.c:autofs4_wait

	name = kmalloc(NAME_MAX + 1, GFP_KERNEL);
	if (!name)
		return -ENOMEM;
	...

	if ( !wq ) {
		/* Create a new wait queue */
		wq = kmalloc(sizeof(struct autofs_wait_queue), GFP_KERNEL);
		if ( !wq ) {
			kfree(name);
			up(&sbi->wq_sem);
			return -ENOMEM;
		}
		...
		wq->name = name;

		...
	} else {
		atomic_inc(&wq->wait_ctr);
		up(&sbi->wq_sem);
		...
       }

In the else clause, we forget to free the name we kmalloc'd above.  This is
pretty easy to trigger, and could be considered a DOS, I think.  Note that
the default timeout for automount is 60 seconds.  As such, it would take
quite some time to render a system useless in this manner.

-Jeff



--- linux-2.4.21/fs/autofs4/waitq.c.orig
+++ linux-2.4.21/fs/autofs4/waitq.c
@@ -226,6 +226,7 @@ int autofs4_wait(struct autofs_sb_info *
 	} else {
 		atomic_inc(&wq->wait_ctr);
 		up(&sbi->wq_sem);
+		kfree(name);
 		DPRINTK(("autofs4_wait: existing wait id = 0x%08lx, name = %.*s, nfy=%d\n",
 			(unsigned long) wq->wait_queue_token, wq->len, wq->name, notify));
 	}