[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240229132610.4ea1517f@kernel.org>
Date: Thu, 29 Feb 2024 13:26:10 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, pabeni@...hat.com
Subject: Re: [GIT PULL] Networking for v6.8-rc7
On Thu, 29 Feb 2024 12:56:21 -0800 Linus Torvalds wrote:
> On Thu, 29 Feb 2024 at 12:39, Jakub Kicinski <kuba@...nel.org> wrote:
> > A few hours late, the commit on top fixes an odd "rcu_dereference()
> > needs to know full type" build issue I can't repro..
>
> Ugfh. That change literally makes a single load instruction be a
> function call. Pretty sad, particularly with all the crazy CPU
> mitigations causing that to be even more expensive than it is already.
>
> I really don't see how that error can happen, it sounds very odd.
>
> Oh well.
Another mysterious report was:
include/linux/dpll.h:179:1: warning: control reaches end of non-void function [-Wreturn-type]
https://lore.kernel.org/all/202403010245.MXVdcekk-lkp@intel.com/
which I also don't see how since the code as of the commit used was:
173 static inline struct dpll_pin *netdev_dpll_pin(const struct net_device *dev)
174 {
175 #if IS_ENABLED(CONFIG_DPLL)
176 return rcu_dereference_rtnl(dev->dpll_pin);
177 #else
178 return NULL;
179 #endif
180 }
We'll rejig this in net-next, all the caller does is pass the result
to another function.
Powered by blists - more mailing lists