From patchwork Wed Feb 12 17:07:27 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vivek Goyal X-Patchwork-Id: 11378827 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E9BDA89A6 for ; Wed, 12 Feb 2020 17:08:02 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A3B8D20658 for ; Wed, 12 Feb 2020 17:08:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="blwyTH4j" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A3B8D20658 Authentication-Results: mail.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dm-devel-bounces@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581527281; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=YeotxazyEvBbERcO4WhmUTvZy2OpxMoM3bHfzs6a5xU=; b=blwyTH4jSidIa/1jHBrttUIEZJi5sM90fjlG58LPzeUiVuaKOPi+xrSbVORm5u2OpigL9S zlqKwl52QfcwRj1F+LiznZaF7wFMAOajAhy7FACIUUh9RDaC1xE71mTiH1iDua1tP+YJr9 CQsiN/IHlTOAbhdqyj6ZkWlADpBZqq4= 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-131-O7o2ZzYVNh6r-deNg33K4A-1; Wed, 12 Feb 2020 12:07:59 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4569BDBA5; Wed, 12 Feb 2020 17:07:52 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1F9E18EA1A; Wed, 12 Feb 2020 17:07:52 +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 A741C8B2A5; Wed, 12 Feb 2020 17:07:51 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 01CH7ngo001109 for ; Wed, 12 Feb 2020 12:07:49 -0500 Received: by smtp.corp.redhat.com (Postfix) id B9B96863CC; Wed, 12 Feb 2020 17:07:49 +0000 (UTC) Delivered-To: dm-devel@redhat.com Received: from horse.redhat.com (unknown [10.18.25.35]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2445C89F30; Wed, 12 Feb 2020 17:07:47 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id AAF6C220A24; Wed, 12 Feb 2020 12:07:46 -0500 (EST) From: Vivek Goyal To: linux-fsdevel@vger.kernel.org, linux-nvdimm@lists.01.org, dan.j.williams@intel.com, hch@infradead.org Date: Wed, 12 Feb 2020 12:07:27 -0500 Message-Id: <20200212170733.8092-1-vgoyal@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: dm-devel@redhat.com Cc: dm-devel@redhat.com, jack@suse.cz, vgoyal@redhat.com Subject: [dm-devel] [RFC PATCH 0/6] dax: Replace bdev_dax_pgoff() with dax_pgoff() 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.13 X-MC-Unique: O7o2ZzYVNh6r-deNg33K4A-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Currently dax code assumes that there is always a block device associated with it. And block device is passed around in few routines. I am implementing DAX support for virtiofs and there is no block device while we are using dax device. So I need dax code to move away from this assumption that there is always a block device. We seem to pass around block deivce only to calculate the partition offset into dax device. bdev_dax_pgoff() does get_start_sect(bdev). There are two proposed solutions to this problem. - Get rid of kernel partition support for pmem devices. - Caller stores offset into dax device and passes that in along with dax_device. First solution was discussed recently in this thread. https://lore.kernel.org/linux-fsdevel/20200107125159.GA15745@infradead.org/ I feel we already shipped partition support for dax block devices and going back now will be painful and its easy to break users out there which are using partitions. Hence I thought of writing patches for second proposal and see how bad it looks. To me patches are fairly small and don't break backward compatibility and seem like a good step in the direction of removing dax assumptions about block device. So I am posting this RFC patch series, which is just boot tested. Any feedback or comments are welcome. Thanks Vivek Vivek Goyal (6): dax: Define a helper dax_pgoff() which takes in dax_offset as argument dax,iomap,ext4,ext2,xfs: Save dax_offset in "struct iomap" fs/dax.c: Start using dax_pgoff() instead of bdev_dax_pgoff() dax, dm/md: Use dax_pgoff() instead of bdev_dax_pgoff() drivers/dax: Use dax_pgoff() instead of bdev_dax_pgoff() dax: Remove bdev_dax_pgoff() helper drivers/dax/super.c | 11 +++++------ drivers/md/dm-linear.c | 9 ++++++--- drivers/md/dm-log-writes.c | 9 ++++++--- drivers/md/dm-stripe.c | 8 +++++--- fs/dax.c | 13 ++++++------- fs/ext2/inode.c | 1 + fs/ext4/inode.c | 1 + fs/xfs/xfs_iomap.c | 2 ++ include/linux/dax.h | 2 +- include/linux/iomap.h | 1 + 10 files changed, 34 insertions(+), 23 deletions(-)