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 488B1C531DF for ; Thu, 22 Aug 2024 07:47:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 670436B00DE; Thu, 22 Aug 2024 03:47:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 620496B00ED; Thu, 22 Aug 2024 03:47:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C0686B00EE; Thu, 22 Aug 2024 03:47:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2EDA06B00DE for ; Thu, 22 Aug 2024 03:47:42 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A9D5D1A13D5 for ; Thu, 22 Aug 2024 07:47:41 +0000 (UTC) X-FDA: 82479101922.16.A3736DA Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf18.hostedemail.com (Postfix) with ESMTP id 9DFEE1C0008 for ; Thu, 22 Aug 2024 07:47:39 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=RaHIr+gL; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.47 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=1724312778; 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=ZOUg6sAJPIKaVbX18cSw88ZQjYwiNscZCwt0YM3lYBw=; b=yCIkM58c2GE+zg1oLPoou4Ow6H9NpPnGKJDvyhAmCLoUA1w+Dv/eHcyagr3cuDP4K/j0fN a8ptyj1ZbwkGcHVobHN3ZMKeWnAI2qihXL1QESGwOWhbzREWZ63e61M0MuiwccbOdXcIwP ZUsqC2zi5ipjucB4qqRrhaw88ajwqao= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724312778; a=rsa-sha256; cv=none; b=oI818vRFnjWo75y/c7+bNAbeQVgNJlFwmPXL0CiZuvQ3VvcY2fnlya9iTnepL8/8inDjrc gDdEHMWk9hsKf3kcNPJN+P/YsrWV4b7v7hrk4PpaObrggIgkaIoT6KM9T74+7O7SbbqYhe Zn9Zx9ISeJ27GXMsjhczVEPbro2HAhc= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=RaHIr+gL; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-a7ac469e4c4so88218466b.0 for ; Thu, 22 Aug 2024 00:47:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1724312858; x=1724917658; 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=ZOUg6sAJPIKaVbX18cSw88ZQjYwiNscZCwt0YM3lYBw=; b=RaHIr+gLTXh6f1UyQ1BBya1dTFbwyWnnWXilvXcjII3WFszWIWMdRDN0h+s2JXVV/D IOj7XY/M2tQZ+9d/8G9Qqc2ibw1/2ARhQLIqQoR1JU3CzEgKnmhNum1RWC0V6VD0/Mpp 6ICQajNg7APInNk67hMc0xX1RV/WK8ztpRbgZm9wV8Ios0vYMTllemHROPgLzYbk7I1E 6qOyMFD7WEp4/u9YR68cuFYFeiUgXq7/zhq5a8Qs1BAOjhdsW8XGndgynRZcwhpMX4n1 ZPBtF5u9sgBQFYRQbUjZ0TGtmdNVdAWDogxnqETIEqsc3uRdTJZWJZrFvJAkcmIhWyHt VTxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724312858; x=1724917658; 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=ZOUg6sAJPIKaVbX18cSw88ZQjYwiNscZCwt0YM3lYBw=; b=LxdNRvfStJEm0q9n6S+Mz4tjE8G5Yyh2+4/l0l/pIQJwA1uNLmF63XTbj6KpeK5K+E WgVEGo11UV9ivrbKsNintW602qJJfdLbjhHU4n5oqT4YHD8cU87+2etXb2FGW6F1ub4k 0RRFcnLggBJo7XOqQF7rsHjuXzoCTuSolmZTL2flqQVyftFtJaT0pxt3Ln3zs8DG85kV ICJ2m+JkGineYgrMVIPZfC0vXA4i1IGDQV1PkNlPgXHD19H/TSEWL/Qhwrb6RbGzm6hH hEEYSGH0ILbn6WwXNQIuQ1FfAamrldZp7PH1hT4DletVzOlIpJseFvRF3WYZlaXHlOlk XzcQ== X-Forwarded-Encrypted: i=1; AJvYcCWUndz6rqeAKuvsVXGT/9/nkT/q0PDGPAS4a+myQdI3p8EX3w77qiifKi9qj55oo7nFi03fROR82g==@kvack.org X-Gm-Message-State: AOJu0YxyK9n3G0TTcoHhozqClyeF+M7/3KhTgN1IALjQ3SEdrY4Rl71f fJdyAqTms7yNXozpBmiL/RzyJ6It48i8z7WpbUz8FaJud04uBaFtq/ZeRv47nJQ= X-Google-Smtp-Source: AGHT+IFAKLPReEiPw9xv+p/rwUpV91S1DMn9/jtovjL8YV2jNNPlezFNNuxQKTXLxTAr1nuRuwrqPw== X-Received: by 2002:a17:906:c143:b0:a86:91a5:4d09 with SMTP id a640c23a62f3a-a8691a67c8fmr83329066b.26.1724312857735; Thu, 22 Aug 2024 00:47:37 -0700 (PDT) Received: from localhost (109-81-92-13.rct.o2.cz. [109.81.92.13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a868f4862b6sm78077966b.170.2024.08.22.00.47.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2024 00:47:37 -0700 (PDT) Date: Thu, 22 Aug 2024 09:47:36 +0200 From: Michal Hocko To: Linus Torvalds Cc: Yafang Shao , David Hildenbrand , Barry Song <21cnbao@gmail.com>, 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-Stat-Signature: ahqmzjq1r1mu56u9ks8ehdnryxf3q6q3 X-Rspamd-Queue-Id: 9DFEE1C0008 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1724312859-17702 X-HE-Meta: U2FsdGVkX18q8wSZDlddjuSK94Y2ju8bM7IbHVPYehaPgc12Nztz+r17Hq0EsSBmAoBi5wpWRAMSaX8mBnlnM0A9IlZCHFgcA2NSfiu6pLg0m8ANuSQYO80IIHR5mukxhdWe/djGY7xmNFLHYMgudliV9SdysI5+BUB1JvsG8GVsQY00x7IwBwWvaQMJZzoCQqmwhR3mQwn6bzP3ibKj5zEHRelm/M2/V+96mSf2BhsRn80jqxsUKSC3A2hkwsq01qAAfkbUi0Ousk/ALs0SFNS/6KoqfMCpAMGBXr5tsgRWGhngY8vgAdy7C4n8ARMRbTqyN395dv4uRkYu7dyXG+ywl2mm95+oLFGAPNBM5Cswsg4oYOyB+Vo/QY8nIiIE45LHE38sNk99OYtvy+2Hci643N5z8rNkWT5/0rVJanJ2T/W1McM4Fotty+dpYHSXv4Kk0t2MwlkOeqn14kJ66BiBuO1yI+lBk2H8W36/zYJOmAQD6x8ETa4AJBVv2iEIxTnhsXts7GEoOh5L/xy0OaX3kMMXpSJC+y0fuZjmACHch9A/uGAoDxd6TedyC2dkjJs+QG2JL2Ho8T+EgVSAZbBitfYnZopcd1RYTxW6Lyf/KX4DPRy5nCL1A/FFUZOxfP3gsBYHtCCnIVGkJPxr4Xyk8ut5T4j09eMj/ntR7JrhccPlhCWdL7ebnKLZfFk8didW8nwp8+ZlCX86k8QLk4AiJb4ylVKaNNuWb7WwYL6Znn7aiX860GpEkm+Y5w9BcuVmUym2BQBaj18SRFWKmO/gd/fP+XOe0yXoNZf3TH1uDP6BvJU6XxZu8rOoMyLs7n+11Bz08FegYup5SdJwZpcesQVPjlpg/JpcIK4FIKmkisJs0wJJRF/HPdQWqtvxeq+uVC0wwwfLX6rycSQshk7Qm0v/CuqFIPvAmFaDg+jl9VqX6EllRzaYRcz9U9NxAgd+zxSDlEPMvcvOH9U Hyktk42P ZZKjx6AO3JrI1TJ7DjkwvyT8yAqJFSoOMgKHIRep4TrtG7gerlRnMBieZ2YA1ChrbTyIcYDIr0J8Ou4j8rAsYfUweQtlF0+oEQSp28mg9UUG/IDsIqUunX1MSOx6gwcf1PQQ+MIDBgQOJVdd9W921XlpQZjRhLX9y6Zz3MXjmblj8ZWIdjEmentkDIVT+SaSUkyY8hnS0FukZLwSXf/VyqFOf1AvEcJN2LISdpah4b49WUlpVOnqROZKSEXJCoinhESD0ReE79p+D6Pl+jwkD/bXm/Yj6E0G5BQMaKF0g/u1DDbj97jt/7V7xLWbqhvdlHLgTAw14XY8AH9DrBbOc6a1FobQ7+uk+cTqGUG4hLWL6Sr8cti3hDoEVpv1blDSWSYw5ofRE0nbgLc8CVXvKgAYdfJGHryEdGO57 X-Bogosity: Ham, tests=bogofilter, spamicity=0.008328, 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 14:56:08, Linus Torvalds wrote: > On Thu, 22 Aug 2024 at 14:40, Linus Torvalds > wrote: > > > > I did find three cases of kvcalloc(NOFAIL) in the nouveau driver and > > one in erofs. It's not clear that any of them make much sense (or that > > the erofs one is actually a large allocation). > > Oh, and I missed one in btrfs because it needed five lines of context > due to being the allocation from hell. > > That said, yes, the vmalloc case at least has no fragmentation issues, > but I do think even that needs to be size limited for sanity. > > The size limit might be larger than a couple of pages, but not > _hugely_ larger. You can't just say "I want a megabyte, and you can't > fail me". That kind of code is garbage, and needs to be called out for > being garbage. yes, no objection here. Our current limits are too large for any practical purpose. We still need a strategy how to communicate that the size is not supported though. Just returning NULL is IMHO bad thing because it adds potentially silent failure. In other subthread I was contemplating about OOPS_ON which would simply terminate the user context and kill it right away. What do you think about something like that? -- Michal Hocko SUSE Labs