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]
Date:   Wed, 30 May 2018 15:37:07 -0400
From:   Mike Snitzer <snitzer@...hat.com>
To:     Jens Axboe <axboe@...nel.dk>
Cc:     Kent Overstreet <kent.overstreet@...il.com>,
        linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        hch@...radead.org, colyli@...e.de, darrick.wong@...cle.com,
        clm@...com, bacik@...com, linux-xfs@...r.kernel.org,
        drbd-dev@...ts.linbit.com, linux-btrfs@...r.kernel.org,
        linux-raid@...r.kernel.org, neilb@...e.com
Subject: Re: [PATCH 00/13] convert block layer to bioset_init()/mempool_init()

On Wed, May 30 2018 at  2:55pm -0400,
Jens Axboe <axboe@...nel.dk> wrote:

> On 5/30/18 7:36 AM, Mike Snitzer wrote:
> > So revisiting this patchset: are you inclined to take these changes (I
> > assume yes)?  If so, what would you need in order to get them staged for
> > 4.18?  I'll start with offering my review in reply to the DM patch.  I'd
> > much prefer to see this level of change go in sooner rather than later.
> 
> Yeah I'd like to take the changes, but we might have to wait for
> 4.19 at this point. It'd certainly help to have the dm bits reviewed,
> as they are some of the larger ones. The grunt of the others are mostly
> trivial and smaller in scope.

I _really_ would like to see this land for 4.18.  It'll avoid downstream
backport problems (due to all the churn in this patchset).

As I'm sure you've seen I reviewed and Acked-by the DM patch.

I mentioned I've been chatting with Kent, he is available if anything
needs a v2 for whatever reason.

Would you be OK adding a single sentence description to each driver's
patch header (rather than leaving empty like how Kent submitted)?  Or
should Kent resubmit the entire set with that boilerplate header for
each patch?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ