[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <459D6F17.2050208@redhat.com>
Date: Thu, 04 Jan 2007 15:18:15 -0600
From: Eric Sandeen <sandeen@...hat.com>
To: Andrew Morton <akpm@...l.org>
CC: Al Viro <viro@....linux.org.uk>,
Linus Torvalds <torvalds@...l.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [UPDATED PATCH] fix memory corruption from misinterpreted bad_inode_ops
return values
Andrew Morton wrote:
> On Thu, 04 Jan 2007 15:04:17 -0600
> Eric Sandeen <sandeen@...hat.com> wrote:
>
>> Andrew Morton wrote:
>>> On Thu, 4 Jan 2007 20:24:12 +0000
>>> Al Viro <viro@....linux.org.uk> wrote:
>>>
>>>> So my main issue with fs/bad_inode.c is not even cast per se; it's that
>>>> cast is to void *.
>>> But Eric's latest patch is OK in that regard, isn't it? It might confuse
>>> parsers (in fixable ways), but it is type-correct and has no casts. (Well,
>>> it kinda has an link-time cast).
>> Even if it is, I'm starting to wonder if all this tricksiness is really
>> worth it for 400 bytes or so. :)
>>
>
> Ah, but it's a learning opportunity!
*grin*
> btw, couldn't we fix this bug with a simple old
>
> --- a/fs/bad_inode.c~a
> +++ a/fs/bad_inode.c
> @@ -15,7 +15,7 @@
> #include <linux/smp_lock.h>
> #include <linux/namei.h>
>
> -static int return_EIO(void)
> +static long return_EIO(void)
> {
> return -EIO;
> }
> _
>
> ?
What about ops that return loff_t (64 bits) on 32-bit arches and stuff
it into 2 registers....
#include <stdio.h>
#include <sys/types.h>
#include <sys/errno.h>
static long return_EIO(void)
{
return -EIO;
}
#define EIO_ERROR ((void *) (return_EIO))
int main(int argc, char ** argv)
{
loff_t error;
loff_t (*fn_ptr) (int);
fn_ptr = EIO_ERROR;
error = fn_ptr(0);
printf("and... error is %lld\n", error);
return 0;
}
[root]# ./ssize_eio
and... error is 8589934587
[root]# uname -m
i686
I'm still not convinced that this is the best place to be clever :)
-Eric
-
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