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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
