linux-kernel - Re: [PATCH V2 0/3] 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] [day] [month] [year] [list]

Date:   Thu, 11 Jan 2018 09:34:51 +0100
From:   Arend van Spriel <aspriel@...il.com>
To:     Greg Koah Hartmann <gregkh@...uxfoundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Arend van Spriel <aspriel@...il.com>
Subject: Re: [PATCH V2 0/3] sysfs: allow user-space request for devcoredump

On Wed, Jan 10, 2018 at 2:53 PM, Arend van Spriel <aspriel@...il.com> wrote:
> 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. As the
> devcoredump API offers more than one option, eg. single buffer vs. scatter
> list, it is left up to the driver how to invoke the devcoredump API. As an
> example this series includes a driver implementation as RFC. There are other
> drivers having some form of device firmware coredump that could benefit
> from this, but decided to tackle that in another cycle.
>
> These patches apply to the driver-core-next branch of the driver-core
> repository.

Please drop this series. I have V3 coming with minor update.

Regards,
Arend