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
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.
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
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
>
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
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
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
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
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
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
@@
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
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
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
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
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
+++
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
16 matches
Mail list logo