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

Attachment: pgpBGxo9sbx11.pgp
Description: PGP signature

Reply via email to