linux-mips
[Top] [All Lists]

Re: bug in fchownat in n32 and 64 ABIs

To: Bruno Haible <bruno@clisp.org>
Subject: Re: bug in fchownat in n32 and 64 ABIs
From: David Daney <david.daney@cavium.com>
Date: Thu, 27 Oct 2011 17:26:44 -0700
Cc: "bug-gnulib@gnu.org" <bug-gnulib@gnu.org>, "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-reply-to: <201110280159.41533.bruno@clisp.org>
References: <201110272107.38510.bruno@clisp.org> <4EA9B072.5000107@cavium.com> <201110280159.41533.bruno@clisp.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10
On 10/27/2011 04:59 PM, Bruno Haible wrote:
David Daney wrote:
'strace' of this program shows that the system call that returns with -1/EPERM
is a call to SYS_6254 (in n32 ABI) or SYS_5250 (in 64 ABI).

Can you get strace -- version 4.5.20 or later and build it for the
corresponding ABI?  That should properly decode the relevant syscalls.

Version 4.6, built with "gcc -m64", compared to version 4.5.17:


For the program in ABI 64:

strace 4.5.17 reports
SYS_5250()                              = -1 EPERM (Operation not permitted)

strace 4.6 reports nothing, it stopped the log after it saw an exit() call:
getsockopt(1099511620912, 0xfffff820 /* SOL_??? */, 1099511625776, 0, 
0x5555748ed0) = 0
svr4_syscall()                          = 5012
exit(1099511623472)                     = ?
fchownat: Operation not permitted
fchownat: Operation not permitted
fchownat: Operation not permitted


For the program in ABI n32:

strace 4.5.17 reports
SYS_6254()                              = -1 EPERM (Operation not permitted)

strace 4.6 reports
n32_inotify_add_watch(0xffffffffffffff9c, 0x10000a30, 0xffffffff) = -1 EPERM 
(Operation not permitted)
n32_inotify_add_watch(0xffffffffffffff9c, 0x10000a30, 0x4f0) = -1 EPERM 
(Operation not permitted)
n32_inotify_add_watch(0xffffffffffffff9c, 0x10000a30, 0xffffffff) = -1 EPERM 
(Operation not permitted)


For the program in ABI 32:

strace 4.5.17 reports
fchownat(AT_FDCWD, "foo.c", -1, 1264, 0) = 0
fchownat(AT_FDCWD, "foo.c", 1264, -1, 0) = 0
fchownat(AT_FDCWD, "foo.c", -1, -1, 0)  = 0

strace 4.6 reports
o32_fchownat(0xffffffffffffff9c, 0x400b00, 0xffffffffffffffff, 0x4f0, 0) = 0
o32_fchownat(0xffffffffffffff9c, 0x400b00, 0x4f0, 0xffffffffffffffff, 0) = 0
o32_fchownat(0xffffffffffffff9c, 0x400b00, 0xffffffffffffffff, 
0xffffffffffffffff, 0) = 0


These traces reveal that
   - in ABI 32 (the case that works) the value (uid_t)-1 is being passed
     to the kernel as 0xffffffffffffffff,
   - in ABI n32 (the case that fails) the value (uid_t)-1 is being passed
     to the kernel as 0x00000000ffffffff.

Note that 'uid_t' is 'unsigned int' in userland.


Your test program works find for me under both n32 and n64 ABIs, so I think you must have either an obsolete kernel or obsolete glibc (or perhaps both). Perhaps you should consider upgrading your system.

David Daney

<Prev in Thread] Current Thread [Next in Thread>