Re: [PATCH] pipefs unique inode numbers

2007-01-31 Thread Kirill Korotaev
Linus, >>Also, that patch would break many 32-bit programs not compiled with large >>offsets when run in compatibility mode on a 64-bit kernel. If they were to >>do a stat on this inode, it would likely generate an EOVERFLOW error since >>the pointer address would probably not fit in a 32 bit

Re: [PATCH] pipefs unique inode numbers

2007-01-31 Thread Kirill Korotaev
Linus, Also, that patch would break many 32-bit programs not compiled with large offsets when run in compatibility mode on a 64-bit kernel. If they were to do a stat on this inode, it would likely generate an EOVERFLOW error since the pointer address would probably not fit in a 32 bit field.

Re: [PATCH] pipefs unique inode numbers

2007-01-30 Thread Jeff Layton
Linus Torvalds wrote: > > On Tue, 30 Jan 2007, Jeff Layton wrote: >> Also, that patch would break many 32-bit programs not compiled with large >> offsets when run in compatibility mode on a 64-bit kernel. If they were to >> do a stat on this inode, it would likely generate an EOVERFLOW error

Re: [PATCH] pipefs unique inode numbers

2007-01-30 Thread Jeff Layton
Jeff Layton wrote: Bodo Eggert wrote: > change pipefs to use a unique inode number equal to the memory > address unless it would be truncated. > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > --- > Tested on i386. > > --- 2.6.19/fs/pipe.c.ori2007-01-30 22:02:46.0 +0100 >

Re: [PATCH] pipefs unique inode numbers

2007-01-30 Thread Linus Torvalds
On Tue, 30 Jan 2007, Jeff Layton wrote: > > Also, that patch would break many 32-bit programs not compiled with large > offsets when run in compatibility mode on a 64-bit kernel. If they were to > do a stat on this inode, it would likely generate an EOVERFLOW error since > the pointer address

Re: [PATCH] pipefs unique inode numbers

2007-01-30 Thread Jeff Layton
Bodo Eggert wrote: > change pipefs to use a unique inode number equal to the memory > address unless it would be truncated. > > Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> > --- > Tested on i386. > > --- 2.6.19/fs/pipe.c.ori 2007-01-30 22:02:46.0 +0100 > +++ 2.6.19/fs/pipe.c

Re: [PATCH] pipefs unique inode numbers

2007-01-30 Thread Jeff Layton
Linus Torvalds wrote: On Tue, 30 Jan 2007, Bodo Eggert wrote: change pipefs to use a unique inode number equal to the memory address unless it would be truncated. I *really* wouldn't want to expose kernel addresses to user space, it just ends up being a piece of data that they shouldn't

Re: [PATCH] pipefs unique inode numbers

2007-01-30 Thread Linus Torvalds
On Tue, 30 Jan 2007, Bodo Eggert wrote: > > change pipefs to use a unique inode number equal to the memory > address unless it would be truncated. I *really* wouldn't want to expose kernel addresses to user space, it just ends up being a piece of data that they shouldn't have. If we have some

[PATCH] pipefs unique inode numbers

2007-01-30 Thread Bodo Eggert
change pipefs to use a unique inode number equal to the memory address unless it would be truncated. Signed-Off-By: Bodo Eggert <[EMAIL PROTECTED]> --- Tested on i386. --- 2.6.19/fs/pipe.c.ori2007-01-30 22:02:46.0 +0100 +++ 2.6.19/fs/pipe.c2007-01-30 23:22:27.0 +0100

[PATCH] pipefs unique inode numbers

2007-01-30 Thread Bodo Eggert
change pipefs to use a unique inode number equal to the memory address unless it would be truncated. Signed-Off-By: Bodo Eggert [EMAIL PROTECTED] --- Tested on i386. --- 2.6.19/fs/pipe.c.ori2007-01-30 22:02:46.0 +0100 +++ 2.6.19/fs/pipe.c2007-01-30 23:22:27.0 +0100 @@

Re: [PATCH] pipefs unique inode numbers

2007-01-30 Thread Linus Torvalds
On Tue, 30 Jan 2007, Bodo Eggert wrote: change pipefs to use a unique inode number equal to the memory address unless it would be truncated. I *really* wouldn't want to expose kernel addresses to user space, it just ends up being a piece of data that they shouldn't have. If we have some

Re: [PATCH] pipefs unique inode numbers

2007-01-30 Thread Jeff Layton
Linus Torvalds wrote: On Tue, 30 Jan 2007, Bodo Eggert wrote: change pipefs to use a unique inode number equal to the memory address unless it would be truncated. I *really* wouldn't want to expose kernel addresses to user space, it just ends up being a piece of data that they shouldn't

Re: [PATCH] pipefs unique inode numbers

2007-01-30 Thread Jeff Layton
Bodo Eggert wrote: change pipefs to use a unique inode number equal to the memory address unless it would be truncated. Signed-Off-By: Bodo Eggert [EMAIL PROTECTED] --- Tested on i386. --- 2.6.19/fs/pipe.c.ori 2007-01-30 22:02:46.0 +0100 +++ 2.6.19/fs/pipe.c 2007-01-30

Re: [PATCH] pipefs unique inode numbers

2007-01-30 Thread Linus Torvalds
On Tue, 30 Jan 2007, Jeff Layton wrote: Also, that patch would break many 32-bit programs not compiled with large offsets when run in compatibility mode on a 64-bit kernel. If they were to do a stat on this inode, it would likely generate an EOVERFLOW error since the pointer address would

Re: [PATCH] pipefs unique inode numbers

2007-01-30 Thread Jeff Layton
Jeff Layton wrote: Bodo Eggert wrote: change pipefs to use a unique inode number equal to the memory address unless it would be truncated. Signed-Off-By: Bodo Eggert [EMAIL PROTECTED] --- Tested on i386. --- 2.6.19/fs/pipe.c.ori2007-01-30 22:02:46.0 +0100 +++

Re: [PATCH] pipefs unique inode numbers

2007-01-30 Thread Jeff Layton
Linus Torvalds wrote: On Tue, 30 Jan 2007, Jeff Layton wrote: Also, that patch would break many 32-bit programs not compiled with large offsets when run in compatibility mode on a 64-bit kernel. If they were to do a stat on this inode, it would likely generate an EOVERFLOW error since the