From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) (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 9ED8232F741 for ; Wed, 18 Feb 2026 21:26:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771449969; cv=none; b=h/KCkNbKU2mbw5Wmts+95ghU8DDtji2UNTUK+hwlBQfQPpicCh0vHQEBEKnhv22rNSctB3Usxnk/M6JMc3Rv0SvHELFgJ88Xf3wdT0rc+HbsvYWXMu1FcHAXv4jxMlSrWg5k5Y5iirbuXm3GhHEIrdHTgObPwCgTQqJVewz6rPU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771449969; c=relaxed/simple; bh=TSEiRfMtoPLZ8CTZelBiCt+Z45NKL8wNlq9NjpF03LE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EuL9CS3cFoA7+eA1+MS5/HqF6S+yOP084vt0rJhdijKcsTD/Cu9szkPvUFbiewJAbczaYJCmUVFvkB9ObLVoDzmGqp4k/tE2dOkPusoZ2CbWlEtSWJxr2qtr3LpBU9Fd4zHR5UkdTTpqzsxiI+TKc+pWQ5DfZ424c9QLXP+KWss= 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=n1x2hzsx; arc=none smtp.client-ip=91.218.175.174 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="n1x2hzsx" Date: Wed, 18 Feb 2026 13:25:44 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1771449955; 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=wo6vv3zwAb49jabaYEhJvfqzD+EG3AeCMF5nyF6m1Uo=; b=n1x2hzsxevl2KlW0/u2V4Vyr/ZSO5Xh+P9TXfWKLEIalUF12vlcIdJ8A5qhfR4EXzkOPNc tA8qejHL3g3QvA2gIMr6KY/kDgpRKkTCAAG7m+6aiqlp3hyLgb8cRmYYEXY3+leRbLTv7i xA43Ain+4HSrKFlMxM5ocAXx9hoOfKQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Vlastimil Babka Cc: Carlos Maiolino , Venkat Rao Bagalkote , Johannes Weiner , Michal Hocko , Roman Gushchin , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, LKML , Madhavan Srinivasan , Ritesh Harjani , ojaswin@linux.ibm.com, Muchun Song , Cgroups , "linux-mm@kvack.org" , Harry Yoo , Hao Li Subject: Re: [next-20260216]NULL pointer dereference in drain_obj_stock() (RCU free path) Message-ID: References: Precedence: bulk X-Mailing-List: linux-fsdevel@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, Feb 18, 2026 at 12:36:06PM +0100, Vlastimil Babka wrote: > On 2/17/26 13:40, Carlos Maiolino wrote: > > On Tue, Feb 17, 2026 at 04:59:12PM +0530, Venkat Rao Bagalkote wrote: > >> Greetings!!! > >> > >> I am observing below OOPs, while running xfstests generic/428 test case. But > >> I am not able to reproduce this consistently. > >> > >> > >> Platform: IBM Power11 (pSeries LPAR), Radix MMU, LE, 64K pages > >> Kernel: 6.19.0-next-20260216 > >> Tests: generic/428 > >> > >> local.config >>> > >> [xfs_4k] > >> export RECREATE_TEST_DEV=true > >> export TEST_DEV=/dev/loop0 > >> export TEST_DIR=/mnt/test > >> export SCRATCH_DEV=/dev/loop1 > >> export SCRATCH_MNT=/mnt/scratch > >> export MKFS_OPTIONS="-b size=4096" > >> export FSTYP=xfs > >> export MOUNT_OPTIONS=""- > >> > >> > >> > >> Attached is .config file used. > >> > >> > >> Traces: > >> > > > > /me fixing trace's indentation > > CCing memcg and slab folks. > Would be nice to figure out where in drain_obj_stock things got wrong. Any > change for e.g. ./scripts/faddr2line ? > > I wonder if we have either some bogus objext pointer, or maybe the > rcu_free_sheaf() context is new (or previously rare) for memcg and we have > some locking issues being exposed in refill/drain. > Yes output of ./scripts/faddr2line would be really helpful. I can't think of anything that might go wrong in refill/drain.