This is a note to let you know that I've just added the patch titled
block: avoid using uninitialized value in from queue_var_store
to the 3.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
block-avoid-using-uninitialized-value-in-from-queue_var_store.patch
and it can be found in the queue-3.0 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From c678ef5286ddb5cf70384ad5af286b0afc9b73e1 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <[email protected]>
Date: Wed, 3 Apr 2013 21:53:57 +0200
Subject: block: avoid using uninitialized value in from queue_var_store
From: Arnd Bergmann <[email protected]>
commit c678ef5286ddb5cf70384ad5af286b0afc9b73e1 upstream.
As found by gcc-4.8, the QUEUE_SYSFS_BIT_FNS macro creates functions
that use a value generated by queue_var_store independent of whether
that value was set or not.
block/blk-sysfs.c: In function 'queue_store_nonrot':
block/blk-sysfs.c:244:385: warning: 'val' may be used uninitialized in this
function [-Wmaybe-uninitialized]
Unlike most other such warnings, this one is not a false positive,
writing any non-number string into the sysfs files indeed has
an undefined result, rather than returning an error.
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
block/blk-sysfs.c | 2 ++
1 file changed, 2 insertions(+)
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -200,6 +200,8 @@ queue_store_##name(struct request_queue
unsigned long val; \
ssize_t ret; \
ret = queue_var_store(&val, page, count); \
+ if (ret < 0) \
+ return ret; \
if (neg) \
val = !val; \
\
Patches currently in stable-queue which might be from [email protected] are
queue-3.0/block-avoid-using-uninitialized-value-in-from-queue_var_store.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
