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 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 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:
> > >
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 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
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
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 add
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
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 was
xtend 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 c
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
S 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:
On Fri, Nov 06, 2020 at 07:24:55PM +0800, Alex Shi wrote:
> Otherwise it cause gcc warning:
> ^~~
> ../mm/filemap.c:830:14: warning: no previous prototype for
> ‘__add_to_page_cache_locked’ [-Wmissing-prototypes]
> noinline int __add_to_page_cache_locked(struct page *page,
>
On Fri, Nov 06, 2020 at 07:33:33PM +0800, Alex Shi wrote:
> The page->mem_cgroup member is replaced by memcg_data, and add a helper
> page_memcg() for it. Need to update comments to avoid confusing.
I'm not an expert in this code but IMO the pointer manipulation of
page->mem_cgroup could be though
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
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
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
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
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:
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 was
(), 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&#
On Mon, Jul 20, 2020 at 11:15:54AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2020 at 03:34:07PM -0700, Ira Weiny wrote:
> > On Fri, Jul 17, 2020 at 10:59:54AM +0200, Peter Zijlstra wrote:
> > > On Fri, Jul 17, 2020 at 12:20:43AM -0700, ira.we...@intel.com wrote:
> > &
On Mon, Jul 20, 2020 at 11:17:40AM +0200, Peter Zijlstra wrote:
> On Sat, Jul 18, 2020 at 09:13:19PM -0700, Ira Weiny wrote:
> > On Fri, Jul 17, 2020 at 11:21:39AM +0200, Peter Zijlstra wrote:
> > > On Fri, Jul 17, 2020 at 12:20:52AM -0700, ira.we...@intel.com wrote:
>
On Fri, Jul 17, 2020 at 11:30:41AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2020 at 12:20:56AM -0700, ira.we...@intel.com wrote:
> > +static void noinstr idt_save_pkrs(idtentry_state_t state)
>
> noinstr goes in the same place you would normally put inline, that's
> before the return type, n
On Tue, Jul 14, 2020 at 10:27:01AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 12:02:09AM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The PKRS MSR is defined as a per-core register. This isolates memory
> > access by CPU. Unfortunately,
On Tue, Jul 14, 2020 at 10:44:51AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 12:02:17AM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > Device managed pages may have additional protections. These protections
> > need to be removed prior t
On Tue, Jul 14, 2020 at 09:05:39PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 11:53:22AM -0700, Ira Weiny wrote:
> > On Tue, Jul 14, 2020 at 10:27:01AM +0200, Peter Zijlstra wrote:
> > > On Tue, Jul 14, 2020 at 12:02:09AM -0700, ira.we...@intel.com wrote:
>
On Tue, Jul 14, 2020 at 10:40:57AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 14, 2020 at 12:02:16AM -0700, ira.we...@intel.com wrote:
>
> > +static pgprot_t dev_protection_enable_get(struct dev_pagemap *pgmap,
> > pgprot_t prot)
> > +{
> > + if (pgmap->flags & PGMAP_PROT_ENABLED && dev_page_pk
On Tue, Jul 14, 2020 at 12:42:11PM -0700, Dave Hansen wrote:
> On 7/14/20 12:29 PM, Peter Zijlstra wrote:
> > On Tue, Jul 14, 2020 at 12:06:16PM -0700, Ira Weiny wrote:
> >> On Tue, Jul 14, 2020 at 10:44:51AM +0200, Peter Zijlstra wrote:
> >>> So, if I followed along
On Fri, Jul 17, 2020 at 10:54:42AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2020 at 12:20:41AM -0700, ira.we...@intel.com wrote:
> > +/*
> > + * Get a new pkey register value from the user values specified.
> > + *
> > + * Kernel users use the same flags as user space:
> > + * PKEY_DISABL
On Fri, Jul 17, 2020 at 10:31:40AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2020 at 12:20:43AM -0700, ira.we...@intel.com wrote:
>
> > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > index f362ce0d5ac0..d69250a7c1bf 100644
> > --- a/arch/x86/kernel/process.c
> > +++ b/
On Fri, Jul 17, 2020 at 10:59:54AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2020 at 12:20:43AM -0700, ira.we...@intel.com wrote:
> > +/*
> > + * Write the PKey Register Supervisor. This must be run with preemption
> > + * disabled as it does not guarantee the atomicity of updating the
> > p
On Fri, Jul 17, 2020 at 11:10:53AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2020 at 12:20:51AM -0700, ira.we...@intel.com wrote:
> > +static pgprot_t dev_protection_enable_get(struct dev_pagemap *pgmap,
> > pgprot_t prot)
> > +{
> > + if (pgmap->flags & PGMAP_PROT_ENABLED && dev_page_pkey
On Fri, Jul 17, 2020 at 11:17:18AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2020 at 12:20:51AM -0700, ira.we...@intel.com wrote:
> > +void dev_access_disable(void)
> > +{
> > + unsigned long flags;
> > +
> > + if (!static_branch_unlikely(&dev_protection_static_key))
> > + return
On Fri, Jul 17, 2020 at 11:21:39AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2020 at 12:20:52AM -0700, ira.we...@intel.com wrote:
> > @@ -31,6 +32,20 @@ static inline void invalidate_kernel_vmap_range(void
> > *vaddr, int size)
> >
> > #include
> >
> > +static inline void enable_access(
On Fri, Jul 17, 2020 at 11:22:43AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 17, 2020 at 12:20:53AM -0700, ira.we...@intel.com wrote:
>
> > --- a/drivers/dax/super.c
> > +++ b/drivers/dax/super.c
> > @@ -30,12 +30,14 @@ static DEFINE_SPINLOCK(dax_host_lock);
> >
> > int dax_read_lock(void)
> >
On Fri, Jul 24, 2020 at 11:24:58PM +0200, Thomas Gleixner wrote:
> Ira,
>
> Thomas Gleixner writes:
> > 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 c
On Fri, Jul 03, 2020 at 08:44:58PM -0700, Randy Dunlap wrote:
> Drop the doubled word "to".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Dan Williams
> Cc: Vishal Verma
> Cc: Dave Jiang
> Cc: Ira Weiny
condition
> > scale-invariant calculations can't be performed.
> >
> > Signed-off-by: Giovanni Gherdovich
> > Suggested-by: Ricardo Neri
>
> FWIW,
>
> Tested-by: Ricardo Neri
Is this going to make it as a fix to 5.8?
Tested-by: Ira Weiny
From: Ira Weiny
The noinstr qualifier is to be specified before the return type in the
same way inline is used.
These 2 cases were missed by previous patches.
Reviewed-by: Tony Luck
Signed-off-by: Ira Weiny
---
arch/x86/kernel/alternative.c | 2 +-
arch/x86/kernel/cpu/mce/core.c | 2 +-
2
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 Thu, Jul 23, 2020 at 10:15:17PM +0200, Thomas Gleixner wrote:
> 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:
&
On Fri, Jul 24, 2020 at 10:29:23AM -0700, Andy Lutomirski wrote:
>
> > On Jul 24, 2020, at 10:23 AM, Ira Weiny wrote:
> >
> > On Thu, Jul 23, 2020 at 10:15:17PM +0200, Thomas Gleixner wrote:
> >> Thomas Gleixner writes:
> >>
> >>> Ira Weiny
On Mon, Jul 20, 2020 at 11:43:03AM +0800, Tang Yizhou wrote:
> The return value of populate_vma_page_range() is consistent with
> __get_user_pages(), and so is the function comment of return value.
>
> Signed-off-by: Tang Yizhou
Reviewed-by: Ira Weiny
> ---
> mm/gup.c
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:
> > First I'm not sure if adding this state to idtentry_state and having
> > that state copied is the right way to go. It seems like we should start
> > passing th
On Wed, Jul 22, 2020 at 11:48:53AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 21, 2020 at 10:27:09PM -0700, Ira Weiny wrote:
>
> > I've been really digging into this today and I'm very concerned that I'm
> > completely missing something WRT idtentry_enter() a
rks
> it static.
>
> Signed-off-by: Wei Yongjun
Seems ok,
Reviewed-by: Ira Weiny
> ---
> drivers/dax/kmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> index 275aa5f87399..87e271668170 10064
From: Ira Weiny
This RFC series has been reviewed by Dave Hansen.
Changes from RFC:
Clean up commit messages based on Peter Zijlstra's and Dave Hansen's
feedback
Fix static branch anti-pattern
New patch:
(memremap: Convert devmap static
From: Ira Weiny
Protecting against stray writes is particularly important for PMEM
because, unlike writes to anonymous memory, writes to PMEM persists
across a reboot. Thus data corruption could result in permanent loss of
data. Therefore, there is no option presented to the user.
Enable
From: Ira Weiny
Protection Keys User (PKU) and Protection Keys Supervisor (PKS) work in
similar fashions.
Share code between them by creating a header with common defines, move
those defines into this header, change their names to reflect the new
use, and include the header where needed
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 accesses which the interrupted process has allowed.
Close this hole by preserve the current task's PKRS MSR, reset the PKR
From: Ira Weiny
The pmem driver uses a cached virtual address to access its memory
directly. Because the nvdimm driver is well aware of the special
protections it has mapped memory with, we call dev_access_[en|dis]able()
around the direct pmem->virt_addr (pmem_addr) usage instead of
se by others.
The interface maintains Access Disabled (AD=1) for all keys not
currently allocated. Therefore, the user can depend on access being
disabled when pks_key_alloc() returns a key.
Co-developed-by: Ira Weiny
Signed-off-by: Ira Weiny
Signed-off-by: Fenghua Yu
---
arch/x86/includ
From: Ira Weiny
Device managed memory exposes itself to the kernel direct map which
allows stray pointers to access these device memories.
Stray pointers to normal memory may result in a crash or other
undesirable behavior which, while unfortunate, are usually recoverable
with a reboot. Stray
From: Ira Weiny
Future Intel CPUS will support Protection Key Supervisor (PKS).
Update the protection key documentation to cover pkeys on supervisor
pages.
Signed-off-by: Ira Weiny
---
Documentation/core-api/protection-keys.rst | 81 +-
1 file changed, 63 insertions
From: Ira Weiny
dax_direct_access() is a special case of accessing pmem via a page
offset and without a struct page.
Because the dax driver is well aware of the special protections it has
mapped memory with, call dev_access_[en|dis]able() directly instead of
the unnecessary overhead of trying
From: Fenghua Yu
The sysadmin may need to know which PKS keys are currently being used.
Add a debugfs file to show the allocated PKS keys and their names.
Signed-off-by: Fenghua Yu
---
arch/x86/mm/pkeys.c | 40
1 file changed, 40 insertions(+)
diff --
From: Ira Weiny
The addition of PKS protection to dax read lock/unlock will require that
the address returned by dax_direct_access() be protected by this lock.
While not technically necessary for this series, this corrects the
locking by ensuring that the use of kaddr and end_kaddr are covered
From: Ira Weiny
Passing size to copy_user_dax implies it can copy variable sizes of data
when in fact it calls copy_user_page() which is exactly a page.
We are safe because the only caller uses PAGE_SIZE anyway so just remove
the variable for clarity.
While we are at it change copy_user_dax
From: Fenghua Yu
Define a helper, get_new_pkr(), 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: Ira Weiny
Signed-off-by: Ira Weiny
Signed-off-by: Fenghua Yu
---
arch/x86/include/asm/pkeys.h
From: Ira Weiny
While reviewing Protection Key Supervisor support it was pointed out
that using a counter to track static branch enable was an anti-pattern
which was better solved using the provided static_branch_{inc,dec}
functions.[1]
Fix up devmap_managed_key to work the same way. Also this
S 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:
From: Ira Weiny
Device managed pages may have additional protections. These protections
need to be removed prior to valid use by kernel users.
Check for special treatment of device managed pages in kmap and take
action if needed. We use kmap as an interface for generic kernel code
because
From: Ira Weiny
The PKRS MSR is defined as a per-logical-processor register. This
isolates memory access by CPU. Unfortunately, the MSR is not managed
by XSAVE. Therefore, We must preserve the protections for individual
tasks even if they are context switched out and placed on another cpu
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
On Sat, Sep 19, 2020 at 06:39:06PM +0100, Matthew Wilcox wrote:
> On Sat, Sep 19, 2020 at 10:18:54AM -0700, Linus Torvalds wrote:
> > On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote:
> > >
> > > this provides a preemptible variant of kmap_atomic & related
> > > interfaces. This is achieved b
On Tue, Sep 15, 2020 at 02:22:33AM +0530, Souptick Joarder wrote:
> On Mon, Sep 14, 2020 at 7:38 PM Jason Gunthorpe wrote:
> >
> > On Mon, Sep 14, 2020 at 07:20:34AM +0530, Souptick Joarder wrote:
> > > On Sun, Sep 13, 2020 at 8:25 PM Matthew Wilcox
> > > wrote:
> > > >
> > > > On Sun, Sep 13, 2
will return false. As a result, the dentry will be
> killed and the inode will be evicted. In this way, if we change per-file
> DAX policy, it will take effects automatically after this file is closed
> by all processes.
>
> I also add some comments to make the code more clea
lem.
>
> Fixes: e8de370188d09 ("rapidio: add mport char device driver")
> Signed-off-by: Souptick Joarder
> Cc: Ira Weiny
Reviewed-by: Ira Weiny
> Cc: John Hubbard
> Cc: Matthew Wilcox
> ---
> drivers/rapidio/devices/rio_mport_cdev.c | 13 +++--
> 1 fil
On Wed, Sep 16, 2020 at 01:02:32PM +0300, Dan Carpenter wrote:
> On Wed, Sep 16, 2020 at 09:12:17AM +0530, Souptick Joarder wrote:
> > There is an error when pin_user_pages_fast() returns -ERRNO and
> > inside error handling path driver end up calling unpin_user_pages()
> > with -ERRNO which is not
On Thu, Sep 17, 2020 at 03:39:51PM +0300, Dan Carpenter wrote:
> On Wed, Sep 16, 2020 at 01:02:32PM +0300, Dan Carpenter wrote:
> > On Wed, Sep 16, 2020 at 09:12:17AM +0530, Souptick Joarder wrote:
> > > There is an error when pin_user_pages_fast() returns -ERRNO and
> > > inside error handling pat
On Thu, Sep 17, 2020 at 07:09:00PM -0300, Jason Gunthorpe wrote:
> On Thu, Sep 17, 2020 at 05:40:59PM -0400, Peter Xu wrote:
> > On Thu, Sep 17, 2020 at 01:35:56PM -0700, Linus Torvalds wrote:
> > > For that to happen, we'd need to have the vma flag so that we wouldn't
> > > have any worry about no
On Mon, Sep 21, 2020 at 12:19:07PM -0400, Mikulas Patocka wrote:
>
>
> On Tue, 15 Sep 2020, Dan Williams wrote:
>
> > > TODO:
> > >
> > > - programs run approximately 4% slower when running from Optane-based
> > > persistent memory. Therefore, programs and libraries should use page cache
> > > a
From: Ira Weiny
release_pages() is an optimized version of a loop around put_page().
Unfortunately for devmap pages the logic is not entirely correct in
release_pages(). This is because device pages can be more than type
MEMORY_DEVICE_PUBLIC. There are in fact 4 types, private, public, FS
DAX
On Tue, Jun 04, 2019 at 12:08:08AM -0700, Christoph Hellwig wrote:
> On Mon, Jun 03, 2019 at 04:56:10PM -0700, Ira Weiny wrote:
> > On Mon, Jun 03, 2019 at 09:42:06AM -0700, Christoph Hellwig wrote:
> > > > +#if defined(CONFIG_CMA)
> > >
> > > You can just
On Tue, Jun 04, 2019 at 01:17:42PM -0700, John Hubbard wrote:
> On 6/4/19 1:11 PM, Dan Williams wrote:
> > On Tue, Jun 4, 2019 at 12:48 PM John Hubbard wrote:
> >>
> >> On 6/4/19 9:48 AM, ira.we...@intel.com wrote:
> >>> From: Ira Weiny
> >>
From: Ira Weiny
release_pages() is an optimized version of a loop around put_page().
Unfortunately for devmap pages the logic is not entirely correct in
release_pages(). This is because device pages can be more than type
MEMORY_DEVICE_PUBLIC. There are in fact 4 types, private, public, FS
DAX
From: Ira Weiny
In order to support checking for a layout lease on a FS DAX inode these
calls need to know if FOLL_LONGTERM was specified.
Prepare for this with this patch.
Signed-off-by: Ira Weiny
---
mm/gup.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions
From: Ira Weiny
Signed-off-by: Ira Weiny
---
fs/locks.c | 20 ++-
include/trace/events/filelock.h | 35 +
2 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index ec1e4a5df629
From: Ira Weiny
On FS DAX files users must inform the file system they intend to take
long term GUP pins on the file pages. Failure to do so should result in
an error.
Ensure that a F_LAYOUT lease exists at the time the GUP call is made.
If not return EPERM.
Signed-off-by: Ira Weiny
---
fs
From: Ira Weiny
Now that there is a mechanism for users to safely take LONGTERM pins on
FS DAX pages, remove the FS DAX exclusion from GUP with FOLL_LONGTERM.
Special processing remains in effect for CONFIG_CMA
Signed-off-by: Ira Weiny
---
mm/gup.c | 78
From: Ira Weiny
dax_layout_busy_page() can now operate on a sub-range of the
address_space provided.
Have xfs specify the sub range to dax_layout_busy_page()
Signed-off-by: Ira Weiny
---
fs/xfs/xfs_file.c | 19 +--
fs/xfs/xfs_inode.h | 5 +++--
fs/xfs/xfs_ioctl.c | 15
From: Ira Weiny
If pages are actively gup pinned fail the truncate operation. To
support an application who wishes to removing a pin upon SIGIO reception
we must change the order of breaking layout leases with respect to DAX
layout leases.
Check for a GUP pin on the page being truncated and
From: Ira Weiny
ext4 needs to break a layout lease if it is held to inform a user
holding a layout lease that a truncate is about to happen. This allows
the user knowledge of, and choice in how to handle, some other thread
attempting to modify a file they are actively using.
Split out the
From: Ira Weiny
GUP longterm pins of non-pagecache file system pages (eg FS DAX) are
currently disallowed because they are unsafe.
The danger for pinning these pages comes from the fact that hole punch
and/or truncate of those files results in the pages being mapped and
pinned by a user space
From: Ira Weiny
If pages are actively gup pinned fail the truncate operation.
Signed-off-by: Ira Weiny
---
fs/ext4/inode.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 75f543f384e4..1ded83ec08c0 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4
From: Ira Weiny
... V1,000,000 ;-)
Pre-requisites:
John Hubbard's put_user_pages() patch series.[1]
Jan Kara's ext4_break_layouts() fixes[2]
Based on the feedback from LSFmm and the LWN article which resulted. I've
decided to take a slightly different tack
From: Ira Weiny
Callers of dax_layout_busy_page() are only rarely operating on the
entire file of concern.
Teach dax_layout_busy_page() to operate on a sub-range of the
address_space provided. Specifying 0 - ULONG_MAX however, will continue
to operate on the "entire file" and XFS is
On Wed, Jun 12, 2019 at 09:54:58PM +0800, Pingfan Liu wrote:
> On Tue, Jun 11, 2019 at 04:29:11PM +, Weiny, Ira wrote:
> > > Pingfan Liu writes:
> > >
> > > > As for FOLL_LONGTERM, it is checked in the slow path
> > > > __gup_longterm_unlocked(). But it is not checked in the fast path,
> > >
On Wed, Jun 12, 2019 at 05:37:53AM -0700, Matthew Wilcox wrote:
> On Sat, Jun 08, 2019 at 10:10:36AM +1000, Dave Chinner wrote:
> > On Fri, Jun 07, 2019 at 11:25:35AM -0700, Ira Weiny wrote:
> > > Are you suggesting that we have something like this from user space?
>
On Wed, Jun 12, 2019 at 03:54:19PM -0700, Dan Williams wrote:
> On Wed, Jun 12, 2019 at 3:12 PM Ira Weiny wrote:
> >
> > On Wed, Jun 12, 2019 at 04:14:21PM -0300, Jason Gunthorpe wrote:
> > > On Wed, Jun 12, 2019 at 02:09:07PM +0200, Jan Kara wrote:
> > >
On Wed, Jun 12, 2019 at 04:14:21PM -0300, Jason Gunthorpe wrote:
> On Wed, Jun 12, 2019 at 02:09:07PM +0200, Jan Kara wrote:
> > On Wed 12-06-19 08:47:21, Jason Gunthorpe wrote:
> > > On Wed, Jun 12, 2019 at 12:29:17PM +0200, Jan Kara wrote:
> > >
> > > > > > The main objection to the current ODP
801 - 900 of 969 matches
Mail list logo
