lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250110133237.61dd14fb@pumpkin>
Date: Fri, 10 Jan 2025 13:32:37 +0000
From: David Laight <david.laight.linux@...il.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Vlastimil Babka <vbabka@...e.cz>, Suren Baghdasaryan
 <surenb@...gle.com>, akpm@...ux-foundation.org, peterz@...radead.org,
 liam.howlett@...cle.com, lorenzo.stoakes@...cle.com, mhocko@...e.com,
 hannes@...xchg.org, mjguzik@...il.com, oliver.sang@...el.com,
 mgorman@...hsingularity.net, david@...hat.com, peterx@...hat.com,
 oleg@...hat.com, dave@...olabs.net, paulmck@...nel.org, brauner@...nel.org,
 dhowells@...hat.com, hdanton@...a.com, hughd@...gle.com,
 lokeshgidra@...gle.com, minchan@...gle.com, jannh@...gle.com,
 shakeel.butt@...ux.dev, souravpanda@...gle.com, pasha.tatashin@...een.com,
 klarasmodin@...il.com, corbet@....net, linux-doc@...r.kernel.org,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH v7 11/17] refcount: introduce
 __refcount_{add|inc}_not_zero_limited

On Wed, 8 Jan 2025 15:06:17 +0000
Matthew Wilcox <willy@...radead.org> wrote:

> On Wed, Jan 08, 2025 at 10:16:04AM +0100, Vlastimil Babka wrote:
> > >  static inline __must_check __signed_wrap
> > > -bool __refcount_add_not_zero(int i, refcount_t *r, int *oldp)
> > > +bool __refcount_add_not_zero_limited(int i, refcount_t *r, int *oldp,
> > > +				     int limit)
> > >  {
> > >  	int old = refcount_read(r);
> > >  
> > >  	do {
> > >  		if (!old)
> > >  			break;
> > > +		if (limit && old + i > limit) {  
> > 
> > Should this be e.g. "old > limit - i" to avoid overflow and false negative
> > if someone sets limit close to INT_MAX?  
> 
> Although 'i' might also be INT_MAX, whereas we know that old < limit.
> So "i > limit - old" is the correct condition to check, IMO.
> 
> I'd further suggest that using a limit of 0 to mean "unlimited" introduces
> an unnecessary arithmetic operation.  Make 'limit' inclusive instead
> of exclusive, pass INT_MAX instead of 0, and Vlastimil's suggestion,
> and this becomes:
> 
> 		if (i > limit - old)
>
...

The problem with that is the compiler is unlikely to optimise it away.
Perhaps:
		if (statically_true(!limit || limit == INT_MAX))
			continue;
		if (i > limit - old) {
			...

	David



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ