From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 11 16:01:42 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 824E71065677; Sun, 11 Jul 2010 16:01:42 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3762D8FC14; Sun, 11 Jul 2010 16:01:41 +0000 (UTC) Received: by iwn35 with SMTP id 35so4806927iwn.13 for ; Sun, 11 Jul 2010 09:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=g6zCkwaCLAWT1TzRyX9wLljrJ+JaecmsjL865Za1WZQ=; b=vCmI2AOIQxRBw4PxLWRIEpdC2h6DpLvFjKDc79xFa31IRPLVN/5Nflq3qQvIBNFoa/ xGQtbDeD6AlcgvIF9fZAiP7PLQ3Sc/Rq0wCSiEE55h9GtOHUdK2/rLAOiClt2hOHQIKI fwTaMEKxZF6QnKOZFhFsTyo+PQIhg17DKFtHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Eyqi15cFVlo6o15K+8yU3lmeaKprlSInGTjGn8oX/x2uXxstOMrSnBUeFc2QWegg/D ec5I79QtqU5lh7Eb0uhdIgOEk3Kupd1R9PDxcEu8asj7DDGv9tF0Be8BhsUZC7FhB1Bj /9Lst6mFVOWsR8ZOrb2Vtwd+fnkEC4EhlCUxc= MIME-Version: 1.0 Received: by 10.42.7.74 with SMTP id d10mr4128455icd.30.1278862390832; Sun, 11 Jul 2010 08:33:10 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.42.1.201 with HTTP; Sun, 11 Jul 2010 08:33:10 -0700 (PDT) In-Reply-To: <4C39DBFF.2000307@FreeBSD.org> References: <4C39D92F.4050605@FreeBSD.org> <4C39DB09.6010808@andric.com> <4C39DBFF.2000307@FreeBSD.org> Date: Sun, 11 Jul 2010 08:33:10 -0700 X-Google-Sender-Auth: xghavWCCKlYI9hITRW1y_c2LDIg Message-ID: From: mdf@FreeBSD.org To: Gabor Kovesdan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Dimitry Andric , FreeBSD Hackers Subject: Re: strange problem with int64_t variables X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 16:01:42 -0000 On Sun, Jul 11, 2010 at 7:58 AM, Gabor Kovesdan 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. =A0Maybe some part of it got non-atomically >> assigned? =A0Maybe the wrong word was read? =A0It is hard to tell withou= t >> code... =A0:) >> > > Userland syscall calling: > > killjob(getjid(), SIGINT); =A0//getjid() returns 1 this case, whose type = is > jid_t > > Kernel code: > > int > killjob(struct thread *td, struct killjob_args *uap) > { > =A0 =A0 =A0 =A0struct jobentry *jp, *jtmp; > =A0 =A0 =A0 =A0struct procentry *pp, *ptmp; > > =A0 =A0 =A0 =A0JOBLIST_bWLOCK; > =A0 =A0 =A0 =A0LIST_FOREACH_SAFE(jp,&irix_joblist, entries, jtmp) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (jp->jid =3D=3D uap->jid) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* never reached code, com= parison always fail because > of corrupted value */ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0JOBLIST_WUNLOCK; > > =A0 =A0 =A0 =A0/* not such job */ > =A0 =A0 =A0 =A0td->td_retval[0] =3D -1; > =A0 =A0 =A0 =A0return (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