On 01/22/2014 01:51 AM, Andrew Morton wrote:
On Tue, 21 Jan 2014 17:00:00 +0530 Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx> wrote:
We could hit null pointer dereference error during alloc_page_buffers
in : (1) block size > PAGE_SIZE (2) low memory.
Add sanity check for that.
Signed-off-by: Raghavendra K T <raghavendra.kt@xxxxxxxxxxxxxxxxxx>
---
fs/block_dev.c | 1 +
fs/buffer.c | 6 ++++++
2 files changed, 7 insertions(+)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 1e86823..2481d42 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1027,6 +1027,7 @@ void bd_set_size(struct block_device *bdev, loff_t size)
break;
bsize <<= 1;
}
+ BUG_ON(bsize > PAGE_SIZE);
bdev->bd_block_size = bsize;
bdev->bd_inode->i_blkbits = blksize_bits(bsize);
}
alloc_page_buffers() will always return NULL if passed size >=
PAGE_SIZE. So if we're going to add a check, it would be better to add
it to alloc_page_buffers() because that will catch errors from the
widest range of callsites.
In that case how about converting BUG_ON to setting a default value of
PAGE_SIZE for bs in bd_set_size() itself (with a warning)?
But alloc_page_buffers() is pretty frequently called and I'd be
inclined to not add any check - most callers will just go oops and that
will provide basically the same information.
Agree with this concern.
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1571,6 +1571,12 @@ void create_empty_buffers(struct page *page,
struct buffer_head *bh, *head, *tail;
head = alloc_page_buffers(page, blocksize, 1);
+
+ /*
+ * alloc_page_buffers() could return NULL on (1) bs > PAGE_SIZE
+ * (2) low memory case. Ensure that we don't dereference null ptr
+ */
+ BUG_ON(!head);
This is unneeded.
- bs > PAGE_SIZE can be checked elsewhere in a direct fashion
- low memory case can't happen - we passed retry=1
- create_empty_buffers() will immediately go oops if head==NULL.
That oops contains the same info as is presented by a BUG().
Okay.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html