From owner-svn-src-all@FreeBSD.ORG Tue Jan 26 07:10:33 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73D20106568B; Tue, 26 Jan 2010 07:10:33 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id 0BBF88FC1B; Tue, 26 Jan 2010 07:10:32 +0000 (UTC) Received: by iwn42 with SMTP id 42so1346875iwn.9 for ; Mon, 25 Jan 2010 23:10:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=pGyYfaeVRa5dt4QVI9ZVbEYVXIBfNaZcGdrBzPjsF50=; b=qI/MKLD22bbOfb+i5yXjENTMucDE6Y2tQgVpT0KyeJn7r0hwC02OW45QW1lFZ1xQBQ hqf+MYcVpmTEGzYmT+F12YuDrvKFyeBUCrFsyJbtESDzGh68cys+XaQdfeK9twB4oyYM NYeD3pGvrBrw5vQmPEyCdNgyrMBulpoZ3ohl8= 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=uruaWmGV6PVS9d/EC8qF2zUxAn4kZfWpXXurlvDAFytOIa+dq+6Vs0zVI41bxKZ8If eDL0xjDTf+gs86+vSWE5zMRq0qqxjXM5CkpHS6x/TaVmCcpEo3cs1dL/ry/2cpND6l+L gb5fQ+q7uxmef0I8wNCKDKe7d9pORPrPBfyag= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.159.129 with SMTP id j1mr48278ibx.81.1264489825184; Mon, 25 Jan 2010 23:10:25 -0800 (PST) In-Reply-To: References: <201001231554.o0NFsMbx049837@svn.freebsd.org> Date: Tue, 26 Jan 2010 08:10:25 +0100 X-Google-Sender-Auth: 27597bf6ad1e375e Message-ID: <3bbf2fe11001252310r408a6be4j9bc42618394b3e3d@mail.gmail.com> From: Attilio Rao To: Rob Farmer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Marius Strobl Subject: Re: svn commit: r202889 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 07:10:33 -0000 2010/1/26 Rob Farmer : > On Sat, Jan 23, 2010 at 7:54 AM, Attilio Rao wrote: >> Author: attilio >> Date: Sat Jan 23 15:54:21 2010 >> New Revision: 202889 >> URL: http://svn.freebsd.org/changeset/base/202889 >> >> Log: >> =C2=A0- Fix a race in sched_switch() of sched_4bsd. >> =C2=A0 =C2=A0In the case of the thread being on a sleepqueue or a turnst= ile, the >> =C2=A0 =C2=A0sched_lock was acquired (without the aid of the td_lock int= erface) and >> =C2=A0 =C2=A0the td_lock was dropped. This was going to break locking ru= les on other >> =C2=A0 =C2=A0threads willing to access to the thread (via the td_lock in= terface) and >> =C2=A0 =C2=A0modify his flags (allowed as long as the container lock was= different >> =C2=A0 =C2=A0by the one used in sched_switch). >> =C2=A0 =C2=A0In order to prevent this situation, while sched_lock is acq= uired there >> =C2=A0 =C2=A0the td_lock gets blocked. [0] >> =C2=A0- Merge the ULE's internal function thread_block_switch() into the= global >> =C2=A0 =C2=A0thread_lock_block() and make the former semantic as the def= ault for >> =C2=A0 =C2=A0thread_lock_block(). This means that thread_lock_block() wi= ll not >> =C2=A0 =C2=A0disable interrupts when called (and consequently thread_unl= ock_block() >> =C2=A0 =C2=A0will not re-enabled them when called). This should be done = manually >> =C2=A0 =C2=A0when necessary. >> =C2=A0 =C2=A0Note, however, that ULE's thread_unblock_switch() is not re= aped >> =C2=A0 =C2=A0because it does reflect a difference in semantic due in ULE= (the >> =C2=A0 =C2=A0td_lock may not be necessarilly still blocked_lock when cal= ling this). >> =C2=A0 =C2=A0While asymmetric, it does describe a remarkable difference = in semantic >> =C2=A0 =C2=A0that is good to keep in mind. >> >> =C2=A0[0] Reported by: =C2=A0 =C2=A0 =C2=A0Kohji Okuno >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 >> =C2=A0Tested by: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Giovanni Trema= terra >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 >> =C2=A0MFC: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A02 weeks >> >> Modified: >> =C2=A0head/sys/kern/kern_mutex.c >> =C2=A0head/sys/kern/sched_4bsd.c >> =C2=A0head/sys/kern/sched_ule.c > > Hi, > > This commit seems to be causing me a kernel panic on sparc64 - details > are in PR 143215. Could you take a look before MFCing this? I think that the bug may be in cpu_switch() where the mutex parameter for sched_4bsd is not handled correctly. Does sparc64 support ULE? I don't think it does and I think that it simply ignores the third argument of cpu_switch() which is vital now for for sched_4bsd too (what needs to happen is to take the passed mutex and to set the TD_LOCK of old thread to be the third argument). Unluckilly, I can't do that in sparc64 asm right now, but it should not be too difficult to cope with it. Attilio --=20 Peace can only be achieved by understanding - A. Einstein