netdev - Re: [PATCH net 2/7] Revert "ibmvnic: remove duplicate napi

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:   Thu, 24 Jun 2021 11:18:56 -0700
From:   Dany Madden <drt@...ux.ibm.com>
To:     Lijun Pan <lijunp213@...il.com>
Cc:     Rick Lindsley <ricklind@...ux.vnet.ibm.com>,
        Johaan Smith <johaansmith74@...il.com>,
        Sukadev Bhattiprolu <sukadev@...ux.ibm.com>,
        Networking <netdev@...r.kernel.org>,
        Rick Lindsley <ricklind@...ux.ibm.com>,
        Brian King <brking@...ux.ibm.com>,
        Cristobal Forno <cforno12@...ux.ibm.com>,
        Abdul Haleem <abdhalee@...ibm.com>
Subject: Re: [PATCH net 2/7] Revert "ibmvnic: remove duplicate napi_schedule
 call in open function"

On 2021-06-24 10:05, Lijun Pan wrote:
> On Thu, Jun 24, 2021 at 2:29 AM Rick Lindsley
> <ricklind@...ux.vnet.ibm.com> wrote:
>> 
>> On 6/24/21 12:02 AM, Johaan Smith wrote:
>> > On Wed, Jun 23, 2021 at 11:17 PM Sukadev Bhattiprolu
>> 
>> > Sometimes git bisect may lead us to the false positives. Full investigation is
>> > always the best solution if it is not too hard.
>> 
>> I'd be happy to view evidence that points at another patch, if someone 
>> has some.
>> But the original patch did not address any observed problem:
>> 
>>       "So there is no need for do_reset to call napi_schedule again
>>        at the end of the function though napi_schedule will neglect
>>        the request if napi is already scheduled."
>> 
>> Given that it fixed no problem but appears to have introduced one, the 
>> efficient
>> action is to revert it for now.
>> 
> 
> With this reverted patch, there are lots of errors after bringing
> device down then up, e.g.,
> "ibmvnic 30000003 env3: rx buffer returned with rc 6".
> That seems something wrong with the handling of set_link_state
> DOWN/UP. It is either the communication protocol or the VIOS itself.

Did the driver bring the link back up with the patch is reverted? When 
link is down, vnic server returns rx buffers back to the client. This 
error message is printed when debug is turned on, driver's way to log 
what happened.