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: <20180522064118.GA18704@infradead.org>
Date:   Mon, 21 May 2018 23:41:18 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Kent Overstreet <kent.overstreet@...il.com>
Cc:     Mike Snitzer <snitzer@...hat.com>, Jens Axboe <axboe@...nel.dk>,
        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 Mon, May 21, 2018 at 07:38:55PM -0400, Kent Overstreet wrote:
> On Mon, May 21, 2018 at 02:24:32PM -0400, Mike Snitzer wrote:
> > Every single data structure change in this series should be reviewed for
> > unforeseen alignment consequences.  Jens seemed to say that is
> > worthwhile.  Not sure if he'll do it or we divide it up.  If we divide
> > it up a temp topic branch should be published for others to inspect.
> > 
> > Could be alignment hasn't been a historic concern for a bunch of the
> > data structures changed in this series.. if so then all we can do is fix
> > up any obvious potential for false sharing.
> 
> Honestly, I almost never worry about alignment... the very few times I do care,
> I use __cacheline_aligned_in_smp.

And that generally is the right stratgey.  If Mike really doesn't want
a change we can just open code the kmalloc for the bio set there, the
important point is that we should not keep the old API around for no
good reason.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ