Re: [PATCH] drivers: nvdimm: fix memleak

EXPORT_SYMBOL_GPL(register_nvdimm_pmu); > void unregister_nvdimm_pmu(struct nvdimm_pmu *nd_pmu) > { > perf_pmu_unregister(_pmu->pmu); > nvdimm_pmu_free_hotplug_memory(nd_pmu); > + kfree(nd_pmu->pmu.attr_groups); > kfree(nd_pmu); > } > EXPORT_SYMBOL_GPL(unregister_nvdimm_pmu); Reviewed-by: Jeff Moyer

Re: [PATCH] drivers: nvdimm: fix dereference after free

= perf_pmu_register(_pmu->pmu, nd_pmu->pmu.name, -1); > if (rc) { > - kfree(nd_pmu->pmu.attr_groups); > nvdimm_pmu_free_hotplug_memory(nd_pmu); > + kfree(nd_pmu->pmu.attr_groups); > return rc; > } > > pr_info("%s NVDIMM performance monitor support registered\n", Reviewed-by: Jeff Moyer

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

David Hildenbrand writes: > On 13.07.23 21:12, Jeff Moyer wrote: >> David Hildenbrand writes: >> >>> On 16.06.23 00:00, Vishal Verma wrote: >>>> The dax/kmem driver can potentially hot-add large amounts of memory >>>> originating from CX

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

David Hildenbrand writes: > 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 regular system memory >> available

Re: [PATCH v2] libnvdimm/region: Allow setting align attribute on regions without mappings

Tyler Hicks writes: > The alignment constraint for namespace creation in a region was > increased, from 2M to 16M, for non-PowerPC architectures in v5.7 with > commit 2522afb86a8c ("libnvdimm/region: Introduce an 'align' > attribute"). The thought behind the change was that region alignment >

Re: [RFC PATCH rdma-next 01/10] RDMA: mr: Introduce is_pmem

"Li, Zhijian" writes: > Copied to nvdimm list > > Thanks > > Zhijian > > > on 2022/1/6 14:12, Li Zhijian wrote: >> >> Add Dan to the party :) >> >> May i know whether there is any existing APIs to check whether >> a va/page backs to a nvdimm/pmem ? I don't know of one. You could try

Re: [block] 52f019d43c: ndctl.test-libndctl.fail

Christoph Hellwig writes: > Dan, > > can you make any sense of thos report? > > name='nfit_test' > path='/lib/modules/5.11.0-rc5-3-g52f019d43c22/extra/test/nfit_test.ko' >> check_set_config_data: dimm: 0 read2 data miscompare: 0 >> check_set_config_data: dimm: 0x1 read2 data miscompare: 0 >>

Re: [PATCH] direct-io: Using kmem_cache_zalloc() instead of kmem_cache_alloc() and memset()

fields placed after it) are not zeroed out at * allocation time. Don't add new fields after pages[] unless you * wish that they not be zeroed. */ union { struct page *pages[DIO_PAGES]; /* page buffer */ struct work_struct complete

Re: [PATCH] ACPI: NFIT: Fix input validation of bus-family

!test_bit(family, _desc->bus_family_mask)) > return -EINVAL; > + family = array_index_nospec(family, > + NVDIMM_BUS_FAMILY_MAX + 1); > dsm_mask = acpi_desc->family_dsm_mask[family]; > guid = to_nfit_bus_uuid(family); > } else { Reviewed-by: Jeff Moyer

Re: [PATCH] fs/dax: Fix pmd vs pte conflict detection

Dan Williams writes: > Check for NULL entries before checking the entry order, otherwise NULL > is misinterpreted as a present pte conflict. The 'order' check needs to > happen before the locked check as an unlocked entry at the wrong order > must fallback to lookup the correct order. Please

Re: [PATCH 00/13] nvdimm: Use more common kernel coding style

Joe Perches writes: > Rather than have a local coding style, use the typical kernel style. The coding style isn't that different from the core kernel, and it's still quite readable. I'd rather avoid the churn and the risk of introducing regressions. This will also make backports to stable

Re: [PATCH v2 0/3] libnvdimm/security: Enumerate the frozen state and other cleanups

Dan Williams writes: > Changes since v1 [1]: > - Cleanup patch1, simplify flags return in the overwrite case and > consolidate frozen-state cases (Jeff) > - Clarify the motivation for patch2 (Jeff) > - Collect Dave's Reviewed-by The series tests out fine for me. Thanks, Dan! -Jeff > >

Re: [PATCH v2 2/3] libnvdimm/security: Tighten scope of nvdimm->busy vs security operations

rather than each of the helper routines to enable > freeze to be run regardless of busy state. > > Reviewed-by: Dave Jiang > Signed-off-by: Dan Williams Reviewed-by: Jeff Moyer > --- > drivers/nvdimm/dimm_devs.c | 33 - > drivers/nvdimm/sec

Re: [PATCH v2 1/3] libnvdimm/security: Introduce a 'frozen' attribute

ns need 'frozen' to show up in the primary 'security' > attribute. The expectation is that communicating 'frozen' is mostly a > helper for debug and status monitoring. > > Reviewed-by: Dave Jiang > Reported-by: Jeff Moyer > Signed-off-by: Dan Williams Reviewed-by: J

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

Jia He writes: > commit c221c0b0308f ("device-dax: "Hotplug" persistent memory for use > like normal RAM") helps to add persistent memory as normal RAM blocks. > But this driver doesn't work if CONFIG_DEV_DAX_PMEM_COMPAT is enabled. > > Here is the debugging call trace when

Re: [PATCH] aio: Fix io_pgetevents() struct __compat_aio_sigset layout

r compat_uptr_t instead of a compat_sigset_t pointer. > > Fixes: 7a074e96 ("aio: implement io_pgetevents") > Signed-off-by: Guillem Jover Looks good, thanks for finding and fixing this! Reviewed-by: Jeff Moyer > --- > fs/aio.c | 6 +++--- > 1 file changed, 3 insertions

Re: [PATCH] aio: remove redundant assignment to variable ret

*req, const struct > iocb *iocb, > file = req->ki_filp; > if (unlikely(!(file->f_mode & FMODE_READ))) > return -EBADF; > - ret = -EINVAL; > if (unlikely(!file->f_op->read_iter)) > return -EINVAL; Acked-by: Jeff Moyer

Re: [PATCH 2/3] libnvdimm/security: Tighten scope of nvdimm->busy vs security operations

Dan Williams writes: > On Fri, Aug 16, 2019 at 1:49 PM Jeff Moyer wrote: >> >> Dan Williams writes: >> >> > The blanket blocking of all security operations while the DIMM is in >> > active use in a region is too restrictive. The only security operations &

Re: [PATCH 3/3] libnvdimm/security: Consolidate 'security' operations

ects, just move the > __security_store() entry point to live with the helpers. > > Cc: Dave Jiang > Signed-off-by: Dan Williams Fine by me. Acked-by: Jeff Moyer

Re: [PATCH 2/3] libnvdimm/security: Tighten scope of nvdimm->busy vs security operations

Dan Williams writes: > The blanket blocking of all security operations while the DIMM is in > active use in a region is too restrictive. The only security operations > that need to be aware of the ->busy state are those that mutate the > state of data, i.e. erase and overwrite. > > Refactor the

Re: [PATCH 1/3] libnvdimm/security: Introduce a 'frozen' attribute

ns need 'frozen' to show up in the primary 'security' > attribute. The expectation is that communicating 'frozen' is mostly a > helper for debug and status monitoring. > > Cc: Dave Jiang > Reported-by: Jeff Moyer > Signed-off-by: Dan Williams > --- > drivers/acpi/nfit

Re: [PATCH] aio: add timeout validity check for io_[p]getevents

Al Viro writes: > On Mon, Jul 29, 2019 at 10:57:41AM -0400, Jeff Moyer wrote: >> Al, can you take this through your tree? > > Umm... Can do, but I had an impression that Arnd and Deepa > had a tree for timespec-related work. OTOH, it had been > relatively quiet last cycle

Re: [PATCH] aio: add timeout validity check for io_[p]getevents

Al, can you take this through your tree? Thanks, Jeff Jeff Moyer writes: > "zhangyi (F)" writes: > >> io_[p]getevents syscall should return -EINVAL if if timeout is out of >> range, add this validity check. >> >> Signed-off-by: zhangyi (F) >>

Re: [PATCH] aio: add timeout validity check for io_[p]getevents

gt; + return ret; > + until = timespec64_to_ktime(*ts); > + } > + > + ioctx = lookup_ioctx(ctx_id); > if (likely(ioctx)) { > if (likely(min_nr <= nr && min_nr >= 0)) > ret = read_eve

Re: [PATCH -next] mm/hotplug: skip bad PFNs from pfn_to_online_page()

"Aneesh Kumar K.V" writes: > On 6/14/19 10:06 PM, Dan Williams wrote: >> On Fri, Jun 14, 2019 at 9:26 AM Aneesh Kumar K.V >> wrote: > >>> Why not let the arch >>> arch decide the SUBSECTION_SHIFT and default to one subsection per >>> section if arch is not enabled to work with subsection. >> >>

Re: [PATCH 7/7] libnvdimm/pfn: Fix 'start_pad' implementation

Dan Williams writes: >> Great! Now let's create another one. >> >> # ndctl create-namespace -m fsdax -s 132m >> libndctl: ndctl_pfn_enable: pfn1.1: failed to enable >> Error: namespace1.2: failed to enable >> >> failed to create namespace: No such device or address >> >> (along with a kernel

Re: [PATCH 7/7] libnvdimm/pfn: Fix 'start_pad' implementation

Dan Williams writes: >> > However, to fix this situation a non-backwards compatible change >> > needs to be made to the interpretation of the nd_pfn info-block. >> > ->start_pad needs to be accounted in ->map.map_offset (formerly >> > ->data_offset), and ->map.map_base (formerly ->phys_addr)

Re: [PATCH 7/7] libnvdimm/pfn: Fix 'start_pad' implementation

Hi, Dan, Thanks for the comprehensive write-up. Comments below. Dan Williams writes: > In the beginning the pmem driver simply passed the persistent memory > resource range to memremap and was done. With the introduction of > devm_memremap_pages() and vmem_altmap the implementation needed to

Re: [PATCH 0/7] libnvdimm/pfn: Fix section-alignment padding

Dan Williams writes: > On Tue, Feb 12, 2019 at 1:37 PM Dan Williams wrote: >> >> Lately Linux has encountered platforms that collide Persistent Memory >> regions between each other, specifically cases where ->start_pad needed >> to be non-zero. This lead to commit ae86cbfef381 "libnvdimm, pfn:

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

s case and call it in the common path. > > Fixes: 11189c1089da ("acpi/nfit: Fix command-supported detection") > Cc: > Cc: Vishal Verma > Reported-by: Grzegorz Burzynski > Signed-off-by: Dan Williams Tricky code path, eh? Tested-by: Jeff Moyer -Jeff > --- &g

Re: [RFC PATCH] aio: add check for timeout to aviod invalid value

: KTIME_MAX; > + ktime_t until; > struct kioctx *ioctx = lookup_ioctx(ctx_id); > long ret = -EINVAL; > > + if (ts && !timespec64_valid(ts)) > + return -EINVAL; > + > + until = ts ? timespec64_to_ktime(*ts) : KTIME_MAX; > + > if (likely(ioctx)) { > if (likely(min_nr <= nr && min_nr >= 0)) > ret = read_events(ioctx, min_nr, nr, events, until); Looks good to me. Thanks for fixing this. Reviewed-by: Jeff Moyer

Re: [PATCH] blk-mq: fix the cmd_flag_name array

FLAG_NAME(NOUNMAP), > CMD_FLAG_NAME(NOWAIT), > + CMD_FLAG_NAME(NOUNMAP), > + CMD_FLAG_NAME(HIPRI), > }; > #undef CMD_FLAG_NAME Acked-by: Jeff Moyer You might consider also adding a comment above the req_flag_bits enum noting that modifications also need to be propagated to cmd_flag_name.

Re: [PATCH 0/4] Allow persistent memory to be used like normal RAM

Keith Busch writes: >> Keith, you seem to be implying that there are platforms that won't >> support memory mode. Do you also have some insight into how customers >> want to use this, beyond my speculation? It's really frustrating to see >> patch sets like this go by without any real use cases

Re: [PATCH 0/4] Allow persistent memory to be used like normal RAM

Keith Busch writes: > On Thu, Jan 17, 2019 at 11:29:10AM -0500, Jeff Moyer wrote: >> Dave Hansen writes: >> > Persistent memory is cool. But, currently, you have to rewrite >> > your applications to use it. Wouldn't it be cool if you could >> > just have i

Re: [PATCH 0/4] Allow persistent memory to be used like normal RAM

Dave Hansen writes: > Persistent memory is cool. But, currently, you have to rewrite > your applications to use it. Wouldn't it be cool if you could > just have it show up in your system like normal RAM and get to > it like a slow blob of memory? Well... have I got the patch > series for you!

Re: [PATCH v3 0/2] acpi/nfit: Fix command-supported detection

Dan Williams writes: > Changes since v2 [1]: > * Don't allow ND_CMD_CALL to bypass dsm_mask restrictions (Jeff) > > [1]: https://lists.01.org/pipermail/linux-nvdimm/2019-January/019498.html > > --- > > One last resend to make sure all the last bits of thrash have settled. LGTM. Thanks! Jeff

Re: [PATCH v2 0/2] acpi/nfit: Fix command-supported detection

Dan Williams writes: > On Tue, Jan 15, 2019 at 6:16 AM Jeff Moyer wrote: >> >> Dan Williams writes: >> >> > Changes since v1 [1]: >> > * Include another patch make sure that function-number zero can be >> > safely used as an invalid function n

Re: [PATCH v2 0/2] acpi/nfit: Fix command-supported detection

ff) > * Collect a Tested-by from Sujith > [1]: https://lists.01.org/pipermail/linux-nvdimm/2019-January/019435.html For the series: Reviewed-by: Jeff Moyer Thanks, Dan! > > --- > > Quote patch2 changelog: > > The _DSM function number validation only happens to succeed

Re: [PATCH] acpi/nfit: Fix command-supported detection

Dan Williams writes: > On Mon, Jan 14, 2019 at 8:43 AM Dan Williams wrote: >> On Mon, Jan 14, 2019 at 7:19 AM Jeff Moyer wrote: > [..] >> > > + >> > > + if (cmd == ND_CMD_CALL) { >> > > + int i; >> > > + >&

Re: [PATCH] acpi/nfit: Fix command-supported detection

Dan Williams writes: > The _DSM function number validation only happens to succeed when the > generic Linux command number translation corresponds with a > DSM-family-specific function number. This breaks NVDIMM-N > implementations that correctly implement _LSR, _LSW, and _LSI, but do > not

Re: [PATCH] scsi: isci: initialize shost fully before calling scsi_add_host()

Intel SCU Linux support > Cc: Artur Paszkiewicz > Cc: "James E.J. Bottomley" > Cc: "Martin K. Petersen" > Cc: Christoph Hellwig > Cc: Jens Axboe > Cc: Jeff Moyer Nice job, and excellent commit message. We'll need a similar patch for lpfc. Reviewed-by: Jeff

Re: Regression in v5.0-rc1: Panic at boot

Hi, Logan, Logan Gunthorpe writes: > Hey, > > I found a regression in v5.0-rc1 this morning. My system panics on boot. > I've attached a log of the panic. > > I bisected to find the problematic commit is: > > Fixes: 9d037ad707ed ("block: remove req->timeout_list") > > But it makes no sense to

Re: [PATCH] aio: Convert ioctx_table to XArray

Jens Axboe writes: > On 12/11/18 11:02 AM, Jeff Moyer wrote: >> Matthew Wilcox writes: >> >>> On Tue, Dec 11, 2018 at 12:21:52PM -0500, Jeff Moyer wrote: >>>> I'm going to submit this version formally. If you're interested in >>>>

Re: [PATCH] aio: Convert ioctx_table to XArray

Matthew Wilcox writes: > On Tue, Dec 11, 2018 at 12:21:52PM -0500, Jeff Moyer wrote: >> I'm going to submit this version formally. If you're interested in >> converting the ioctx_table to xarray, you can do that separately from a >> security fix. I would include a

Re: [PATCH] aio: Convert ioctx_table to XArray

Jeff Moyer writes: > Jeff Moyer writes: > >> Matthew Wilcox writes: >> >>> This custom resizing array was vulnerable to a Spectre attack (speculating >>> off the end of an array to a user-controlled offset). The XArray is >>> not vulnera

Re: [PATCH] aio: Convert ioctx_table to XArray

Jeff Moyer writes: > Matthew Wilcox writes: > >> This custom resizing array was vulnerable to a Spectre attack (speculating >> off the end of an array to a user-controlled offset). The XArray is >> not vulnerable to Spectre as it always masks its lookups to be within &g

Re: [PATCH] aio: Convert ioctx_table to XArray

Jeff Moyer writes: > Matthew Wilcox writes: > >> This custom resizing array was vulnerable to a Spectre attack (speculating >> off the end of an array to a user-controlled offset). The XArray is >> not vulnerable to Spectre as it always masks its lookups to be within &g

Re: [PATCH] aio: Convert ioctx_table to XArray

Matthew Wilcox writes: > This custom resizing array was vulnerable to a Spectre attack (speculating > off the end of an array to a user-controlled offset). The XArray is > not vulnerable to Spectre as it always masks its lookups to be within > the bounds of the array. I'm not a big fan of

Re: [PATCH] aio: Convert ioctx_table to XArray

Matthew Wilcox writes: > This custom resizing array was vulnerable to a Spectre attack (speculating > off the end of an array to a user-controlled offset). The XArray is > not vulnerable to Spectre as it always masks its lookups to be within > the bounds of the array. I'm not a big fan of

Re: Very slow SYS_io_destroy()

Alex Richman writes: > Hi, > > I'm seeing some weirdness with AIO, specifically SYS_io_destroy() is > taking upwards of ~10 microseconds (~100 miliseconds) per call. > How long is that call expected to take?  I can see from the source Well, it waits for an RCU grace period. I would not

Re: Very slow SYS_io_destroy()

Alex Richman writes: > Hi, > > I'm seeing some weirdness with AIO, specifically SYS_io_destroy() is > taking upwards of ~10 microseconds (~100 miliseconds) per call. > How long is that call expected to take?  I can see from the source Well, it waits for an RCU grace period. I would not

Re: [PATCH v6 4/5] fs: blkdev set bio prio from kiocb prio

adam.manzana...@wdc.com writes: > From: Adam Manzanares <adam.manzana...@wdc.com> > > Now that kiocb has an ioprio field copy this over to the bio when it is > created from the kiocb. > > Signed-off-by: Adam Manzanares <adam.manzana...@wdc.com> Reviewed-by: Jeff Moy

Re: [PATCH v6 4/5] fs: blkdev set bio prio from kiocb prio

adam.manzana...@wdc.com writes: > From: Adam Manzanares > > Now that kiocb has an ioprio field copy this over to the bio when it is > created from the kiocb. > > Signed-off-by: Adam Manzanares Reviewed-by: Jeff Moyer Thanks! Jeff > --- > fs/block_dev.c | 2

Re: [PATCH v5 4/5] fs: blkdev set bio prio from kiocb prio

adam.manzana...@wdc.com writes: > From: Adam Manzanares > > Now that kiocb has an ioprio field copy this over to the bio when it is > created from the kiocb. > > Signed-off-by: Adam Manzanares > --- > fs/block_dev.c | 1 + > 1 file changed, 1

Re: [PATCH v5 4/5] fs: blkdev set bio prio from kiocb prio

adam.manzana...@wdc.com writes: > From: Adam Manzanares > > Now that kiocb has an ioprio field copy this over to the bio when it is > created from the kiocb. > > Signed-off-by: Adam Manzanares > --- > fs/block_dev.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/fs/block_dev.c

Re: [PATCH v5 3/5] fs: Add aio iopriority support

nction. > > Signed-off-by: Adam Manzanares <adam.manzana...@wdc.com> Reviewed-by: Jeff Moyer <jmo...@redhat.com> > --- > drivers/block/loop.c | 3 +++ > fs/aio.c | 16 > include/linux/fs.h | 3 +++ > includ

Re: [PATCH v5 3/5] fs: Add aio iopriority support

field. > > We set the blkdev bio iopriority unconditionally, so we need to guarantee the > kiocb is initialized properly. Added changes to the loopback driver and > init_sync_kiocb to achieve this. > > This patch depends on block: add ioprio_check_cap function. > > Signed-o

Re: [PATCH v5 5/5] fs: iomap dio set bio prio from kiocb prio

adam.manzana...@wdc.com writes: > From: Adam Manzanares <adam.manzana...@wdc.com> > > Now that kiocb has an ioprio field copy this over to the bio when it is > created from the kiocb during direct IO. > > Signed-off-by: Adam Manzanares <adam.manzana...@wdc.com>

Re: [PATCH v5 5/5] fs: iomap dio set bio prio from kiocb prio

adam.manzana...@wdc.com writes: > From: Adam Manzanares > > Now that kiocb has an ioprio field copy this over to the bio when it is > created from the kiocb during direct IO. > > Signed-off-by: Adam Manzanares Reviewed-by: Jeff Moyer > --- > fs/iomap.c | 1 + >

Re: [PATCH v5 4/5] fs: blkdev set bio prio from kiocb prio

adam.manzana...@wdc.com writes: > From: Adam Manzanares <adam.manzana...@wdc.com> > > Now that kiocb has an ioprio field copy this over to the bio when it is > created from the kiocb. > > Signed-off-by: Adam Manzanares <adam.manzana...@wdc.com> Reviewed-by:

Re: [PATCH v5 4/5] fs: blkdev set bio prio from kiocb prio

adam.manzana...@wdc.com writes: > From: Adam Manzanares > > Now that kiocb has an ioprio field copy this over to the bio when it is > created from the kiocb. > > Signed-off-by: Adam Manzanares Reviewed-by: Jeff Moyer > --- > fs/block_dev.c | 1 + > 1 file chang

Re: [PATCH v5 1/5] block: add ioprio_check_cap function

; Reviewed-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Jeff Moyer <jmo...@redhat.com> > --- > block/ioprio.c | 22 -- > include/linux/ioprio.h | 2 ++ > 2 files changed, 18 insertions(+), 6 deletions(-) > > diff --git a/block/ioprio.c b/bloc

Re: [PATCH v5 1/5] block: add ioprio_check_cap function

has sufficient > priviledges to submit IOPRIO_RT commands. This patch creates the > ioprio_check_cap function to be used by the ioprio_set system call and also by > the aio interface. > > Signed-off-by: Adam Manzanares > Reviewed-by: Christoph Hellwig Reviewed-by: Jeff Moyer >

Re: [PATCH v5 0/5] AIO add per-command iopriority

Hi, Adam, adam.manzana...@wdc.com writes: > From: Adam Manzanares > > This is the per-I/O equivalent of the ioprio_set system call. > See the following link for performance implications on a SATA HDD: > https://lkml.org/lkml/2016/12/6/495 > > First patch factors

Re: [PATCH v5 0/5] AIO add per-command iopriority

Hi, Adam, adam.manzana...@wdc.com writes: > From: Adam Manzanares > > This is the per-I/O equivalent of the ioprio_set system call. > See the following link for performance implications on a SATA HDD: > https://lkml.org/lkml/2016/12/6/495 > > First patch factors ioprio_check_cap function out of

Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone

Dan Williams <dan.j.willi...@intel.com> writes: > On Mon, May 7, 2018 at 12:08 PM, Jeff Moyer <jmo...@redhat.com> wrote: >> Dan Williams <dan.j.willi...@intel.com> writes: >> >>> On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox <wi...@infradead.org>

Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone

Dan Williams writes: > On Mon, May 7, 2018 at 12:08 PM, Jeff Moyer wrote: >> Dan Williams writes: >> >>> On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox wrote: >>>> On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote: >>>>> Traditi

Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone

Dan Williams writes: > On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox wrote: >> On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote: >>> Traditionally, NVDIMMs are treated by mm(memory management) subsystem as >>> DEVICE zone, which is a

Re: [RFC PATCH v1 0/6] use mm to manage NVDIMM (pmem) zone

Dan Williams writes: > On Mon, May 7, 2018 at 11:46 AM, Matthew Wilcox wrote: >> On Mon, May 07, 2018 at 10:50:21PM +0800, Huaisheng Ye wrote: >>> Traditionally, NVDIMMs are treated by mm(memory management) subsystem as >>> DEVICE zone, which is a virtual zone and both its start and end of pfn

Re: [PATCH v2] fs: Add aio iopriority support for block_dev

Hi, Adam, adam.manzana...@wdc.com writes: > From: Adam Manzanares > > This is the per-I/O equivalent of the ioprio_set system call. > > When IOCB_FLAG_IOPRIO is set on the iocb aio_flags field, then we set the > newly added kiocb ki_ioprio field to the value in the iocb

Re: [PATCH v2] fs: Add aio iopriority support for block_dev

Hi, Adam, adam.manzana...@wdc.com writes: > From: Adam Manzanares > > This is the per-I/O equivalent of the ioprio_set system call. > > When IOCB_FLAG_IOPRIO is set on the iocb aio_flags field, then we set the > newly added kiocb ki_ioprio field to the value in the iocb aio_reqprio field. > >

Re: [PATCH] pmem: fix badblocks population for raw mode

r raw mode. > > Fixes: e8d513483300 ("memremap: change devm_memremap_pages interface to use > struct dev_pagemap") > Signed-off-by: Toshi Kani <toshi.k...@hpe.com> > Cc: Christoph Hellwig <h...@lst.de> > Cc: Dan Williams <dan.j.willi...@intel.com> > Cc

Re: [PATCH] pmem: fix badblocks population for raw mode

00 ("memremap: change devm_memremap_pages interface to use > struct dev_pagemap") > Signed-off-by: Toshi Kani > Cc: Christoph Hellwig > Cc: Dan Williams > Cc: Reviewed-by: Jeff Moyer > --- > drivers/nvdimm/pmem.c |4 +++- > 1 file changed, 3 inser

Re: [Qemu-devel] [RFC v2 1/2] virtio: add pmem driver

Pankaj Gupta writes: >> Ideally, qemu (seabios?) would advertise a platform capabilities >> sub-table that doesn't fill in the flush bits. > > Could you please elaborate on this, how its related to disabling > MAP_SYNC? We are not doing entire nvdimm device emulation. My

Re: [Qemu-devel] [RFC v2 1/2] virtio: add pmem driver

Pankaj Gupta writes: >> Ideally, qemu (seabios?) would advertise a platform capabilities >> sub-table that doesn't fill in the flush bits. > > Could you please elaborate on this, how its related to disabling > MAP_SYNC? We are not doing entire nvdimm device emulation. My mistake. If you're

Re: [RFC v2 1/2] virtio: add pmem driver

Dan Williams writes: > [ adding Jeff directly since he has also been looking at > infrastructure to track when MAP_SYNC should be disabled ] > > On Wed, Apr 25, 2018 at 7:21 AM, Dan Williams > wrote: >> On Wed, Apr 25, 2018 at 4:24 AM, Pankaj

Re: [RFC v2 1/2] virtio: add pmem driver

Dan Williams writes: > [ adding Jeff directly since he has also been looking at > infrastructure to track when MAP_SYNC should be disabled ] > > On Wed, Apr 25, 2018 at 7:21 AM, Dan Williams > wrote: >> On Wed, Apr 25, 2018 at 4:24 AM, Pankaj Gupta wrote: >>> This patch adds virtio-pmem

Re: io_pgetevents & aio fsync V2

Christoph Hellwig writes: > On Fri, Apr 06, 2018 at 04:16:30AM +0100, Al Viro wrote: >> BTW, this is only tangentially related, but... does *anything* call >> io_submit() for huge amounts of iocb? I don't know. If an application did that, as many I/Os as could fit into the ring

Re: io_pgetevents & aio fsync V2

Christoph Hellwig writes: > On Fri, Apr 06, 2018 at 04:16:30AM +0100, Al Viro wrote: >> BTW, this is only tangentially related, but... does *anything* call >> io_submit() for huge amounts of iocb? I don't know. If an application did that, as many I/Os as could fit into the ring buffer would be

Re: [PATCH 08/36] aio: implement io_pgetevents

Christoph Hellwig <h...@lst.de> writes: > On Tue, Mar 20, 2018 at 11:30:29AM -0400, Jeff Moyer wrote: >> > In this commit: >> > >> > http://git.infradead.org/users/hch/libaio.git/commitdiff/49f77d595210393ce7b125cb00233cf737402f56 >> >> BTW, th

Re: [PATCH 08/36] aio: implement io_pgetevents

Christoph Hellwig writes: > On Tue, Mar 20, 2018 at 11:30:29AM -0400, Jeff Moyer wrote: >> > In this commit: >> > >> > http://git.infradead.org/users/hch/libaio.git/commitdiff/49f77d595210393ce7b125cb00233cf737402f56 >> >> BTW, the man pages

Re: [PATCH 08/36] aio: implement io_pgetevents

Christoph Hellwig writes: > On Mon, Mar 19, 2018 at 07:12:41PM -0700, Darrick J. Wong wrote: >> > Note that unlike many other signal related calls we do not pass a sigmask >> > size, as that would get us to 7 arguments, which aren't easily supported >> > by the syscall

Re: [PATCH 08/36] aio: implement io_pgetevents

Christoph Hellwig writes: > On Mon, Mar 19, 2018 at 07:12:41PM -0700, Darrick J. Wong wrote: >> > Note that unlike many other signal related calls we do not pass a sigmask >> > size, as that would get us to 7 arguments, which aren't easily supported >> > by the syscall infrastructure. It seems

Re: [PATCH 14/36] aio: implement IOCB_CMD_POLL

the aio_buf field of the iocb. > > Unlike poll or epoll without EPOLLONESHOT this interface always works > in one shot mode, that is once the iocb is completed, it will have to be > resubmitted. > > Signed-off-by: Christoph Hellwig <h...@lst.de> Also acked this one in th

Re: [PATCH 14/36] aio: implement IOCB_CMD_POLL

of the iocb. > > Unlike poll or epoll without EPOLLONESHOT this interface always works > in one shot mode, that is once the iocb is completed, it will have to be > resubmitted. > > Signed-off-by: Christoph Hellwig Also acked this one in the last posting. Acked-by: J

Re: [PATCH 08/36] aio: implement io_pgetevents

h aren't easily supported > by the syscall infrastructure. It seems a lot less painful to just add a > new syscall variant in the unlikely case we're going to increase the > sigset size. > > Signed-off-by: Christoph Hellwig <h...@lst.de> I acked this in the last set, so... Acked-by: J

Re: [PATCH 08/36] aio: implement io_pgetevents

y the syscall infrastructure. It seems a lot less painful to just add a > new syscall variant in the unlikely case we're going to increase the > sigset size. > > Signed-off-by: Christoph Hellwig I acked this in the last set, so... Acked-by: Jeff Moyer > --- > arch/x8

Re: [PATCH v2] libnvdimm: re-enable deep flush for pmem devices

Dan Williams <dan.j.willi...@intel.com> writes: > On Mon, Feb 12, 2018 at 2:53 PM, Jeff Moyer <jmo...@redhat.com> wrote: >> Dave Jiang <dave.ji...@intel.com> writes: >> >>> Re-enable deep flush so that users always have a way to be sure that a write >

Re: [PATCH v2] libnvdimm: re-enable deep flush for pmem devices

Dan Williams writes: > On Mon, Feb 12, 2018 at 2:53 PM, Jeff Moyer wrote: >> Dave Jiang writes: >> >>> Re-enable deep flush so that users always have a way to be sure that a write >>> does make it all the way out to the NVDIMM. The PMEM driver write

Re: [PATCH v2] libnvdimm: re-enable deep flush for pmem devices

er deep flush in the > filesystem-dax case. That's still very confusing text. Specifically, the part where you say that pmem driver writes always make it to the DIMM. I think the changelog could start with "Deep flush is there to explicitly flush write buffers" Anyway, the fi

Re: [PATCH v2] libnvdimm: re-enable deep flush for pmem devices

filesystem-dax case. That's still very confusing text. Specifically, the part where you say that pmem driver writes always make it to the DIMM. I think the changelog could start with "Deep flush is there to explicitly flush write buffers" Anyway, the fix looks right to me. Reviewed-by: Jeff Moyer

Re: [PATCH 08/36] aio: implement io_pgetevents

h aren't easily supported > by the syscall infrastructure. It seems a lot less painful to just add a > new syscall variant in the unlikely case we're going to increase the > sigset size. > > Signed-off-by: Christoph Hellwig <h...@lst.de> Acked-by: Jeff Moyer <jmo...@redhat.com

Re: [PATCH 08/36] aio: implement io_pgetevents

y the syscall infrastructure. It seems a lot less painful to just add a > new syscall variant in the unlikely case we're going to increase the > sigset size. > > Signed-off-by: Christoph Hellwig Acked-by: Jeff Moyer I assume other arch maintainers will also plumb this in? -Jeff &g

Re: [PATCH 14/36] aio: implement IOCB_CMD_POLL

the aio_buf field of the iocb. > > Unlike poll or epoll without EPOLLONESHOT this interface always works > in one shot mode, that is once the iocb is completed, it will have to be > resubmitted. > > Signed-off-by: Christoph Hellwig <h...@lst.de> Acked-by: Jeff Moyer <jmo...@redhat.com>

Re: [PATCH 14/36] aio: implement IOCB_CMD_POLL

of the iocb. > > Unlike poll or epoll without EPOLLONESHOT this interface always works > in one shot mode, that is once the iocb is completed, it will have to be > resubmitted. > > Signed-off-by: Christoph Hellwig Acked-by: Jeff Moyer

Re: aio poll, io_pgetevents and a new in-kernel poll API V3

Christoph Hellwig <h...@lst.de> writes: > On Thu, Jan 18, 2018 at 11:44:03AM -0500, Jeff Moyer wrote: >> Jeff Moyer <jmo...@redhat.com> writes: >> >> > FYI, this kernel has issues. It will boot up, but I don't have >> > networking, and

Re: aio poll, io_pgetevents and a new in-kernel poll API V3

Christoph Hellwig writes: > On Thu, Jan 18, 2018 at 11:44:03AM -0500, Jeff Moyer wrote: >> Jeff Moyer writes: >> >> > FYI, this kernel has issues. It will boot up, but I don't have >> > networking, and even rebooting doesn't succeed. I'm looking into it.

Re: aio poll, io_pgetevents and a new in-kernel poll API V3

Avi Kivity <a...@scylladb.com> writes: > On 01/18/2018 05:46 PM, Jeff Moyer wrote: >> FYI, this kernel has issues. It will boot up, but I don't have >> networking, and even rebooting doesn't succeed. I'm looking into it. > > FWIW, I'm running an older version of

Re: aio poll, io_pgetevents and a new in-kernel poll API V3

Avi Kivity writes: > On 01/18/2018 05:46 PM, Jeff Moyer wrote: >> FYI, this kernel has issues. It will boot up, but I don't have >> networking, and even rebooting doesn't succeed. I'm looking into it. > > FWIW, I'm running an older version of this patchset on my desktop

Re: aio poll, io_pgetevents and a new in-kernel poll API V3

Jeff Moyer <jmo...@redhat.com> writes: > FYI, this kernel has issues. It will boot up, but I don't have > networking, and even rebooting doesn't succeed. I'm looking into it. A bisect lands on: eventfd: switch to ->poll_mask. That's not super helpful, though. I did run the ltp

  1   2   3   4   5   6   7   8   9   10   >