syscall record for mq_unlink

Hey Steve,

So, Happy Thanksgiving, is this a bug? :P

Audit record:
type=SYSCALL msg=audit(1164127960.194:49): arch=c000003e syscall=241 success=yes exit=0 a0=2aaaaab2171d a1=2aaaaab2171c a2=7fff69a6cab8 a3=2aaaafb31188 items=3 ppid=1758 pid=1791 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="python" exe="/usr/bin/python" subj=abat_u:abat_r:abat_t:s0-s15:c0.c1023 key=(null) type=CWD msg=audit(1164127960.194:49): cwd="/rhcc/lspp/tests/LTP/ltp-merged/testcases/kernel/security/mls/tests/framework"
type=PATH msg=audit(1164127960.194:49): item=0 name="-RNHJnfkU"
type=PATH msg=audit(1164127960.194:49): item=1 name=(null) inode=7385 dev=00:0d mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=abat_u:object_r:abat_tmpfs_t:s0
type=PATH msg=audit(1164127960.194:49): item=2 name=(null) inode=338 dev=00:0d mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmpfs_t:s15:c0.c1023

The syscall prototype in the kernel is as follows:
asmlinkage long sys_mq_unlink(const char __user *u_name)

The function all is:
ret = mq_unlink(msgqid);

The value of char *msgqid is:
2aaaaab2171c

So, the question is:
Why is a0=(msgqid)+1, and why is a1=(msgqid)

I am not sure if this is some crazy "feature" or if this is a real bug. I know there are some syscalls that differ from the glibc-level calls, but this one violates the function internal to the kernel.

Any ideas? This is on the lspp.55 kernel.

Thanks,
Mike

Sounds like it might be a bug. Maybe one of the kernel people could look into it? If not, file a bug and we'll handle it that way.

Thanks,
-Steve

I am seeing the same behaviour with mq_open... I'll file a bug so it doesn't get lost over the holidays, and I'll see if I can get some kernel people on my end to take a peek at it.

Thanks,
Mike