public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* /proc/sys/kernel/pty/nr broken, possibly since 2.6.28
@ 2009-11-05 23:51 H. Peter Anvin
  2009-11-06  1:04 ` H. Peter Anvin
  0 siblings, 1 reply; 2+ messages in thread
From: H. Peter Anvin @ 2009-11-05 23:51 UTC (permalink / raw)
  To: Alan Cox, Sukadev Bhattiprolu; +Cc: LKML, Greg KH

I just noticed that /proc/sys/kernel/pty/nr is broken, and the most
likely culprit seems to be the series of checkins that include 8b0a88d5
and bf970ee4, during the 2.6.28 merge window.  This is thus a
regression.  I haven't verified that the bug really goes that far back
-- I should do a bisection -- but it is at least present in 2.6.30.9 and
2.6.32-rc6.

The symptom is that /proc/sys/kernel/pty/nr is properly increased, but
never decreased when a pty gets dropped.  It is in fact rather trivial
to escalate /proc/sys/kernel/pty/nr far above /proc/sys/kernel/pty/max.

As far as I read this series, the indent was to have this accounting
handled in pty_unix98_remove(), however, it would appear that that
function never gets called.  I'm wondering if this may be a symptom of a
bigger problem as well.

	-hpa

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: /proc/sys/kernel/pty/nr broken, possibly since 2.6.28
  2009-11-05 23:51 /proc/sys/kernel/pty/nr broken, possibly since 2.6.28 H. Peter Anvin
@ 2009-11-06  1:04 ` H. Peter Anvin
  0 siblings, 0 replies; 2+ messages in thread
From: H. Peter Anvin @ 2009-11-06  1:04 UTC (permalink / raw)
  To: Alan Cox, Sukadev Bhattiprolu; +Cc: LKML, Greg KH

On 11/05/2009 03:51 PM, H. Peter Anvin wrote:
> I just noticed that /proc/sys/kernel/pty/nr is broken, and the most
> likely culprit seems to be the series of checkins that include 8b0a88d5
> and bf970ee4, during the 2.6.28 merge window.  This is thus a
> regression.  I haven't verified that the bug really goes that far back
> -- I should do a bisection -- but it is at least present in 2.6.30.9 and
> 2.6.32-rc6.
> 
> The symptom is that /proc/sys/kernel/pty/nr is properly increased, but
> never decreased when a pty gets dropped.  It is in fact rather trivial
> to escalate /proc/sys/kernel/pty/nr far above /proc/sys/kernel/pty/max.
> 
> As far as I read this series, the indent was to have this accounting
> handled in pty_unix98_remove(), however, it would appear that that
> function never gets called.  I'm wondering if this may be a symptom of a
> bigger problem as well.
> 

Bisection confirms that the bug was introduced during this commit series:

There are only 'skip'ped commit left to test.
The first bad commit could be any of:
8b0a88d5912ab549d5adac2c8498ecdaae5319a5
73ec06fc5f5c8e1097a7a4a4ab2d7c6c3a007e81
7d7b93c1452f381350dbaf276a63357fa6559e6d
bf970ee46e0fb363c8df4393229121d54330a98e
We cannot bisect more!

This series of skipped commits are ones during which
/proc/sys/kernel/pty doesn't exist at all.

	-hpa

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-11-06  1:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-05 23:51 /proc/sys/kernel/pty/nr broken, possibly since 2.6.28 H. Peter Anvin
2009-11-06  1:04 ` H. Peter Anvin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox