Received-SPF: pass (google.com: domain of linux-kernel+bounces-77779-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <tencent_3867DFAA296AACA094C9E8F413E6493FF407@qq.com>
Date: Fri, 23 Feb 2024 13:16:04 +0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH 2/2] kernel/signal.c: explicitly initialize si_code and
 use ksig->info uniformly
Content-Language: en-US
To: Oleg Nesterov <oleg@redhat.com>
Cc: Christian Brauner <brauner@kernel.org>,
 Andrew Morton <akpm@linux-foundation.org>,
 Thomas Gleixner <tglx@linutronix.de>,
 Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
 Luis Chamberlain <mcgrof@kernel.org>,
 Mike Christie <michael.christie@oracle.com>,
 Dmitry Vyukov <dvyukov@google.com>,
 Vincent Whitchurch <vincent.whitchurch@axis.com>,
 Ard Biesheuvel <ardb@kernel.org>, linux-kernel@vger.kernel.org
References: <tencent_195B55A5521705954D5EA4873327F8E53D0A@qq.com>
 <20240222190546.GA5993@redhat.com>
From: Wen Yang <wenyang.linux@foxmail.com>
In-Reply-To: <20240222190546.GA5993@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 2024/2/23 03:05, Oleg Nesterov wrote:
> On 02/23, wenyang.linux@foxmail.com wrote:
>>
>> From: Wen Yang <wenyang.linux@foxmail.com>
>>
>> By explicitly initializing ksig->info.si_code and uniformly using ksig->info,
>> get_signal() function could be slightly optimized, as folowes:
> 
> I don't understand. Why do you think it will be optimized? in what sense?
> 
>> 	clear_siginfo(&ksig->info);
>> 	ksig->info.si_signo = signr = SIGKILL;          --> missed si_code
> 
> because we do not need to set .si_code in this case?
> 
>> 	sigdelset(&current->pending.signal, SIGKILL);
>> 	trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO,  --> unnecessary SEND_SIG_NOINFO
> 
> Why do you think the usage of SEND_SIG_NOINFO is "unnecessary" or bad?
> To me this looks good.
> 

Since it is called "SEND_SIG_NOINFO", but here it is neither SEND_SIG
nor NOINFO.
It is get_signal() here, and ksig->info has also been partially
initialized before calling trace_signal_deliver(). Below "goto fatal", 
do_coredump() also use the initialized ksig->info.


>> @@ -2732,8 +2732,9 @@ bool get_signal(struct ksignal *ksig)
>>   		     signal->group_exec_task) {
>>   			clear_siginfo(&ksig->info);
>>   			ksig->info.si_signo = signr = SIGKILL;
>> +			ksig->info.si_code = SI_USER;
>>   			sigdelset(&current->pending.signal, SIGKILL);
>> -			trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO,
>> +			trace_signal_deliver(SIGKILL, &ksig->info,
> 
> Well. to me this look like the minor but unnecessary pessimization.
> 
> AFAICS, we do not need to initialize .si_code. The usage if ksig->info
> instead of  means that TP_STORE_SIGINFO() will actually read
> the memory.
> 
> Sorry, I don't understand the point at all :/
> 
> and it seems that we can simply kill clear_siginfo(), but this is
> another story.
> 


This is not right.

ksig->info will be passed to user space through do_coredump(), and the 
clear_siginfo() cannot be killed.


bool get_signal(struct ksignal *ksig)
{
..
                 if ((signal->flags & SIGNAL_GROUP_EXIT) ||
                      signal->group_exec_task) {
                         clear_siginfo(&ksig->info);
                         ksig->info.si_signo = signr = SIGKILL;
..
                         goto fatal;
                 }

         fatal:
..
                         do_coredump(&ksig->info);
                 }


void do_coredump(const kernel_siginfo_t *siginfo)
{
..
         struct coredump_params cprm = {
                 .siginfo = siginfo,
..
         };

..
        sub_info = call_usermodehelper_setup(..., &cprm);
..
        call_usermodehelper_exec(sub_info,...);


> Oleg.
>