Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v2 0/2] Replace and improve "mcsafe" with copy_safe()
Date:   Thu, 30 Apr 2020 13:07:09 -0700
Message-Id: <4819995F-4EAE-46EE-8311-9CF65CB8D08A@amacapital.net>
References: <CAPcyv4g8rA2TRvoFHqEjs5Xn74gdZx8uF0PXFYCjTcx56yA=Jw@mail.gmail.com>
Cc:     "Luck, Tony" <tony.luck@intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Borislav Petkov <bp@alien8.de>,
        stable <stable@vger.kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Paul Mackerras <paulus@samba.org>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Erwin Tsaur <erwin.tsaur@intel.com>,
        Michael Ellerman <mpe@ellerman.id.au>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        linux-nvdimm <linux-nvdimm@lists.01.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
In-Reply-To: <CAPcyv4g8rA2TRvoFHqEjs5Xn74gdZx8uF0PXFYCjTcx56yA=Jw@mail.gmail.com>
To:     Dan Williams <dan.j.williams@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Apr 30, 2020, at 12:51 PM, Dan Williams <dan.j.williams@intel.com> wrot=
e:
>=20
> =EF=BB=BFOn Thu, Apr 30, 2020 at 12:23 PM Luck, Tony <tony.luck@intel.com>=
 wrote:
>>=20
>>> On Thu, Apr 30, 2020 at 11:42:20AM -0700, Andy Lutomirski wrote:
>>> I suppose there could be a consistent naming like this:
>>>=20
>>> copy_from_user()
>>> copy_to_user()
>>>=20
>>> copy_from_unchecked_kernel_address() [what probe_kernel_read() is]
>>> copy_to_unchecked_kernel_address() [what probe_kernel_write() is]
>>>=20
>>> copy_from_fallible() [from a kernel address that can fail to a kernel
>>> address that can't fail]
>>> copy_to_fallible() [the opposite, but hopefully identical to memcpy() on=
 x86]
>>>=20
>>> copy_from_fallible_to_user()
>>> copy_from_user_to_fallible()
>>>=20
>>> These names are fairly verbose and could probably be improved.
>>=20
>> How about
>>=20
>>        try_copy_catch(void *dst, void *src, size_t count, int *fault)
>>=20
>> returns number of bytes not-copied (like copy_to_user etc).
>>=20
>> if return is not zero, "fault" tells you what type of fault
>> cause the early stop (#PF, #MC).
>=20
> I do like try_copy_catch() for the case when neither of the buffers
> are __user (like in the pmem driver) and _copy_to_iter_fallible()
> (plus all the helpers it implies) for the other cases.
>=20
> copy_to_user_fallible
> copy_fallible_to_page
> copy_pipe_to_iter_fallible
>=20
> ...because the mmu-fault handling is an aspect of "_user" and fallible
> implies other source fault reasons. It does leave a gap if an
> architecture has a concept of a fallible write, but that seems like
> something that will be handled asynchronously and not subject to this
> interface.


I=E2=80=99m suspicious that, as a practical matter, x86 does have a fallible=
 write. In particular, if a page fails and the memory failure code is notifi=
ed, the page will be unmapped. At that point, an attempt to write to the fai=
led fallible page will get #PF, and code that writes to it needs to be prepa=
red to handle #PF.  Perhaps copy_to_fallible(), etc can still return void, b=
ut I=E2=80=99m unconvinced
the implementation can be the same as memcpy.=