netdev - Re: [PATCH net-next 1/2] net: add a napi variant for RT-well-behaved drivers

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: <20210515133844.21f08a5e@kicinski-fedora-PC1C0HJN>
Date:   Sat, 15 May 2021 13:38:44 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        eric.dumazet@...il.com, simon.horman@...ronome.com,
        oss-drivers@...ronome.com, bigeasy@...utronix.de
Subject: Re: [PATCH net-next 1/2] net: add a napi variant for
 RT-well-behaved drivers

On Sat, 15 May 2021 11:49:02 +0200 Thomas Gleixner wrote:
> On Fri, May 14 2021 at 15:24, Jakub Kicinski wrote:
> >  /**
> > - *	napi_schedule_irqoff - schedule NAPI poll
> > - *	@n: NAPI context
> > + * napi_schedule_irq() - schedule NAPI poll from hardware IRQ
> > + * @n: NAPI context
> >   *
> >   * Variant of napi_schedule(), assuming hard irqs are masked.
> > + * Hardware interrupt handler must be marked with IRQF_NO_THREAD
> > + * to safely invoke this function on CONFIG_RT=y kernels (unless
> > + * it manually masks the interrupts already).
> >   */
> > -static inline void napi_schedule_irqoff(struct napi_struct *n)
> > +static inline void napi_schedule_irq(struct napi_struct *n)
> >  {
> >  	if (napi_schedule_prep(n))
> > -		__napi_schedule_irqoff(n);
> > +		__napi_schedule_irq(n);  
> 
> As this is intended for the trivial
> 
>    irqhandler()
>         napi_schedule_irq(n);
>         return IRQ_HANDLED;
> 
> case, wouldn't it make sense to bring napi_schedule_irq() out of line
> and have the prep invocation right there?
> 
> void napi_schedule_irq(struct napi_struct *n)
> {
>  	if (napi_schedule_prep(n))
> 		____napi_schedule(this_cpu_ptr(&softnet_data), n);
> }
> EXPORT_SYMBOL(napi_schedule_irq);
> 
> As that spares a function call and lets the compiler be smarter about
> it. I might be missing something though, but at least brain is more
> awake now :)

I'm just copying the existing two handlers (reviewer's favorite
response, I know) :)

My guess is .._prep() used to be a static inline itself, I can look 
at modifying all helpers if the assembly really looks better, but based
on Sebastian's email I'm not sure we're gonna go ahead with the new 
helper at all?