Hi,
On Thu, 4 Jan 2007, Al Viro wrote:
> PS: what would be the sane strategy for timer series merge, BTW?
PPS: I still don't like it. It fixes a rather theoretical problem with
absolutely no practical relevance.
PPPS: type safety is also possible with container_of(), the prototype
patch below
Hi,
On Thu, 4 Jan 2007, Al Viro wrote:
PS: what would be the sane strategy for timer series merge, BTW?
PPS: I still don't like it. It fixes a rather theoretical problem with
absolutely no practical relevance.
PPPS: type safety is also possible with container_of(), the prototype
patch below
Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
>> +++ a/fs/bad_inode.c
>> -static int return_EIO(void)
>> +static long return_EIO(void)
> What about ops that return loff_t (64 bits) on 32-bit arches and stuff
> it into 2 registers
*If* it uses an additional register for the
On Thu, 2007-01-04 at 23:52 +, Al Viro wrote:
> On Thu, Jan 04, 2007 at 03:21:06PM -0800, Mitchell Blank Jr wrote:
> > Linus Torvalds wrote:
> > > Well, that probably would work, but it's also true that returning a
> > > 64-bit
> > > value on a 32-bit platform really _does_ depend on more
On Thu, 2007-01-04 at 23:52 +, Al Viro wrote:
On Thu, Jan 04, 2007 at 03:21:06PM -0800, Mitchell Blank Jr wrote:
Linus Torvalds wrote:
Well, that probably would work, but it's also true that returning a
64-bit
value on a 32-bit platform really _does_ depend on more than the size.
Eric Sandeen [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
+++ a/fs/bad_inode.c
-static int return_EIO(void)
+static long return_EIO(void)
What about ops that return loff_t (64 bits) on 32-bit arches and stuff
it into 2 registers
*If* it uses an additional register for the high bits,
On Thu, Jan 04, 2007 at 03:21:06PM -0800, Mitchell Blank Jr wrote:
> Linus Torvalds wrote:
> > Well, that probably would work, but it's also true that returning a 64-bit
> > value on a 32-bit platform really _does_ depend on more than the size.
>
> Yeah, obviously this is restricted to the
Linus Torvalds wrote:
> On Thu, 4 Jan 2007, Andrew Morton wrote:
>
>> That's what I currently have queued. It increases bad_inode.o text from
>> 200-odd bytes to 700-odd :(
>>
> Then I think we're ok. We do care about bytes, but we care more about
> bytes that actually ever hit the
On Thu, 4 Jan 2007, Andrew Morton wrote:
>
> That's what I currently have queued. It increases bad_inode.o text from
> 200-odd bytes to 700-odd :(
Then I think we're ok. We do care about bytes, but we care more about
bytes that actually ever hit the icache or dcache, and this will
On Thu, 4 Jan 2007 14:35:09 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Anybody want to send in the patch that just generates separate versions
> for
>
> loff_t eio_llseek(struct file *file, loff_t offset, int origin)
> {
> return -EIO;
> }
>
>
Linus Torvalds wrote:
> Well, that probably would work, but it's also true that returning a 64-bit
> value on a 32-bit platform really _does_ depend on more than the size.
Yeah, obviously this is restricted to the signed-integer case. My point
was just that you could have the compiler figure
Linus Torvalds wrote:
> Anybody want to send in the patch that just generates separate versions
> for
>
> loff_t eio_llseek(struct file *file, loff_t offset, int origin)
> {
> return -EIO;
> }
>
> int eio_readdir(struct file *filp, void *dirent, filldir_t
On Thu, 4 Jan 2007, Mitchell Blank Jr wrote:
>
> I don't think you need to do fancy #ifdef's:
>
> static s32 return_eio_32(void) { return -EIO; }
> static s64 return_eio_64(void) { return -EIO; }
> extern void return_eio_unknown(void); /* Doesn't exist */
> #define return_eio(type)
Al Viro wrote:
> At least 3 versions, unless you want to mess with ifdefs to reduce them to
> two.
I don't think you need to do fancy #ifdef's:
static s32 return_eio_32(void) { return -EIO; }
static s64 return_eio_64(void) { return -EIO; }
extern void return_eio_unknown(void); /* Doesn't exist
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
Linus Torvalds wrote:
>
> On Thu, 4 Jan 2007, Eric Sandeen wrote:
>> Andrew Morton wrote:
>>
>>> 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
>>> #include
>>>
>>> -static int return_EIO(void)
>>>
On Thu, 4 Jan 2007, Eric Sandeen wrote:
> Andrew Morton wrote:
>
> > 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
> > #include
> >
> > -static int return_EIO(void)
> > +static long
Andrew Morton wrote:
> On Thu, 04 Jan 2007 15:04:17 -0600
> Eric Sandeen <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>>> On Thu, 4 Jan 2007 20:24:12 +
>>> Al Viro <[EMAIL PROTECTED]> wrote:
>>>
So my main issue with fs/bad_inode.c is not even cast per se; it's that
cast is
On Thu, 04 Jan 2007 15:04:17 -0600
Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Thu, 4 Jan 2007 20:24:12 +
> > Al Viro <[EMAIL PROTECTED]> wrote:
> >
> >> So my main issue with fs/bad_inode.c is not even cast per se; it's that
> >> cast is to void *.
> >
> > But
Andrew Morton wrote:
> On Thu, 4 Jan 2007 20:24:12 +
> Al Viro <[EMAIL PROTECTED]> 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
On Thu, 4 Jan 2007 20:24:12 +
Al Viro <[EMAIL PROTECTED]> 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
On Thu, Jan 04, 2007 at 11:30:22AM -0800, Linus Torvalds wrote:
>
>
> On Thu, 4 Jan 2007, Al Viro wrote:
> >
> > How about "makes call graph analysis easier"? ;-) In principle, I have
> > no problem with force-casting, but it'd better be cast to the right
> > type...
>
> Do we really care in
On Thu, 4 Jan 2007, Al Viro wrote:
>
> PS: what would be the sane strategy for timer series merge, BTW?
I think Andrew may care more. I just care about it happening after 2.6.20.
Whether we can do it really early after that, or whether we should do it
as the last thing just before releasing
On Thu, 4 Jan 2007, Al Viro wrote:
>
> How about "makes call graph analysis easier"? ;-) In principle, I have
> no problem with force-casting, but it'd better be cast to the right
> type...
Do we really care in the kernel? We simply never use function pointer
casts like this for anything
On Thu, 04 Jan 2007 11:51:10 -0600, Eric Sandeen wrote:
>Also - is it ok to alias a function with one signature to a function with
>another signature?
NO!
Specific cases of type mismatches may work on many machines
(say different pointer types as long as they aren't accessed),
but in general
On Thu, Jan 04, 2007 at 07:14:51PM +, Al Viro wrote:
> On Thu, Jan 04, 2007 at 11:09:31AM -0800, Linus Torvalds wrote:
>
> > But I'd argue we should only do it if there is an actual
> > honest-to-goodness reason to do so.
>
> How about "makes call graph analysis easier"? ;-) In principle,
On Thu, Jan 04, 2007 at 11:09:31AM -0800, Linus Torvalds wrote:
> But I'd argue we should only do it if there is an actual
> honest-to-goodness reason to do so.
How about "makes call graph analysis easier"? ;-) In principle, I have
no problem with force-casting, but it'd better be cast to the
On Thu, 4 Jan 2007, Andrew Morton wrote:
> On Thu, 04 Jan 2007 12:33:59 -0600
> Eric Sandeen <[EMAIL PROTECTED]> wrote:
>
> > Andrew Morton wrote:
> > > On Thu, 04 Jan 2007 11:51:10 -0600
> > > Eric Sandeen <[EMAIL PROTECTED]> wrote:
> >
> > >> Also - is it ok to alias a function with one
On Thu, 04 Jan 2007 12:33:59 -0600
Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Thu, 04 Jan 2007 11:51:10 -0600
> > Eric Sandeen <[EMAIL PROTECTED]> wrote:
>
> >> Also - is it ok to alias a function with one signature to a function with
> >> another signature?
> >
> >
Andrew Morton wrote:
> On Thu, 04 Jan 2007 11:51:10 -0600
> Eric Sandeen <[EMAIL PROTECTED]> wrote:
>> Also - is it ok to alias a function with one signature to a function with
>> another signature?
>
> Ordinarily I'd say no wucking fay, but that's effectively what we've been
> doing in there
On Thu, 04 Jan 2007 11:51:10 -0600
Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
>
> > Al is correct, of course. But the patch takes bad_inode.o from 280 up to
> > 703
> > bytes, which is a bit sad for some cosmetic thing which nobody ever looks
> > at or modifies.
> >
> >
Andrew Morton wrote:
> Al is correct, of course. But the patch takes bad_inode.o from 280 up to 703
> bytes, which is a bit sad for some cosmetic thing which nobody ever looks
> at or modifies.
>
> Perhaps you can do
>
> static int return_EIO_int(void)
> {
> return -EIO;
> }
>
> static int
Andrew Morton wrote:
Al is correct, of course. But the patch takes bad_inode.o from 280 up to 703
bytes, which is a bit sad for some cosmetic thing which nobody ever looks
at or modifies.
Perhaps you can do
static int return_EIO_int(void)
{
return -EIO;
}
static int
On Thu, 04 Jan 2007 11:51:10 -0600
Eric Sandeen [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
Al is correct, of course. But the patch takes bad_inode.o from 280 up to
703
bytes, which is a bit sad for some cosmetic thing which nobody ever looks
at or modifies.
Perhaps you can do
Andrew Morton wrote:
On Thu, 04 Jan 2007 11:51:10 -0600
Eric Sandeen [EMAIL PROTECTED] wrote:
Also - is it ok to alias a function with one signature to a function with
another signature?
Ordinarily I'd say no wucking fay, but that's effectively what we've been
doing in there for ages, and
On Thu, 04 Jan 2007 12:33:59 -0600
Eric Sandeen [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Thu, 04 Jan 2007 11:51:10 -0600
Eric Sandeen [EMAIL PROTECTED] wrote:
Also - is it ok to alias a function with one signature to a function with
another signature?
Ordinarily I'd say no
On Thu, 4 Jan 2007, Andrew Morton wrote:
On Thu, 04 Jan 2007 12:33:59 -0600
Eric Sandeen [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Thu, 04 Jan 2007 11:51:10 -0600
Eric Sandeen [EMAIL PROTECTED] wrote:
Also - is it ok to alias a function with one signature to a function
On Thu, Jan 04, 2007 at 11:09:31AM -0800, Linus Torvalds wrote:
But I'd argue we should only do it if there is an actual
honest-to-goodness reason to do so.
How about makes call graph analysis easier? ;-) In principle, I have
no problem with force-casting, but it'd better be cast to the
On Thu, Jan 04, 2007 at 07:14:51PM +, Al Viro wrote:
On Thu, Jan 04, 2007 at 11:09:31AM -0800, Linus Torvalds wrote:
But I'd argue we should only do it if there is an actual
honest-to-goodness reason to do so.
How about makes call graph analysis easier? ;-) In principle, I have
On Thu, 04 Jan 2007 11:51:10 -0600, Eric Sandeen wrote:
Also - is it ok to alias a function with one signature to a function with
another signature?
NO!
Specific cases of type mismatches may work on many machines
(say different pointer types as long as they aren't accessed),
but in general this
On Thu, 4 Jan 2007, Al Viro wrote:
How about makes call graph analysis easier? ;-) In principle, I have
no problem with force-casting, but it'd better be cast to the right
type...
Do we really care in the kernel? We simply never use function pointer
casts like this for anything
On Thu, 4 Jan 2007, Al Viro wrote:
PS: what would be the sane strategy for timer series merge, BTW?
I think Andrew may care more. I just care about it happening after 2.6.20.
Whether we can do it really early after that, or whether we should do it
as the last thing just before releasing
On Thu, Jan 04, 2007 at 11:30:22AM -0800, Linus Torvalds wrote:
On Thu, 4 Jan 2007, Al Viro wrote:
How about makes call graph analysis easier? ;-) In principle, I have
no problem with force-casting, but it'd better be cast to the right
type...
Do we really care in the kernel? We
On Thu, 4 Jan 2007 20:24:12 +
Al Viro [EMAIL PROTECTED] 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
Andrew Morton wrote:
On Thu, 4 Jan 2007 20:24:12 +
Al Viro [EMAIL PROTECTED] 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
On Thu, 04 Jan 2007 15:04:17 -0600
Eric Sandeen [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Thu, 4 Jan 2007 20:24:12 +
Al Viro [EMAIL PROTECTED] 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
Andrew Morton wrote:
On Thu, 04 Jan 2007 15:04:17 -0600
Eric Sandeen [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Thu, 4 Jan 2007 20:24:12 +
Al Viro [EMAIL PROTECTED] 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
On Thu, 4 Jan 2007, Eric Sandeen wrote:
Andrew Morton wrote:
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
Linus Torvalds wrote:
On Thu, 4 Jan 2007, Eric Sandeen wrote:
Andrew Morton wrote:
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
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
Al Viro wrote:
At least 3 versions, unless you want to mess with ifdefs to reduce them to
two.
I don't think you need to do fancy #ifdef's:
static s32 return_eio_32(void) { return -EIO; }
static s64 return_eio_64(void) { return -EIO; }
extern void return_eio_unknown(void); /* Doesn't exist
On Thu, 4 Jan 2007, Mitchell Blank Jr wrote:
I don't think you need to do fancy #ifdef's:
static s32 return_eio_32(void) { return -EIO; }
static s64 return_eio_64(void) { return -EIO; }
extern void return_eio_unknown(void); /* Doesn't exist */
#define return_eio(type)
Linus Torvalds wrote:
Anybody want to send in the patch that just generates separate versions
for
loff_t eio_llseek(struct file *file, loff_t offset, int origin)
{
return -EIO;
}
int eio_readdir(struct file *filp, void *dirent, filldir_t filldir)
Linus Torvalds wrote:
Well, that probably would work, but it's also true that returning a 64-bit
value on a 32-bit platform really _does_ depend on more than the size.
Yeah, obviously this is restricted to the signed-integer case. My point
was just that you could have the compiler figure out
On Thu, 4 Jan 2007 14:35:09 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
Anybody want to send in the patch that just generates separate versions
for
loff_t eio_llseek(struct file *file, loff_t offset, int origin)
{
return -EIO;
}
int
On Thu, 4 Jan 2007, Andrew Morton wrote:
That's what I currently have queued. It increases bad_inode.o text from
200-odd bytes to 700-odd :(
Then I think we're ok. We do care about bytes, but we care more about
bytes that actually ever hit the icache or dcache, and this will
effectively
Linus Torvalds wrote:
On Thu, 4 Jan 2007, Andrew Morton wrote:
That's what I currently have queued. It increases bad_inode.o text from
200-odd bytes to 700-odd :(
Then I think we're ok. We do care about bytes, but we care more about
bytes that actually ever hit the icache or
On Thu, Jan 04, 2007 at 03:21:06PM -0800, Mitchell Blank Jr wrote:
Linus Torvalds wrote:
Well, that probably would work, but it's also true that returning a 64-bit
value on a 32-bit platform really _does_ depend on more than the size.
Yeah, obviously this is restricted to the
On Wed, 03 Jan 2007 17:46:00 -0600
Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Take 2... all in one file. I suppose I really did know better than
> to create that new header. ;-)
>
> Better?
>
> ---
>
> CVE-2006-5753 is for a case where an inode can be marked bad, switching
> the ops to
Take 2... all in one file. I suppose I really did know better than
to create that new header. ;-)
Better?
---
CVE-2006-5753 is for a case where an inode can be marked bad, switching
the ops to bad_inode_ops, which are all connected as:
static int return_EIO(void)
{
return -EIO;
}
Take 2... all in one file. I suppose I really did know better than
to create that new header. ;-)
Better?
---
CVE-2006-5753 is for a case where an inode can be marked bad, switching
the ops to bad_inode_ops, which are all connected as:
static int return_EIO(void)
{
return -EIO;
}
On Wed, 03 Jan 2007 17:46:00 -0600
Eric Sandeen [EMAIL PROTECTED] wrote:
Take 2... all in one file. I suppose I really did know better than
to create that new header. ;-)
Better?
---
CVE-2006-5753 is for a case where an inode can be marked bad, switching
the ops to
62 matches
Mail list logo
