netdev - Re: [PATCH v4 net-next 11/19] ionic: Add Rx filter and rx

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]

Date:   Tue, 23 Jul 2019 17:19:38 -0700
From:   Shannon Nelson <snelson@...sando.io>
To:     Saeed Mahameed <saeedm@...lanox.com>,
        "davem@...emloft.net" <davem@...emloft.net>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v4 net-next 11/19] ionic: Add Rx filter and rx_mode ndo
 support

On 7/23/19 4:54 PM, Saeed Mahameed wrote:
> On Tue, 2019-07-23 at 16:06 -0700, David Miller wrote:
>> From: Shannon Nelson <snelson@...sando.io>
>> Date: Tue, 23 Jul 2019 15:50:43 -0700
>>
>>> On 7/23/19 2:33 PM, David Miller wrote:
>>>> Generally interface address changes are expected to be
>>>> synchronous.
>>> Yeah, this bothers me a bit as well, but the address change calls
>>> come
>>> in under spin_lock_bh(), and I'm reluctant to make an AdminQ call
>>> under the _bh that could block for a few seconds.
>> So it's not about memory allocation but rather the fact that the
>> device
>> might take a while to complete?
>>
>> Can you start the operation synchronously yet complete it async?
> The driver is doing busy polling on command completion, doing only busy
> polling on completion status in the deferred work will not be much
> different than what they have now..
>
> async completion will only make since if the hardware supports
> interrupt based (MSI-x) command completion.

Actually, there are two different command paths - one for basic 
low-level setup, and one for more advanced work:
- dev_cmd does indeed do polling on PCI register space, and we try to 
keep this to a minimum
- adminq does a wait_for_completion_timeout() which gets completed in an 
MSI-x handler

The rx_mode related work goes through adminq.

Yes, it could be made async, but would the extra logic needed buy us 
that much?  We already know this model works in other drivers.  We 
wouldn't get the address into the hardware any quicker, and we still 
wouldn't get any errors from the request back to the original call.

sln