Message-ID: <20251013015149.GC52546@system.software.com>
Date: Mon, 13 Oct 2025 10:51:49 +0900
From: Byungchul Park <byungchul@...com>
To: Mark Brown <broonie@...nel.org>
Cc: linux-kernel@...r.kernel.org, kernel_team@...ynix.com,
	torvalds@...ux-foundation.org, damien.lemoal@...nsource.wdc.com,
	linux-ide@...r.kernel.org, adilger.kernel@...ger.ca,
	linux-ext4@...r.kernel.org, mingo@...hat.com, peterz@...radead.org,
	will@...nel.org, tglx@...utronix.de, rostedt@...dmis.org,
	joel@...lfernandes.org, sashal@...nel.org, daniel.vetter@...ll.ch,
	duyuyang@...il.com, johannes.berg@...el.com, tj@...nel.org,
	tytso@....edu, willy@...radead.org, david@...morbit.com,
	amir73il@...il.com, gregkh@...uxfoundation.org, kernel-team@....com,
	linux-mm@...ck.org, akpm@...ux-foundation.org, mhocko@...nel.org,
	minchan@...nel.org, hannes@...xchg.org, vdavydov.dev@...il.com,
	sj@...nel.org, jglisse@...hat.com, dennis@...nel.org, cl@...ux.com,
	penberg@...nel.org, rientjes@...gle.com, vbabka@...e.cz,
	ngupta@...are.org, linux-block@...r.kernel.org,
	josef@...icpanda.com, linux-fsdevel@...r.kernel.org, jack@...e.cz,
	jlayton@...nel.org, dan.j.williams@...el.com, hch@...radead.org,
	djwong@...nel.org, dri-devel@...ts.freedesktop.org,
	rodrigosiqueiramelo@...il.com, melissa.srw@...il.com,
	hamohammed.sa@...il.com, harry.yoo@...cle.com,
	chris.p.wilson@...el.com, gwan-gyeong.mun@...el.com,
	max.byungchul.park@...il.com, boqun.feng@...il.com,
	longman@...hat.com, yunseong.kim@...csson.com, ysk@...lloc.com,
	yeoreum.yun@....com, netdev@...r.kernel.org,
	matthew.brost@...el.com, her0gyugyu@...il.com, corbet@....net,
	catalin.marinas@....com, bp@...en8.de, dave.hansen@...ux.intel.com,
	x86@...nel.org, hpa@...or.com, luto@...nel.org,
	sumit.semwal@...aro.org, gustavo@...ovan.org,
	christian.koenig@....com, andi.shyti@...nel.org, arnd@...db.de,
	lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com,
	rppt@...nel.org, surenb@...gle.com, mcgrof@...nel.org,
	petr.pavlu@...e.com, da.gomez@...nel.org, samitolvanen@...gle.com,
	paulmck@...nel.org, frederic@...nel.org, neeraj.upadhyay@...nel.org,
	joelagnelf@...dia.com, josh@...htriplett.org, urezki@...il.com,
	mathieu.desnoyers@...icios.com, jiangshanlai@...il.com,
	qiang.zhang@...ux.dev, juri.lelli@...hat.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	bsegall@...gle.com, mgorman@...e.de, vschneid@...hat.com,
	chuck.lever@...cle.com, neil@...wn.name, okorniev@...hat.com,
	Dai.Ngo@...cle.com, tom@...pey.com, trondmy@...nel.org,
	anna@...nel.org, kees@...nel.org, bigeasy@...utronix.de,
	clrkwllms@...nel.org, mark.rutland@....com, ada.coupriediaz@....com,
	kristina.martsenko@....com, wangkefeng.wang@...wei.com,
	kevin.brodsky@....com, dwmw@...zon.co.uk, shakeel.butt@...ux.dev,
	ast@...nel.org, ziy@...dia.com, yuzhao@...gle.com,
	baolin.wang@...ux.alibaba.com, usamaarif642@...il.com,
	joel.granados@...nel.org, richard.weiyang@...il.com,
	geert+renesas@...der.be, tim.c.chen@...ux.intel.com,
	linux@...blig.org, alexander.shishkin@...ux.intel.com,
	lillian@...r-ark.net, chenhuacai@...nel.org, francesco@...la.it,
	guoweikang.kernel@...il.com, link@...o.com, jpoimboe@...nel.org,
	masahiroy@...nel.org, brauner@...nel.org,
	thomas.weissschuh@...utronix.de, oleg@...hat.com, mjguzik@...il.com,
	andrii@...nel.org, wangfushuai@...du.com, linux-doc@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-media@...r.kernel.org,
	linaro-mm-sig@...ts.linaro.org, linux-i2c@...r.kernel.org,
	linux-arch@...r.kernel.org, linux-modules@...r.kernel.org,
	rcu@...r.kernel.org, linux-nfs@...r.kernel.org,
	linux-rt-devel@...ts.linux.dev
Subject: Re: [PATCH v17 09/47] arm64, dept: add support
 CONFIG_ARCH_HAS_DEPT_SUPPORT to arm64

On Fri, Oct 03, 2025 at 12:33:03PM +0100, Mark Brown wrote:
> On Fri, Oct 03, 2025 at 10:46:41AM +0900, Byungchul Park wrote:
> > On Thu, Oct 02, 2025 at 12:39:31PM +0100, Mark Brown wrote:
> > > On Thu, Oct 02, 2025 at 05:12:09PM +0900, Byungchul Park wrote:
> > > > dept needs to notice every entrance from user to kernel mode to treat
> > > > every kernel context independently when tracking wait-event dependencies.
> > > > Roughly, system call and user oriented fault are the cases.
> 
> > > > Make dept aware of the entrances of arm64 and add support
> > > > CONFIG_ARCH_HAS_DEPT_SUPPORT to arm64.
> 
> > > The description of what needs to be tracked probably needs some
> > > tightening up here, it's not clear to me for example why exceptions for
> > > mops or the vector extensions aren't included here, or what the
> > > distinction is with error faults like BTI or GCS not being tracked?
> 
> > Thanks for the feedback but I'm afraid I don't get you.  Can you explain
> > in more detail with example?
> 
> Your commit log says we need to track every entrance from user mode to
> kernel mode but the code only adds tracking to syscalls and some memory
> faults.  The exception types listed above (and some others) also result
> in entries to the kernel from userspace.

You're right.  Each kernel mode context needs to be tracked
independently.  Just for your information, context ID is used for making
DEPT only track waits and events within each context, preventing
tracking those across independent contexts to avoid false positives.

Currently, irq, fault, and system calls are covered.  It should be taken
into account if any other exceptions can include waits and events anyway.

> > JFYI, pairs of wait and its event need to be tracked to see if each
> > event can be prevented from being reachable by other waits like:
> 
> >    context X				context Y
> > 
> >    lock L
> >    ...
> >    initiate event A context		start toward event A
> >    ...					...
> >    wait A // wait for event A and	lock L // wait for unlock L and
> >           // prevent unlock L		       // prevent event A
> >    ...					...
> >    unlock L				unlock L
> > 					...
> > 					event A
> 
> > I meant things like this need to be tracked.
> 
> I don't think that's at all clear from the above context, and the
> handling for some of the above exception types (eg, the vector
> extensions) includes taking locks.

A trivial thing to mention, each typical lock pair, lock and unlock, can
only happen within each independent context, not across different
contexts.  So the context ID is not necessary for typical locks.

   exception X

   lock A;
   ...
   unlock A; // already guarateed to unlock A in the context that lock A
             // has been acqured in.
   ...
   finish exception X and return back to user mode;

But yes, as you concern, we should take into account all the exceptions
if any can include general waits and events in it, to avoid unnecessary
false positives.

Thank you!

	Byungchul

Powered by blists - more mailing lists