netdev - Re: Why do we need tasklet in IFB?

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-next>] [day] [month] [year] [list]

Date:   Mon, 31 Oct 2016 11:02:28 -0700
From:   Michael Ma <make0818@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Why do we need tasklet in IFB?

2016-10-28 14:52 GMT-07:00 Michael Ma <make0818@...il.com>:
> 2016-10-28 14:48 GMT-07:00 Stephen Hemminger <stephen@...workplumber.org>:
>> On Fri, 28 Oct 2016 14:45:07 -0700
>> Michael Ma <make0818@...il.com> wrote:
>>
>>> 2016-10-28 14:38 GMT-07:00 Stephen Hemminger <stephen@...workplumber.org>:
>>> > On Fri, 28 Oct 2016 14:36:27 -0700
>>> > Michael Ma <make0818@...il.com> wrote:
>>> >
>>> >> Hi -
>>> >>
>>> >> Currently IFB uses tasklet to process tx/rx on the interface that
>>> >> forwarded the packet to IFB. My understanding on why we're doing this
>>> >> is that since dev_queue_xmit() can be invoked in interrupt, we want to
>>> >> defer the processing of original tx/rx in case ifb_xmit() is called
>>> >> from interrupt.
>>> >
>>> > dev_queue_xmit is only called from interrupt if doing netconsole.
>>>

In fact this doesn't seem to explain since if the original path is tx
and the context is interrupt, IFB will call dev_queue_xmit as well so
the context can be interrupt in that case.

Then tasklet is still unnecessary.

>>> OK - so the reason is that netif_receive_skb() can only be invoked
>>> from softirq and we have to use tasklet in IFB to guarantee this.
>>>
>>> Then if the original path is rx, tasklet is unnecessary because
>>> ifb_xmit() is invoked from netif_receive_skb() which is always in the
>>> softirq context, right?
>>
>> The other reason is to avoid deep kernel callstacks