Re: [PATCH v2 00/12] gendisk: Generate uevent after attribute available

On Thu, Jun 30, 2016 at 6:01 PM, Fam Zheng wrote: > On Wed, 06/29 23:38, Christoph Hellwig wrote: >> On Thu, Jun 30, 2016 at 02:35:54PM +0800, Fam Zheng wrote: >> > also more code and less flexible IMO. For example, we need at least two >> > variants, for attribute_group and

Re: [PATCH v2 04/12] axonrom: Generate uevent after attribute available

On Wed, Jun 29, 2016 at 6:59 PM, Fam Zheng wrote: > It is documented that KOBJ_ADD should be generated after the object's > attributes and children are ready. We can achieve this with the new > disk_gen_uevents interface. > > Signed-off-by: Fam Zheng > --- >

Re: [RFC] virtio-mem: paravirtualized memory

On Fri, Jul 28, 2017 at 4:09 AM, David Hildenbrand wrote: > Btw, I am thinking about the following addition to the concept: > > 1. Add a type to each virtio-mem device. > > This describes the type of the memory region we expose to the guest. > Initially, we could have RAM and

Re: [PATCH v3 0/5] kvm "virtio pmem" device

On Mon, Jan 14, 2019 at 1:25 PM Dave Chinner wrote: > > On Mon, Jan 14, 2019 at 02:15:40AM -0500, Pankaj Gupta wrote: > > > > > > Until you have images (and hence host page cache) shared between > > > > multiple guests. People will want to do this, because it means they > > > > only need a single

Re: [PATCH v3 0/5] kvm "virtio pmem" device

On Sat, Jan 12, 2019 at 5:38 PM Pankaj Gupta wrote: > > > > > > > On Thu 10-01-19 12:26:17, Dave Chinner wrote: > > > On Wed, Jan 09, 2019 at 08:17:31PM +0530, Pankaj Gupta wrote: > > > > This patch series has implementation for "virtio pmem". > > > > "virtio pmem" is fake persistent

Re: [RFC PATCH V3 0/5] Hi:

On Mon, Jan 7, 2019 at 6:11 AM Michael S. Tsirkin wrote: > > On Sun, Jan 06, 2019 at 11:15:20PM -0800, Dan Williams wrote: > > On Sun, Jan 6, 2019 at 8:17 PM Michael S. Tsirkin wrote: > > > > > > On Mon, Jan 07, 2019 at 11:53:41AM +0800, Jason Wang wrote: >

Re: [RFC PATCH V3 0/5] Hi:

On Mon, Jan 7, 2019 at 2:25 PM Michael S. Tsirkin wrote: > > On Mon, Jan 07, 2019 at 01:39:15PM -0800, Dan Williams wrote: > > On Mon, Jan 7, 2019 at 6:11 AM Michael S. Tsirkin wrote: > > > > > > On Sun, Jan 06, 2019 at 11:15:20PM -0800, Dan Williams wrote: > >

Re: [PATCH v3 3/5] libnvdimm: add nd_region buffered dax_dev flag

On Wed, Jan 9, 2019 at 5:53 AM Pankaj Gupta wrote: > > This patch adds 'DAXDEV_BUFFERED' flag which is set > for virtio pmem corresponding nd_region. This later > is used to disable MAP_SYNC functionality for ext4 > & xfs filesystem. > > Signed-off-by: Pankaj Gupta > --- > drivers/dax/super.c

Re: [RFC PATCH V3 0/5] Hi:

_begin_nospec introduced by > commit 304ec1b050310548db33063e567123fae8fd0301 > ? > > So fundamentally we do access_ok checks when supplying > the memory table to the kernel thread, and we should > do the spec barrier there. > > Then we can just create and use a varian

Re: [PATCH v5 1/6] libnvdimm: nd_region flush callback support

On Tue, Apr 9, 2019 at 9:09 PM Pankaj Gupta wrote: > > This patch adds functionality to perform flush from guest > to host over VIRTIO. We are registering a callback based > on 'nd_region' type. virtio_pmem driver requires this special > flush function. For rest of the region types we are

Re: [Qemu-devel] [PATCH v5 1/6] libnvdimm: nd_region flush callback support

ayer > > > by creating a child bio and chaining it with parent bio. > > > > > > Signed-off-by: Pankaj Gupta > > > ---bio_chain Dan williams > > [..] > > > diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c > > > index b4ef7d

Re: [PATCH v5 3/6] libnvdimm: add dax_dev sync flag

On Tue, Apr 9, 2019 at 9:10 PM Pankaj Gupta wrote: > > This patch adds 'DAXDEV_SYNC' flag which is set > for nd_region doing synchronous flush. This later > is used to disable MAP_SYNC functionality for > ext4 & xfs filesystem for devices don't support > synchronous flush. > > Signed-off-by:

Re: [PATCH v9 4/7] dm: enable synchronous dax

[ add Mike and dm-devel ] Mike, any concerns with the below addition to the device-mapper-dax implementation? On Tue, May 14, 2019 at 7:58 AM Pankaj Gupta wrote: > > This patch sets dax device 'DAXDEV_SYNC' flag if all the target > devices of device mapper support synchrononous DAX. If device

Re: [Qemu-devel] [PATCH v9 2/7] virtio-pmem: Add virtio pmem driver

On Tue, May 14, 2019 at 8:25 AM Pankaj Gupta wrote: > > > > On 5/14/19 7:54 AM, Pankaj Gupta wrote: > > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig > > > index 35897649c24f..94bad084ebab 100644 > > > --- a/drivers/virtio/Kconfig > > > +++ b/drivers/virtio/Kconfig > > > @@ -42,6

Re: [PATCH v9 1/7] libnvdimm: nd_region flush callback support

On Tue, May 14, 2019 at 7:55 AM Pankaj Gupta wrote: > > This patch adds functionality to perform flush from guest > to host over VIRTIO. We are registering a callback based > on 'nd_region' type. virtio_pmem driver requires this special > flush function. For rest of the region types we are

Re: [PATCH v10 4/7] dm: enable synchronous dax

On Tue, May 21, 2019 at 6:43 AM Pankaj Gupta wrote: > > This patch sets dax device 'DAXDEV_SYNC' flag if all the target > devices of device mapper support synchrononous DAX. If device > mapper consists of both synchronous and asynchronous dax devices, > we don't set 'DAXDEV_SYNC' flag. > >

Re: [PATCH v8 0/6] virtio pmem driver

On Fri, May 10, 2019 at 8:52 AM Pankaj Gupta wrote: > > Hi Michael & Dan, > > Please review/ack the patch series from LIBNVDIMM & VIRTIO side. > We have ack on ext4, xfs patches(4, 5 & 6) patch 2. Still need > your ack on nvdimm patches(1 & 3) & virtio patch 2. I was planning to merge these

Re: [PATCH v8 3/6] libnvdimm: add dax_dev sync flag

On Fri, May 10, 2019 at 8:53 AM Pankaj Gupta wrote: > > This patch adds 'DAXDEV_SYNC' flag which is set > for nd_region doing synchronous flush. This later > is used to disable MAP_SYNC functionality for > ext4 & xfs filesystem for devices don't support > synchronous flush. > > Signed-off-by:

Re: [Qemu-devel] [PATCH v7 2/6] virtio-pmem: Add virtio pmem driver

On Wed, May 8, 2019 at 4:19 AM Pankaj Gupta wrote: > > > Hi Dan, > > Thank you for the review. Please see my reply inline. > > > > > Hi Pankaj, > > > > Some minor file placement comments below. > > Sure. > > > > > On Thu, Apr 25, 2019 at 10:02 PM Pankaj Gupta wrote: > > > > > > This patch adds

Re: [PATCH v8 3/6] libnvdimm: add dax_dev sync flag

On Fri, May 10, 2019 at 5:45 PM Pankaj Gupta wrote: > > > > > > > > > This patch adds 'DAXDEV_SYNC' flag which is set > > > for nd_region doing synchronous flush. This later > > > is used to disable MAP_SYNC functionality for > > > ext4 & xfs filesystem for devices don't support > > > synchronous

Re: [Qemu-devel] [PATCH v8 3/6] libnvdimm: add dax_dev sync flag

On Mon, May 13, 2019 at 10:32 AM Pankaj Gupta wrote: > > > Hi Dan, > > While testing device mapper with DAX, I faced a bug with the commit: > > commit ad428cdb525a97d15c0349fdc80f3d58befb50df > Author: Dan Williams > Date: Wed Feb 20 21:12:50 2019 -0800 > > Whe

Re: [PATCH v7 6/6] xfs: disable map_sync for async flush

On Thu, Apr 25, 2019 at 10:03 PM Pankaj Gupta wrote: > > Dont support 'MAP_SYNC' with non-DAX files and DAX files > with asynchronous dax_device. Virtio pmem provides > asynchronous host page cache flush mechanism. We don't > support 'MAP_SYNC' with virtio pmem and xfs. > > Signed-off-by: Pankaj

Re: [PATCH v7 2/6] virtio-pmem: Add virtio pmem driver

Hi Pankaj, Some minor file placement comments below. On Thu, Apr 25, 2019 at 10:02 PM Pankaj Gupta wrote: > > This patch adds virtio-pmem driver for KVM guest. > > Guest reads the persistent memory range information from > Qemu over VIRTIO and registers it on nvdimm_bus. It also > creates a

Re: [PATCH v7 3/6] libnvdimm: add dax_dev sync flag

On Thu, Apr 25, 2019 at 10:02 PM Pankaj Gupta wrote: > > This patch adds 'DAXDEV_SYNC' flag which is set > for nd_region doing synchronous flush. This later > is used to disable MAP_SYNC functionality for > ext4 & xfs filesystem for devices don't support > synchronous flush. > > Signed-off-by:

Re: [PATCH v5 1/6] libnvdimm: nd_region flush callback support

On Fri, Apr 12, 2019 at 6:12 AM Jeff Moyer wrote: > > Jan Kara writes: > > > On Thu 11-04-19 07:51:48, Dan Williams wrote: > >> On Tue, Apr 9, 2019 at 9:09 PM Pankaj Gupta wrote: > >> > + } else { > >> > + if (nd_region->

Re: [PATCH v5 1/6] libnvdimm: nd_region flush callback support

On Thu, Apr 18, 2019 at 9:18 AM Christoph Hellwig wrote: > > On Thu, Apr 18, 2019 at 09:05:05AM -0700, Dan Williams wrote: > > > > I'd either add a comment about avoiding retpoline overhead here or just > > > > make ->flush == NULL mean generic_nvdimm_flush(). J

Re: [PATCH v5 1/6] libnvdimm: nd_region flush callback support

On Mon, Apr 22, 2019 at 8:59 AM Jeff Moyer wrote: > > Dan Williams writes: > > > On Thu, Apr 18, 2019 at 9:18 AM Christoph Hellwig > > wrote: > >> > >> On Thu, Apr 18, 2019 at 09:05:05AM -0700, Dan Williams wrote: > >> > > > I'd ei

Re: [PATCH v3] virtio_pmem: fix sparse warning

On Fri, Jul 12, 2019 at 7:11 AM Michael S. Tsirkin wrote: > > On Fri, Jul 12, 2019 at 10:46:10AM +0530, Pankaj Gupta wrote: > > This patch fixes below sparse warning related to __virtio > > type in virtio pmem driver. This is reported by Intel test > > bot on linux-next tree. > > > >

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

On Thu, Apr 30, 2020 at 11:44 AM David Hildenbrand wrote: > > >>> If the class of memory is different then please by all means let's mark > >>> it differently in struct resource so everyone knows it is different. > >>> But that difference needs to be more than hotplug. > >>> > >>> That

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

On Fri, May 1, 2020 at 12:18 PM David Hildenbrand wrote: > > On 01.05.20 20:43, Dan Williams wrote: > > On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote: > >> > >> On 01.05.20 20:03, Dan Williams wrote: > >>> On Fri, May 1, 2020 a

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote: > > On 01.05.20 19:45, David Hildenbrand wrote: > > On 01.05.20 19:39, Dan Williams wrote: > >> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote: > >>> > >>> On 01.05.20 18:56, Dan Willi

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

On Fri, May 1, 2020 at 11:14 AM David Hildenbrand wrote: > > On 01.05.20 20:03, Dan Williams wrote: > > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand wrote: > >> > >> On 01.05.20 19:45, David Hildenbrand wrote: > >>> On 01.05.20 19:39, Dan Williams

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

On Fri, May 1, 2020 at 2:11 PM David Hildenbrand wrote: > > On 01.05.20 22:12, Dan Williams wrote: [..] > >>> Consider the case of EFI Special Purpose (SP) Memory that is > >>> marked EFI Conventional Memory with the SP attribute. In that case the &g

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

On Sat, May 2, 2020 at 2:27 AM David Hildenbrand wrote: > > >> Now, let's clarify what I want regarding virtio-mem: > >> > >> 1. kexec should not add virtio-mem memory to the initial firmware > >>memmap. The driver has to be in charge as discussed. > >> 2. kexec should not place kexec images

Re: [PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED

On Thu, Apr 30, 2020 at 12:20 AM David Hildenbrand wrote: > > On 29.04.20 18:08, David Hildenbrand wrote: > > Some paravirtualized devices that add memory via add_memory() and > > friends (esp. virtio-mem) don't want to create entries in > > /sys/firmware/memmap/ - primarily to hinder kexec from

Re: [PATCH v1 2/3] mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED

On Thu, Apr 30, 2020 at 1:21 AM David Hildenbrand wrote: > >> Just because we decided to use some DAX memory in the current kernel as > >> system ram, doesn't mean we should make that decision for the kexec > >> kernel (e.g., using it as initial memory, placing kexec binaries onto > >> it, etc.).

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

On Fri, May 1, 2020 at 10:21 AM David Hildenbrand wrote: > > On 01.05.20 18:56, Dan Williams wrote: > > On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote: > >> > >> On 01.05.20 00:24, Andrew Morton wrote: > >>> On Thu, 30 Apr 2020 20:4

Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP

On Fri, May 1, 2020 at 2:34 AM David Hildenbrand wrote: > > On 01.05.20 00:24, Andrew Morton wrote: > > On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand > > wrote: > > > >>> > >>> Why does the firmware map support hotplug entries? > >> > >> I assume: > >> > >> The firmware memmap was added

Re: [RFC] treewide: cleanup unreachable breaks

/claim.c > +++ b/drivers/nvdimm/claim.c > @@ -200,11 +200,10 @@ ssize_t nd_namespace_store(struct device *dev, > } > break; > default: > len = -EBUSY; > goto out_attach; > - break; > } Acked-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH mlx5-next v1 06/11] vdpa/mlx5: Connect mlx5_vdpa to auxiliary bus

On Tue, Nov 3, 2020 at 7:45 AM Jason Gunthorpe wrote: [..] > > +MODULE_DEVICE_TABLE(auxiliary, mlx5v_id_table); > > + > > +static struct auxiliary_driver mlx5v_driver = { > > + .name = "vnet", > > + .probe = mlx5v_probe, > > + .remove = mlx5v_remove, > > + .id_table =

Re: [PATCH mlx5-next v1 06/11] vdpa/mlx5: Connect mlx5_vdpa to auxiliary bus

On Wed, Nov 4, 2020 at 11:32 PM gregkh wrote: > > On Wed, Nov 04, 2020 at 03:21:23PM -0800, Dan Williams wrote: > > On Tue, Nov 3, 2020 at 7:45 AM Jason Gunthorpe wrote: > > [..] > > > > +MODULE_DEVICE_TABLE(auxiliary, mlx5v_id_table); > > > >

Re: [RFC v2 PATCH 4/4] mm: pre zero out free pages to speed up page allocation for __GFP_ZERO

On Mon, Jan 4, 2021 at 12:11 PM David Hildenbrand wrote: > > > > Am 04.01.2021 um 20:52 schrieb Dave Hansen : > > > > On 1/4/21 11:27 AM, Matthew Wilcox wrote: > >>> On Mon, Jan 04, 2021 at 11:19:13AM -0800, Dave Hansen wrote: > >>> On 12/21/20 8:30 AM, Liang Li wrote: > ---

Re: [RFC v2 PATCH 4/4] mm: pre zero out free pages to speed up page allocation for __GFP_ZERO

On Mon, Jan 4, 2021 at 11:28 AM Matthew Wilcox wrote: > > On Mon, Jan 04, 2021 at 11:19:13AM -0800, Dave Hansen wrote: > > On 12/21/20 8:30 AM, Liang Li wrote: > > > --- a/include/linux/page-flags.h > > > +++ b/include/linux/page-flags.h > > > @@ -137,6 +137,9 @@ enum pageflags { > > > #endif >

Re: [PATCH v2 4/4] bus: Make remove callback return void

mented buses return an ignored error code and so don't anticipate > wrong expectations for driver authors. > > drivers/cxl/core.c| 3 +-- > drivers/dax/bus.c | 4 +--- > drivers/nvdimm/bus.c | 3 +-

Re: [PATCH v2 1/3] /dev/mem: disallow access to explicitly excluded system RAM regions

On Mon, Aug 16, 2021 at 7:25 AM David Hildenbrand wrote: > > virtio-mem dynamically exposes memory inside a device memory region as > system RAM to Linux, coordinating with the hypervisor which parts are > actually "plugged" and consequently usable/accessible. On the one hand, the > virtio-mem

Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}

On Tue, Aug 24, 2021 at 2:57 PM Rajat Jain wrote: > > On Mon, Aug 23, 2021 at 6:06 PM Dan Williams wrote: > > > > On Mon, Aug 23, 2021 at 5:31 PM Kuppuswamy, Sathyanarayanan > > wrote: > > > > > > > > > > > > On 8/23/21 4:56 PM, Micha

Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}

On Tue, Aug 24, 2021 at 1:50 PM Andi Kleen wrote: > > > On 8/24/2021 1:31 PM, Bjorn Helgaas wrote: > > On Tue, Aug 24, 2021 at 01:14:02PM -0700, Andi Kleen wrote: > >> On 8/24/2021 11:55 AM, Bjorn Helgaas wrote: > >>> [+cc Rajat; I still don't know what "shared memory with a hypervisor > >>> in a

Re: [PATCH v4 11/15] pci: Add pci_iomap_shared{,_range}

On Mon, Aug 23, 2021 at 5:31 PM Kuppuswamy, Sathyanarayanan wrote: > > > > On 8/23/21 4:56 PM, Michael S. Tsirkin wrote: > >> Add a new variant of pci_iomap for mapping all PCI resources > >> of a devices as shared memory with a hypervisor in a confidential > >> guest. > >> > >> Signed-off-by:

Re: [PATCH v2 1/3] /dev/mem: disallow access to explicitly excluded system RAM regions

On Wed, Aug 25, 2021 at 12:23 AM David Hildenbrand wrote: > > On 25.08.21 02:58, Dan Williams wrote: > > On Mon, Aug 16, 2021 at 7:25 AM David Hildenbrand wrote: > >> > >> virtio-mem dynamically exposes memory inside a device memory region as > >

Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range()

On Tue, Oct 12, 2021 at 11:57 AM Reshetova, Elena wrote: > > > > I suspect the true number is even higher because that doesn't include IO > > inside calls to other modules and indirect pointers, correct? > > Actually everything should be included. Smatch has cross-function db and > I am using it

Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range()

On Sat, Oct 9, 2021 at 2:53 AM Michael S. Tsirkin wrote: > > On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan wrote: > > From: Andi Kleen > > > > For Confidential VM guests like TDX, the host is untrusted and hence > > the devices emulated by the host or any data coming from

Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range()

On Sun, Oct 10, 2021 at 3:11 PM Andi Kleen wrote: > > > On 10/9/2021 1:39 PM, Dan Williams wrote: > > On Sat, Oct 9, 2021 at 2:53 AM Michael S. Tsirkin wrote: > >> On Fri, Oct 08, 2021 at 05:37:07PM -0700, Kuppuswamy Sathyanarayanan wrote: > >>> From: Andi Kl

Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range()

On Tue, Oct 12, 2021 at 11:35 AM Andi Kleen wrote: > > > > The "better safe-than-sorry" argument is hard to build consensus > > around. The spectre mitigations ran into similar problems where the > > community rightly wanted to see the details and instrument the > > problematic paths rather than

Re: [PATCH v5 12/16] PCI: Add pci_iomap_host_shared(), pci_iomap_host_shared_range()

On Tue, Oct 12, 2021 at 2:28 PM Andi Kleen wrote: [..] > >> But how do you debug the kernel then? Making early undebuggable seems > >> just bad policy to me. > > I am not proposing making the early undebuggable. > > > That's the implication of moving the policy into initrd. > > > If only initrd

Re: [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core

On Wed, Sep 29, 2021 at 7:39 PM Kuppuswamy, Sathyanarayanan wrote: > > > > On 9/29/21 6:55 PM, Dan Williams wrote: > >> Also, you ignored the usb_[de]authorize_interface() functions and > >> their friends. > > Ugh, yes. > > I did not change it because I

Re: [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core

reated as bool value. So when converting the authorized > > attribute from int to bool value, there should be no functional > > changes other than value 2 being not visible to the user. > > > > [1]: > > https://lore.kernel.org/all/CACK8Z6E8pjVeC934oFgr=vb3p

Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest

gt; > arrange for all devices to default to unauthorized (via > > dev_default_authorization) in device_initialize(). Since virtio > > driver is already hardened against the attack from the un-trusted host, > > override the confidential computing default unauthorized state >

Re: [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core

On Thu, Sep 30, 2021 at 8:00 AM Alan Stern wrote: > > On Wed, Sep 29, 2021 at 06:55:12PM -0700, Dan Williams wrote: > > On Wed, Sep 29, 2021 at 6:43 PM Alan Stern > > wrote: > > > > > > On Wed, Sep 29, 2021 at 06:05:06PM -0700, Kuppuswamy Sathyanarayanan

Re: [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core

On Thu, Sep 30, 2021 at 4:20 AM Yehezkel Bernat wrote: > > On Thu, Sep 30, 2021 at 4:05 AM Kuppuswamy Sathyanarayanan > wrote: > > > > no functional > > changes other than value 2 being not visible to the user. > > > > Are we sure we don't break any user-facing tool with it? Tools might use this

Re: [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core

On Thu, Sep 30, 2021 at 12:50 PM Kuppuswamy, Sathyanarayanan wrote: > > > > On 9/30/21 12:04 PM, Dan Williams wrote: > >>> That's why it was highlighted in the changelog. Hopefully a > >>> Thunderbolt developer can confirm if it is a non-issue. >

Re: [PATCH v2 1/6] driver core: Move the "authorized" attribute from USB/Thunderbolt to core

On Thu, Sep 30, 2021 at 11:25 AM Yehezkel Bernat wrote: > > On Thu, Sep 30, 2021 at 6:28 PM Dan Williams wrote: > > > > On Thu, Sep 30, 2021 at 4:20 AM Yehezkel Bernat > > wrote: > > > > > > On Thu, Sep 30, 2021 at 4:05 AM Kuppuswamy Sathyanarayanan &

Re: [PATCH v2 2/6] driver core: Add common support to skip probe for un-authorized devices

On Thu, Sep 30, 2021 at 1:44 PM Alan Stern wrote: > > On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen wrote: > > > > > I don't think the current mitigations under discussion here are about > > > keeping the system working. In fact most encrypted VM configs tend to > > > stop booting as a

Re: [PATCH v2 2/6] driver core: Add common support to skip probe for un-authorized devices

On Thu, Sep 30, 2021 at 6:41 PM Alan Stern wrote: > > On Thu, Sep 30, 2021 at 01:52:59PM -0700, Dan Williams wrote: > > On Thu, Sep 30, 2021 at 1:44 PM Alan Stern > > wrote: > > > > > > On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen wrote: > &g

Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest

amy, Sathyanarayanan > > > wrote: > > > > > > > > > > > > On 9/30/21 6:36 AM, Dan Williams wrote: > > > > > > And in particular, not all virtio drivers are hardened - > > > > > > I think at this point blk and scsi drivers have be

Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest

On Fri, Oct 1, 2021 at 12:02 PM Alan Stern wrote: > > On Fri, Oct 01, 2021 at 11:09:52AM -0700, Dan Williams wrote: > > On Fri, Oct 1, 2021 at 9:47 AM Alan Stern wrote: > > > > > > On Fri, Oct 01, 2021 at 09:13:54AM -0700, Dan Williams wrote: > > >

Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest

On Fri, Oct 1, 2021 at 9:47 AM Alan Stern wrote: > > On Fri, Oct 01, 2021 at 09:13:54AM -0700, Dan Williams wrote: > > Bear with me, and perhaps it's a lack of imagination on my part, but I > > don't see how to get to a globally generic "authorized" sysfs ABI > &

Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest

On Sat, Oct 2, 2021 at 7:20 AM Andi Kleen wrote: > > > On 10/2/2021 4:14 AM, Greg Kroah-Hartman wrote: > > On Sat, Oct 02, 2021 at 07:04:28AM -0400, Michael S. Tsirkin wrote: > >> On Fri, Oct 01, 2021 at 08:49:28AM -0700, Andi Kleen wrote: > Do you have a list of specific drivers and

Re: [PATCH v2 4/6] virtio: Initialize authorized attribute for confidential guest

On Sun, Oct 3, 2021 at 10:16 PM Mika Westerberg wrote: > > Hi, > > On Fri, Oct 01, 2021 at 12:57:18PM -0700, Dan Williams wrote: > > > > Ah, so are you saying that it would be sufficient for USB if the > > > > generic authorized implementation did something l

Re: [PATCH 05/29] dax: remove the pgmap sanity checks in generic_fsdax_supported

On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > Drivers that register a dax_dev should make sure it works, no need > to double check from the file system. Reviewed-by: Dan Williams ...with a self-reminder to migrate this validation to a unit test to backstop any future re

Re: [PATCH 11/29] dm-stripe: add a stripe_dax_pgoff helper

ted. > > Signed-off-by: Christoph Hellwig > Acked-by: Mike Snitzer Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 12/29] fsdax: remove a pointless __force cast in copy_cow_page_dax

On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Despite its name copy_user_page expected kernel addresses, which is what > we already have. Yup, Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@li

Re: [PATCH 02/29] dm: make the DAX support dependend on CONFIG_FS_DAX

On Thu, Nov 18, 2021 at 10:55 PM Christoph Hellwig wrote: > > On Wed, Nov 17, 2021 at 09:23:44AM -0800, Dan Williams wrote: > > Applied, fixed the spelling of 'dependent' in the subject and picked > > up Mike's Ack from the previous send: > > > > https://l

Re: [PATCH 03/29] dax: remove CONFIG_DAX_DRIVER

On Wed, Nov 17, 2021 at 9:43 AM Dan Williams wrote: > > On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > > > CONFIG_DAX_DRIVER only selects CONFIG_DAX now, so remove it. > > Applied. Unapplied, R

Re: [PATCH 04/29] dax: simplify the dax_device <-> gendisk association

On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > Replace the dax_host_hash with an xarray indexed by the pointer value > of the gendisk, and require explicitly calls from the block drivers that > want to associate their gendisk with a dax_device. > > Signed-off-by: Christoph Hellwig

Re: [PATCH 10/29] dm-log-writes: add a log_writes_dax_pgoff helper

ted. > > Signed-off-by: Christoph Hellwig > Acked-by: Mike Snitzer Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 06/29] dax: move the partition alignment check into fs_dax_get_by_bdev

On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > fs_dax_get_by_bdev is the primary interface to find a dax device for a > block device, so move the partition alignment check there instead of > wiring it up through ->dax_supported. > Reviewe

Re: [PATCH 08/29] dax: remove dax_capable

B-P7TQMD6M-0146.local ...and Darrick's https://lore.kernel.org/r/20211019154447.GL24282@magnolia ...which had a few more review comments below, otherwise you can also add: Reviewed-by: Dan Williams > --- > drivers/dax/super.c | 36 >

Re: [PATCH 09/29] dm-linear: add a linear_dax_pgoff helper

ted. > > Signed-off-by: Christoph Hellwig > Acked-by: Mike Snitzer Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 07/29] xfs: factor out a xfs_setup_dax_always helper

On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > Factor out another DAX setup helper to simplify future changes. Also > move the experimental warning after the checks to not clutter the log > too much if the setup failed. > > Signed-off-by: Christoph Hellwig

Re: [PATCH 13/29] fsdax: use a saner calling convention for copy_cow_page_dax

On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > Just pass the vm_fault and iomap_iter structures, and figure out the rest > locally. Note that this requires moving dax_iomap_sector up in the file. Looks good, Reviewed-by: Dan Williams > > Signed-off-by: Ch

Re: [PATCH 14/29] fsdax: simplify the pgoff calculation

On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > Replace the two steps of dax_iomap_sector and bdev_dax_pgoff with a > single dax_iomap_pgoff helper that avoids lots of cumbersome sector > conversions. Looks good, Reviewed-by: Dan Williams > > Signed-off-by:

Re: [PATCH 20/29] ext4: cleanup the dax handling in ext4_fill_super

On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Only call fs_dax_get_by_bdev once the sbi has been allocated and remove > the need for the dax_dev local variable. Looks good. Reviewed-by: Dan Williams ___ Virtualization mai

Re: [PATCH 18/29] fsdax: decouple zeroing from the iomap buffered I/O code

callers. Most callers already have DAX special casing anyway > and XFS will need it for reflink support as well. Looks ok, a tangential question below about iomap_truncate_page(), but you can add: Reviewed-by: Dan Williams > > Signed-off-by: Christoph Hellwig > --- >

Re: [PATCH 19/29] ext2: cleanup the dax handling in ext2_fill_super

On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Only call fs_dax_get_by_bdev once the sbi has been allocated and remove > the need for the dax_dev local variable. Looks good. Reviewed-by: Dan Williams ___ Virtualization mai

Re: [PATCH 29/29] fsdax: don't require CONFIG_BLOCK

On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > The file system DAX code now does not require the block code. So allow > building a kernel with fuse DAX but not block layer. Looks good to me. Reviewed-by: Dan Williams ___ Virtu

Re: [PATCH 26/29] fsdax: shift partition offset handling into the file systems

On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Remove the last user of ->bdev in dax.c by requiring the file system to > pass in an address that already includes the DAX offset. As part of the > only set ->bdev or ->daxdev when actually required in the ->iomap_begin > methods.

Re: [PATCH 27/29] dax: fix up some of the block device related ifdefs

On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > The DAX device <-> block device association is only enabled if > CONFIG_BLOCK is enabled. Update dax.h to account for that and use > the right conditions for the fs_put_dax stub as well. Looks good to me. Reviewe

Re: [PATCH 28/29] iomap: build the block based code conditionally

On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Only build the block based iomap code if CONFIG_BLOCK is set. Currently > that is always the case, but it will change soon. Looks good. Reviewed-by: Dan Williams ___ Virtualizatio

Re: [PATCH 16/29] fsdax: simplify the offset check in dax_iomap_zero

On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > The file relative offset must have the same alignment as the storage > offset, so use that and get rid of the call to iomap_sector. Agree. Reviewed-by: Dan Williams ___ Virtu

Re: [PATCH 15/29] xfs: add xfs_zero_range and xfs_truncate_page helpers

ks good to me. Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 04/29] dax: simplify the dax_device <-> gendisk association

On Mon, Nov 22, 2021 at 9:58 PM Christoph Hellwig wrote: > > On Mon, Nov 22, 2021 at 07:33:06PM -0800, Dan Williams wrote: > > Is it time to add a "DAX" symbol namespace? > > What would be the benefit? Just the small benefit of identifying DAX core users with a commo

Re: [PATCH 17/29] fsdax: factor out a dax_memzero helper

On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Factor out a helper for the "manual" zeroing of a DAX range to clean > up dax_iomap_zero a lot. > Small / optional fixup below: Reviewed-by: Dan Williams > Signed-off-by: Christoph Hellwi

Re: [PATCH 03/29] dax: remove CONFIG_DAX_DRIVER

On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > CONFIG_DAX_DRIVER only selects CONFIG_DAX now, so remove it. Applied. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org

Re: [PATCH 01/29] nvdimm/pmem: move dax_attribute_group from dax to pmem

the same ifdef block as that caller. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Dan Williams > Link: https://lore.kernel.org/r/20210922173431.2454024-3-...@lst.de > Signed-off-by: Dan Williams This one already made v5.16-rc1. _

Re: [PATCH 02/29] dm: make the DAX support dependend on CONFIG_FS_DAX

On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > The device mapper DAX support is all hanging off a block device and thus > can't be used with device dax. Make it depend on CONFIG_FS_DAX instead > of CONFIG_DAX_DRIVER. This also means that bdev_dax_pgoff only needs to > be built

Re: [PATCH 01/29] nvdimm/pmem: move dax_attribute_group from dax to pmem

On Thu, Nov 18, 2021 at 10:56 PM Christoph Hellwig wrote: > > On Wed, Nov 17, 2021 at 09:44:25AM -0800, Dan Williams wrote: > > On Tue, Nov 9, 2021 at 12:33 AM Christoph Hellwig wrote: > > > > > > dax_attribute_group is only used by the pmem driver, and can avoid

Re: [PATCH 23/29] xfs: use IOMAP_DAX to check for DAX mappings

On Tue, Nov 9, 2021 at 12:34 AM Christoph Hellwig wrote: > > Use the explicit DAX flag instead of checking the inode flag in the > iomap code. It's not immediately clear to me why this is a net benefit, are you anticipating inode-less operations? With reflink and multi-inode operations a single

Re: [PATCH 21/29] xfs: move dax device handling into xfs_{alloc, free}_buftarg

ain about missing sign-off? Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 25/29] dax: return the partition offset from fs_dax_get_by_bdev

bdev; > - td->dm_dev.dax_dev = fs_dax_get_by_bdev(bdev); > + td->dm_dev.dax_dev = fs_dax_get_by_bdev(bdev, _off); Perhaps allow NULL as an argument for callers that do not care about the start offset? Otherwise, looks good / clever. Reviewed-by: Dan Williams ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 22/29] iomap: add a IOMAP_DAX flag

an add: Reviewed-by: Dan Williams > > Signed-off-by: Christoph Hellwig > --- > fs/dax.c | 7 --- > include/linux/iomap.h | 1 + > 2 files changed, 5 insertions(+), 3 deletions(-) > > diff --git a/fs/dax.c b/fs/dax.c > index 5b52b878124ac..0bd6cdcbacfc4 1

  1   2   >