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 4E887C27C53 for ; Wed, 12 Jun 2024 16:25:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CC7626B00A2; Wed, 12 Jun 2024 12:25:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C76FB6B00A3; Wed, 12 Jun 2024 12:25:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B17856B00A4; Wed, 12 Jun 2024 12:25:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 8EBDD6B00A2 for ; Wed, 12 Jun 2024 12:25:14 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2FA6B80532 for ; Wed, 12 Jun 2024 16:25:14 +0000 (UTC) X-FDA: 82222761348.25.ADF0150 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf22.hostedemail.com (Postfix) with ESMTP id 2F7B6C0023 for ; Wed, 12 Jun 2024 16:25:11 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VhOkhGJb; spf=pass (imf22.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718209512; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cjViDW1ofcPI9Q3XzCSNNVOySVpdiDhgF1rEIa0r7VA=; b=EXTFpiegTJJaH4OGbx3nnHAMxp93Obx7nthO3sP2IRlurgWWfuL2PdvgJrG+s9WEoMiDFV 1JSeKW2MHQ5rrkZeAF3Y+IW/ns9tS3TpvaLn2Y/UI9BoHSj+I3jt+O/qONK5fS3ZXhCc05 mwvHXUcKS2dNfw2pppkxyeUWZ4PehD0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718209512; a=rsa-sha256; cv=none; b=jCxL1xGnvHD/KSpJdog3Xcn29u4tvaKjK20V5FmY25QIPsiBbrx+3+AcnFkc+y8LemawD4 GK8i9n8zdeyUFyWrI1P+/AZzI26yLkUJd/dVs17LCVEeqgidJDR/aJeAQb3TnLZumVzBe1 +Ubqv5lOf2nWdhxfik4muvQ2sPbZa9o= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=VhOkhGJb; spf=pass (imf22.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-5295eb47b48so79373e87.1 for ; Wed, 12 Jun 2024 09:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718209510; x=1718814310; darn=kvack.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=cjViDW1ofcPI9Q3XzCSNNVOySVpdiDhgF1rEIa0r7VA=; b=VhOkhGJbQho94VrPgeLrI991Y5Rq+XhlpD9OPFsw5OBtNhdiO1unkWjIRx7wER5Z// FsnAd86Q1mUWIN/unXPwqWis55gas0Q9nlUXKvnv1SMqszmQQ2y8ziI4at5ylQI5Rbmt vBBzFBjf50IP9/MGPhRUdfKvtMH9Rrp/TTIk0hBSJYUIx9neZqM+Cg2A5rFvNLRK/7wV R3wZkPuhbwCxQrkkMUokaqM2vpSc/qzSSy/SX3Lj6eG0U7I0NuEn2B9obGUDQwE0ZT9J lSVlvHc2hFw+FoqjGRWh9L0HxpQH80EjPgBmsoG/yUCPMRuhcpk9uOzibYZ2Tndxi82T zPqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718209510; x=1718814310; 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=cjViDW1ofcPI9Q3XzCSNNVOySVpdiDhgF1rEIa0r7VA=; b=S6V082vhI3MJPmsvxga2w7fVZJQGyGoN4y0wuO67Jc9WCENglNSUJ+hwQ9CTyCHEOG /68ZP+EXkycsqEmgSdUQrD6I/vsNuT6Qsshhxw35n+aX9pe2rzQjXZzoyK0Jt2+o4MaW 39Ly4YXHqvxnIxqWSPlQUcBQa2My1IU52Di/O4rfBNQUCanSv1fxGJwcSr3PPhyqfrEA iX/zWnyPjceRvAlz0Ow/HCxNy0Op6DObZzQS4Ll5eNLmdziigNKfdjw8LG15+Bf3z5em fb+TzXHaYxV0mQvCfuIPOEEWyngGuFoaWZqVKqBsuSt1/njPgH5mMpPAnb43/JK0rBhF 01Aw== X-Forwarded-Encrypted: i=1; AJvYcCUu5H3+El0Wh4aA0A2oBJffq+kuBC7pAFgzZXFC3GaYwJqvWhvawGdRsF0G3qaeS6oJqMi4UmfT/xSHPSUg40rdDPw= X-Gm-Message-State: AOJu0YwyM9Sh+JhRrxsnEo8PJ8zMBmRXOZe+ZUcus2k/VWeOp7dHXZaR GOGNUHTOhrTXZjfLIYC6zwI9V/UFGlCp34tEnM1LoA/a1Um5SEYn X-Google-Smtp-Source: AGHT+IHBg4ENXu6zKpZ4W+gE4pdn4C5m09sRJi6Bz+mwDKzOLfMiJn8NxGSpgfnMNC0+xPotL9oCnA== X-Received: by 2002:a05:6512:20c7:b0:52c:83c2:9670 with SMTP id 2adb3069b0e04-52c9a405bbcmr1175666e87.69.1718209510177; Wed, 12 Jun 2024 09:25:10 -0700 (PDT) Received: from pc636 (host-90-233-193-23.mobileonline.telia.com. [90.233.193.23]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-52c8a3be915sm1465837e87.289.2024.06.12.09.25.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Jun 2024 09:25:09 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 12 Jun 2024 18:25:06 +0200 To: Linus =?utf-8?Q?L=C3=BCssing?= , Vlastimil Babka Cc: "Paul E. McKenney" , b.a.t.m.a.n@lists.open-mesh.org, Dmitry Antipov , netdev@vger.kernel.org, rcu@vger.kernel.org, Matthew Wilcox , "linux-mm@kvack.org" Subject: Re: [PATCH] Revert "batman-adv: prefer kfree_rcu() over call_rcu() with free-only callbacks" Message-ID: References: <20240612133357.2596-1-linus.luessing@c0d3.blue> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 2F7B6C0023 X-Rspam-User: X-Rspamd-Server: rspam08 X-Stat-Signature: zxxq8ytiiaw7bmxyic7b8ezt3kbi7gbk X-HE-Tag: 1718209511-259828 X-HE-Meta: U2FsdGVkX19SodiGuM9+AbPjVTV/zSjOGR+CYpTzc5S59N62sdvm+Ex2D3SanCQ6EVsZ2mkq4P9rqsCJ+NxaAEUs2JqHMVb6sCypWgny89PWIK/Ll+SwWyFNSPht6Bs/CK6OcAMXK3+V2o6RmmrZA0t/eQwPiLD/hkj1RimmrU4TZznO+VXM8ER4cCSaKiA5VKY5L6NyMfhG7+CbJiukdkeytBeaCMWPnbrrKiNflCBglXAsMFqJzWLo/M50Qha6g1G5AWvQ+dTyFKeLVFw80qXZz9On0DZZZtgxFVTbvtyJmsUcV7fg8HM+x0liHIf0v3Ijl9n3vFiEkupvK6VUdEe4Ob2xfoA8RYzL6KM2XeZ3ePBPWCgZMPvutB83Ut9YoHHjNEhq4VwdlzeE4yVQIi2vuELdsyJYngiVFRsDvA1LNXpR76/8mc96NYpcIB9AR9Dh3VOIJJuq2wn47L1b0/Pbcr4Lyw6oodx2c/qY07dyzupa7OQuNVYVRoKS9PruCJUOP2Jj9+5hedQdTMHYKtTrsh7ZuZ13K3wp6zdNgjPj75OM+GrEwe1jIcAtW2IsEHz/98P3lvFMkDRrEHz9PG54aucXl42Yl8GXoZTjbiO/goAEbgKuJw3mSlCcfr2vBAiKpwn+gTbZ6FC3xcuH2jAuRaUPRymu6rBYYnlVwJze9OEjCi2IAGzfeK0lEkr3c9JZWhn8xieAB52xa/KllBpmUrALFIVJFY/JMEa3HSiHTGRpzSuqsDLaYNuaORBt21pzmiTTN2YkEdRiqfPMlzpfzHttJoJ8LZs0sVEMy6imtXHQ07mPyuZ0752TzhrzOtIypgSeHYhjtXafeReRK4guRUVkbKmNzsyapz1xHFD+GqQcS+YmW28hwwEqcq8EpX2eOaIFSFr2cDCIchcALZOdoHVgajf8/dlTQdP6zu9QsyHKyRuREuKmGBjOI/3a1t/x0hSf52CdtY/I4W+ tZlfd7TJ ql4sbJoLSpw2v0/VoWweL3czdOi3KzkIe3YKWWBQ9jtmcEayfrsATC7YmhvcxSpqHW4Z3Y4xluhgjI3oh4WOxTzjR0O7oOIvvI9Nuck1qIh/Y8Rmu+v+6GTM+K29MCgkC5FZrXeOIzUeE186VmVmxPi/kOUQF8al2+2MGxaZwhWhyKD+51U7Z+KVQ4NAGufOEVa7Y3M+codYM7HoEnqN4nyCF47ah9tCNSa5vN+yevl3nfTn9kdfPlfVAvTc9frgu5lnsxHVzbgR3FQhhGXYSF/U4QvLoEikHRWYzCw9nH0KRPL0JxYlK/crjPJc/gTWaoPK4gasX93V3HEuWTgYpGz7z27Jfq8JOCp/SQiDBxH9pzXBXUQjStMX7zzE6oBfnFStmV+2UUIVEmxhIdnpDkYFwghp63qvwubVDVKPWmS19uaI= 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: List-Subscribe: List-Unsubscribe: + Vlastimil Babka + Matthew Wilcox > On Wed, Jun 12, 2024 at 07:06:04AM -0700, Paul E. McKenney wrote: > > Let me make sure that I understand... > > > > You need rcu_barrier() to wait for any memory passed to kfree_rcu() > > to actually be freed? If so, please explain why you need this, as > > in what bad thing happens if the actual kfree() happens later. > > > > (I could imagine something involving OOM avoidance, but I need to > > hear your code's needs rather than my imaginations.) > > > > Thanx, Paul > > We have allocated a kmem-cache for some objects, which are like > batman-adv's version of a bridge's FDB entry. > > The very last thing we do before unloading the module is > free'ing/destroying this kmem-cache with a call to > kmem_cache_destroy(). > > As far as I understand before calling kmem_cache_destroy() > we need to ensure that all previously allocated objects on this > kmem-cache were free'd. At least we get this kernel splat > (from Slub?) otherwise. I'm not quite sure if any other bad things > other than this noise in dmesg would occur though. Other than a > stale, zero objects entry remaining in /proc/slabinfo maybe. Which > gets duplicated everytime we repeat loading+unloading the module. > At least these entries would be a memory leak I suppose? > > ``` > # after insmod/rmmod'ing batman-adv 6 times: > $ cat /proc/slabinfo | grep batadv_tl_cache > batadv_tl_cache 0 16 256 16 1 : tunables 0 0 0 : slabdata 1 1 0 > batadv_tl_cache 0 16 256 16 1 : tunables 0 0 0 : slabdata 1 1 0 > batadv_tl_cache 0 16 256 16 1 : tunables 0 0 0 : slabdata 1 1 0 > batadv_tl_cache 0 16 256 16 1 : tunables 0 0 0 : slabdata 1 1 0 > batadv_tl_cache 0 16 256 16 1 : tunables 0 0 0 : slabdata 1 1 0 > batadv_tl_cache 0 16 256 16 1 : tunables 0 0 0 : slabdata 1 1 0 > ``` > > That's why we added this rcu_barrier() call on module > shutdown in the batman-adv module __exit function right before the > kmem_cache_destroy() calls. Hoping that this would wait for all > call_rcu() / kfree_rcu() callbacks and their final kfree() to finish. > This worked when we were using call_rcu() with our own callback > with a kfree(). However for kfree_rcu() this somehow does not seem > to be the case anymore (- or more likely I'm missing something else, > some other bug within the batman-adv code?). > Some background: Before kfree_rcu() could deal only with "internal system slab caches" which are static and live forever. After removing SLAB allocator it become possible to free a memory over RCU using kfree_rcu() without specifying a kmem-cache an object belongs to because two remaining allocators are capable of convert an object to its cache internally. So, now, kfree_rcu() does not need to be aware of any cache and this is something new. In your scenario the cache is destroyed and after that kfree_rcu() started to free objects into non-existing cache which is a problem. I have a question to Vlastimil. Is kmem_cached_destroy() removes the cache right away even though there are allocated objects which have not yet been freed? If so, is that possible to destroy the cache only when usage counter becomes zero? i.e. when all objects were returned back to the cache. Thank you! -- Uladzislau Rezki