Messages in this thread | | | Subject | Re: [RFC 1/2] devlink: add simple fw crash helpers | From | Johannes Berg <> | Date | Fri, 22 May 2020 22:46:07 +0200 |
| |
On Fri, 2020-05-22 at 10:17 -0700, Jakub Kicinski wrote:
> > > --- a/net/core/Makefile > > > +++ b/net/core/Makefile > > > @@ -31,7 +31,7 @@ obj-$(CONFIG_LWTUNNEL_BPF) += lwt_bpf.o > > > obj-$(CONFIG_BPF_STREAM_PARSER) += sock_map.o > > > obj-$(CONFIG_DST_CACHE) += dst_cache.o > > > obj-$(CONFIG_HWBM) += hwbm.o > > > -obj-$(CONFIG_NET_DEVLINK) += devlink.o > > > +obj-$(CONFIG_NET_DEVLINK) += devlink.o devlink_simple_fw_reporter.o > > > > This was looking super sexy up to here. This is networking specific. > > We want something generic for *anything* that requests firmware. > > You can't be serious. It's network specific because of how the Kconfig > is named?
Wait, yeah, what?
> Working for a company operating large data centers I would strongly > prefer if we didn't have ten different ways of reporting firmware > problems in the fleet.
Agree. I don't actually operate anything, but still ...
Thinking about this - maybe there's a way to still combine devcoredump and devlink somehow?
Or (optionally) make devlink trigger devcoredump while userspace migrates?
> > So networking may want to be aware that a firmware crash happened as > > part of this network device health thing, but firmware crashing is a > > generic thing. > > > > I have now extended my patch set to include uvents and I am more set on > > that we need the taint now more than ever.
FWIW, I still completely disagree on that taint. You (Luis) obviously have been running into a bug in that driver, I doubt the firmware actually managed to wedge the hardware.
But even if it did, that's still not really a kernel taint. The kernel itself isn't in any way affected by this.
Yes, the system is in a weird state now. But that's *not* equivalent to "kernel tainted".
> The irony is you have a problem with a networking device and all the > devices your initial set touched are networking. Two of the drivers > you touched either have or will soon have devlink health reporters > implemented.
Like I said above, do you think it'd be feasible to make a devcoredump out of devlink health reports? And can the report be in a way that we control the file format, or are there limits? I guess I should read the code to find out, but I figure you probably just know. But feel free to tell me to read it :)
The reason I'm asking is that it's starting to sound like we really ought to be implementing devlink, but we've got a bunch of infrastructure that uses the devcoredump, and it'll take time (significantly so) to change all that...
johannes
| |