linux-kernel - Re: [PATCH 0/1] block io layer filters api

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: <CY4PR04MB37518959789817D5CEE3E5AEE7520@CY4PR04MB3751.namprd04.prod.outlook.com>
Date:   Fri, 28 Aug 2020 07:24:30 +0000
From:   Damien Le Moal <Damien.LeMoal@....com>
To:     Sergei Shtepa <sergei.shtepa@...am.com>,
        "masahiroy@...nel.org" <masahiroy@...nel.org>,
        "michal.lkml@...kovi.net" <michal.lkml@...kovi.net>,
        "axboe@...nel.dk" <axboe@...nel.dk>,
        "koct9i@...il.com" <koct9i@...il.com>,
        "jack@...e.cz" <jack@...e.cz>,
        "ming.lei@...hat.com" <ming.lei@...hat.com>,
        "steve@....org" <steve@....org>,
        "linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>
Subject: Re: [PATCH 0/1] block io layer filters api

On 2020/08/28 4:14, Sergei Shtepa wrote:
> Hello everyone! Requesting for your comments and suggestions.
> 
> We propose new kernel API that should be beneficial for out-of-tree
> kernel modules of multiple backup vendors: block layer filter API.
> 
> Functionality:
> * Provide callback to intercept bio requests, the main purpose is to
> allow block level snapshots for the devices that do not support it,
> for example, non-LVM block devices and implementation of changed block
> tracking for faster incremental backups without system reconfiguration
> or reboot, but there could be other use cases that we have not thought of.
> * Allow multiple filters to work at the same time. The order in which the
> request is intercepted is determined by their altitude.
> * When new block devices appear, send a synchronous request to the
> registered filter to add it for filtering.
> * If a block device is permanently deleted or disappears, send a
> synchronous request to remove the device from filtering.
> 
> Why dm-snap and dm-era is not the solution:
> Device mapper must be set up in advance, usually backup vendors have very
> little ability to change or convince users to modify the existing setup
> at the time of software installation.
> One of the most common setups is still a block device without LVM and
> formatted with ext4.
> Convincing users to redeploy or reconfigure machine, just to make block
> level snapshots/backup software work, is a challenging task.

And convincing said users to change their kernel is not challenging ? In my
experience, that is even harder than trying to get them to change their
configuration.

> As of now, commit c62b37d96b6e removed make_request_fn from
> struct request_queue and our out-of-tree module [1] can no longer
> hook/replace it to intercept bio requests. And fops in struct gendisk
> is declared as const and cannot be hooked as well.
> 
> We would appreciate your feedback!

Upstream your out-of-tree module ?

> [1] https://github.com/veeam/veeamsnap
> 
> Sergei Shtepa (1):
>   block io layer filters api
> 
>  block/Kconfig               |  11 ++
>  block/Makefile              |   1 +
>  block/blk-core.c            |  11 +-
>  block/blk-filter-internal.h |  34 +++++
>  block/blk-filter.c          | 288 ++++++++++++++++++++++++++++++++++++
>  block/genhd.c               |  24 +++
>  include/linux/blk-filter.h  |  41 +++++
>  include/linux/genhd.h       |   2 +
>  8 files changed, 410 insertions(+), 2 deletions(-)
>  create mode 100644 block/blk-filter-internal.h
>  create mode 100644 block/blk-filter.c
>  create mode 100644 include/linux/blk-filter.h
> 


-- 
Damien Le Moal
Western Digital Research