From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 243831C862F for ; Sun, 28 Jun 2026 06:01:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782626467; cv=none; b=bwBpD09oYlE6cR26Xi0ZQre/h/oRcVPcmxbvrYX5u0jBWugUMWc9+jhQ2ypzCvBq5hQLoZEN2oD7k9b3RSAquP8yTFws9gzAnSvkTxy8FsaekhSqjI8y9UTjoDn7s1rE9htTbpSmEsmcCSNBij4wieO5dfDays1cRuBIKuVztc0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782626467; c=relaxed/simple; bh=adhpToJISHz0dBY9EeXrcy/vePA6zdx93rqOSDZT26s=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=mOIRYPG3llDnQiv9pdDIOf3hPpcFvLeHdUYecqdbzqS1WcP94KL0J5D1a4syNKy8nMwuoVsNwK4TB8Xgt29Jd0+4Ete/p5ObxQqha8G0aBVmn3h4Np3Vfe3GPtTZPlJ6VVC5VJoXq6g19zAICnxZsu4VzLu9M7RYOHBDUm+Kvyo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=CUtKT3rQ; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="CUtKT3rQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 875A71F000E9; Sun, 28 Jun 2026 06:01:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1782626465; bh=v7o4FC/H4wYIIJ5O45lCyQUnME37whf92MwIGdEhfyc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=CUtKT3rQFUjFEICTBRfs2qcctdekpkiLOUu/r5vionTd+aKLT887pWPewMu07qxiW /rrQZO2E0zQwWxyMSiv9eoEP0s9VWmNoZlUAQdKNd/mXAo/gy+zDoEyiJMoGf8vAhA V/+ifcVhvgMYRuPoXV6tJfiCVwTW6mSZDUaZZ9II= Date: Sat, 27 Jun 2026 23:01:05 -0700 From: Andrew Morton To: Jiayuan Chen Cc: linux-kernel@vger.kernel.org, Thomas Gleixner Subject: Re: [PATCH] debugobjects: skip activate fixup when disabled by a concurrent OOM Message-Id: <20260627230105.0989abc510ad6e5cf63a862c@linux-foundation.org> In-Reply-To: <20260610034726.213910-1-jiayuan.chen@linux.dev> References: <20260610034726.213910-1-jiayuan.chen@linux.dev> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Wed, 10 Jun 2026 11:47:25 +0800 Jiayuan Chen wrote: > When a tracking object cannot be allocated, lookup_object_or_alloc() > sets debug_objects_enabled = false and the caller runs > debug_objects_oom(), which wipes the whole hash. The flag is cleared > before the hash is wiped. > > debug_object_activate() only tests debug_objects_enabled once on entry. > If another CPU hits OOM and wipes the hash after that test, the lookup > here misses and the object is taken as ODEBUG_STATE_NOTAVAILABLE. > fixup_activate() then "repairs" it; for timers that overwrites a live > timer's callback with stub_timer, which later fires a bogus WARN. > > Re-check debug_objects_enabled while still holding the bucket lock, > before the fixup. The flag is cleared before the hash is wiped, and both > the wipe and the lookup are serialized by the bucket lock, so a > wipe-induced miss is guaranteed to observe the cleared flag and the > spurious fixup is skipped. Thanks for working on this. The patch was sent at an inopportune time - late in -rc people aren't paying much attention to new material so bugfixes can fall through cracks. How was this problem observed? Code inspection? Fault injection? Real-world failures? If it is known that this WARN can trigger in real-world situations then we'll probably want to fix earlier kernels, which means a Fixes: and a cc:stable. > --- a/lib/debugobjects.c > +++ b/lib/debugobjects.c > @@ -865,6 +865,16 @@ int debug_object_activate(void *addr, const struct debug_obj_descr *descr) > } > } > > + /* > + * A concurrent OOM teardown may have disabled debugobjects and > + * wiped the hash after the check at function entry. So we need > + * check it again here. > + */ > + if (!debug_objects_enabled) { > + raw_spin_unlock_irqrestore(&db->lock, flags); > + return 0; > + } > + Sashiko AI review suggests that further fixing might be needed: https://sashiko.dev/#/patchset/20260610034726.213910-1-jiayuan.chen@linux.dev