Re: [PATCH] devpts: fix pty count limit off by one

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Aug 04, 2026 at 05:52:52PM +0800, Yichong Chen wrote:
> Hi Greg,
> 
> Yes, this is user-visible.

Sorry, always include the proper context, and respond after email text.
Remember, some of us get 1000+ emails a day to deal with.

For specifics:

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

> The reason I sent the patch is that this used to allow pty_count to reach
> the configured limit.  Before commit 0f0a0e54a2a1 ("devpts: Convert to new
> IDA API"), devpts_new_index() checked the old pty_count first and only
> incremented it after the allocation succeeded:
> 
>   if (pty_count >= limit)
>           return -ENOSPC;
>   ...
>   pty_count++;
> 
> After that commit, the code started using atomic_inc_return(), but kept the
> >= comparison:
> 
>   if (atomic_inc_return(&pty_count) >= limit)
>           goto out;
> 
> So a count equal to the configured limit became rejected.  That makes
> kernel.pty.max behave as an effective max - 1 limit.
> 
> I thought allowing the count to reach kernel.pty.max again would better
> match the usual interpretation of a "max" sysctl.  But I agree this also
> changes visible behavior again, and the current max - 1 behavior has been
> around since 2018.
> 
> So if you prefer to preserve the existing behavior for compatibility, I am
> fine with dropping the patch.

What is currently breaking that was working just fine with the way the
code is today?  If nothing, then we should probably leave it alone,
right?

thanks,

greg k-h