[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a7f41101-d80a-4cee-ada5-9c591321b1d7@sirena.org.uk>
Date: Thu, 2 Oct 2025 12:39:31 +0100
From: Mark Brown <broonie@...nel.org>
To: Byungchul Park <byungchul@...com>
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 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?
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists