linux-kernel - Re: Resource limits interface proposal [was: pull request for writable limits]

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]

Date:	Thu, 6 May 2010 08:37:11 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alexey Dobriyan <adobriyan@...il.com>
cc:	Jiri Slaby <jirislaby@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Neil Horman <nhorman@...driver.com>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: Resource limits interface proposal [was: pull request for 
 writable limits]

On Thu, 6 May 2010, Alexey Dobriyan wrote:

> On Wed, May 5, 2010 at 6:08 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > Ok, I'm not entirely sure we need to care specially about INFINITY,
> > _especially_ since INF is really rather big in 64 bits. So to some degree,
> > making things 64-bit is _less_ likely to make INFINITIES a problem.
> 
> I'm _sure_, someone will mention bloat and performance degradation
> on 32-bit, so there will be config option for 32-bit in-kernel limits.
> And if there will be config option, infinities are better be separated.

Umm. Why?

Adding an INF field will make it essentially impossible to use that thing 
as a compatibility function, and/or together with the legacy rlimit() 
system call. And that is going to be 99.999% of all uses.

I don't think you understand how system calls work. People don't use 
Linux-only features. It's been shown over and over and over again. People 
use the standard interfaces, and they don't _have_ that INF field. We can 
extend ranges by just updating structures (see "stat()" and friends) and a 
recompile will make it use higher limits, but we can't make programs use 
new features.

So there is _no_ upside. There would be _no_ programs ever using it. 

Whether the internal limits for the kernel are 32-bit or not makes 
absolutely zero difference. And my argument is that _if_ they are 64-bit, 
that makes the INF field even _less_ interesting. So they go from "zero 
practical difference" in 32-bit to "f*ck it, nobody can _possibly_ care 
even in theory" in 64-bit.

If the internal limits are 32-bit, then you just turn any 64-bit value 
larger than the (32-bit) RLIM_INFINITY into a RLIM_INFINITY. And that's as 
good as you can get with mixing with the legacy interface anyway.

		Linus
--
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/