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 C26CEC433EF for ; Mon, 7 Feb 2022 19:31:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 53E2D6B0074; Mon, 7 Feb 2022 14:31:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4EE0D6B0075; Mon, 7 Feb 2022 14:31:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38EBA6B0078; Mon, 7 Feb 2022 14:31:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0069.hostedemail.com [216.40.44.69]) by kanga.kvack.org (Postfix) with ESMTP id 2602C6B0074 for ; Mon, 7 Feb 2022 14:31:51 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D907A9367E for ; Mon, 7 Feb 2022 19:31:50 +0000 (UTC) X-FDA: 79116978780.27.EF07B3B Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf01.hostedemail.com (Postfix) with ESMTP id 85B184000C for ; Mon, 7 Feb 2022 19:31:50 +0000 (UTC) Received: by mail-yb1-f181.google.com with SMTP id v186so43312391ybg.1 for ; Mon, 07 Feb 2022 11:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MK2v0Nt4cCV21YTIg8dlF+1LBbs9TTGPuFsltjIOmZY=; b=rMiweCVJx+urv7AcwZojioWaGyvA45MimmXZ4nW0za2fZ/cduytjm2OQZyHtYp+tPx 1HrHmPCebzKnd6tfbU9efn7x6cPgg2Ts12sYH1bDkvdoffD8pp5XtzMRdtBkI3j8bFgF YF8jFpySNTXhHpbW0iLLaZ4Xdtr7HVgrurfwh05TUxgliW41tE3zDiMNBC92jvKeZe2h BS7mTS5MFOFRAbgaP/GIIe5MrNQy5/9MDgN3RIjeirtsr0eY6VsPOsClYYcVlnZCqq2l 1iBhLbmjaF6IPhNqDof1RAmK2+93XkctSjr/Btdd8oUPy7U+M6KqcYX7XZFxPvWMb/zn ooHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MK2v0Nt4cCV21YTIg8dlF+1LBbs9TTGPuFsltjIOmZY=; b=NUwyd1K7E0c7ut/qQilB4nnVQte+ZDAGC6XWdI+qcMkZNVIonWRgmGl4Wps4liMFwz M/8u+WyWto4gaoe8T2/heWGUz1bm4ICYR1qODjlEJvKd22gKg7A+KCGD59YV2pI1neTm Rn1CgRfjBN9HFszl8FR/ZjCpyE4GPUAi7Eh0KwDznKRKeWJa+jlVHTASNmTynY1GTyd+ hYlcwCYo4tg+iIxjtJR+meLct1qvYPTTtFuSFobMIcLZxACk3Q2ZaxJocoACVS8vWSh6 hbaHdsrLZGkam97MlB0KA8cTTDqmSCY0L0lJfmclzeR6JH/BIhX1h4Z8QrK+PU2p1MBd 0RCw== X-Gm-Message-State: AOAM532kgappNpw6n8o+lUEjBMt5uECIndj1YZLVtEPM2uGRzgtccfQk lMpjMwsRO6SZRprFRPdajoS5JiNZMdTcDM4BpD0XzQ== X-Google-Smtp-Source: ABdhPJx6cAOVkZDsEsjED0wt0V+zqCARCd6Uf0sXMZfve4eA84dGGFKqAgMYW0gF9smp23F+c8iYQKEpGwRFHz8d2dg= X-Received: by 2002:a25:d7d0:: with SMTP id o199mr1316951ybg.34.1644262309574; Mon, 07 Feb 2022 11:31:49 -0800 (PST) MIME-Version: 1.0 References: <20220128131006.67712-1-michel@lespinasse.org> <20220128131006.67712-23-michel@lespinasse.org> <20220129121319.3593-1-hdanton@sina.com> <20220201020958.3720-1-hdanton@sina.com> In-Reply-To: <20220201020958.3720-1-hdanton@sina.com> From: Suren Baghdasaryan Date: Mon, 7 Feb 2022 11:31:38 -0800 Message-ID: Subject: Re: [PATCH v2 22/35] percpu-rwsem: enable percpu_sem destruction in atomic context To: Hillf Danton Cc: Michel Lespinasse , Linux-MM , LKML Content-Type: text/plain; charset="UTF-8" X-Rspam-User: nil X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 85B184000C X-Stat-Signature: dob8nawba6mo5w3k7gkdsgnkxpsfcxs6 Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=rMiweCVJ; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1644262310-557317 X-Bogosity: Ham, tests=bogofilter, spamicity=0.023915, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jan 31, 2022 at 6:10 PM Hillf Danton wrote: > > On Mon, 31 Jan 2022 10:04:16 -0800 Suren Baghdasaryan wrote: > > On Sat, Jan 29, 2022 at 4:13 AM Hillf Danton wrote: > > > > > > On Fri, 28 Jan 2022 05:09:53 -0800 Michel Lespinasse wrote: > > > > + > > > > +static LIST_HEAD(destroy_list); > > > > +static DEFINE_SPINLOCK(destroy_list_lock); > > > > > > static bool destroyer_running; > > > > > > > + > > > > +static void destroy_list_workfn(struct work_struct *work) > > > > +{ > > > > + struct percpu_rw_semaphore *sem, *sem2; > > > > + LIST_HEAD(to_destroy); > > > > + > > > > > > again: > > > > > > > + spin_lock(&destroy_list_lock); > > > > > > if (list_empty(&destroy_list)) { > > > destroyer_running = false; > > > spin_unlock(&destroy_list_lock); > > > return; > > > } > > > destroyer_running = true; > > > > > > > + list_splice_init(&destroy_list, &to_destroy); > > > > + spin_unlock(&destroy_list_lock); > > > > + > > > > + if (list_empty(&to_destroy)) > > > > + return; > > > > + > > > > + list_for_each_entry_safe(sem, sem2, &to_destroy, destroy_list_entry) { > > > > > > list_del(&sem->destroy_list_entry); > > > > > > > + percpu_free_rwsem(sem); > > > > + kfree(sem); > > > > + } > > > > > > goto again; > > > > +} > > > > + > > > > +static DECLARE_WORK(destroy_list_work, destroy_list_workfn); > > > > + > > > > +void percpu_rwsem_async_destroy(struct percpu_rw_semaphore *sem) > > > > +{ > > > > + spin_lock(&destroy_list_lock); > > > > + list_add_tail(&sem->destroy_list_entry, &destroy_list); > > > > + spin_unlock(&destroy_list_lock); > > > > + schedule_work(&destroy_list_work); > > > > > > Nits > > > spin_lock(&destroy_list_lock); > > > 1/ /* LIFO */ > > > list_add(&sem->destroy_list_entry, &destroy_list); > > > 2/ /* spawn worker if it is idle */ > > > if (!destroyer_running) > > > 3/ /* this is not critical work */ > > > queue_work(system_unbound_wq, &destroy_list_work); > > > spin_unlock(&destroy_list_lock); > > > > Thanks for the review! Just to clarify, are you suggesting > > simplifications to the current patch or do you see a function issue? > > Apart from the nits that can be safely ignored in usual spins, I wonder if > the async destroy can be used in the contexts wrt raw_spin_lock. > > Hillf > > raw_spin_lock_irq(&foo->lock); > ... > percpu_rwsem_async_destroy(*sem); > ... > raw_spin_unlock_irq(&foo->lock); Sorry for the delay. Are you concerned about the use of spin_lock() inside percpu_rwsem_async_destroy() which would become a sleeping lock in case of PREEMPT_RT? If so, we can use raw_spin_lock() when locking destroy_list_lock. Please confirm. Thanks! >