diff options
| author | Al Viro <viro@ZenIV.linux.org.uk> | 2012-12-03 18:15:30 +0000 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2012-12-03 11:13:09 -0800 |
| commit | 25a3bc6bd1ca03ab504b8c55c98f8d0135644d53 (patch) | |
| tree | df9b6f4ae48f8037af3e8b5ad551f36010884f40 /drivers/edac/i82975x_edac.c | |
| parent | fd8ef11730f1d03d5d6555aa53126e9e34f52f12 (diff) | |
| download | linux-25a3bc6bd1ca03ab504b8c55c98f8d0135644d53.tar.gz linux-25a3bc6bd1ca03ab504b8c55c98f8d0135644d53.tar.bz2 linux-25a3bc6bd1ca03ab504b8c55c98f8d0135644d53.zip | |
[parisc] open(2) compat bug
In commit 9d73fc2d641f ("open*(2) compat fixes (s390, arm64)") I said:
>
> The usual rules for open()/openat()/open_by_handle_at() are
> 1) native 32bit - don't force O_LARGEFILE in flags
> 2) native 64bit - force O_LARGEFILE in flags
> 3) compat on 64bit host - as for native 32bit
> 4) native 32bit ABI for 64bit system (mips/n32, x86/x32) - as for native 64bit
>
> There are only two exceptions - s390 compat has open() forcing O_LARGEFILE and
> arm64 compat has open_by_handle_at() doing the same thing. The same binaries
> on native host (s390/31 and arm resp.) will *not* force O_LARGEFILE, so IMO
> both are emulation bugs.
Three exceptions, actually - parisc open() is another case like that.
Native 32bit won't force O_LARGEFILE, the same binary on parisc64 will.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/edac/i82975x_edac.c')
0 files changed, 0 insertions, 0 deletions