From: Catalin Marinas <catalin.marinas@arm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>,
Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
Andreas Gruenbacher <agruenba@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Will Deacon <will@kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 3/3] btrfs: Avoid live-lock in search_ioctl() on hardware with sub-page faults
Date: Thu, 25 Nov 2021 11:10:43 +0000 [thread overview]
Message-ID: <YZ9vM91Uj8g36VQC@arm.com> (raw)
In-Reply-To: <CAHk-=wgHqjX3kenSk5_bCRM+ZC-tgndBMfbVVsbp0CwJf2DU-w@mail.gmail.com>
On Wed, Nov 24, 2021 at 03:00:00PM -0800, Linus Torvalds wrote:
> On Wed, Nov 24, 2021 at 12:04 PM Matthew Wilcox <willy@infradead.org> wrote:
> > (where __copy_to_user_nofault() is a new function that does exactly what
> > copy_to_user_nofault() does, but returns the number of bytes copied)
>
> If we want the "how many bytes" part, then we should just make
> copy_to_user_nofault() have the same semantics as a plain
> copy_to_user().
>
> IOW, change it to return "number of bytes not copied".
>
> Looking at the current uses, such a change would be trivial. The only
> case that wants a 0/-EFAULT error is the bpf_probe_write_user(),
> everybody else already just wants "zero for success", so changing
> copy_to_user_nofault() would be trivial.
I agree, if we want the number of byte not copied, we should just change
copy_{to,from}_user_nofault() and their callers (I can count three
each).
For this specific btrfs case, if we want go with tuning the offset based
on the fault address, we'd need copy_to_user_nofault() (or a new
function) to be exact. IOW, fall back to byte-at-a-time copy until it
hits the real faulting address.
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Wilcox <willy@infradead.org>,
Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
Andreas Gruenbacher <agruenba@redhat.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Will Deacon <will@kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH 3/3] btrfs: Avoid live-lock in search_ioctl() on hardware with sub-page faults
Date: Thu, 25 Nov 2021 11:10:43 +0000 [thread overview]
Message-ID: <YZ9vM91Uj8g36VQC@arm.com> (raw)
In-Reply-To: <CAHk-=wgHqjX3kenSk5_bCRM+ZC-tgndBMfbVVsbp0CwJf2DU-w@mail.gmail.com>
On Wed, Nov 24, 2021 at 03:00:00PM -0800, Linus Torvalds wrote:
> On Wed, Nov 24, 2021 at 12:04 PM Matthew Wilcox <willy@infradead.org> wrote:
> > (where __copy_to_user_nofault() is a new function that does exactly what
> > copy_to_user_nofault() does, but returns the number of bytes copied)
>
> If we want the "how many bytes" part, then we should just make
> copy_to_user_nofault() have the same semantics as a plain
> copy_to_user().
>
> IOW, change it to return "number of bytes not copied".
>
> Looking at the current uses, such a change would be trivial. The only
> case that wants a 0/-EFAULT error is the bpf_probe_write_user(),
> everybody else already just wants "zero for success", so changing
> copy_to_user_nofault() would be trivial.
I agree, if we want the number of byte not copied, we should just change
copy_{to,from}_user_nofault() and their callers (I can count three
each).
For this specific btrfs case, if we want go with tuning the offset based
on the fault address, we'd need copy_to_user_nofault() (or a new
function) to be exact. IOW, fall back to byte-at-a-time copy until it
hits the real faulting address.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-11-25 11:12 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-24 19:20 [PATCH 0/3] Avoid live-lock in fault-in+uaccess loops with sub-page faults Catalin Marinas
2021-11-24 19:20 ` Catalin Marinas
2021-11-24 19:20 ` [PATCH 1/3] mm: Introduce fault_in_exact_writeable() to probe for " Catalin Marinas
2021-11-24 19:20 ` Catalin Marinas
2021-11-24 19:20 ` [PATCH 2/3] arm64: Add support for sub-page faults user probing Catalin Marinas
2021-11-24 19:20 ` Catalin Marinas
2021-11-24 19:20 ` [PATCH 3/3] btrfs: Avoid live-lock in search_ioctl() on hardware with sub-page faults Catalin Marinas
2021-11-24 19:20 ` Catalin Marinas
2021-11-24 20:03 ` Matthew Wilcox
2021-11-24 20:03 ` Matthew Wilcox
2021-11-24 20:37 ` Catalin Marinas
2021-11-24 20:37 ` Catalin Marinas
2021-11-25 22:25 ` Andreas Gruenbacher
2021-11-25 22:25 ` Andreas Gruenbacher
2021-11-25 22:42 ` Catalin Marinas
2021-11-25 22:42 ` Catalin Marinas
2021-11-26 22:29 ` Andreas Gruenbacher
2021-11-26 22:29 ` Andreas Gruenbacher
2021-11-26 22:57 ` Catalin Marinas
2021-11-26 22:57 ` Catalin Marinas
2021-11-27 3:52 ` Andreas Gruenbacher
2021-11-27 3:52 ` Andreas Gruenbacher
2021-11-27 12:39 ` Andreas Gruenbacher
2021-11-27 12:39 ` Andreas Gruenbacher
2021-11-27 15:21 ` Catalin Marinas
2021-11-27 15:21 ` Catalin Marinas
2021-11-27 18:05 ` Andreas Gruenbacher
2021-11-27 18:05 ` Andreas Gruenbacher
2021-11-29 12:16 ` Catalin Marinas
2021-11-29 12:16 ` Catalin Marinas
2021-11-29 13:33 ` Andreas Gruenbacher
2021-11-29 13:33 ` Andreas Gruenbacher
2021-11-29 15:36 ` Catalin Marinas
2021-11-29 15:36 ` Catalin Marinas
2021-11-29 18:40 ` Linus Torvalds
2021-11-29 18:40 ` Linus Torvalds
2021-11-29 19:31 ` Andreas Gruenbacher
2021-11-29 19:31 ` Andreas Gruenbacher
2021-11-29 20:56 ` Catalin Marinas
2021-11-29 20:56 ` Catalin Marinas
2021-11-29 21:53 ` Linus Torvalds
2021-11-29 21:53 ` Linus Torvalds
2021-11-29 23:12 ` Catalin Marinas
2021-11-29 23:12 ` Catalin Marinas
2021-11-29 13:52 ` Catalin Marinas
2021-11-29 13:52 ` Catalin Marinas
2021-11-27 14:33 ` Catalin Marinas
2021-11-27 14:33 ` Catalin Marinas
2021-11-24 23:00 ` Linus Torvalds
2021-11-24 23:00 ` Linus Torvalds
2021-11-25 11:10 ` Catalin Marinas [this message]
2021-11-25 11:10 ` Catalin Marinas
2021-11-25 18:13 ` Linus Torvalds
2021-11-25 18:13 ` Linus Torvalds
2021-11-25 20:43 ` Catalin Marinas
2021-11-25 20:43 ` Catalin Marinas
2021-11-25 21:02 ` Matthew Wilcox
2021-11-25 21:02 ` Matthew Wilcox
2021-11-25 21:29 ` Catalin Marinas
2021-11-25 21:29 ` Catalin Marinas
2021-11-25 21:40 ` Andreas Gruenbacher
2021-11-25 21:40 ` Andreas Gruenbacher
2021-11-26 16:42 ` David Sterba
2021-11-26 16:42 ` David Sterba
2021-11-24 21:36 ` [PATCH 0/3] Avoid live-lock in fault-in+uaccess loops " Andrew Morton
2021-11-24 21:36 ` Andrew Morton
2021-11-24 22:31 ` Catalin Marinas
2021-11-24 22:31 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YZ9vM91Uj8g36VQC@arm.com \
--to=catalin.marinas@arm.com \
--cc=agruenba@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=will@kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.