Re: Re: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags

[Lino Sanfilippo]

Hi,

>
> 
> This patch should be enhanced with the smb_xx() calls as suggested by by Lino.
> 

If you do this, please place the smp_rmb() before the if condition in the irq
handler like

smp_rmb();
if (rtlpci->irq_enabled == 0) {
return ret;


as I think that the suggestion I made before was not correct (sorry for the
confusion). 

Regards,
Lino 
 

Re: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags

[Lino Sanfilippo]

Hi,

On 19.01.2017 19:08, Larry Finger wrote:

On 01/19/2017 08:35 AM, Lino Sanfilippo wrote:

Hi,

altek/rtlwifi/rtl8192ce/hw.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c

index a47be73..143766c4 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/hw.c
@@ -1306,9 +1306,9 @@ void rtl92ce_enable_interrupt(struct 
ieee80211_hw *hw)

 struct rtl_priv *rtlpriv = rtl_priv(hw);
 struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));

+rtlpci->irq_enabled = true;
 rtl_write_dword(rtlpriv, REG_HIMR, rtlpci->irq_mask[0] & 
0x);
 rtl_write_dword(rtlpriv, REG_HIMRE, rtlpci->irq_mask[1] & 
0x);

-rtlpci->irq_enabled = true;
 }

 void rtl92ce_disable_interrupt(struct ieee80211_hw *hw)
@@ -1316,9 +1316,9 @@ void rtl92ce_disable_interrupt(struct 
ieee80211_hw *hw)

 struct rtl_priv *rtlpriv = rtl_priv(hw);
 struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));

+rtlpci->irq_enabled = false;
 rtl_write_dword(rtlpriv, REG_HIMR, IMR8190_DISABLED);
 rtl_write_dword(rtlpriv, REG_HIMRE, IMR8190_DISABLED);
-rtlpci->irq_enabled = false;
 }



AFAIK you also have to use memory barriers here to ensure that
the concerning instructions are not reordered, and both irq handler
and process have a consistent perception of irq_enabled, e.g:

rtlpci->irq_enabled = true;
smp_wmb();
rtl_write_dword(rtlpriv, REG_HIMR, rtlpci->irq_mask[0] & 0x);

and in the irq handler

if (rtlpci->irq_enabled == 0) {
smp_rmb();
return ret;
}


I can see the potential race condition between setting interrupts and 
setting the flag, and I will likely accept Bharat's patch after testing.


I am likely displaying my ignorance regarding instruction reordering, 
but what compiler/cpu combination is likely to move a simple set 
operation after a call to an external routine? Is the smp_wmb() 
operation really needed?


I dont know if and when a specific compiler would actually do such a 
reordering. But the thing is, that you simply cant be sure
that it does not. As I wrote it is also not only reordering that could 
cause trouble, but also a different perception of the

flag value on different CPUs.
We guard against those issues in other drivers, too. See

http://lxr.free-electrons.com/source/drivers/net/ethernet/3com/typhoon.c#L1935

for example.

I am also unsure of the smp_rmb() call in the interrupt handler. 
Neither instruction should cause any problems, but I'm not sure they 
are needed


The smp_rmb() is needed to ensure that the irq handler actually "sees" 
the most recent value of  irq_enabled even if the irq handler is

running on another CPU than the one that set this flag.

Regards,
Lino

Aw: Re: staging: wilc1000: Reduce scope for a few variables in mac_ioctl()

[Lino Sanfilippo]

> Gesendet: Dienstag, 26. Juli 2016 um 08:25 Uhr
> Von: "SF Markus Elfring" 

>
> >> -  if (strncasecmp(buff, "RSSI", length) == 0) {
> >> +  if (strncasecmp(buff, "RSSI", 0) == 0) {
> >> +  s8 rssi;
> >> +
> > 
> > Um, please think a second about if it makes any sense at all to compare 
> > zero chars of two strings.
> 
> Under which circumstances should the variable "length" contain an other
> value than zero?

Which circumstances do "not any sense at all" imply? 

> 
> How can this open issue be fixed better?

The code is not too complicated and I think it is very obvious which 
value/variable
should be passed instead of 0. I suggest to fix this since it is indeed a bug, 
instead of 
doing "micro optimizations" - which is the last thing that code in the staging 
area 
needs (as IIRC you have already been told by others, including the staging 
maintainer).

Regards,
Lino


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html