[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220811133703.30fb948e@kernel.org>
Date: Thu, 11 Aug 2022 13:37:03 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Luiz Augusto von Dentz <luiz.dentz@...il.com>
Cc: "Sudip Mukherjee (Codethink)" <sudipm.mukherjee@...il.com>,
Luiz Augusto von Dentz <luiz.von.dentz@...el.com>,
Johan Hedberg <johan.hedberg@...il.com>,
Marcel Holtmann <marcel@...tmann.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"open list:NETWORKING [GENERAL]" <netdev@...r.kernel.org>,
"linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
linux-next@...r.kernel.org,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
linux-mips@...r.kernel.org
Subject: Re: build failure of next-20220811 due to 332f1795ca20 ("Bluetooth:
L2CAP: Fix l2cap_global_chan_by_psm regression")
On Thu, 11 Aug 2022 13:20:52 -0700 Luiz Augusto von Dentz wrote:
> > +static inline int ba_is_any(const bdaddr_t *ba)
> > +{
> > + return memchr_inv(ba, sizeof(*ba), 0);
> > +}
>
> So we can't use something like BDADDR_ANY to compare? Anyway afaik
> these were already present before the patch so I do wonder what had
> trigger it show now or perhaps it was being suppressed before and
> since we change it now start showing again?
Yeah, I mentioned that in my previous reply as well, a quick grep
counts 70 instances, IDK what makes the l2cap code different :S
Then again I don't know how the compiler deals with passing a pointer
to a constant to an inline function.... so I figured memchr_inv()
could help us avoid hitting compiler bugs.
Powered by blists - more mailing lists