From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24214 invoked from network); 15 Oct 2020 15:49:42 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Oct 2020 15:49:42 -0000 Received: (qmail 26315 invoked by uid 550); 15 Oct 2020 15:49:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26201 invoked from network); 15 Oct 2020 15:49:37 -0000 Date: Thu, 15 Oct 2020 11:49:25 -0400 From: Rich Felker To: musl@lists.openwall.com Cc: Alexey Izbyshev Message-ID: <20201015154925.GU17637@brightrain.aerifal.cx> References: <948f6fc6f3458f18152c0f8b505beec0@ispras.ru> <20201015085024.GR2947641@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201015085024.GR2947641@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Why is setrlimit() considered to have per-thread effect? On Thu, Oct 15, 2020 at 10:50:24AM +0200, Szabolcs Nagy wrote: > * Alexey Izbyshev [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