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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0A35C433F5 for ; Tue, 19 Oct 2021 19:47:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3AB5360296 for ; Tue, 19 Oct 2021 19:47:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3AB5360296 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id B99A16B0071; Tue, 19 Oct 2021 15:47:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B48EC6B007B; Tue, 19 Oct 2021 15:47:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A383E6B007D; Tue, 19 Oct 2021 15:47:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0135.hostedemail.com [216.40.44.135]) by kanga.kvack.org (Postfix) with ESMTP id 9110F6B0071 for ; Tue, 19 Oct 2021 15:47:03 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 4200F8249980 for ; Tue, 19 Oct 2021 19:47:03 +0000 (UTC) X-FDA: 78714220326.07.E4BF308 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf06.hostedemail.com (Postfix) with ESMTP id 21853801A8AE for ; Tue, 19 Oct 2021 19:47:02 +0000 (UTC) Received: by mail-lj1-f176.google.com with SMTP id r6so8212316ljg.6 for ; Tue, 19 Oct 2021 12:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=dU9JPjCF/QTHYanK0ubxc1uDAVdt4MQo9gsrLFf8T0o=; b=CEnquVm6zuPjD6ToNyyTaUnJlEN5UdVTyHGgrKm9v3Ktx9ySAbGgNfBCkdj4kczwgU LQNfKvxWvfy2E7wchjG4g7r7gIwhyf2JzesOB44LHHFt3+1JiaC/CyNo69M4tjZ+Sf8Q UnoZsHYnCkHbe8CvEJwJR+pVwDG5iBcz/kvQzo/MI87j7tujktg+6qMK1cISrE+hXpeP q9MTPImuSAoK7OVSZa4g8Ao33xzUVQfnbmrwub2SHMkZH0h0Gw/CZjoDG+RL/KxUWjMN omKxddKgnIuHoAMBzQTpSI1usJd2ccvqcciMTcM+saI0ctVoJ0GUcI6gM+3H+gcUc2Ra fjwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=dU9JPjCF/QTHYanK0ubxc1uDAVdt4MQo9gsrLFf8T0o=; b=H5mGGKsFASJZg9T2xrmS3OtqPHt4sauMAdCQQ8zWa7rTUp2lMqQ/s0yqI50KikWqRS hCzZitlLFrGV3Q8qS3t3JhgdKvxj0ptFQbpvF4nEmZwjgWeNHvmjvz+E/msvRYcXNM0d qUrJLeG011rQ+C/qMjKXEP0NGvpOUVLdMzCSPB+g6N7Fgv6P22isTz7GUZG0UpLApzr1 RCN60K55Y1UrNuMMPB6p/AyRufYN7RJfDwunqKGIk4B/3+maogcZC6ifiUnyQaUBHvCB sD/vDs82Qe1Kx6RAE4geZN77FDehFpVm/zl4EuJnSgwcEZa3BU1iRmwXnOxRaWbIwsQ/ Qv4g== X-Gm-Message-State: AOAM532BuudXLP03da0kJqRxSM7qwM9gqjEJcetq8nfiTQftBvNpMAf8 UspL48aoJK/JmM5DZyymDu0= X-Google-Smtp-Source: ABdhPJzveWHVkx2ylYoebfuMsa1JZePdpzsdY9LAzL7gLa4QSNKCJ1lYZ0HzeN378yYNoKs3GIgtrg== X-Received: by 2002:a2e:2d12:: with SMTP id t18mr8541409ljt.254.1634672821174; Tue, 19 Oct 2021 12:47:01 -0700 (PDT) Received: from pc638.lan (h5ef52e3d.seluork.dyn.perspektivbredband.net. [94.245.46.61]) by smtp.gmail.com with ESMTPSA id x34sm6454lfa.170.2021.10.19.12.47.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Oct 2021 12:47:00 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 19 Oct 2021 21:46:58 +0200 To: Michal Hocko Cc: Uladzislau Rezki , linux-mm@kvack.org, Dave Chinner , Neil Brown , Andrew Morton , Christoph Hellwig , linux-fsdevel@vger.kernel.org, LKML , Ilya Dryomov , Jeff Layton Subject: Re: [RFC 2/3] mm/vmalloc: add support for __GFP_NOFAIL Message-ID: <20211019194658.GA1787@pc638.lan> References: <20211018114712.9802-1-mhocko@kernel.org> <20211018114712.9802-3-mhocko@kernel.org> <20211019110649.GA1933@pc638.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Stat-Signature: e3rzgj6z151mzk15tqp7s874zuiapnyy Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=CEnquVm6; spf=pass (imf06.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 21853801A8AE X-HE-Tag: 1634672821-453923 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: On Tue, Oct 19, 2021 at 01:52:07PM +0200, Michal Hocko wrote: > On Tue 19-10-21 13:06:49, Uladzislau Rezki wrote: > > > From: Michal Hocko > > > > > > Dave Chinner has mentioned that some of the xfs code would benefit from > > > kvmalloc support for __GFP_NOFAIL because they have allocations that > > > cannot fail and they do not fit into a single page. > > > > > > The larg part of the vmalloc implementation already complies with the > > > given gfp flags so there is no work for those to be done. The area > > > and page table allocations are an exception to that. Implement a retry > > > loop for those. > > > > > > Signed-off-by: Michal Hocko > > > --- > > > mm/vmalloc.c | 6 +++++- > > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > > index 7455c89598d3..3a5a178295d1 100644 > > > --- a/mm/vmalloc.c > > > +++ b/mm/vmalloc.c > > > @@ -2941,8 +2941,10 @@ static void *__vmalloc_area_node(struct vm_struct *area, gfp_t gfp_mask, > > > else if (!(gfp_mask & (__GFP_FS | __GFP_IO))) > > > flags = memalloc_noio_save(); > > > > > > - ret = vmap_pages_range(addr, addr + size, prot, area->pages, > > > + do { > > > + ret = vmap_pages_range(addr, addr + size, prot, area->pages, > > > page_shift); > > > + } while ((gfp_mask & __GFP_NOFAIL) && (ret < 0)); > > > > > > if ((gfp_mask & (__GFP_FS | __GFP_IO)) == __GFP_IO) > > > memalloc_nofs_restore(flags); > > > @@ -3032,6 +3034,8 @@ void *__vmalloc_node_range(unsigned long size, unsigned long align, > > > warn_alloc(gfp_mask, NULL, > > > "vmalloc error: size %lu, vm_struct allocation failed", > > > real_size); > > > + if (gfp_mask && __GFP_NOFAIL) > > > + goto again; > > > goto fail; > > > } > > > > > > -- > > > 2.30.2 > > > > > I have checked the vmap code how it aligns with the __GFP_NOFAIL flag. > > To me it looks correct from functional point of view. > > > > There is one place though it is kasan_populate_vmalloc_pte(). It does > > not use gfp_mask, instead it directly deals with GFP_KERNEL for its > > internal purpose. If it fails the code will end up in loping in the > > __vmalloc_node_range(). > > > > I am not sure how it is important to pass __GFP_NOFAIL into KASAN code. > > > > Any thoughts about it? > > The flag itself is not really necessary down there as long as we > guarantee that the high level logic doesn't fail. In this case we keep > retrying at __vmalloc_node_range level which should be possible to cover > all callers that can control gfp mask. I was thinking to put it into > __get_vm_area_node but that was slightly more hairy and we would be > losing the warning which might turn out being helpful in cases where the > failure is due to lack of vmalloc space or similar constrain. Btw. do we > want some throttling on a retry? > I think adding kind of schedule() will not make things worse and in corner cases could prevent a power drain by CPU. It is important for mobile devices. As for vmap space, it can be that a user specifies a short range that does not contain any free area. In that case we might never return back to a caller. Maybe add a good comment something like: think what you do when deal with the __vmalloc_node_range() and __GFP_NOFAIL? -- Vlad Rezki