linux-kernel - Re: [PATCH v1] net/dev.c : Remove redundant state settings after waking 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: <CAEA6p_AdUL-NgX-C9j0DRNbwnc+nKPnwKRY8dXNCEZ4_pnTOXQ@mail.gmail.com>
Date:   Tue, 10 Jan 2023 16:42:56 -0800
From:   Wei Wang <weiwan@...gle.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        李哲 <sensor1010@....com>, davem@...emloft.net,
        pabeni@...hat.com, bigeasy@...utronix.de, imagedong@...cent.com,
        kuniyu@...zon.com, petrm@...dia.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] net/dev.c : Remove redundant state settings after
 waking up

I was not able to see the entire changelog, but I don't think
> -               set_current_state(TASK_INTERRUPTIBLE);
is redundant.

It makes sure that if the previous if statement:
    if (test_bit(NAPI_STATE_SCHED_THREADED, &napi->state) || woken)
is false, this napi thread yields the CPU to other threads waiting to
be run by calling schedule().

And the napi thread gets into running state again after the next
wake_up_process() is called from ____napi_schedule().


On Tue, Jan 10, 2023 at 4:30 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Tue, 10 Jan 2023 10:29:20 +0100 Eric Dumazet wrote:
> > > the task status has been set to TASK_RUNNING in shcedule(),
> > > no need to set again here
> >
> > Changelog is rather confusing, this does not match the patch, which
> > removes one set_current_state(TASK_INTERRUPTIBLE);
> >
> > TASK_INTERRUPTIBLE != TASK_RUNNING
> >
> > Patch itself looks okay (but has nothing to do with thread state after
> > schedule()),
> > you should have CC Wei Wang because she
> > authored commit cb038357937e net: fix race between napi kthread mode
> > and busy poll
>
> AFAIU this is the semi-idiomatic way of handling wait loops.
> It's not schedule() that may set the task state to TASK_RUNNING,
> it's whoever wakes the process and makes the "wait condition" true.
> In this case - test_bit(NAPI_STATE_SCHED, &napi->state)
>
> I vote to not futz with this logic.