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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A3595C27C4F for ; Fri, 21 Jun 2024 09:33:01 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=M6nMDIcY; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4W5Bwq26B1z3cSd for ; Fri, 21 Jun 2024 19:32:59 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=M6nMDIcY; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2a00:1450:4864:20::62c; helo=mail-ej1-x62c.google.com; envelope-from=urezki@gmail.com; receiver=lists.ozlabs.org) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4W5Bw16CTyz3bhD for ; Fri, 21 Jun 2024 19:32:17 +1000 (AEST) Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-a6efacd25ecso97605066b.1 for ; Fri, 21 Jun 2024 02:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718962335; x=1719567135; darn=lists.ozlabs.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=LXjbiUeKX1jEQnL+FwWLcen6cX7ksdYWye9qn3fwv6g=; b=M6nMDIcYKWsbLwrnxf9eE7ep71qx4CQ0HTeAfvowxlLVMhoCBb6UapSmTF23v9jAQ3 GPdmR5m1/idEFzFkSX1n2yQdEifnz42I1khuE9rbZFltIZ+HB93pR6eDGUsXv7ncjgk3 LIPIxII9ZEf0q1A8UnduBWSrrHbKK0B4V94h/Qe3ecw5hBCn/B5vKsUI/TRA8LZp5ZRV v+P6PtIsO3/JCCuT/FABdx76bjzjgS2Wzzyiog/YZDQsCdrDTyYHQqlIPB+W3IQghHTg VULKfHWypuWj8k3Qlt5Ye7niQRAVNqhMy3n3AxD3U7p2bdOGYeky8LZlRAzFvM5CzRsx e89w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718962335; x=1719567135; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=LXjbiUeKX1jEQnL+FwWLcen6cX7ksdYWye9qn3fwv6g=; b=gozZRkTeQQgxDFGa6arunLC8ufu0Rr6+t8vxGxYBDH1aedpvYT20ZFbvlI/He+thae nO2kNRqhsZZvnBL8xnhPjj5SiRVdfm+oYwf4Q9folZ2B6KuWI0M4J/CDs5aTAk1PgNSG WAYmARb9kpwBa8Es50pLPeW3uJx8TmwJYttVZ+7TgcHQdcF7MjDhSBnjf9wuz4raKWH4 9Nj4CFrYnNklv/+9jX6Z7MWwGle4ogWzLnGmGeB69hujW7O9iXy0IFZ15/XqZvHBNgLd RvvBPH7LSn85AcQDVZJBsc8LlkcQMxglKPtNu7wyS6kDxnXgJGOVHa78Slp1WGdsNkcs eK4A== X-Forwarded-Encrypted: i=1; AJvYcCVPAY7xHUInsdnAysqVFM3ybByglDpLUH64uP+heregBXSYhkeKezkT0J3JrXToI4ulYtUnNJNtQLrrGTnspUeBHgJnt7387XPGdyjP3g== X-Gm-Message-State: AOJu0Yzx4lv3nebUyKXot0tfgSE1aTtrof9CxgVPUpzWr3WJOFlqyXF0 3hirgzjN9b2fDX/5BFKXefMmUOkmg6eP+8hl2jJauv8RybsYJgJh X-Google-Smtp-Source: AGHT+IEG3QIZH1aO0GWd9T0Xk/3yUg93srj60sGG+BwmRF3tpMGbSRtFwCmQB/INPoCeCqb37IZhUg== X-Received: by 2002:a50:d60b:0:b0:57a:79c2:e9d6 with SMTP id 4fb4d7f45d1cf-57d07ea9ccbmr5867695a12.33.1718962334727; Fri, 21 Jun 2024 02:32:14 -0700 (PDT) Received: from pc636 (176-227-201-31.ftth.glasoperator.nl. [31.201.227.176]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6fcf56e9f3sm62345066b.215.2024.06.21.02.32.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Jun 2024 02:32:14 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Fri, 21 Jun 2024 11:32:12 +0200 To: Vlastimil Babka Subject: Re: [PATCH 00/14] replace call_rcu by kfree_rcu for simple kmem_cache_free callback Message-ID: References: <3b6fe525-626c-41fb-8625-3925ca820d8e@paulmck-laptop> <6711935d-20b5-41c1-8864-db3fc7d7823d@suse.cz> <36c60acd-543e-48c5-8bd2-6ed509972d28@suse.cz> <5c8b2883-962f-431f-b2d3-3632755de3b0@paulmck-laptop> <9967fdfa-e649-456d-a0cb-b4c4bf7f9d68@suse.cz> <6dad6e9f-e0ca-4446-be9c-1be25b2536dd@paulmck-laptop> <4cba4a48-902b-4fb6-895c-c8e6b64e0d5f@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4cba4a48-902b-4fb6-895c-c8e6b64e0d5f@suse.cz> X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Jason A. Donenfeld" , kvm@vger.kernel.org, Neil Brown , kernel-janitors@vger.kernel.org, Olga Kornievskaia , kasan-dev , Dai Ngo , Christophe Leroy , coreteam@netfilter.org, "Naveen N. Rao" , Jakub Kicinski , linux-trace-kernel@vger.kernel.org, paulmck@kernel.org, bridge@lists.linux.dev, ecryptfs@vger.kernel.org, Nicholas Piggin , linux-can@vger.kernel.org, linux-block@vger.kernel.org, Mathieu Desnoyers , Tom Talpey , linux-nfs@vger.kernel.org, netdev@vger.kernel.org, Lai Jiangshan , linux-kernel@vger.kernel.org, Julia Lawall , Uladzislau Rezki , netfilter-devel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, wireguard@lists.zx2c4.com Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Jun 19, 2024 at 11:28:13AM +0200, Vlastimil Babka wrote: > On 6/18/24 7:53 PM, Paul E. McKenney wrote: > > On Tue, Jun 18, 2024 at 07:21:42PM +0200, Vlastimil Babka wrote: > >> On 6/18/24 6:48 PM, Paul E. McKenney wrote: > >> > On Tue, Jun 18, 2024 at 11:31:00AM +0200, Uladzislau Rezki wrote: > >> >> > On 6/17/24 8:42 PM, Uladzislau Rezki wrote: > >> >> > >> + > >> >> > >> + s = container_of(work, struct kmem_cache, async_destroy_work); > >> >> > >> + > >> >> > >> + // XXX use the real kmem_cache_free_barrier() or similar thing here > >> >> > > It implies that we need to introduce kfree_rcu_barrier(), a new API, which i > >> >> > > wanted to avoid initially. > >> >> > > >> >> > I wanted to avoid new API or flags for kfree_rcu() users and this would > >> >> > be achieved. The barrier is used internally so I don't consider that an > >> >> > API to avoid. How difficult is the implementation is another question, > >> >> > depending on how the current batching works. Once (if) we have sheaves > >> >> > proven to work and move kfree_rcu() fully into SLUB, the barrier might > >> >> > also look different and hopefully easier. So maybe it's not worth to > >> >> > invest too much into that barrier and just go for the potentially > >> >> > longer, but easier to implement? > >> >> > > >> >> Right. I agree here. If the cache is not empty, OK, we just defer the > >> >> work, even we can use a big 21 seconds delay, after that we just "warn" > >> >> if it is still not empty and leave it as it is, i.e. emit a warning and > >> >> we are done. > >> >> > >> >> Destroying the cache is not something that must happen right away. > >> > > >> > OK, I have to ask... > >> > > >> > Suppose that the cache is created and destroyed by a module and > >> > init/cleanup time, respectively. Suppose that this module is rmmod'ed > >> > then very quickly insmod'ed. > >> > > >> > Do we need to fail the insmod if the kmem_cache has not yet been fully > >> > cleaned up? > >> > >> We don't have any such link between kmem_cache and module to detect that, so > >> we would have to start tracking that. Probably not worth the trouble. > > > > Fair enough! > > > >> > If not, do we have two versions of the same kmem_cache in > >> > /proc during the overlap time? > >> > >> Hm could happen in /proc/slabinfo but without being harmful other than > >> perhaps confusing someone. We could filter out the caches being destroyed > >> trivially. > > > > Or mark them in /proc/slabinfo? Yet another column, yay!!! Or script > > breakage from flagging the name somehow, for example, trailing "/" > > character. > > Yeah I've been resisting such changes to the layout and this wouldn't be > worth it, apart from changing the name itself but not in a dangerous way > like with "/" :) > > >> Sysfs and debugfs might be more problematic as I suppose directory names > >> would clash. I'll have to check... might be even happening now when we do > >> detect leaked objects and just leave the cache around... thanks for the > >> question. > > > > "It is a service that I provide." ;-) > > > > But yes, we might be living with it already and there might already > > be ways people deal with it. > > So it seems if the sysfs/debugfs directories already exist, they will > silently not be created. Wonder if we have such cases today already because > caches with same name exist. I think we do with the zsmalloc using 32 caches > with same name that we discussed elsewhere just recently. > > Also indeed if the cache has leaked objects and won't be thus destroyed, > these directories indeed stay around, as well as the slabinfo entry, and can > prevent new ones from being created (slabinfo lines with same name are not > prevented). > > But it wouldn't be great to introduce this possibility to happen for the > temporarily delayed removal due to kfree_rcu() and a module re-insert, since > that's a legitimate case and not buggy state due to leaks. > > The debugfs directory we could remove immediately before handing over to the > scheduled workfn, but if it turns out there was a leak and the workfn leaves > the cache around, debugfs dir will be gone and we can't check the > alloc_traces/free_traces files there (but we have the per-object info > including the traces in the dmesg splat). > > The sysfs directory is currently removed only with the whole cache being > destryed due to sysfs/kobject lifetime model. I'd love to untangle it for > other reasons too, but haven't investigated it yet. But again it might be > useful for sysfs dir to stay around for inspection, as for the debugfs. > > We could rename the sysfs/debugfs directories before queuing the work? Add > some prefix like GOING_AWAY-$name. If leak is detected and cache stays > forever, another rename to LEAKED-$name. (and same for the slabinfo). But > multiple ones with same name might pile up, so try adding a counter then? > Probably messy to implement, but perhaps the most robust in the end? The > automatic counter could also solve the general case of people using same > name for multiple caches. > > Other ideas? > One question. Maybe it is already late but it is better to ask rather than not. What do you think if we have a small discussion about it on the LPC 2024 as a topic? It might be it is already late or a schedule is set by now. Or we fix it by a conference time. Just a thought. -- Uladzislau Rezki