Re: [PATCH v2 2/4] dax/bus.c: fix locking for unregister_dax_dev / unregister_dax_mapping paths

On Mon, 2024-04-29 at 18:25 -0700, Dan Williams wrote: > Vishal Verma wrote: > > Commit c05ae9d85b47 ("dax/bus.c: replace driver-core lock usage by a local > > rwsem") > > was a bit overzealous in eliminating device_lock() usage, and ended up > > removing a couple of lock acquisitions which were

Re: [PATCH][next] dax: remove redundant assignment to variable rc

On Mon, 2024-04-15 at 11:19 +0100, Colin Ian King wrote: > The variable rc is being assigned an value and then is being re-assigned > a new value in the next statement. The assignment is redundant and can > be removed. > > Cleans up clang scan build warning: > drivers/dax/bus.c:1207:2: warning:

Re: [PATCH] dax/bus.c: replace WARN_ON_ONCE() with lockdep asserts

On Thu, 2024-04-04 at 14:23 -0700, Andrew Morton wrote: > On Tue, 02 Apr 2024 00:24:28 -0600 Vishal Verma > wrote: > > > In [1], Dan points out that all of the WARN_ON_ONCE() usage in the > > referenced patch should be replaced with lockdep_assert_held(_write)(). > > > > Replace those, and

Re: [PATCH v7 1/5] dax/bus.c: replace driver-core lock usage by a local rwsem

On Tue, 2024-03-12 at 13:07 -0700, Dan Williams wrote: > Vishal Verma wrote: > > The dax driver incorrectly used driver-core device locks to protect > > internal dax region and dax device configuration structures. Replace the > > device lock usage with a local rwsem, one each for dax region > >

Re: [PATCH] dax: remove SLAB_MEM_SPREAD flag usage

On Wed, 2024-02-28 at 11:16 +0800, Chengming Zhou wrote: > On 2024/2/28 00:29, Dave Jiang wrote: > > > > > > On 2/24/24 6:47 AM, chengming.z...@linux.dev wrote: > > > From: Chengming Zhou > > > > > > The SLAB_MEM_SPREAD flag is already a no-op as of 6.8-rc1, remove > > > its usage so we can

Re: [PATCH v6 2/4] dax/bus: Use guard(device) in sysfs attribute helpers

On Fri, 2023-12-15 at 09:15 -0800, Dan Williams wrote: > Greg Kroah-Hartman wrote: > > On Thu, Dec 14, 2023 at 10:25:27PM -0700, Vishal Verma wrote: > > > Use the guard(device) macro to lock a 'struct device', and unlock it > > > automatically when going out of scope using Scope Based Resource > >

Re: [PATCH v6 2/4] dax/bus: Use guard(device) in sysfs attribute helpers

On Fri, 2023-12-15 at 05:56 +, Matthew Wilcox wrote: > On Thu, Dec 14, 2023 at 10:25:27PM -0700, Vishal Verma wrote: > > @@ -294,13 +294,10 @@ static ssize_t available_size_show(struct device *dev, > > struct device_attribute *attr, char *buf) > >  { > > struct

Re: [PATCH] driver core: Add a guard() definition for the device_lock()

On Wed, 2023-12-13 at 15:02 -0800, Dan Williams wrote: > At present there are ~200 usages of device_lock() in the kernel. Some of > those usages lead to "goto unlock;" patterns which have proven to be > error prone. Define a "device" guard() definition to allow for those to "Define a definition"

Re: [PATCH v3 2/2] dax: add a sysfs knob to control memmap_on_memory behavior

On Tue, 2023-12-12 at 08:56 +0800, Huang, Ying wrote: > "Verma, Vishal L" writes: > > > On Tue, 2023-12-12 at 08:30 +0800, Huang, Ying wrote: > > > > > > > + > > > > +static ssize_t memmap_on_memory_store(struct device *dev, > > >

Re: [PATCH v3 2/2] dax: add a sysfs knob to control memmap_on_memory behavior

On Tue, 2023-12-12 at 08:30 +0800, Huang, Ying wrote: > Vishal Verma writes: > > > Add a sysfs knob for dax devices to control the memmap_on_memory setting > > if the dax device were to be hotplugged as system memory. > > > > The default memmap_on_memory setting for dax devices originating via

Re: [PATCH v2 2/2] dax: add a sysfs knob to control memmap_on_memory behavior

On Fri, 2023-12-08 at 12:36 +0100, David Hildenbrand wrote: > On 07.12.23 05:36, Vishal Verma wrote: [..] > > > > + > > +What:  /sys/bus/dax/devices/daxX.Y/memmap_on_memory > > +Date:  October, 2023 > > +KernelVersion: v6.8 > > +Contact:   nvd...@lists.linux.dev > >

Re: [PATCH v2 2/2] dax: add a sysfs knob to control memmap_on_memory behavior

On Fri, 2023-12-08 at 11:13 +0800, Huang, Ying wrote: > Vishal Verma writes: > [..] > > > > + > > +static ssize_t memmap_on_memory_store(struct device *dev, > > + struct device_attribute *attr, > > + const char *buf, size_t

Re: [PATCH v2 2/2] dax: add a sysfs knob to control memmap_on_memory behavior

On Fri, 2023-12-08 at 09:20 +, Zhijian Li (Fujitsu) wrote: > > > On 08/12/2023 03:25, Verma, Vishal L wrote: > > On Thu, 2023-12-07 at 08:29 +, Zhijian Li (Fujitsu) wrote: > > > Hi Vishal, > > > > > > > > > On 07/12/2023 12:36, Vishal

Re: [PATCH v2 2/2] dax: add a sysfs knob to control memmap_on_memory behavior

On Thu, 2023-12-07 at 08:29 +, Zhijian Li (Fujitsu) wrote: > Hi Vishal, > > > On 07/12/2023 12:36, Vishal Verma wrote: > > + > > +What:  /sys/bus/dax/devices/daxX.Y/memmap_on_memory > > +Date:  October, 2023 > > +KernelVersion: v6.8 > > +Contact:   nvd...@lists.linux.dev

Re: [PATCH v8 2/3] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Fri, 2023-11-03 at 09:43 -0700, fan wrote: > On Wed, Nov 01, 2023 at 04:51:52PM -0600, Vishal Verma wrote: > > [..] > >   > > +static void __ref remove_memory_blocks_and_altmaps(u64 start, u64 size) > > +{ > > +   unsigned long memblock_size = memory_block_size_bytes(); > > +   u64

Re: [PATCH v8 2/3] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Thu, 2023-11-02 at 09:16 +0800, Huang, Ying wrote: > Vishal Verma writes: > [..] > > + > > +static int create_altmaps_and_memory_blocks(int nid, struct memory_group > > *group, > > +   u64 start, u64 size) > > +{ > > +   unsigned long memblock_size

Re: [PATCH v7 2/3] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Mon, 2023-10-30 at 11:20 +0100, David Hildenbrand wrote: > On 26.10.23 00:44, Vishal Verma wrote: > > [..] > > @@ -2146,11 +2186,69 @@ void try_offline_node(int nid) > >   } > >   EXPORT_SYMBOL(try_offline_node); > >   > > -static int __ref try_remove_memory(u64 start, u64 size) > > +static

Re: [PATCH v5 2/2] dax/kmem: allow kmem to add memory with memmap_on_memory

On Tue, 2023-10-17 at 13:18 +0800, Huang, Ying wrote: > "Verma, Vishal L" writes: > > > On Thu, 2023-10-05 at 14:16 -0700, Dan Williams wrote: > > > Vishal Verma wrote: > > > > > > <..> > > > > > > + > > > > +

Re: [PATCH v5 2/2] dax/kmem: allow kmem to add memory with memmap_on_memory

On Thu, 2023-10-05 at 14:16 -0700, Dan Williams wrote: > Vishal Verma wrote: > > <..> > > + > > +   rc = kstrtobool(buf, ); > > +   if (rc) > > +   return rc; > > Perhaps: > > if (dev_dax->memmap_on_memory == val) > return len; > > ...and skip the check below when

Re: [PATCH v5 1/2] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Thu, 2023-10-12 at 10:40 +0200, David Hildenbrand wrote: > On 12.10.23 07:53, Verma, Vishal L wrote: > > On Mon, 2023-10-09 at 17:04 +0200, David Hildenbrand wrote: > > > On 07.10.23 10:55, Huang, Ying wrote: > > > > Vishal Verma writes: > <..> &

Re: [PATCH v5 1/2] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Mon, 2023-10-09 at 17:04 +0200, David Hildenbrand wrote: > On 07.10.23 10:55, Huang, Ying wrote: > > Vishal Verma writes: > > > > > @@ -2167,47 +2221,28 @@ static int __ref try_remove_memory(u64 start, u64 > > > size) > > > if (rc) > > > return rc; > > >   > > > +

Re: [PATCH v5 1/2] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Fri, 2023-10-06 at 14:52 +0200, David Hildenbrand wrote: > On 05.10.23 20:31, Vishal Verma wrote: > > <..> > > @@ -2167,47 +2221,28 @@ static int __ref try_remove_memory(u64 start, u64 > > size) > > if (rc) > > return rc; > >   > > +   mem_hotplug_begin(); > > + >

Re: [PATCH v5 1/2] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Thu, 2023-10-05 at 14:20 -0700, Dan Williams wrote: > Vishal Verma wrote: <..> > > > > --- a/mm/memory_hotplug.c > > +++ b/mm/memory_hotplug.c > > @@ -1380,6 +1380,44 @@ static bool mhp_supports_memmap_on_memory(unsigned > > long size) > > return

Re: [PATCH v4 2/2] dax/kmem: allow kmem to add memory with memmap_on_memory

On Tue, 2023-10-03 at 09:34 +0530, Aneesh Kumar K V wrote: > On 9/29/23 2:00 AM, Vishal Verma wrote: > > Large amounts of memory managed by the kmem driver may come in via CXL, > > and it is often desirable to have the memmap for this memory on the new > > memory itself. > > > > Enroll

Re: [PATCH v4 1/2] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Mon, 2023-10-02 at 11:28 +0200, David Hildenbrand wrote: > > > + > > +static int __ref try_remove_memory(u64 start, u64 size) > > +{ > > +   int rc, nid = NUMA_NO_NODE; > > + > > +   BUG_ON(check_hotplug_memory_range(start, size)); > > + > > +   /* > > +    * All memory blocks

Re: [PATCH v2] nd_btt: Make BTT lanes preemptible

On Wed, 2023-09-20 at 07:37 +0200, Tomas Glozar wrote: > nd_region_acquire_lane uses get_cpu, which disables preemption. This is > an issue on PREEMPT_RT kernels, since btt_write_pg and also > nd_region_acquire_lane itself take a spin lock, resulting in BUG: > sleeping function called from invalid

Re: [PATCH v3 1/2] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Wed, 2023-08-02 at 15:20 +0100, Jonathan Cameron wrote: > On Tue, 01 Aug 2023 23:55:37 -0600 > Vishal Verma wrote: > > > The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is restricted to > > 'memblock_size' chunks of memory being added. Adding a larger span of > > memory precludes

Re: [PATCH v2 2/3] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Mon, 2023-07-24 at 13:54 +0800, Huang, Ying wrote: > Vishal Verma writes: > > > > > @@ -2035,12 +2056,38 @@ void try_offline_node(int nid) > >  } > >  EXPORT_SYMBOL(try_offline_node); > >   > > -static int __ref try_remove_memory(u64 start, u64 size) > > +static void __ref

Re: [PATCH v2 2/3] mm/memory_hotplug: split memmap_on_memory requests across memblocks

On Mon, 2023-07-24 at 11:16 +0800, Huang, Ying wrote: > "Aneesh Kumar K.V" writes: > > > > > @@ -1339,27 +1367,20 @@ int __ref add_memory_resource(int nid, > > > struct resource *res, mhp_t mhp_flags) > > > /* > > > * Self hosted memmap array > > > */ > > > -   if

Re: [PATCH 3/3] dax/kmem: Always enroll hotplugged memory for memmap_on_memory

On Thu, 2023-07-13 at 17:23 +0200, David Hildenbrand wrote: > On 13.07.23 17:15, Verma, Vishal L wrote: > > On Thu, 2023-07-13 at 09:23 +0200, David Hildenbrand wrote: > > > On 13.07.23 08:45, Verma, Vishal L wrote: > > > > > > > > I'm taking a sho

Re: [PATCH 3/3] dax/kmem: Always enroll hotplugged memory for memmap_on_memory

On Thu, 2023-07-13 at 09:23 +0200, David Hildenbrand wrote: > On 13.07.23 08:45, Verma, Vishal L wrote: > > > > I'm taking a shot at implementing the splitting internally in > > memory_hotplug.c. The caller (kmem) side does become trivial with this > > approach, but th

Re: [PATCH 3/3] dax/kmem: Always enroll hotplugged memory for memmap_on_memory

On Tue, 2023-07-11 at 17:21 +0200, David Hildenbrand wrote: > On 11.07.23 16:30, Aneesh Kumar K.V wrote: > > David Hildenbrand writes: > > > > > > Maybe the better alternative is teach > > > add_memory_resource()/try_remove_memory() to do that internally. > > > > > > In the

Re: [PATCH] ACPI: NFIT: add helper to_nfit_mem() to take device to nfit_mem

On Mon, 2023-07-03 at 14:17 +0100, Ben Dooks wrote: > Add a quick helper to just do struct device to the struct nfit_mem > field it should be referencing. This reduces the number of code > lines in some of the followgn code as it removes the intermediate > struct nvdimm. > > Signed-off-by: Ben

[GIT PULL] NVDIMM and DAX for 6.5

Hi Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git tags/libnvdimm-for-6.5 ... to receive the libnvdimm and DAX update for v6.5. This is mostly small cleanups and fixes, with the biggest change being the change to the DAX fault handler allowing it to

Re: [PATCH 0/3] mm: use memmap_on_memory semantics for dax/kmem

On Fri, 2023-06-16 at 09:44 +0200, David Hildenbrand wrote: > On 16.06.23 00:00, Vishal Verma wrote: > > The dax/kmem driver can potentially hot-add large amounts of memory > > originating from CXL memory expanders, or NVDIMMs, or other 'device > > memories'. There is a chance there isn't enough

Re: [PATCH] dax/kmem: Pass valid argument to memory_group_register_static

On Wed, 2023-06-21 at 11:36 +0530, Tarun Sahu wrote: > Hi Alison, > > Alison Schofield writes: > > > On Tue, Jun 20, 2023 at 07:33:32PM +0530, Tarun Sahu wrote: > > > memory_group_register_static takes maximum number of pages as the argument > > > while dev_dax_kmem_probe passes total_len (in

Re: [PATCH v2] nvdimm: Use kstrtobool() instead of strtobool()

On Sat, 2023-01-14 at 09:50 +0100, Christophe JAILLET wrote: > strtobool() is the same as kstrtobool(). > However, the latter is more used within the kernel. > > In order to remove strtobool() and slightly simplify kstrtox.h, switch to > the other function name. > > While at it, include the

Re: [PATCH 2/2] ACPI: HMAT: Fix initiator registration for single-initiator systems

On Wed, 2022-11-16 at 15:46 +0300, Kirill A. Shutemov wrote: > On Wed, Nov 16, 2022 at 12:57:36AM -0700, Vishal Verma wrote: > > In a system with a single initiator node, and one or more memory-only > > 'target' nodes, the memory-only node(s) would fail to register their > > initiator node

[GIT PULL] nvdimm fixes v5.19-rc5

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm tags/libnvdimm-fixes-5.19-rc5 ...to receive a fix for v5.19-rc5. It has been in -next for a week with no reported issues. --- The following changes since commit a111daf0c53ae91e71fd2bfe7497862d14132e3e:

Re: [PATCH] cxl/mem: Fix memory device capacity probing

On Fri, 2021-04-16 at 17:43 -0700, Dan Williams wrote: > The CXL Identify Memory Device output payload emits capacity in 256MB > units. The driver is treating the capacity field as bytes. This was > missed because QEMU reports bytes when it should report bytes / 256MB. > > Fixes: 8adaf747c9f0

Re: [PATCH 3/3] cxl/mem: Demarcate vendor specific capability IDs

On Thu, 2021-04-15 at 16:27 -0700, Ben Widawsky wrote: > Vendor capabilities occupy 0x8000 to 0x according to CXL 2.0 spec > 8.2.8.2.1 CXL Device Capabilities. While they are not defined by the > spec, they are allowed and not "unknown". Call this detail out in the > logs to let users easily

Re: [PATCH 2/3] cxl/mem: Print unknown capability IDs as hex

On Thu, 2021-04-15 at 16:26 -0700, Ben Widawsky wrote: > Trivial. The spec lists these as hex, so do the same here to make > debugging easier. > > Fixes: 8adaf747c9f0b ("cxl/mem: Find device capabilities") > Signed-off-by: Ben Widawsky > --- >  drivers/cxl/mem.c | 2 +- >  1 file changed, 1

Re: [PATCH v2] libnvdimm: Notify disk drivers to revalidate region read-only

On Tue, 2021-03-09 at 17:43 -0800, Dan Williams wrote: > Previous kernels allowed the BLKROSET to override the disk's read-only > status. With that situation fixed the pmem driver needs to rely on > notification events to reevaluate the disk read-only status after the > host region has been marked

Re: [RFC PATCH v3 02/16] cxl/acpi: Add an acpi_cxl module for the CXL interconnect

On Wed, 2021-01-13 at 13:40 +0100, Rafael J. Wysocki wrote: > On Tue, Jan 12, 2021 at 1:29 AM Ben Widawsky wrote: > > > > From: Vishal Verma > > > > Add an acpi_cxl module to coordinate the ACPI portions of the CXL > > (Compute eXpress Link) interconnect. This driver binds to ACPI0017 > >

Re: [RFC PATCH v3 02/16] cxl/acpi: Add an acpi_cxl module for the CXL interconnect

On Tue, 2021-01-12 at 18:43 +, Jonathan Cameron wrote: > On Mon, 11 Jan 2021 14:51:06 -0800 > Ben Widawsky wrote: > > > From: Vishal Verma > > > > Add an acpi_cxl module to coordinate the ACPI portions of the CXL > > (Compute eXpress Link) interconnect. This driver binds to ACPI0017 > >

Re: [PATCH] ACPI: NFIT: Fix flexible_array.cocci warnings

On Tue, 2021-01-05 at 13:03 -0800, Dan Williams wrote: > Julia and 0day report: > > Zero-length and one-element arrays are deprecated, see > Documentation/process/deprecated.rst > Flexible-array members should be used instead. > > However, a straight conversion to flexible arrays

Re: [RFC PATCH v2 00/14] CXL 2.0 Support

On Tue, 2020-12-08 at 16:24 -0800, Ben Widawsky wrote: > Changes since v1 [1] > > A few additions have been made: > - IOCTL (UAPI) interface has been added with commands > - Kernel docs have been created > - A new debug macro is introduced and sprinkled throughout. > > A deletion was made: >

Re: [RFC PATCH 0/9] CXL 2.0 Support

On Fri, 2020-12-04 at 10:12 -0800, Ben Widawsky wrote: > Hi Chris. > > On 20-12-04 12:40:03, Chris Browy wrote: [..] > > >acpidump indicates the CXL0 and CXLM devices but no SRAT or HMAT tables > > are > >in the dump which is curious. > > I don't typically use HMAT, but I do have an

Re: [PATCH 1/1] ACPI/nfit: correct the badrange to be reported in nfit_handle_mce()

On Wed, 2020-11-18 at 16:41 +0800, Zhen Lei wrote: > The badrange to be reported should always cover mce->addr. > > Signed-off-by: Zhen Lei > --- > drivers/acpi/nfit/mce.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Ah good find, agreed with Dan that this is stable material. Minor

Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect

On Mon, 2020-11-16 at 17:59 +, Jonathan Cameron wrote: > On Tue, 10 Nov 2020 21:43:48 -0800 > Ben Widawsky wrote: > > > From: Vishal Verma > > > > Add an acpi_cxl module to coordinate the ACPI portions of the CXL > > (Compute eXpress Link) interconnect. This driver binds to ACPI0017 > >

Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect

On Wed, 2020-11-11 at 07:34 +, h...@infradead.org wrote: > On Wed, Nov 11, 2020 at 07:30:34AM +0000, Verma, Vishal L wrote: > > Hi Christpph, > > > > I thought 100 col. lines were acceptable now. > > Quote from the coding style document: > > "The pre

Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect

On Wed, 2020-11-11 at 07:10 +, Christoph Hellwig wrote: > On Tue, Nov 10, 2020 at 09:43:48PM -0800, Ben Widawsky wrote: > > +menuconfig CXL_BUS > > + tristate "CXL (Compute Express Link) Devices Support" > > + help > > + CXL is a bus that is electrically compatible with PCI-E, but

[GIT PULL] libnvdimm fix for v5.9-rc5

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git tags/libnvdimm-fix-v5.9-rc5 ...to receive another fix for detection of DAX support for block devices. The previous fix in this area (merged in -rc3) was incomplete, and this should finally address all the

[GIT PULL] libnvdimm fixes for v5.9-rc3

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git tags/libnvdimm-fix-v5.9-rc3 ...to receive a couple of minor fixes for things merged in 5.9-rc1. One is an out-of-bounds access caught by KASAN, and the second is a tweak to some overzealous logging about

Re: 回复: [PATCH v2] libnvdimm: KASAN: global-out-of-bounds Read in internal_create_group

On Wed, 2020-08-19 at 03:23 +, Zhang, Qiang wrote: > cc: Dan Williams > Please review. Hi Qiang, I've got this queued up, I'll submit it for -rc2. Thanks, -Vishal > > > 发件人: linux-kernel-ow...@vger.kernel.org > 代表 qiang.zh...@windriver.com >

Re: [PATCH] acpi/nfit: Use kobj_to_dev() instead

On Fri, 2020-08-14 at 17:28 +0200, Rafael J. Wysocki wrote: > On Thu, Aug 13, 2020 at 4:54 AM Wang Qing wrote: > > Use kobj_to_dev() instead of container_of() > > > > Signed-off-by: Wang Qing > > LGTM > > Dan, any objections? Looks good to me - you can add: Acked-by: Vishal Verma > > > ---

[GIT PULL] libnvdimm for v5.9

Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/ tags/libnvdimm-for-5.9 ...to receive a new feature in libnvdimm - 'Runtime Firmware Activation', and a few small cleanups and fixes in libnvdimm and DAX. You'd normally receive this pull request from

Re: [PATCH] ACPI: Replace HTTP links with HTTPS ones

On Fri, 2020-07-17 at 20:24 +0200, Alexander A. Klimov wrote: > Rationale: > Reduces attack surface on kernel devs opening the links for MITM > as HTTPS traffic is much harder to manipulate. > > Deterministic algorithm: > For each file: > If not .svg: > For each line: > If doesn't

Re: [PATCH v4 2/2] ACPICA: Preserve memory opregion mappings

On Mon, 2020-06-29 at 18:33 +0200, Rafael J. Wysocki wrote: > From: "Rafael J. Wysocki" > > The ACPICA's strategy with respect to the handling of memory mappings > associated with memory operation regions is to avoid mapping the > entire region at once which may be problematic at least in

Re: [RFC] Memory Tiering

On Thu, 2019-10-17 at 07:17 -0700, Dave Hansen wrote: > On 10/17/19 1:07 AM, David Hildenbrand wrote: > > Very interesting topic. I heard similar demand from HPC folks > > (especially involving other memory types ("tiers")). There, I think > > you often want to let the application manage that.

Re: [PATCH 11/13] nvdimm: Use more common logic testing styles and bare ; positions

On Wed, 2019-09-11 at 19:54 -0700, Joe Perches wrote: > Avoid using uncommon logic testing styles to make the code a > bit more like other kernel code. > > e.g.: > if (foo) { > ; > } else { > > } > > is typically written > > if (!foo) { >

Re: [Ksummit-discuss] [PATCH v2 2/3] Maintainer Handbook: Maintainer Entry Profile

On Wed, 2019-09-11 at 08:48 -0700, Dan Williams wrote: > diff --git a/MAINTAINERS b/MAINTAINERS > index 3f171339df53..e5d111a86e61 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -98,6 +98,10 @@ Descriptions of section entries: > Obsolete:Old code. Something tagged obsolete

Re: [PATCH] libnvdimm, region: Use struct_size() in kzalloc()

On Wed, 2019-08-28 at 14:36 -0500, Gustavo A. R. Silva wrote: > struct_size() does not apply to those scenarios. See below... > > > [1]: > > https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git/tree/drivers/nvdimm/region_devs.c#n1030 > > struct_size() only applies to structures of

Re: [PATCH] libnvdimm, region: Use struct_size() in kzalloc()

On Mon, 2019-06-10 at 16:06 -0500, Gustavo A. R. Silva wrote: > One of the more common cases of allocation size calculations is > finding > the size of a structure that has a zero-sized array at the end, along > with memory for some number of elements for that array. For example: > > struct

Re: [PATCH 2/2] drivers/dax/kmem: give a warning if CONFIG_DEV_DAX_PMEM_COMPAT is enabled

On Thu, 2019-08-22 at 14:55 -0400, Jeff Moyer wrote: > > When using daxctl to online memory, you already get the following > message: > > libdaxctl: daxctl_dev_disable: dax0.0: error: device model is dax-class > > That's still not very helpful. It would be better if the message > suggested a

Re: [PATCH v2 4/7] libnvdimm/bus: Prepare the nd_ioctl() path to be re-entrant

On Wed, 2019-07-17 at 18:08 -0700, Dan Williams wrote: > In preparation for not holding a lock over the execution of > nd_ioctl(), > update the implementation to allow multiple threads to be attempting > ioctls at the same time. The bus lock still prevents multiple in- > flight > ->ndctl()

Re: [PATCH v2 3/7] libnvdimm/region: Register badblocks before namespaces

On Wed, 2019-07-17 at 18:08 -0700, Dan Williams wrote: > Namespace activation expects to be able to reference region badblocks. > The following warning sometimes triggers when asynchronous namespace > activation races in front of the completion of namespace probing. Move > all possible namespace

Re: [RESEND PATCH] nvdimm: fix some compilation warnings

On Wed, 2019-06-26 at 17:00 -0400, Qian Cai wrote: > > Verma, are you still working on this? I can still see this warning in the > latest > linux-next. > > drivers/nvdimm/btt.c: In function 'btt_read_pg': > drivers/nvdimm/btt.c:1272:8: warning: variable 'rc' set but not used >

Re: [PATCH 3/6] libnvdimm/region: Register badblocks before namespaces

On Tue, 2019-06-11 at 16:25 -0700, Dan Williams wrote: > Namespace activation expects to be able to reference region badblocks. > The following warning sometimes triggers when asynchronous namespace > activation races in front of the completion of namespace probing. Move > all possible namespace

Re: [PATCH] mm, memory-failure: clarify error message

On Thu, 2019-05-16 at 22:08 -0600, Jane Chu wrote: > Some user who install SIGBUS handler that does longjmp out > therefore keeping the process alive is confused by the error > message > "[188988.765862] Memory failure: 0x1840200: Killing >cellsrv:33395 due to hardware memory corruption" >

Re: [RESEND PATCH] nvdimm: fix some compilation warnings

On Wed, 2019-05-15 at 16:25 -0700, Dan Williams wrote: > > > diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c > > index 4671776f5623..9f02a99cfac0 100644 > > --- a/drivers/nvdimm/btt.c > > +++ b/drivers/nvdimm/btt.c > > @@ -1269,11 +1269,9 @@ static int btt_read_pg(struct btt *btt, struct

Re: [RESEND PATCH] nvdimm: fix some compilation warnings

On Wed, 2019-05-15 at 17:26 -0700, Dan Williams wrote: > On Wed, May 15, 2019 at 5:25 PM Verma, Vishal L > wrote: > > On Wed, 2019-05-15 at 16:25 -0700, Dan Williams wrote: > > > > diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c > > > > ind

Re: [v5 0/3] "Hotremove" persistent memory

On Thu, 2019-05-02 at 14:43 -0400, Pavel Tatashin wrote: > The series of operations look like this: > > 1. After boot restore /dev/pmem0 to ramdisk to be consumed by apps. >and free ramdisk. > 2. Convert raw pmem0 to devdax >ndctl create-namespace --mode devdax --map mem -e namespace0.0

Re: [PATCH] nvdimm: btt_devs: fix a NULL pointer dereference and a memory leak

On Tue, 2019-03-12 at 03:15 -0500, Kangjie Lu wrote: > In case kmemdup fails, the fix releases resources and returns to > avoid the NULL pointer dereference. > Also, the error paths in the following code should release > resources to avoid memory leaks. > > Signed-off-by: Kangjie Lu > --- >

Re: [PATCH] libnvdimm/namespace: Clean up holder_class_store()

On Mon, 2019-03-04 at 12:14 -0800, Dan Williams wrote: > Use sysfs_streq() in place of open-coded strcmp()'s that check for an > optional "\n" at the end of the input. > > Signed-off-by: Dan Williams > --- > drivers/nvdimm/namespace_devs.c |8 > 1 file changed, 4 insertions(+), 4

Re: [PATCH] acpi/nfit: Fix bus command validation

On Thu, 2019-02-07 at 15:57 -0800, Dan Williams wrote: > Commit 11189c1089da "acpi/nfit: Fix command-supported detection" broke > ND_CMD_CALL for bus-level commands. The "func = cmd" assumption is only > valid for: > > ND_CMD_ARS_CAP > ND_CMD_ARS_START > ND_CMD_ARS_STATUS >

Re: [PATCH 5/5] dax: "Hotplug" persistent memory for use like normal RAM

On Fri, 2019-01-25 at 09:18 -0800, Dan Williams wrote: > On Fri, Jan 25, 2019 at 12:20 AM Du, Fan wrote: > > Dan > > > > Thanks for the insights! > > > > Can I say, the UCE is delivered from h/w to OS in a single way in > > case of machine > > check, only PMEM/DAX stuff filter out UC address

Re: [PATCH 1/2] tools/testing/nvdimm: Align test resources to 128M

On Sat, 2018-11-24 at 10:46 -0800, Dan Williams wrote: > In preparation for libnvdimm growing new restrictions to detect section > conflicts between persistent memory regions, enable nfit_test to > allocate aligned resources. Use a gen_pool to allocate nfit_test's fake > resources in a separate

Re: [PATCH 1/2] tools/testing/nvdimm: Align test resources to 128M

On Sat, 2018-11-24 at 10:46 -0800, Dan Williams wrote: > In preparation for libnvdimm growing new restrictions to detect section > conflicts between persistent memory regions, enable nfit_test to > allocate aligned resources. Use a gen_pool to allocate nfit_test's fake > resources in a separate

Re: [PATCH] libnvdimm, bus: check id immediately following ida_simple_get

On Fri, 2018-08-03 at 08:08 -0400, Ocean He wrote: > From: Ocean He > > The id check was not executed immediately following ida_simple_get. > Just > change the codes position, without function change. > > Signed-off-by: Ocean He > --- > drivers/nvdimm/bus.c | 4 ++-- > 1 file changed, 2

Re: [PATCH] libnvdimm, bus: check id immediately following ida_simple_get

On Fri, 2018-08-03 at 08:08 -0400, Ocean He wrote: > From: Ocean He > > The id check was not executed immediately following ida_simple_get. > Just > change the codes position, without function change. > > Signed-off-by: Ocean He > --- > drivers/nvdimm/bus.c | 4 ++-- > 1 file changed, 2

Re: [PATCH] libnvdimm: rework region badblocks clearing

On Mon, 2017-05-01 at 09:38 -0700, Dan Williams wrote: > On Mon, May 1, 2017 at 9:20 AM, Kani, Toshimitsu > wrote: > > On Mon, 2017-05-01 at 09:16 -0700, Dan Williams wrote: > > > On Mon, May 1, 2017 at 9:12 AM, Kani, Toshimitsu > > com> > > > wrote: > > > >

Re: [PATCH] libnvdimm: rework region badblocks clearing

On Mon, 2017-05-01 at 09:38 -0700, Dan Williams wrote: > On Mon, May 1, 2017 at 9:20 AM, Kani, Toshimitsu > wrote: > > On Mon, 2017-05-01 at 09:16 -0700, Dan Williams wrote: > > > On Mon, May 1, 2017 at 9:12 AM, Kani, Toshimitsu > > com> > > > wrote: > > > > On Mon, 2017-05-01 at 08:52 -0700,

Re: [PATCH] block: hide badblocks attribute by default

On Thu, 2017-04-27 at 14:46 -0700, Dan Williams wrote: > Commit 99e6608c9e74 "block: Add badblock management for gendisks" > allowed for drivers like pmem and software-raid to advertise a list of > bad media areas. However, it inadvertently added a 'badblocks' to all > block devices. Lets clean

Re: [PATCH] block: hide badblocks attribute by default

On Thu, 2017-04-27 at 14:46 -0700, Dan Williams wrote: > Commit 99e6608c9e74 "block: Add badblock management for gendisks" > allowed for drivers like pmem and software-raid to advertise a list of > bad media areas. However, it inadvertently added a 'badblocks' to all > block devices. Lets clean

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Thu, 2017-04-13 at 13:31 +0200, Borislav Petkov wrote: > On Thu, Apr 13, 2017 at 12:29:25AM +0200, Borislav Petkov wrote: > > On Wed, Apr 12, 2017 at 03:26:19PM -0700, Luck, Tony wrote: > > > We can futz with that and have them specify which chain (or both) > > > that they want to be added to.

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Thu, 2017-04-13 at 13:31 +0200, Borislav Petkov wrote: > On Thu, Apr 13, 2017 at 12:29:25AM +0200, Borislav Petkov wrote: > > On Wed, Apr 12, 2017 at 03:26:19PM -0700, Luck, Tony wrote: > > > We can futz with that and have them specify which chain (or both) > > > that they want to be added to.

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, 2017-04-12 at 22:22 +0200, Borislav Petkov wrote: > On Wed, Apr 12, 2017 at 01:59:03PM -0600, Vishal Verma wrote: > > I don't think we can do anything about the panic path errors. > > Then the fix should be a lot easier: > > --- > diff --git a/drivers/acpi/nfit/mce.c

Re: [RFC PATCH] x86, mce: change the mce notifier to 'blocking' from 'atomic'

On Wed, 2017-04-12 at 22:22 +0200, Borislav Petkov wrote: > On Wed, Apr 12, 2017 at 01:59:03PM -0600, Vishal Verma wrote: > > I don't think we can do anything about the panic path errors. > > Then the fix should be a lot easier: > > --- > diff --git a/drivers/acpi/nfit/mce.c

Re: [PATCH] libnvdimm: use consistent naming for request_mem_region()

On Mon, 2016-11-28 at 11:25 -0800, Dan Williams wrote: > Here is an example /proc/iomem listing for a system with 2 > namespaces, > one in "sector" mode and one in "memory" mode: > >   1fc00-2fbff : Persistent Memory (legacy) > 1fc00-2fbff : namespace1.0 >  

Re: [PATCH] libnvdimm: use consistent naming for request_mem_region()

On Mon, 2016-11-28 at 11:25 -0800, Dan Williams wrote: > Here is an example /proc/iomem listing for a system with 2 > namespaces, > one in "sector" mode and one in "memory" mode: > >   1fc00-2fbff : Persistent Memory (legacy) > 1fc00-2fbff : namespace1.0 >  

Re: [PATCH] acpi, nfit: fix acpi event notifications for nfit

On Thu, 2016-08-18 at 12:54 -0700, Dan Williams wrote: > On Thu, Aug 18, 2016 at 12:52 PM, Linda Knippers om> wrote: > > > > > > > > On 8/18/2016 3:48 PM, Dan Williams wrote: > > > > > > On Thu, Aug 18, 2016 at 11:48 AM, Vishal Verma > > el.com>

Re: [PATCH] acpi, nfit: fix acpi event notifications for nfit

On Thu, 2016-08-18 at 12:54 -0700, Dan Williams wrote: > On Thu, Aug 18, 2016 at 12:52 PM, Linda Knippers om> wrote: > > > > > > > > On 8/18/2016 3:48 PM, Dan Williams wrote: > > > > > > On Thu, Aug 18, 2016 at 11:48 AM, Vishal Verma > > el.com> wrote: > > > > > > > > The nfit driver had an

Re: [PATCH v4 0/6] Add alignment check for DAX mount

On Fri, 2016-05-20 at 14:50 +, Kani, Toshimitsu wrote: > On Thu, 2016-05-19 at 18:37 -0500, Eric Sandeen wrote: > > > > On 5/10/16 11:23 AM, Toshi Kani wrote: > > > > > > > > > When a partition is not aligned by 4KB, mount -o dax succeeds, > > Sorry for being late, but - > > > > Shouldn't

Re: [PATCH v4 0/6] Add alignment check for DAX mount

On Fri, 2016-05-20 at 14:50 +, Kani, Toshimitsu wrote: > On Thu, 2016-05-19 at 18:37 -0500, Eric Sandeen wrote: > > > > On 5/10/16 11:23 AM, Toshi Kani wrote: > > > > > > > > > When a partition is not aligned by 4KB, mount -o dax succeeds, > > Sorry for being late, but - > > > > Shouldn't

Re: [PATCH v7 4/6] dax: export a low-level __dax_zero_page_range helper

On Thu, 2016-05-12 at 10:41 +0200, Jan Kara wrote: > On Wed 11-05-16 15:08:50, Vishal Verma wrote: > > > > From: Christoph Hellwig > > > > This allows XFS to perform zeroing using the iomap infrastructure > > and > > avoid buffer heads. > > > > [vishal: fix conflicts with

Re: [PATCH v7 4/6] dax: export a low-level __dax_zero_page_range helper

On Thu, 2016-05-12 at 10:41 +0200, Jan Kara wrote: > On Wed 11-05-16 15:08:50, Vishal Verma wrote: > > > > From: Christoph Hellwig > > > > This allows XFS to perform zeroing using the iomap infrastructure > > and > > avoid buffer heads. > > > > [vishal: fix conflicts with dax-error-handling] >

Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible

On Tue, 2016-05-10 at 12:49 -0600, Vishal Verma wrote: >  ... > @@ -1240,11 +1254,16 @@ int dax_zero_page_range(struct inode *inode, > loff_t from, unsigned length, >   .size = PAGE_SIZE, >   }; >   > - if (dax_map_atomic(bdev, ) < 0) > -

Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible

On Tue, 2016-05-10 at 12:49 -0600, Vishal Verma wrote: >  ... > @@ -1240,11 +1254,16 @@ int dax_zero_page_range(struct inode *inode, > loff_t from, unsigned length, >   .size = PAGE_SIZE, >   }; >   > - if (dax_map_atomic(bdev, ) < 0) > -

Re: [PATCH v6 4/5] dax: for truncate/hole-punch, do zeroing through the driver if possible

On Wed, 2016-05-11 at 10:15 +0200, Jan Kara wrote: > On Tue 10-05-16 12:49:15, Vishal Verma wrote: > > > > In the truncate or hole-punch path in dax, we clear out sub-page > > ranges. > > If these sub-page ranges are sector aligned and sized, we can do the > > zeroing through the driver instead

  1   2   >