Some NVDIMMs, in addition to providing an indication of whether the
previous shutdown was clean, also provide a running count of lifetime
dirty-shutdown events for the device. In anticipation of this
functionality appearing on more devices arrange for the nfit driver to
retrieve / cache this data
Allow the unit tests to verify the retrieval of the dirty shutdown
count via smart commands, and allow the driver-load-time retrieval of
the smart health payload to be simulated by nfit_test.
Signed-off-by: Dan Williams
---
drivers/acpi/nfit/core.c | 14 --
In preparation for adding a flag to indicate whether a DIMM publishes a
dirty-shutdown count, convert the existing flags to a bit field.
Signed-off-by: Dan Williams
---
drivers/acpi/nfit/core.c | 27 ---
drivers/acpi/nfit/nfit.h |8 ++--
2 files changed, 22
The Intel NVDIMM command specification publishes a dirty-shutdown-count
in addition to the dirty-shutdown / flush-failed indication that comes
from the ACPI NFIT. This is expected to be a common property of NVDIMMs
and is a static hardware health detail to be cached / exported via
sysfs.
Add
All that is missing is a helper to go from an nvdimm to its bus. With
the new nvdimm_to_bus() and nvdimm_ctl() helpers some boilerplate can be
consolidated.
Signed-off-by: Dan Williams
---
drivers/acpi/nfit/intel.c | 46 +++-
drivers/nvdimm/bus.c
Correct some spelling and stray comments.
Signed-off-by: Dan Williams
---
drivers/nvdimm/dimm_devs.c |8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/nvdimm/dimm_devs.c b/drivers/nvdimm/dimm_devs.c
index 06d0395c1f43..8740c6c61912 100644
---
In anticipation of other DIMMs adding security operations support, don't
require them to edit intel.h. Instead have intel.h optionally arrange
for intel_security_ops to be NULL or not based on build parameters.
Signed-off-by: Dan Williams
---
drivers/acpi/nfit/core.c | 10 ++
The following series implements the overwrite support for Intel nvdimm.
Overwrite DSM commands are part of Intel DSM v1.7 spec. It allows the
nvdimm to wipe all the information on the target nvdimm (including the
label area). The operation can take tens of mintues or more depending
on the size of
We are adding support for the security calls of ovewrite and query
overwrite from Intel DSM spec v1.7. This will allow triggering of
overwrite on Intel NVDIMMs. The overwrite operation can take tens
of minutes. When the overwrite DSM is issued successfully, the NVDIMMs
will be unaccessible. The
With the implementation of Intel NVDIMM DSM overwrite, we are adding unit
test to nfit_test for testing of overwrite operation.
Signed-off-by: Dave Jiang
---
drivers/acpi/nfit/intel.h|1 +
tools/testing/nvdimm/test/nfit.c | 55 ++
2 files
Adding a flag for nvdimm->flags to support erase functions. While it's ok
to hold the nvdimm_bus lock for secure erase due to minimal time to execute
the command, overwrite requires a significantly longer time and makes this
impossible. The flag will block any drivers from being loaded and DIMMs
Adding sysfs notification for when overwrite has completed to allow
user monitoring app to be aware of overwrite completion status.
Signed-off-by: Dave Jiang
---
drivers/acpi/nfit/core.c |5 +
drivers/nvdimm/dimm_devs.c | 12
drivers/nvdimm/nd-core.h |1 +
Add overwrite command usages to security documentation.
Signed-off-by: Dave Jiang
---
Documentation/nvdimm/security.txt | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/nvdimm/security.txt
b/Documentation/nvdimm/security.txt
index 50cbb6cb96a1..ded5f0e3f7c3
On Wed, Sep 26, 2018 at 2:51 PM Alexander Duyck
wrote:
>
> This change makes it so that we probe devices asynchronously instead of the
> driver. This results in us seeing the same behavior if the device is
> registered before the driver or after. This way we can avoid serializing
> the
On Wed, Sep 26, 2018 at 2:51 PM Alexander Duyck
wrote:
>
> This patch introduces four new variants of the async_schedule_ functions
> that allow scheduling on a specific NUMA node.
>
> The first two functions are async_schedule_near and
> async_schedule_near_domain which end up mapping to
On Wed, 26 Sep 2018 08:36:47 -0700 Dave Hansen wrote:
> On 09/26/2018 12:38 AM, Michal Hocko wrote:
> > Why cannot you simply go with [no]vm_page_poison[=on/off]?
>
> I was trying to look to the future a bit, if we end up with five or six
> more other options we want to allow folks to
On 9/26/2018 3:09 PM, Tejun Heo wrote:
Hello,
On Wed, Sep 26, 2018 at 03:05:17PM -0700, Alexander Duyck wrote:
I am using unbound workqueues. However there isn't an interface that
exposes the NUMA bits of them directly. All I am doing with this
patch is adding "queue_work_near" which takes a
Hello,
On Wed, Sep 26, 2018 at 03:05:17PM -0700, Alexander Duyck wrote:
> I am using unbound workqueues. However there isn't an interface that
> exposes the NUMA bits of them directly. All I am doing with this
> patch is adding "queue_work_near" which takes a NUMA node as an
> argument and then
On 9/26/2018 2:53 PM, Tejun Heo wrote:
Hello,
On Wed, Sep 26, 2018 at 02:51:38PM -0700, Alexander Duyck wrote:
This patch provides a new function queue_work_near which is meant to
schedule work on the nearest unbound CPU to the requested NUMA node. The
main motivation for this is to help
Hello,
On Wed, Sep 26, 2018 at 02:51:38PM -0700, Alexander Duyck wrote:
> This patch provides a new function queue_work_near which is meant to
> schedule work on the nearest unbound CPU to the requested NUMA node. The
> main motivation for this is to help assist asynchronous init to better
>
This patch is meant to force the device registration for nvdimm devices to
be closer to the actual device. This is achieved by using either the NUMA
node ID of the region, or of the parent. By doing this we can have
everything above the region based on the region, and everything below the
region
This change makes it so that we use the device specific version of the
async_schedule commands to defer various tasks related to devices. By doing
this we should see a slight improvement in performance as any device that
is sensitive to latency/locality in the setup will now be initializing on
the
This change makes it so that we probe devices asynchronously instead of the
driver. This results in us seeing the same behavior if the device is
registered before the driver or after. This way we can avoid serializing
the initialization should the driver not be loaded until after the devices
have
This patch introduces four new variants of the async_schedule_ functions
that allow scheduling on a specific NUMA node.
The first two functions are async_schedule_near and
async_schedule_near_domain which end up mapping to async_schedule and
async_schedule_domain but provide NUMA node specific
This patch provides a new function queue_work_near which is meant to
schedule work on the nearest unbound CPU to the requested NUMA node. The
main motivation for this is to help assist asynchronous init to better
improve boot times for devices that are local to a specific node.
Signed-off-by:
This patch set provides functionality that will help to improve the
locality of the async_schedule calls used to provide deferred
initialization.
This patch set originally started out with me focused on just the one call
to async_schedule_domain in the nvdimm tree that was being used to
defer the
On Wed, Sep 26, 2018 at 1:47 PM Dave Jiang wrote:
>
> The following series implements security support for nvdimm. Mostly adding
> new security DSM support from the Intel NVDIMM DSM spec v1.7, but also
> adding generic support libnvdimm for other vendors. The most important
> security features
Add nfit_test support for DSM functions "Get Security State",
"Set Passphrase", "Disable Passphrase", "Unlock Unit", "Freeze Lock",
and "Secure Erase" for the fake DIMMs.
Also adding a sysfs knob in order to put the DIMMs in "locked" state. The
order of testing DIMM unlocking would be.
1a.
Prepping the libnvdimm to support security management by adding a keyring
in order to provide passphrase management through the kernel key management
APIs.
Signed-off-by: Dave Jiang
Reviewed-by: Dan Williams
---
drivers/nvdimm/Kconfig |1 +
drivers/nvdimm/core.c |7 ++-
Add support for setting and/or updating passphrase on the Intel nvdimms.
The passphrase is pulled from userspace through the kernel key management.
We trigger the update via writing "update " to the
sysfs attribute "security". If no exists (for enabling security)
then a 0 should be used. The
Add support to disable passphrase (security) for the Intel nvdimm. The
passphrase used for disabling is pulled from userspace via the kernel
key management. The action is triggered by writing "disable " to
the sysfs attribute "security". libnvdimm will support the generic disable
API call. The
In order to access the nfit_test context via sideband sysfs knobs, the
dimm_dev needs to be more than struct device in order to point back to
struct nfit_test. Wrapping the original struct device with a struct
nfit_dimm_dev and saving the nfit_test as private driver data. Also
changing the
Add support to issue a secure erase DSM to the Intel nvdimm. The
required passphrase is acquired from userspace through the kernel key
management. To trigger the action, "erase " is written to the
"security" sysfs attribute. libnvdimm will support the erase generic API
call. The user key provided
Add theory of operation for the security support that's going into
libnvdimm.
Signed-off-by: Dave Jiang
---
Documentation/nvdimm/security.txt | 99 +
1 file changed, 99 insertions(+)
create mode 100644 Documentation/nvdimm/security.txt
diff --git
Export lookup_user_key() symbol in order to allow nvdimm passphrase
update to retrieve user injected keys.
Signed-off-by: Dave Jiang
Acked-by: David Howells
---
include/linux/key.h |3 +++
security/keys/internal.h |2 --
security/keys/process_keys.c |1 +
3 files
Add support for freeze security on Intel nvdimm. This locks out any
changes to security for the DIMM unless a reboot is done. This is triggered
by writing "freeze" to the "security" sysfs attribute. libnvdimm will
support the generic freeze_lock API call.
Signed-off-by: Dave Jiang
Reviewed-by:
Add support to allow query the security status of the Intel nvdimms and
also unlock the dimm via the kernel key management APIs. The passphrase is
expected to be pulled from userspace through keyutils. Moving the Intel
related bits to its own source file as well.
Signed-off-by: Dave Jiang
The generated dimm id is needed for the sysfs attribute as well as being
used as the identifier/description for the security key. Since it's
constant and should never change, store it as a member of struct nvdimm.
Signed-off-by: Dave Jiang
Reviewed-by: Dan Williams
---
drivers/acpi/nfit/core.c
Add command definition for security commands defined in Intel DSM
specification v1.7. This includes "get security state", "set passphrase",
"unlock unit", "freeze lock", "secure erase", "ovewrite", and
"overwrite query". Since we are adding a lot of Intel definitions, moving
the relevant bits to
The following series implements security support for nvdimm. Mostly adding
new security DSM support from the Intel NVDIMM DSM spec v1.7, but also
adding generic support libnvdimm for other vendors. The most important
security features are unlocking locked nvdimms, and updating/setting security
On Wed, Sep 26, 2018 at 11:25 AM Alexander Duyck
wrote:
>
>
>
> On 9/26/2018 12:55 AM, Michal Hocko wrote:
> > On Tue 25-09-18 13:21:24, Alexander Duyck wrote:
> >> The ZONE_DEVICE pages were being initialized in two locations. One was with
> >> the memory_hotplug lock held and another was
On 9/26/2018 12:55 AM, Michal Hocko wrote:
On Tue 25-09-18 13:21:24, Alexander Duyck wrote:
The ZONE_DEVICE pages were being initialized in two locations. One was with
the memory_hotplug lock held and another was outside of that lock. The
problem with this is that it was nearly doubling the
On 09/26/2018 08:24 AM, Alexander Duyck wrote:
> With no options it works just like slub_debug and enables all
> available options. So in our case it is a NOP since we wanted the
> debugging enabled by default.
Yeah, but slub_debug is different.
First, nobody uses the slub_debug=- option because
On 09/26/2018 12:38 AM, Michal Hocko wrote:
> Why cannot you simply go with [no]vm_page_poison[=on/off]?
I was trying to look to the future a bit, if we end up with five or six
more other options we want to allow folks to enable/disable. I don't
want to end up in a situation where we have a
On Wed 26-09-18 08:24:56, Alexander Duyck wrote:
> On 9/26/2018 12:38 AM, Michal Hocko wrote:
> > On Tue 25-09-18 13:20:12, Alexander Duyck wrote:
> > [...]
> > > + vm_debug[=options] [KNL] Available with CONFIG_DEBUG_VM=y.
> > > + May slow down system boot speed, especially
On 9/26/2018 12:38 AM, Michal Hocko wrote:
On Tue 25-09-18 13:20:12, Alexander Duyck wrote:
[...]
+ vm_debug[=options] [KNL] Available with CONFIG_DEBUG_VM=y.
+ May slow down system boot speed, especially when
+ enabled on systems with a
This Message was undeliverable due to the following reason:
Your message was not delivered because the destination computer was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely
On Tue 25-09-18 13:21:24, Alexander Duyck wrote:
> The ZONE_DEVICE pages were being initialized in two locations. One was with
> the memory_hotplug lock held and another was outside of that lock. The
> problem with this is that it was nearly doubling the memory initialization
> time. Instead of
On Tue 25-09-18 13:20:12, Alexander Duyck wrote:
[...]
> + vm_debug[=options] [KNL] Available with CONFIG_DEBUG_VM=y.
> + May slow down system boot speed, especially when
> + enabled on systems with a large amount of memory.
> +
49 matches
Mail list logo
