If 'down_read_trylock' fails we'll curently leak the memory allocated to 
'buffer'.
Fix the leak by simply kfree'ing 'buffer' before returning '-EDEADLK'.

Signed-off-by: Jesper Juhl <j...@chaosbits.net>
---
 .../lustre/lustre/libcfs/linux/linux-curproc.c     |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c 
b/drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c
index ea9e949..ecd031f 100644
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c
@@ -227,8 +227,10 @@ int cfs_get_environ(const char *key, char *value, int 
*val_len)
         * which is already holding mmap_sem for writes.  If some other
         * thread gets the write lock in the meantime, this thread will
         * block, but at least it won't deadlock on itself.  LU-1735 */
-       if (down_read_trylock(&mm->mmap_sem) == 0)
+       if (down_read_trylock(&mm->mmap_sem) == 0) {
+               kfree(buffer);
                return -EDEADLK;
+       }
        up_read(&mm->mmap_sem);
 
        addr = mm->env_start;
-- 
1.7.1


-- 
Jesper Juhl <j...@chaosbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to