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 27314 invoked from network); 15 Oct 2020 16:13:45 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Oct 2020 16:13:45 -0000 Received: (qmail 3961 invoked by uid 550); 15 Oct 2020 16:13:41 -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 3942 invoked from network); 15 Oct 2020 16:13:41 -0000 MIME-Version: 1.0 Date: Thu, 15 Oct 2020 19:13:30 +0300 From: Alexey Izbyshev To: musl@lists.openwall.com In-Reply-To: <20201015154925.GU17637@brightrain.aerifal.cx> References: <948f6fc6f3458f18152c0f8b505beec0@ispras.ru> <20201015085024.GR2947641@port70.net> <20201015154925.GU17637@brightrain.aerifal.cx> User-Agent: Roundcube Webmail/1.4.4 Message-ID: <68e70f27d78c9507631dd2c22187f77d@ispras.ru> X-Sender: izbyshev@ispras.ru Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] 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