Re: [PATCH v3 2/8] cxl/acpi: Add root device lockdep validation

On Thu, Apr 21, 2022 at 08:33:18AM -0700, Dan Williams wrote: > The CXL "root" device, ACPI0017, is an attach point for coordinating > platform level CXL resources and is the parent device for a CXL port > topology tree. As such it has distinct locking rules relative to other > CXL subsystem object

Re: [PATCH v3 7/8] device-core: Kill the lockdep_mutex

On Thu, Apr 21, 2022 at 08:33:45AM -0700, Dan Williams wrote: > Per Peter [1], the lockdep API has native support for all the use cases > lockdep_mutex was attempting to enable. Now that all lockdep_mutex users > have been converted to those APIs, drop this lock. > > Link: > https://lore.kernel.o

[PATCH] libnvdimm/security: change __nvdimm_security_overwrite_query from global to static

Smatch reports this issue security.c:416:6: warning: symbol '__nvdimm_security_overwrite_query' was not declared. Should it be static? __nvdimm_security_overwrite_query is only used in security.c so change its storage-class specifier to static Signed-off-by: Tom Rix --- drivers/nvdimm/security

[PATCH v3 5/8] ACPI: NFIT: Drop nfit_device_lock()

The nfit_device_lock() helper was added to provide lockdep coverage for the NFIT driver's usage of device_lock() on the nvdimm_bus object. Now that nvdimm_bus objects have their own lock class this wrapper can be dropped. Cc: Vishal Verma Cc: Dave Jiang Cc: Ira Weiny Signed-off-by: Dan Williams

[PATCH v3 8/8] nvdimm: Fix firmware activation deadlock scenarios

Lockdep reports the following deadlock scenarios for CXL root device power-management, device_prepare(), operations, and device_shutdown() operations for 'nd_region' devices: --- Chain exists of: &nvdimm_region_key --> &nvdimm_bus->reconfig_mutex --> system_transition_mutex Possible unsafe

[PATCH v3 0/8] device-core: Enable device_lock() lockdep validation

Changes since v2 [1] - Use lockdep_set_class(), lockdep_set_class_and_subclass(), and lock_set_class() instead of a 'lockdep_mutex' in 'struct device'. (Peter and Waiman) - Include a fix identifed by this new infrastructure [1]: https://lore.kernel.org/r/164982968798.684294.158178533298239764

[PATCH v3 1/8] cxl: Replace lockdep_mutex with local lock classes

In response to an attempt to expand dev->lockdep_mutex for device_lock() validation [1], Peter points out [2] that the lockdep API already has the ability to assign a dedicated lock class per subsystem device-type. Use lockdep_set_class() to override the default device_lock() '__lockdep_no_validat

[PATCH v3 7/8] device-core: Kill the lockdep_mutex

Per Peter [1], the lockdep API has native support for all the use cases lockdep_mutex was attempting to enable. Now that all lockdep_mutex users have been converted to those APIs, drop this lock. Link: https://lore.kernel.org/r/ylf0dewci8myl...@hirez.programming.kicks-ass.net [1] Cc: Greg Kroah-H

[PATCH v3 6/8] nvdimm: Drop nd_device_lock()

Now that all NVDIMM subsystem locking is validated with custom lock classes, there is no need for the custom usage of the lockdep_mutex. Cc: Vishal Verma Cc: Dave Jiang Cc: Ira Weiny Signed-off-by: Dan Williams --- drivers/nvdimm/btt_devs.c | 16 + drivers/nvdimm/bus.c

[PATCH v3 4/8] nvdimm: Replace lockdep_mutex with local lock classes

In response to an attempt to expand dev->lockdep_mutex for device_lock() validation [1], Peter points out [2] that the lockdep API already has the ability to assign a dedicated lock class per subsystem device-type. Use lockdep_set_class() to override the default device_lock() '__lockdep_no_validat

[PATCH v3 3/8] cxl: Drop cxl_device_lock()

Now that all CXL subsystem locking is validated with custom lock classes, there is no need for the custom usage of the lockdep_mutex. Cc: Alison Schofield Cc: Vishal Verma Cc: Ira Weiny Cc: Ben Widawsky Cc: Jonathan Cameron Signed-off-by: Dan Williams --- drivers/cxl/core/pmem.c |4 +-

[PATCH v3 2/8] cxl/acpi: Add root device lockdep validation

The CXL "root" device, ACPI0017, is an attach point for coordinating platform level CXL resources and is the parent device for a CXL port topology tree. As such it has distinct locking rules relative to other CXL subsystem objects, but because it is an ACPI device the lock class is established well

Re: [PATCH v13 5/7] mm: Introduce mf_dax_kill_procs() for fsdax case

On Tue, Apr 19, 2022 at 12:50:43PM +0800, Shiyang Ruan wrote: > This new function is a variant of mf_generic_kill_procs that accepts a > file, offset pair instead of a struct to support multiple files sharing > a DAX mapping. It is intended to be called by the file systems as part > of the memory_

Re: [PATCH v13 2/7] mm: factor helpers for memory_failure_dev_pagemap

在 2022/4/21 14:13, HORIGUCHI NAOYA(堀口 直也) 写道: On Tue, Apr 19, 2022 at 12:50:40PM +0800, Shiyang Ruan wrote: memory_failure_dev_pagemap code is a bit complex before introduce RMAP feature for fsdax. So it is needed to factor some helper functions to simplify these code. Signed-off-by: Shiyan

Re: [PATCH v13 0/7] fsdax: introduce fs query to support reflink

On Wed, Apr 20, 2022 at 10:54:59PM -0700, Christoph Hellwig wrote: > On Thu, Apr 21, 2022 at 02:35:02PM +1000, Dave Chinner wrote: > > Sure, I'm not a maintainer and just the stand-in patch shepherd for > > a single release. However, being unable to cleanly merge code we > > need integrated into ou