[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070104215206.GZ17561@ftp.linux.org.uk>
Date: Thu, 4 Jan 2007 21:52:06 +0000
From: Al Viro <viro@....linux.org.uk>
To: Linus Torvalds <torvalds@...l.org>
Cc: Eric Sandeen <sandeen@...hat.com>, Andrew Morton <akpm@...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
On Thu, Jan 04, 2007 at 01:30:47PM -0800, Linus Torvalds wrote:
> I'll happily cast away arguments that aren't used, but I'm not sure that
> we ever should cast different return values (not "int" vs "long", but also
> not "loff_t" etc).
>
> On 32-bit architectures, 64-bit entities may be returned totally different
> ways (ie things like "caller allocates space for them and passes in a
> magic pointer to the return value as the first _real_ argument").
>
> So with my previous email, I was definitely _not_ trying to say that
> casting function pointers is ok. In practice it is ok when the _arguments_
> differ, but not necessarily when the _return-type_ differs.
>
> I was cc'd into the discussion late, so I didn't realize that we
> apparently already have a situation where changing the return value to
> "long" might make a difference. If so, I agree that we shouldn't do this
> at all (although Andrew's change to "long" seems perfectly fine as a "make
> old cases continue to work" patch if it actually matters).
We do.
loff_t (*llseek) (struct file *, loff_t, int);
...
int (*readdir) (struct file *, void *, filldir_t);
static const struct file_operations bad_file_ops =
{
.llseek = EIO_ERROR,
...
.readdir = EIO_ERROR,
Moreover, we have int, loff_t, ssize_t and long, plus the unsigned variants.
At least 3 versions, unless you want to mess with ifdefs to reduce them to
two.
-
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