On Thu, Apr 30, 2020 at 06:21:45PM -0700, Dan Williams wrote:
> On Thu, 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
On Mon, May 4, 2020 at 1:26 PM Andy Lutomirski wrote:
>
> 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.)
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
> 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 suspect that we will only ever find a handful of situations where th
On Sun, May 3, 2020 at 5:57 AM David Laight wrote:
>
> From: Linus Torvalds
> > Sent: 01 May 2020 19:29
> ...
> > And as DavidL pointed out - if you ever have "iomem" as a source or
> > destination, you need yet another case. Not because they can take
> > another kind of fault (although on some pl
From: Linus Torvalds
> Sent: 01 May 2020 19:29
...
> And as DavidL pointed out - if you ever have "iomem" as a source or
> destination, you need yet another case. Not because they can take
> another kind of fault (although on some platforms you have the machine
> checks for that too), but because t
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 5/1/20 11:28 AM, Linus Torvalds wrote:
> Plus on x86 you can't reasonably even have different code sequences
> for that case, because CLAC/STAC don't have a "enable users read
> accesses" vs "write accesses" case. It's an all-or-nothing "enable
> user faults".
>
> We _used_ to have a difference
On Thu, Apr 30, 2020 at 6:21 PM Dan Williams wrote:
>
> However now I see that copy_user_generic() works for the wrong reason.
> It works because the exception on the source address due to poison
> looks no different than a write fault on the user address to the
> caller, it's still just a short c
> 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_to_user()
> callers
> that are also directly accessing the sour
From: Andy Lutomirski
> Sent: 30 April 2020 19:42
...
> I suppose there could be a consistent naming like this:
>
> copy_from_user()
> copy_to_user()
>
> copy_from_unchecked_kernel_address() [what probe_kernel_read() is]
> copy_to_unchecked_kernel_address() [what probe_kernel_write() is]
>
> cop
On Thu, 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 safety che
> 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 w
> 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 that "user" can always
>>> take a fault, so it's the
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 that "user" can always
> > take a fault, so it's the _source_ that can fault, not the "user"
> > part.
>
> I don’t like
On Thu, Apr 30, 2020 at 5:10 PM Linus Torvalds
wrote:
>
> It's a horrible word, btw. The word doesn't actually mean what Andy
> means it to mean. "fallible" means "can make mistakes", not "can
> fault".
Btw, on naming: the name should be about _why_ it can fault, not about
whether it faults.
Whi
> 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 safe
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 safety checks. copy_to_user() and
> copy_to_user_fallible() mean *something*
On Thu, Apr 30, 2020 at 12:56 PM Linus Torvalds
wrote:
>
> On Thu, Apr 30, 2020 at 12:23 PM Luck, Tony wrote:
> >
> > How about
> >
> > try_copy_catch(void *dst, void *src, size_t count, int *fault)
> >
> > returns number of bytes not-copied (like copy_to_user etc).
> >
> > if return is n
On Thu, Apr 30, 2020 at 12:50:40PM -0700, Linus Torvalds wrote:
I see your point about the namimg being important. I think Dan's
case is indeed "copy from pmem to user" where only options for faulting
are #MC on the source addresses, and #PF on the destination.
> The only *fundamental* access wo
> 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:
>>>
>>> copy_from_user()
>>> copy_to_user()
>>>
>>>
On Thu, Apr 30, 2020 at 12:23 PM Luck, Tony wrote:
>
> How about
>
> try_copy_catch(void *dst, void *src, size_t count, int *fault)
>
> returns number of bytes not-copied (like copy_to_user etc).
>
> if return is not zero, "fault" tells you what type of fault
> cause the early stop (#PF, #
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:
> >
> > copy_from_user()
> > copy_to_user()
> >
> > copy_from_unchecked_kernel_address() [what probe_kernel_read() is]
On Thu, Apr 30, 2020 at 11:42:20AM -0700, Andy Lutomirski wrote:
> I suppose there could be a consistent naming like this:
>
> copy_from_user()
> copy_to_user()
>
> copy_from_unchecked_kernel_address() [what probe_kernel_read() is]
> copy_to_unchecked_kernel_address() [what probe_kernel_write() i
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
> > from memory that might be entir
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
> from memory that might be entirely bogus, that's a different
> operation. In other words, if I'm w
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
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 default implementation that is independent of
> detecting the presence of
28 matches
Mail list logo
