Message-ID: <cd056d80-aadd-4f8a-8aad-c34b55686fac@intel.com>
Date: Thu, 2 Oct 2025 08:22:29 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Byungchul Park <byungchul@...com>, linux-kernel@...r.kernel.org
Cc: 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, broonie@...nel.org,
 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 08/47] x86_64, dept: add support
 CONFIG_ARCH_HAS_DEPT_SUPPORT to x86_64

On 10/2/25 01:12, 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.

"Roughly"?

>  #define __SYSCALL(nr, sym) extern long __x64_##sym(const struct pt_regs *);
>  #define __SYSCALL_NORETURN(nr, sym) extern long __noreturn __x64_##sym(const struct pt_regs *);
> @@ -86,6 +87,12 @@ static __always_inline bool do_syscall_x32(struct pt_regs *regs, int nr)
>  /* Returns true to return using SYSRET, or false to use IRET */
>  __visible noinstr bool do_syscall_64(struct pt_regs *regs, int nr)
>  {
> +	/*
> +	 * This is a system call from user mode.  Make dept work with a
> +	 * new kernel mode context.
> +	 */
> +	dept_update_cxt();
> +
>  	add_random_kstack_offset();
>  	nr = syscall_enter_from_user_mode(regs, nr);

Please take a look in syscall_enter_from_user_mode(). You'll see the
quite nicely-named function: enter_from_user_mode(). That might be a
nice place to put code that you want to run when the kernel is entered
from user mode.

> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 998bd807fc7b..017edb75f0a0 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -19,6 +19,7 @@
>  #include <linux/mm_types.h>
>  #include <linux/mm.h>			/* find_and_lock_vma() */
>  #include <linux/vmalloc.h>
> +#include <linux/dept.h>
>  
>  #include <asm/cpufeature.h>		/* boot_cpu_has, ...		*/
>  #include <asm/traps.h>			/* dotraplinkage, ...		*/
> @@ -1219,6 +1220,12 @@ void do_user_addr_fault(struct pt_regs *regs,
>  	tsk = current;
>  	mm = tsk->mm;
>  
> +	/*
> +	 * This fault comes from user mode.  Make dept work with a new
> +	 * kernel mode context.
> +	 */
> +	dept_update_cxt();
No, this fault does not come from user mode. That's why we call it "user
addr" fault, not "user mode" fault. You end up here if, for instance,
the kernel faults doing a copy_from_user().

Powered by blists - more mailing lists