[systemd-devel] [PATCH] Fix broken syscall(__NR_fanotify_mark... on 32bit mips.

[David Daney]

On 04/20/2011 06:18 PM, fykcee1 at gmail.com wrote:
> 2011/4/21 Eric Paris<eparis at redhat.com>:
>> I am pretty arch stupid, and I have no idea at all if it is related, but
>> I'm looking at kernel commit 5e844b31c2ace282ab8bea630b63e0212d9532d4
>> which wires up the fanotify syscalls for mips.  I see that it used a u64
>> for a3 and a4 when these are only going to be 32 values.  Does that
>> matter?  I also see that some prototype such as sys32_readahead()
>> explicitly added a pad into the 32 helper.  Should we be doing that?
> This will break the direct system call way.
>
>> I also notice that the naming of arguments seems wrong (although it
>> shouldn't matter)
>>
>> SYSCALL_DEFINE6(32_fanotify_mark, int, fanotify_fd, unsigned int, flags,
>>                 u64, a3, u64, a4, int, dfd, const char  __user *, pathname)
> IMHO, rearrange the order of arguments can do the trick(But API
> changes). e.g. exchange positions of 'mark' and 'flags'. mark will in
> a 64-aligned position in case of indirect syscall. In direct syscall,
> libc can take care of it.
>

IMHO, the API is set in stone.  So any talk of changing it is moot.

David Daney