svn commit: r192094 - head/sys/kern

[Peter Holm]

On Fri, May 15, 2009 at 09:02:39AM +0200, Ed Schouten wrote:
> Hi Kostik,
> 
> * Konstantin Belousov <kib at FreeBSD.org> wrote:
> > Log:
> >   Do not advance req->oldidx when sysctl_old_user returning an
> >   error due to copyout failure or short buffer.
> >   
> >   The later breaks the usermode iterators of the sysctl results that pack
> >   arbitrary number of variable-sized structures. Iterator expects that
> >   kernel filled exactly oldlen bytes, and tries to interpret half-filled
> >   or garbage structure at the end of the buffer. In particular,
> >   kinfo_getfile(3) segfaulted.
> >   
> >   Reported and tested by:	pho
> >   MFC after:	3 weeks
> 
> Is it possible that this change introduces a regression? Right now
> `pstat -t' gets stuck in an infinite loop. I've added the following
> printf:
> 
> | Index: pstat.c
> | ===================================================================
> | --- pstat.c	(revision 192128)
> | +++ pstat.c	(working copy)
> | @@ -263,6 +263,7 @@
> |  		if (errno != ENOMEM)
> |  			err(1, "sysctlbyname()");
> |  		len *= 2;
> | +		printf("Going to %zu\n", len);
> |  		if ((xttys = realloc(xttys, len)) == NULL)
> |  			err(1, "realloc()");
> |  	}
> 
> pstat on -CURRENT prints:
> 
> |       LINE   INQ  CAN  LIN  LOW  OUTQ  USE  LOW   COL  SESS  PGID STATE
> | Going to 0
> | Going to 0
> | Going to 0
> | ...
> 
> If I use the same patch on RELENG_6, I get the expected result:
> 
> |      LINE RAW CAN OUT IHIWT ILOWT OHWT LWT     COL STATE  SESS      PGID DISC
> | Going to 272
> | Going to 544
> | Going to 1088
> | Going to 2176
> | Going to 4352
> | Going to 8704
> |   sysmouse  0   0   0     0     0    0   0       0 -             0     0 term
> | ...
> 
> So the problem is that sysctl overwrites the len argument with 0, even
> if it returns back to userspace with ENOMEM.
> 
> I see we have two changes in sysctl. In theory it could also be related
> to jhb@'s changes to sysctl locking, but I suspect it's less likely.
> 

I can confirm that it is r192094 that triggers the loop.

- Peter

> -- 
>  Ed Schouten <ed at 80386.nl>
>  WWW: http://80386.nl/

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (FreeBSD)
> 
> iEYEARECAAYFAkoNE48ACgkQ52SDGA2eCwUaEwCbBX5Nb09/6Y1n09wBL4QAB18C
> j24AnRhGs34TjIAWSJDlXfigNOapL2WN
> =nh0e
> -----END PGP SIGNATURE-----