linux-kernel - Re: [RFC PATCH v2 00/10] Add configurable block device LED triggers

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: <20210810153840.42419d06@thinkpad>
Date:   Tue, 10 Aug 2021 15:38:40 +0200
From:   Marek Behún <kabel@...nel.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Ian Pilcher <arequipeno@...il.com>, hch@....de, axboe@...nel.dk,
        kernelnewbies@...nelnewbies.org, linux-kernel@...r.kernel.org,
        linux-block@...r.kernel.org, pavel@....cz, pali@...nel.org,
        linux-leds@...r.kernel.org
Subject: Re: [RFC PATCH v2 00/10] Add configurable block device LED triggers

On Tue, 10 Aug 2021 08:35:08 +0200
Greg KH <gregkh@...uxfoundation.org> wrote:

> On Mon, Aug 09, 2021 at 06:50:44PM -0500, Ian Pilcher wrote:
> > On 8/9/21 5:43 PM, Marek Behún wrote:  
> > > I confess that I am not very familiar with internal blkdev API.  
> > 
> > It's mainly a matter of symbol visibility.  See this thread from a few
> > months ago:
> > 
> >   https://www.spinics.net/lists/linux-leds/msg18244.html
> > 
> > Now ... my code currently lives in block/, so there isn't actually
> > anything technically preventing it from iterating through the block
> > devices.
> > 
> > The reactions to Enzo's patch (which you can see in that thread) make me
> > think that anything that iterates through all block devices is likely to
> > be rejected, but maybe I'm reading too much into it.
> > 
> > 
> > Greg / Christoph -
> > 
> > (As you were the people who expressed disapproval of Enzo's patch to
> > export block_class and disk_type ...)
> > 
> > Can you weigh in on the acceptability of iterating through the block
> > devices (searching by name) from LED trigger code within the block
> > subsystem (i.e. no new symbols would need to be exported)?
> > 
> > This would allow the trigger to implement the sysfs API that Marek and
> > Pavel want.  
> 
> No idea, let's see the change first, we can never promise anything :)

Hi Greg,

Can't we use blkdev_get_by_path() (or blk_lookup_devt() with
blkdev_get_by_dev())?
This would open the block device and return a struct block_device *.
When the LED trigger is disabled, it would also have to release the
device.

Marek