aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/export-to-sqlite-report
diff options
context:
space:
mode:
authorFilipe Manana <[email protected]>2020-01-16 11:29:20 +0000
committerDavid Sterba <[email protected]>2020-01-17 15:28:52 +0100
commit5afe6ce748c1ea99e0d648153c05075e1ab93afb (patch)
treebccebac0ec57be3d149f6304f2f3952f0bf3d17a /tools/perf/scripts/python/bin/export-to-sqlite-report
parent6282675e6708ec78518cc0e9ad1f1f73d7c5c53d (diff)
Btrfs: always copy scrub arguments back to user space
If scrub returns an error we are not copying back the scrub arguments structure to user space. This prevents user space to know how much progress scrub has done if an error happened - this includes -ECANCELED which is returned when users ask for scrub to stop. A particular use case, which is used in btrfs-progs, is to resume scrub after it is canceled, in that case it relies on checking the progress from the scrub arguments structure and then use that progress in a call to resume scrub. So fix this by always copying the scrub arguments structure to user space, overwriting the value returned to user space with -EFAULT only if copying the structure failed to let user space know that either that copying did not happen, and therefore the structure is stale, or it happened partially and the structure is probably not valid and corrupt due to the partial copy. Reported-by: Graham Cobb <[email protected]> Link: https://lore.kernel.org/linux-btrfs/[email protected]/ Fixes: 06fe39ab15a6a4 ("Btrfs: do not overwrite scrub error with fault error in scrub ioctl") CC: [email protected] # 5.1+ Reviewed-by: Johannes Thumshirn <[email protected]> Reviewed-by: Qu Wenruo <[email protected]> Tested-by: Graham Cobb <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/bin/export-to-sqlite-report')
0 files changed, 0 insertions, 0 deletions