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 E985AC48BF6 for ; Sun, 3 Mar 2024 22:54:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A8736B009D; Sun, 3 Mar 2024 17:54:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 358A26B009E; Sun, 3 Mar 2024 17:54:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 247396B009F; Sun, 3 Mar 2024 17:54:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 16FCA6B009D for ; Sun, 3 Mar 2024 17:54:27 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BF6831A08AD for ; Sun, 3 Mar 2024 22:54:26 +0000 (UTC) X-FDA: 81857233332.01.891777A Received: from out-176.mta0.migadu.com (out-176.mta0.migadu.com [91.218.175.176]) by imf19.hostedemail.com (Postfix) with ESMTP id CB05D1A0013 for ; Sun, 3 Mar 2024 22:54:24 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="flirE8/8"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf19.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.176 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709506465; 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=tBtO++uCH/Gk7Nt1NmLc0KgAdMtxlsr8/WSB+ik87hg=; b=dQNlTDUhpZvreJEg7EnihI0hJBDk2lDnaF8Vja+2EDY1MwMv9+6ntyIzBKaL7RnQIl8DUa /QiiRn3xIyCcvfGxf5LJGmYi3dXAT4/H3tMt0Wa1VLdu2mdkX/xVqsGoxJagTEffzhz2Vs Pf9Guwupbp6VdHUcxayvLSdyX/ghTto= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="flirE8/8"; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf19.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.176 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709506465; a=rsa-sha256; cv=none; b=8CcrRrpFuTQg7GiNsqSQxOn0Isk0VNancl40JCEC5IMDYxvDK/HSbzR3MXSr0x0tmS9bUa t7RHd6v53QTCSgVtxX+rXImU/J9sqy/+fOK12H6aPWjvioRs71VA0ZHLHBU0qa7OPMcB7I GV3ecdmBraw5jbGYBfhYVyUGApNEOuI= Date: Sun, 3 Mar 2024 17:54:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1709506462; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tBtO++uCH/Gk7Nt1NmLc0KgAdMtxlsr8/WSB+ik87hg=; b=flirE8/8ycsMSeDWZs3JrSx1+rFXSr/TsOtDszGEJZTXZuBj7BjBYBie20SQab7M5bxpR+ rmQye+LKENym+ZbSwRAVnxNhniL2PgN7cNKrGfMWi9pYdy91cl2G5uAVGOPXJ1J6kJR6Z/ oOQnqXP4cwmX5UFS8IxPL2JbpsGEAGg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: NeilBrown Cc: Dave Chinner , Matthew Wilcox , Amir Goldstein , paulmck@kernel.org, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel , Jan Kara Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU Message-ID: References: <170925937840.24797.2167230750547152404@noble.neil.brown.name> <170933687972.24797.18406852925615624495@noble.neil.brown.name> <170950594802.24797.17587526251920021411@noble.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <170950594802.24797.17587526251920021411@noble.neil.brown.name> X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: CB05D1A0013 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: sq4oriexokm4he18aea6cu1ppprrrr5m X-HE-Tag: 1709506464-737190 X-HE-Meta: U2FsdGVkX1+B7N0odg98LI0Xb4uVgClEv8ck2ZGsKZNOJL7dbPU3gjzYQhgDQ1fOsduYCUKQp01xNuQg2Vy5duL4eFTrSQBYSEu4zSThuRA4VhqjxPW2d6Yr955ygob/wztgYrfHauUBpir5Qd+Ny4HHvJSdKMHLCMazmidFYqYCcEdJLHa0qYywf/Jn51eeMIOP0ZccJKJGH5+S5RZyqONR/+9n9DMh4hql57ArmfPo4IoIi6dYMenRegnS7mSDdZh+ezmPlf0fwIb8GlLcBtATvCVYcFyUNqu7LeJ2cqLVAwgWqaGz8S/o/ETB2aMTefACH64BVVY947USAs+nxm8K6JDBhl5Trzz4lGSF0uTUwxO0Yo9ELl2fsE/YXAXI0+Vs4qrDQAcOaBIc7GNl6xcoKQz7vJ9M2rdBInwrESEUtFqmaIEzKuMEZXg0AKFkVbzPw+lqiT8XUm6Rew28pnBTFJAkYFLs/xKVxfq0slvL8CPDiQb1ApFAhaOoRreNolqXMmg7mlDiHXp5WbP4KCVGztEVykvUOk29QMOvSu0S9UD5qt0CYEzecSYUQRI+iG6Oqx8kZZedc5rajHG2oJ369EdP0Zth7NeAObyHysIyUS8GpUZ7JtH9uAf6WjHoUU/j9MxhyhuKuoe5PkNdeR9tPJS063UmuDwLc8R8GGmw4zMRXvKVB1NxTD8NpNcfatnu0eupSXwXK4S4SjNe2HIlsC6aB2ScitQNAUV8GI17UNkRMgZh8WAzqy+3pOYdHQCwk469L1Pt+wuCp1Eej3A4CzdM5C0TTNMXUiW+XWHf0vZkiqXaOXImFDvGX+MJBj5Zx9zSC3TsZyVQeML2tN0J+2ZTXYaOfRIezibHVMjYqNXAbFmISHBxCsPlHIJ+YeE9WidAw20BarC1Y3sI4tGknELzuWMca02sYqqkWyK5IS7vRBPYRDzcFo8b1KeaxQonCl7HE8RqZLtbkvv 0QJzcjxE HO6ZiwlytQ0zVUxjmH84Yq5rItjNm6sSYq/vjO6t4yATSqCgA2jGPqI1xauGPdc9TH59uRPZYCvOXj/lMJj4dDg6pew== 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 09:45:48AM +1100, NeilBrown wrote: > I have in mind a more explicit statement of how much waiting is > acceptable. > > GFP_NOFAIL - wait indefinitely > GFP_KILLABLE - wait indefinitely unless fatal signal is pending. > GFP_RETRY - may retry but deadlock, though unlikely, is possible. So > don't wait indefinitely. May abort more quickly if fatal > signal is pending. > GFP_NO_RETRY - only try things once. This may sleep, but will give up > fairly quickly. Either deadlock is a significant > possibility, or alternate strategy is fairly cheap. > GFP_ATOMIC - don't sleep - same as current. > > I don't see how "GFP_KERNEL" fits into that spectrum. The definition of > "this will try really hard, but might fail and we can't really tell you > what circumstances it might fail in" isn't fun to work with. Well, lots of things "aren't fun to work with", but error handling is just a part of life. Your "GFP_KILLABLE" has the exact same problem of "this thing will be rarely hit and difficult to test" - if anything moreso. We just need to make sure error paths are getting tested - we need more practical fault injection, that's all.