Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Oct 2020 18:50:41 +0300
From: Alexey Izbyshev <>
Subject: Re: Why is setrlimit() considered to have per-thread effect?

On 2020-10-15 11:50, Szabolcs Nagy wrote:
> note that prlimit does not have synccall in
> musl: the kernel implemented the per process
> rlimit setting when prlimit was added.
> (i think this is linux commit
>  1c1e618ddd15f69fd87ccea596769f78c8065504 )
> but older kernels don't have that.
Ah, thank you for checking that, though the transition appear to have 
happened much earlier than the commit you referenced (which is not 
relevant), in pre-git epoch between 2.6.9 and 2.6.10[1, 2]. I was 
confused because Linux man pages never mention that and explicitly say 
"Resource limits are per-process attributes that are shared by all of 
the threads in a process."[3], but I should have checked old sources.

>> Tangentially, setgroups() is not called via __synccall(), though it 
>> does
>> have per-thread effect. Is this intentional?
> that may be a bug, but it's not a posix api
> so not a conformance issue, but a linux issue:
> if other linux libcs don't do synccall then
> that's the defacto interface contract.
FWIW, glibc does synccall since 2011:;a=commit;h=70181fddf14


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.