svn commit: r235480 - in stable/9/sys: dev/usb geom geom/mountver i386/conf kern sys

Andriy Gapon avg at FreeBSD.org
Tue May 15 20:08:49 UTC 2012


on 15/05/2012 21:27 Konstantin Belousov said the following:
> On Tue, May 15, 2012 at 05:21:47PM +0000, Andriy Gapon wrote:
>> Author: avg Date: Tue May 15 17:21:46 2012 New Revision: 235480 URL:
>> http://svn.freebsd.org/changeset/base/235480
>> 
>> Log: MFC r230643: stop_scheduler -> td_stopsched Modified:
>> stable/9/sys/sys/proc.h 
>> ==============================================================================
>>
>> 
--- stable/9/sys/sys/proc.h	Tue May 15 17:11:00 2012	(r235479)
>> +++ stable/9/sys/sys/proc.h	Tue May 15 17:21:46 2012	(r235480) @@ -235,6
>> +235,7 @@ struct thread { short		td_locks;	/* (k) Count of non-spin
>> locks. */ short		td_rw_rlocks;	/* (k) Count of rwlock read locks. */ 
>> short		td_lk_slocks;	/* (k) Count of lockmgr shared locks. */ +	short
>> td_stopsched;	/* (k) Scheduler stopped. */ struct turnstile *td_blocked;
>> /* (t) Lock thread is blocked on. */ const char	*td_lockname;	/* (t) Name
>> of lock blocked on. */ LIST_HEAD(, turnstile) td_contested;	/* (q)
>> Contested locks. */
>> 
> Did you verified that there is a gap between td_lk_slocks and td_blocked an
> all tier-1 architectures large enough to adopt td_stopsched without 
> changing the layout of struct thread after the new member ?

I haven't verified that. but I presumed that the gap was either 2 bytes on
32-bit architectures or 6 bytes on 64-bit ones.
What is the proper and doable way of verifying this?

> If not, this breaks KBI.

I can just revert the commit to not risk an obscure breakage.
What would you suggest?

Thank you for spotting this.
-- 
Andriy Gapon


More information about the svn-src-stable mailing list