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 us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5B10AC433F5 for ; Fri, 10 Dec 2021 14:09:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639145367; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=MyeftgpK41Om51vs8aE843Wjt/kZFhAJziy3h/Z5tiY=; b=D+VqggJ07usGg/N5zF2unPac3SfxyTicxbiAOOHIPkwHqsiSMzbpNnRI32yKOXicB71im3 c6nA4tc7ce0v5BIziZ0f6MzBwuYlisD1Fi0uYvBEEOY9DXudHRFGE3V/nMZSm66pHIcMVj qtJY/kZKjCasAS9rU9so5a5pG9//55c= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-167-_wuZ5zgiOZ-SrMmB3M5c_Q-1; Fri, 10 Dec 2021 09:09:22 -0500 X-MC-Unique: _wuZ5zgiOZ-SrMmB3M5c_Q-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B543A100CCC2; Fri, 10 Dec 2021 14:09:16 +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 96B9110016F5; Fri, 10 Dec 2021 14:09:14 +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 BEB094BB7C; Fri, 10 Dec 2021 14:09:11 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 1BAE5Tk3003485 for ; Fri, 10 Dec 2021 09:05:29 -0500 Received: by smtp.corp.redhat.com (Postfix) id EB6A4A211; Fri, 10 Dec 2021 14:05:29 +0000 (UTC) Received: from horse.redhat.com (unknown [10.22.17.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7C13919C59; Fri, 10 Dec 2021 14:05:02 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id AC32F2209DD; Fri, 10 Dec 2021 09:05:01 -0500 (EST) Date: Fri, 10 Dec 2021 09:05:01 -0500 From: Vivek Goyal To: Christoph Hellwig Message-ID: References: <20211209063828.18944-1-hch@lst.de> <20211209063828.18944-6-hch@lst.de> MIME-Version: 1.0 In-Reply-To: <20211209063828.18944-6-hch@lst.de> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-loop: dm-devel@redhat.com Cc: nvdimm@lists.linux.dev, linux-s390@vger.kernel.org, Dave Jiang , Vasily Gorbik , Mike Snitzer , Miklos Szeredi , Vishal Verma , Heiko Carstens , Matthew Wilcox , virtualization@lists.linux-foundation.org, Christian Borntraeger , dm-devel@redhat.com, Stefan Hajnoczi , linux-fsdevel@vger.kernel.org, Dan Williams , Ira Weiny , Alasdair Kergon Subject: Re: [dm-devel] [PATCH 5/5] dax: always use _copy_mc_to_iter in dax_copy_to_iter 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.84 on 10.5.11.22 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-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Dec 09, 2021 at 07:38:28AM +0100, Christoph Hellwig wrote: > While using the MC-safe copy routines is rather pointless on a virtual device > like virtiofs, I was wondering about that. Is it completely pointless. Typically we are just mapping host page cache into qemu address space. That shows as virtiofs device pfn in guest and that pfn is mapped into guest application address space in mmap() call. Given on host its DRAM, so I would not expect machine check on load side so there was no need to use machine check safe variant. But what if host filesystem is on persistent memory and using DAX. In that case load in guest can trigger a machine check. Not sure if that machine check will actually travel into the guest and unblock read() operation or not. But this sounds like a good change from virtiofs point of view, anyway. Thanks Vivek > it also isn't harmful at all. So just use _copy_mc_to_iter > unconditionally to simplify the code. > > Signed-off-by: Christoph Hellwig > --- > drivers/dax/super.c | 10 ---------- > fs/fuse/virtio_fs.c | 1 - > include/linux/dax.h | 1 - > 3 files changed, 12 deletions(-) > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > index ff676a07480c8..fe783234ca669 100644 > --- a/drivers/dax/super.c > +++ b/drivers/dax/super.c > @@ -107,8 +107,6 @@ enum dax_device_flags { > DAXDEV_SYNC, > /* do not use uncached operations to write data */ > DAXDEV_CACHED, > - /* do not use mcsafe operations to read data */ > - DAXDEV_NOMCSAFE, > }; > > /** > @@ -171,8 +169,6 @@ size_t dax_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, > * via access_ok() in vfs_red, so use the 'no check' version to bypass > * the HARDENED_USERCOPY overhead. > */ > - if (test_bit(DAXDEV_NOMCSAFE, &dax_dev->flags)) > - return _copy_to_iter(addr, bytes, i); > return _copy_mc_to_iter(addr, bytes, i); > } > > @@ -242,12 +238,6 @@ void set_dax_cached(struct dax_device *dax_dev) > } > EXPORT_SYMBOL_GPL(set_dax_cached); > > -void set_dax_nomcsafe(struct dax_device *dax_dev) > -{ > - set_bit(DAXDEV_NOMCSAFE, &dax_dev->flags); > -} > -EXPORT_SYMBOL_GPL(set_dax_nomcsafe); > - > bool dax_alive(struct dax_device *dax_dev) > { > lockdep_assert_held(&dax_srcu); > diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c > index 754319ce2a29b..d9c20b148ac19 100644 > --- a/fs/fuse/virtio_fs.c > +++ b/fs/fuse/virtio_fs.c > @@ -838,7 +838,6 @@ static int virtio_fs_setup_dax(struct virtio_device *vdev, struct virtio_fs *fs) > if (IS_ERR(fs->dax_dev)) > return PTR_ERR(fs->dax_dev); > set_dax_cached(fs->dax_dev); > - set_dax_nomcsafe(fs->dax_dev); > return devm_add_action_or_reset(&vdev->dev, virtio_fs_cleanup_dax, > fs->dax_dev); > } > diff --git a/include/linux/dax.h b/include/linux/dax.h > index d22cbf03d37d2..d267331bc37e7 100644 > --- a/include/linux/dax.h > +++ b/include/linux/dax.h > @@ -90,7 +90,6 @@ static inline bool daxdev_mapping_supported(struct vm_area_struct *vma, > #endif > > void set_dax_cached(struct dax_device *dax_dev); > -void set_dax_nomcsafe(struct dax_device *dax_dev); > > struct writeback_control; > #if defined(CONFIG_BLOCK) && defined(CONFIG_FS_DAX) > -- > 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14A53C433EF for ; Fri, 10 Dec 2021 14:05:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233620AbhLJOJJ (ORCPT ); Fri, 10 Dec 2021 09:09:09 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:38523 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230463AbhLJOJJ (ORCPT ); Fri, 10 Dec 2021 09:09:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639145133; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1IPYd/U/Ts1tZJpb5JWXIO6VaK+NnfSEAcLoJXiiX6k=; b=U0HVff06h/J7uBSCVm07/LOKCJfS1hbt0NZ+cJG7PweIfXOCa4eNj0if53hwhZhF9sf/4D 15/4sPPPhxPWeKZpTQGUlPw7+/FAV30bHA9Yaq+944rHibssKCrlkl0Xdw3TFawL4ZOFNL rtluFEIQYxXySHN3sKYm2Lmim3lvQlg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-507-AXVHfjlYNN-rOCr5ug7-OA-1; Fri, 10 Dec 2021 09:05:32 -0500 X-MC-Unique: AXVHfjlYNN-rOCr5ug7-OA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ECA031017965; Fri, 10 Dec 2021 14:05:29 +0000 (UTC) Received: from horse.redhat.com (unknown [10.22.17.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7C13919C59; Fri, 10 Dec 2021 14:05:02 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id AC32F2209DD; Fri, 10 Dec 2021 09:05:01 -0500 (EST) Date: Fri, 10 Dec 2021 09:05:01 -0500 From: Vivek Goyal To: Christoph Hellwig Cc: Dan Williams , Vishal Verma , Dave Jiang , Alasdair Kergon , Mike Snitzer , Ira Weiny , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Stefan Hajnoczi , Miklos Szeredi , Matthew Wilcox , dm-devel@redhat.com, nvdimm@lists.linux.dev, linux-s390@vger.kernel.org, linux-fsdevel@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCH 5/5] dax: always use _copy_mc_to_iter in dax_copy_to_iter Message-ID: References: <20211209063828.18944-1-hch@lst.de> <20211209063828.18944-6-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211209063828.18944-6-hch@lst.de> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-s390@vger.kernel.org On Thu, Dec 09, 2021 at 07:38:28AM +0100, Christoph Hellwig wrote: > While using the MC-safe copy routines is rather pointless on a virtual device > like virtiofs, I was wondering about that. Is it completely pointless. Typically we are just mapping host page cache into qemu address space. That shows as virtiofs device pfn in guest and that pfn is mapped into guest application address space in mmap() call. Given on host its DRAM, so I would not expect machine check on load side so there was no need to use machine check safe variant. But what if host filesystem is on persistent memory and using DAX. In that case load in guest can trigger a machine check. Not sure if that machine check will actually travel into the guest and unblock read() operation or not. But this sounds like a good change from virtiofs point of view, anyway. Thanks Vivek > it also isn't harmful at all. So just use _copy_mc_to_iter > unconditionally to simplify the code. > > Signed-off-by: Christoph Hellwig > --- > drivers/dax/super.c | 10 ---------- > fs/fuse/virtio_fs.c | 1 - > include/linux/dax.h | 1 - > 3 files changed, 12 deletions(-) > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > index ff676a07480c8..fe783234ca669 100644 > --- a/drivers/dax/super.c > +++ b/drivers/dax/super.c > @@ -107,8 +107,6 @@ enum dax_device_flags { > DAXDEV_SYNC, > /* do not use uncached operations to write data */ > DAXDEV_CACHED, > - /* do not use mcsafe operations to read data */ > - DAXDEV_NOMCSAFE, > }; > > /** > @@ -171,8 +169,6 @@ size_t dax_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, > * via access_ok() in vfs_red, so use the 'no check' version to bypass > * the HARDENED_USERCOPY overhead. > */ > - if (test_bit(DAXDEV_NOMCSAFE, &dax_dev->flags)) > - return _copy_to_iter(addr, bytes, i); > return _copy_mc_to_iter(addr, bytes, i); > } > > @@ -242,12 +238,6 @@ void set_dax_cached(struct dax_device *dax_dev) > } > EXPORT_SYMBOL_GPL(set_dax_cached); > > -void set_dax_nomcsafe(struct dax_device *dax_dev) > -{ > - set_bit(DAXDEV_NOMCSAFE, &dax_dev->flags); > -} > -EXPORT_SYMBOL_GPL(set_dax_nomcsafe); > - > bool dax_alive(struct dax_device *dax_dev) > { > lockdep_assert_held(&dax_srcu); > diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c > index 754319ce2a29b..d9c20b148ac19 100644 > --- a/fs/fuse/virtio_fs.c > +++ b/fs/fuse/virtio_fs.c > @@ -838,7 +838,6 @@ static int virtio_fs_setup_dax(struct virtio_device *vdev, struct virtio_fs *fs) > if (IS_ERR(fs->dax_dev)) > return PTR_ERR(fs->dax_dev); > set_dax_cached(fs->dax_dev); > - set_dax_nomcsafe(fs->dax_dev); > return devm_add_action_or_reset(&vdev->dev, virtio_fs_cleanup_dax, > fs->dax_dev); > } > diff --git a/include/linux/dax.h b/include/linux/dax.h > index d22cbf03d37d2..d267331bc37e7 100644 > --- a/include/linux/dax.h > +++ b/include/linux/dax.h > @@ -90,7 +90,6 @@ static inline bool daxdev_mapping_supported(struct vm_area_struct *vma, > #endif > > void set_dax_cached(struct dax_device *dax_dev); > -void set_dax_nomcsafe(struct dax_device *dax_dev); > > struct writeback_control; > #if defined(CONFIG_BLOCK) && defined(CONFIG_FS_DAX) > -- > 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 smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 452C4C433EF for ; Fri, 10 Dec 2021 14:05:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 9FFA6411E9; Fri, 10 Dec 2021 14:05:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org 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 lPoLVTMzIpR2; Fri, 10 Dec 2021 14:05:42 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by smtp2.osuosl.org (Postfix) with ESMTPS id E220F411DA; Fri, 10 Dec 2021 14:05:41 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id B67DFC001E; Fri, 10 Dec 2021 14:05:41 +0000 (UTC) Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 02569C0012 for ; Fri, 10 Dec 2021 14:05:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id DEBA284EB3 for ; Fri, 10 Dec 2021 14:05:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvo3dAzu49ot for ; Fri, 10 Dec 2021 14:05:38 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by smtp1.osuosl.org (Postfix) with ESMTPS id C62BD84EAF for ; Fri, 10 Dec 2021 14:05:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639145137; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1IPYd/U/Ts1tZJpb5JWXIO6VaK+NnfSEAcLoJXiiX6k=; b=cmlDa8Qni1skJjwHveQxClTwy6Q0BCc18oDZVEqY6d+UL72ocVp9zyDhLbHoMGaHRfFW8t kmM/UnCHSGdqpdb3NsKyQvqrYN8unffNfo8A9h6boc/piq5s4d+mGBQHtpuVEVUTBj8vV1 CWX89DabyOzuF37bJqYpxtCnCgs23S0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-507-AXVHfjlYNN-rOCr5ug7-OA-1; Fri, 10 Dec 2021 09:05:32 -0500 X-MC-Unique: AXVHfjlYNN-rOCr5ug7-OA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ECA031017965; Fri, 10 Dec 2021 14:05:29 +0000 (UTC) Received: from horse.redhat.com (unknown [10.22.17.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7C13919C59; Fri, 10 Dec 2021 14:05:02 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id AC32F2209DD; Fri, 10 Dec 2021 09:05:01 -0500 (EST) Date: Fri, 10 Dec 2021 09:05:01 -0500 From: Vivek Goyal To: Christoph Hellwig Subject: Re: [PATCH 5/5] dax: always use _copy_mc_to_iter in dax_copy_to_iter Message-ID: References: <20211209063828.18944-1-hch@lst.de> <20211209063828.18944-6-hch@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211209063828.18944-6-hch@lst.de> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Cc: nvdimm@lists.linux.dev, linux-s390@vger.kernel.org, Dave Jiang , Vasily Gorbik , Mike Snitzer , Miklos Szeredi , Vishal Verma , Heiko Carstens , Matthew Wilcox , virtualization@lists.linux-foundation.org, Christian Borntraeger , dm-devel@redhat.com, Stefan Hajnoczi , linux-fsdevel@vger.kernel.org, Dan Williams , Ira Weiny , Alasdair Kergon 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 Thu, Dec 09, 2021 at 07:38:28AM +0100, Christoph Hellwig wrote: > While using the MC-safe copy routines is rather pointless on a virtual device > like virtiofs, I was wondering about that. Is it completely pointless. Typically we are just mapping host page cache into qemu address space. That shows as virtiofs device pfn in guest and that pfn is mapped into guest application address space in mmap() call. Given on host its DRAM, so I would not expect machine check on load side so there was no need to use machine check safe variant. But what if host filesystem is on persistent memory and using DAX. In that case load in guest can trigger a machine check. Not sure if that machine check will actually travel into the guest and unblock read() operation or not. But this sounds like a good change from virtiofs point of view, anyway. Thanks Vivek > it also isn't harmful at all. So just use _copy_mc_to_iter > unconditionally to simplify the code. > > Signed-off-by: Christoph Hellwig > --- > drivers/dax/super.c | 10 ---------- > fs/fuse/virtio_fs.c | 1 - > include/linux/dax.h | 1 - > 3 files changed, 12 deletions(-) > > diff --git a/drivers/dax/super.c b/drivers/dax/super.c > index ff676a07480c8..fe783234ca669 100644 > --- a/drivers/dax/super.c > +++ b/drivers/dax/super.c > @@ -107,8 +107,6 @@ enum dax_device_flags { > DAXDEV_SYNC, > /* do not use uncached operations to write data */ > DAXDEV_CACHED, > - /* do not use mcsafe operations to read data */ > - DAXDEV_NOMCSAFE, > }; > > /** > @@ -171,8 +169,6 @@ size_t dax_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr, > * via access_ok() in vfs_red, so use the 'no check' version to bypass > * the HARDENED_USERCOPY overhead. > */ > - if (test_bit(DAXDEV_NOMCSAFE, &dax_dev->flags)) > - return _copy_to_iter(addr, bytes, i); > return _copy_mc_to_iter(addr, bytes, i); > } > > @@ -242,12 +238,6 @@ void set_dax_cached(struct dax_device *dax_dev) > } > EXPORT_SYMBOL_GPL(set_dax_cached); > > -void set_dax_nomcsafe(struct dax_device *dax_dev) > -{ > - set_bit(DAXDEV_NOMCSAFE, &dax_dev->flags); > -} > -EXPORT_SYMBOL_GPL(set_dax_nomcsafe); > - > bool dax_alive(struct dax_device *dax_dev) > { > lockdep_assert_held(&dax_srcu); > diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c > index 754319ce2a29b..d9c20b148ac19 100644 > --- a/fs/fuse/virtio_fs.c > +++ b/fs/fuse/virtio_fs.c > @@ -838,7 +838,6 @@ static int virtio_fs_setup_dax(struct virtio_device *vdev, struct virtio_fs *fs) > if (IS_ERR(fs->dax_dev)) > return PTR_ERR(fs->dax_dev); > set_dax_cached(fs->dax_dev); > - set_dax_nomcsafe(fs->dax_dev); > return devm_add_action_or_reset(&vdev->dev, virtio_fs_cleanup_dax, > fs->dax_dev); > } > diff --git a/include/linux/dax.h b/include/linux/dax.h > index d22cbf03d37d2..d267331bc37e7 100644 > --- a/include/linux/dax.h > +++ b/include/linux/dax.h > @@ -90,7 +90,6 @@ static inline bool daxdev_mapping_supported(struct vm_area_struct *vma, > #endif > > void set_dax_cached(struct dax_device *dax_dev); > -void set_dax_nomcsafe(struct dax_device *dax_dev); > > struct writeback_control; > #if defined(CONFIG_BLOCK) && defined(CONFIG_FS_DAX) > -- > 2.30.2 > _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization