All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.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>,
	LKML <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: Fri, 26 Nov 2021 22:57:44 +0000	[thread overview]
Message-ID: <YaFmaJqyie6KZ2bY@arm.com> (raw)
In-Reply-To: <20211126222945.549971-1-agruenba@redhat.com>

On Fri, Nov 26, 2021 at 11:29:45PM +0100, Andreas Gruenbacher wrote:
> On Thu, Nov 25, 2021 at 11:42 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > As per Linus' reply, we can work around this by doing
> > a sub-page fault_in_writable(point_of_failure, align) where 'align'
> > should cover the copy_to_user() impreciseness.
> >
> > (of course, fault_in_writable() takes the full size argument but behind
> > the scene it probes the 'align' prefix at sub-page fault granularity)
> 
> That doesn't make sense; we don't want fault_in_writable() to fail or
> succeed depending on the alignment of the address range passed to it.

If we know that the arch copy_to_user() has an error of say maximum 16
bytes (or 15 rather on arm64), we can instead get fault_in_writeable()
to probe first 16 bytes rather than 1.

> Have a look at the below code to see what I mean.  Function
> copy_to_user_nofault_unaligned() should be further optimized, maybe as
> mm/maccess.c:copy_from_kernel_nofault() and/or per architecture
> depending on the actual alignment rules; I'm not sure.
[...]
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -2051,13 +2051,30 @@ static noinline int key_in_sk(struct btrfs_key *key,
>  	return 1;
>  }
>  
> +size_t copy_to_user_nofault_unaligned(void __user *to, void *from, size_t size)
> +{
> +	size_t rest = copy_to_user_nofault(to, from, size);
> +
> +	if (rest) {
> +		size_t n;
> +
> +		for (n = size - rest; n < size; n++) {
> +			if (copy_to_user_nofault(to + n, from + n, 1))
> +				break;
> +		}
> +		rest = size - n;
> +	}
> +	return rest;

That's what I was trying to avoid. That's basically a fall-back to byte
at a time copy (we do this in copy_mount_options(); at some point we
even had a copy_from_user_exact() IIRC).

Linus' idea (if I got it correctly) was instead to slightly extend the
probing in fault_in_writeable() for the beginning of the buffer from 1
byte to some per-arch range.

I attempted the above here and works ok:

https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=devel/btrfs-live-lock-fix

but too late to post it this evening, I'll do it in the next day or so
as an alternative to this series.

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Andreas Gruenbacher <agruenba@redhat.com>
Cc: Matthew Wilcox <willy@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.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>,
	LKML <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: Fri, 26 Nov 2021 22:57:44 +0000	[thread overview]
Message-ID: <YaFmaJqyie6KZ2bY@arm.com> (raw)
In-Reply-To: <20211126222945.549971-1-agruenba@redhat.com>

On Fri, Nov 26, 2021 at 11:29:45PM +0100, Andreas Gruenbacher wrote:
> On Thu, Nov 25, 2021 at 11:42 PM Catalin Marinas <catalin.marinas@arm.com> wrote:
> > As per Linus' reply, we can work around this by doing
> > a sub-page fault_in_writable(point_of_failure, align) where 'align'
> > should cover the copy_to_user() impreciseness.
> >
> > (of course, fault_in_writable() takes the full size argument but behind
> > the scene it probes the 'align' prefix at sub-page fault granularity)
> 
> That doesn't make sense; we don't want fault_in_writable() to fail or
> succeed depending on the alignment of the address range passed to it.

If we know that the arch copy_to_user() has an error of say maximum 16
bytes (or 15 rather on arm64), we can instead get fault_in_writeable()
to probe first 16 bytes rather than 1.

> Have a look at the below code to see what I mean.  Function
> copy_to_user_nofault_unaligned() should be further optimized, maybe as
> mm/maccess.c:copy_from_kernel_nofault() and/or per architecture
> depending on the actual alignment rules; I'm not sure.
[...]
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -2051,13 +2051,30 @@ static noinline int key_in_sk(struct btrfs_key *key,
>  	return 1;
>  }
>  
> +size_t copy_to_user_nofault_unaligned(void __user *to, void *from, size_t size)
> +{
> +	size_t rest = copy_to_user_nofault(to, from, size);
> +
> +	if (rest) {
> +		size_t n;
> +
> +		for (n = size - rest; n < size; n++) {
> +			if (copy_to_user_nofault(to + n, from + n, 1))
> +				break;
> +		}
> +		rest = size - n;
> +	}
> +	return rest;

That's what I was trying to avoid. That's basically a fall-back to byte
at a time copy (we do this in copy_mount_options(); at some point we
even had a copy_from_user_exact() IIRC).

Linus' idea (if I got it correctly) was instead to slightly extend the
probing in fault_in_writeable() for the beginning of the buffer from 1
byte to some per-arch range.

I attempted the above here and works ok:

https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=devel/btrfs-live-lock-fix

but too late to post it this evening, I'll do it in the next day or so
as an alternative to this series.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-11-26 22:59 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 [this message]
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
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=YaFmaJqyie6KZ2bY@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.