Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1422085pxb; Thu, 4 Mar 2021 10:50:32 -0800 (PST) X-Google-Smtp-Source: ABdhPJx8R7l0cVH7PQCpHHvrd+BkJ1Qj8/VjerLIieik50X/2150Nj8KqZyDfYUKs1rgKFzIRJap X-Received: by 2002:a50:e702:: with SMTP id a2mr6063418edn.3.1614883832692; Thu, 04 Mar 2021 10:50:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614883832; cv=none; d=google.com; s=arc-20160816; b=WYoMCoWLhVFWy33+jzep7Fe2gQqr86XemZxzx/jzl2BJmMM+bNWluIaua6OX6urjGj V2/Lci7rKHtNx6+WSimn4CNChEyjilMwPJnqOTPoYJqHHsUEtduRKlmiFQoWM7VeRb7K Egq8/p9yI8mWPC8/AuMofXlrQZHl+IuBhDscsnKab4EYELjbUkexJKPzeRR9D4NbDEpH qb266AckXSG59jngW265Cqcaj2sFqeYweAbRLUnjnmaB4PX5RR3yMbRkjKw+8vLsuK2U CSFFLpKYb8CFiUYzsCF4DG6S+H4iiZA/M3LMELEiRU66d34tF3d6LvjUADSR8EuYFp/C Ap2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from :dkim-signature; bh=LH+nxslTQcrSx/rBsBPlCNstmi56jt6xI2HDC7GWY1A=; b=ITczdMn6lRGJmpkJwuuHd0vWEwOY6OfKiWtlIpnQHtPHD6AsyU0zW34D+6JC/huIFo vpWiAW/hzyPcI3j0n+U/AEUl31DZoBQYRlVR0czkWEMT9qMp7eJNYQZPfHeRrNkQqczg H4a9rNRI9+dBF7LTul/KlxUoZdeFNDlnoC5p7kLKoomyQB5awXtjuqS6j4qf9JOo3kcr Jmm1T7E837SIYqVrMlA164LLPCHy1c6L1GAuIonX42SpombhYzuhmzv+E/4QhOOug/jU a/xWYloNxoTW/pTTcZYVrUeQ5N6Qm4AWsgXngOfgSZxW3piH9pUORaokBKfW1LrRWdWE eZXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@veeam.com header.s=mx4 header.b=AFPQIMF+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=veeam.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j22si173803edq.584.2021.03.04.10.50.10; Thu, 04 Mar 2021 10:50:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@veeam.com header.s=mx4 header.b=AFPQIMF+; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=veeam.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239165AbhCDRPA (ORCPT + 99 others); Thu, 4 Mar 2021 12:15:00 -0500 Received: from mx4.veeam.com ([104.41.138.86]:54418 "EHLO mx4.veeam.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239044AbhCDROa (ORCPT ); Thu, 4 Mar 2021 12:14:30 -0500 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=veeam.com; s=mx4; t=1614878027; bh=LH+nxslTQcrSx/rBsBPlCNstmi56jt6xI2HDC7GWY1A=; h=From:To:CC:Subject:Date:From; b=AFPQIMF+g2f0h+ZmZU097geUiQrYHMPct5DBt/NudWOu67CYsjfCSFz3jKpIV0UJx M22hjVoW3Pl+tATPUrFrEluSbgzxriD0km7B/1OAcuS/LLBrfr79JOzrngi+ygQtut xEk4vaB2n85uYZd+CJzFVDfvj8U3HfKSX45f+pt0= 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: , , , , , CC: , Subject: [PATCH 0/1] device filter Date: Thu, 4 Mar 2021 20:13:37 +0300 Message-ID: <1614878018-23278-1-git-send-email-sergei.shtepa@veeam.com> X-Mailer: git-send-email 1.8.3.1 MIME-Version: 1.0 Content-Type: text/plain 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 -- 2.20.1