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:   Fri, 13 Mar 2020 13:50:01 -0700
From:   Ram Muthiah <rammuthiah@...gle.com>
To:     Christoph Hellwig <hch@...radead.org>
Cc:     Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel-team@...roid.com
Subject: Re: [PATCH] Inline contents of BLK_MQ_VIRTIO config

On Thu, Mar 12, 2020 at 1:24 AM Christoph Hellwig <hch@...radead.org> wrote:
>
> On Wed, Mar 11, 2020 at 04:56:53PM -0700, Ram Muthiah wrote:
> > The config contains one symbol and is a dep of only two configs.
> > Inlined this symbol so that it's built in by the two configs
> > which need it and deleted the config.
>
> So now we build the code twice instead of once.  Nevermind that you
> have dropped the copyright noticed.  What is the point?
>

The android kernel team is working towards generating a generic
kernel that can be used across many devices. One of the devices in
question is cuttlefish, a android virtual device that relies on
virtio blk.

The config here, blk_mq_virtio, is needed for virtio-blk but it is
binary. blk-mq-virtio cannot be built into this generic kernel in the
interest of keeping all virtio related configs as modules. (This
compromise is needed to enable all physical devices to run this
generic kernel.)

To fix this problem, there are two paths forward that I see. The
patch proposed fixes the problem by inling the one symbol
blk_mq_virtio has since this symbol is used in just two tristate
virtio configs. Additionally, the symbol is fairly small so this
doesn't seem like a bad solution.

Alternatively, I could modularize blk-mq-virtio. It does look like
this config was meant to be tristate based on the include of the
module header and the export of blk_mq_virtio_map_queues.

If the latter approach is preferred, I'd be happy to resubmit the
patch.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ