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, 06 May 2010 17:46:12 +0200
From:	Jiri Slaby <jirislaby@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Alexey Dobriyan <adobriyan@...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 05/05/2010 05:08 PM, Linus Torvalds wrote:
> On Wed, 5 May 2010, Jiri Slaby wrote:
>> The drawback is when a 32-bit user passes down a value >= (1 << 32),
>> EINVAL shall occur.
> 
> I'd almost prefer to just turn them into RLIMIT_MAX. If somebody asks for 
> a really huge limit that is bigger than the max we already have, doesn't 
> RLIMIT_MAX sound like the right thing?

Yes, silently setting the highest possible value (INFINITY) is OK too
(as we cannot do better anyway).

>> Just a side note, we cannot use the rlimit64 name which is already
>> reserved in glibc headers for limits handling.
> 
> What does the glibc 'struct rlimit64' look like? It's the structure name 
> that matters, since the system call name would presumably be 'prlimit64()' 
> due to the pid thing.
> 
> And if the glibc rlimit64 matches what we would use, I think we can decide 
> to just re-use it.

With glibc-2.11.1 which I have includes from:
#ifdef __USE_LARGEFILE64
struct rlimit64
  {
    /* The current (soft) limit.  */
    rlim64_t rlim_cur;
    /* The hard limit.  */
    rlim64_t rlim_max;
 };
#endif

where rlim64_t expands to __u_quad_t which is
#if __WORDSIZE == 64
typedef unsigned long int __u_quad_t;
#elif defined __GLIBC_HAVE_LONG_LONG
__extension__ typedef unsigned long long int __u_quad_t;
#endif

so something like our u64. The structure is the same to what we are
about to use. If nobody objects?

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