Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1343712

Re: [PATCH v13] x86, mce: Add memcpy_trap()

From Andy Lutomirski <luto@amacapital.net>
Newsgroups linux.kernel
Subject Re: [PATCH v13] x86, mce: Add memcpy_trap()
Date 2016-02-26 02:30 +0100
Message-ID <r6fod-447-1@gated-at.bofh.it> (permalink)
References <r5ZWa-1ea-25@gated-at.bofh.it> <r69Vv-9g-5@gated-at.bofh.it> <r6aRz-Ng-7@gated-at.bofh.it> <r6cqm-1Y1-13@gated-at.bofh.it> <r6eVc-3Cr-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Feb 25, 2016 at 4:58 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Feb 25, 2016 at 2:11 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>>
>> do_machine_check uses IST, the memory failure code can sleep, and you
>> can't sleep in IST context.  There's a special escape that lets
>> memory_failure sleep *if* it came from user mode.
>
> So?
>

[...]

Then let's answer the API question instead of the implementation question.

If a user program accesses a bad virtual address directly, it gets
SIGSEGV or SIGBUS depending on the nature of the error.  This is
long-established practice.  The SIGSEGV case is programmer error and
the SIGBUS case might be an IO error.

If a user program accesses a bad virtual address by passing the
address to a syscall, it gets EFAULT.  This may be programmer error or
and underlying IO error, and the program can't tell.

If a user program accesses a bad address on an NVDIMM via mmap, what
should happen?  If mmaped NVDIMM (or other DAX space) is the same as
existing poisoned memory, the program gets SIGBUS.  This still makes
sense.

The question here: what happens if a program accesses a bad NVDIMM
address by passing a pointer to a syscall?  With Tony's patches as
written, I think the program gets SIGBUS via memory_failure.  Do we
want that behavior?  If we take your suggestion and change only the
error code, then the program will *not* get SIGBUS.  Instead it will
get -EFAULT or -ESOMETHINGELSE.  Is that okay?  If it is, then
everything is straightforward and nothing in my previous email is
relevant.

--Andy

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v13] x86, mce: Add memcpy_trap() Tony Luck <tony.luck@gmail.com> - 2016-02-24 18:40 +0100
  Re: [PATCH v13] x86, mce: Add memcpy_trap() Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-24 19:40 +0100
    Re: [PATCH v13] x86, mce: Add memcpy_trap() Tony Luck <tony.luck@gmail.com> - 2016-02-24 20:30 +0100
      Re: [PATCH v13] x86, mce: Add memcpy_trap() Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-24 20:40 +0100
        Re: [PATCH v13] x86, mce: Add memcpy_trap() Ingo Molnar <mingo@kernel.org> - 2016-02-25 10:00 +0100
          Re: [PATCH v13] x86, mce: Add memcpy_trap() "Luck, Tony" <tony.luck@intel.com> - 2016-02-25 20:40 +0100
            Re: [PATCH v13] x86, mce: Add memcpy_trap() Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-25 21:40 +0100
              Re: [PATCH v13] x86, mce: Add memcpy_trap() Andy Lutomirski <luto@amacapital.net> - 2016-02-25 23:20 +0100
                [PATCH v14] x86, mce: Add memcpy_mcsafe() Tony Luck <tony.luck@intel.com> - 2016-02-25 23:50 +0100
                Re: [PATCH v14] x86, mce: Add memcpy_mcsafe() "Luck, Tony" <tony.luck@intel.com> - 2016-03-02 21:50 +0100
                Re: [PATCH v13] x86, mce: Add memcpy_trap() Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-26 02:00 +0100
                Re: [PATCH v13] x86, mce: Add memcpy_trap() Andy Lutomirski <luto@amacapital.net> - 2016-02-26 02:30 +0100
                Re: [PATCH v13] x86, mce: Add memcpy_trap() Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-26 03:40 +0100

csiph-web