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, 9 Jan 2014 18:18:50 +0000
From:	"Rustad, Mark D" <mark.d.rustad@...el.com>
To:	Scott Feldman <sfeldma@...il.com>
CC:	"Brown, Aaron F" <aaron.f.brown@...el.com>,
	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>,
	"sassmann@...hat.com" <sassmann@...hat.com>
Subject: Re: [net-next 2/7] ixgbe: Indicate removal state explicitly

On Jan 9, 2014, at 9:27 AM, Rustad, Mark D <mark.d.rustad@...el.com> wrote:

> On Jan 8, 2014, at 12:35 AM, Scott Feldman <sfeldma@...il.com> wrote:
> 
>> On Jan 7, 2014, at 11:40 PM, Aaron Brown <aaron.f.brown@...el.com> wrote:
>> 
>>> From: Mark Rustad <mark.d.rustad@...el.com>
>>> 
>>> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
>>> index 5e157ac..480c5c1 100644
>>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
>>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
>>> @@ -124,6 +124,11 @@ s32 ixgbe_reset_pipeline_82599(struct ixgbe_hw *hw);
>>> s32 ixgbe_get_thermal_sensor_data_generic(struct ixgbe_hw *hw);
>>> s32 ixgbe_init_thermal_sensor_thresh_generic(struct ixgbe_hw *hw);
>>> 
>>> +#define IXGBE_FAILED_READ_REG 0xffffffffU
>>> +
>>> +void ixgbe_check_remove(struct ixgbe_hw *hw, u32 reg);
>>> +#define IXGBE_REMOVED(a) unlikely(!(a))
>> 
>> IXGBE_REMOVED seems pretty closely tied to hw->hw_addr, but the macro turns any input into !input.  Maybe an inline that takes a *hw?
> 
> An earlier version had two different inputs, but not any more. I will change it to take a hw parameter. Good suggestion.

Actually, I responded too quickly. Although my comment on there previously having been two different inputs was true, that isn't the real reason for this form. The reason is that the check needs to be done on the value retrieved by ACCESS_ONCE - the address that will be used for the access. If the parameter were hw, then a separate dereference could occur, which is definitely not wanted.

One could argue that the macro should just be eliminated and the expansion put everywhere, but I feel that the code is much clearer with the macro. Unless there is another suggestion, I think this should stay as it is in this series.

-- 
Mark Rustad, Networking Division, Intel Corporation


Download attachment "signature.asc" of type "application/pgp-signature" (842 bytes)

Powered by blists - more mailing lists