[PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access

[PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access

[nicolas.bouchinet]

From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>

Currently, yama only checks if the `PTRACE_MODE_ATTACH` mode is set
during the `yama_ptrace_access_check()` LSM hook implementation.

In cases of call with the `PTRACE_MODE_READ_FSCREDS` mode, nothing
happens. Thus, yama does not interact properly with the
"hidepid=ptraceable" option.

hidepid's "ptraceable" option being documented as follow :

- hidepid=ptraceable or hidepid=4 means that procfs should only contain
  `/proc/<pid>/` directories that the caller can ptrace.

This patch simply add yama a `PTRACE_MODE_READ_FSCREDS` mode check to
enable an interaction with "hidepid=ptraceable".

Combined with hidepid=ptraceable, the following behaviors will then
happen while reading in `/proc/<pid>`:

- "restricted": A process that has a predefined relationship with the
  inferior will see the inferior process in `/proc`.

- "admin-only": A process that has the CAP_SYS_PTRACE will be able to
  see every processes in `/proc`.

- "no attach": A process will not see anything but itself in
  `/proc/<pid>/`.

It is important to note that the combination of "hidepid=ptraceable" and
yama "no attach" also makes PIDs invisible to root.

No access reports are logged in case of denied access with
`PTRACE_MODE_READ_FSCREDS` to avoid flooding kernel logs.

Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
---
 security/yama/yama_lsm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index 3d064dd4e03f9eaaf5258b37ad05641b35967995..63b589850a88d35dd6a08b23c14ba1a660e6f1b3 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -352,7 +352,7 @@ static int yama_ptrace_access_check(struct task_struct *child,
 	int rc = 0;
 
 	/* require ptrace target be a child of ptracer on attach */
-	if (mode & PTRACE_MODE_ATTACH) {
+	if (mode & (PTRACE_MODE_ATTACH | PTRACE_MODE_READ_FSCREDS)) {
 		switch (ptrace_scope) {
 		case YAMA_SCOPE_DISABLED:
 			/* No additional restrictions. */
@@ -380,7 +380,7 @@ static int yama_ptrace_access_check(struct task_struct *child,
 		}
 	}
 
-	if (rc && (mode & PTRACE_MODE_NOAUDIT) == 0)
+	if (rc && (mode & PTRACE_MODE_NOAUDIT) == 0 && (mode & PTRACE_MODE_ATTACH))
 		report_access("attach", child, current);
 
 	return rc;

---
base-commit: 5d8b97c946777118930e1cfb075cab59a139ca7c
change-id: 20250718-yama_fix-ea5c2c4b2fbe

Best regards,
-- 
Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>

Re: [PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access

[Nicolas Bouchinet]

Note that a hidepid patch has also been sent [1].

[1]: https://lore.kernel.org/all/20250718-hidepid_fix-v1-1-3fd5566980bc@ssi.gouv.fr/

Best regards,

Nicolas

On 7/18/25 10:47, nicolas.bouchinet@oss.cyber.gouv.fr wrote:
> From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
>
> Currently, yama only checks if the `PTRACE_MODE_ATTACH` mode is set
> during the `yama_ptrace_access_check()` LSM hook implementation.
>
> In cases of call with the `PTRACE_MODE_READ_FSCREDS` mode, nothing
> happens. Thus, yama does not interact properly with the
> "hidepid=ptraceable" option.
>
> hidepid's "ptraceable" option being documented as follow :
>
> - hidepid=ptraceable or hidepid=4 means that procfs should only contain
>    `/proc/<pid>/` directories that the caller can ptrace.
>
> This patch simply add yama a `PTRACE_MODE_READ_FSCREDS` mode check to
> enable an interaction with "hidepid=ptraceable".
>
> Combined with hidepid=ptraceable, the following behaviors will then
> happen while reading in `/proc/<pid>`:
>
> - "restricted": A process that has a predefined relationship with the
>    inferior will see the inferior process in `/proc`.
>
> - "admin-only": A process that has the CAP_SYS_PTRACE will be able to
>    see every processes in `/proc`.
>
> - "no attach": A process will not see anything but itself in
>    `/proc/<pid>/`.
>
> It is important to note that the combination of "hidepid=ptraceable" and
> yama "no attach" also makes PIDs invisible to root.
>
> No access reports are logged in case of denied access with
> `PTRACE_MODE_READ_FSCREDS` to avoid flooding kernel logs.
>
> Signed-off-by: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
> ---
>   security/yama/yama_lsm.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
> index 3d064dd4e03f9eaaf5258b37ad05641b35967995..63b589850a88d35dd6a08b23c14ba1a660e6f1b3 100644
> --- a/security/yama/yama_lsm.c
> +++ b/security/yama/yama_lsm.c
> @@ -352,7 +352,7 @@ static int yama_ptrace_access_check(struct task_struct *child,
>   	int rc = 0;
>   
>   	/* require ptrace target be a child of ptracer on attach */
> -	if (mode & PTRACE_MODE_ATTACH) {
> +	if (mode & (PTRACE_MODE_ATTACH | PTRACE_MODE_READ_FSCREDS)) {
>   		switch (ptrace_scope) {
>   		case YAMA_SCOPE_DISABLED:
>   			/* No additional restrictions. */
> @@ -380,7 +380,7 @@ static int yama_ptrace_access_check(struct task_struct *child,
>   		}
>   	}
>   
> -	if (rc && (mode & PTRACE_MODE_NOAUDIT) == 0)
> +	if (rc && (mode & PTRACE_MODE_NOAUDIT) == 0 && (mode & PTRACE_MODE_ATTACH))
>   		report_access("attach", child, current);
>   
>   	return rc;
>
> ---
> base-commit: 5d8b97c946777118930e1cfb075cab59a139ca7c
> change-id: 20250718-yama_fix-ea5c2c4b2fbe
>
> Best regards,

Re: [PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access

[Jann Horn]

On Fri, Jul 18, 2025 at 10:47 AM <nicolas.bouchinet@oss.cyber.gouv.fr> wrote:
> From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
>
> Currently, yama only checks if the `PTRACE_MODE_ATTACH` mode is set
> during the `yama_ptrace_access_check()` LSM hook implementation.
>
> In cases of call with the `PTRACE_MODE_READ_FSCREDS` mode, nothing
> happens. Thus, yama does not interact properly with the
> "hidepid=ptraceable" option.
>
> hidepid's "ptraceable" option being documented as follow :
>
> - hidepid=ptraceable or hidepid=4 means that procfs should only contain
>   `/proc/<pid>/` directories that the caller can ptrace.
>
> This patch simply add yama a `PTRACE_MODE_READ_FSCREDS` mode check to
> enable an interaction with "hidepid=ptraceable".

Please note that PTRACE_MODE_READ_FSCREDS is actually a combination of
two flags, and the intention is that the PTRACE_MODE_REALCREDS /
PTRACE_MODE_FSCREDS part of the flags should basically only be used to
determine where to read the caller's credentials from:

/* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
#define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
#define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
PTRACE_MODE_REALCREDS)

> Combined with hidepid=ptraceable, the following behaviors will then
> happen while reading in `/proc/<pid>`:
>
> - "restricted": A process that has a predefined relationship with the
>   inferior will see the inferior process in `/proc`.
>
> - "admin-only": A process that has the CAP_SYS_PTRACE will be able to
>   see every processes in `/proc`.
>
> - "no attach": A process will not see anything but itself in
>   `/proc/<pid>/`.
>
> It is important to note that the combination of "hidepid=ptraceable" and
> yama "no attach" also makes PIDs invisible to root.
>
> No access reports are logged in case of denied access with
> `PTRACE_MODE_READ_FSCREDS` to avoid flooding kernel logs.

This seems like a major semantic change; I believe it essentially
means that commands like "ps" stop working entirely on systems that
enable hidepid. While that might be desirable in some scenarios, I
think changing the semantics like this without making it opt-in
through a new sysctl knob or such would be a bad idea.

Re: [PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access

[Nicolas Bouchinet]

On Fri, Jul 18, 2025 at 04:52:51PM +0200, Jann Horn wrote:
> On Fri, Jul 18, 2025 at 10:47 AM <nicolas.bouchinet@oss.cyber.gouv.fr> wrote:
> > From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
> >
> > Currently, yama only checks if the `PTRACE_MODE_ATTACH` mode is set
> > during the `yama_ptrace_access_check()` LSM hook implementation.
> >
> > In cases of call with the `PTRACE_MODE_READ_FSCREDS` mode, nothing
> > happens. Thus, yama does not interact properly with the
> > "hidepid=ptraceable" option.
> >
> > hidepid's "ptraceable" option being documented as follow :
> >
> > - hidepid=ptraceable or hidepid=4 means that procfs should only contain
> >   `/proc/<pid>/` directories that the caller can ptrace.
> >
> > This patch simply add yama a `PTRACE_MODE_READ_FSCREDS` mode check to
> > enable an interaction with "hidepid=ptraceable".
> 
> Please note that PTRACE_MODE_READ_FSCREDS is actually a combination of
> two flags, and the intention is that the PTRACE_MODE_REALCREDS /
> PTRACE_MODE_FSCREDS part of the flags should basically only be used to
> determine where to read the caller's credentials from:
> 
> /* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
> #define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
> #define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
> #define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
> #define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
> PTRACE_MODE_REALCREDS)
> 

Yes my bad, I should have sent the hidepid [1] patch in the same batch.
The idea here is to take "hidepid=ptraceable" into account. Which
already calls yama with `PTRACE_MODE_READ_FSCREDS`.

> > Combined with hidepid=ptraceable, the following behaviors will then
> > happen while reading in `/proc/<pid>`:
> >
> > - "restricted": A process that has a predefined relationship with the
> >   inferior will see the inferior process in `/proc`.
> >
> > - "admin-only": A process that has the CAP_SYS_PTRACE will be able to
> >   see every processes in `/proc`.
> >
> > - "no attach": A process will not see anything but itself in
> >   `/proc/<pid>/`.
> >
> > It is important to note that the combination of "hidepid=ptraceable" and
> > yama "no attach" also makes PIDs invisible to root.
> >
> > No access reports are logged in case of denied access with
> > `PTRACE_MODE_READ_FSCREDS` to avoid flooding kernel logs.
> 
> This seems like a major semantic change; I believe it essentially
> means that commands like "ps" stop working entirely on systems that
> enable hidepid. While that might be desirable in some scenarios, I
> think changing the semantics like this without making it opt-in
> through a new sysctl knob or such would be a bad idea.

Yes, this patch doesn't work alone it needs to be coupled with

[1]: https://lore.kernel.org/all/20250718-hidepid_fix-v1-1-3fd5566980bc@ssi.gouv.fr/.

Re: [PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access

[Jann Horn]

On Fri, Jul 18, 2025 at 5:55 PM Nicolas Bouchinet
<nicolas.bouchinet@oss.cyber.gouv.fr> wrote:
> On Fri, Jul 18, 2025 at 04:52:51PM +0200, Jann Horn wrote:
> > On Fri, Jul 18, 2025 at 10:47 AM <nicolas.bouchinet@oss.cyber.gouv.fr> wrote:
> > > From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
> > >
> > > Currently, yama only checks if the `PTRACE_MODE_ATTACH` mode is set
> > > during the `yama_ptrace_access_check()` LSM hook implementation.
> > >
> > > In cases of call with the `PTRACE_MODE_READ_FSCREDS` mode, nothing
> > > happens. Thus, yama does not interact properly with the
> > > "hidepid=ptraceable" option.
> > >
> > > hidepid's "ptraceable" option being documented as follow :
> > >
> > > - hidepid=ptraceable or hidepid=4 means that procfs should only contain
> > >   `/proc/<pid>/` directories that the caller can ptrace.
> > >
> > > This patch simply add yama a `PTRACE_MODE_READ_FSCREDS` mode check to
> > > enable an interaction with "hidepid=ptraceable".
> >
> > Please note that PTRACE_MODE_READ_FSCREDS is actually a combination of
> > two flags, and the intention is that the PTRACE_MODE_REALCREDS /
> > PTRACE_MODE_FSCREDS part of the flags should basically only be used to
> > determine where to read the caller's credentials from:
> >
> > /* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
> > #define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
> > #define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
> > #define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
> > #define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
> > PTRACE_MODE_REALCREDS)
> >
>
> Yes my bad, I should have sent the hidepid [1] patch in the same batch.
> The idea here is to take "hidepid=ptraceable" into account. Which
> already calls yama with `PTRACE_MODE_READ_FSCREDS`.

To be clearer: "if (mode & (PTRACE_MODE_ATTACH |
PTRACE_MODE_READ_FSCREDS))" does not make sense, because it expands to
"if (mode & (PTRACE_MODE_ATTACH | PTRACE_MODE_READ |
PTRACE_MODE_FSCREDS))", which is always true.

Re: [PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access

[Nicolas Bouchinet]

On Fri, Jul 18, 2025 at 04:52:51PM +0200, Jann Horn wrote:
> On Fri, Jul 18, 2025 at 10:47 AM <nicolas.bouchinet@oss.cyber.gouv.fr> wrote:
> > From: Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr>
> >
> > Currently, yama only checks if the `PTRACE_MODE_ATTACH` mode is set
> > during the `yama_ptrace_access_check()` LSM hook implementation.
> >
> > In cases of call with the `PTRACE_MODE_READ_FSCREDS` mode, nothing
> > happens. Thus, yama does not interact properly with the
> > "hidepid=ptraceable" option.
> >
> > hidepid's "ptraceable" option being documented as follow :
> >
> > - hidepid=ptraceable or hidepid=4 means that procfs should only contain
> >   `/proc/<pid>/` directories that the caller can ptrace.
> >
> > This patch simply add yama a `PTRACE_MODE_READ_FSCREDS` mode check to
> > enable an interaction with "hidepid=ptraceable".
> 
> Please note that PTRACE_MODE_READ_FSCREDS is actually a combination of
> two flags, and the intention is that the PTRACE_MODE_REALCREDS /
> PTRACE_MODE_FSCREDS part of the flags should basically only be used to
> determine where to read the caller's credentials from:
> 
> /* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
> #define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
> #define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
> #define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
> #define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
> PTRACE_MODE_REALCREDS)
> 
> > Combined with hidepid=ptraceable, the following behaviors will then
> > happen while reading in `/proc/<pid>`:
> >
> > - "restricted": A process that has a predefined relationship with the
> >   inferior will see the inferior process in `/proc`.
> >
> > - "admin-only": A process that has the CAP_SYS_PTRACE will be able to
> >   see every processes in `/proc`.
> >
> > - "no attach": A process will not see anything but itself in
> >   `/proc/<pid>/`.
> >
> > It is important to note that the combination of "hidepid=ptraceable" and
> > yama "no attach" also makes PIDs invisible to root.
> >
> > No access reports are logged in case of denied access with
> > `PTRACE_MODE_READ_FSCREDS` to avoid flooding kernel logs.
> 
> This seems like a major semantic change; I believe it essentially
> means that commands like "ps" stop working entirely on systems that
> enable hidepid. While that might be desirable in some scenarios, I
> think changing the semantics like this without making it opt-in
> through a new sysctl knob or such would be a bad idea.

I agree with you, it is a bit to harsh, I'll add a new orthogonal sysctl
knob that enables this yama behavior. Will send a V2 with it.

Thanks,

Nicolas

Re: [PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access

[kernel test robot]

Hello,

kernel test robot noticed "ltp.migrate_pages02.fail" on:

commit: 0d6496041d407998103595db3dc42240f124a7f1 ("[PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access")
url: https://github.com/intel-lab-lkp/linux/commits/nicolas-bouchinet-oss-cyber-gouv-fr/lsm-yama-Check-for-PTRACE_MODE_READ_FSCREDS-access/20250718-164849
patch link: https://lore.kernel.org/all/20250718-yama_fix-v1-1-a51455359e67@ssi.gouv.fr/
patch subject: [PATCH] lsm: yama: Check for PTRACE_MODE_READ_FSCREDS access

in testcase: ltp
version: ltp-x86_64-0e4be9201-1_20250726
with following parameters:

	test: numa/migrate_pages02



config: x86_64-rhel-9.4-ltp
compiler: gcc-12
test machine: 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids) with 256G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)




If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202507310843.52fb528f-lkp@intel.com



Running tests.......
<<<test_start>>>
tag=migrate_pages02 stime=1753707486
cmdline="migrate_pages02"
contacts=""
analysis=exit
<<<test_output>>>
tst_tmpdir.c:316: TINFO: Using /tmp/ltp-5PDNJlpHwH/LTP_mig4NxxK0 as tmpdir (tmpfs filesystem)
tst_test.c:2004: TINFO: LTP version: 20250530-108-g0e4be9201
tst_test.c:2007: TINFO: Tested kernel: 6.16.0-rc2-00013-g0d6496041d40 #1 SMP PREEMPT_DYNAMIC Mon Jul 28 20:46:21 CST 2025 x86_64
tst_kconfig.c:88: TINFO: Parsing kernel config '/proc/config.gz'
tst_kconfig.c:676: TINFO: CONFIG_KASAN kernel option detected which might slow the execution
tst_test.c:1825: TINFO: Overall timeout per run is 0h 02m 00s
migrate_pages02.c:313: TINFO: Using nodes: 0 1
migrate_pages02.c:143: TINFO: current_process, cap_sys_nice: 1
migrate_pages02.c:147: TINFO: private anonymous: 0x7f1006150000
migrate_pages02.c:75: TINFO: pid(6801) migrate pid 0 to node -> 1
migrate_pages02.c:96: TINFO: migrate_pages could not migrate all pages, not migrated: 452
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 1
migrate_pages02.c:75: TINFO: pid(6801) migrate pid 0 to node -> 0
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 0
migrate_pages02.c:159: TINFO: shared anonymous: 0x7f1006150000
migrate_pages02.c:75: TINFO: pid(6801) migrate pid 0 to node -> 1
migrate_pages02.c:96: TINFO: migrate_pages could not migrate all pages, not migrated: 452
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 1
migrate_pages02.c:167: TINFO: child shared anonymous, cap_sys_nice: 1
migrate_pages02.c:75: TINFO: pid(6803) migrate pid 0 to node -> 0
migrate_pages02.c:125: TPASS: pid(6803) addr 0x7f100614f000 is on expected node: 0
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 0
migrate_pages02.c:143: TINFO: current_process, cap_sys_nice: 0
migrate_pages02.c:147: TINFO: private anonymous: 0x7f1006150000
migrate_pages02.c:75: TINFO: pid(6801) migrate pid 0 to node -> 1
migrate_pages02.c:96: TINFO: migrate_pages could not migrate all pages, not migrated: 452
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 1
migrate_pages02.c:75: TINFO: pid(6801) migrate pid 0 to node -> 0
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 0
migrate_pages02.c:159: TINFO: shared anonymous: 0x7f1006150000
migrate_pages02.c:75: TINFO: pid(6801) migrate pid 0 to node -> 1
migrate_pages02.c:96: TINFO: migrate_pages could not migrate all pages, not migrated: 452
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 1
migrate_pages02.c:167: TINFO: child shared anonymous, cap_sys_nice: 0
migrate_pages02.c:75: TINFO: pid(6804) migrate pid 0 to node -> 0
migrate_pages02.c:125: TPASS: pid(6804) addr 0x7f100614f000 is on expected node: 0
migrate_pages02.c:125: TPASS: pid(6801) addr 0x7f1006150000 is on expected node: 1
migrate_pages02.c:200: TINFO: other_process, cap_sys_nice: 1
migrate_pages02.c:75: TINFO: pid(6805) migrate pid 0 to node -> 0
migrate_pages02.c:125: TPASS: pid(6805) addr 0x7f1006150000 is on expected node: 0
migrate_pages02.c:75: TINFO: pid(6806) migrate pid 6805 to node -> 1
migrate_pages02.c:96: TINFO: migrate_pages could not migrate all pages, not migrated: 362
migrate_pages02.c:125: TPASS: pid(6805) addr 0x7f1006150000 is on expected node: 1
migrate_pages02.c:200: TINFO: other_process, cap_sys_nice: 0
migrate_pages02.c:75: TINFO: pid(6807) migrate pid 0 to node -> 0
migrate_pages02.c:125: TPASS: pid(6807) addr 0x7f1006150000 is on expected node: 0
migrate_pages02.c:75: TINFO: pid(6808) migrate pid 6807 to node -> 1
migrate_pages02.c:92: TFAIL: migrate_pages failed ret: -1, : EPERM (1)
migrate_pages02.c:55: TINFO: mem_stats pid: 6807, node: 1
Name:	migrate_pages02
Umask:	0000
State:	S (sleeping)
Tgid:	6807
Ngid:	0
Pid:	6807
PPid:	6801
TracerPid:	0
Uid:	65534	65534	65534	65534
Gid:	0	0	0	0
FDSize:	64
Groups:	 
NStgid:	6807
NSpid:	6807
NSpgid:	6801
NSsid:	2420
Kthread:	0
VmPeak:	    2868 kB
VmSize:	    2868 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	       0 kB
VmRSS:	       0 kB
RssAnon:	       0 kB
RssFile:	       0 kB
RssShmem:	       0 kB
VmData:	     348 kB
VmStk:	     136 kB
VmExe:	     132 kB
VmLib:	    1548 kB
VmPTE:	      48 kB
VmSwap:	       0 kB
HugetlbPages:	       0 kB
CoreDumping:	0
THP_enabled:	1
untag_mask:	0xffffffffffffffff
Threads:	1
SigQ:	0/444866
SigPnd:	0000000000000000
ShdPnd:	0000000000000000
SigBlk:	0000000000000000
SigIgn:	0000000000000004
SigCgt:	0000000000000000
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	000001ffffffffff
CapAmb:	0000000000000000
NoNewPrivs:	0
Seccomp:	0
Seccomp_filters:	0
Speculation_Store_Bypass:	thread vulnerable
SpeculationIndirectBranch:	conditional enabled
Cpus_allowed:	ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff
Cpus_allowed_list:	0-223
Mems_allowed:	00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003
Mems_allowed_list:	0-1
voluntary_ctxt_switches:	5
nonvoluntary_ctxt_switches:	0
cat: /proc/6807/numa_maps: Permission denied
migrate_pages02.c:65: TINFO: Node id: 1, size: 117471789056, free: 106811031552
migrate_pages02.c:129: TFAIL: pid(6807) addr 0x7f1006150000 not on expected node: 0 , expected 1
migrate_pages02.c:55: TINFO: mem_stats pid: 6807, node: 1
Name:	migrate_pages02
Umask:	0000
State:	S (sleeping)
Tgid:	6807
Ngid:	0
Pid:	6807
PPid:	6801
TracerPid:	0
Uid:	65534	65534	65534	65534
Gid:	0	0	0	0
FDSize:	64
Groups:	 
NStgid:	6807
NSpid:	6807
NSpgid:	6801
NSsid:	2420
Kthread:	0
VmPeak:	    2904 kB
VmSize:	    2868 kB
VmLck:	       0 kB
VmPin:	       0 kB
VmHWM:	       0 kB
VmRSS:	       0 kB
RssAnon:	       0 kB
RssFile:	       0 kB
RssShmem:	       0 kB
VmData:	     348 kB
VmStk:	     136 kB
VmExe:	     132 kB
VmLib:	    1548 kB
VmPTE:	      48 kB
VmSwap:	       0 kB
HugetlbPages:	       0 kB
CoreDumping:	0
THP_enabled:	1
untag_mask:	0xffffffffffffffff
Threads:	1
SigQ:	0/444866
SigPnd:	0000000000000000
ShdPnd:	0000000000000000
SigBlk:	0000000000010000
SigIgn:	0000000000000006
SigCgt:	0000000000000000
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	000001ffffffffff
CapAmb:	0000000000000000
NoNewPrivs:	0
Seccomp:	0
Seccomp_filters:	0
Speculation_Store_Bypass:	thread vulnerable
SpeculationIndirectBranch:	conditional enabled
Cpus_allowed:	ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff
Cpus_allowed_list:	0-223
Mems_allowed:	00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003
Mems_allowed_list:	0-1
voluntary_ctxt_switches:	7
nonvoluntary_ctxt_switches:	0
cat: /proc/6807/numa_maps: Permission denied
migrate_pages02.c:65: TINFO: Node id: 1, size: 117471789056, free: 106811031552

Summary:
passed   13
failed   2
broken   0
skipped  0
warnings 0
incrementing stop
<<<execution_status>>>
initiation_status="ok"
duration=0 termination_type=exited termination_id=1 corefile=no
cutime=0 cstime=11
<<<test_end>>>
INFO: ltp-pan reported some tests FAIL
LTP Version: 20250530-108-g0e4be9201

       ###############################################################

            Done executing testcases.
            LTP Version:  20250530-108-g0e4be9201
       ###############################################################




The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20250731/202507310843.52fb528f-lkp@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki