netdev - Re: [PATCH][RT] netpoll: Always take 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: <1465576133.7945.65.camel@edumazet-glaptop3.roam.corp.google.com>
Date:	Fri, 10 Jun 2016 09:28:53 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-rt-users <linux-rt-users@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Clark Williams <williams@...hat.com>,
	David Miller <davem@...emloft.net>, alison@...oton-tech.com
Subject: Re: [PATCH][RT] netpoll: Always take poll_lock when doing polling

On Fri, 2016-06-10 at 17:30 +0200, Sebastian Andrzej Siewior wrote:
> * Steven Rostedt | 2016-05-26 19:56:41 [-0400]:
> 
> >For example:
> >
> >   <interrupt thread (as all interrupts on RT are threaded>
> >
> >   napi_schedule_prep()
> >        test_and_set_bit(NAPI_STATE_SCHED, &n->state)
> >
> >   <preempted by higher prio task that runs softirqs in its context>
> >
> >   sk_busy_loop()
> >
> >      do {
> >           rc = busy_poll()
> >               ret = napi_schedule_prep()
> >                    return !test_and_set_bit(NAPI_STATE_SCHED, &n->state)
> >                     <returns zero because NAPI_STATE_SCHED is set>
> >               if (!ret) return 0
> >           <rc is zero>
> >      } while (...) /* for ever */
> >
> 
> No, I don't see the busyloop. while() is here:
> |    while (!nonblock && skb_queue_empty(&sk->sk_receive_queue) &&
> |                  !need_resched() && !busy_loop_timeout(end_time));
> 
> and this seems to be the case since v3.11 where it was introduced (but
> now it moved to dev.c). So even if there is no busy_poll() and
> napi_schedule_prep() returns 0 our cycles here are limited by
> busy_loop_timeout().

Well, before linux-4.5 and commit 2a028ecb76497d ("net: allow BH
servicing in sk_busy_loop()") , sk_busy_loop() was completely blocking
BH.

Not sure it matters in your case.