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 E9548C433EF for ; Tue, 28 Dec 2021 20:26:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 188806B0072; Tue, 28 Dec 2021 15:26:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 138136B0073; Tue, 28 Dec 2021 15:26:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 026F66B0074; Tue, 28 Dec 2021 15:26:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0160.hostedemail.com [216.40.44.160]) by kanga.kvack.org (Postfix) with ESMTP id E405E6B0072 for ; Tue, 28 Dec 2021 15:26:21 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 8D08E86E9F for ; Tue, 28 Dec 2021 20:26:21 +0000 (UTC) X-FDA: 78968335362.09.8D3D35F Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf02.hostedemail.com (Postfix) with ESMTP id 2C6EC80004 for ; Tue, 28 Dec 2021 20:26:16 +0000 (UTC) Received: by mail-lf1-f42.google.com with SMTP id x21so43621970lfa.5 for ; Tue, 28 Dec 2021 12:26:21 -0800 (PST) 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; bh=x9H1jwZuw47RIqVS8FsoYJoRzz2cUXj5zvjpJ6npwgc=; b=B+d9lyKIiZ7AIGDnhbu3YYirNZTBqKOuNocTRQpIRr9GQXgBEaCAqhYnrQQ9Nhfjhh FM4K0O+L5cYhUJxZEcjDAvJqqyhRbSUDKygvgdH3BTKNK0A7K1tABK5WNvDa85jjNNjo cDZupRlNJsQPBeQG37nmEQbyE3SdiMorm95gPenZIlmWNP4YM7HIzH35MpB4J5k+qZxT HmOD4XiCMPyKtJk5N9iu9tuIqomOldoaQYPfAjc1yK9YYtjfigvicozY7PonDhjk0lJL YJXtnR12Ok4xfwpaRxgtViHbuCy+9OUibj9vcTkZF32I9nZZHxAgRqquggLsQUd4mMb1 AFkw== 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; bh=x9H1jwZuw47RIqVS8FsoYJoRzz2cUXj5zvjpJ6npwgc=; b=Ywq7p6Xr6t5OKTHSKjMveHreVc5HpibJnq7TN526O0OaDRfRRN/GAFiMRN5ykKIcOV zYrZa6x5d3HUbW0DTkJAQZo4cPNzEa6e/JUmEjoPfAfkQ0es5Igxv1ZJwfely0VwVWH1 ZZS7eg/PypZ7ZGdOJ6yQckzf1qvWSYxw0LASyYycjfdoUO2L08KvHJlRfhvZDjbsSIqn l3ud0wwml49YcMmEdQXUfWukmxDoDYbEZNtfX9OWMl4QWDjFHaRYPQAQfva2rS5noARw KOq0/3QdGckjHwgWR1VtPcqsXY5BiHe3n27Yvc7Izq/yXaMQSPxJONAlP/FPaDyrp0g8 JKCg== X-Gm-Message-State: AOAM533c7k6YWkPEkQ5Wii66I1734kAu+c3WdXOpMfEIX3mWOW2307B7 2GHuXAIfHO7SMNlNH4tT7mc= X-Google-Smtp-Source: ABdhPJyo56MvrHZq/Ljfy8VHLlMtXo4FFR1WW8OtjsDsiosKJ4zawuypX3wIdN7EpaAZHFZ9F3tL3w== X-Received: by 2002:ac2:455c:: with SMTP id j28mr19927816lfm.667.1640723179633; Tue, 28 Dec 2021 12:26:19 -0800 (PST) Received: from pc638.lan (h5ef52e3d.seluork.dyn.perspektivbredband.net. [94.245.46.61]) by smtp.gmail.com with ESMTPSA id s21sm1788114ljg.131.2021.12.28.12.26.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Dec 2021 12:26:18 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 28 Dec 2021 21:26:16 +0100 To: Manfred Spraul Cc: Uladzislau Rezki , Matthew Wilcox , LKML , Andrew Morton , Vasily Averin , cgel.zte@gmail.com, shakeelb@google.com, rdunlap@infradead.org, dbueso@suse.de, unixbhaskar@gmail.com, chi.minghao@zte.com.cn, arnd@arndb.de, Zeal Robot , linux-mm@kvack.org, 1vier1@web.de, stable@vger.kernel.org Subject: Re: [PATCH] mm/util.c: Make kvfree() safe for calling while holding spinlocks Message-ID: References: <20211222194828.15320-1-manfred@colorfullife.com> <18b6afe8-43b1-4159-0ddd-eca08f175f0a@colorfullife.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18b6afe8-43b1-4159-0ddd-eca08f175f0a@colorfullife.com> X-Stat-Signature: 7ytb8ch9okrshbeqye94kgkm7fh3ubca X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 2C6EC80004 Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=B+d9lyKI; spf=pass (imf02.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1640723176-753157 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: > Hello Vlad, > > On 12/28/21 20:45, Uladzislau Rezki wrote: > > [...] > > Manfred, could you please have a look and if you have a time test it? > > I mean if it solves your issue. You can take over this patch and resend > > it, otherwise i can send it myself later if we all agree with it. > > I think we mix tasks: We have a bug in ipc/sem.c, thus we need a solution > suitable for stable. > > Fixes: fc37a3b8b438 ("[PATCH] ipc sem: use kvmalloc for sem_undo > allocation") > Cc: stable@vger.kernel.org > > I think for stable, there are only two options: > > - change ipc/sem.c, call kvfree() after dropping the spinlock > > - change kvfree() to use vfree_atomic(). > > From my point of view, both approaches are fine. > > I.e. I'm waiting for feedback from an mm maintainer. > > As soon as it is agreed, I will retest the chosen solution. > Here for me it anyway looks like a change and it is hard to judge if the second solution is stable or not, because it is a new change and the kvfree() interface is changed internally. > > Now you propose to redesign vfree(), so that vfree() is safe to be called > while holding spinlocks: > > > > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > > index d2a00ad4e1dd..b82db44fea60 100644 > > --- a/mm/vmalloc.c > > +++ b/mm/vmalloc.c > > @@ -1717,17 +1717,10 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) > > return true; > > } > > -/* > > - * Kick off a purge of the outstanding lazy areas. Don't bother if somebody > > - * is already purging. > > - */ > > -static void try_purge_vmap_area_lazy(void) > > -{ > > - if (mutex_trylock(&vmap_purge_lock)) { > > - __purge_vmap_area_lazy(ULONG_MAX, 0); > > - mutex_unlock(&vmap_purge_lock); > > - } > > -} > > +static void purge_vmap_area_lazy(void); > > +static void drain_vmap_area(struct work_struct *work); > > +static DECLARE_WORK(drain_vmap_area_work, drain_vmap_area); > > +static atomic_t drain_vmap_area_work_in_progress; > > /* > > * Kick off a purge of the outstanding lazy areas. > > @@ -1740,6 +1733,22 @@ static void purge_vmap_area_lazy(void) > > mutex_unlock(&vmap_purge_lock); > > } > > +static void drain_vmap_area(struct work_struct *work) > > +{ > > + mutex_lock(&vmap_purge_lock); > > + __purge_vmap_area_lazy(ULONG_MAX, 0); > > + mutex_unlock(&vmap_purge_lock); > > + > > + /* > > + * Check if rearming is still required. If not, we are > > + * done and can let a next caller to initiate a new drain. > > + */ > > + if (atomic_long_read(&vmap_lazy_nr) > lazy_max_pages()) > > + schedule_work(&drain_vmap_area_work); > > + else > > + atomic_set(&drain_vmap_area_work_in_progress, 0); > > +} > > + > > /* > > * Free a vmap area, caller ensuring that the area has been unmapped > > * and flush_cache_vunmap had been called for the correct range > > @@ -1766,7 +1775,8 @@ static void free_vmap_area_noflush(struct vmap_area *va) > > /* After this point, we may free va at any time */ > > if (unlikely(nr_lazy > lazy_max_pages())) > > - try_purge_vmap_area_lazy(); > > + if (!atomic_xchg(&drain_vmap_area_work_in_progress, 1)) > > + schedule_work(&drain_vmap_area_work); > > } > > /* > > > I do now know the mm code well enough to understand the side effects of the > change. And doubt that it is suitable for stable, i.e. we need the simple > patch first. > Well, it is as simple as it could be :) -- Vlad Rezki