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 19:13:30 +0300
From: Alexey Izbyshev <>
Subject: Re: Why is setrlimit() considered to have per-thread effect?

On 2020-10-15 18:49, Rich Felker wrote:
> setrlimit implemented in terms of prlimit does; as far as I can tell
> prlimit does not perform any process-global action itself but just
> lets you target different tasks. This means we *could* "optimize"
> setrlimit to skip __synccall and instead just iterate over the thread
> list and SYS_prlimit each one from the calling thread context.
> The prlimit function on the other hand behaves as the Linux syscall
> and lets you set thread-specific limits.
But in my understanding, prlimit() sets process- (not thread-) specific 
limits, and have done so since its introduction[1]. The code operates on 
"signal" structure which is shared between threads of a thread group. 
Further, an earlier commit[2] explicitly says that "...rlimit are
per process and not per-thread.". It's true that in pre-2.6.10 kernels 
setrlimit() operated in per-thread limits (see my reply to Szabolcs), 
but it's not related to prlimit() syscall, which was added much later.

To be clear, I did not propose to optimize setrlimit() in my initial 
email, I was just surprised that synccall() is needed at all. But if we 
want optimization, it seems that trying prlimit() first and falling back 
to synccall() in case of ENOSYS would be what we want.


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.