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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 16 Dec 2022 15:33:07 +0100 From: Toke Høiland-Jørgensen <toke@...e.dk> To: Arnd Bergmann <arnd@...db.de>, Arnd Bergmann <arnd@...nel.org>, Kalle Valo <kvalo@...nel.org>, Pavel Skripkin <paskripkin@...il.com> Cc: "David S . Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, linux-wireless@...r.kernel.org, Netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH] ath9k: use proper statements in conditionals "Arnd Bergmann" <arnd@...db.de> writes: > On Thu, Dec 15, 2022, at 18:16, Toke Høiland-Jørgensen wrote: >>> index 30f0765fb9fd..237f4ec2cffd 100644 >>> --- a/drivers/net/wireless/ath/ath9k/htc.h >>> +++ b/drivers/net/wireless/ath/ath9k/htc.h >>> @@ -327,9 +327,9 @@ static inline struct ath9k_htc_tx_ctl *HTC_SKB_CB(struct sk_buff *skb) >>> } >>> >>> #ifdef CONFIG_ATH9K_HTC_DEBUGFS >>> -#define __STAT_SAFE(hif_dev, expr) ((hif_dev)->htc_handle->drv_priv ? (expr) : 0) >>> -#define CAB_STAT_INC(priv) ((priv)->debug.tx_stats.cab_queued++) >>> -#define TX_QSTAT_INC(priv, q) ((priv)->debug.tx_stats.queue_stats[q]++) >>> +#define __STAT_SAFE(hif_dev, expr) do { ((hif_dev)->htc_handle->drv_priv ? (expr) : 0); } while (0) >>> +#define CAB_STAT_INC(priv) do { ((priv)->debug.tx_stats.cab_queued++); } while (0) >>> +#define TX_QSTAT_INC(priv, q) do { ((priv)->debug.tx_stats.queue_stats[q]++); } while (0) >> >> Hmm, is it really necessary to wrap these in do/while constructs? AFAICT >> they're all simple statements already? > > It's generally safer to do the same thing on both side of the #ifdef. > > The "do { } while (0)" is an empty statement that is needed to fix > the bug on the #else side. The expressions you have on the #ifdef > side can be used as values, and wrapping them in do{}while(0) > turns them into statements (without a value) as well, so fewer > things can go wrong when you only test one side. Alright, makes sense; thanks for explaining! > I suppose the best solution would be to just use inline functions > for all of them and get rid of the macros. Let's merge this patch to fix the bug, and if someone wants to follow up with a conversion to inline functions, that would be awesome, of course :) -Toke
Powered by blists - more mailing lists