> 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 this f
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;
> >
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
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 protectio
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 added
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 cach
> 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, ira.
> 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
> 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 (
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 pre
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 suspe
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 copy_
> 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 wi
> 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 t
> 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 safet
> 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:
>>&
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
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 defaul
--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 CONFIG_X86
> 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.
Agreed. I think it’s plausibl
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' implementation.
> Ugh, ok.
> I guess the good news is that your patc
On Tue, May 1, 2018 at 4:02 PM Dan Williams
wrote:
> On Tue, May 1, 2018 at 2:05 PM, Linus Torvalds
> wrote:
> > On Tue, May 1, 2018 at 1:55 PM Dan Williams
> > wrote:
> >
> >> The result of the bypass is that the kernel treats machine checks
during
> >> read as system fatal (reboot) when they
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
> without the feature. Use
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 being able to
> support applications that MA
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 implementation:
>> >
>> > 1) Is it worth the hassle?
>> >
On Thu, Jun 22, 2017 at 5:52 PM, Dave Chinner 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 wrote:
>> >
>> > You seem to be calling the "fdatasync on every page fault" the
>&g
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" option. That's the brute-
Hence
> they want to use userspace 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
On Tue, Jun 20, 2017 at 9:17 AM, Dan Williams wrote:
> On Tue, Jun 20, 2017 at 1:49 AM, Christoph Hellwig wrote:
>> [stripped giant fullquotes]
>>
>> On Mon, Jun 19, 2017 at 10:53:12PM -0700, Andy Lutomirski wrote:
>>> But that's my whole point. The kernel doe
On Tue, Jun 20, 2017 at 3:11 AM, Dave Chinner 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 wrote:
>> > On Mon, Jun 19, 2017 at 08:22:10AM -0700, Andy Lutomirski wrote:
>> >> Second: syncin
On Mon, Jun 19, 2017 at 5:46 PM, Dave Chinner 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 wrote:
>> > On Sat, Jun 17, 2017 at 10:05:45PM -0700, Andy Lutomirski wrote:
>> >> On Sat
On Mon, Jun 19, 2017 at 6:21 AM, Dave Chinner 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
>> wrote:
>> > On Sat, Jun 17, 2017 at 4:50 PM, Andy Lutomirski wrote:
>> >> My
On Sat, Jun 17, 2017 at 8:15 PM, Dan Williams wrote:
> On Sat, Jun 17, 2017 at 4:50 PM, Andy Lutomirski wrote:
>> My other objection is that the syscall intentionally leaks a reference
>> to the file. This means it needs overflow protection and it probably
>> shouldn't
On Sat, Jun 17, 2017 at 2:52 PM, Dan Williams wrote:
> On Sat, Jun 17, 2017 at 9:25 AM, Andy Lutomirski wrote:
>>
>> Can you remind those of us who haven't played with DAX in a while what
>> the problem is with mmapping a DAX file without this patchset? If
>> the
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)
> data from persistent sto
35 matches
Mail list logo