linux-kernel - Re: Fwd: [PATCH 0/2] sysfs: allow user-space request for devcoredump

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180109200305.GA28050@kroah.com>
Date:   Tue, 9 Jan 2018 21:03:05 +0100
From:   Greg KH <greg@...ah.com>
To:     Arend van Spriel <aspriel@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: Fwd: [PATCH 0/2] sysfs: allow user-space request for devcoredump

On Tue, Jan 09, 2018 at 08:21:11PM +0100, Arend van Spriel wrote:
> + LKML
> 
> ---------- Forwarded message ----------
> From: Arend van Spriel <aspriel@...il.com>
> Date: Tue, Jan 9, 2018 at 8:19 PM
> Subject: Re: [PATCH 0/2] sysfs: allow user-space request for devcoredump
> To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> 
> 
> On Tue, Jan 9, 2018 at 7:46 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > On Tue, Dec 19, 2017 at 11:03:20AM +0100, Arend van Spriel wrote:
> >> From: Arend van Spriel <aspriel@...il.com>
> >>
> >> Since commit 833c95456a70 ("device coredump: add new device coredump class")
> >> device drivers have a unified way to provide binary data obtained from a
> >> failing_device to user-space. However, there may be use-cases in which the
> >> driver has no reason to obtain the data, but user-space wants to initiate
> >> it. This adds a coredump device attribute in sysfs when the driver bound to
> >> the device supports the newly added coredump driver callback.
> >
> > What driver is going to set this?  I don't want to add new options to
> > the kernel that never get used, do you have a driver to use it?
> 
> Hi Greg,
> 
> After sending these patches I realized that was going to be your
> response, but decided to wait for it. Obviously there is a driver for
> which I would like to have an option to create a device coredump from
> user-space, ie. the brcm80211 drivers (maintained by my alter-ego ;-)
> ). I can post these patches again as RFC including the brcm80211
> driver patches. Here a bit of background about this itch. A couple of
> other driver support their own coredump implementation, ie. not using
> dev_coredump class and some support user-space initiated coredump
> through debugfs. As that depends on a Kconfig option I looked for
> other solutions. At first I considered doing it in dev_coredump class
> itself by doing:
> 
> # echo 0000:04:00.0 > /sys/class/devcoredump/trigger
> 
> with 'trigger' being a new sysfs attribute for devcoredump. However,
> using the driver core turned out to be much simpler, but I am still
> open for other/better options.

Nah, I don't object to the patches, but I want someone to use it.  So
can you resend these, with a RFC for the driver you want using it as the
last patch?

thanks,

greg k-h