On Mon, 2020-11-02 at 18:26 +0200, Kalle Valo wrote: > Arnd Bergmann <arnd@xxxxxxxxxx> writes: > > > From: Arnd Bergmann <arnd@xxxxxxxx> > > > > gcc-10 shows a false-positive warning with CONFIG_KASAN: > > > > drivers/net/wireless/ath/ath9k/dynack.c: In function 'ath_dynack_sample_tx_ts': > > include/linux/etherdevice.h:290:14: warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=] > > 290 | *(u32 *)dst = *(const u32 *)src; > > | ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ > > > > Until gcc is fixed, work around this by using memcpy() in place > > of ether_addr_copy(). Hopefully gcc-11 will not have this problem. > > > > Link: https://godbolt.org/z/sab1MK > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490 > > Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx> > > --- > > drivers/net/wireless/ath/ath9k/dynack.c | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/net/wireless/ath/ath9k/dynack.c b/drivers/net/wireless/ath/ath9k/dynack.c > > index fbeb4a739d32..e4eb96b26ca4 100644 > > --- a/drivers/net/wireless/ath/ath9k/dynack.c > > +++ b/drivers/net/wireless/ath/ath9k/dynack.c > > @@ -247,8 +247,14 @@ void ath_dynack_sample_tx_ts(struct ath_hw *ah, struct sk_buff *skb, > > ridx = ts->ts_rateindex; > > > > da->st_rbf.ts[da->st_rbf.t_rb].tstamp = ts->ts_tstamp; > > +#if defined(CONFIG_KASAN) && (CONFIG_GCC_VERSION >= 100000) && (CONFIG_GCC_VERSION < 110000) > > + /* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490 */ > > + memcpy(da->st_rbf.addr[da->st_rbf.t_rb].h_dest, hdr->addr1, ETH_ALEN); > > + memcpy(da->st_rbf.addr[da->st_rbf.t_rb].h_src, hdr->addr2, ETH_ALEN); > > +#else > > ether_addr_copy(da->st_rbf.addr[da->st_rbf.t_rb].h_dest, hdr->addr1); > > ether_addr_copy(da->st_rbf.addr[da->st_rbf.t_rb].h_src, hdr->addr2); > > +#endif > > Isn't there a better way to handle this? I really would not want > checking for GCC versions become a common approach in drivers. > > I even think that using memcpy() always is better than the ugly ifdef. If you put memcpy() always somebody will surely go and clean it up to use ether_addr_copy() soon ... That said, if there's a gcc issue with ether_addr_copy() then how come it's specific to this place? johannes
