4.14.51-stable review
Subsystems (15)
Greg Kroah-Hartman
maintainerPATCH 178/189 drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit 2b6207291b7b277a5df9d1aab44b56815a292dba ]
There is a comment here which says that DIV_ROUND_UP() and that's where the problem comes from. Say you pick:
args->bpp = UINT_MAX - 7; args->width = 4; args->height = 1;
The integer overflow in DIV_ROUND_UP() means "cpp" is UINT_MAX / 8 and because of how we picked args->width that means cpp < UINT_MAX / 4.
I've fixed it by preventing the integer overflow in DIV_ROUND_UP(). I removed the check for !cpp because it's not possible after this change. I also changed all the 0xffffffffU references to U32_MAX.
--- drivers/gpu/drm/drm_dumb_buffers.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/gpu/drm/drm_dumb_buffers.c +4 -3
@@ -65,12 +65,13 @@ int drm_mode_create_dumb_ioctl(struct drreturn -EINVAL ;/* overflow checks for 32bit size calculations */ -/* NOTE: DIV_ROUND_UP() can overflow */ +if (args->bpp >U32_MAX -8 ) +return -EINVAL ; cpp =DIV_ROUND_UP (args->bpp,8 ); -if (!cpp || cpp >0xffffffffU / args->width) +if (cpp >U32_MAX / args->width)return -EINVAL ; stride = cpp * args->width; -if (args->height >0xffffffffU / stride) +if (args->height >U32_MAX / stride)return -EINVAL ;/* test for wrap-around */
Greg Kroah-Hartman
maintainerPATCH 181/189 parisc: Move setup_profiling_timer() out of init section
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <[email protected]>
[ Upstream commit 01f56832cfb6fcc204e7203f46841b6185ebd574 ]
No other architecture has setup_profiling_timer() in the init section,
thus on parisc we face this section mismatch warning:
Reference from the function devm_device_add_group() to the function .init.text:setup_profiling_timer()
--- arch/parisc/kernel/smp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
arch/parisc/kernel/smp.c +1 -2
@@ -418,8 +418,7 @@ int __cpu_up(unsigned int cpu, struct ta }#ifdef CONFIG_PROC_FS -int __init -setup_profiling_timer (unsigned int multiplier) +int setup_profiling_timer (unsigned int multiplier) {return -EINVAL ; }
Greg Kroah-Hartman
maintainerPATCH 182/189 efi/libstub/arm64: Handle randomized TEXT_OFFSET
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Rutland <[email protected]>
[ Upstream commit 4f74d72aa7067e75af92fbab077e6d7d0210be66 ]
When CONFIG_RANDOMIZE_TEXT_OFFSET=y, TEXT_OFFSET is an arbitrary multiple of PAGE_SIZE in the interval [0, 2MB).
The EFI stub does not account for the potential misalignment of TEXT_OFFSET relative to EFI_KIMG_ALIGN, and produces a randomized physical offset which is always a round multiple of EFI_KIMG_ALIGN. This may result in statically allocated objects whose alignment exceeds PAGE_SIZE to appear misaligned in memory. This has been observed to result in spurious stack overflow reports and failure to make use of the IRQ stacks, and theoretically could result in a number of other issues.
We can OR in the low bits of TEXT_OFFSET to ensure that we have the necessary offset (and hence preserve the misalignment of TEXT_OFFSET relative to EFI_KIMG_ALIGN), so let's do that.
--- drivers/firmware/efi/libstub/arm64-stub.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
drivers/firmware/efi/libstub/arm64-stub.c +10 -0
@@ -98,6 +98,16 @@ efi_status_t handle_kernel_image(efi_sys (phys_seed >> 32) & mask : TEXT_OFFSET;/* +* With CONFIG_RANDOMIZE_TEXT_OFFSET=y, TEXT_OFFSET may not +* be a multiple of EFI_KIMG_ALIGN, and we must ensure that +* we preserve the misalignment of 'offset' relative to +* EFI_KIMG_ALIGN so that statically allocated objects whose +* alignment exceeds PAGE_SIZE appear correctly aligned in +* memory. +*/ + offset |=TEXT_OFFSET %EFI_KIMG_ALIGN ; + +/* * If KASLR is enabled, and we have some randomness available, * locate the kernel at a randomized offset in physical memory. */
Greg Kroah-Hartman
maintainerPATCH 185/189 ARM: kexec: fix kdump register saving on panic()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Russell King <[email protected]>
[ Upstream commit 2d7b3c64431245c95b05a441669c074da10db943 ]
When a panic() occurs, the kexec code uses smp_send_stop() to stop the other CPUs, but this results in the CPU register state not being saved, and gdb is unable to inspect the state of other CPUs.
Commit 0ee59413c967 ("x86/panic: replace smp_send_stop() with kdump friendly version in panic path") addressed the issue on x86, but ignored other architectures. Address the issue on ARM by splitting out the crash stop implementation to crash_smp_send_stop() and adding the necessary protection.
--- arch/arm/kernel/machine_kexec.c | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-)
arch/arm/kernel/machine_kexec.c +22 -12
@@ -95,6 +95,27 @@ void machine_crash_nonpanic_core(void *ucpu_relax (); } +void crash_smp_send_stop (void ) +{ +static int cpus_stopped; +unsigned long msecs; + +if (cpus_stopped) +return ; + +atomic_set (&waiting_for_crash_ipi,num_online_cpus () -1 ); +smp_call_function (machine_crash_nonpanic_core,NULL , false); + msecs =1000 ;/* Wait at most a second for the other cpus to stop */ +while ((atomic_read (&waiting_for_crash_ipi) >0 ) && msecs) { +mdelay (1 ); + msecs--; + } +if (atomic_read (&waiting_for_crash_ipi) >0 ) +pr_warn ("Non-crashing CPUs did not react to IPI\n" ); + + cpus_stopped =1 ; +} +static void machine_kexec_mask_interrupts (void ) {unsigned int i;
@@ -120,19 +141,8 @@ static void machine_kexec_mask_interruptvoid machine_crash_shutdown (struct pt_regs *regs) { -unsigned long msecs; -local_irq_disable (); - -atomic_set (&waiting_for_crash_ipi,num_online_cpus () -1 ); -smp_call_function (machine_crash_nonpanic_core,NULL , false); - msecs =1000 ;/* Wait at most a second for the other cpus to stop */ -while ((atomic_read (&waiting_for_crash_ipi) >0 ) && msecs) { -mdelay (1 ); - msecs--; - } -if (atomic_read (&waiting_for_crash_ipi) >0 ) -pr_warn ("Non-crashing CPUs did not react to IPI\n" ); +crash_smp_send_stop ();crash_save_cpu (regs,smp_processor_id ());machine_kexec_mask_interrupts ();
Greg Kroah-Hartman
maintainerPATCH 186/189 Revert "Btrfs: fix scrub to repair raid6 corruption"
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sasha Levin <[email protected]>
This reverts commit d91bb7c6988bd6450284c762b33f2e1ea3fe7c97.
This commit used an incorrect log message.
--- fs/btrfs/raid56.c | 18 ++++-------------- fs/btrfs/volumes.c | 9 +-------- 2 files changed, 5 insertions(+), 22 deletions(-)
fs/btrfs/raid56.c +4 -14
@@ -2172,21 +2172,11 @@ int raid56_parity_recover(struct btrfs_f }/* -* Loop retry: -* for 'mirror == 2', reconstruct from all other stripes. -* for 'mirror_num > 2', select a stripe to fail on every retry. +* reconstruct from the q stripe if they are +* asking for mirror 3 */ -if (mirror_num >2 ) { -/* -* 'mirror == 3' is to fail the p stripe and -* reconstruct from the q stripe. 'mirror > 3' is to -* fail a data stripe and reconstruct from p+q stripe. -*/ - rbio->failb = rbio->real_stripes - (mirror_num -1 ); -ASSERT (rbio->failb >0 ); -if (rbio->failb <= rbio->faila) - rbio->failb--; - } +if (mirror_num ==3 ) + rbio->failb = rbio->real_stripes -2 ; ret =lock_stripe_add (rbio);
fs/btrfs/volumes.c +1 -8
@@ -5110,14 +5110,7 @@ int btrfs_num_copies(struct btrfs_fs_infelse if (map->type &BTRFS_BLOCK_GROUP_RAID5 ) ret =2 ;else if (map->type &BTRFS_BLOCK_GROUP_RAID6 ) -/* -* There could be two corrupted data stripes, we need -* to loop retry in order to rebuild the correct data. -* -* Fail a stripe at a time on every retry except the -* stripe under reconstruction. -*/ - ret = map->num_stripes; + ret =3 ;else ret =1 ;free_extent_map (em);
Greg Kroah-Hartman
maintainerPATCH 187/189 Btrfs: fix scrub to repair raid6 corruption
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Bo <[email protected]>
[ Upstream commit 762221f095e3932669093466aaf4b85ed9ad2ac1 ]
The raid6 corruption is that,
suppose that all disks can be read without problems and if the content that was read out doesn't match its checksum, currently for raid6 btrfs at most retries twice,
- the 1st retry is to rebuild with all other stripes, it'll eventually be a raid5 xor rebuild,
- if the 1st fails, the 2nd retry will deliberately fail parity p so that it will do raid6 style rebuild,
however, the chances are that another non-parity stripe content also has something corrupted, so that the above retries are not able to return correct content.
We've fixed normal reads to rebuild raid6 correctly with more retries in Patch "Btrfs: make raid6 rebuild retry more"[1], this is to fix scrub to do the exactly same rebuild process.
[1]: https://patchwork.kernel.org/patch/10091755/
--- fs/btrfs/scrub.c | 44 ++++++++++++++++++++++++++++++++------------ 1 file changed, 32 insertions(+), 12 deletions(-)
fs/btrfs/scrub.c +32 -12
@@ -301,6 +301,11 @@ static void __scrub_blocked_if_needed(ststatic void scrub_blocked_if_needed (struct btrfs_fs_info *fs_info);static void scrub_put_ctx (struct scrub_ctx *sctx); +static inline int scrub_is_page_on_raid56 (struct scrub_page *page) +{ +return page->recover && + (page->recover->bbio->map_type &BTRFS_BLOCK_GROUP_RAID56_MASK ); +}static void scrub_pending_bio_inc (struct scrub_ctx *sctx) {
@@ -1323,15 +1328,34 @@ nodatasum_case:* could happen otherwise that a correct page would be * overwritten by a bad one). */ -for (mirror_index =0 ; - mirror_index <BTRFS_MAX_MIRRORS && - sblocks_for_recheck[mirror_index].page_count >0 ; - mirror_index++) { +for (mirror_index =0 ; ;mirror_index++) {struct scrub_block *sblock_other;if (mirror_index == failed_mirror_index)continue ; - sblock_other = sblocks_for_recheck + mirror_index; + +/* raid56's mirror can be more than BTRFS_MAX_MIRRORS */ +if (!scrub_is_page_on_raid56 (sblock_bad->pagev[0 ])) { +if (mirror_index >=BTRFS_MAX_MIRRORS ) +break ; +if (!sblocks_for_recheck[mirror_index].page_count) +break ; + + sblock_other = sblocks_for_recheck + mirror_index; + }else { +struct scrub_recover *r = sblock_bad->pagev[0 ]->recover; +int max_allowed = r->bbio->num_stripes - + r->bbio->num_tgtdevs; + +if (mirror_index >= max_allowed) +break ; +if (!sblocks_for_recheck[1 ].page_count) +break ; + +ASSERT (failed_mirror_index ==0 ); + sblock_other = sblocks_for_recheck +1 ; + sblock_other->pagev[0 ]->mirror_num =1 + mirror_index; + }/* build and submit the bios, check checksums */ scrub_recheck_block (fs_info, sblock_other,0 );
@@ -1679,18 +1703,13 @@ static void scrub_bio_wait_endio(structcomplete (&ret->event); } -static inline int scrub_is_page_on_raid56 (struct scrub_page *page) -{ -return page->recover && - (page->recover->bbio->map_type &BTRFS_BLOCK_GROUP_RAID56_MASK ); -} -static int scrub_submit_raid56_bio_wait (struct btrfs_fs_info *fs_info,struct bio *bio,struct scrub_page *page) {struct scrub_bio_ret done;int ret; +int mirror_num;init_completion (&done.event); done.status =0 ;
@@ -1698,9 +1717,10 @@ static int scrub_submit_raid56_bio_wait( bio->bi_private = &done; bio->bi_end_io = scrub_bio_wait_endio; + mirror_num = page->sblock->pagev[0 ]->mirror_num; ret =raid56_parity_recover (fs_info, bio, page->recover->bbio, page->recover->map_length, - page->mirror_num,0 ); + mirror_num,0 );if (ret)return ret;
Greg Kroah-Hartman
maintainerPATCH 188/189 Btrfs: make raid6 rebuild retry more
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Bo <[email protected]>
[ Upstream commit 8810f7517a3bc4ca2d41d022446d3f5fd6b77c09 ]
There is a scenario that can end up with rebuild process failing to return good content, i.e.
suppose that all disks can be read without problems and if the content that was read out doesn't match its checksum, currently for raid6 btrfs at most retries twice,
- the 1st retry is to rebuild with all other stripes, it'll eventually be a raid5 xor rebuild,
- if the 1st fails, the 2nd retry will deliberately fail parity p so that it will do raid6 style rebuild,
however, the chances are that another non-parity stripe content also has something corrupted, so that the above retries are not able to return correct content, and users will think of this as data loss. More seriouly, if the loss happens on some important internal btree roots, it could refuse to mount.
This extends btrfs to do more retries and each retry fails only one stripe. Since raid6 can tolerate 2 disk failures, if there is one more failure besides the failure on which we're recovering, this can always work.
The worst case is to retry as many times as the number of raid6 disks, but given the fact that such a scenario is really rare in practice, it's still acceptable.
--- fs/btrfs/raid56.c | 18 ++++++++++++++---- fs/btrfs/volumes.c | 9 ++++++++- 2 files changed, 22 insertions(+), 5 deletions(-)
fs/btrfs/raid56.c +14 -4
@@ -2172,11 +2172,21 @@ int raid56_parity_recover(struct btrfs_f }/* -* reconstruct from the q stripe if they are -* asking for mirror 3 +* Loop retry: +* for 'mirror == 2', reconstruct from all other stripes. +* for 'mirror_num > 2', select a stripe to fail on every retry. */ -if (mirror_num ==3 ) - rbio->failb = rbio->real_stripes -2 ; +if (mirror_num >2 ) { +/* +* 'mirror == 3' is to fail the p stripe and +* reconstruct from the q stripe. 'mirror > 3' is to +* fail a data stripe and reconstruct from p+q stripe. +*/ + rbio->failb = rbio->real_stripes - (mirror_num -1 ); +ASSERT (rbio->failb >0 ); +if (rbio->failb <= rbio->faila) + rbio->failb--; + } ret =lock_stripe_add (rbio);
fs/btrfs/volumes.c +8 -1
@@ -5110,7 +5110,14 @@ int btrfs_num_copies(struct btrfs_fs_infelse if (map->type &BTRFS_BLOCK_GROUP_RAID5 ) ret =2 ;else if (map->type &BTRFS_BLOCK_GROUP_RAID6 ) - ret =3 ; +/* +* There could be two corrupted data stripes, we need +* to loop retry in order to rebuild the correct data. +* +* Fail a stripe at a time on every retry except the +* stripe under reconstruction. +*/ + ret = map->num_stripes;else ret =1 ;free_extent_map (em);
Greg Kroah-Hartman
maintainerPATCH 189/189 tcp: do not overshoot window_clamp in tcp_rcv_space_adjust()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
commit 02db55718d53f9d426cee504c27fb768e9ed4ffe upstream.
While rcvbuf is properly clamped by tcp_rmem[2], rcvwin is left to a potentially too big value.
It has no serious effect, since :
1) tcp_grow_window() has very strict checks.
2) window_clamp can be mangled by user space to any value anyway.
tcp_init_buffer_space() and companions use tcp_full_space(), we use tcp_win_from_space() to avoid reloading sk->sk_rcvbuf
--- net/ipv4/tcp_input.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv4/tcp_input.c +1 -1
@@ -647,7 +647,7 @@ void tcp_rcv_space_adjust(struct sock *s sk->sk_rcvbuf = rcvbuf;/* Make the window clamp follow along. */ - tp->window_clamp = rcvwin; + tp->window_clamp =tcp_win_from_space (rcvbuf); } } tp->rcvq_space.space = copied;
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.51 release. There are 189 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Jun 20 08:11:38 UTC 2018. Anything received after that time might be too late.
For 4.14.50-189-g3e67e20:
Build results:
total: 148 pass: 148 fail: 0 Qemu test results: total: 154 pass: 154 fail: 0
Details are available at http://kerneltests.org/builders/.
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.51 release. There are 189 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed Jun 20 08:11:38 UTC 2018. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.51-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
Summary
------------------------------------------------------------------------
kernel: 4.14.51-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 3e67e2023733ff0796077205a09178330bdac357
git describe: v4.14.50-189-g3e67e2023733
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.50-189-g3e67e2023733
No regressions (compared to build v4.14.50-190-gc758a48da7f5)
Ran 11416 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-io-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org