From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [95.215.58.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9EEC5175A8F for ; Wed, 11 Mar 2026 20:09:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773259764; cv=none; b=Fk+emyo1ZuGhwGj38DVaSZoIVgKF71dFsHShD6EgsUpwZqgZyCz1JJxqiWpxR5iOWFdBEXiJJE/NABs/Avfo582ZWBuBfWWBM5oMzGSfDcnzulbH/ZOgSAsjTalOBCrjMz9UHyCgQiBvoMjkJzu4EP48LBXWFIDlSHTd9RUxIIM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773259764; c=relaxed/simple; bh=DWy36Q6HIKKenOCssEDtBsQNbPn9ea9pG0cShX8+VW4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uhfnZ+u36m7hlmE2Z0qATC0SNpRyzzkKfSyBY5UpQiy7K1RjByem5QQD/BM9XDKtNqq6EDVYJx7Lu3RM8pU0LZwryahVwVoYD35PyeA2r616SVRHWC1yGRdoe8lufWVqzRGTdEDjuOiJcvuje7OHQiNaw6O0DB2oYxyE4FBGd6I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=SZIFaxta; arc=none smtp.client-ip=95.215.58.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="SZIFaxta" Date: Wed, 11 Mar 2026 13:09:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1773259759; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uQuA0YpIdsrN1RWSmhy/mTOwH1p+GbEMS26GuV96Pq4=; b=SZIFaxtaJcxWlYrLTUvftvVaiPSgdlnpcm5+jKsRFAO68U7Szwobz4MYv7xVhXIv7ubHRU LP+cHJlbjgIhI5iJTUzVOyy7yAzcMgGTkQ5uZruF91OmDwhGx6c9Zkg84GKMlCOg1os8/7 I1nHql8jbBTqQIrJMEe1P5uCUdFJlPg= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Johannes Weiner Cc: Usama Arif , Andrew Morton , David Hildenbrand , Zi Yan , "Liam R. Howlett" , Kiryl Shutsemau , Dave Chinner , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: switch deferred split shrinker to list_lru Message-ID: References: <20260311154358.150977-1-hannes@cmpxchg.org> <050ce5bd-4725-468e-acaf-7fca72b84d06@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT On Wed, Mar 11, 2026 at 03:24:18PM -0400, Johannes Weiner wrote: > On Wed, Mar 11, 2026 at 01:42:32PM -0400, Johannes Weiner wrote: > > On Wed, Mar 11, 2026 at 08:00:29PM +0300, Usama Arif wrote: > > > On 11/03/2026 18:43, Johannes Weiner wrote: > > > > @@ -3802,33 +3706,25 @@ static int __folio_freeze_and_split_unmapped(struct folio *folio, unsigned int n > > > > struct folio *new_folio, *next; > > > > int old_order = folio_order(folio); > > > > int ret = 0; > > > > - struct deferred_split *ds_queue; > > > > + struct list_lru_one *l; > > > > > > > > VM_WARN_ON_ONCE(!mapping && end); > > > > /* Prevent deferred_split_scan() touching ->_refcount */ > > > > - ds_queue = folio_split_queue_lock(folio); > > > > + l = list_lru_lock(&deferred_split_lru, folio_nid(folio), folio_memcg(folio)); > > > > > > Hello Johannes! > > > > > > I think we need folio_memcg() to be under rcu_read_lock()? > > > folio_memcg() calls obj_cgroup_memcg() which has lockdep_assert_once(rcu_read_lock_held()). > > > > > > folio_split_queue_lock() wraps split_queue_lock() under rcu_read_lock() so wasnt an issue. > > > > In this case, the caller has interrupts disabled, which implies an RCU > > read-side critical section. > > > > That's also why it's using the plain list_lru_lock(), not the irq > > variant. Same for the lruvec lock a few lines down. I followed the > > example of none of that being documented, either ;) > > > > How do folks feel about a VM_WARN_ON(!irqs_disabled()) at the top? > > Okay, lockdep actually does warn. rcu_read_lock_held() is explicit and > not appeased by implicit RCU sections. > > Paul pointed me to rcu_read_lock_any_held(), which we could use in > obj_cgroup_memcg() to suppress the splat and permit implicit RCU. > > Or we can make rcu_read_lock() explicit in the above code. > > Any preferences for how we want to handle this in MM code? I would vote for explicit rcu_read_lock() to be consistent with other places.