On Fri, Apr 9, 2021 at 5:33 PM wrote:
>
> From: Yingjie Wang
>
> In nd_dax_probe(), nd_dax_alloc() may fail and return NULL.
> Check for NULL before attempting to
> use nd_dax to avoid a NULL pointer dereference.
>
> Fixes: c5ed9268643c ("libnvdimm, dax: autodetect support")
> Signed-off-by:
Hi Bjorn, thanks for taking a look.
On Thu, Apr 8, 2021 at 3:42 PM Bjorn Helgaas wrote:
>
> [+cc Greg, Rafael, Matthew: device model questions]
>
> Hi Dan,
>
> On Thu, Apr 01, 2021 at 07:31:20AM -0700, Dan Williams wrote:
> > Once the cxl_root is established then othe
On Mon, 2021-04-05 at 11:52 +0200, Loic Poulain wrote:
> This change introduces initial support for a WWAN framework. Given
> the
> complexity and heterogeneity of existing WWAN hardwares and
> interfaces,
> there is no strict definition of what a WWAN device is and how it
> should
> be
oilerplate and sysfs attributes, to
be followed by enumeration of the ports within the host bridge.
Signed-off-by: Dan Williams
---
drivers/cxl/Kconfig | 14 ++
drivers/cxl/Makefile |2
drivers/cxl/acpi.c | 39 ++
drivers/cxl/core.
register block mapping.
Acked-by: Ben Widawsky
Signed-off-by: Dan Williams
---
Documentation/driver-api/cxl/memory-devices.rst |6 ++---
drivers/cxl/Makefile|4 ++-
drivers/cxl/bus.c | 29 --
drivers/cxl/core.c
his patch set chooses to implement 1
cxl_root for all address spaces.
[1]: CXL 2.0 8.2.5.12.8 CXL HDM Decoder 0 Target List Low Register
(Offset 24h) ...The Target Port Identifier for a given Downstream Port
is reported via Port Number field in Link Capabilities Register. (See
PC
── target_id
│ └── uevent
├── subsystem -> ../../../../bus/cxl
├── target_id
└── uevent
Signed-off-by: Dan Williams
---
drivers/cxl/acpi.c | 99 +++
drivers/cxl/core.c | 121
drivers/cxl/cxl.h |
-by: Jason Gunthorpe
Signed-off-by: Dan Williams
---
drivers/cxl/mem.c | 39 +--
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index c77d375fad95..e59b373694d3 100644
--- a/drivers/cxl/mem.c
+++ b/d
Signed-off-by: Dan Williams
---
drivers/cxl/mem.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index ecfc9ccdba8d..30bf4f0f3c17 100644
--- a/drivers/cxl/mem.c
+++ b/drivers/cxl/mem.c
@@ -1066,7 +1066,7 @@ static ssize_t firmware_ve
and unpublishing of device power management files
are independent sanity cleanups.
---
Dan Williams (4):
cxl/mem: Use sysfs_emit() for attribute show routines
cxl/mem: Fix synchronization mechanism for device removal vs ioctl
operations
cxl/mem: Do not rely on device_add() side effects
devices")
Reported-by: Jason Gunthorpe
Reviewed-by: Jason Gunthorpe
Signed-off-by: Dan Williams
---
drivers/cxl/mem.c | 97 +++--
1 file changed, 50 insertions(+), 47 deletions(-)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index
ltiple types.
Reviewed-by: Ben Widawsky
Signed-off-by: Dan Williams
---
drivers/cxl/cxl.h | 33 +
drivers/cxl/mem.c | 44
drivers/cxl/mem.h | 13 +
3 files changed, 62 insertions(+), 28 deletions(-)
diff --g
[debug / to-be-replaced / not-for-upstream]
Given ACPICA support is needed before drivers can integrate ACPI
functionality add some module parameters as proxies.
---
drivers/cxl/acpi.c | 81 +++-
1 file changed, 79 insertions(+), 2 deletions(-)
capable platforms). Default CONFIG_CXL_MEM and
CONFIG_CXL_ACPI to CONFIG_CXL_BUS.
Acked-by: Ben Widawsky
Signed-off-by: Dan Williams
---
drivers/cxl/Kconfig |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
index fb282af84afd..1da7970a5e55 100644
In preparation for sharing cxl.h with other generic CXL consumers,
move / consolidate some of the memory device specifics to mem.h.
Reviewed-by: Ben Widawsky
Signed-off-by: Dan Williams
---
drivers/cxl/cxl.h | 57
drivers/cxl/mem.c | 25
There is no power management of cxl virtual devices, disable
device-power-management and runtime-power-management to prevent
userspace from growing expectations of those attributes appearing. They
can be added back in the future if needed.
Reviewed-by: Ben Widawsky
Signed-off-by: Dan Williams
-by: Dan Williams
---
drivers/cxl/core.c | 57 +++-
drivers/cxl/cxl.h |3 +++
drivers/cxl/mem.c | 50 +-
3 files changed, 65 insertions(+), 45 deletions(-)
diff --git a/drivers/cxl/core.c b/drivers/cxl
On Wed, Mar 31, 2021 at 9:18 AM Jason Gunthorpe wrote:
>
> On Wed, Mar 31, 2021 at 09:04:32AM -0700, Dan Williams wrote:
> > On Wed, Mar 31, 2021 at 6:10 AM Jason Gunthorpe wrote:
> > >
> > > On Tue, Mar 30, 2021 at 04:36:42PM -0700, Dan Williams wrote:
> >
On Wed, Mar 31, 2021 at 6:10 AM Jason Gunthorpe wrote:
>
> On Tue, Mar 30, 2021 at 04:36:42PM -0700, Dan Williams wrote:
> > +static int cxl_mem_add_memdev(struct cxl_mem *cxlm)
> > +{
> > + struct cxl_memdev *cxlmd;
> > + struct device *dev;
> > +
On Wed, Mar 31, 2021 at 6:07 AM Jason Gunthorpe wrote:
>
> On Tue, Mar 30, 2021 at 04:36:37PM -0700, Dan Williams wrote:
> > -static void cxlmdev_unregister(void *_cxlmd)
> > +static void cxl_memdev_activate(struct cxl_memdev *cxlmd, struct cxl_mem
> > *cxlm)
> >
devices")
Reported-by: Jason Gunthorpe
Signed-off-by: Dan Williams
---
drivers/cxl/mem.c | 97 -
1 file changed, 51 insertions(+), 46 deletions(-)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 30bf4f0f3c17..2cf620d201a6 100644
---
to
put_device() if the name set fails.
This type of bug is easier to see if 'alloc' is split from 'add'
operations that require put_device() on failure. So cxl_memdev_alloc()
is split out as a result.
Fixes: b39cb1052a5c ("cxl/mem: Register CXL memX devices")
Reported-by: Jason Gunthorpe
Signed-o
There is no power management of cxl virtual devices, disable
device-power-management and runtime-power-management to prevent
userspace from growing expectations of those attributes appearing. They
can be added back in the future if needed.
Reviewed-by: Ben Widawsky
Signed-off-by: Dan Williams
nk:
https://lore.kernel.org/r/161661971101.1721612.16412318662284948582.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams
---
drivers/cxl/mem.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index ecfc9ccdba8d..30
xup and unpublishing of device power management files
are independent sanity cleanups.
---
Dan Williams (4):
cxl/mem: Use sysfs_emit() for attribute show routines
cxl/mem: Fix synchronization mechanism for device removal vs ioctl
operations
cxl/mem: Do not rely on device_add() side effe
On Tue, Mar 30, 2021 at 12:52 PM Jason Gunthorpe wrote:
>
> On Tue, Mar 30, 2021 at 12:43:15PM -0700, Dan Williams wrote:
>
> > Ok, so this is the disagreement. Strict adherence to the model where
> > it does not matter in practice.
>
> The basic problem is that it
On Tue, Mar 30, 2021 at 12:26 PM Jason Gunthorpe wrote:
>
> On Tue, Mar 30, 2021 at 12:00:23PM -0700, Dan Williams wrote:
>
> > > > > IMHO this can't use 'dev->kobj.state_in_sysfs' as the RCU protected
> > > > > data.
> > > >
> > &g
On Tue, Mar 30, 2021 at 10:54 AM Jason Gunthorpe wrote:
>
> On Tue, Mar 30, 2021 at 10:31:15AM -0700, Dan Williams wrote:
> > On Tue, Mar 30, 2021 at 10:03 AM Jason Gunthorpe wrote:
> > >
> > > On Tue, Mar 30, 2021 at 09:05:29AM -0700, Dan Williams wrote:
> &
On Tue, Mar 30, 2021 at 10:03 AM Jason Gunthorpe wrote:
>
> On Tue, Mar 30, 2021 at 09:05:29AM -0700, Dan Williams wrote:
>
> > > If you can't clearly point to the *data* under RCU protection it is
> > > being used wrong.
> >
> > Agree.
> >
> &g
On Tue, Mar 30, 2021 at 8:47 AM Jason Gunthorpe wrote:
>
> On Tue, Mar 30, 2021 at 08:37:19AM -0700, Dan Williams wrote:
> > On Tue, Mar 30, 2021 at 4:16 AM Jason Gunthorpe wrote:
> > >
> > > On Mon, Mar 29, 2021 at 07:47:49PM -0700, Dan Williams wrote:
>
On Tue, Mar 30, 2021 at 4:16 AM Jason Gunthorpe wrote:
>
> On Mon, Mar 29, 2021 at 07:47:49PM -0700, Dan Williams wrote:
>
> > @@ -1155,21 +1175,12 @@ static void cxlmdev_unregister(void *_cxlmd)
> > struct cxl_memdev *cxlmd = _cxlmd;
> >
On Mon, Mar 29, 2021 at 3:44 PM Jason Gunthorpe wrote:
>
> On Mon, Mar 29, 2021 at 02:03:37PM -0700, Dan Williams wrote:
>
> > Ugh, exactly why I was motivated to attempt to preclude this with new
> > core infrastructure that attempted to fix this centrally [1]. Remove
to
put_device() if the name set fails.
This type of bug is easier to see if 'alloc' is split from 'add'
operations that require put_device() on failure. So cxl_memdev_alloc()
is split out as a result.
Fixes: b39cb1052a5c ("cxl/mem: Register CXL memX devices")
Reported-by: Jason Gunthorpe
Signed-o
There is no power management of cxl virtual devices, disable
device-power-management and runtime-power-management to prevent
userspace from growing expectations of those attributes appearing. They
can be added back in the future if needed.
Reviewed-by: Ben Widawsky
Signed-off-by: Dan Williams
)
Reported-by: Jason Gunthorpe
Signed-off-by: Dan Williams
---
drivers/cxl/mem.c | 83 +++--
1 file changed, 43 insertions(+), 40 deletions(-)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index 30bf4f0f3c17..548d696f1f54 100644
--- a/d
nk:
https://lore.kernel.org/r/161661971101.1721612.16412318662284948582.st...@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Dan Williams
---
drivers/cxl/mem.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
index ecfc9ccdba8d..30
of device power management files
are just sanity cleanups.
---
Dan Williams (4):
cxl/mem: Use sysfs_emit() for attribute show routines
cxl/mem: Fix synchronization mechanism for device removal vs ioctl
operations
cxl/mem: Do not rely on device_add() side effects
On Thu, Mar 25, 2021 at 7:34 AM Jason Gunthorpe wrote:
>
> On Thu, Mar 18, 2021 at 10:03:06AM -0700, Dan Williams wrote:
> > Yes. I still need to answer the question of whether mapping
> > invalidation triggers longterm pin holders to relinquish their hold,
> > but tha
On Thu, Mar 25, 2021 at 10:12 AM Jason Gunthorpe wrote:
>
> On Wed, Mar 24, 2021 at 02:01:56PM -0700, Dan Williams wrote:
> > If cdev_device_add() fails then the allocation performed by
> > dev_set_name() is leaked. Use put_device(), not open coded release, for
> &g
On Fri, Mar 26, 2021 at 9:12 AM Bjorn Helgaas wrote:
>
> [+cc Christoph]
>
> On Wed, Mar 24, 2021 at 06:23:54PM -0700, Dan Williams wrote:
> > The PCIE Data Object Exchange (DOE) mailbox is a protocol run over
> > configuration cycles. It assumes one initiator at a tim
On Thu, Mar 25, 2021 at 1:29 AM Christoph Hellwig wrote:
>
> On Thu, Mar 25, 2021 at 07:54:59AM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Mar 24, 2021 at 06:23:54PM -0700, Dan Williams wrote:
> > > The PCIE Data Object Exchange (DOE) mailbox is a protocol run over
>
On Wed, Mar 24, 2021 at 11:55 PM Greg Kroah-Hartman
wrote:
>
> On Wed, Mar 24, 2021 at 06:23:54PM -0700, Dan Williams wrote:
> > The PCIE Data Object Exchange (DOE) mailbox is a protocol run over
> > configuration cycles. It assumes one initiator at a time is
> >
output if any configuration
register in the request is exclusive. Instead skip the actual
configuration cycle on a per-access basis and return all f's as if the
read had failed.
Cc: Bjorn Helgaas
Cc: Greg Kroah-Hartman
Cc: Jonathan Cameron
Signed-off-by: Dan Williams
---
drivers/pci/access.c
register block mapping.
Acked-by: Ben Widawsky
Signed-off-by: Dan Williams
---
Documentation/driver-api/cxl/memory-devices.rst |6 ++---
drivers/cxl/Makefile|4 ++-
drivers/cxl/bus.c | 29 --
drivers/cxl/core.c
[debug / to-be-replaced / not-for-upstream]
Given ACPICA support is needed before drivers can integrate ACPI
functionality add some module parameters as proxies.
---
drivers/cxl/acpi.c | 81 +++-
1 file changed, 79 insertions(+), 2 deletions(-)
── target_id
│ └── uevent
├── subsystem -> ../../../../bus/cxl
├── target_id
└── uevent
Signed-off-by: Dan Williams
---
drivers/cxl/acpi.c | 99 +++
drivers/cxl/core.c | 100 +++-
drivers/cxl/cxl.h
-by: Dan Williams
---
drivers/cxl/core.c | 57 +++-
drivers/cxl/cxl.h |3 +++
drivers/cxl/mem.c | 50 +-
3 files changed, 65 insertions(+), 45 deletions(-)
diff --git a/drivers/cxl/core.c b/drivers/cxl
capable platforms). Default CONFIG_CXL_MEM and
CONFIG_CXL_ACPI to CONFIG_CXL_BUS.
Acked-by: Ben Widawsky
Signed-off-by: Dan Williams
---
drivers/cxl/Kconfig |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
index fb282af84afd..1da7970a5e55 100644
In preparation for common register mapping facility, introduce a generic
container, 'struct cxl_regs', for CXL device register and later
component register block base pointers. Some CXL device types implement
both.
Reviewed-by: Ben Widawsky
Signed-off-by: Dan Williams
---
drivers/cxl/cxl.h
oilerplate and sysfs attributes, to
be followed by enumeration of the ports within the host bridge.
Signed-off-by: Dan Williams
---
drivers/cxl/Kconfig | 14 ++
drivers/cxl/Makefile |2
drivers/cxl/acpi.c | 39 +++
drivers/cxl/core.
In preparation for sharing cxl.h with other generic CXL consumers,
move / consolidate some of the memory device specifics to mem.h.
Reviewed-by: Ben Widawsky
Signed-off-by: Dan Williams
---
drivers/cxl/cxl.h | 57
drivers/cxl/mem.c | 25
ort
is reported via Port Number field in Link Capabilities Register. (See
PCI Express Base Specification).
---
Dan Williams (8):
cxl/mem: Move some definitions to mem.h
cxl/mem: Introduce 'struct cxl_regs'
cxl/core: Rename bus.c to core.c
cxl/core: Refactor C
for cdev_device_add() failures leaked the device name.
The sysfs_emit() fixup and unpublishing of device power management files
are just sanity cleanups.
---
Dan Williams (4):
cxl/mem: Use sysfs_emit() for attribute show routines
cxl/mem: Fix cdev_device_add() error handling
cxl/mem: Do
There is no power management of cxl virtual devices, disable
device-power-management and runtime-power-management to prevent
userspace from growing expectations of those attributes appearing. They
can be added back in the future if needed.
Reviewed-by: Ben Widawsky
Signed-off-by: Dan Williams
While none the CXL sysfs attributes are threatening to overrun a
PAGE_SIZE of output, it is good form to use the recommended helpers.
Fixes: b39cb1052a5c ("cxl/mem: Register CXL memX devices")
Reviewed-by: Ben Widawsky
Reported-by: Jason Gunthorpe
Signed-off-by: Dan Williams
---
d
to
put_device() if the name set failure.
Fixes: b39cb1052a5c ("cxl/mem: Register CXL memX devices")
Reported-by: Jason Gunthorpe
Signed-off-by: Dan Williams
---
drivers/cxl/mem.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/cxl/mem.c b/drivers/cxl/m
is already dead, so
percpu_ref_kill() is needed before put_device(). However, given that the
cdev was partially live wait_for_completion() also belongs in the
release method.
Fixes: b39cb1052a5c ("cxl/mem: Register CXL memX devices")
Reported-by: Jason Gunthorpe
Signed-off-by: Da
On Wed, Mar 24, 2021 at 11:43 AM Ira Weiny wrote:
>
> On Wed, Mar 24, 2021 at 03:16:35PM +0100, Robert Richter wrote:
> > Typically the mem_commands[] array is in sync with 'enum { CXL_CMDS }'.
> > Current code works well.
> >
> > However, the array size of mem_commands[] may not strictly be the
On Wed, Mar 24, 2021 at 7:17 AM Robert Richter wrote:
>
> Typically the mem_commands[] array is in sync with 'enum { CXL_CMDS }'.
> Current code works well.
>
> However, the array size of mem_commands[] may not strictly be the same
> as CXL_MEM_COMMAND_ID_MAX. E.g. if a new CXL_CMD() is added
On Wed, Mar 24, 2021 at 10:39 AM Christoph Hellwig wrote:
>
> On Wed, Mar 24, 2021 at 09:37:01AM -0700, Dan Williams wrote:
> > > Eww. As I said I think the right way is that the file system (or
> > > other consumer) can register a set of callbacks for opening the
On Thu, Mar 18, 2021 at 3:02 AM Joao Martins wrote:
>
> On 3/18/21 4:08 AM, Dan Williams wrote:
> > Now that device-dax and filesystem-dax are guaranteed to unmap all user
> > mappings of devmap / DAX pages before tearing down the 'struct page'
> > array, get_user_page
On Wed, Mar 24, 2021 at 12:48 AM Christoph Hellwig wrote:
>
> On Tue, Mar 23, 2021 at 07:19:28PM -0700, Dan Williams wrote:
> > So I think the path forward is:
> >
> > - teach memory_failure() to allow for ranged failures
> >
> > - let interested drivers re
On Thu, Mar 18, 2021 at 7:18 PM ruansy.f...@fujitsu.com
wrote:
>
>
>
> > -Original Message-
> > From: ruansy.f...@fujitsu.com
> > Subject: RE: [PATCH v3 01/11] pagemap: Introduce ->memory_failure()
> > > > > > >
> > > > > > > After the conversation with Dave I don't see the point of
On Mon, Mar 22, 2021 at 4:45 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> gcc warns about an empty body in an else statement:
>
> drivers/dax/bus.c: In function 'do_id_store':
> drivers/dax/bus.c:94:48: error: suggest braces around empty body in an 'else'
> statement [-Werror=empty-body]
le tree, so remove documentation
> that indicates that some functions behave differently.
Looks good, and the staging of the potential regressions as standalone
lead-in patches makes sense.
Reviewed-by: Dan Williams
>
> Let's find all busy IORESOURCE_SYSTEM_RAM resources, making the function
> behave like walk_system_ram_range().
>
> Cc: Andrew Morton
> Cc: Greg Kroah-Hartman
> Cc: Dan Williams
> Cc: Daniel Vetter
> Cc: Andy Shevchenko
> Cc: Mauro Carvalho Chehab
> Cc: Signed-off
ot; in __ioremap_caller().
>
> Let's find all busy IORESOURCE_MEM resources, making the function
> behave similar to walk_system_ram_res().
Looks good,
Reviewed-by: Dan Williams
On Fri, Mar 19, 2021 at 6:47 PM Dave Chinner wrote:
[..]
> > Now I'm trying to reconcile the fact that platform
> > poison handling will hit memory_failure() first and may not
> > immediately reach the driver, if ever (see the perennially awkward
> > firmware-first-mode error handling:
On Wed, Mar 17, 2021 at 9:45 PM Darrick J. Wong wrote:
>
> On Wed, Mar 17, 2021 at 09:08:23PM -0700, Dan Williams wrote:
> > Jason wondered why the get_user_pages_fast() path takes references on a
> > @pgmap object. The rationale was to protect against accessing a 'struct
&g
On Wed, Mar 17, 2021 at 9:58 PM Dave Chinner wrote:
>
> On Wed, Mar 17, 2021 at 09:08:23PM -0700, Dan Williams wrote:
> > Jason wondered why the get_user_pages_fast() path takes references on a
> > @pgmap object. The rationale was to protect against accessing a 'struct
&g
On Thu, Mar 18, 2021 at 3:02 AM Joao Martins wrote:
>
> On 3/18/21 4:08 AM, Dan Williams wrote:
> > Now that device-dax and filesystem-dax are guaranteed to unmap all user
> > mappings of devmap / DAX pages before tearing down the 'struct page'
> > array, get_user_page
Christoph Hellwig
Cc: Shiyang Ruan
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Ira Weiny
Cc: Matthew Wilcox
Cc: Jan Kara
Cc: Andrew Morton
Cc: Naoya Horiguchi
Cc: "Darrick J. Wong"
Signed-off-by: Dan Williams
---
drivers/dax/super.c | 15 +++
drivers/nvdi
c: Shiyang Ruan
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Ira Weiny
Cc: Matthew Wilcox
Cc: Jan Kara
Cc: Andrew Morton
Signed-off-by: Dan Williams
---
mm/gup.c | 38 --
1 file changed, 16 insertions(+), 22 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index e4
to be called directly.
Cc: Naoya Horiguchi
Cc: Andrew Morton
Signed-off-by: Dan Williams
---
mm/memory-failure.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 24210c9bd843..43ba4307c526 100644
--- a/mm
that this proposal is to do a best effort recovery of an event that
should not happen (surprise removal) under nominal operation.
---
Dan Williams (3):
mm/memory-failure: Prepare for mass memory_failure()
mm, dax, pmem: Introduce dev_pagemap_failure()
mm/devmap: Remove
On Wed, Mar 17, 2021 at 10:20 AM Sathyanarayanan Kuppuswamy Natarajan
wrote:
>
> Hi,
>
> On Wed, Mar 17, 2021 at 9:31 AM Dan Williams wrote:
> >
> > On Tue, Mar 16, 2021 at 10:31 PM Lukas Wunner wrote:
> > >
> > > On Tue, Mar 16, 2021 at 10:08:31PM -070
On Tue, Mar 16, 2021 at 10:31 PM Lukas Wunner wrote:
>
> On Tue, Mar 16, 2021 at 10:08:31PM -0700, Dan Williams wrote:
> > On Tue, Mar 16, 2021 at 9:14 PM Lukas Wunner wrote:
> > >
> > > On Fri, Mar 12, 2021 at 07:32:08PM -0800,
> > > sathyanar
On Tue, Mar 16, 2021 at 9:14 PM Lukas Wunner wrote:
>
> On Fri, Mar 12, 2021 at 07:32:08PM -0800,
> sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > + if ((events == PCI_EXP_SLTSTA_DLLSC) && is_dpc_reset_active(pdev)) {
> > + ctrl_info(ctrl, "Slot(%s): DLLSC event(DPC),
On Tue, Mar 16, 2021 at 8:00 PM chenjun (AM) wrote:
>
> 在 2021/3/12 1:25, Dan Williams 写道:
> > On Thu, Mar 11, 2021 at 4:20 AM Matthew Wilcox wrote:
> >>
> >> On Thu, Mar 11, 2021 at 07:48:25AM +, chenjun (AM) wrote:
> >>> static int dax_writeback_o
On Fri, Mar 12, 2021 at 3:14 PM Bjorn Helgaas wrote:
>
> On Fri, Mar 12, 2021 at 02:11:03PM -0800, Kuppuswamy, Sathyanarayanan wrote:
> > On 3/12/21 1:33 PM, Bjorn Helgaas wrote:
> > > On Mon, Mar 08, 2021 at 10:34:10PM -0800,
> > > sathyanarayanan.kuppusw...@linux.intel.com wrote:
> > > > From:
On Thu, Mar 11, 2021 at 8:21 PM Pankaj Gupta
wrote:
>
> Hi David,
>
> > > Jeff reported preflush order issue with the existing implementation
> > > of virtio pmem preflush. Dan suggested[1] to implement asynchronous
> > > flush
> > > for virtio pmem using work queue as done in md/RAID.
On Thu, Mar 11, 2021 at 4:20 AM Matthew Wilcox wrote:
>
> On Thu, Mar 11, 2021 at 07:48:25AM +, chenjun (AM) wrote:
> > static int dax_writeback_one(struct xa_state *xas, struct dax_device
> > *dax_dev, struct address_space *mapping, void *entry)
> > dax_flush(dax_dev,
On Wed, Mar 10, 2021 at 6:27 AM Matthew Wilcox wrote:
>
> On Wed, Mar 10, 2021 at 08:21:59AM -0600, Goldwyn Rodrigues wrote:
> > On 13:02 10/03, Matthew Wilcox wrote:
> > > On Wed, Mar 10, 2021 at 07:30:41AM -0500, Neal Gompa wrote:
> > > > Forgive my ignorance, but is there a reason why this
On Tue, Mar 9, 2021 at 10:54 PM Christoph Hellwig wrote:
>
> Looks good to me:
>
> Reviewed-by: Christoph Hellwig
>
> Question on the pre-existing code: given that nvdimm_check_and_set_ro is
> the only caller of set_disk_ro for nvdimm devices, we'll also get
> the message when initially setting
On Mon, Mar 8, 2021 at 8:53 PM Chen, Mike Ximing
wrote:
>
>
> > -Original Message-
> > From: Greg KH
> > On Mon, Mar 08, 2021 at 08:00:00PM +, Chen, Mike Ximing wrote:
> > >
> > > Hi Greg,
> > >
> > > While waiting for the feedback from the networking maintainers, I am
> > >
Vishal Verma
Signed-off-by: Dan Williams
---
Changes since v1 [1]:
- Move from the sinking ship of revalidate_disk() to the local hotness
of nd_pmem_notify() (hch).
[1]:
http://lore.kernel.org/r/161527286194.446794.5215036039655765042.st...@dwillia2-desk3.amr.corp.intel.com
drivers
gt; the number of files from 240, but that's still a big win -- 68%
> reduction instead of 77%.
>
[..]
> drivers/nvdimm/btt.c | 1 +
> drivers/nvdimm/pmem.c | 1 +
For the nvdimm bits:
Acked-by: Dan Williams
On Mon, Mar 8, 2021 at 11:31 PM Christoph Hellwig wrote:
>
> On Mon, Mar 08, 2021 at 10:54:22PM -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
&
Vishal Verma
Signed-off-by: Dan Williams
---
drivers/nvdimm/btt.c |7 +++
drivers/nvdimm/bus.c | 14 ++
drivers/nvdimm/pmem.c |7 +++
3 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
index 41aa1f01fc07..73d3bf
[ add Kevin and Maxim ]
On Mon, Mar 8, 2021 at 12:13 PM Greg KH wrote:
>
> On Mon, Mar 08, 2021 at 08:00:00PM +, Chen, Mike Ximing wrote:
[..]
> > Hi Greg,
> >
> > While waiting for the feedback from the networking maintainers, I am
> > wondering if you have any other comments/suggestions
On Mon, Mar 8, 2021 at 3:34 AM ruansy.f...@fujitsu.com
wrote:
> > > > > 1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/include/linux/memremap.h b/include/linux/memremap.h
> > > > > index 79c49e7f5c30..0bcf2b1e20bd 100644
> > > > > --- a/include/linux/memremap.h
> > > > > +++
On Sun, Mar 7, 2021 at 7:38 PM ruansy.f...@fujitsu.com
wrote:
>
> > On Mon, Feb 8, 2021 at 2:55 AM Shiyang Ruan
> > wrote:
> > >
> > > When memory-failure occurs, we call this function which is implemented
> > > by each kind of devices. For the fsdax case, pmem device driver
> > > implements
On Mon, Feb 8, 2021 at 2:55 AM Shiyang Ruan wrote:
>
> When memory-failure occurs, we call this function which is implemented
> by each kind of devices. For the fsdax case, pmem device driver
> implements it. Pmem device driver will find out the block device where
> the error page locates in,
On Mon, Mar 1, 2021 at 11:57 PM Dave Chinner wrote:
>
> On Mon, Mar 01, 2021 at 09:41:02PM -0800, Dan Williams wrote:
> > On Mon, Mar 1, 2021 at 7:28 PM Darrick J. Wong wrote:
> > > > > I really don't see you seem to be telling us that invalidation is an
> > >
On Mon, Mar 1, 2021 at 9:38 PM Dave Chinner wrote:
>
> On Mon, Mar 01, 2021 at 07:33:28PM -0800, Dan Williams wrote:
> > On Mon, Mar 1, 2021 at 6:42 PM Dave Chinner wrote:
> > [..]
> > > We do not need a DAX specific mechanism to tell us "DAX device
> > &
On Mon, Mar 1, 2021 at 7:28 PM Darrick J. Wong wrote:
>
> On Mon, Mar 01, 2021 at 12:55:53PM -0800, Dan Williams wrote:
> > On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
> > >
> > > On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > >
On Mon, Mar 1, 2021 at 6:42 PM Dave Chinner wrote:
[..]
> We do not need a DAX specific mechanism to tell us "DAX device
> gone", we need a generic block device interface that tells us "range
> of block device is gone".
This is the crux of the disagreement. The block_device is going away
*and*
On Mon, Mar 1, 2021 at 2:47 PM Dave Chinner wrote:
>
> On Mon, Mar 01, 2021 at 12:55:53PM -0800, Dan Williams wrote:
> > On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
> > >
> > > On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > >
On Sun, Feb 28, 2021 at 11:27 PM Yasunori Goto wrote:
>
> Hello, Dan-san,
>
> On 2021/02/27 4:24, Dan Williams wrote:
> > On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong wrote:
> >>
> >> On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com wrot
On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
>
> On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > On Sat, Feb 27, 2021 at 2:36 PM Dave Chinner wrote:
> > > On Fri, Feb 26, 2021 at 02:41:34PM -0800, Dan Williams wrote:
> > > > On Fri, Feb
301 - 400 of 9324 matches
Mail list logo
