netdev - Re: [PATCH] net/core: remove explicit do_softirq() from busy_poll

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: <CANn89iJx0-z2KZWMRZdqmYUNAWcqQo4nBbRwK7pLz2-WAymqrQ@mail.gmail.com>
Date:   Mon, 22 May 2017 14:26:44 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     netdev <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] net/core: remove explicit do_softirq() from busy_poll_stop()

On Mon, May 22, 2017 at 12:26 PM, Sebastian Andrzej Siewior
<bigeasy@...utronix.de> wrote:
> Since commit 217f69743681 ("net: busy-poll: allow preemption in
> sk_busy_loop()") there is an explicit do_softirq() invocation after
> local_bh_enable() has been invoked.
> I don't understand why we need this because local_bh_enable() will
> invoke do_softirq() once the softirq counter reached zero and we have
> softirq-related work pending.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> ---
>  net/core/dev.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index fca407b4a6ea..e84eb0ec5529 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5199,8 +5199,6 @@ static void busy_poll_stop(struct napi_struct *napi, void *have_poll_lock)
>         if (rc == BUSY_POLL_BUDGET)
>                 __napi_schedule(napi);
>         local_bh_enable();
> -       if (local_softirq_pending())
> -               do_softirq();
>  }

preemption is disabled.

Look at netif_rx_ni() for a similar construct.

What exact problem do you have with existing code, that is worth
adding this change ?

Thanks.