strange problem with int64_t variables

[mdf at FreeBSD.org]

On Sun, Jul 11, 2010 at 7:58 AM, Gabor Kovesdan <gabor at freebsd.org> wrote:
> Em 2010.07.11. 16:54, Dimitry Andric escreveu:
>>
>> On 2010-07-11 16:46, Gabor Kovesdan wrote:
>>
>>>
>>> I have two int64_t variables in kernel code, first is stored internally
>>> and the second one is passed from a syscall argument. When I print them
>>> with printf %lld modifier, the internal one behaves correctly but the
>>> other one I pass from a syscall has a corrupted value. If I pass 1, it
>>> prints out 3735348794091372545. I'm not doing anything special with it
>>> just reading it out from the struct that was generated with make sysent.
>>>
>>
>> Since 3735348794091372545 is 0x33d69ff000000001, it looks like the upper
>> word got corrupted somehow.  Maybe some part of it got non-atomically
>> assigned?  Maybe the wrong word was read?  It is hard to tell without
>> code...  :)
>>
>
> Userland syscall calling:
>
> killjob(getjid(), SIGINT);  //getjid() returns 1 this case, whose type is
> jid_t
>
> Kernel code:
>
> int
> killjob(struct thread *td, struct killjob_args *uap)
> {
>        struct jobentry *jp, *jtmp;
>        struct procentry *pp, *ptmp;
>
>        JOBLIST_bWLOCK;
>        LIST_FOREACH_SAFE(jp,&irix_joblist, entries, jtmp) {
>                if (jp->jid == uap->jid) {
>                        /* never reached code, comparison always fail because
> of corrupted value */
>                }
>        }
>        JOBLIST_WUNLOCK;
>
>        /* not such job */
>        td->td_retval[0] = -1;
>        return (ENOJOB);
> }

What does struct killjob_args look like?

Is this syscall defined in a module, or an addition to the kernel's
syscalls.master?

Is the user-space 32-bit or 64-bit?  What about the kernel?

Thanks,
matthew