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 ED824C3DA4A for ; Thu, 22 Aug 2024 08:24:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 831BA6B02D2; Thu, 22 Aug 2024 04:24:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E2336B02D5; Thu, 22 Aug 2024 04:24:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 633C16B02D3; Thu, 22 Aug 2024 04:24:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4119C6B02CF for ; Thu, 22 Aug 2024 04:24:18 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0465FA13E1 for ; Thu, 22 Aug 2024 08:24:17 +0000 (UTC) X-FDA: 82479194196.19.CF1AF8E Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) by imf09.hostedemail.com (Postfix) with ESMTP id 02E6114002B for ; Thu, 22 Aug 2024 08:24:15 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=I2Fuc95M; spf=pass (imf09.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724314976; 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=nXgj37TMx8aL1rRaQNhJVUmv3g5neGPq4DUZTSDo83g=; b=0z71m3TBR2F0kYFxtkBOQ796LqUN1yW2+/Pl0JXCPRf6AzDNUjaNBoAEAll/KLJw15/t26 34O3CRmrMtp7cHZwl7bedDy57C1Gj/q8dLHw56yymGCH5hc1Vcin85Cef0Yafgk1WijqxM ivehKeFTlDs3uh4SHzLbEgmae+eoXkA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724314976; a=rsa-sha256; cv=none; b=mhAchdZj5xUdt0E7oxCx9099UlA75qUVJr/Vjw8DTByy7KukS6kfoTqZDWlaIo9hd4Lbg9 mvtKImwOOilHsBYb136FkpgwPjMFat4d7CEc1Fco793XxrTFJOdAuY6OCEUWotPrhLPl2o 43p6LuonWeX8Vo1Bx5A79exiPusKQz8= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=I2Fuc95M; spf=pass (imf09.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.172 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-lj1-f172.google.com with SMTP id 38308e7fff4ca-2f3edb2d908so5087921fa.2 for ; Thu, 22 Aug 2024 01:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724315054; x=1724919854; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=nXgj37TMx8aL1rRaQNhJVUmv3g5neGPq4DUZTSDo83g=; b=I2Fuc95MppZ5U+OLxfaka5VY9Mh2mqxA/zEXcxT/47ig3xCzCqDfRsm9VUuZuPdyRS YkKnBd6YRn+haJLed0Z9HR8sM9/DddMDrPaDrcomWfY0Grng6VMouLWPqJOmRXNiWkmG cL2D/+1n//JJpzAG62H0/vYOipwNKzI21UjqTRXh05QOZOWkA8WjM2DzK3emg3rHQmxg NuPel1EEnwKWZSs4ZDVE/rEfDxan+k5YXf2MR1XOVziL202m9SlIiHKpy0yBSoNeIPh6 riYhNmHOiIfxwMM93gCZuypFffJT4jaQ+ukx3khH/ErC4E00Mlq1bGuhUB3ONiB96nUD OLhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724315054; x=1724919854; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nXgj37TMx8aL1rRaQNhJVUmv3g5neGPq4DUZTSDo83g=; b=aeV8nL+tltp1MpaoEC9wcs9Zh+eYSJ+2tZQgHZxXoUtOydoyIIYGP6ck/i9gWjSkwo zl+mmak8RaXRqbw8iuC2YuhVgdHD68BnbNpWsZsPl9ezW6rpv8ulzN27N1IaMutMCx9D 5Jow5qI/uyqR2lvG+N1z5LqRIPqD5WeXKQXfGutzfA9V/UO/kr7sJMf6YX7jej8Zz+bW 3BiiK6USjWJy4lA90F7PouAeDQx+DI81LI0L7GdgOKorrXUmKKgtCwFSN7qydBasbuem jMaEf+OLHEgYGLLoVnUuOJtB9IEZ4iKxzjRFWxJsw3+6Fzu4xYzkXGLogVbA2fh0zgj+ 2NVw== X-Forwarded-Encrypted: i=1; AJvYcCWnOeHsUnySQny7daXsUeYLM5GV9Q+Wc+S/cX6PFIViGYkM4erSWKhwPFbg3itMSLSIXxh9uNszsg==@kvack.org X-Gm-Message-State: AOJu0Yzbv/g8FSHqXK642XRt5BVq7J49/IokIzfvQaMMMoK5DzErWE6o yv1qX7d0PfA9F7QwG2FXztIF5sjzopQTTKxwyq7ukD/p4ipN/74EL8GlpZxLbwA= X-Google-Smtp-Source: AGHT+IFB2eEPLaBDM1KUM6aZQy1e8xYD9Bh6pKUfYpZ84sAeHB8dPoSo2HIQ0e9MSM6g1QoeRd5Tpw== X-Received: by 2002:a2e:bc13:0:b0:2f3:c029:d7e with SMTP id 38308e7fff4ca-2f3f88b843cmr36602701fa.18.1724315053944; Thu, 22 Aug 2024 01:24:13 -0700 (PDT) Received: from localhost (109-81-92-13.rct.o2.cz. [109.81.92.13]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5c04a3ead28sm608629a12.56.2024.08.22.01.24.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2024 01:24:13 -0700 (PDT) Date: Thu, 22 Aug 2024 10:24:12 +0200 From: Michal Hocko To: Barry Song <21cnbao@gmail.com> Cc: Linus Torvalds , Yafang Shao , David Hildenbrand , akpm@linux-foundation.org, linux-mm@kvack.org, 42.hyeyoo@gmail.com, cl@linux.com, hailong.liu@oppo.com, hch@infradead.org, iamjoonsoo.kim@lge.com, penberg@kernel.org, rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com, v-songbaohua@oppo.com, vbabka@suse.cz, virtualization@lists.linux.dev Subject: Re: [PATCH v3 0/4] mm: clarify nofail memory allocation Message-ID: References: <20240817062449.21164-1-21cnbao@gmail.com> <7050deab-e99c-4c83-b7b9-b5dad42f4e95@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 02E6114002B X-Stat-Signature: ewjam6877iwkbsgxo6rf4zyp8kbiwyaj X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1724315055-629221 X-HE-Meta: U2FsdGVkX19a7/mUkBp+5KvsMLplOuXdLoDgo6WmClm8d21I6aKauakVmtcgUq9lk7OUTMaVxQtLhDRFVfWorpuA4Zw+u2obSvDIa0cnv58F3CjRgMelTFV/uc4OYgztk+TzWTi+LohuMfLZuSlEK5vX1Qc8i07Q3aivyZIAEdVJw60zm5fQtTXfIQN7kKYl/UGiQAQSdnA7DEGAr4TD8IVEnGwrciA4WIWj8yS7lp8wMwuiT3uUCAHwL7JFJw0fJOOjJVF39vwBr7mwscCw0imswntsGs+HrOZ/gmeAjP5CzL40Ib6UqedDiMDfwLm+le+2x90NDHWZDMZewr02gJIvkTfgO2fexU9gxTOfqTPG2OjmHi43yIP15+oS/r4A7E6u4s5J9BDiYEapIpPPQZdRfaCMsg+d2bVBNogHfK14rqkDnmTxFRvJiiO4mYy3hgdVKxoLDFdSEtWWqKYCum/XPwnebi8QhSV+FBDY4WlB0aYwv63N75StRr/BfVcBw3Vj5DtBgTaj5CeyPtfnA3dv3D/UJld5Wrgth6h+gyHA2ib4vpBadISGNnpSCZ6yB0wHjP2VIU5aJndiXxaeOWxZNZRsD5I/IuoZeYDwZfMBM0B6YfJ6uf2rsKFGW7f+11OGi/813vPsqPIimGqpuQrIaiiSmG6FprqIed7urDFyB1OPWlZQTXhm4U1CpzTtmO+JbTSe8Uhfp5YWRJnsXDxrC82o9c1SQps7NlOmoMGxqrI0yMjgyNuAJMsXw0iPRaVm1PGteFNjfQcursx2i9WmFOA4g0U+Acg6cNO+xchHqg8GtY9iGmwy9AFrTXMc0MK+UNNGoY96IJzOabAwL6i6pj69DN9vz5+V8u/jxuyynY6xLAU0iqJONXEvFfhPgD8F3mgX3Yid59Or0+7VMHPx880A/WbBfPztbxhl0bX1qzysN4cxmpgFKpyjgWLVpThRjsy2ppYMvDa8nx8 s5hQ3+5o IvkuI0D6WYg3YwPOnNa0SJ1ppHLvKTodEM8g9i+NMrzVjJE+ehB4mTzWJH0Zp5ha8JfH3LvSdxXmtX2osaqtzxre91G1rf6Jtt7g5rwqSVPpCndAaP5R7D08Jhr7EvkeKroT0QSRWDRPWfrNlsF/FMRyvbGass5t2fLfExlOI4aaGFZndwFQk/qLr2ZZPNcZH7ggfDMnax0XIT7YE4H672ROXbarzmCUGP/owlMwG6r1/p8omxoaFEHDygM9aokFtUUkTQH4s6G49suZrutAb2+XhqiVS288ySmhw43qr548PWkBTAyJtZb1FaWbwkdWKgA6r9Rbh4/gceH6wgF7bdSNvLB7m03G7PtBDqLX7JLM6jnk= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, 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 22-08-24 19:57:41, Barry Song wrote: > Regarding the concern about 'leaving locks > behind' you have in that subthread, I believe there's no difference > when returning NULL, as it could still leave locks behind but offers > a chance for the calling process to avoid an immediate crash. Yes, I have mentioned this risk just for completeness. Without having some sort of unwinding mechanism we are doomed to not be able to handle this. The sole difference between just returning NULL and OOPsing rigth away is that the former is not guaranteed to happen and the caller can cause an actual harm by derefering non-oopsing addressed close to 0 which would be a) much harder to find out b) could cause much more damage than killing the context right away. Besides that I believe we have many BUG_ON users which would really prefer to just call the current context instead, they just do not have means to do that so OOPS_ON could be a safer way to stop bad users and reduce the number of BUG_ONs as well. I am just not really sure how to implement that. A stupid and an obvious way would be to have a dereference from a known (pre-defined) unmapped area. But this smells like something that should be achievable in a better way. -- Michal Hocko SUSE Labs