[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <68e70f27d78c9507631dd2c22187f77d@ispras.ru>
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[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.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c022a0acad534fd5f5d5f17280f6d4d135e74e81
[2]
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.
