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

[fykcee1 at gmail.com]

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.



-- 
Regards,
- cee1