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

[Konstantin Belousov]

On Tue, May 15, 2012 at 11:08:37PM +0300, Andriy Gapon wrote:
> 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?
I think that p sizeof(struct thread) from gdb on previous and current
version of the kernel would be a good indicator. If sizes differ, it is
bad.

To be completely sure, calculate offset of the next member in the structure:
in gdb,
p &(((struct thread *)0)->td_blocked)
for previous and current kernels.

> 
> > If not, this breaks KBI.
> 
> I can just revert the commit to not risk an obscure breakage.
> What would you suggest?
Move the new member to the end of the struct thread, and do explicit
zeroing on the thread allocation, if commit changed the layout.

> 
> Thank you for spotting this.
> -- 
> Andriy Gapon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-stable-9/attachments/20120515/62d3bfdd/attachment.pgp