Re: [PATCH] Fix nasty 32-bit overflow bug in buffer i/o code.

2014-09-22 Thread Anton Altaparmakov
Hi Linus, On 22 Sep 2014, at 16:33, Linus Torvalds wrote: > On Mon, Sep 22, 2014 at 8:29 AM, Anton Altaparmakov wrote: >> >> You could do "block & ~(sector_t)(size - 1)" instead of "(sector_t)index << >> sizebits" if you prefer but not sure that is an improvement! > > No, it would be even wor

Re: [PATCH] Fix nasty 32-bit overflow bug in buffer i/o code.

2014-09-22 Thread Linus Torvalds
On Mon, Sep 22, 2014 at 8:29 AM, Anton Altaparmakov wrote: > > You could do "block & ~(sector_t)(size - 1)" instead of "(sector_t)index << > sizebits" if you prefer but not sure that is an improvement! No, it would be even worse. Something like block & ~(sector_t)((size >> 9) - 1) because bl

Re: [PATCH] Fix nasty 32-bit overflow bug in buffer i/o code.

2014-09-22 Thread Anton Altaparmakov
Hi Linus, On 22 Sep 2014, at 16:18, Linus Torvalds wrote: > On Sun, Sep 21, 2014 at 5:53 PM, Anton Altaparmakov wrote: >> >> This patch fixes this issue by type casting "index" to sector_t before >> doing the left shift. > > Ugh. Does the simpler patch to just pass in "block" work as well? Th

Re: [PATCH] Fix nasty 32-bit overflow bug in buffer i/o code.

2014-09-22 Thread Linus Torvalds
On Mon, Sep 22, 2014 at 8:18 AM, Linus Torvalds wrote: > > Ugh. Does the simpler patch to just pass in "block" work as well? Ugh, never mind, no it does not. It doesn't truncate the sectors to the beginning of a page boundary. Will take the patch as-is (will edit the commit message that seems a

Re: [PATCH] Fix nasty 32-bit overflow bug in buffer i/o code.

2014-09-22 Thread Linus Torvalds
On Sun, Sep 21, 2014 at 5:53 PM, Anton Altaparmakov wrote: > > This patch fixes this issue by type casting "index" to sector_t before > doing the left shift. Ugh. Does the simpler patch to just pass in "block" work as well? Linus fs/buffer.c | 5 ++--- 1 file changed, 2 inse

Re: [PATCH] Fix nasty 32-bit overflow bug in buffer i/o code.

2014-09-22 Thread Anton Altaparmakov
Hi, On 22 Sep 2014, at 11:36, Hugh Dickins wrote: > On Mon, 22 Sep 2014, Anton Altaparmakov wrote: >> On 22 Sep 2014, at 05:43, Hugh Dickins wrote: >>> On Mon, 22 Sep 2014, Anton Altaparmakov wrote: Any code that uses __getblk() and thus bread(), breadahead(), sb_bread(), sb_breadahea

Re: [PATCH] Fix nasty 32-bit overflow bug in buffer i/o code.

2014-09-22 Thread Hugh Dickins
On Mon, 22 Sep 2014, Anton Altaparmakov wrote: > Hi Hugh, > > On 22 Sep 2014, at 05:43, Hugh Dickins wrote: > > On Mon, 22 Sep 2014, Anton Altaparmakov wrote: > >> Any code that uses __getblk() and thus bread(), breadahead(), sb_bread(), > >> sb_breadahead(), sb_getblk(), and calls it using a 6

Re: [PATCH] Fix nasty 32-bit overflow bug in buffer i/o code.

2014-09-22 Thread Anton Altaparmakov
Hi Hugh, On 22 Sep 2014, at 05:43, Hugh Dickins wrote: > On Mon, 22 Sep 2014, Anton Altaparmakov wrote: >> Any code that uses __getblk() and thus bread(), breadahead(), sb_bread(), >> sb_breadahead(), sb_getblk(), and calls it using a 64-bit block on a >> 32-bit arch (where "long" is 32-bit) ca

Re: [PATCH] Fix nasty 32-bit overflow bug in buffer i/o code.

2014-09-21 Thread Hugh Dickins
On Mon, 22 Sep 2014, Anton Altaparmakov wrote: > Any code that uses __getblk() and thus bread(), breadahead(), sb_bread(), > sb_breadahead(), sb_getblk(), and calls it using a 64-bit block on a > 32-bit arch (where "long" is 32-bit) causes an inifinite loop in > __getblk_slow() with an infinite

[PATCH] Fix nasty 32-bit overflow bug in buffer i/o code.

2014-09-21 Thread Anton Altaparmakov
Any code that uses __getblk() and thus bread(), breadahead(), sb_bread(), sb_breadahead(), sb_getblk(), and calls it using a 64-bit block on a 32-bit arch (where "long" is 32-bit) causes an inifinite loop in __getblk_slow() with an infinite stream of errors logged to dmesg like this: __find_ge