From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 86EB672 for ; Wed, 27 Oct 2021 23:02:34 +0000 (UTC) Received: by mail-pl1-f178.google.com with SMTP id r5so3099759pls.1 for ; Wed, 27 Oct 2021 16:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TIqjtDMduKwUTBKX+tBygnWIDjEpMEr2bhy/yT20mZY=; b=REyhBK6tQZDsAnyKckv+GTqli7ewznlsn87vyBbY5f9febMQ9OwtuAQWJhdicQr38K K1RmGd24wmhycGjPGNyFLV1NcRjXV0YOMJgCvWwD1u2op9FVS5Ne01Ma8I3/7N/vKG+L Nf/tcy6ZTKg9EdZlESmgy/KdDpwwSItb4MeferFvOhl0fHKDs4iLoNdhifCWx1/jKI7k we4R1sn71TU5C2vgTscBN2f7yTZYEbFO4nfi+2G6AAM+9u32OYSh0jX2w1H4FzdcM3Ry 12G6L2JWGDbLkKio2wNGWYlGKXiSVAEj+xqYbUihB4TpfsaefQ6c0TKQ0AY7vxbKpFnC uryw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TIqjtDMduKwUTBKX+tBygnWIDjEpMEr2bhy/yT20mZY=; b=EkkbwNJpaoRMw7cjkiKgbQdps6yV0SGesyN2XruCRy00gV0Ges9nNCpnd7avXy3bp8 VgFu/4zRGTA8NYKzShDnnuLlPbWgkd36IjMJcNLrHN0vOxVGPpe5lYwUDc4ZPY53RsdV pGSqKqnkd/na278j3vzvPomQutgh80dPa0aNOeMjOcNKWjgisBUNA3eOWbleOCQY3Bey 1ImOQLHXrkIiztgo4ZwYqK5Ij8gPaxgpbWZGnfJ+4lwThMhsVLD6sb6T0UzeUx6bOlbf I3yEBr1jJRybeZYVt7r0HrJzDRFmRlT/fOTTJy3SJXom95KP2AjjaFHN2cKBKe/MJdJF cxvg== X-Gm-Message-State: AOAM532zOoHX/P9YRBgytPy8U2I5g0ggHN35I7ZLI2PpAeUjR1vqAIG3 h8nFqEY12tzlzSsBkm67+FW+55uE6ClwTWw707SdYQ== X-Google-Smtp-Source: ABdhPJxUwYpsZPDBKuNiovYR0U6XMhxIiDSjLBJJ1e6zz5gkWe8hCvGUK6ph3bxfDtcB6AFtR1bn5v1MGpOhiVcMhIY= X-Received: by 2002:a17:90a:a085:: with SMTP id r5mr8858216pjp.8.1635375753946; Wed, 27 Oct 2021 16:02:33 -0700 (PDT) Precedence: bulk X-Mailing-List: nvdimm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20211018044054.1779424-1-hch@lst.de> <20211018044054.1779424-5-hch@lst.de> In-Reply-To: <20211018044054.1779424-5-hch@lst.de> From: Dan Williams Date: Wed, 27 Oct 2021 16:02:22 -0700 Message-ID: Subject: Re: [PATCH 04/11] dax: remove the pgmap sanity checks in generic_fsdax_supported To: Christoph Hellwig Cc: Mike Snitzer , Ira Weiny , device-mapper development , linux-xfs , Linux NVDIMM , linux-s390 , linux-fsdevel , linux-erofs@lists.ozlabs.org, linux-ext4 , virtualization@lists.linux-foundation.org Content-Type: text/plain; charset="UTF-8" On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > Drivers that register a dax_dev should make sure it works, no need > to double check from the file system. > > Signed-off-by: Christoph Hellwig > --- > drivers/dax/super.c | 49 +-------------------------------------------- > 1 file changed, 1 insertion(+), 48 deletions(-) > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > index 9383c11b21853..04fc680542e8d 100644 > --- a/drivers/dax/super.c > +++ b/drivers/dax/super.c > @@ -107,13 +107,9 @@ bool generic_fsdax_supported(struct dax_device *dax_dev, > struct block_device *bdev, int blocksize, sector_t start, > sector_t sectors) > { > - bool dax_enabled = false; > pgoff_t pgoff, pgoff_end; > - void *kaddr, *end_kaddr; > - pfn_t pfn, end_pfn; > sector_t last_page; > - long len, len2; > - int err, id; > + int err; > > if (blocksize != PAGE_SIZE) { > pr_info("%pg: error: unsupported blocksize for dax\n", bdev); > @@ -138,49 +134,6 @@ bool generic_fsdax_supported(struct dax_device *dax_dev, > return false; > } > > - id = dax_read_lock(); > - len = dax_direct_access(dax_dev, pgoff, 1, &kaddr, &pfn); > - len2 = dax_direct_access(dax_dev, pgoff_end, 1, &end_kaddr, &end_pfn); > - > - if (len < 1 || len2 < 1) { > - pr_info("%pg: error: dax access failed (%ld)\n", > - bdev, len < 1 ? len : len2); > - dax_read_unlock(id); > - return false; > - } > - > - if (IS_ENABLED(CONFIG_FS_DAX_LIMITED) && pfn_t_special(pfn)) { > - /* > - * An arch that has enabled the pmem api should also > - * have its drivers support pfn_t_devmap() > - * > - * This is a developer warning and should not trigger in > - * production. dax_flush() will crash since it depends > - * on being able to do (page_address(pfn_to_page())). > - */ > - WARN_ON(IS_ENABLED(CONFIG_ARCH_HAS_PMEM_API)); > - dax_enabled = true; > - } else if (pfn_t_devmap(pfn) && pfn_t_devmap(end_pfn)) { > - struct dev_pagemap *pgmap, *end_pgmap; > - > - pgmap = get_dev_pagemap(pfn_t_to_pfn(pfn), NULL); > - end_pgmap = get_dev_pagemap(pfn_t_to_pfn(end_pfn), NULL); > - if (pgmap && pgmap == end_pgmap && pgmap->type == MEMORY_DEVICE_FS_DAX > - && pfn_t_to_page(pfn)->pgmap == pgmap > - && pfn_t_to_page(end_pfn)->pgmap == pgmap > - && pfn_t_to_pfn(pfn) == PHYS_PFN(__pa(kaddr)) > - && pfn_t_to_pfn(end_pfn) == PHYS_PFN(__pa(end_kaddr))) This is effectively a self-test for a regression that was found while manipulating the 'struct page' memmap metadata reservation for PMEM namespaces. I guess it's just serving as a security-blanket now and I should find a way to move it out to a self-test. I'll take a look. > - dax_enabled = true; > - put_dev_pagemap(pgmap); > - put_dev_pagemap(end_pgmap); > - > - } > - dax_read_unlock(id); > - > - if (!dax_enabled) { > - pr_info("%pg: error: dax support not enabled\n", bdev); > - return false; > - } > return true; > } > EXPORT_SYMBOL_GPL(generic_fsdax_supported); > -- > 2.30.2 > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C567CC433F5 for ; Wed, 27 Oct 2021 23:02:39 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 27BB760F9B for ; Wed, 27 Oct 2021 23:02:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 27BB760F9B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id C6A4A60B3C; Wed, 27 Oct 2021 23:02:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRbImsThsv0N; Wed, 27 Oct 2021 23:02:38 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp3.osuosl.org (Postfix) with ESMTPS id 78F306064B; Wed, 27 Oct 2021 23:02:37 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 26E9EC0019; Wed, 27 Oct 2021 23:02:37 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 958FDC000E for ; Wed, 27 Oct 2021 23:02:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6EFD24020A for ; Wed, 27 Oct 2021 23:02:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=intel-com.20210112.gappssmtp.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Oo_93YRC0oD for ; Wed, 27 Oct 2021 23:02:34 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by smtp2.osuosl.org (Postfix) with ESMTPS id 9743D400EA for ; Wed, 27 Oct 2021 23:02:34 +0000 (UTC) Received: by mail-pl1-x62b.google.com with SMTP id t11so3057676plq.11 for ; Wed, 27 Oct 2021 16:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TIqjtDMduKwUTBKX+tBygnWIDjEpMEr2bhy/yT20mZY=; b=REyhBK6tQZDsAnyKckv+GTqli7ewznlsn87vyBbY5f9febMQ9OwtuAQWJhdicQr38K K1RmGd24wmhycGjPGNyFLV1NcRjXV0YOMJgCvWwD1u2op9FVS5Ne01Ma8I3/7N/vKG+L Nf/tcy6ZTKg9EdZlESmgy/KdDpwwSItb4MeferFvOhl0fHKDs4iLoNdhifCWx1/jKI7k we4R1sn71TU5C2vgTscBN2f7yTZYEbFO4nfi+2G6AAM+9u32OYSh0jX2w1H4FzdcM3Ry 12G6L2JWGDbLkKio2wNGWYlGKXiSVAEj+xqYbUihB4TpfsaefQ6c0TKQ0AY7vxbKpFnC uryw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TIqjtDMduKwUTBKX+tBygnWIDjEpMEr2bhy/yT20mZY=; b=3MLlmVwWV3CaIUxwKdS31oJk1nCp4e8u9kmeHL54UY/VnO1gAq2MBCu/mNkFyg2tZ2 fL75LTCCQ9Kv2Hu+kM52tuqjsrvg6qWX/YA2mlmQ0QBaoq55Mn6dwAz+tsfHEzJIs68c bX6m31VxUc8nQo4x4VxMup8obREN8lJM1GXRmw/UxPQ3pgexFjk2EaJk7PWnYyHHoeAp bBPn7dkI/GV9EPjtq24Oyy7pVYEksZVi8IjPW4UcsFz56tcff1DqrI7qm/ODuImyXl2/ /74nfH1cLXFqu+asTqrCqawNRQ8sIZHzTNxmhIP4Fl38HYl9pqasi4BSxYyyeievMbBj H0qQ== X-Gm-Message-State: AOAM532SWtGmSoMh0A0QG3SqUdlYVoPjmcNdCImVAuJraJ7e9+o0Een4 uJaIi2SWnEqPQ/NFeYiBFB5f4OGgQPXsAMlpqsk65Q== X-Google-Smtp-Source: ABdhPJxUwYpsZPDBKuNiovYR0U6XMhxIiDSjLBJJ1e6zz5gkWe8hCvGUK6ph3bxfDtcB6AFtR1bn5v1MGpOhiVcMhIY= X-Received: by 2002:a17:90a:a085:: with SMTP id r5mr8858216pjp.8.1635375753946; Wed, 27 Oct 2021 16:02:33 -0700 (PDT) MIME-Version: 1.0 References: <20211018044054.1779424-1-hch@lst.de> <20211018044054.1779424-5-hch@lst.de> In-Reply-To: <20211018044054.1779424-5-hch@lst.de> From: Dan Williams Date: Wed, 27 Oct 2021 16:02:22 -0700 Message-ID: Subject: Re: [PATCH 04/11] dax: remove the pgmap sanity checks in generic_fsdax_supported To: Christoph Hellwig Cc: Linux NVDIMM , Mike Snitzer , linux-s390 , linux-erofs@lists.ozlabs.org, virtualization@lists.linux-foundation.org, linux-xfs , device-mapper development , linux-fsdevel , linux-ext4 , Ira Weiny X-BeenThere: virtualization@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux virtualization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > Drivers that register a dax_dev should make sure it works, no need > to double check from the file system. > > Signed-off-by: Christoph Hellwig > --- > drivers/dax/super.c | 49 +-------------------------------------------- > 1 file changed, 1 insertion(+), 48 deletions(-) > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > index 9383c11b21853..04fc680542e8d 100644 > --- a/drivers/dax/super.c > +++ b/drivers/dax/super.c > @@ -107,13 +107,9 @@ bool generic_fsdax_supported(struct dax_device *dax_dev, > struct block_device *bdev, int blocksize, sector_t start, > sector_t sectors) > { > - bool dax_enabled = false; > pgoff_t pgoff, pgoff_end; > - void *kaddr, *end_kaddr; > - pfn_t pfn, end_pfn; > sector_t last_page; > - long len, len2; > - int err, id; > + int err; > > if (blocksize != PAGE_SIZE) { > pr_info("%pg: error: unsupported blocksize for dax\n", bdev); > @@ -138,49 +134,6 @@ bool generic_fsdax_supported(struct dax_device *dax_dev, > return false; > } > > - id = dax_read_lock(); > - len = dax_direct_access(dax_dev, pgoff, 1, &kaddr, &pfn); > - len2 = dax_direct_access(dax_dev, pgoff_end, 1, &end_kaddr, &end_pfn); > - > - if (len < 1 || len2 < 1) { > - pr_info("%pg: error: dax access failed (%ld)\n", > - bdev, len < 1 ? len : len2); > - dax_read_unlock(id); > - return false; > - } > - > - if (IS_ENABLED(CONFIG_FS_DAX_LIMITED) && pfn_t_special(pfn)) { > - /* > - * An arch that has enabled the pmem api should also > - * have its drivers support pfn_t_devmap() > - * > - * This is a developer warning and should not trigger in > - * production. dax_flush() will crash since it depends > - * on being able to do (page_address(pfn_to_page())). > - */ > - WARN_ON(IS_ENABLED(CONFIG_ARCH_HAS_PMEM_API)); > - dax_enabled = true; > - } else if (pfn_t_devmap(pfn) && pfn_t_devmap(end_pfn)) { > - struct dev_pagemap *pgmap, *end_pgmap; > - > - pgmap = get_dev_pagemap(pfn_t_to_pfn(pfn), NULL); > - end_pgmap = get_dev_pagemap(pfn_t_to_pfn(end_pfn), NULL); > - if (pgmap && pgmap == end_pgmap && pgmap->type == MEMORY_DEVICE_FS_DAX > - && pfn_t_to_page(pfn)->pgmap == pgmap > - && pfn_t_to_page(end_pfn)->pgmap == pgmap > - && pfn_t_to_pfn(pfn) == PHYS_PFN(__pa(kaddr)) > - && pfn_t_to_pfn(end_pfn) == PHYS_PFN(__pa(end_kaddr))) This is effectively a self-test for a regression that was found while manipulating the 'struct page' memmap metadata reservation for PMEM namespaces. I guess it's just serving as a security-blanket now and I should find a way to move it out to a self-test. I'll take a look. > - dax_enabled = true; > - put_dev_pagemap(pgmap); > - put_dev_pagemap(end_pgmap); > - > - } > - dax_read_unlock(id); > - > - if (!dax_enabled) { > - pr_info("%pg: error: dax support not enabled\n", bdev); > - return false; > - } > return true; > } > EXPORT_SYMBOL_GPL(generic_fsdax_supported); > -- > 2.30.2 > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4EAF1C433F5 for ; Wed, 27 Oct 2021 23:02:51 +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-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CB0A760F9B for ; Wed, 27 Oct 2021 23:02:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CB0A760F9B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=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-216-Vm8XBXbAOveEDuTJP_W14A-1; Wed, 27 Oct 2021 19:02:46 -0400 X-MC-Unique: Vm8XBXbAOveEDuTJP_W14A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9BC8B802B4F; Wed, 27 Oct 2021 23:02:41 +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 15B355DA61; Wed, 27 Oct 2021 23:02:40 +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 7B9E44EA2A; Wed, 27 Oct 2021 23:02:38 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 19RN2b2U016526 for ; Wed, 27 Oct 2021 19:02:37 -0400 Received: by smtp.corp.redhat.com (Postfix) id 16EBE40CFD10; Wed, 27 Oct 2021 23:02:37 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast02.extmail.prod.ext.rdu2.redhat.com [10.11.55.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 11C9040CFD0C for ; Wed, 27 Oct 2021 23:02:37 +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-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EC12780231F for ; Wed, 27 Oct 2021 23:02:36 +0000 (UTC) Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-239-8JPlnLtmMGyl40eHMuV0Hg-1; Wed, 27 Oct 2021 19:02:35 -0400 X-MC-Unique: 8JPlnLtmMGyl40eHMuV0Hg-1 Received: by mail-pl1-f176.google.com with SMTP id i5so3081938pla.5 for ; Wed, 27 Oct 2021 16:02:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TIqjtDMduKwUTBKX+tBygnWIDjEpMEr2bhy/yT20mZY=; b=tXjTmjgt5Q4e4mxUjvJwVza0iwfRum8Excj/enypDB4zTK0WWu1UDh3jHfA8p/agWJ AK9MC4gHAu1M4S11JKlzOkOohjz3XNXKld+rrjNg2kNp+gjs92cNPxWGuaVZBs4EvwlH J2ul0/koCapluvMgY+X80AVZ98dD/sQjYaJH9sESKyVl8PfkPi5CeXQuuulg7xCqMsJL 8RhUI4ABolobF3xZxxJClPDVY0zcyvgZzrACd0J23958pJZPQBA7jqAvdBAnaLdxYJ+L i8F0y5+GdL3utBFRL4bMp9aYv2/0ZpbXR2aj6pVjkAUuWiC6AYwPPhKfznOkhaCMeI/D FD+Q== X-Gm-Message-State: AOAM531TbGj0wve09tkLpPyvZ8Xb71bInln47Tk7iRf4OlyVhzX6jM4G YeFeGvAdFCqUE1hY039eb2tPJJ0JU2ww7fzloXWBOA== X-Google-Smtp-Source: ABdhPJxUwYpsZPDBKuNiovYR0U6XMhxIiDSjLBJJ1e6zz5gkWe8hCvGUK6ph3bxfDtcB6AFtR1bn5v1MGpOhiVcMhIY= X-Received: by 2002:a17:90a:a085:: with SMTP id r5mr8858216pjp.8.1635375753946; Wed, 27 Oct 2021 16:02:33 -0700 (PDT) MIME-Version: 1.0 References: <20211018044054.1779424-1-hch@lst.de> <20211018044054.1779424-5-hch@lst.de> In-Reply-To: <20211018044054.1779424-5-hch@lst.de> From: Dan Williams Date: Wed, 27 Oct 2021 16:02:22 -0700 Message-ID: To: Christoph Hellwig 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.84 on 10.11.54.1 X-loop: dm-devel@redhat.com Cc: Linux NVDIMM , Mike Snitzer , linux-s390 , linux-erofs@lists.ozlabs.org, virtualization@lists.linux-foundation.org, linux-xfs , device-mapper development , linux-fsdevel , linux-ext4 , Ira Weiny Subject: Re: [dm-devel] [PATCH 04/11] dax: remove the pgmap sanity checks in generic_fsdax_supported 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.14 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > Drivers that register a dax_dev should make sure it works, no need > to double check from the file system. > > Signed-off-by: Christoph Hellwig > --- > drivers/dax/super.c | 49 +-------------------------------------------- > 1 file changed, 1 insertion(+), 48 deletions(-) > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > index 9383c11b21853..04fc680542e8d 100644 > --- a/drivers/dax/super.c > +++ b/drivers/dax/super.c > @@ -107,13 +107,9 @@ bool generic_fsdax_supported(struct dax_device *dax_dev, > struct block_device *bdev, int blocksize, sector_t start, > sector_t sectors) > { > - bool dax_enabled = false; > pgoff_t pgoff, pgoff_end; > - void *kaddr, *end_kaddr; > - pfn_t pfn, end_pfn; > sector_t last_page; > - long len, len2; > - int err, id; > + int err; > > if (blocksize != PAGE_SIZE) { > pr_info("%pg: error: unsupported blocksize for dax\n", bdev); > @@ -138,49 +134,6 @@ bool generic_fsdax_supported(struct dax_device *dax_dev, > return false; > } > > - id = dax_read_lock(); > - len = dax_direct_access(dax_dev, pgoff, 1, &kaddr, &pfn); > - len2 = dax_direct_access(dax_dev, pgoff_end, 1, &end_kaddr, &end_pfn); > - > - if (len < 1 || len2 < 1) { > - pr_info("%pg: error: dax access failed (%ld)\n", > - bdev, len < 1 ? len : len2); > - dax_read_unlock(id); > - return false; > - } > - > - if (IS_ENABLED(CONFIG_FS_DAX_LIMITED) && pfn_t_special(pfn)) { > - /* > - * An arch that has enabled the pmem api should also > - * have its drivers support pfn_t_devmap() > - * > - * This is a developer warning and should not trigger in > - * production. dax_flush() will crash since it depends > - * on being able to do (page_address(pfn_to_page())). > - */ > - WARN_ON(IS_ENABLED(CONFIG_ARCH_HAS_PMEM_API)); > - dax_enabled = true; > - } else if (pfn_t_devmap(pfn) && pfn_t_devmap(end_pfn)) { > - struct dev_pagemap *pgmap, *end_pgmap; > - > - pgmap = get_dev_pagemap(pfn_t_to_pfn(pfn), NULL); > - end_pgmap = get_dev_pagemap(pfn_t_to_pfn(end_pfn), NULL); > - if (pgmap && pgmap == end_pgmap && pgmap->type == MEMORY_DEVICE_FS_DAX > - && pfn_t_to_page(pfn)->pgmap == pgmap > - && pfn_t_to_page(end_pfn)->pgmap == pgmap > - && pfn_t_to_pfn(pfn) == PHYS_PFN(__pa(kaddr)) > - && pfn_t_to_pfn(end_pfn) == PHYS_PFN(__pa(end_kaddr))) This is effectively a self-test for a regression that was found while manipulating the 'struct page' memmap metadata reservation for PMEM namespaces. I guess it's just serving as a security-blanket now and I should find a way to move it out to a self-test. I'll take a look. > - dax_enabled = true; > - put_dev_pagemap(pgmap); > - put_dev_pagemap(end_pgmap); > - > - } > - dax_read_unlock(id); > - > - if (!dax_enabled) { > - pr_info("%pg: error: dax support not enabled\n", bdev); > - return false; > - } > return true; > } > EXPORT_SYMBOL_GPL(generic_fsdax_supported); > -- > 2.30.2 > -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A08BC433EF for ; Wed, 27 Oct 2021 23:18:00 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7077761039 for ; Wed, 27 Oct 2021 23:17:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7077761039 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Hfl3V0k8Lz3gDC for ; Thu, 28 Oct 2021 10:17:58 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=intel-com.20210112.gappssmtp.com header.i=@intel-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=REyhBK6t; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=intel.com (client-ip=2607:f8b0:4864:20::1030; helo=mail-pj1-x1030.google.com; envelope-from=dan.j.williams@intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel-com.20210112.gappssmtp.com header.i=@intel-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=REyhBK6t; dkim-atps=neutral Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Hfkjs0vZ4z3clL for ; Thu, 28 Oct 2021 10:02:38 +1100 (AEDT) Received: by mail-pj1-x1030.google.com with SMTP id na16-20020a17090b4c1000b0019f5bb661f9so3256269pjb.0 for ; Wed, 27 Oct 2021 16:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TIqjtDMduKwUTBKX+tBygnWIDjEpMEr2bhy/yT20mZY=; b=REyhBK6tQZDsAnyKckv+GTqli7ewznlsn87vyBbY5f9febMQ9OwtuAQWJhdicQr38K K1RmGd24wmhycGjPGNyFLV1NcRjXV0YOMJgCvWwD1u2op9FVS5Ne01Ma8I3/7N/vKG+L Nf/tcy6ZTKg9EdZlESmgy/KdDpwwSItb4MeferFvOhl0fHKDs4iLoNdhifCWx1/jKI7k we4R1sn71TU5C2vgTscBN2f7yTZYEbFO4nfi+2G6AAM+9u32OYSh0jX2w1H4FzdcM3Ry 12G6L2JWGDbLkKio2wNGWYlGKXiSVAEj+xqYbUihB4TpfsaefQ6c0TKQ0AY7vxbKpFnC uryw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TIqjtDMduKwUTBKX+tBygnWIDjEpMEr2bhy/yT20mZY=; b=smBe3cYQp360H0U3UtgHKpFBkg/D1E1/abHcKN4GqvJhltHY6zhO3iOLdUPE4VkhLQ hb34B41Tl0rUYBlqwAjGws3JuHDMUMZ5k1iLY1ZxtoC9+oqYXdPLtJqF61E8+mrOL4Y4 QpzdDYqkkKHihA0qtsf/yENG4rYS7s7okLLpq5IIMk9ylPVUS7nQsgY1541Jar2mv1u7 ziCHRM+5dbdxswhPx4wxEeqK23WE2N4qBK5C8mlmgkfVqylqUzPAR2GcA8E6ahSWv+tN 0qB28ySmp/koeWllqtUnH3CZp+G7h8JfltZq727BA6puhgu2iY3cuW4DZT8pNy/yDu/1 FZCg== X-Gm-Message-State: AOAM532MvCli1M8Vvi65yAOIa8YaA8egD5pzCdUheVU9+BFnn06x2/ot h/cNfq7LhGq+hZMOPbd0Rr5ODKqrJ12b4IvW+bjTjA== X-Google-Smtp-Source: ABdhPJxUwYpsZPDBKuNiovYR0U6XMhxIiDSjLBJJ1e6zz5gkWe8hCvGUK6ph3bxfDtcB6AFtR1bn5v1MGpOhiVcMhIY= X-Received: by 2002:a17:90a:a085:: with SMTP id r5mr8858216pjp.8.1635375753946; Wed, 27 Oct 2021 16:02:33 -0700 (PDT) MIME-Version: 1.0 References: <20211018044054.1779424-1-hch@lst.de> <20211018044054.1779424-5-hch@lst.de> In-Reply-To: <20211018044054.1779424-5-hch@lst.de> From: Dan Williams Date: Wed, 27 Oct 2021 16:02:22 -0700 Message-ID: Subject: Re: [PATCH 04/11] dax: remove the pgmap sanity checks in generic_fsdax_supported To: Christoph Hellwig Content-Type: text/plain; charset="UTF-8" X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux NVDIMM , Mike Snitzer , linux-s390 , linux-erofs@lists.ozlabs.org, virtualization@lists.linux-foundation.org, linux-xfs , device-mapper development , linux-fsdevel , linux-ext4 , Ira Weiny Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" On Sun, Oct 17, 2021 at 9:41 PM Christoph Hellwig wrote: > > Drivers that register a dax_dev should make sure it works, no need > to double check from the file system. > > Signed-off-by: Christoph Hellwig > --- > drivers/dax/super.c | 49 +-------------------------------------------- > 1 file changed, 1 insertion(+), 48 deletions(-) > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > index 9383c11b21853..04fc680542e8d 100644 > --- a/drivers/dax/super.c > +++ b/drivers/dax/super.c > @@ -107,13 +107,9 @@ bool generic_fsdax_supported(struct dax_device *dax_dev, > struct block_device *bdev, int blocksize, sector_t start, > sector_t sectors) > { > - bool dax_enabled = false; > pgoff_t pgoff, pgoff_end; > - void *kaddr, *end_kaddr; > - pfn_t pfn, end_pfn; > sector_t last_page; > - long len, len2; > - int err, id; > + int err; > > if (blocksize != PAGE_SIZE) { > pr_info("%pg: error: unsupported blocksize for dax\n", bdev); > @@ -138,49 +134,6 @@ bool generic_fsdax_supported(struct dax_device *dax_dev, > return false; > } > > - id = dax_read_lock(); > - len = dax_direct_access(dax_dev, pgoff, 1, &kaddr, &pfn); > - len2 = dax_direct_access(dax_dev, pgoff_end, 1, &end_kaddr, &end_pfn); > - > - if (len < 1 || len2 < 1) { > - pr_info("%pg: error: dax access failed (%ld)\n", > - bdev, len < 1 ? len : len2); > - dax_read_unlock(id); > - return false; > - } > - > - if (IS_ENABLED(CONFIG_FS_DAX_LIMITED) && pfn_t_special(pfn)) { > - /* > - * An arch that has enabled the pmem api should also > - * have its drivers support pfn_t_devmap() > - * > - * This is a developer warning and should not trigger in > - * production. dax_flush() will crash since it depends > - * on being able to do (page_address(pfn_to_page())). > - */ > - WARN_ON(IS_ENABLED(CONFIG_ARCH_HAS_PMEM_API)); > - dax_enabled = true; > - } else if (pfn_t_devmap(pfn) && pfn_t_devmap(end_pfn)) { > - struct dev_pagemap *pgmap, *end_pgmap; > - > - pgmap = get_dev_pagemap(pfn_t_to_pfn(pfn), NULL); > - end_pgmap = get_dev_pagemap(pfn_t_to_pfn(end_pfn), NULL); > - if (pgmap && pgmap == end_pgmap && pgmap->type == MEMORY_DEVICE_FS_DAX > - && pfn_t_to_page(pfn)->pgmap == pgmap > - && pfn_t_to_page(end_pfn)->pgmap == pgmap > - && pfn_t_to_pfn(pfn) == PHYS_PFN(__pa(kaddr)) > - && pfn_t_to_pfn(end_pfn) == PHYS_PFN(__pa(end_kaddr))) This is effectively a self-test for a regression that was found while manipulating the 'struct page' memmap metadata reservation for PMEM namespaces. I guess it's just serving as a security-blanket now and I should find a way to move it out to a self-test. I'll take a look. > - dax_enabled = true; > - put_dev_pagemap(pgmap); > - put_dev_pagemap(end_pgmap); > - > - } > - dax_read_unlock(id); > - > - if (!dax_enabled) { > - pr_info("%pg: error: dax support not enabled\n", bdev); > - return false; > - } > return true; > } > EXPORT_SYMBOL_GPL(generic_fsdax_supported); > -- > 2.30.2 >