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 0120B2E7BD6 for ; Sat, 25 Jul 2026 21:59:37 +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=1785016779; cv=none; b=ei0PLZ+GThkHvETf7uDhyiqJ/zBzLaHUp+nRcp0mKbVVx3aKiWysbIz0ArA8rG5SkQ2Cwpa9SkAxt7a14wxzyzxkYOHA8huCmpViAL2nUo5NAt2Ki1hck0GGpGAI5OCuCHdfAuaKFeNNyQqhDa6cmVTofSNrBiv0GweyZiN/SLg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785016779; c=relaxed/simple; bh=TLX7bjkrUlR3ylBho5D098K3wNBzhK1JlXFHkP674Jk=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=jyFwt+HpLpS5npGygex0CJQAW/fOup/d82OICAfOxHe88yZ1Aa7yjrESyrkB3m8zVRIADjbJNNQLRYr3/GxWamyqXHpa8bT2ZDXS2VcBUBbnasvYA4itfh31qx8zdMF2iO1WCaQaTTBDcEvrhV2j3+Ij4be4O3LPTWVTFns4pQA= 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=ujaVABHr; 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="ujaVABHr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F1501F000E9; Sat, 25 Jul 2026 21:59:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1785016777; bh=3M/alIcjiaYyiRtH7uJlfOHsLmeroinYUreIdaOArFE=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ujaVABHrqsoexQ2uS+8H4LNPyNV8qvxHCDIqFzsg0qkX25sqhMOG3xAuhk4Qr1mqP cVXyL6fGJlQCaIhLFgOeqK5wrd34qngT6/hKSQSYwSoJIbv2MBsaNWiEfXMhV33eMu eDAeFZsoTB0YoY3oJ987fi9rK/HITwiG77fDr5mI= Date: Sat, 25 Jul 2026 14:59:36 -0700 From: Andrew Morton To: Tetsuo Handa Cc: Alexander Potapenko , Sebastian Andrzej Siewior , Dmitry Vyukov , kasan-dev , LKML , Alan Stern , Andrey Konovalov , Andrey Konovalov , Clark Williams , Greg Kroah-Hartman , Marco Elver , Roman Gushchin , Christoph Hellwig , Mark Brown Subject: Re: [PATCH v7] kcov: fix data corruption and race conditions on PREEMPT_RT Message-Id: <20260725145936.11e2d08c90044b8bcb3ab149@linux-foundation.org> In-Reply-To: <43552d09-2ce2-4b19-b0d3-a2d1ab952145@I-love.SAKURA.ne.jp> References: <1956540a-e458-4a44-854b-11ff07cb1072@I-love.SAKURA.ne.jp> <20260521083848.UF_zf4xK@linutronix.de> <20260521181450.Ax-chxOE@linutronix.de> <88c3951e-f733-4733-ab81-4feeb5de6b51@I-love.SAKURA.ne.jp> <7aff4d71-a6a0-4898-9491-2a3973e9d0cc@I-love.SAKURA.ne.jp> <7eb7e90a-69a7-4290-93ff-cc0f37ab69f4@I-love.SAKURA.ne.jp> <8eef915c-96d4-4901-b404-60a19d5f9f54@I-love.SAKURA.ne.jp> <43552d09-2ce2-4b19-b0d3-a2d1ab952145@I-love.SAKURA.ne.jp> 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 Thu, 16 Jul 2026 08:01:29 +0900 Tetsuo Handa wrote: > syzbot is reporting KCOV state corruption on PREEMPT_RT kernels, for the > temporary storage used for saving/restoring remote KCOV state is currently > allocated as the per-CPU area. > > On PREEMPT_RT kernels, softirq handlers run as preemptible task threads > (e.g., ksoftirqd). If a softirq context preempts a task running a remote > KCOV session, it safely saves the task's state into the per-CPU area. > However, if that softirq thread is subsequently preempted by a higher- > priority softirq thread on the same CPU, the second softirq will overwrite > the same per-CPU area, permanently destroying the original task's KCOV > state. > > Fix this data corruption by moving the temporary storage from the per-CPU > area to the per-thread area. Since each softirq thread now owns its own > task context, nested softirq preemption no longer causes data overwrites. All sounds rather unpleasant. Should we add cc:stable here?