From: Graham Cobb <g.btrfs@cobb.uk.net>
To: linux-btrfs@vger.kernel.org
Cc: "Sebastian Döring" <moralapostel@gmail.com>
Subject: Scrub resume regression
Date: Wed, 15 Jan 2020 09:03:13 +0000 [thread overview]
Message-ID: <d0a97688-78be-08de-ca7d-bcb4c7fb397e@cobb.uk.net> (raw)
OK, I have bisected the problem with scrub resume being broken by the
scrub ioctl ABI being changed.
The bad commit is:
Fail
06fe39ab15a6a47d4979460fcc17d33b1d72ccf9 is the first bad commit
commit 06fe39ab15a6a47d4979460fcc17d33b1d72ccf9
Author: Filipe Manana <fdmanana@suse.com>
Date: Fri Dec 14 19:50:17 2018 +0000
Btrfs: do not overwrite scrub error with fault error in scrub ioctl
If scrub returned an error and then the copy_to_user() call did not
succeed, we would overwrite the error returned by scrub with -EFAULT.
Fix that by calling copy_to_user() only if btrfs_scrub_dev() returned
success.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
bisect run success
It is important that scrub always returns the stats, even when it
returns an error. This is critical for cancel, as that is how
cancel/resume works, but it should also apply in case of other errors so
that the user can see how much of the scrub was done before the fatal error.
I am not sure in which kernel release this commit appeared but as this
breaks the "scrub resume" command completely, I think the fix for this
needs to be backported and may want to be considered by distro kernel
maintainers.
I will reply later with the simple reproducer program I created for the
bisection in case it is useful for testing.
next reply other threads:[~2020-01-15 9:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-15 9:03 Graham Cobb [this message]
2020-01-15 9:33 ` Scrub resume regression Filipe Manana
2020-01-15 11:55 ` Graham Cobb
2020-01-15 12:51 ` David Sterba
2020-01-15 13:10 ` Holger Hoffstätte
2020-01-15 21:02 ` Sebastian Döring
2020-01-16 14:02 ` David Sterba
2020-01-17 15:59 ` Zygo Blaxell
2020-01-17 18:39 ` Chris Murphy
2020-01-17 19:39 ` Graham Cobb
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=d0a97688-78be-08de-ca7d-bcb4c7fb397e@cobb.uk.net \
--to=g.btrfs@cobb.uk.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=moralapostel@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).