linux-kernel - Re: [PATCH 1/3 v5] kernel/fork.c: new function for max

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] [day] [month] [year] [list]

Date:	Wed, 25 Feb 2015 13:07:12 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Heinrich Schuchardt <xypron.glpk@....de>
cc:	Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Aaron Tomlin <atomlin@...hat.com>,
	Andy Lutomirski <luto@...capital.net>,
	Davidlohr Bueso <dave@...olabs.net>,
	"David S. Miller" <davem@...emloft.net>,
	Fabian Frederick <fabf@...net.be>,
	Guenter Roeck <linux@...ck-us.net>,
	"H. Peter Anvin" <hpa@...or.com>, Jens Axboe <axboe@...com>,
	Joe Perches <joe@...ches.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Kees Cook <keescook@...omium.org>,
	Michael Marineau <mike@...ineau.org>,
	Oleg Nesterov <oleg@...hat.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Prarit Bhargava <prarit@...hat.com>,
	Rik van Riel <riel@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Vladimir Davydov <vdavydov@...allels.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3 v5] kernel/fork.c: new function for max_threads

On Wed, 25 Feb 2015, Heinrich Schuchardt wrote:

> > I disagree strongly: it's better to first do low-risk 
> > cleanups, then do any fix and other changes.
> > 
> > This approach has four advantages:
> > 
> >   - it makes the bug fix more apparent, in the context of 
> >     an already cleaned up code.
> > 
> >   - it strengthens the basic principle that 'substantial 
> >     work should be done on clean code'.
> > 
> >   - on the off chance that the bugfix introduces problems 
> >     _upstream_, it's much easier to revert in a late -rc 
> >     kernel, than to first revert the cleanups. This 
> >     happens in practice occasionally, so it's not a
> >     theoretical concern.
> > 
> >   - the _backport_ to the -stable kernel will be more 
> >     robust as well, because under your proposed structure, 
> >     what gets tested upstream is the fix+cleanup, while the
> >     backport will only be the fix, which does not get 
> >     tested by upstream in isolation. If there's any 
> >     (unintended) side effect of the cleanup that happens to
> >     be an improvement, then we'll break -stable!
> > 
> > It is true that this makes backports a tiny bit more 
> > involved (2 cherry-picks instead of just one), but -stable 
> > kernels can backport preparatory patches just fine, and 
> > it's actually an advantage to have -stable kernel code 
> > match the upstream version as much as possible.
> > 
> > Thanks,
> > 
> > 	Ingo
> > --
> 
> Hello David,
> 
> to my understanding the biggest no-go for you was that patch 1/3
> introduces a function argument that is not needed until patch 3/3.
> 

Your series is adding an unused argument in patch 1 and passes in UINT_MAX 
for no clear reason.  Patch 2 then starts to use the argument because the 
new helper function needs to cast to u64 and you want to prevent overflow, 
so the UINT_MAX becomes apparent but should rather be part of the 
implementation of the function that does the casting.  

Futhermore, the most significant part of the review still hasn't been 
addressed: the fact that doing (u64)totalram_pages * (u64)PAGE_SIZE can 
overflow your own numerator, so the calculation will need to be changed 
itself.

> Could you accept the sequence proposed by Ingo if I leave away the
> argument max_threads_suggested in patch 1 and 2 and only introduce it in
> patch 3?
> 

I'm not the person who will be merging these, so feel free to follow the 
guidance of whoever will be doing that.  I think if there was inspection 
of the series that it's really two things proposed together: a 
divide-by-zero bugfix and changing threads-max to respect limits.

I understand there is depdenencies on the same code between those two 
things so proposing them as part of the same patchset is good, but I would 
have proposed the current divide-by-zero bugfix first which can be done 
solely in fork_init() and then change threads-max afterwards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/