Re: [RFC] firmware coredump: add new firmware coredump class

[Johannes Berg]

On Wed, 2014-09-03 at 12:15 -0700, Greg Kroah-Hartman wrote:
> On Wed, Sep 03, 2014 at 09:00:42PM +0200, Johannes Berg wrote:
> > On Wed, 2014-09-03 at 09:38 -0500, Seth Forshee wrote:
> > 
> > > Overall I think this looks pretty sensible. The thing that worries me
> > > though is firmware which might crash repeatedly in a short period of
> > > time, resulting in a proliferation of coredumps and eating up all
> > > available RAM. How about a limit of one active coredump per device or
> > > something similar?
> > 
> > Oh, right, I completely forgot about that. Not sure what context I can
> > iterate the class device list, but worst case I have to add another
> > list.
> 
> Before you add another device, walk the list of all devices of the class
> to see if there is already a device with the same parent.  If so, delete
> that one and then continue and add the one you wanted to create.

Or throw away the new data, yeah. The "context" part was just that I was
aiming to make this function callable say without being able to sleep
(hence also the gfp_t argument) but I don't know for sure I can iterate
the class device list that way. I can look it up though - no need for
anyone else to answer that question :)

> > We likely want to store the first dump then, I suppose?
> 
> Or the last one?  I don't know...

It might even have to be device-specific policy? But in general I'd
think that the first would make more sense because mostly we'd try to
recover from the issue, but if that results in another issue that's
usually not all that helpful to know about.

johannes

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/