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 5BA18C433EF for ; Tue, 28 Dec 2021 20:04:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A9F126B0072; Tue, 28 Dec 2021 15:04:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A4F366B0073; Tue, 28 Dec 2021 15:04:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8EF926B0074; Tue, 28 Dec 2021 15:04:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0184.hostedemail.com [216.40.44.184]) by kanga.kvack.org (Postfix) with ESMTP id 811A26B0072 for ; Tue, 28 Dec 2021 15:04:21 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 39F4A89549 for ; Tue, 28 Dec 2021 20:04:21 +0000 (UTC) X-FDA: 78968279922.08.6C91690 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by imf06.hostedemail.com (Postfix) with ESMTP id 5DAE2180004 for ; Tue, 28 Dec 2021 20:04:19 +0000 (UTC) Received: by mail-wr1-f52.google.com with SMTP id s1so40284128wra.6 for ; Tue, 28 Dec 2021 12:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=colorfullife-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=goEETpOG9lfFevQHaur9PF5zaafWC9JdHro5XcDyM3s=; b=BZL8TKVxZBTtWhHhRnFHkYQw4mr94k7ePLKn6WIBSrOqTeipYFKW7BnRWSvQbvQYKc qanpY3Tu6TN6CaeWQ5rLt+SYXVKHpXjKHR1PAQgrSFA+FYgJiXFUyJ3WlHnd5L9/wNeE MURgsEKGnoZhMt6u9du4beR0EWgThKhNloCUzKlTT4tqdCX3msJumjBrmOXYm4kxcW9L U8I+zpsfS+Iap32r3gjcUkJXyZkKSJXeeVNMUsB/qusvwNZKWn+mDwjc+YKeUrtMLE9M LgIPTWJoBi7d8EiSh7dtZeu7sE3O7zv+WsVdCo1EKO23JJcg8ChK2ysPpFkthd3UKysK BkAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=goEETpOG9lfFevQHaur9PF5zaafWC9JdHro5XcDyM3s=; b=r/2Mtvyz5vepiuxyp9OVqXGQXSHj5O8tPwvdZrDU5GmaFzUQE+pvYuCuhvw/yE+iDn XPE2szDydJ5P5I1pAThl6r9gif/2CtP67UJLrEH/+igWA+XNoKuMGrqZjZAFTMxzsiAy cTuhq1CiUmxVhr6gFlT5sCwtHu4A2ozD8IppmHDvFmSYsM6RTqME6W41zWc8qVFAdZ5s FG/RSzw2B4BPjPgpRpaWEGSllgBgFutfi+QdN3g6oiKjPq9HzNRdBOw1ycKU1ca5tHp3 OeMy1f16+jwov2GfWsZbzmZoxif6Yqb3nb42f7kBszeBrRhKGURgKDedYp9aZY9RR/TV rULQ== X-Gm-Message-State: AOAM531etkmTcgaIiB9yO6Omfn1vGtxtQ1nsQcLmoxGaLfYs7DLX9An6 gY9sPMTQjF+Z1mRBcQZxHKBahg== X-Google-Smtp-Source: ABdhPJzENjmDSLB7a5xJOEU+owmw+05dK3GBXnyzbbvMdDMN+9jwRyPqZ3c1x7m35sU3sZGX/Ty7KQ== X-Received: by 2002:a5d:58c5:: with SMTP id o5mr17226605wrf.15.1640721859327; Tue, 28 Dec 2021 12:04:19 -0800 (PST) Received: from ?IPV6:2003:d9:970a:4f00:9d27:bf8:b765:305? (p200300d9970a4f009d270bf8b7650305.dip0.t-ipconnect.de. [2003:d9:970a:4f00:9d27:bf8:b765:305]) by smtp.googlemail.com with ESMTPSA id a198sm19125636wmd.42.2021.12.28.12.04.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Dec 2021 12:04:18 -0800 (PST) Message-ID: <18b6afe8-43b1-4159-0ddd-eca08f175f0a@colorfullife.com> Date: Tue, 28 Dec 2021 21:04:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH] mm/util.c: Make kvfree() safe for calling while holding spinlocks Content-Language: en-US To: Uladzislau Rezki Cc: 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 References: <20211222194828.15320-1-manfred@colorfullife.com> From: Manfred Spraul In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=colorfullife-com.20210112.gappssmtp.com header.s=20210112 header.b=BZL8TKVx; dmarc=none; spf=pass (imf06.hostedemail.com: domain of manfred@colorfullife.com designates 209.85.221.52 as permitted sender) smtp.mailfrom=manfred@colorfullife.com X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 5DAE2180004 X-Stat-Signature: ay6we4aecacq4rf9kbd9cah6349k4eyq X-HE-Tag: 1640721859-434285 Content-Transfer-Encoding: quoted-printable 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=20 solution suitable for stable. Fixes: fc37a3b8b438 ("[PATCH] ipc sem: use kvmalloc for sem_undo=20 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. Now you propose to redesign vfree(), so that vfree() is safe to be=20 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 lon= g start, unsigned long end) > return true; > } > =20 > -/* > - * Kick off a purge of the outstanding lazy areas. Don't bother if som= ebody > - * 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; > =20 > /* > * 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); > } > =20 > +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_ar= ea *va) > =20 > /* 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); > } > =20 > /* > I do now know the mm code well enough to understand the side effects of=20 the change. And doubt that it is suitable for stable, i.e. we need the=20 simple patch first. -- =C2=A0=C2=A0=C2=A0 Manfred