From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60E23C48BF6 for ; Thu, 7 Mar 2024 10:46:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E4C916B0146; Thu, 7 Mar 2024 05:46:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DFD106B0147; Thu, 7 Mar 2024 05:46:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9E116B0148; Thu, 7 Mar 2024 05:46:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id B5F346B0146 for ; Thu, 7 Mar 2024 05:46:06 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 863AC121142 for ; Thu, 7 Mar 2024 10:46:06 +0000 (UTC) X-FDA: 81869913132.22.07BDFA2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id CC2CB140013 for ; Thu, 7 Mar 2024 10:46:04 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ACeHsAnb; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709808364; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ODcbcfN4eVGJWlquQ5n8UDa9/ayWWJqoOlaV61fWtnI=; b=qNI5WrbFh2X/L+h5cvkLIltIGC0IuDOaBghlWYd6WTU2X+8xWndbCDQ0L5LYSw6GRWkQoz q4CT3xhVqqyp7WzBojCabnFEzywnx0gJSv7FlcMWaleHEr8AqKgKJGXTW0EjMrYCv/QgDY n/Pglb1o9xeZfhmOOJq8WoGWQB0Vyvo= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ACeHsAnb; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709808364; a=rsa-sha256; cv=none; b=UhsHQaz0FUqLXpVGwS0jm3WaVkwKDH/+dYnzopZdHZyBI/fJxBcnuEQCwrRAjy76Fh1y4K WF7iWtIyiJ1e1aU2ZyRXaHN6Gx2b5JihgTKAUpItNq2YeLs4w0BcVvQTpZoRNCIQCxAPLc 0znJU582L2DqseX9LymJxABAuMNkHrs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id EF70461C0D; Thu, 7 Mar 2024 10:46:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2F7BC433C7; Thu, 7 Mar 2024 10:46:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709808363; bh=28T7aDiv+0JpHXnY5aFECCvvkSp0ZHPva8vQV4qDAHw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ACeHsAnb3cwLoFnulFkcinhb7epPaF/c55XZj2m5nQJ1pJvzeLulMFiBH4TZHT1xC BJoT5emLpqWz8rWrQzPSJDnfARaCEscCgcqVewmk4olOZ9nt+pWkuyRpqTpW+17Bw1 cfbFx9okRNJVSm7pNXg3bHWTKvJBX3w5vjFRzvYiPEuA7e7UShPJQR7YSJV6N9ALkj nfVtQ+E+lNq++WlX7/IV322774n49W9JIVTw+OKht02y5+W6fcdFQIQwJMtODkqUhE XJmSDJyelW5cCMvWEt/eLgONqafMJ67zo5V74YQgDldsTNlWxC7+MuuXMqnBhobyk0 bOF00GwIg/Flg== Date: Thu, 7 Mar 2024 11:45:59 +0100 From: Christian Brauner To: Jan Kara Cc: Mikulas Patocka , Hugh Dickins , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] tmpfs: don't interrupt fallocate with EINTR Message-ID: <20240307-kultur-ankam-39d311604493@brauner> References: <20240305-abgas-tierzucht-1c60219b7839@brauner> <20240306174911.ixwy2kto33cfjueq@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240306174911.ixwy2kto33cfjueq@quack3> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: CC2CB140013 X-Stat-Signature: w516anwi58xy7sytgh39opgrjqe1tfnq X-HE-Tag: 1709808364-459276 X-HE-Meta: U2FsdGVkX183slHERenbMsC3QyXqMxyKIIqARiL0Lw6SKDr3b2vySWHCbADroPOj/FwPb/OOyMdCmGe7LZxwYM+vvkc9Vg3ixjdvFkCvYvKY6fDr3kZvyH0jTp/VI+1JFaBK8GXXcZURZWn83QU9QkN5eI+5UdUjSZBMKHNj3xEOjYnCANCAwJeqRWu5nu2b8fQOuWX61ud9DbBje4n9+SZbCf62hUhWHTCp9/2OMTW8Vh3g9+2TxS4Y3C+UUUsMf0sPndGoIrcEY5hv3pfNYyI4ANOwzbFKCgGSJq5QWJ/Y0q0L3dDdjgwOJy57oZSYJX3MB8nXCXuhF4p+3reSLo83ToDPQo5OCZ1+y9VyCVWeYfyGykngF+tD5quSJvwRsSIfn26QCI5/E9YHWP8i6CuiKo7UP9wzIgicCpudwbn8UHWH7Im7Wl4Q/LRq5RIhdjxpXj59q5MFmAidXRIIrfgIV7RbhmOGtD46N7zEs8HsS0E5aFAdzRZrfkxi2mpbjUqnemFX3jPv2g4ckgTIMHh/nZbBe8ybcyYtQMwF2lTsnLtD/wiDIr/bQi87qzHSWcoPyWVtBPjACRxpaI2+la6cxLJ0QWakHo8zyBg44uWWY5oZKEKU647MSmzz8SGfQJU1RqVfDmbYs/sFoj3I+sjkZj/Z1XGFGgg0QhhZG1Lkh055w9qLf0Q2KQMwtScblVmclMAcn5hkLQJTC2KabePHsuxFmPqQMpFl2+ZUPDaMBNevbPUESJQ3F9Kb4etvd0+ybsXVwWDGhvXKWgteW3aQin/5cnBx3eX+6cJhbwBLqw7WsyZWh6auSrBI8BEV41XAJ2UIaRzyyW9NIP1I0oxKQExXTDlwCs4xbqAFzZjxvvZZfzTAt3CFYf40HIwUSLhYfdXHfvfPnALPZK0oA6iMONViIah+5h0/6r63XAvK1SCZQe989yOoqHWnMJuNJXhjwimvj7IK70zn7j0 0p7j71Wm vtKh2ZRwr8jpQSqHaT1Md3Gjuhf1cdFxy34M6LRqsngiAvTPBG62DSHSQ7sUQKdXHpJuJzk31sr6f4I5jHhWHwaGtS3Gf/1VNO+knL5AIiLCzJ2i3MwSQh5/imJIb8y2I63XlKEG1e3wlAImO0/xz6prf9ODKyhN3g6WlQ14hx3jWbhb45B0rRDVtnWGKsLq5MPkEEr0PBSVcveYAcuHD8qw5fulu4KFvFDNllopQc0bOaHU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Mar 06, 2024 at 06:49:11PM +0100, Jan Kara wrote: > Hello, > > On Tue 05-03-24 09:42:27, Christian Brauner wrote: > > On Mon, Mar 04, 2024 at 07:43:39PM +0100, Mikulas Patocka wrote: > > > I have a program that sets up a periodic timer with 10ms interval. When > > > the program attempts to call fallocate on tmpfs, it goes into an infinite > > > loop. fallocate takes longer than 10ms, so it gets interrupted by a > > > signal and it returns EINTR. On EINTR, the fallocate call is restarted, > > > going into the same loop again. > > > > > > fallocate(19, FALLOC_FL_KEEP_SIZE, 0, 206057565) = -1 EINTR (Přerušené volání systému) > > > --- SIGALRM {si_signo=SIGALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_int=0, si_ptr=NULL} --- > > > sigreturn({mask=[]}) = -1 EINTR (Přerušené volání systému) > > > fallocate(19, FALLOC_FL_KEEP_SIZE, 0, 206057565) = -1 EINTR (Přerušené volání systému) > > > --- SIGALRM {si_signo=SIGALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_int=0, si_ptr=NULL} --- > > > sigreturn({mask=[]}) = -1 EINTR (Přerušené volání systému) > > > fallocate(19, FALLOC_FL_KEEP_SIZE, 0, 206057565) = -1 EINTR (Přerušené volání systému) > > > --- SIGALRM {si_signo=SIGALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_int=0, si_ptr=NULL} --- > > > sigreturn({mask=[]}) = -1 EINTR (Přerušené volání systému) > > > fallocate(19, FALLOC_FL_KEEP_SIZE, 0, 206057565) = -1 EINTR (Přerušené volání systému) > > > --- SIGALRM {si_signo=SIGALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_int=0, si_ptr=NULL} --- > > > sigreturn({mask=[]}) = -1 EINTR (Přerušené volání systému) > > > > > > Should there be fatal_signal_pending instead of signal_pending in the > > > shmem_fallocate loop? > > > > > > Signed-off-by: Mikulas Patocka > > > > > > --- > > > mm/shmem.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > Index: linux-2.6/mm/shmem.c > > > =================================================================== > > > --- linux-2.6.orig/mm/shmem.c 2024-01-18 19:18:31.000000000 +0100 > > > +++ linux-2.6/mm/shmem.c 2024-03-04 19:05:25.000000000 +0100 > > > @@ -3143,7 +3143,7 @@ static long shmem_fallocate(struct file > > > * Good, the fallocate(2) manpage permits EINTR: we may have > > > * been interrupted because we are using up too much memory. > > > */ > > > - if (signal_pending(current)) > > > + if (fatal_signal_pending(current)) > > > > I think that's likely wrong and probably would cause regressions as > > there may be users relying on this? > > I understand your concern about userspace regressions but is the EINTR > behavior that useful? Sure, something can be relying on terminating I don't know. > fallocate(2) with any signal but since tmpfs is the only filesystem having Hugetlbfs has the same logic. > this behavior, it is fair to say there are even higher chances some > application will be surprised by this behavior when used on tmpfs as > Mikulas was? So I wouldn't be that opposed to this change. *But* tmpfs has > a comment explaining the signal_pending() check: > > /* > * Good, the fallocate(2) manpage permits EINTR: we may have > * been interrupted because we are using up too much memory. > */ > > Now I'd expect the signal to be fatal in this case but we definitely need > to make sure this is the case if we want to consider changing the test. Right now fallocate() is restartable. You could get EINTR and then retry. Changing this to fatal_signal_pending() would mean that this property is lost. The task will have to be wiped. If this is only done for the sake of the OOM killer then we can probably try and change it. But then we'd need to also reflect that on the manpage.