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 16670 invoked from network); 15 Oct 2020 05:01:16 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Oct 2020 05:01:16 -0000 Received: (qmail 26263 invoked by uid 550); 15 Oct 2020 05:01:12 -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 26233 invoked from network); 15 Oct 2020 05:01:12 -0000 MIME-Version: 1.0 Date: Thu, 15 Oct 2020 08:01:00 +0300 From: Alexey Izbyshev To: musl@lists.openwall.com User-Agent: Roundcube Webmail/1.4.4 Message-ID: <948f6fc6f3458f18152c0f8b505beec0@ispras.ru> X-Sender: izbyshev@ispras.ru Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: [musl] Why is setrlimit() considered to have per-thread effect? Hello, 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? Tangentially, setgroups() is not called via __synccall(), though it does have per-thread effect. Is this intentional? Alexey [1] https://git.musl-libc.org/cgit/musl/commit/?id=544ee752cd38febfa3aa3798b4dfb6fabd13846b [2] https://elixir.bootlin.com/linux/v5.9/source/kernel/sys.c#L1566