commit 7d988097c546 ("acpi/nfit, libnvdimm/security: Add security DSM overwrite
support")
adds a sysfs_notify_dirent() to wake up userspace poll thread when the
"overwrite"
operation has completed. But the notification is issued before the internal
dimm security state and flags have been updated,
Since
commit d78c620a2e82 ("libnvdimm/security: Introduce a 'frozen' attribute"),
when issue
then immediately check the 'security' attribute,
unlocked
Actually the attribute stays 'unlocked' through out the entire overwrite
operation, never changed. That's because 'nvdimm->sec.flags' is a bitma
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Ira,
Ira Weiny writes:
> On Thu, Jul 23, 2020 at 09:53:20PM +0200, Thomas Gleixner wrote:
> I think, after fixing my code (see below), using idtentry_state could still
> work. If the per-cpu cache and the MSR is updated in idtentry_exit() that
> should carry the state to the new cpu, correct?
I
Andy Lutomirski writes:
>> On Jul 23, 2020, at 1:22 PM, Thomas Gleixner wrote:
>> Andy Lutomirski writes:
>>> My suggestion is to enlarge pt_regs. The save and restore logic can
>>> probably be in C, but pt_regs is the logical place to put a register
>>> that is saved and restored across all e
On Thu, Jul 23, 2020 at 09:53:20PM +0200, Thomas Gleixner wrote:
> Ira,
>
> ira.we...@intel.com writes:
>
> > ...
> > // ref == 0
> > dev_access_enable() // ref += 1 ==> disable protection
> > irq()
> > // enable protection
> > // ref =
> On Jul 23, 2020, at 1:22 PM, Thomas Gleixner wrote:
>
> Andy Lutomirski writes:
>
>> Suppose some kernel code (a syscall or kernel thread) changes PKRS
>> then takes a page fault. The page fault handler needs a fresh
>> PKRS. Then the page fault handler (say a VMA’s .fault handler) changes
>>
Dave Hansen writes:
> On 7/23/20 10:08 AM, Andy Lutomirski wrote:
>> Suppose some kernel code (a syscall or kernel thread) changes PKRS
>> then takes a page fault. The page fault handler needs a fresh PKRS.
>> Then the page fault handler (say a VMA’s .fault handler) changes
>> PKRS. The we get a
Andy Lutomirski writes:
> Suppose some kernel code (a syscall or kernel thread) changes PKRS
> then takes a page fault. The page fault handler needs a fresh
> PKRS. Then the page fault handler (say a VMA’s .fault handler) changes
> PKRS. The we get an interrupt. The interrupt *also* needs a fres
Thomas Gleixner writes:
> Ira Weiny writes:
>> On Fri, Jul 17, 2020 at 12:06:10PM +0200, Peter Zijlstra wrote:
>>> On Fri, Jul 17, 2020 at 12:20:56AM -0700, ira.we...@intel.com wrote:
>> I've been really digging into this today and I'm very concerned that I'm
>> completely missing something WRT
Ira Weiny writes:
> On Fri, Jul 17, 2020 at 12:06:10PM +0200, Peter Zijlstra wrote:
>> On Fri, Jul 17, 2020 at 12:20:56AM -0700, ira.we...@intel.com wrote:
> I've been really digging into this today and I'm very concerned that I'm
> completely missing something WRT idtentry_enter() and idtentry_ex
Ira,
ira.we...@intel.com writes:
> ...
> // ref == 0
> dev_access_enable() // ref += 1 ==> disable protection
> irq()
> // enable protection
> // ref = 0
> _handler()
> dev_a
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
When processing all namespaces and no namespaces exist user gets the
default -ENOENT. Set default rc to 0 when processing all namespaces.
This avoids confusing error message printed in addition to the message
saying 0 namespaces were affected.
Before:
# ndctl check-namespace all
namespace0.0: na
The kernel always creates zero length namespace with uuid 0 in each
region.
When processing all namespaces the user gets confusing errors from ndctl
trying to process this namespace. Skip it.
The user can still specify the namespace by name directly in case
processing it is desirable.
Fixes: #41
On 7/23/20 10:08 AM, Andy Lutomirski wrote:
> Suppose some kernel code (a syscall or kernel thread) changes PKRS
> then takes a page fault. The page fault handler needs a fresh PKRS.
> Then the page fault handler (say a VMA’s .fault handler) changes
> PKRS. The we get an interrupt. The interrupt *
> On Jul 23, 2020, at 9:52 AM, Fenghua Yu wrote:
>
> Hi, Dave,
>
>> On Thu, Jul 23, 2020 at 09:23:13AM -0700, Dave Hansen wrote:
>>> On 7/23/20 9:18 AM, Fenghua Yu wrote:
>>> The PKRS MSR has been preserved in thread_info during kernel entry. We
>>> don't need to preserve it in another place (
Hi, Dave,
On Thu, Jul 23, 2020 at 09:23:13AM -0700, Dave Hansen wrote:
> On 7/23/20 9:18 AM, Fenghua Yu wrote:
> > The PKRS MSR has been preserved in thread_info during kernel entry. We
> > don't need to preserve it in another place (i.e. idtentry_state).
>
> I'm missing how the PKRS MSR gets pre
On 7/23/20 9:18 AM, Fenghua Yu wrote:
> The PKRS MSR has been preserved in thread_info during kernel entry. We
> don't need to preserve it in another place (i.e. idtentry_state).
I'm missing how the PKRS MSR gets preserved in thread_info. Could you
explain the mechanism by which this happens and
On Wed, Jul 22, 2020 at 09:21:43AM -0700, Andy Lutomirski wrote:
> On Fri, Jul 17, 2020 at 12:21 AM wrote:
> >
> > From: Ira Weiny
> >
> > The PKRS MSR is not managed by XSAVE. It is already preserved through a
> > context switch but this support leaves exception handling code open to
> > memory
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
Greetings,
I wonder why you continue neglecting my emails. Please, acknowledge
the receipt of this message in reference to the subject above as I
intend to send to you the details of the mail. Sometimes, try to check
your spam box because most of these correspondences fall out sometimes
in SPAM fo
23 matches
Mail list logo
