From: Jeff Moyer There is a memory in the autofs4_wait function, if multiple processes are waiting on the same queue: 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 with the following reproducer: setup an automount map as follows: for n in `seq 1 48`; do echo "$n server:/export/$n" >> /etc/auto.test; done setup a master map entry to point at this: echo "/test /etc/auto.test --timeout=1" >> /etc/auto.master Now, assuming the nfs server was setup to export said directories, 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 and watch the size-256 slab cache grow Within 4 minutes, I had the size-256 cache grow to 384k. On a kernel with the below patch applied, the size-256 remained constant during an over-night run. Signed-off-by: Jeff Moyer Signed-off-by: Andrew Morton --- 25-akpm/fs/autofs4/waitq.c | 1 + 1 files changed, 1 insertion(+) diff -puN fs/autofs4/waitq.c~autofs4-patch-autofs4_wait-can-leak-memory fs/autofs4/waitq.c --- 25/fs/autofs4/waitq.c~autofs4-patch-autofs4_wait-can-leak-memory 2005-03-07 20:41:43.000000000 -0800 +++ 25-akpm/fs/autofs4/waitq.c 2005-03-07 20:41:43.000000000 -0800 @@ -224,6 +224,7 @@ int autofs4_wait(struct autofs_sb_info * } else { atomic_inc(&wq->wait_ctr); up(&sbi->wq_sem); + kfree(name); DPRINTK("existing wait id = 0x%08lx, name = %.*s, nfy=%d", (unsigned long) wq->wait_queue_token, wq->len, wq->name, notify); } _