linux-kernel - Re: [PATCH net-next 1/2] connector/cn_proc: Handle threads for proc connector

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <72426AB7-DAF9-4779-A29E-EA5FF8816695@oracle.com>
Date: Fri, 20 Sep 2024 15:42:37 +0000
From: Anjali Kulkarni <anjali.k.kulkarni@...cle.com>
To: Oleg Nesterov <oleg@...hat.com>
CC: "davem@...emloft.net" <davem@...emloft.net>,
        Liam Howlett
	<liam.howlett@...cle.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "axboe@...nel.dk"
	<axboe@...nel.dk>,
        "brauner@...nel.org" <brauner@...nel.org>,
        "mhocko@...e.com" <mhocko@...e.com>,
        "alexjlzheng@...cent.com"
	<alexjlzheng@...cent.com>,
        "willy@...radead.org" <willy@...radead.org>,
        Michael Christie <michael.christie@...cle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "shuah@...nel.org"
	<shuah@...nel.org>,
        "linux-kselftest@...r.kernel.org"
	<linux-kselftest@...r.kernel.org>,
        Pei Li <peili.io@...cle.com>,
        "Eric W.
 Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH net-next 1/2] connector/cn_proc: Handle threads for proc
 connector



> On Sep 20, 2024, at 4:00 AM, Oleg Nesterov <oleg@...hat.com> wrote:
> 
> On 09/19, Anjali Kulkarni wrote:
>> 
>> @@ -413,6 +416,10 @@ static void cn_proc_mcast_ctl(struct cn_msg *msg,
>> 	if (msg->len == sizeof(*pinput)) {
>> 		pinput = (struct proc_input *)msg->data;
>> 		mc_op = pinput->mcast_op;
>> +		if (mc_op == PROC_CN_MCAST_NOTIFY) {
>> +			current->exit_code = pinput->uexit_code;
>> +			return;
> 
> ...
> 
>> --- a/kernel/exit.c
>> +++ b/kernel/exit.c
>> @@ -821,6 +821,7 @@ void __noreturn do_exit(long code)
>> {
>> 	struct task_struct *tsk = current;
>> 	int group_dead;
>> +	__u32 uexit_code;
>> 
>> 	WARN_ON(irqs_disabled());
>> 
>> @@ -863,6 +864,8 @@ void __noreturn do_exit(long code)
>> 		tty_audit_exit();
>> 	audit_free(tsk);
>> 
>> +	uexit_code = tsk->exit_code;
> 
> I don't think you can use task_struct->exit_code. If this task is ptraced,
> it can be changed/cleared in, say, ptrace_stop() after PROC_CN_MCAST_NOTIFY.
> 

Thank you, that’s a good point! However, the use case of ptrace, which I assume is for mostly debug and tracing, is exclusive of the use case I am using it for - for production and mostly scaling scenarios. That is, I assume ptrace calls can be done only to your own processes (except superuser), so the tracing process should understand and only do one(ptrace) or the other (request for a exit notification by using a system call) and not both? I could add a comment or something which describes this somewhere. Another point is - if an exit_code is modified, it will anyways be overwritten in the do_exit() call - so it’s not clear to me what the purpose of writing that field would be for ptrace_stop() or any other function…? Is there any other reason for ptrace_stop() to modify task_struct->exit_code?

Anjali

> Oleg.
>