From: Ira Weiny
Remove the pattern of kmap/mem*/kunmap in favor of the new mem*_page()
functions which handle the kmap'ing correctly for us.
Signed-off-by: Ira Weiny
---
fs/hfsplus/bnode.c | 53 +-
1 file changed, 15 insertions(+), 38 deletions
From: Ira Weiny
Use memcpy_page() instead of open coding kmap/memcpy/kunmap.
Cc: Steve French
Signed-off-by: Ira Weiny
---
fs/cifs/smb2ops.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
index 504766cb6c19..d1088ee9a0e6
From: Ira Weiny
The following pattern is used often:
kmap()
memcpy(), memmove(), or memset()
kunmap()
The problem with this is 2 fold: 1) This is best done with k[un]map_atomic().
2) kmap() is expanding and evolving beyond the use of highmem.
To the second point we
From: Ira Weiny
Too many users are using kmap_*() incorrectly and a common pattern is
for them to kmap/mempcy/kunmap. Change these calls to use the newly
lifted memcpy_[to|from]_page() calls.
Cc: Luis Chamberlain
Signed-off-by: Ira Weiny
---
drivers/base/firmware_loader/fallback.c | 11
From: Ira Weiny
Currently struct irqentry_state_t only contains a single bool value
which makes passing it by value is reasonable. However, future patches
add information to this struct. This includes the PKRS thread state,
included in this series, as well as information to store kmap
the looks of it, it was quite a successful auction.
Ira
From: MoPo List on behalf of Christopher Quarles
Reply-To: Christopher Quarles
Date: Monday, November 23, 2020 at 2:40 PM
To: "MoPo-L@LISTSERV.AMERICAN.EDU"
Subject: Re: [MOPO] What's going on with today's Heritage auctio
On Thu, Nov 19, 2020 at 06:34:01PM -0800, Dan Williams wrote:
> Convert to the LICENSES/ directory format for COPYING from the Linux
> kernel, and switch all remaining files over to SPDX annotations.
>
> Cc: Ira Weiny
LGTM
Reviewed-by: Ira Weiny
> Reported-by: Christoph Hellwi
On Sun, Nov 15, 2020 at 07:58:52PM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Nov 06 2020 at 15:29, ira weiny wrote:
>
> Subject prefix wants to 'entry:'. This changes generic code and the x86
> part is just required to fix the generic code change.
Sorry, yes that was c
On Sun, Nov 15, 2020 at 07:58:52PM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Nov 06 2020 at 15:29, ira weiny wrote:
>
> Subject prefix wants to 'entry:'. This changes generic code and the x86
> part is just required to fix the generic code change.
Sorry, yes that was c
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 78a56e0494ad29feccd4c54c2b5682721f8cb988
Gitweb:
https://git.kernel.org/tip/78a56e0494ad29feccd4c54c2b5682721f8cb988
Author:Ira Weiny
AuthorDate:Wed, 04 Nov 2020 15:01:57 -08:00
Committer
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 8ca2378089994a0508248230e1a1e75f73102d32
Gitweb:
https://git.kernel.org/tip/8ca2378089994a0508248230e1a1e75f73102d32
Author:Ira Weiny
AuthorDate:Wed, 04 Nov 2020 15:01:57 -08:00
Committer
From: Ira Weiny
There are 3 places in namei.c where the equivalent of ext2_put_page() is
open coded on a page which was returned from the ext2_get_page() call
[through the use of ext2_find_entry() and ext2_dotdot()].
Move ext2_put_page() to ext2.h and use it in namei.c
Also add a comment
o work all of the time.
> > >
> > > And all this comes about because DAX is a property of the block
> > > device, not the filesystem. Hence the only time a DAX capable
> > > filesystem on a block device that is DAX capable will not be DAX
> > > capable is if the dax=never is set...
> > See, it is not property of the block device. It is property of the mount
> > point. The availability on the device is one requirement but the
> > filesystem options affect availability to the user in the end.
>
> No, it is not really a property of the mountpoint either. If anything it is
> a property of the inode. Two different inodes on the very same filesystem,
> one may support DAX the other will not (think for example of XFS real-time
> volumes, or simply inodes with / without S_DAX flag set). And we are back
> at what Dave tries to get accross. As inconvenient as it is
> statx(STATX_ATTR_DAX) is the only way to tell.
>
> > > Of course, this is just encoding how existing filesystems behave -
> > > it's not a requirement for future filesytsems so they may use other
> > > mechanisms for enabling/disabling DAX. Which leaves you with the
> > > only reliable mechanism of creating filesystem and checking
> > > statx(STATX_ATTR_DAX)
> > Or the kernel could just tell the user. But right, information is power,
> > and keeping the user in the dark is much more entertaining.
>
> I think it would be more productive if you actually answered Ted's
> question: Exactly which application got broken by the change? I know for a
> fact that one large DB vendor was parsing mount options in /proc/mounts to
> determine whether their DB can use DAX or not (and this was already a
> "cleaned up" method because before this they were parsing VMA flags in
> /proc//smaps which is even worse). But in this case they also seemed
> OK to switch to statx() once it is available...
I agree. I struggled over these options and what to present when I added the
feature and I never intended to break anything.
That said, I'm not sure what exactly is broken. Moreover, I'm concerned that
there may be more wrong here than just the lack of a 'dax' option string in the
mount.
Ira
From: Ira Weiny
There are 3 places in namei.c where the equivalent of ext2_put_page() is
open coded on a page which was returned from the ext2_get_page() call
[through the use of ext2_find_entry() and ext2_dotdot()].
Move ext2_get_page() and ext2_put_page() to ext2.h in order to help
clarify
, if you open the hot water valve when the machine is cold and lift the lever does water come out? Wait a minute to see.
-- Ira
--
You received this message because you are subscribed to the Google Groups "Brewtus" group.
To unsubscribe from this group and stop receiving emails fro
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required t
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required t
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required t
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required t
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required t
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required t
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required t
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required t
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required t
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required t
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required t
From: Ira Weiny
Changes from V2 [4]
Rebased on tip-tree/core/entry
From Thomas Gleixner
Address bisectability
Drop Patch:
x86/entry: Move nmi entry/exit into common code
From Greg KH
Remove WARN_ON's
From: Ira Weiny
The PKRS MSR is not managed by XSAVE. It is preserved through a context
switch but this support leaves exception handling code open to memory
accesses during exceptions.
2 possible places for preserving this state were considered,
irqentry_state_t or pt_regs.[1] pt_regs
using a
supervisor specific MSR.
Kernel users can thus defines 'domains' of page mappings which have an
extra level of protection beyond those specified in the supervisor page
table entries.
Enable PKS on supported CPUS.
Co-developed-by: Ira Weiny
Signed-off-by: Ira Weiny
Signed-off-by: Fenghua Yu
using a
supervisor specific MSR.
Kernel users can thus defines 'domains' of page mappings which have an
extra level of protection beyond those specified in the supervisor page
table entries.
Enable PKS on supported CPUS.
Co-developed-by: Ira Weiny
Signed-off-by: Ira Weiny
Signed-off-by: Fenghua Yu
(), pks_mkrdwr(), and pks_key_free(). Add 2 new macros;
PAGE_KERNEL_PKEY(key) and _PAGE_PKEY(pkey).
Update the protection key documentation to cover pkeys on supervisor
pages.
Co-developed-by: Ira Weiny
Signed-off-by: Ira Weiny
Signed-off-by: Fenghua Yu
---
Changes from V2
From Greg
From: Ira Weiny
The core PKS functionality provides an interface for kernel users to
reserve keys to their domains set up the page tables with those keys and
control access to those domains when needed.
Define test code which exercises the core functionality of PKS via a
debugfs entry. Basic
From: Ira Weiny
Currently struct irqentry_state_t only contains a single bool value
which makes passing it by value is reasonable. However, future patches
propose to add information to this struct, for example the PKRS
register/thread state.
Adding information to irqentry_state_t makes passing
From: Ira Weiny
When only user space pkeys are enabled faulting within the kernel was an
unexpected condition which should never happen. Therefore a WARN_ON in
the kernel fault handler would detect if it ever did. Now this is no
longer the case if PKS is enabled and supported.
Report a Pkey
From: Ira Weiny
When only user space pkeys are enabled faulting within the kernel was an
unexpected condition which should never happen. Therefore a WARN_ON in
the kernel fault handler would detect if it ever did. Now this is no
longer the case if PKS is enabled and supported.
Report a Pkey
From: Ira Weiny
Currently struct irqentry_state_t only contains a single bool value
which makes passing it by value is reasonable. However, future patches
propose to add information to this struct, for example the PKRS
register/thread state.
Adding information to irqentry_state_t makes passing
From: Ira Weiny
Define a helper, update_pkey_val(), which will be used to support both
Protection Key User (PKU) and the new Protection Key for Supervisor
(PKS) in subsequent patches.
Co-developed-by: Peter Zijlstra
Signed-off-by: Peter Zijlstra
Signed-off-by: Ira Weiny
---
Changes from RFC
From: Ira Weiny
Protection Keys for Supervisor pages (PKS) enables fast, hardware thread
specific, manipulation of permission restrictions on supervisor page
mappings. It uses the same mechanism of Protection Keys as those on
User mappings but applies that mechanism to supervisor mappings using
From: Ira Weiny
Protection Keys for Supervisor pages (PKS) enables fast, hardware thread
specific, manipulation of permission restrictions on supervisor page
mappings. It uses the same mechanism of Protection Keys as those on
User mappings but applies that mechanism to supervisor mappings using
From: Ira Weiny
The PKRS MSR is not managed by XSAVE. It is preserved through a context
switch but this support leaves exception handling code open to memory
accesses during exceptions.
2 possible places for preserving this state were considered,
irqentry_state_t or pt_regs.[1] pt_regs
From: Ira Weiny
The core PKS functionality provides an interface for kernel users to
reserve keys to their domains set up the page tables with those keys and
control access to those domains when needed.
Define test code which exercises the core functionality of PKS via a
debugfs entry. Basic
From: Ira Weiny
Define a helper, update_pkey_val(), which will be used to support both
Protection Key User (PKU) and the new Protection Key for Supervisor
(PKS) in subsequent patches.
Co-developed-by: Peter Zijlstra
Signed-off-by: Peter Zijlstra
Signed-off-by: Ira Weiny
---
Changes from RFC
(), pks_mkrdwr(), and pks_key_free(). Add 2 new macros;
PAGE_KERNEL_PKEY(key) and _PAGE_PKEY(pkey).
Update the protection key documentation to cover pkeys on supervisor
pages.
Co-developed-by: Ira Weiny
Signed-off-by: Ira Weiny
Signed-off-by: Fenghua Yu
---
Changes from V2
From Greg
From: Ira Weiny
Changes from V2 [4]
Rebased on tip-tree/core/entry
From Thomas Gleixner
Address bisectability
Drop Patch:
x86/entry: Move nmi entry/exit into common code
From Greg KH
Remove WARN_ON's
From: Ira Weiny
Protection Keys User (PKU) and Protection Keys Supervisor (PKS) work in
similar fashions and can share common defines. Specifically PKS and PKU
each have:
1. A single control register
2. The same number of keys
3. The same number of bits in the register
From: Ira Weiny
The PKRS MSR is defined as a per-logical-processor register. This
isolates memory access by logical CPU. Unfortunately, the MSR is not
managed by XSAVE. Therefore, tasks must save/restore the MSR value on
context switch.
Define a saved PKRS value in the task struct, as well
From: Ira Weiny
The PKRS MSR is defined as a per-logical-processor register. This
isolates memory access by logical CPU. Unfortunately, the MSR is not
managed by XSAVE. Therefore, tasks must save/restore the MSR value on
context switch.
Define a saved PKRS value in the task struct, as well
From: Ira Weiny
Protection Keys User (PKU) and Protection Keys Supervisor (PKS) work in
similar fashions and can share common defines. Specifically PKS and PKU
each have:
1. A single control register
2. The same number of keys
3. The same number of bits in the register
cgroup could be thought of as local to the code in mm/memcontrol.c.
As such the detail of the member of the page struct that the code depends on is
a valuable part of the comment. Having to look at page_memcg() to find out
this information is kind of annoying.
Ira
>
> Signed-off-by: Alex Shi
>
not sure what BTF_ID
does?
Ira
>
> Signed-off-by: Alex Shi
> Cc: Andrew Morton
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> ---
> mm/filemap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/filemap.c b/mm/
From: Ira Weiny
s/reguired/required/
s/Interupts/Interrupts/
s/quiescient/quiescent/
s/assemenbly/assembly/
Signed-off-by: Ira Weiny
---
include/linux/entry-common.h | 4 ++--
kernel/entry/common.c| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux
On Wed, Nov 04, 2020 at 02:45:54PM -0800, 'Ira Weiny' wrote:
> On Wed, Nov 04, 2020 at 11:00:04PM +0100, Thomas Gleixner wrote:
> > On Wed, Nov 04 2020 at 09:46, Ira Weiny wrote:
> > > On Tue, Nov 03, 2020 at 12:36:16AM +0100, Thomas Gleixner wrote:
> > >> This
On Wed, Nov 04, 2020 at 02:45:54PM -0800, 'Ira Weiny' wrote:
> On Wed, Nov 04, 2020 at 11:00:04PM +0100, Thomas Gleixner wrote:
> > On Wed, Nov 04 2020 at 09:46, Ira Weiny wrote:
> > > On Tue, Nov 03, 2020 at 12:36:16AM +0100, Thomas Gleixner wrote:
> > >> This
On Wed, Nov 04, 2020 at 11:00:04PM +0100, Thomas Gleixner wrote:
> On Wed, Nov 04 2020 at 09:46, Ira Weiny wrote:
> > On Tue, Nov 03, 2020 at 12:36:16AM +0100, Thomas Gleixner wrote:
> >> This is the wrong ordering, really.
> >>
> >> x86/entry:
On Wed, Nov 04, 2020 at 11:00:04PM +0100, Thomas Gleixner wrote:
> On Wed, Nov 04 2020 at 09:46, Ira Weiny wrote:
> > On Tue, Nov 03, 2020 at 12:36:16AM +0100, Thomas Gleixner wrote:
> >> This is the wrong ordering, really.
> >>
> >> x86/entry:
On Tue, Nov 03, 2020 at 12:36:16AM +0100, Thomas Gleixner wrote:
> On Mon, Nov 02 2020 at 12:53, ira weiny wrote:
> > Fenghua Yu (2):
> > x86/pks: Enable Protection Keys Supervisor (PKS)
> > x86/pks: Add PKS kernel API
> >
> > Ira Weiny (7):
> > x86/pke
On Tue, Nov 03, 2020 at 12:36:16AM +0100, Thomas Gleixner wrote:
> On Mon, Nov 02 2020 at 12:53, ira weiny wrote:
> > Fenghua Yu (2):
> > x86/pks: Enable Protection Keys Supervisor (PKS)
> > x86/pks: Add PKS kernel API
> >
> > Ira Weiny (7):
> > x86/pke
On Tue, Nov 03, 2020 at 07:14:07PM +0100, Greg KH wrote:
> On Tue, Nov 03, 2020 at 09:53:36AM -0800, Ira Weiny wrote:
> > On Tue, Nov 03, 2020 at 07:50:24AM +0100, Greg KH wrote:
> > > On Mon, Nov 02, 2020 at 12:53:15PM -0800, ira.we...@intel.com wrote:
> &
On Tue, Nov 03, 2020 at 07:14:07PM +0100, Greg KH wrote:
> On Tue, Nov 03, 2020 at 09:53:36AM -0800, Ira Weiny wrote:
> > On Tue, Nov 03, 2020 at 07:50:24AM +0100, Greg KH wrote:
> > > On Mon, Nov 02, 2020 at 12:53:15PM -0800, ira.we...@intel.com wrote:
> &
an error.
>
> Are you sure, that feels odd...
It does feel odd and downright wrong... But there are a lot of WARN_ON_ONCE's
out there to catch this type of internal programming error. Is panic-on-warn
commonly used?
Ira
an error.
>
> Are you sure, that feels odd...
It does feel odd and downright wrong... But there are a lot of WARN_ON_ONCE's
out there to catch this type of internal programming error. Is panic-on-warn
commonly used?
Ira
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
From: Ira Weiny
When only user space pkeys are enabled faulting within the kernel was an
unexpected condition which should never happen. Therefore a WARN_ON in
the kernel fault handler would detect if it ever did. Now this is no
longer the case if PKS is enabled and supported.
Report a Pkey
From: Ira Weiny
The PKRS MSR is not managed by XSAVE. It is preserved through a context
switch but this support leaves exception handling code open to memory
accesses during exceptions.
2 possible places for preserving this state were considered,
irqentry_state_t or pt_regs.[1] pt_regs
and then enable PKS when configured and
indicated by the CPU instance. While not strictly necessary in this
patch, ARCH_HAS_SUPERVISOR_PKEYS separates this functionality through
the patch series so it is introduced here.
Co-developed-by: Ira Weiny
Signed-off-by: Ira Weiny
Signed-off-by: Fenghua Yu
From: Ira Weiny
Changes from V1
Rebase to TIP master; resolve conflicts and test
Clean up some kernel docs updates missed in V1
Add irqentry_state_t kernel doc for PKRS field
Removed redundant irq_state->pkrs
This is only needed when we
From: Ira Weiny
The core PKS functionality provides an interface for kernel users to
reserve keys to their domains set up the page tables with those keys and
control access to those domains when needed.
Define test code which exercises the core functionality of PKS via a
debugfs entry. Basic
From: Ira Weiny
The core PKS functionality provides an interface for kernel users to
reserve keys to their domains set up the page tables with those keys and
control access to those domains when needed.
Define test code which exercises the core functionality of PKS via a
debugfs entry. Basic
From: Ira Weiny
Protection Keys User (PKU) and Protection Keys Supervisor (PKS) work in
similar fashions and can share common defines. Specifically PKS and PKU
each have:
1. A single control register
2. The same number of keys
3. The same number of bits in the register
(), pks_mkrdwr(), and pks_key_free(). Add 2 new macros;
PAGE_KERNEL_PKEY(key) and _PAGE_PKEY(pkey).
Update the protection key documentation to cover pkeys on supervisor
pages.
Co-developed-by: Ira Weiny
Signed-off-by: Ira Weiny
Signed-off-by: Fenghua Yu
---
Changes from V1
Per Dave
From: Ira Weiny
The PKRS MSR is defined as a per-logical-processor register. This
isolates memory access by logical CPU. Unfortunately, the MSR is not
managed by XSAVE. Therefore, tasks must save/restore the MSR value on
context switch.
Define a saved PKRS value in the task struct, as well
From: Ira Weiny
Currently struct irqentry_state_t only contains a single bool value
which makes passing it by value is reasonable. However, future patches
propose to add information to this struct, for example the PKRS
register/thread state.
Adding information to irqentry_state_t makes passing
irqentry_state_t to carry lockdep state.
Ira: Make exit_rcu and lockdep a union as they are mutually exclusive
between the IRQ and NMI exceptions, and add kernel documentation for
struct irqentry_state_t
Signed-off-by: Thomas Gleixner
Signed-off-by: Ira Weiny
---
Changes from V1
Update commit
From: Ira Weiny
Define a helper, update_pkey_val(), which will be used to support both
Protection Key User (PKU) and the new Protection Key for Supervisor
(PKS) in subsequent patches.
Co-developed-by: Peter Zijlstra
Signed-off-by: Peter Zijlstra
Signed-off-by: Ira Weiny
---
Changes from RFC
From: Ira Weiny
When only user space pkeys are enabled faulting within the kernel was an
unexpected condition which should never happen. Therefore a WARN_ON in
the kernel fault handler would detect if it ever did. Now this is no
longer the case if PKS is enabled and supported.
Report a Pkey
From: Ira Weiny
Currently struct irqentry_state_t only contains a single bool value
which makes passing it by value is reasonable. However, future patches
propose to add information to this struct, for example the PKRS
register/thread state.
Adding information to irqentry_state_t makes passing
From: Ira Weiny
The PKRS MSR is not managed by XSAVE. It is preserved through a context
switch but this support leaves exception handling code open to memory
accesses during exceptions.
2 possible places for preserving this state were considered,
irqentry_state_t or pt_regs.[1] pt_regs
(), pks_mkrdwr(), and pks_key_free(). Add 2 new macros;
PAGE_KERNEL_PKEY(key) and _PAGE_PKEY(pkey).
Update the protection key documentation to cover pkeys on supervisor
pages.
Co-developed-by: Ira Weiny
Signed-off-by: Ira Weiny
Signed-off-by: Fenghua Yu
---
Changes from V1
Per Dave
irqentry_state_t to carry lockdep state.
Ira: Make exit_rcu and lockdep a union as they are mutually exclusive
between the IRQ and NMI exceptions, and add kernel documentation for
struct irqentry_state_t
Signed-off-by: Thomas Gleixner
Signed-off-by: Ira Weiny
---
Changes from V1
Update commit
From: Ira Weiny
The PKRS MSR is defined as a per-logical-processor register. This
isolates memory access by logical CPU. Unfortunately, the MSR is not
managed by XSAVE. Therefore, tasks must save/restore the MSR value on
context switch.
Define a saved PKRS value in the task struct, as well
From: Ira Weiny
Protection Keys User (PKU) and Protection Keys Supervisor (PKS) work in
similar fashions and can share common defines. Specifically PKS and PKU
each have:
1. A single control register
2. The same number of keys
3. The same number of bits in the register
From: Ira Weiny
Changes from V1
Rebase to TIP master; resolve conflicts and test
Clean up some kernel docs updates missed in V1
Add irqentry_state_t kernel doc for PKRS field
Removed redundant irq_state->pkrs
This is only needed when we
and then enable PKS when configured and
indicated by the CPU instance. While not strictly necessary in this
patch, ARCH_HAS_SUPERVISOR_PKEYS separates this functionality through
the patch series so it is introduced here.
Co-developed-by: Ira Weiny
Signed-off-by: Ira Weiny
Signed-off-by: Fenghua Yu
From: Ira Weiny
Define a helper, update_pkey_val(), which will be used to support both
Protection Key User (PKU) and the new Protection Key for Supervisor
(PKS) in subsequent patches.
Co-developed-by: Peter Zijlstra
Signed-off-by: Peter Zijlstra
Signed-off-by: Ira Weiny
---
Changes from RFC
The following commit has been merged into the core/entry branch of tip:
Commit-ID: 45ff510517f3b1354a3d9c273ad5e5e8d08312cb
Gitweb:
https://git.kernel.org/tip/45ff510517f3b1354a3d9c273ad5e5e8d08312cb
Author:Ira Weiny
AuthorDate:Wed, 28 Oct 2020 09:36:32 -07:00
Committer
Also yet the Sibley app states "pied wing pattern resembles dark M of other
species" in description of Juvenile Sabine's Gull, but let us note that the
juvenile wing pattern is the same as the adult wing pattern.
Ira Sanders
Golden, CO
On Wed, Oct 28, 2020 at 4:32 PM Charles Hundertm
From: Ira Weiny
irq_enter_from_user_mode() was changed to
irqentry_enter_from_user_mode(). Update the comment within
irqentry_enter() to reflect this change.
Suggested-by: Thomas Gleixner
Signed-off-by: Ira Weiny
---
Resend due to mail being dropped on it's way to LKML
kernel/entry
On Fri, Oct 23, 2020 at 11:56:33PM +0200, Thomas Gleixner wrote:
> On Thu, Oct 22 2020 at 15:26, ira weiny wrote:
> > From: Ira Weiny
> >
> > In preparation for adding PKS information to struct irqentry_state_t
> > change all call sites and usages to pass the stru
On Fri, Oct 23, 2020 at 11:56:33PM +0200, Thomas Gleixner wrote:
> On Thu, Oct 22 2020 at 15:26, ira weiny wrote:
> > From: Ira Weiny
> >
> > In preparation for adding PKS information to struct irqentry_state_t
> > change all call sites and usages to pass the stru
On Fri, Oct 23, 2020 at 11:50:11PM +0200, Thomas Gleixner wrote:
> On Thu, Oct 22 2020 at 15:26, ira weiny wrote:
>
> > From: Thomas Gleixner
> >
> > Lockdep state handling on NMI enter and exit is nothing specific to X86.
> > It's
> > not any different on
On Fri, Oct 23, 2020 at 11:50:11PM +0200, Thomas Gleixner wrote:
> On Thu, Oct 22 2020 at 15:26, ira weiny wrote:
>
> > From: Thomas Gleixner
> >
> > Lockdep state handling on NMI enter and exit is nothing specific to X86.
> > It's
> > not any different on
onally. As soon as I do anything, it corrects itself. It didn't select
another message so in effect, it's still on that message even though it
disappeared.
-- Ira
'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html
really late but I guess it's finding something to eat.
Earlier in the day I had a dark morph Rough-legged Hawk between 6th Ave and
the Fossil Trace Golf Course in Golden.
--
Ira Sanders
Golden, CO
"My mind is a raging torrent flooded with rivulets of thought cascading
into a waterfall of cre
hitting send the message became unread
and disappeared as expected, but the message body is still displayed in the
message pane even though the header no longer exists in the message list above
it.
Thanks, Ira
'Using TBBETA' information
irqentry_state_t to carry lockdep state.
Signed-off-by: Thomas Gleixner
Signed-off-by: Ira Weiny
---
arch/x86/entry/common.c | 34 ---
arch/x86/include/asm/idtentry.h | 3 ---
arch/x86/kernel/cpu/mce/core.c | 6 +++---
arch/x86/kernel/nmi.c | 6 +++---
arch
(), pks_mkrdwr(), and pks_key_free(). Add 2 new macros;
PAGE_KERNEL_PKEY(key) and _PAGE_PKEY(pkey).
Update the protection key documentation to cover pkeys on supervisor
pages.
Co-developed-by: Ira Weiny
Signed-off-by: Ira Weiny
Signed-off-by: Fenghua Yu
---
Changes from RFC V3
Per
From: Ira Weiny
When only user space pkeys are enabled faulting within the kernel was an
unexpected condition which should never happen. Therefore a WARN_ON in
the kernel fault handler would detect if it ever did. Now this is no
longer the case if PKS is enabled and supported.
Report a Pkey
From: Ira Weiny
Protection Keys User (PKU) and Protection Keys Supervisor (PKS) work in
similar fashions and can share common defines. Specifically PKS and PKU
each have:
1. A single control register
2. The same number of keys
3. The same number of bits in the register
From: Ira Weiny
When only user space pkeys are enabled faulting within the kernel was an
unexpected condition which should never happen. Therefore a WARN_ON in
the kernel fault handler would detect if it ever did. Now this is no
longer the case if PKS is enabled and supported.
Report a Pkey
From: Ira Weiny
The PKRS MSR is defined as a per-logical-processor register. This
isolates memory access by logical CPU. Unfortunately, the MSR is not
managed by XSAVE. Therefore, tasks must save/restore the MSR value on
context switch.
Define a saved PKRS value in the task struct, as well
From: Ira Weiny
The PKRS MSR is defined as a per-logical-processor register. This
isolates memory access by logical CPU. Unfortunately, the MSR is not
managed by XSAVE. Therefore, tasks must save/restore the MSR value on
context switch.
Define a saved PKRS value in the task struct, as well
801 - 900 of 13060 matches
Mail list logo
