From patchwork Thu Mar 4 17:13:37 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sergei Shtepa X-Patchwork-Id: 12116607 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 076A9C433DB for ; Thu, 4 Mar 2021 17:14:09 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7136264F57 for ; Thu, 4 Mar 2021 17:14:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7136264F57 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=veeam.com Authentication-Results: mail.kernel.org; spf=tempfail smtp.mailfrom=dm-devel-bounces@redhat.com Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-124-QYN_uBgAOXeOzRCqBvEPrQ-1; Thu, 04 Mar 2021 12:14:05 -0500 X-MC-Unique: QYN_uBgAOXeOzRCqBvEPrQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8912480006E; Thu, 4 Mar 2021 17:14:00 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E7F495C1C2; Thu, 4 Mar 2021 17:13:58 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 2FACB1809C86; Thu, 4 Mar 2021 17:13:57 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 124HDux4031376 for ; Thu, 4 Mar 2021 12:13:56 -0500 Received: by smtp.corp.redhat.com (Postfix) id 17A26142550A; Thu, 4 Mar 2021 17:13:56 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast05.extmail.prod.ext.rdu2.redhat.com [10.11.55.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 11C251419594 for ; Thu, 4 Mar 2021 17:13:53 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8E7EF8493E2 for ; Thu, 4 Mar 2021 17:13:53 +0000 (UTC) Received: from mx4.veeam.com (mx4.veeam.com [104.41.138.86]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-233-nk6lenRpOtqbGRG6IFUNPA-1; Thu, 04 Mar 2021 12:13:49 -0500 X-MC-Unique: nk6lenRpOtqbGRG6IFUNPA-1 Received: from mail.veeam.com (prgmbx01.amust.local [172.24.0.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.veeam.com (Postfix) with ESMTPS id 9ABA6114A8F; Thu, 4 Mar 2021 20:13:47 +0300 (MSK) Received: from prgdevlinuxpatch01.amust.local (172.24.14.5) by prgmbx01.amust.local (172.24.0.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Thu, 4 Mar 2021 18:13:46 +0100 From: Sergei Shtepa To: , , , , , Date: Thu, 4 Mar 2021 20:13:37 +0300 Message-ID: <1614878018-23278-1-git-send-email-sergei.shtepa@veeam.com> MIME-Version: 1.0 X-Originating-IP: [172.24.14.5] X-ClientProxiedBy: prgmbx02.amust.local (172.24.0.172) To prgmbx01.amust.local (172.24.0.171) X-EsetResult: clean, is OK X-EsetId: 37303A29D2A50B58637265 X-Veeam-MMEX: True X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-loop: dm-devel@redhat.com Cc: pavel.tide@veeam.com, sergei.shtepa@veeam.com Subject: [dm-devel] [PATCH 0/1] device filter X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dm-devel-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Hi all. I would like to discuss the idea of further extending the functionality of device mapper and suggest the concept of device filters (DF). The DM creates new block devices based on existing ones. DF will not create new devices. Using blk_interposer, DF will intercept bio requests, perform additional processing, and then pass (or skip) the original request. By analogy with the way DM implements various mapping algorithms through additional modules, so DF will be the basis for the work of modules that implement their own filtering algorithm. Based on DF, it will be possible to create solutions for live migration, continius data protection, and implement the backup on write algorithm. For security systems, it will be possible to implement algorithms for checking accesses to a block device. Installing and removing such filters does not require changing the configuration of the user's infrastructure or rebooting. Connecting and disconnecting is possible "on the fly" using blk-interposer. In this patch, I propose to consider additional IOCTL for the dm-mod module. The new IOCTL looks like a good starting point for developing device filters. It is technically possible to create a DF independently of the DM. However, I think that DF can use a significant part of the code already existing in the DM without creating duplication. I look forward to your feedback on device filter. Sergei Shtepa (1): dm: adds an IOCTL to work with device-filters drivers/md/Makefile | 2 +- drivers/md/dm-ioctl.c | 22 ++++++++++++++++++++++ drivers/md/flt-ctl.c | 25 +++++++++++++++++++++++++ drivers/md/flt-ctl.h | 10 ++++++++++ include/uapi/linux/dm-ioctl.h | 18 ++++++++++++++++-- 5 files changed, 74 insertions(+), 3 deletions(-) create mode 100644 drivers/md/flt-ctl.c create mode 100644 drivers/md/flt-ctl.h