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: <34b5d395531d0e1bee47c87961ccbc1e@imap.linux.ibm.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ