Date: Thu, 15 Oct 2020 19:13:30 +0300 From: Alexey Izbyshev <izbyshev@...ras.ru> To: musl@...ts.openwall.com 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. The code operates on "signal" structure which is shared between threads of a thread group. Further, an earlier commit 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.  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c022a0acad534fd5f5d5f17280f6d4d135e74e81  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7855c35da7ba16b389d17710401c4a55a3ea2102
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.