Re: [PATCH V3.1] entry: Pass irqentry_state_t by reference

> On Dec 17, 2020, at 5:19 AM, Peter Zijlstra wrote: > > On Thu, Dec 17, 2020 at 02:07:01PM +0100, Thomas Gleixner wrote: >>> On Fri, Dec 11 2020 at 14:14, Andy Lutomirski wrote: >>>> On Mon, Nov 23, 2020 at 10:10 PM wrote: >>> After contemplating th

Re: [PATCH V3.1] entry: Pass irqentry_state_t by reference

On Tue, Dec 15, 2020 at 5:32 PM Ira Weiny wrote: > > On Fri, Dec 11, 2020 at 02:14:28PM -0800, Andy Lutomirski wrote: > > On Mon, Nov 23, 2020 at 10:10 PM wrote: > > IOW we have: > > > > struct extended_pt_regs { > > bool rcu_whatever; > >

Re: [PATCH V3.1] entry: Pass irqentry_state_t by reference

On Mon, Nov 23, 2020 at 10:10 PM wrote: > > 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

Re: [PATCH v10 0/9] mm: introduce memfd_secret system call to create "secret" memory areas

On Mon, Nov 23, 2020 at 1:54 AM Mike Rapoport wrote: > > From: Mike Rapoport > > Hi, > > This is an implementation of "secret" mappings backed by a file descriptor. > > The file descriptor backing secret memory mappings is created using a > dedicated memfd_secret system call The desired

Re: [PATCH v5 0/5] mm: introduce memfd_secret system call to create "secret" memory areas

On Wed, Sep 16, 2020 at 12:28 AM Mike Rapoport wrote: > > From: Mike Rapoport > > Hi, > > This is an implementation of "secret" mappings backed by a file descriptor. > I've dropped the boot time reservation patch for now as it is not strictly > required for the basic usage and can be easily

Re: [PATCH RFC V2 17/17] x86/entry: Preserve PKRS MSR across exceptions

On Fri, Jul 24, 2020 at 2:25 PM 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 could still > >> work. If the per-cpu

Re: [PATCH RFC V2 17/17] x86/entry: Preserve PKRS MSR across exceptions

> 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 writes: On Fri, Jul 17, 2020 at 12:06:10PM +0200, Peter Zijlstra wrote: >> On Fri, Jul 17, 2020 at 12:20:56AM -0700,

Re: [PATCH RFC V2 17/17] x86/entry: Preserve PKRS MSR across exceptions

> 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

Re: [PATCH RFC V2 17/17] x86/entry: Preserve PKRS MSR across exceptions

> 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

Re: [PATCH RFC V2 17/17] x86/entry: Preserve PKRS MSR across exceptions

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 accesses which the interrupted process has allowed. > > Close this hole by

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

On Mon, May 4, 2020 at 1:05 PM Luck, Tony wrote: > > > When a copy function hits a bad page and the page is not yet known to > > be bad, what does it do? (I.e. the page was believed to be fine but > > the copy function gets #MC.) Does it unmap it right away? What does > > it return? > > I

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

On Fri, May 1, 2020 at 7:09 AM Luck, Tony wrote: > > > Now maybe copy_to_user() should *always* work this way, but I’m not > > convinced. > > Certainly put_user() shouldn’t — the result wouldn’t even be well defined. > > And I’m > > unconvinced that it makes much sense for the majority of

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

> On Apr 30, 2020, at 5:25 PM, Linus Torvalds > wrote: > > > It wasn't clear how "copy_to_mc()" could ever fault. Poisoning > after-the-fact? Why would that be preferable to just mapping a dummy > page? If the kernel gets an async memory error and maps a dummy page, then subsequent reads

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

> On Apr 30, 2020, at 5:40 PM, Linus Torvalds > wrote: > > On Thu, Apr 30, 2020 at 5:23 PM Andy Lutomirski wrote: >> >>> But anyway, I don't hate something like "copy_to_user_fallible()" >>> conceptually. The naming needs to be fixed, in th

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

> On Apr 30, 2020, at 5:10 PM, Linus Torvalds > wrote: > > On Thu, Apr 30, 2020 at 4:52 PM Dan Williams > wrote: >> >> You had me until here. Up to this point I was grokking that Andy's >> "_fallible" suggestion does help explain better than "_safe", because >> the copy is doing extra

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

> On Apr 30, 2020, at 12:51 PM, Dan Williams wrote: > > On Thu, Apr 30, 2020 at 12:23 PM Luck, Tony wrote: >> >>> On Thu, Apr 30, 2020 at 11:42:20AM -0700, Andy Lutomirski wrote: >>> I suppose there could be a consistent naming like this: >>&

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

On Thu, Apr 30, 2020 at 10:17 AM Linus Torvalds wrote: > > On Thu, Apr 30, 2020 at 9:52 AM Andy Lutomirski wrote: > > > > If I'm going to copy from memory that might be bad but is at least a > > valid pointer, I want a function to do this. If I'm going to copy &g

Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()

On Thu, Apr 30, 2020 at 7:03 AM Linus Torvalds wrote: > > On Thu, Apr 30, 2020 at 1:41 AM Dan Williams wrote: > > > > With the above realizations the name "mcsafe" is no longer accurate and > > copy_safe() is proposed as its replacement. x86 grows a copy_safe_fast() > > implementation as a

Re: [PATCH] x86/memcpy: Introduce memcpy_mcsafe_fast

--Andy > On Apr 18, 2020, at 12:42 PM, Linus Torvalds > wrote: > >>> On Fri, Apr 17, 2020 at 5:12 PM Dan Williams >>> wrote: >>> >>> @@ -106,12 +108,10 @@ static __always_inline __must_check unsigned long >>> memcpy_mcsafe(void *dst, const void *src, size_t cnt) >>> { >>> #ifdef

Re: use memcpy_mcsafe() for copy_to_iter() (was: Re: [PATCH v3 0/9] Series short description)

> On May 14, 2018, at 8:52 AM, Dan Williams wrote: > > > I think "happy" is a strong word when it comes to x86 machine check > handling. My interpretation is that he and Andy acquiesced that this > is about the best we can do with dax+mce as things stand today.

Re: [PATCH 0/6] use memcpy_mcsafe() for copy_to_iter()

On Tue, May 1, 2018 at 8:34 PM Linus Torvalds wrote: > On Tue, May 1, 2018 at 8:22 PM Dan Williams > wrote: > > All that to say that having a typical RAM page covering poisoned pmem > > would complicate the 'clear badblocks'

Re: [PATCH v4 2/3] mm: introduce MAP_VALIDATE a mechanism for adding new mmap flags

On Mon, Aug 14, 2017 at 11:12 PM, Dan Williams wrote: > The mmap syscall suffers from the ABI anti-pattern of not validating > unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a > mechanism to define new behavior that is known to fail on older kernels

Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

On Fri, Aug 11, 2017 at 3:26 PM, Dan Williams wrote: > On Fri, Aug 11, 2017 at 3:44 AM, Christoph Hellwig wrote: >> Please explain how this interface allows for any sort of safe userspace >> DMA. > > So this is where I continue to see S_IOMAP_IMMUTABLE

Re: [RFC PATCH 0/7] dax, ext4: Synchronous page faults

On Thu, Jul 27, 2017 at 2:57 PM, Ross Zwisler wrote: > On Thu, Jul 27, 2017 at 10:09:07AM -0400, Jeff Moyer wrote: >> Jan Kara writes: >> >> Hi, Jan, >> >> Thanks for looking into this! >> >> > There are couple of open questions with this

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Thu, Jun 22, 2017 at 5:52 PM, Dave Chinner <da...@fromorbit.com> wrote: > On Wed, Jun 21, 2017 at 09:07:57PM -0700, Andy Lutomirski wrote: >> On Wed, Jun 21, 2017 at 5:02 PM, Dave Chinner <da...@fromorbit.com> wrote: >> > >> > You seem to be cal

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Wed, Jun 21, 2017 at 5:02 PM, Dave Chinner wrote: > > You seem to be calling the "fdatasync on every page fault" the It's the opposite of fdatasync(). It needs to sync whatever metadata is needed to find the data. The data doesn't need to be synced. > "lightweight"

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

erspace data sync primitives to avoid this > overhead and so filesystems need to make it possible to provide this > userspace idata sync capability. If I were using DAX in production, I'd have exactly this issue. Let me quote myself: On Tue, Jun 20, 2017 at 9:14 AM, Andy Lutomirski <l...@

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Tue, Jun 20, 2017 at 9:17 AM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Tue, Jun 20, 2017 at 1:49 AM, Christoph Hellwig <h...@lst.de> wrote: >> [stripped giant fullquotes] >> >> On Mon, Jun 19, 2017 at 10:53:12PM -0700, Andy Lutomirski wrote: >>&

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Tue, Jun 20, 2017 at 3:11 AM, Dave Chinner <da...@fromorbit.com> wrote: > On Mon, Jun 19, 2017 at 10:53:12PM -0700, Andy Lutomirski wrote: >> On Mon, Jun 19, 2017 at 5:46 PM, Dave Chinner <da...@fromorbit.com> wrote: >> > On Mon, Jun 19, 2017 at 08:22:10A

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Mon, Jun 19, 2017 at 5:46 PM, Dave Chinner <da...@fromorbit.com> wrote: > On Mon, Jun 19, 2017 at 08:22:10AM -0700, Andy Lutomirski wrote: >> On Mon, Jun 19, 2017 at 6:21 AM, Dave Chinner <da...@fromorbit.com> wrote: >> > On Sat, Jun 17, 2017 at 10:05:45P

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Mon, Jun 19, 2017 at 6:21 AM, Dave Chinner <da...@fromorbit.com> wrote: > On Sat, Jun 17, 2017 at 10:05:45PM -0700, Andy Lutomirski wrote: >> On Sat, Jun 17, 2017 at 8:15 PM, Dan Williams <dan.j.willi...@intel.com> >> wrote: >> > On Sat, Jun 17,

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Sat, Jun 17, 2017 at 8:15 PM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Sat, Jun 17, 2017 at 4:50 PM, Andy Lutomirski <l...@kernel.org> wrote: >> My other objection is that the syscall intentionally leaks a reference >> to the file. This means i

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Sat, Jun 17, 2017 at 2:52 PM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Sat, Jun 17, 2017 at 9:25 AM, Andy Lutomirski <l...@kernel.org> wrote: >> >> Can you remind those of us who haven't played with DAX in a while what >> the problem is with mmapping

Re: [RFC PATCH 2/2] mm, fs: daxfile, an interface for byte-addressable updates to pmem

On Fri, Jun 16, 2017 at 6:15 PM, Dan Williams wrote: > To date, the full promise of byte-addressable access to persistent > memory has only been half realized via the filesystem-dax interface. The > current filesystem-dax mechanism allows an application to consume (read)