linux-kernel - Re:Re: [PATCH] futex: use wake_up_process() instead of wake_up

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <ADIA4QBfDph6an7WJnsk3KrC.3.1616145348005.Hmail.wangqing@vivo.com>
Date:   Fri, 19 Mar 2021 17:15:48 +0800 (GMT+08:00)
From:   王擎 <wangqing@...o.com>
To:     Mike Galbraith <efault@....de>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Darren Hart <dvhart@...radead.org>,
        linux-kernel@...r.kernel.org
Subject: Re:Re: [PATCH] futex: use wake_up_process() instead of wake_up_state()


>> On Fri, 2021-03-19 at 10:59 +0800, Wang Qing wrote:
>> > Using wake_up_process() is more simpler and friendly,
>> > and it is more convenient for analysis and statistics
>>
>> I likely needn't bother, and don't have a NAK to paste on this thing,
>> but here's another copy of my NOPE for yet another gratuitous change
>> with complete BS justification.
>
>Let me try a bit softer tone.  I think you're trying to help, but
>ignoring feedback is not the way to achieve that goal.  My feedback was
>and remains that your change is not an improvement, it's churn, but
>more importantly, that changes require technical justification, which
>you did not provide.  You were subsequently handed the justification
>you lacked by none other than the maintainer of the code you were
>modifying.  He told you that your change could become a tiny kernel
>size optimization by converting like instances all in one patch.. which
>you promptly ignored, instead submitting multiple patches with zero
>justification.  That is not the path to success.

Thank you for your reply. There are two reasons for sending patch again. 
One is that I think this is only an improvement in format and has no 
substantial impact, so no verification is required. 
The second one is that I want to hear more opinions from the maintainer. 
Because the entire kernel may have similar problems, I have to figure out 
whether this is a tacit behavior.
Also, I don't understand what you mean by "your change could become a 
tiny kernel size optimization by converting like instances all in one patch".

Thanks,
WangQing.

>
>>
>> >
>> > Signed-off-by: Wang Qing <wangqing@...o.com>
>> > ---
>> >  kernel/futex.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/kernel/futex.c b/kernel/futex.c
>> > index e68db77..078a1f9
>> > --- a/kernel/futex.c
>> > +++ b/kernel/futex.c
>> > @@ -1820,7 +1820,7 @@ void requeue_pi_wake_futex(struct futex_q *q, union futex_key *key,
>> >
>> >  	q->lock_ptr = &hb->lock;
>> >
>> > -	wake_up_state(q->task, TASK_NORMAL);
>> > +	wake_up_process(q->task);
>> >  }
>> >
>> >  /**
>>
>