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