June 2020 - Linux-nvdimm

[PATCH] libnvdimm/security: Fix key lookup permissions

by Dan Williams

As of commit 8c0637e950d6 ("keys: Make the KEY_NEED_* perms an enum rather than a mask") lookup_user_key() needs an explicit declaration of what it wants to do with the key. Add KEY_NEED_SEARCH to fix a warning with the below signature, and fixes the inability to retrieve a key. WARNING: CPU: 15 PID: 6276 at security/keys/permission.c:35 key_task_permission+0xd3/0x140 [..] RIP: 0010:key_task_permission+0xd3/0x140 [..] Call Trace: lookup_user_key+0xeb/0x6b0 ? vsscanf+0x3df/0x840 ? key_validate+0x50/0x50 ? key_default_cmp+0x20/0x20 nvdimm_get_user_key_payload.part.0+0x21/0x110 [libnvdimm] nvdimm_security_store+0x67d/0xb20 [libnvdimm] security_store+0x67/0x1a0 [libnvdimm] kernfs_fop_write+0xcf/0x1c0 vfs_write+0xde/0x1d0 ksys_write+0x68/0xe0 do_syscall_64+0x5c/0xa0 entry_SYSCALL_64_after_hwframe+0x49/0xb3 Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Vishal Verma <vishal.l.verma(a)intel.com> Cc: Dave Jiang <dave.jiang(a)intel.com> Cc: Ira Weiny <ira.weiny(a)intel.com> Suggested-by: David Howells <dhowells(a)redhat.com> Fixes: 8c0637e950d6 ("keys: Make the KEY_NEED_* perms an enum rather than a mask") Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- drivers/nvdimm/security.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/nvdimm/security.c b/drivers/nvdimm/security.c index 89b85970912d..4cef69bd3c1b 100644 --- a/drivers/nvdimm/security.c +++ b/drivers/nvdimm/security.c @@ -95,7 +95,7 @@ static struct key *nvdimm_lookup_user_key(struct nvdimm *nvdimm, struct encrypted_key_payload *epayload; struct device *dev = &nvdimm->dev; - keyref = lookup_user_key(id, 0, 0); + keyref = lookup_user_key(id, 0, KEY_NEED_SEARCH); if (IS_ERR(keyref)) return NULL;

14 hours

3
2
0 / 0

rename ->make_request_fn and move it to the block_device_operations

by Christoph Hellwig

5 days, 16 hours

5
31
0 / 0

[PATCH 00/12] ACPI/NVDIMM: Runtime Firmware Activation

by Dan Williams

Quoting the documentation: Some persistent memory devices run a firmware locally on the device / "DIMM" to perform tasks like media management, capacity provisioning, and health monitoring. The process of updating that firmware typically involves a reboot because it has implications for in-flight memory transactions. However, reboots are disruptive and at least the Intel persistent memory platform implementation, described by the Intel ACPI DSM specification [1], has added support for activating firmware at runtime. [1]: https://docs.pmem.io/persistent-memory/ The approach taken is to abstract the Intel platform specific mechanism behind a libnvdimm-generic sysfs interface. The interface could support runtime-firmware-activation on another architecture without need to change userspace tooling. The ACPI NFIT implementation involves a set of device-specific-methods (DSMs) to 'arm' individual devices for activation and bus-level 'trigger' method to execute the activation. Informational / enumeration methods are also provided at the bus and device level. One complicating aspect of the memory device firmware activation is that the memory controller may need to be quiesced, no memory cycles, during the activation. While the platform has mechanisms to support holding off in-flight DMA during the activation, the device response to that delay is potentially undefined. The platform may reject a runtime firmware update if, for example a PCI-E device does not support its completion timeout value being increased to meet the activation time. Outside of device timeouts the quiesce period may also violate application timeouts. Given the above device and application timeout considerations the implementation defaults to hooking into the suspend path to trigger the activation, i.e. that a suspend-resume cycle (at least up to the syscore suspend point) is required. That default policy ensures that the system is in a quiescent state before ceasing memory controller responses for the activate. However, if desired, runtime activation without suspend can be forced as an override. The ndctl utility grows the following extensions / commands to drive this mechanism: 1/ The existing update-firmware command will 'arm' devices where the firmware image is staged by default. ndctl update-firmware all -f firmware_image.bin 2/ The existing ability to enumerate firmware-update capabilities now includes firmware activate capabilities at the 'bus' and 'dimm/device' level: ndctl list -BDF -b nfit_test.0 [ { "provider":"nfit_test.0", "dev":"ndbus2", "scrub_state":"idle", "firmware":{ "activate_method":"suspend", "activate_state":"idle" }, "dimms":[ { "dev":"nmem1", "id":"cdab-0a-07e0-ffffffff", "handle":0, "phys_id":0, "security":"disabled", "firmware":{ "current_version":0, "can_update":true } }, ... 3/ When the system can support activation without quiesce, or when the suspend-resume requirement is going to be suppressed, the new activate-firmware command wraps that functionality: ndctl activate-firmware nfit_test.0 --force One major open question for review is how users can trigger firmware-activation via suspend without doing a full trip through the BIOS. The activation currently requires CONFIG_PM_DEBUG to enable that flow. This seems an awkward dependency for something that is expected to be a production capability. --- Dan Williams (12): libnvdimm: Validate command family indices ACPI: NFIT: Move bus_dsm_mask out of generic nvdimm_bus_descriptor ACPI: NFIT: Define runtime firmware activation commands tools/testing/nvdimm: Cleanup dimm index passing tools/testing/nvdimm: Add command debug messages tools/testing/nvdimm: Prepare nfit_ctl_test() for ND_CMD_CALL emulation tools/testing/nvdimm: Emulate firmware activation commands driver-core: Introduce DEVICE_ATTR_ADMIN_{RO,RW} libnvdimm: Convert to DEVICE_ATTR_ADMIN_RO() libnvdimm: Add runtime firmware activation sysfs interface PM, libnvdimm: Add syscore_quiesced() callback for firmware activation ACPI: NFIT: Add runtime firmware activate support Documentation/ABI/testing/sysfs-bus-nfit | 35 ++ Documentation/ABI/testing/sysfs-bus-nvdimm | 2 .../driver-api/nvdimm/firmware-activate.rst | 74 +++ drivers/acpi/nfit/core.c | 146 +++++-- drivers/acpi/nfit/intel.c | 426 ++++++++++++++++++++ drivers/acpi/nfit/intel.h | 61 +++ drivers/acpi/nfit/nfit.h | 39 ++ drivers/base/syscore.c | 18 + drivers/nvdimm/bus.c | 46 ++ drivers/nvdimm/core.c | 103 +++++ drivers/nvdimm/dimm_devs.c | 99 +++++ drivers/nvdimm/namespace_devs.c | 2 drivers/nvdimm/nd-core.h | 1 drivers/nvdimm/pfn_devs.c | 2 drivers/nvdimm/region_devs.c | 2 include/linux/device.h | 4 include/linux/libnvdimm.h | 53 ++ include/linux/syscore_ops.h | 2 include/linux/sysfs.h | 7 include/uapi/linux/ndctl.h | 5 kernel/power/suspend.c | 2 tools/testing/nvdimm/test/nfit.c | 367 ++++++++++++++--- 22 files changed, 1382 insertions(+), 114 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-nvdimm create mode 100644 Documentation/driver-api/nvdimm/firmware-activate.rst base-commit: 48778464bb7d346b47157d21ffde2af6b2d39110

6 days, 13 hours

4
21
0 / 0

[PATCH v6 0/8] Support new pmem flush and sync instructions for POWER

by Aneesh Kumar K.V

This patch series enables the usage os new pmem flush and sync instructions on POWER architecture. POWER10 introduces two new variants of dcbf instructions (dcbstps and dcbfps) that can be used to write modified locations back to persistent storage. Additionally, POWER10 also introduce phwsync and plwsync which can be used to establish order of these writes to persistent storage. This series exposes these instructions to the rest of the kernel. The existing dcbf and hwsync instructions in P8 and P9 are adequate to enable appropriate synchronization with OpenCAPI-hosted persistent storage. Hence the new instructions are added as a variant of the old ones that old hardware won't differentiate. On POWER10, pmem devices will be represented by a different device tree compat strings. This ensures that older kernels won't initialize pmem devices on POWER10. With this: 1) vPMEM continues to work since it is a volatile region. That doesn't need any flush instructions. 2) pmdk and other user applications get updated to use new instructions and updated packages are made available to all distributions 3) On newer hardware, the device will appear with a new compat string. Hence older distributions won't initialize pmem on newer hardware. Changes from v5: * Drop CONFIG_ARCH_MAP_SYNC_DISABLE and related changes Changes from V4: * Add namespace specific sychronous fault control. Changes from V3: * Add new compat string to be used for the device. * Use arch_pmem_flush_barrier() in dm-writecache. Aneesh Kumar K.V (8): powerpc/pmem: Restrict papr_scm to P8 and above. powerpc/pmem: Add new instructions for persistent storage and sync powerpc/pmem: Add flush routines using new pmem store and sync instruction libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier powerpc/pmem/of_pmem: Update of_pmem to use the new barrier instruction. powerpc/pmem: Avoid the barrier in flush routines powerpc/pmem: Add WARN_ONCE to catch the wrong usage of pmem flush functions. powerpc/pmem: Initialize pmem device on newer hardware arch/powerpc/include/asm/cacheflush.h | 10 +++++ arch/powerpc/include/asm/ppc-opcode.h | 12 ++++++ arch/powerpc/lib/pmem.c | 46 +++++++++++++++++++++-- arch/powerpc/platforms/pseries/papr_scm.c | 14 +++++++ arch/powerpc/platforms/pseries/pmem.c | 6 +++ drivers/md/dm-writecache.c | 2 +- drivers/nvdimm/of_pmem.c | 1 + drivers/nvdimm/region_devs.c | 8 ++-- include/asm-generic/cacheflush.h | 4 ++ 9 files changed, 94 insertions(+), 9 deletions(-) -- 2.26.2

1 week

4
32
0 / 0

[PATCH v2] ACPI: Drop rcu usage for MMIO mappings

by Dan Williams

Recently a performance problem was reported for a process invoking a non-trival ASL program. The method call in this case ends up repetitively triggering a call path like: acpi_ex_store acpi_ex_store_object_to_node acpi_ex_write_data_to_field acpi_ex_insert_into_field acpi_ex_write_with_update_rule acpi_ex_field_datum_io acpi_ex_access_region acpi_ev_address_space_dispatch acpi_ex_system_memory_space_handler acpi_os_map_cleanup.part.14 _synchronize_rcu_expedited.constprop.89 schedule The end result of frequent synchronize_rcu_expedited() invocation is tiny sub-millisecond spurts of execution where the scheduler freely migrates this apparently sleepy task. The overhead of frequent scheduler invocation multiplies the execution time by a factor of 2-3X. For example, performance improves from 16 minutes to 7 minutes for a firmware update procedure across 24 devices. Perhaps the rcu usage was intended to allow for not taking a sleeping lock in the acpi_os_{read,write}_memory() path which ostensibly could be called from an APEI NMI error interrupt? Neither rcu_read_lock() nor ioremap() are interrupt safe, so add a WARN_ONCE() to validate that rcu was not serving as a mechanism to avoid direct calls to ioremap(). Even the original implementation had a spin_lock_irqsave(), but that is not NMI safe. APEI itself already has some concept of avoiding ioremap() from interrupt context (see erst_exec_move_data()), if the new warning triggers it means that APEI either needs more instrumentation like that to pre-emptively fail, or more infrastructure to arrange for pre-mapping the resources it needs in NMI context. Cc: <stable(a)vger.kernel.org> Fixes: 620242ae8c3d ("ACPI: Maintain a list of ACPI memory mapped I/O remappings") Cc: Len Brown <lenb(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Ira Weiny <ira.weiny(a)intel.com> Cc: James Morse <james.morse(a)arm.com> Cc: Erik Kaneda <erik.kaneda(a)intel.com> Cc: Myron Stowe <myron.stowe(a)redhat.com> Cc: "Rafael J. Wysocki" <rjw(a)rjwysocki.net> Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- Changes since v1 [1]: - Actually cc: the most important list for ACPI changes (Rafael) - Cleanup unnecessary variable initialization (Andy) Link: https://lore.kernel.org/linux-nvdimm/158880834905.2183490.156163294694202... drivers/acpi/osl.c | 117 +++++++++++++++++++++++++--------------------------- 1 file changed, 57 insertions(+), 60 deletions(-) diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index 762c5d50b8fe..a44b75aac5d0 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -214,13 +214,13 @@ acpi_physical_address __init acpi_os_get_root_pointer(void) return pa; } -/* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */ static struct acpi_ioremap * acpi_map_lookup(acpi_physical_address phys, acpi_size size) { struct acpi_ioremap *map; - list_for_each_entry_rcu(map, &acpi_ioremaps, list, acpi_ioremap_lock_held()) + lockdep_assert_held(&acpi_ioremap_lock); + list_for_each_entry(map, &acpi_ioremaps, list) if (map->phys <= phys && phys + size <= map->phys + map->size) return map; @@ -228,7 +228,6 @@ acpi_map_lookup(acpi_physical_address phys, acpi_size size) return NULL; } -/* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */ static void __iomem * acpi_map_vaddr_lookup(acpi_physical_address phys, unsigned int size) { @@ -263,7 +262,8 @@ acpi_map_lookup_virt(void __iomem *virt, acpi_size size) { struct acpi_ioremap *map; - list_for_each_entry_rcu(map, &acpi_ioremaps, list, acpi_ioremap_lock_held()) + lockdep_assert_held(&acpi_ioremap_lock); + list_for_each_entry(map, &acpi_ioremaps, list) if (map->virt <= virt && virt + size <= map->virt + map->size) return map; @@ -360,7 +360,7 @@ void __iomem __ref map->size = pg_sz; map->refcount = 1; - list_add_tail_rcu(&map->list, &acpi_ioremaps); + list_add_tail(&map->list, &acpi_ioremaps); out: mutex_unlock(&acpi_ioremap_lock); @@ -374,20 +374,13 @@ void *__ref acpi_os_map_memory(acpi_physical_address phys, acpi_size size) } EXPORT_SYMBOL_GPL(acpi_os_map_memory); -/* Must be called with mutex_lock(&acpi_ioremap_lock) */ -static unsigned long acpi_os_drop_map_ref(struct acpi_ioremap *map) -{ - unsigned long refcount = --map->refcount; - - if (!refcount) - list_del_rcu(&map->list); - return refcount; -} - -static void acpi_os_map_cleanup(struct acpi_ioremap *map) +static void acpi_os_drop_map_ref(struct acpi_ioremap *map) { - synchronize_rcu_expedited(); + lockdep_assert_held(&acpi_ioremap_lock); + if (--map->refcount > 0) + return; acpi_unmap(map->phys, map->virt); + list_del(&map->list); kfree(map); } @@ -408,7 +401,6 @@ static void acpi_os_map_cleanup(struct acpi_ioremap *map) void __ref acpi_os_unmap_iomem(void __iomem *virt, acpi_size size) { struct acpi_ioremap *map; - unsigned long refcount; if (!acpi_permanent_mmap) { __acpi_unmap_table(virt, size); @@ -422,11 +414,8 @@ void __ref acpi_os_unmap_iomem(void __iomem *virt, acpi_size size) WARN(true, PREFIX "%s: bad address %p\n", __func__, virt); return; } - refcount = acpi_os_drop_map_ref(map); + acpi_os_drop_map_ref(map); mutex_unlock(&acpi_ioremap_lock); - - if (!refcount) - acpi_os_map_cleanup(map); } EXPORT_SYMBOL_GPL(acpi_os_unmap_iomem); @@ -461,7 +450,6 @@ void acpi_os_unmap_generic_address(struct acpi_generic_address *gas) { u64 addr; struct acpi_ioremap *map; - unsigned long refcount; if (gas->space_id != ACPI_ADR_SPACE_SYSTEM_MEMORY) return; @@ -477,11 +465,8 @@ void acpi_os_unmap_generic_address(struct acpi_generic_address *gas) mutex_unlock(&acpi_ioremap_lock); return; } - refcount = acpi_os_drop_map_ref(map); + acpi_os_drop_map_ref(map); mutex_unlock(&acpi_ioremap_lock); - - if (!refcount) - acpi_os_map_cleanup(map); } EXPORT_SYMBOL(acpi_os_unmap_generic_address); @@ -700,55 +685,71 @@ int acpi_os_read_iomem(void __iomem *virt_addr, u64 *value, u32 width) return 0; } +static void __iomem *acpi_os_rw_map(acpi_physical_address phys_addr, + unsigned int size, bool *did_fallback) +{ + void __iomem *virt_addr; + + if (WARN_ONCE(in_interrupt(), "ioremap in interrupt context\n")) + return NULL; + + /* Try to use a cached mapping and fallback otherwise */ + *did_fallback = false; + mutex_lock(&acpi_ioremap_lock); + virt_addr = acpi_map_vaddr_lookup(phys_addr, size); + if (virt_addr) + return virt_addr; + mutex_unlock(&acpi_ioremap_lock); + + virt_addr = acpi_os_ioremap(phys_addr, size); + *did_fallback = true; + + return virt_addr; +} + +static void acpi_os_rw_unmap(void __iomem *virt_addr, bool did_fallback) +{ + if (did_fallback) { + /* in the fallback case no lock is held */ + iounmap(virt_addr); + return; + } + + mutex_unlock(&acpi_ioremap_lock); +} + acpi_status acpi_os_read_memory(acpi_physical_address phys_addr, u64 *value, u32 width) { - void __iomem *virt_addr; unsigned int size = width / 8; - bool unmap = false; + bool did_fallback = false; + void __iomem *virt_addr; u64 dummy; int error; - rcu_read_lock(); - virt_addr = acpi_map_vaddr_lookup(phys_addr, size); - if (!virt_addr) { - rcu_read_unlock(); - virt_addr = acpi_os_ioremap(phys_addr, size); - if (!virt_addr) - return AE_BAD_ADDRESS; - unmap = true; - } - + virt_addr = acpi_os_rw_map(phys_addr, size, &did_fallback); + if (!virt_addr) + return AE_BAD_ADDRESS; if (!value) value = &dummy; error = acpi_os_read_iomem(virt_addr, value, width); BUG_ON(error); - if (unmap) - iounmap(virt_addr); - else - rcu_read_unlock(); - + acpi_os_rw_unmap(virt_addr, did_fallback); return AE_OK; } acpi_status acpi_os_write_memory(acpi_physical_address phys_addr, u64 value, u32 width) { - void __iomem *virt_addr; unsigned int size = width / 8; - bool unmap = false; + bool did_fallback = false; + void __iomem *virt_addr; - rcu_read_lock(); - virt_addr = acpi_map_vaddr_lookup(phys_addr, size); - if (!virt_addr) { - rcu_read_unlock(); - virt_addr = acpi_os_ioremap(phys_addr, size); - if (!virt_addr) - return AE_BAD_ADDRESS; - unmap = true; - } + virt_addr = acpi_os_rw_map(phys_addr, size, &did_fallback); + if (!virt_addr) + return AE_BAD_ADDRESS; switch (width) { case 8: @@ -767,11 +768,7 @@ acpi_os_write_memory(acpi_physical_address phys_addr, u64 value, u32 width) BUG(); } - if (unmap) - iounmap(virt_addr); - else - rcu_read_unlock(); - + acpi_os_rw_unmap(virt_addr, did_fallback); return AE_OK; }

1 week

7
49
0 / 0

[PATCH] dm writecache: reject asynchronous pmem.

by Michal Suchanek

The writecache driver does not handle asynchronous pmem. Reject it when supplied as cache. Link: https://lore.kernel.org/linux-nvdimm/87lfk5hahc.fsf@linux.ibm.com/ Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver") Signed-off-by: Michal Suchanek <msuchanek(a)suse.de> --- drivers/md/dm-writecache.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/md/dm-writecache.c b/drivers/md/dm-writecache.c index 30505d70f423..57b0a972f6fd 100644 --- a/drivers/md/dm-writecache.c +++ b/drivers/md/dm-writecache.c @@ -2277,6 +2277,12 @@ static int writecache_ctr(struct dm_target *ti, unsigned argc, char **argv) wc->memory_map_size -= (uint64_t)wc->start_sector << SECTOR_SHIFT; + if (!dax_synchronous(wc->ssd_dev->dax_dev)) { + r = -EOPNOTSUPP; + ti->error = "Asynchronous persistent memory not supported as pmem cache"; + goto bad; + } + bio_list_init(&wc->flush_list); wc->flush_thread = kthread_create(writecache_flush_thread, wc, "dm_writecache_flush"); if (IS_ERR(wc->flush_thread)) { -- 2.26.2

1 week

4
9
0 / 0

DHL Delivery e-Notification for incorrect Info.

by uaeimportcollection＠dhl.com

1 week

1
0
0 / 0

Delivery Notification: 5 messages to linux-nvdimm@lists.01.org delayed for 48 hours

by lists.01.org

1 week, 1 day

1
0
0 / 0

妙龄美女爱丽莎性感内衣美乳魅惑

by cbntwnsaj

1 week, 1 day

1
0
0 / 0

Hello,

by mrs.victoria alexander

Dear friend, I have a business container transaction what that some of( $13million dollars) I would like to discuss with you. If you are interested, please contact my email address (mrs.victoria.alexander2(a)gmail.com) My WhatsApp number but only message (+19293737780) Please do not reply if you are not ready Thanks

1 week, 1 day

1
0
0 / 0

2020

2019

2018

2017

2016

2015

2014

Linux-nvdimm June 2020