[PATCH] sysfs/bin: Fix size handling overflow for bin_attribute

[Benjamin Herrenschmidt]

While looking at the code, I noticed that bin_attribute read() and write()
ops copy the inode size into an int for futher comparisons.

Some bin_attributes can be fairly large. For example, pci creates some for
BARs set to the BAR size and giant BARs are around the corner, so this is
going to break something somewhere eventually.

Let's use the right type.

Signed-off-by: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
---

I noticed that while messing around with my "xscom" file which I had
originally set to be LONG_MAX :-)

I eventually decided to use an i_size of 0 instead which seems to be
the way that sort of "special" file tend to be done (it's a bridge to
a special sideband bus in the system which has a sparse addressing which
is splattered all over 64 bits though I've somewhat "compressed" it to 63
for the sake of sysfs).

Note that I noticed that late and don't have a good test case for it,
but code inspection didn't seem to show anything else cropping i_size. 

diff --git a/fs/sysfs/bin.c b/fs/sysfs/bin.c
index c590cab..373ddcf 100644
--- a/fs/sysfs/bin.c
+++ b/fs/sysfs/bin.c
@@ -69,7 +69,7 @@ static ssize_t
 read(struct file *file, char __user *userbuf, size_t bytes, loff_t *off)
 {
 	struct bin_buffer *bb = file->private_data;
-	int size = file_inode(file)->i_size;
+	loff_t size = file_inode(file)->i_size;
 	loff_t offs = *off;
 	int count = min_t(size_t, bytes, PAGE_SIZE);
 	char *temp;
@@ -139,7 +139,7 @@ static ssize_t write(struct file *file, const char __user *userbuf,
 		     size_t bytes, loff_t *off)
 {
 	struct bin_buffer *bb = file->private_data;
-	int size = file_inode(file)->i_size;
+	loff_t size = file_inode(file)->i_size;
 	loff_t offs = *off;
 	int count = min_t(size_t, bytes, PAGE_SIZE);
 	char *temp;


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