From: Bruno Haible <bruno@clisp.org>
To: David Daney <david.daney@cavium.com>
Cc: "bug-gnulib@gnu.org" <bug-gnulib@gnu.org>,
"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: bug in fchownat in n32 and 64 ABIs
Date: Fri, 28 Oct 2011 01:59:41 +0200 [thread overview]
Message-ID: <201110280159.41533.bruno@clisp.org> (raw)
In-Reply-To: <4EA9B072.5000107@cavium.com>
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.
Bruno
--
In memoriam Helmuth Hübener <http://en.wikipedia.org/wiki/Helmuth_Hübener>
next prev parent reply other threads:[~2011-10-27 23:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-27 19:07 bug in fchownat in n32 and 64 ABIs Bruno Haible
2011-10-27 19:26 ` David Daney
2011-10-27 21:29 ` David Daney
2011-10-27 23:59 ` Bruno Haible [this message]
2011-10-28 0:26 ` David Daney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201110280159.41533.bruno@clisp.org \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=david.daney@cavium.com \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.