Re: [musl] Why is setrlimit() considered to have per-thread effect?

[Rich Felker <dalias@libc.org>]

On Thu, Oct 15, 2020 at 10:50:24AM +0200, Szabolcs Nagy wrote:
> * Alexey Izbyshev <izbyshev@ispras.ru> [2020-10-15 08:01:00 +0300]:
> > Commit 544ee752cd[1] claims that setrlimit() is per-thread on Linux,
> > similarly to setxid() calls, so it should be called via __synccall(). But
> > this appears to be wrong: the kernel code operates on tsk->signal[2], which
> > is a per-thread-group structure. Glibc doesn't call setrlimit() for each
> > thread either. Am I missing something?
> 
> 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.

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.

> > 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.

I'm not sure about that. We should probably examine whether there's
any intent to change just one thread in real world usage, as well as
whether other systems (e.g. BSDs) do the POSIX-like behavior and make
it process-global. If so I'm inclined to change it to be more
consistent.

Rich