From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 261D335F8D1 for ; Sun, 17 May 2026 12:40:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779021650; cv=none; b=A0DOpz2yb9i/DhCf6v+HmdAtczAPpuSnAU3d8+W/0s45r0Sd4B1fwUuoCKqlhEchGeh6odTpMmG0VtXmieQaVyZSy9j1H2Nrc/rlAbp7KR3nsQ+HJ2NcCiGV6pTvgE7XcPWy+lGhYNrXqaXIlbazIZeP9b/jUacjH1h8D9Of6ZM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779021650; c=relaxed/simple; bh=k+BrRivwukn3OK/Y1hu9L8GIvVDUkrvTnBi8DCc2axU=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Qc78+ncx1dshnVXX6KqMdqLSloee4rx7302ORPu0xCAo2b02Rs551MmPCz/qqkRlX8sYtqkUPoTUKnwZBmq4nwMOg+adgCQ7LYDomzreZDyHBhi0uGu3d2q3znX0oBZZTGjlfbC236+s1482HuCOhTiBp6WaXhQefCn1MohhNt0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ct3/h4x/; arc=none smtp.client-ip=209.85.208.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ct3/h4x/" Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-39378db197aso17329471fa.3 for ; Sun, 17 May 2026 05:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779021645; x=1779626445; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=bdw84rcYXuEmEaU8wZljv2tbDx3e6Ol+lObzuMrz5QA=; b=ct3/h4x/X8om2vOlvUhQOnKi1ryu/h+K9ZHfrCNfm36xKGPkC4ca9DJK+T+WghSeJa EPRT57WUJySpy2zCaVzl2f6z/CM7fnhhB9/98bz58HGiqkih8+JP60qRVRHT+B8WE6hV iGgOLvar2vTTuoesub1/7Ga/WB11IeM2PsOYXAIFbULhVVbJly0a3vgX253zzcGTaKRS RuabuTBl1WSak04A/2elrfbqPSMmMDkLTBp3pulFu9NFD1Mzy7GYdYaTggxxFdvBTPNS PBtYod/Tk0rVKTFJS6S+PRfmBYkSIC1neW8LssVKFUEshZlDz39RSjyr0Wb4yJSt+bUY 9WpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779021645; x=1779626445; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=bdw84rcYXuEmEaU8wZljv2tbDx3e6Ol+lObzuMrz5QA=; b=rXx2QsjlVEfpwWKi8k0r26jBZu8Pb/s9g5aQQG6+4/JJsR5Z6iX8pkJkoo2gvwhV9u Td8sjV/oNtfORaoBqjgIxU37d9AhaA9BG0adQ58NyAVTYLea0+xWb5bz0LUMprYudkuU HuHDr44xyykOqocl7UfPEwlZ3DdpcrzLroC4/8j6PnVbaxXckP3uEnAjwDIP6+fZb+xO eVlcR+FeY/RQ03YiWvmBTBGxfU5w502lzQ7OPopLZRkvUwQCPdpsTfse1Gp5ETDfJBLc xZamCCv0snCh1D9Rkvy8OdYjoIqmOAtawXF15ZPCfKJxUlasM32NSR5WznZGybnxOLo2 GTiw== X-Forwarded-Encrypted: i=1; AFNElJ9mEd5ZLz4mLgjYl+wom+72e1D+/DiPukYIlG9lIj+n+B9WtEV4juMQbF0/Bp6pi1k7r9CQ/m85m2FjNt8=@vger.kernel.org X-Gm-Message-State: AOJu0YyG8dhgV9ODqVSrZE3CsIVs/VVWniOAUfR2uwLuCN7Kw9GuPLEz ROCWXu1frkOuAmFoZIOktcHMQ/8zKCcCJzzjVXtJNq/cC6Wuc3MKToa8 X-Gm-Gg: Acq92OExXWYpGqwIIhU0n3xU65SDDNfxw/z25fmadYTv37CySdhdlhNXZ6vVMnur9tl xbqOrxjHf9N3h6sua2sHkOMHQ5m23MamM1kLZotpy6tAa/+Q0X7yV/VeRrec/w2hFOJAAbUPum9 wkjYYd2dq0UZafbpbMUx2RGmq8C798Qgo/iQy8DSLF0SWrSBURA6/aP/57WKQLdh6Ytc2ZEh/xy lUhubXzLmpddm6kJi+hD1w5hNsKUBtt6FlGyCB8vHzjMQfI9xoRyuYd+9EcnUy0qy/WmQ5I0tZf 8OK/BwwRHlvNvijGumPFMlmJDGZWHu9Uvmu14QqqdF9Z/8AzMUVtztTDigALRAjxssnjpF4kUS3 k5UlxX8iyvcAxSZuyhUqTyI3CjPuQcZ+xafDxeSyowauQe5A8ceVlolMztUir+lE2kV/U93kWO0 s+3W7inX0v X-Received: by 2002:a2e:3507:0:b0:38e:ae31:f0a5 with SMTP id 38308e7fff4ca-39561c3db53mr26103021fa.9.1779021645248; Sun, 17 May 2026 05:40:45 -0700 (PDT) Received: from pc636 ([2001:9b1:d5a0:a500:de96:9acf:5dca:ede4]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-3958874ec2fsm4927391fa.26.2026.05.17.05.40.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 May 2026 05:40:44 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Sun, 17 May 2026 14:40:42 +0200 To: Z qiang , "Paul E . McKenney" Cc: "Paul E . McKenney" , qiang.zhang@linux.dev, Joel Fernandes , "Uladzislau Rezki (Sony)" , Frederic Weisbecker , Boqun Feng , RCU , LKML , Saravana Kannan Subject: Re: [PATCH -next v1 01/12] rcutorture: Fully test lazy RCU Message-ID: References: <20260511175448.153326-1-urezki@gmail.com> <20260511175448.153326-2-urezki@gmail.com> 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-Disposition: inline In-Reply-To: On Thu, May 14, 2026 at 09:33:10PM +0800, Z qiang wrote: > > > > From: "Paul E. McKenney" > > > > Currently, rcutorture bypasses lazy RCU by using call_rcu_hurry(). > > This works, avoiding the dreaded rtort_pipe_count WARN(), but fails to > > fully test lazy RCU. The rtort_pipe_count WARN() splats because lazy RCU > > could delay the start of an RCU grace period for a full stutter period, > > which defaults to only three seconds. > > > > This commit therefore reverts the call_rcu_hurry() instances > > back to call_rcu(), but, in kernels built with CONFIG_RCU_LAZY=y, > > queues a workqueue handler just before the call to stutter_wait() in > > rcu_torture_writer(). This workqueue handler invokes rcu_barrier(), > > which motivates any lingering lazy callbacks, thus avoiding the splat. > > > > Questions for review: > > > > 1. Should we avoid queueing work for RCU implementations not > > supporting lazy callbacks? > > Hello, Paul > > maybe we can do this: > > rcu_ops = { > ... > .support_lazy = IS_ENABLED(CONFIG_RCU_LAZY), > }; > > and > > if (cur_ops->support_lazy ) > queue_work(..., &lazy_work); > > > > > 2. Should we avoid queueing work in kernels built with > > CONFIG_RCU_LAZY=y, but that were not booted with the > > rcutree.enable_rcu_lazy kernel boot parameter set? (Note that > > this requires some ugliness to access this parameter, and must > > also handle Tiny RCU.) > > > > 3. Does the rcu_torture_ops structure need a ->call_hurry() field, > > and if so, why? If not, why not? > > > > 4. Your additional questions here! > > > > Reported-by: Saravana Kannan > > Signed-off-by: Paul E. McKenney > > Signed-off-by: Uladzislau Rezki (Sony) > > --- > > kernel/rcu/rcutorture.c | 21 ++++++++++++++++++--- > > 1 file changed, 18 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c > > index 5f2848b828dc..91ba3160ba6a 100644 > > --- a/kernel/rcu/rcutorture.c > > +++ b/kernel/rcu/rcutorture.c > > @@ -572,7 +572,7 @@ static unsigned long rcu_no_completed(void) > > > > static void rcu_torture_deferred_free(struct rcu_torture *p) > > { > > - call_rcu_hurry(&p->rtort_rcu, rcu_torture_cb); > > + call_rcu(&p->rtort_rcu, rcu_torture_cb); > > } > > > > static void rcu_sync_torture_init(void) > > @@ -619,7 +619,7 @@ static struct rcu_torture_ops rcu_ops = { > > .poll_gp_state_exp = poll_state_synchronize_rcu, > > .cond_sync_exp = cond_synchronize_rcu_expedited, > > .cond_sync_exp_full = cond_synchronize_rcu_expedited_full, > > - .call = call_rcu_hurry, > > + .call = call_rcu, > > .cb_barrier = rcu_barrier, > > .fqs = rcu_force_quiescent_state, > > .gp_kthread_dbg = show_rcu_gp_kthreads, > > @@ -1145,7 +1145,7 @@ static void rcu_tasks_torture_deferred_free(struct rcu_torture *p) > > > > static void synchronize_rcu_mult_test(void) > > { > > - synchronize_rcu_mult(call_rcu_tasks, call_rcu_hurry); > > + synchronize_rcu_mult(call_rcu_tasks, call_rcu); > > } > > > > static struct rcu_torture_ops tasks_ops = { > > @@ -1631,6 +1631,17 @@ static void do_rtws_sync(struct torture_random_state *trsp, void (*sync)(void)) > > cpus_read_unlock(); > > } > > > > +/* > > + * Do an rcu_barrier() to motivate lazy callbacks during a stutter > > + * pause. Without this, we can get false-positives rtort_pipe_count > > + * splats. > > + */ > > +static void rcu_torture_writer_work(struct work_struct *work) > > +{ > > + if (cur_ops->cb_barrier) > > + cur_ops->cb_barrier(); > > +} > > + > > /* > > * RCU torture writer kthread. Repeatedly substitutes a new structure > > * for that pointed to by rcu_torture_current, freeing the old structure > > @@ -1651,6 +1662,7 @@ rcu_torture_writer(void *arg) > > int i; > > int idx; > > unsigned long j; > > + struct work_struct lazy_work; > > int oldnice = task_nice(current); > > struct rcu_gp_oldstate *rgo = NULL; > > int rgo_size = 0; > > @@ -1667,6 +1679,7 @@ rcu_torture_writer(void *arg) > > stallsdone += (stall_cpu_holdoff + stall_gp_kthread + stall_cpu + 60) * > > HZ * (stall_cpu_repeat + 1); > > VERBOSE_TOROUT_STRING("rcu_torture_writer task started"); > > + INIT_WORK_ONSTACK(&lazy_work, rcu_torture_writer_work); > > if (!can_expedite) > > pr_alert("%s" TORTURE_FLAG > > " GP expediting controlled from boot/sysfs for %s.\n", > > @@ -1895,6 +1908,8 @@ rcu_torture_writer(void *arg) > > !rcu_gp_is_normal(); > > } > > rcu_torture_writer_state = RTWS_STUTTER; > > + if (IS_ENABLED(CONFIG_RCU_LAZY)) > > + queue_work(system_percpu_wq, &lazy_work); > > > When the task ends, the lazy_work should be cancel and destroy: > > diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c > index f593f8b794dd..5adf537ab410 100644 > --- a/kernel/rcu/rcutorture.c > +++ b/kernel/rcu/rcutorture.c > @@ -1682,7 +1682,6 @@ rcu_torture_writer(void *arg) > stallsdone += (stall_cpu_holdoff + stall_gp_kthread + stall_cpu + 60) * > HZ * (stall_cpu_repeat + 1); > VERBOSE_TOROUT_STRING("rcu_torture_writer task started"); > - INIT_WORK_ONSTACK(&lazy_work, rcu_torture_writer_work); > if (!can_expedite) > pr_alert("%s" TORTURE_FLAG > " GP expediting controlled from boot/sysfs for %s.\n", > @@ -1719,6 +1718,8 @@ rcu_torture_writer(void *arg) > pr_alert("%s" TORTURE_FLAG " Waited %lu jiffies for boot to complete.\n", > torture_type, jiffies - j); > > + INIT_WORK_ONSTACK(&lazy_work, rcu_torture_writer_work); > + > do { > rcu_torture_writer_state = RTWS_FIXED_DELAY; > torture_hrtimeout_us(500, 1000, &rand); > @@ -1943,6 +1944,9 @@ rcu_torture_writer(void *arg) > pr_alert("%s" TORTURE_FLAG > " Dynamic grace-period expediting was disabled.\n", > torture_type); > + if (IS_ENABLED(CONFIG_RCU_LAZY)) > + cancel_work_sync(&lazy_work); > + destroy_work_on_stack(&lazy_work); > kfree(ulo); > kfree(rgo); > rcu_torture_writer_state = RTWS_STOPPING; > I agree, we seem miss destroying the work via destroy_work_on_stack() and "sync" the lazy_work work via cancel_work_sync(). Paul, any thoughts? -- Uladzislau Rezki