From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 239943FFAC1 for ; Mon, 29 Jun 2026 12:40:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782736859; cv=none; b=kSHb9ghBODmkOBW0kGeKtVsw8MHZQGD1uP3fvQlMTIlYrIvUA6hqQ7++8PVOhLfaRAZdRECqsQIeBSwwWl4sp5DOYlZUKKRDMNlXc9gtFBIzqxmtgWgOOBATG7FSfUiTmBV1DBGEv4JXLDrMze8YTKCMJS+7d8o+I/in4VOaa18= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782736859; c=relaxed/simple; bh=MBQvj9C3fGh00W+5tHrupwkGYVoMskBzvA3h4S5l5ls=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=FT6aBmFg1TAOi8TxW8XStkF8nNbUUj6+pEHpWNof4ohgYoPACxRrQY+0WjsDlqeDmzGbjTrfSQAHyb3WAl74tFy+rdaG7JIRx1RwJlyFWeRwu41j59AiuMQVjELSgSslAXecacW0gVjsMDkMJs52bfGza1gsaaMESCDJTZ4roYQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=NOKhEgTc; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=ArT1ouO9; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="NOKhEgTc"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="ArT1ouO9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1782736857; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=MBQvj9C3fGh00W+5tHrupwkGYVoMskBzvA3h4S5l5ls=; b=NOKhEgTcjv8KAVheRjJnAuc/wpwarhqWKWq+20pMedPj4BGDGehqgyHNwtiqe8U12x1qHY pQEMfnzz43U/CLZEVbL/k8bd818B9SKy3oG3mLmuqX+OkpnP5/PIdgqVYsP1kNCDaAa2xS eqtuhx2Pos8DXOk2ONB8LcXfWgr4ZqY= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-158-yjMPwnCpNGaLx4BuI0QBGg-1; Mon, 29 Jun 2026 08:40:53 -0400 X-MC-Unique: yjMPwnCpNGaLx4BuI0QBGg-1 X-Mimecast-MFC-AGG-ID: yjMPwnCpNGaLx4BuI0QBGg_1782736853 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-4926d371224so19838415e9.1 for ; Mon, 29 Jun 2026 05:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1782736852; x=1783341652; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to; bh=MBQvj9C3fGh00W+5tHrupwkGYVoMskBzvA3h4S5l5ls=; b=ArT1ouO97/jEtt74t6ZLbaMukGfbM7xQKnwWADGcgA26BCReAPoGxaLLSSS/WxGeCA oEeZdA1Aka57ug8Rh+EvFmvkvRzRPHgdyNFHuZoJkCNIqORubrA/Zf1Prxf0vJsuAYQq YaIaHvtRJabhBc7t8O+yKZjZi171d2C9gBYQFD0UcLFhrp0yRrzsS/T5rKv3tuUHoW8r XCyMo1nWWaOZCuJpVAEKjxLHS3M+Lrf00ckngW/VLAJo7gblKziQP+DzgubxyvyTDXWQ EeVpcFOzyx3nHIJm+wPoVIPciHsdIk1YairKuLm0c6hupMzujfQ5jXLB2G/SZRDmzvZR MlLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782736852; x=1783341652; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MBQvj9C3fGh00W+5tHrupwkGYVoMskBzvA3h4S5l5ls=; b=CjY5GycYuk5gFAQ4K8q5VKH+vcIRsz+CQ6j/0ZFwvV3ESjDfFacWFRQsj2iVyJvPL/ AVKF4d61yxHeqvb1W2EDq3UGy/0ObvLjkTfPaVNrBhLc8Gbjf5Vp6nnmL56fDqlt8ElM RE/61qwvdF5bwcHqYYclWsKoszvFpI4m324tJ/DfxHyr8/Zu57fOMs9wmAADEJs2bFn0 SHrZae89J3oxYmMfERNcvsrswUryLaTQQM3jfveShHmnEY1NebN7rXdGM3PHFafr3RV8 JhXX8D1tpvCKANi8Y6lzhEb07r8LFg1d27wQRLcebLK3a3FondHIE1C4kYOy8kYO7AjZ 1usQ== X-Forwarded-Encrypted: i=1; AFNElJ/ixmgj/DmheUJ3Z8HRv/Ir4NI4DWnOqgi4hpAUQsOnPUhRGzSJKzv7Z8OvGEhVtQex01nTOXeJbA9PaIg=@vger.kernel.org X-Gm-Message-State: AOJu0YyPyPBqBTqSDnrKJ5D85GqyAhN63J3R+skgLGHOhj6yozpJ9JlA FBIZGnt/lWnImRg7/AWira4wDrTIqRI8C7bw3kTqWJqnhZWDhpXTyIQNvvO82A95hT1LMWSk3hY hh0kjzwxIYIm5IClLlykXNf1AYQhFe0bCC60pm9pwd5CS6j69dThKeq7oVmAfp335qg== X-Gm-Gg: AfdE7cl17XP8Ug9I/oU2CQnAgk7x4CRa0eHsMPbyWiDF++4K15MTTSINYoiNm3dZpHc VeoCGNm+spZloAqr/dq9fzPvjrn5+aNOUkBDF0wV7XdYjSnS6DHRLKGSmDupKs8MRh42GTgwGcB VUk2D4xhRi1sdORSoITjaDHKJj7qIBU1gHRl1r6N0W66Zqh3NreSd4Pe7Dl6aoXcNoBpa/BXk5W acgBBf2VqSZ0J3juwvIq9x14SbkMR+i2o8XTdinhPVo0Byd+zHHUMMZwVc3b7zZ2TrfpB1pZrEu 5IbpkfoW0wZCZWQRRalGkytSzedU0TFipaBUrc6I/XR3/1vLuO5Co6nHbuKe1+/YKlhDmPvFWTG y5JMVOtyNmmYnr/DoS45leFtDNMHAm9ROVgRUn7smBFso+OJJhxAvMJogJwlIHcZa806GR+cbgp XQJGuY X-Received: by 2002:a05:600c:4e4b:b0:492:7078:4ead with SMTP id 5b1f17b1804b1-49270784ee4mr143634895e9.25.1782736852517; Mon, 29 Jun 2026 05:40:52 -0700 (PDT) X-Received: by 2002:a05:600c:4e4b:b0:492:7078:4ead with SMTP id 5b1f17b1804b1-49270784ee4mr143634325e9.25.1782736851890; Mon, 29 Jun 2026 05:40:51 -0700 (PDT) Received: from gmonaco-thinkpadt14gen3.rmtit.csb (212-8-243-115.hosted-by-worldstream.net. [212.8.243.115]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-492690a1a85sm544810635e9.15.2026.06.29.05.40.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jun 2026 05:40:51 -0700 (PDT) Message-ID: <6cbcc3ea742b92b6a34b5994f5498c7611beac7e.camel@redhat.com> Subject: Re: [PATCH v2] sched: set TIF_NEED_RESCHED before calling __trace_set_need_resched() From: Gabriele Monaco To: K Prateek Nayak , Sechang Lim , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot Cc: Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , linux-kernel@vger.kernel.org Date: Mon, 29 Jun 2026 14:40:48 +0200 In-Reply-To: References: <20260627081657.499781-1-rhkrqnwk98@gmail.com> Autocrypt: addr=gmonaco@redhat.com; prefer-encrypt=mutual; keydata=mDMEZuK5YxYJKwYBBAHaRw8BAQdAmJ3dM9Sz6/Hodu33Qrf8QH2bNeNbOikqYtxWFLVm0 1a0JEdhYnJpZWxlIE1vbmFjbyA8Z21vbmFjb0BrZXJuZWwub3JnPoiZBBMWCgBBFiEEysoR+AuB3R Zwp6j270psSVh4TfIFAmjKX2MCGwMFCQWjmoAFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgk Q70psSVh4TfIQuAD+JulczTN6l7oJjyroySU55Fbjdvo52xiYYlMjPG7dCTsBAMFI7dSL5zg98I+8 cXY1J7kyNsY6/dcipqBM4RMaxXsOtCRHYWJyaWVsZSBNb25hY28gPGdtb25hY29AcmVkaGF0LmNvb T6InAQTFgoARAIbAwUJBaOagAULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgBYhBMrKEfgLgd0WcK eo9u9KbElYeE3yBQJoymCyAhkBAAoJEO9KbElYeE3yjX4BAJ/ETNnlHn8OjZPT77xGmal9kbT1bC1 7DfrYVISWV2Y1AP9HdAMhWNAvtCtN2S1beYjNybuK6IzWYcFfeOV+OBWRDQ== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.2 (3.60.2-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2026-06-29 at 09:41 +0530, K Prateek Nayak wrote: > Unrelated to changes here: This tracepoint seems to be missing from > wake_up_idle_cpu() which modifies the ti->flags without taking the > rq_lock. >=20 > A newly enqueued timer can race with the wakeup on idle CPU and you can > see a wakeup + sched_switch without seeing a corresponding > trace_sched_set_need_resched_tp() for the CPU. >=20 > Gabriele, is that a concern for RV? Thanks Prateek for pointing this out. So as I'm understanding, we are missi= ng the tracepoint in that path, but even after putting it, this race might cau= se a sched_switch to be visible concurrently or before the corresponding need_re= sched for that CPU, right? That's potentially an issue. Currently the only model really relying on the need_resched event is nrp, validating every kernel preemption has a corresponding need_resched set. The scenario passing through wake_up_idle_cpu() is setting the flag on a CP= U that is idle (causing __schedule(SM_IDLE)), this doesn't count as a preempt= ion for the model. Or am I missing something? That said, we should indeed add the tracepoint to that path and probably ad= apt the monitor if that's making it fail indirectly. Thanks, Gabriele > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (need_ipi) { > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 if (tif =3D=3D TIF_NEED_RESCHED) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 smp_s= end_reschedule(cpu); > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } else { > > -- > > 2.43.0 > >=20