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 3482CC25B75 for ; Wed, 15 May 2024 23:09:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A831D6B03A7; Wed, 15 May 2024 19:09:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A0C9E6B03AA; Wed, 15 May 2024 19:09:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 885956B03AC; Wed, 15 May 2024 19:09:55 -0400 (EDT) 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 6AA516B03A7 for ; Wed, 15 May 2024 19:09:55 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 19067A04FB for ; Wed, 15 May 2024 23:09:54 +0000 (UTC) X-FDA: 82122174708.21.6915EE2 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id A1CDEC0005 for ; Wed, 15 May 2024 23:09:51 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Ep7+mVF+; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715814592; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fYJdcYOCrtY52szVHROd32Y61zKELNIPF2cnxBmIFbE=; b=5kcySE1u4mhGiTBXnn+Qhq0/mT0ggRbToTHjywl+RLoZEnFk1qQz7cmCrfN/VifrI7WupR mUUVioMxQ55Gm1gWJ1Z3ULXBfrCdzep9YEFH/Enj67m/iFAW1lQIqilnniHqEeN3n+t6Lc Eh58XCxo6c5Ijl9EvT9/wvhXxlDSG+E= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Ep7+mVF+; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715814592; a=rsa-sha256; cv=none; b=Ll0TbY0BXgj0Ehx5CMDqPT0WLBsNyUM1s7Ibed+yumDU9LTjCw7wkRUlv8pcqo/kEc8pL/ wgU21EO8AzaUxZDe1WB2ur1zZ6T+I8BfEvUneGYoUMo8PW5Nq49jDivGg1HskXE5ZWvqVZ yMAa3CtLGpJqafQ745iSrE5Pt/cVibo= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=fYJdcYOCrtY52szVHROd32Y61zKELNIPF2cnxBmIFbE=; b=Ep7+mVF+gMRGYOm4rpCUmli3AI N9Bc6n6YMcNMDwxkLTHiL+zpIgUHFkTZbT1YRvE9BTkojh8IUXojUDYlxYYdKEYBcUuONiMa8uAcP AYKkG0g+FY5nQ29RqM/icWF8hE5T/NDYqvxKgTJlpXe6N3Cnp/JbtsDY3OXuzjdiN4eTUGK5JL9sj yPUD+Hl+oE60rQywJQ5Uqdfk6HS3LMraTIcGDAz65el2leLy/sLIch1Q5FqzWTL4cC2YDQYA8+d0n 20/L07N7CPyO35bR+vI1uRSCqFm9uMf5emNFEwjx2oPamrueM68Gc+fgXodUq7vYha3rqXGL1kand aD6B3Jrw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1s7Nkr-0000000B32v-05gX; Wed, 15 May 2024 23:09:49 +0000 Date: Thu, 16 May 2024 00:09:48 +0100 From: Matthew Wilcox To: Jan Kara Cc: Christian Brauner , linux-fsdevel@vger.kernel.org, Hugh Dickins , linux-mm@kvack.org, Mikulas Patocka Subject: Re: [PATCH] tmpfs: don't interrupt fallocate with EINTR Message-ID: References: <20240515221044.590-1-jack@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240515221044.590-1-jack@suse.cz> X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: A1CDEC0005 X-Stat-Signature: 414y5eqtwqsw73stw5k8jbunpc19k4wo X-HE-Tag: 1715814591-899525 X-HE-Meta: U2FsdGVkX1/I8iMY/BtoBgmVTiKQ1NAeb6oHFVXQHVeuuK8XUDBpyAny2zvk1B2ajRlVNL7vleri+6ijWbzhN6t/BcYfgdcU3V3ZhduwEcuBW3TSfYI16wnbvaiGA95m+tN5v+2K9cGxIjmvSmHHGBxXt6HQTpFG2WJ562O1byC2f+Co+6NiFE+MTUt1ozIhE+ZKCrfxlwqoUNeQbQXY2bjb+1mrEtILLIDMHsMHvJ3wbRysTJ/z9w5q+dZzsVeSqxsY/eQiCCcTHyc7vJl2F2jeu+nSBTHaNkgL6BGnF2cGY6AG9zXWMqv96kpJRmgI//+G5OS5HByTJNHSqUeS2HfTjnYcAu2wl2pPVWrQ/rwqKuEZENs4LV72JfoJhpHvV56kIDf1Ct9WcxKtfcjKCJ8/OhjPd4g25zRbMaWfl/KU6qa7hwcExSCtuenrbo5lsPLOpfRdKrdvaAcEFAZqiHYIv4KTIz4Bi1YA00d3CvW0vjLHWWTraURbBPAkY8AcAl8n5zXPHHZXopnhFK+818u9fZ2fz5at+a+bSu5hie/49ZhnYtz0NatwmO3aC3IOsydPRbgdFoBN7h6EViNwdDSdn9I7FjSIntmRg6EgAVAPiLal+3xA/DTs7KLSNyiSyW4uXxW3u4p1/DkCf7NK2E/7JLvFUpgLZ8iIApF3NSzCdah3btEha8BZMZhKxHs5MPex+Mqt5M17PIP5ot41L0bZb8zMrmc/IaGk7/ASgPi867+CMBlwOL3328lkEq99bs0l71I84G4x6wNWi4Xell8Md5SXgYbTa1ElOmrkfPRlouu0XzfI68esR/fZLGqb3KAtpcv0EHef7037dMp6t8bTGfjXGN15ODuE/dKKwORXu9aDJwpWrbe0f2Snj2VC9b2e1hjAsVOYeSnVNiOUOJYK3xhweXnpkPA4uPKDS6VJRTfG19qeSiKuGcq+IdQByhrhpxvpGoy55BVveaJ zc7lqcOU vfnhuGhcItQQxEWCcpUtq5qLxhK6ZZ/bANhats1HBfd/2iKHfPFNP3K/oiy4wlTp+dYOM88Opo9HHczkJ814kUn3cpA5KpoZpSXaUbnIGfaKLyj//iYAc3vnw1Gd3bKqTFvSCs9kkK5aCeCtS3/3dmVyXU52XvTcBhoenSo8ZZiq4PZXU4NOLKVTJNJcAexVX9/JXDNvZD3E8062gV766sEmABA== 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 Thu, May 16, 2024 at 12:10:44AM +0200, Jan Kara wrote: > From: Mikulas Patocka > > I have a program that sets up a periodic timer with 10ms interval. When > the program attempts to call fallocate(2) on tmpfs, it goes into an > infinite loop. fallocate(2) 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. > > Let's change the signal_pending() check in shmem_fallocate() loop to > fatal_signal_pending(). This solves the problem of shmem_fallocate() > constantly restarting. Since most other filesystem's fallocate methods > don't react to signals, it is unlikely userspace really relies on timely > delivery of non-fatal signals while fallocate is running. Also the > comment before the signal check: > > /* > * Good, the fallocate(2) manpage permits EINTR: we may have > * been interrupted because we are using up too much memory. > */ > > indicates that the check was mainly added for OOM situations in which > case the process will be sent a fatal signal so this change preserves > the behavior in OOM situations. > > [JK: Update changelog and comment based on upstream discussion] > > Signed-off-by: Mikulas Patocka > Signed-off-by: Jan Kara Reviewed-by: Matthew Wilcox (Oracle)