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  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]
Date:   Wed, 5 Oct 2016 08:51:01 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Andy Grover <agrover@...hat.com>, dm-devel@...hat.com,
        linux-kernel@...r.kernel.org, snitzer@...hat.com
Subject: Re: [dm-devel] [PATCH 0/9] Generate uevents for all DM events

On Wed, Oct 05, 2016 at 01:40:05AM +0100, Alasdair G Kergon wrote:
> On Tue, Oct 04, 2016 at 04:39:28PM -0700, Andy Grover wrote:
> > devicemapper is using uevents for:
> > a. dm-verity detected corruption
> > b. dm-multipath: path failed or reinstated
> > c. dm device renamed
> > d. there's also some use in md and bcache.
> >
> > devicemapper uses DM_EVENT ioctl (yuck) for:
> > 1. dm-thin pool data/metadata filling up (hit a threshold)
> > 2. dm-cache is now clean
> > 3. dm-log flushed or log failed
> > 4. dm-raid error detected or sync complete
> 
> > there doesn't seem to be much technical differentiation between the  
> > two lists.
> 
> The distinction in dm is that events in the first category may affect
> the availability of the device: they represent major (and hopefully
> rare) changes.
> 
> Events in the second category are just notifications: no impact on /dev,
> no need to trigger udev rules, and their use will continue to be
> extended, and (rarely at the moment) could be frequent (which is no
> problem for the existing polling-based mechanism).
> 
> > Instead of using uevent for everything, we could go to a separate  
> > genetlink for 1-4 instead of making them use uevent like a-d, but we'd  
> > end up with two different userspace notification techniques.
> 
> We see these as two different categories of notifications, and prefer
> the greater flexibility a mechanism independent of uevents would
> provide.  The team has discussed several alternatives over the years but
> didn't make a decision as we've not yet reached a point where we're
> straining the existing mechanism too far.

So, no changes need to be made?  I'm confused here, who is wanting this
changed?

greg k-h

Powered by blists - more mailing lists