From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 B4CC338D406 for ; Thu, 21 May 2026 18:14:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779387295; cv=none; b=rJ9lrpUVPq+gXVoP88oGlFEfFHcDc5CagS947OJnUl96Z4Ah9/NrULzJOmVD/j05eUehT8pVDPcPMmppT9bbA/99uOm1FKUZdAmyWN9QbZaqakyWf89yOr84GTNVNa5ZHJ00zRj+KXL8gg4bY46NT5QNph2bFSA99mbPmhHw17A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779387295; c=relaxed/simple; bh=UWeZoxkr91dg1m5NANZT6PjO+0lmxxKh/LZGGLSvvJ0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mSHcwKU3PIaLEVk8Dd7Rf0+QUPEWOKIJf9KwqrwEy6sNYNM1kNbuxiOBZNvQYzN2C5bq+qn6wUnoOtcDV8lmn5E8c84xSgGWJXTPTeZjBG7+gwHhy0TlwM132eaO5xO+8wKomXwtBryn5uZcQLSajcl0cly02m9U6EYpLCkCULk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=wYyjouPC; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=88Q+LGff; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="wYyjouPC"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="88Q+LGff" Date: Thu, 21 May 2026 20:14:50 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1779387291; 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=HnA0WNSsqROC7RNF5vfiexiKcgYyAEA33uV95fX/i1M=; b=wYyjouPCc0qZM4Z7js0HsAMt/X2VuGREpH01TlX985cWb7oTuhagAEUEGTWsA9fRFMPz+c rvPsNNAqj9nX+OYFF1Plmj18/soel0LXDSU1QM7OJuuUsHTl674rw88WuK24dOKV8Q9nPi 1v1om0Mudxi4D804hJrBsLmqnUL6m/AugAW/uMvUCvKKsDDU9YgVacEpeD/EegBzyLOKMH 7UuEstTcg7WFc4gtZ5HWdrYnNWdCRgDCnDhVW0CxmSTfQK26fPcKUffxoAgo2EYMbdTUJ6 XROGenUGxeXmZH+SnFnVJs0sBrIAgNlXAe8YgGg3PM9zXr1RDe16k6d7cnr84w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1779387291; 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=HnA0WNSsqROC7RNF5vfiexiKcgYyAEA33uV95fX/i1M=; b=88Q+LGffSV3dKLp35sCyN/MXlgDNJe0Ir3Cfnh+0DyHDNeRkYKsMjDWAXs3GyK0/fYC4LF 5SjH1GAMatR5/eAg== From: Sebastian Andrzej Siewior To: Tetsuo Handa Cc: kasan-dev , LKML , Dmitry Vyukov , Alexander Potapenko , Alan Stern , Andrew Morton , Andrey Konovalov , Andrey Konovalov , Clark Williams , Greg Kroah-Hartman , Marco Elver Subject: Re: [PATCH v3] kcov: move kcov_remote_data to task_struct for RT and remove local_lock Message-ID: <20260521181450.Ax-chxOE@linutronix.de> References: <1956540a-e458-4a44-854b-11ff07cb1072@I-love.SAKURA.ne.jp> <20260521083848.UF_zf4xK@linutronix.de> 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=utf-8 Content-Disposition: inline In-Reply-To: On 2026-05-22 00:28:26 [+0900], Tetsuo Handa wrote: > > If handling softirqs in parallel might be indeed a reasonable solution. > > You would need to use the per-task area instead per-CPU for this in the > > softirq case on PREEMPT_RT. But the other checks, such as in_task() > > work as intended on both. > > https://share.google/aimode/PveuuU5od6d1lAwit (expires in 7 days) says > > Non-PREEMPT_RT Kernel: in_task() returns false while executing a softirq. > > PREEMPT_RT Kernel: in_task() returns true while executing a softirq (unless > nested inside a hard interrupt or NMI). > > Is this explanation wrong? Yes. If a softirq is executed (in_serving_softirq() returns true) then in_task() returns false. On PREEMPT_RT and on non-PREEMPT_RT kernels. It is irrelevant if the softirq is executed at the end of an interrupt handler and within ksoftirqd. Sebastian