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 71AA7C54798 for ; Tue, 5 Mar 2024 08:42:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0776D6B008C; Tue, 5 Mar 2024 03:42:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 029236B0095; Tue, 5 Mar 2024 03:42:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E31F46B0096; Tue, 5 Mar 2024 03:42:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CDE3A6B008C for ; Tue, 5 Mar 2024 03:42:38 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id A0887A0261 for ; Tue, 5 Mar 2024 08:42:38 +0000 (UTC) X-FDA: 81862344396.30.F505BC1 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf26.hostedemail.com (Postfix) with ESMTP id 76B7D140007 for ; Tue, 5 Mar 2024 08:42:35 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=e0QoQcRc; spf=pass (imf26.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709628155; 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=0aPmFlqjRQ1wEA82sX+yI5Rq+jJ6b47MW7dFjOO9VPE=; b=z2x70d3AJ6R7MokGddQQBW2/sH0evJRdfdSYBrub/MD0BYH+/m2Wr+cuODZWEqVmioqjld 753b9gR8qZjzFwhtN1+kfzBdWzG1OLVj763PSnpnIWH4etRGo5mHeMQ/xuDw+9X5atvPHx EiBmuEM2um4SmUwOWgqXsDKwSH54PNc= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=e0QoQcRc; spf=pass (imf26.hostedemail.com: domain of brauner@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709628155; a=rsa-sha256; cv=none; b=wrDVgyRE95b95xMTJbaSDof34FZXThLJhlBcgYlr4g+R4kpp9ZMp4FzpI/mGk8YTDzlyY+ mk1+T2BtRrRIomBIy4tIY5GgrfpJ+AiWqB54XvAsX/DoT6v4J8PC1l2Ro8sxuuXw8vu2qq WDN80pDtwd0RfNUhaEn/vltGGuHuMGI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 98F55CE1729; Tue, 5 Mar 2024 08:42:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14442C433F1; Tue, 5 Mar 2024 08:42:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709628151; bh=uoo3zKerEHzMgEHlrnPwSr6IBKYesoBCdKdQ1mTQyFQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=e0QoQcRcsy8PoOylzJNBfp483uR0YHLu3b7a3mt0nHRsOipYeHo3BCRkYsM8eC3b1 cbJzqJrd9fNXd9dTUGulYuOjouAtORBDtHfsBUM8kZj0CFrvNTyTX7CVpy9+KC23Jt BQSK1qmCJhZ0PD84pcpVcPb9Qy04y2F1JrKAtpBWdDBRCzQPYDLmWfpXk7OwxU8Z2N /RBOt+EBYy+LU4AOSUDYb5IrMpQFo5hZcz89ZKY8dO2FjGHeqK4J7byRUZ153b9dXT f4Q91kQzDdi3y4BsdPXvHW9G6VNDWUBIFuwlbgXrR5bFa30AABX823vzMNNJ5r8JMQ pd1+EE2FOohNg== Date: Tue, 5 Mar 2024 09:42:27 +0100 From: Christian Brauner To: Mikulas Patocka , Hugh Dickins Cc: Alexander Viro , Jan Kara , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] tmpfs: don't interrupt fallocate with EINTR Message-ID: <20240305-abgas-tierzucht-1c60219b7839@brauner> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 76B7D140007 X-Rspam-User: X-Stat-Signature: 8ck3ndfq4cxhiskkr9xu71g565w3sew3 X-Rspamd-Server: rspam01 X-HE-Tag: 1709628155-564061 X-HE-Meta: U2FsdGVkX1/31bWoL5XQznwtdKIDXhHHlWOlrk05wS8XdpIioak9gx74hMpnhCsOZJMF9capw9IloNIEaSBGk4/fC3tVS7cZ981XMhFKLQT9hzxK0W09D7OWIE3ZEs9njn2BWnErvkouIEC6EZM/sVLSCuaQTdgACfTEqVj5fQIdIVCa/BNh2CxlZ1WPz232win3kaRl4TL5agKU574K5B6eXxrCIliY2PhRtE1yM2RYua7Z6YG8Ry5Ugu8J5i767lnWtBDADcQA986opM2xcicgG+5GJCRVwOwqU/gs38CYB8/1Vu4jVlG4rmzWaDMn5PHitsK6muCE9YH+Ic5Zlrv6FsaskBf2qib8ykTdOOL2TlXzKNlK/w9Ki2LySDHA1bbU6TseO4b5Yz35v17Z9PyXpej6YXAJ1KRJQGdHueoEiQvkF44g21X6NkHSwkxrBpwkfpTcdaUzbaglgThEMgQE+vSmpe/5Pm8Xm7GFdTgX+KLGjnnHqeg7xDhUR+FHUFVRdEXwJ6BQ05hEpsFbnDlMkI2YF61Nu583qN2NQULL3I1jFm+TioiPlt1+CK06Boo+qZ9D02s0pblHYi8HBMQfCrNlPh85Va0o/U2AtuqVljvxW2LkX/FZGbPZBeJmPW7PCrl2FxG9d9CwC0AUYjWdm1D2Z14bd/jGSzxNpvRCkEPesStK6OLP0x3hA5byX3A2ltIr6XDWE+xyGHCWLQGxZg/n6cvKdX+vzDMhQGgB3Zv0o/+78MtnAbQduJTU7i9Mz4thrISyh9DtcUUhNoJPmlYmeInhXsT7HkJ7YjSqjvlS6AAVItiatgaCECIRGQQzgaJl9KCteHxKdfcfMKxJ6fdIbwVohoJ3N9i9+DFuw1qUhFVE+580FORXlDkapJThCf2RhdLsupNvVmcBtIKLYODIarBF54rj2kA/ArHy0OfQOAxqPac0IoFjQMEBvZooIuglsT5w7CvAkBh +uM1GoRr JH6DZ+vSFxrVXQJVZ1CIznrXPWxaQ/CJsfzs3cW9YQv3YOa/VsSovQWNKUoUmHqej2sZVH1El/+XkzRTWqlmp1v1vj5l6sTESxe5lH3z8ok078rhgG0p2Ucs9KoTyVtZn9vpShQSSemEnJ3lKd0ctsdqpuxs+fr1DB+gFEQ2WbRi1WuUL96phul7byeODho6v507hQM2mngfo9i1clOgAyhxhpg/JITKkbdaKL3ZHoc2c++AMsRWSoPqB4apUEkcbIY4S9XknVWRw+lU= 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 Mon, Mar 04, 2024 at 07:43:39PM +0100, Mikulas Patocka wrote: > Hi > > 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?