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 A01CBC433EF for ; Tue, 28 Dec 2021 19:45:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B500C6B0072; Tue, 28 Dec 2021 14:45:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AFF6A6B0073; Tue, 28 Dec 2021 14:45:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 99FD26B0074; Tue, 28 Dec 2021 14:45:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0131.hostedemail.com [216.40.44.131]) by kanga.kvack.org (Postfix) with ESMTP id 891046B0072 for ; Tue, 28 Dec 2021 14:45:28 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 30C678907F for ; Tue, 28 Dec 2021 19:45:28 +0000 (UTC) X-FDA: 78968232336.26.2CE42A0 Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com [209.85.208.180]) by imf24.hostedemail.com (Postfix) with ESMTP id BDE91180002 for ; Tue, 28 Dec 2021 19:45:21 +0000 (UTC) Received: by mail-lj1-f180.google.com with SMTP id t14so3846956ljh.8 for ; Tue, 28 Dec 2021 11:45:27 -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=o9olEKFlA55ZJTj6pGz1teXDqC+Puxhe5pQT53/VCPs=; b=Kn/7lVydah5hdVCDnM9++24rhnnD/RpyVA5cDmQXgdbL5QYG/ZKA+uPseckR1p+ovP TyK6yc0YJ38MUDQfuC6s/uIwk9Kjv0sCWPVx1R22NQxxmoo027NoYH+ta8VTDldyNf7c AVdBlp4/GQZ0j81cWnq8Zxr/TuALjTjOAE8y8wQ+XCTpUks+9HWptE7H3K195MG+X9qk kk1Sj0J4XtxEpufFE8yzuZisPPITLGFMIrhwaRcI9dLXhSdG7b3RpH/HiU9ujZjMM3qB 73v2SygW+AcRbXUpin6rEtPHSS5AS4eEjpUwyYb0Jn70ztd6mntcbCjXXcIkhgpaDYyt 1zrg== 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=o9olEKFlA55ZJTj6pGz1teXDqC+Puxhe5pQT53/VCPs=; b=twZsU0MgnHRcDpiCFfyAGkzqdKx2I9Nn6xTFI7xXHGgx+SIwHTtNe9ii/sarW0mY+g dbRAw1qofWUB9JPdVtMuRNF7UEWN3y9qgVqIUos1fNhby0yD8XYWux6XMSdmItvbkY0w NeH2pCTFwGb4nVyR4Wh/wZlYmgz05v5jUyhgpRfGjs3cei0O3tn8jBPqHUEDW1jhQlPM ROsuxXejc1LAZa77aUqMYZoE8EHaVSMF4yxV61VuLAsXGbHiDy7mqJTkSDYbEqZ0jOiS 4sSxMbh7A/Ao1ajUa/6UUeH0XY5sEGoSo185g/yMIIOqwltGEdQ50oZJrez+JoA86Wvg hI/A== X-Gm-Message-State: AOAM531fCm8imH+gdsSJzR5kYyW2xl+dpMoB/Kqr1QAjaFS6OXSdwXwI dhR3eLUJPqkyOcfAlxZsSbM= X-Google-Smtp-Source: ABdhPJwU1p9x7xu7xLETwDkQJPqmjQWGEmx5dGeUsx32iiTom8PhIXwjFUHSt1qG6HBRxmBYFlUe0A== X-Received: by 2002:a05:651c:481:: with SMTP id s1mr3689346ljc.385.1640720726214; Tue, 28 Dec 2021 11:45:26 -0800 (PST) Received: from pc638.lan (h5ef52e3d.seluork.dyn.perspektivbredband.net. [94.245.46.61]) by smtp.gmail.com with ESMTPSA id s21sm1778797ljg.131.2021.12.28.11.45.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Dec 2021 11:45:25 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 28 Dec 2021 20:45:22 +0100 To: Manfred Spraul Cc: Matthew Wilcox , Manfred Spraul , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: BDE91180002 X-Stat-Signature: 5d5cuk1wunte9pcyzi8zsgyqmswswb4t Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="Kn/7lVyd"; spf=pass (imf24.hostedemail.com: domain of urezki@gmail.com designates 209.85.208.180 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1640720721-582851 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 Sun, Dec 26, 2021 at 06:57:16PM +0100, Uladzislau Rezki wrote: > On Sat, Dec 25, 2021 at 10:58:29PM +0000, Matthew Wilcox wrote: > > On Sat, Dec 25, 2021 at 07:54:12PM +0100, Uladzislau Rezki wrote: > > > +static void drain_vmap_area(struct work_struct *work) > > > +{ > > > + if (mutex_trylock(&vmap_purge_lock)) { > > > + __purge_vmap_area_lazy(ULONG_MAX, 0); > > > + mutex_unlock(&vmap_purge_lock); > > > + } > > > +} > > > + > > > +static DECLARE_WORK(drain_vmap_area_work, drain_vmap_area); > > > > Presuambly if the worker fails to get the mutex, it should reschedule > > itself? And should it even trylock or just always lock? > > > mutex_trylock() has no sense here. It should just always get the lock. > Otherwise we can miss the point to purge. Agree with your opinion. > Below the patch that address Matthew's points: 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); } /* 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. -- Vlad Rezki