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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 1 Sep 2011 11:37:15 +0200
From:	Michał Mirosław <mirqus@...il.com>
To:	Vladislav Zolotarov <vladz@...adcom.com>
Cc:	Michal Schmidt <mschmidt@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Dmitry Kravkov <dmitry@...adcom.com>,
	Eilon Greenstein <eilong@...adcom.com>
Subject: Re: [PATCH 1/3] bnx2x: remove TPA_ENABLE_FLAG

W dniu 1 września 2011 10:37 użytkownik Vladislav Zolotarov
<vladz@...adcom.com> napisał:
>> -----Original Message-----
>> From: netdev-owner@...r.kernel.org [mailto:netdev-
>> owner@...r.kernel.org] On Behalf Of Michal Miroslaw
>> Sent: Wednesday, August 31, 2011 9:05 PM
>> To: Vladislav Zolotarov
>> Cc: Michal Schmidt; netdev@...r.kernel.org; Dmitry Kravkov; Eilon
>> Greenstein
>> Subject: Re: [PATCH 1/3] bnx2x: remove TPA_ENABLE_FLAG
>>
>> 2011/8/31 Vladislav Zolotarov <vladz@...adcom.com>:
>> >> -----Original Message-----
>> >> From: Michal Schmidt [mailto:mschmidt@...hat.com]
>> >> Sent: Wednesday, August 31, 2011 6:59 PM
>> >> To: Vladislav Zolotarov
>> >> Cc: netdev@...r.kernel.org; Dmitry Kravkov; Eilon Greenstein;
>> >> mirqus@...il.com
>> >> Subject: Re: [PATCH 1/3] bnx2x: remove TPA_ENABLE_FLAG
>> >>
>> >> On Wed, 31 Aug 2011 18:16:30 +0300 Vlad Zolotarov wrote:
>> >> > On Wednesday 31 August 2011 18:00:34 Michal Schmidt wrote:
>> >> > >   if (bnx2x_reload) {
>> >> > > -         if (bp->recovery_state == BNX2X_RECOVERY_DONE)
>> >> > > +         if (bp->recovery_state == BNX2X_RECOVERY_DONE) {
>> >> > > +                 /*
>> >> > > +                  * Cheat! Normally dev->features will be
>> >> > > set after we
>> >> > > +                  * return, but that's too late. We need to
>> >> > > know how to
>> >> > > +                  * configure the NIC when reloading it, so
>> >> > > update
>> >> > > +                  * the features early.
>> >> > > +                  */
>> >> > > +                 dev->features = features;
>> >> > >                   return bnx2x_reload_if_running(dev);
>> >> >
>> >> > NACK
>> >> >
>> >> > This is bogus - what if bnx2x_reload_if_running(dev)
>> >> > (bnx2x_nic_load()) failes? The original dev->features would be
>> >> > lost...
>> >>
>> >> Well, yes, but since the NIC would be now not working, do we really
>> >> care about its features? :-)
>> >
>> > U r kidding, right? ;)
>> > We care about the consistency in the netdev features state - if we
>> failed
>> > to configure the requested feature and returned an error on e.g.
>> "ethtool -K ethX lro on"
>> > call, it's expected that a subsequent ethtool -k ethX call won't
>> report the requested
>> > feature (LRO) as set.
>>
>> If bnx2x_reload_if_running() failure means that NIC is disabled, then
>> Michal is right that there's no point in caring about dev->features,
>> sice 'load' operation (NIC configuration) needs to be done again
>> anyway.
> Michal, it's a matter of a consistent semantics/behavior of the ethtool callbacks just as I described above.
> As long as dev->features may be queried both when device is down I'm afraid I can't agree with u.

If I understand correctly, bnx2x_reload_if_running() failure does not
mean exactly that features change failed. It means that device failed
to initialize, possibly because of other (transient?) conditions. So
unless reverting features change and retrying the initialization is
known to allow the device to be brought back, there's no difference
whether old or new dev->features value is kept and which set is
reported by ethtool.

Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ