linux-kernel - Re: [PATCH 0/2] block layer filter and block device snapshot module

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: <CAMM=eLfTf2f2Me7f5tpL5DEGgKsqaFaAS0qTDVpLAYrwR5Jf5g@mail.gmail.com>
Date:   Thu, 22 Oct 2020 14:35:02 -0400
From:   Mike Snitzer <snitzer@...hat.com>
To:     Sergei Shtepa <sergei.shtepa@...am.com>
Cc:     Jens Axboe <axboe@...nel.dk>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christoph Hellwig <hch@...radead.org>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        linux-xfs@...r.kernel.org,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>, rjw@...ysocki.net,
        len.brown@...el.com, Pavel Machek <pavel@....cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        johannes.thumshirn@....com, Ming Lei <ming.lei@...hat.com>,
        Jan Kara <jack@...e.cz>, Tejun Heo <tj@...nel.org>,
        gustavo@...eddedor.com, Bart Van Assche <bvanassche@....org>,
        osandov@...com, koct9i@...il.com,
        Damien Le Moal <damien.lemoal@....com>, steve@....org,
        linux-block <linux-block@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-pm@...r.kernel.org, linux-mm@...ck.org,
        device-mapper development <dm-devel@...hat.com>
Subject: Re: [PATCH 0/2] block layer filter and block device snapshot module

On Wed, Oct 21, 2020 at 5:04 AM Sergei Shtepa <sergei.shtepa@...am.com> wrote:
>
> Hello everyone! Requesting for your comments and suggestions.
>
> # blk-filter
>
> Block layer filter allows to intercept BIO requests to a block device.
>
> Interception is performed at the very beginning of the BIO request
> processing, and therefore does not affect the operation of the request
> processing queue. This also makes it possible to intercept requests from
> a specific block device, rather than from the entire disk.
>
> The logic of the submit_bio function has been changed - since the
> function execution results are not processed anywhere (except for swap
> and direct-io) the function won't return a value anymore.

Your desire to switch to a void return comes exactly when I've noticed
we need it.

->submit_bio's blk_qc_t return is the cookie assigned by blk-mq.  Up
to this point we haven't actually used it for bio-based devices but it
seems clear we'll soon need for bio-based IO polling support.

Just today, I've been auditing drivers/md/dm.c with an eye toward
properly handling the blk_qc_t return (or lack thereof) from various
DM methods.

It could easily be that __submit_bio_noacct and __submit_bio_noacct_mq
will be updated to do something meaningful with the returned cookie
(or that DM will) to facilitate proper IO polling.

Mike