Re: [PATCH RESEND v2 1/2] ucount: Fix atomic_long_inc_below() argument type

[Mark Rutland]

On Tue, Jul 22, 2025 at 08:44:29AM +0200, Uros Bizjak wrote:
> On Tue, Jul 22, 2025 at 12:43 AM Andrew Morton
> <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > On Mon, 21 Jul 2025 19:45:57 +0200 Uros Bizjak <ubizjak@xxxxxxxxx> wrote:
> >
> > > The type of u argument of atomic_long_inc_below() should be long
> > > to avoid unwanted truncation to int.
> > >
> > > Fixes: f9c82a4ea89c ("Increase size of ucounts to atomic_long_t")
> >
> > Please (always!) provide a description of the userspace-visible effects
> > of the bug.  That way I (and others) can decide whether the fix should
> > be backported.  And people will be able to determine whether this patch
> > may fix problems which they are observing.  Thanks.
> 
> The patch fixes the wrong argument type of an internal function to
> prevent unwanted argument truncation. It fixes an internal locking
> primitive; it should not have any direct effect on userspace.

AFAICT there's no problem in practice because atomic_long_inc_below() is
only used by inc_ucount(), and it looks like the value is constrained
between 0 and INT_MAX.

In inc_ucount() the limit value is taken from
user_namespace::ucount_max[], and AFAICT that's only written by sysctls,
to the table setup by setup_userns_sysctls(), where UCOUNT_ENTRY()
limits the value between 0 and INT_MAX.

This is certainly a cleanup, but there might be no functional issue in
practice as above.

Mark.