[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20101014162021.ce03ab66.akpm@linux-foundation.org>
Date: Thu, 14 Oct 2010 16:20:21 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Edward Shishkin <edward.shishkin@...il.com>
Cc: linux-fsdevel@...r.kernel.org, Eric Sandeen <sandeen@...hat.com>,
lmcilroy@...hat.com, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch 1/2] vfs: fix overflow in direct-io subsystem
On Wed, 13 Oct 2010 22:45:57 +0200
Edward Shishkin <edward.shishkin@...il.com> wrote:
> Fix up overflow (ssize_t->int) in the direct-io subsystem.
>
> Signed-off-by: Edward Shishkin <edward@...hat.com>
> ---
> fs/direct-io.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2.6.36-rc7.orig/fs/direct-io.c
> +++ linux-2.6.36-rc7/fs/direct-io.c
> @@ -218,7 +218,7 @@ static struct page *dio_get_page(struct
> * filesystems can use it to hold additional state between get_block calls and
> * dio_complete.
> */
> -static int dio_complete(struct dio *dio, loff_t offset, int ret, bool is_async)
> +static ssize_t dio_complete(struct dio *dio, loff_t offset, ssize_t ret, bool is_async)
> {
> ssize_t transferred = 0;
>
I'd call this a truncation error, not an overflow. Semantics.
So what's the runtime effect? The subsystem will go stupid when doing
a single transfer of over 2G on a 64-bit machine?
Can this actually happen in practice? Has nobody ever done this before
now?
<goes to test it>
<discovers that ubuntu 8.04's dd doesn't support conv=direct>
<stupid thing>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists