user/sven/linux.git, branch v4.19.53

Linux 4.19.53

2019-06-19T06:18:07Z

rtc: pcf8523: don't return invalid date when battery is low

2019-06-19T06:18:07Z

commit ecb4a353d3afd45b9bb30c85d03ee113a0589079 upstream. The RTC_VL_READ ioctl reports the low battery condition. Still, pcf8523_rtc_read_time() happily returns invalid dates in this case. Check the battery health on pcf8523_rtc_read_time() to avoid that. Reported-by: Erik Čuk Signed-off-by: Baruch Siach Signed-off-by: Alexandre Belloni Signed-off-by: Greg Kroah-Hartman

drm: add fallback override/firmware EDID modes workaround

2019-06-19T06:18:07Z

commit 48eaeb7664c76139438724d520a1ea4a84a3ed92 upstream. We've moved the override and firmware EDID (simply "override EDID" from now on) handling to the low level drm_do_get_edid() function in order to transparently use the override throughout the stack. The idea is that you get the override EDID via the ->get_modes() hook. Unfortunately, there are scenarios where the DDC probe in drm_get_edid() called via ->get_modes() fails, although the preceding ->detect() succeeds. In the case reported by Paul Wise, the ->detect() hook, intel_crt_detect(), relies on hotplug detect, bypassing the DDC. In the case reported by Ilpo Järvinen, there is no ->detect() hook, which is interpreted as connected. The subsequent DDC probe reached via ->get_modes() fails, and we don't even look at the override EDID, resulting in no modes being added. Because drm_get_edid() is used via ->detect() all over the place, we can't trivially remove the DDC probe, as it leads to override EDID effectively meaning connector forcing. The goal is that connector forcing and override EDID remain orthogonal. Generally, the underlying problem here is the conflation of ->detect() and ->get_modes() via drm_get_edid(). The former should just detect, and the latter should just get the modes, typically via reading the EDID. As long as drm_get_edid() is used in ->detect(), it needs to retain the DDC probe. Or such users need to have a separate DDC probe step first. The EDID caching between ->detect() and ->get_modes() done by some drivers is a further complication that prevents us from making drm_do_get_edid() adapt to the two cases. Work around the regression by falling back to a separate attempt at getting the override EDID at drm_helper_probe_single_connector_modes() level. With a working DDC and override EDID, it'll never be called; the override EDID will come via ->get_modes(). There will still be a failing DDC probe attempt in the cases that require the fallback. v2: - Call drm_connector_update_edid_property (Paul) - Update commit message about EDID caching (Daniel) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107583 Reported-by: Paul Wise Cc: Paul Wise References: http://mid.mail-archive.com/alpine.DEB.2.20.1905262211270.24390@whs-18.cs.helsinki.fi Reported-by: Ilpo Järvinen Cc: Ilpo Järvinen Suggested-by: Daniel Vetter References: 15f080f08d48 ("drm/edid: respect connector force for drm_get_edid ddc probe") Fixes: 53fd40a90f3c ("drm: handle override and firmware EDID at drm_do_get_edid() level") Cc: # v4.15+ 56a2b7f2a39a drm/edid: abstract override/firmware EDID retrieval Cc: # v4.15+ Cc: Daniel Vetter Cc: Ville Syrjälä Cc: Harish Chegondi Tested-by: Paul Wise Reviewed-by: Daniel Vetter Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20190610093054.28445-1-jani.nikula@intel.com Signed-off-by: Greg Kroah-Hartman

drm/edid: abstract override/firmware EDID retrieval

2019-06-19T06:18:07Z

commit 56a2b7f2a39a8d4b16a628e113decde3d7400879 upstream. Abstract the debugfs override and the firmware EDID retrieval function. We'll be needing it in the follow-up. No functional changes. Cc: Daniel Vetter Cc: Harish Chegondi Reviewed-by: Daniel Vetter Tested-by: Tested-by: Paul Wise Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20190607110513.12072-1-jani.nikula@intel.com Signed-off-by: Greg Kroah-Hartman

x86/resctrl: Prevent NULL pointer dereference when local MBM is disabled

2019-06-19T06:18:07Z

commit c7563e62a6d720aa3b068e26ddffab5f0df29263 upstream. Booting with kernel parameter "rdt=cmt,mbmtotal,memlocal,l3cat,mba" and executing "mount -t resctrl resctrl -o mba_MBps /sys/fs/resctrl" results in a NULL pointer dereference on systems which do not have local MBM support enabled.. BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 722 Comm: kworker/0:3 Not tainted 5.2.0-0.rc3.git0.1.el7_UNSUPPORTED.x86_64 #2 Workqueue: events mbm_handle_overflow RIP: 0010:mbm_handle_overflow+0x150/0x2b0 Only enter the bandwith update loop if the system has local MBM enabled. Fixes: de73f38f7680 ("x86/intel_rdt/mba_sc: Feedback loop to dynamically update mem bandwidth") Signed-off-by: Prarit Bhargava Signed-off-by: Thomas Gleixner Cc: Fenghua Yu Cc: Reinette Chatre Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20190610171544.13474-1-prarit@redhat.com Signed-off-by: Greg Kroah-Hartman

x86/mm/KASLR: Compute the size of the vmemmap section properly

2019-06-19T06:18:07Z

commit 00e5a2bbcc31d5fea853f8daeba0f06c1c88c3ff upstream. The size of the vmemmap section is hardcoded to 1 TB to support the maximum amount of system RAM in 4-level paging mode - 64 TB. However, 1 TB is not enough for vmemmap in 5-level paging mode. Assuming the size of struct page is 64 Bytes, to support 4 PB system RAM in 5-level, 64 TB of vmemmap area is needed: 4 * 1000^5 PB / 4096 bytes page size * 64 bytes per page struct / 1000^4 TB = 62.5 TB. This hardcoding may cause vmemmap to corrupt the following cpu_entry_area section, if KASLR puts vmemmap very close to it and the actual vmemmap size is bigger than 1 TB. So calculate the actual size of the vmemmap region needed and then align it up to 1 TB boundary. In 4-level paging mode it is always 1 TB. In 5-level it's adjusted on demand. The current code reserves 0.5 PB for vmemmap on 5-level. With this change, the space can be saved and thus used to increase entropy for the randomization. [ bp: Spell out how the 64 TB needed for vmemmap is computed and massage commit message. ] Fixes: eedb92abb9bb ("x86/mm: Make virtual memory layout dynamic for CONFIG_X86_5LEVEL=y") Signed-off-by: Baoquan He Signed-off-by: Borislav Petkov Reviewed-by: Kees Cook Acked-by: Kirill A. Shutemov Cc: Andy Lutomirski Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: kirill.shutemov@linux.intel.com Cc: Peter Zijlstra Cc: stable Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20190523025744.3756-1-bhe@redhat.com Signed-off-by: Greg Kroah-Hartman

x86/kasan: Fix boot with 5-level paging and KASAN

2019-06-19T06:18:06Z

commit f3176ec9420de0c385023afa3e4970129444ac2f upstream. Since commit d52888aa2753 ("x86/mm: Move LDT remap out of KASLR region on 5-level paging") kernel doesn't boot with KASAN on 5-level paging machines. The bug is actually in early_p4d_offset() and introduced by commit 12a8cc7fcf54 ("x86/kasan: Use the same shadow offset for 4- and 5-level paging") early_p4d_offset() tries to convert pgd_val(*pgd) value to a physical address. This doesn't make sense because pgd_val() already contains the physical address. It did work prior to commit d52888aa2753 because the result of "__pa_nodebug(pgd_val(*pgd)) & PTE_PFN_MASK" was the same as "pgd_val(*pgd) & PTE_PFN_MASK". __pa_nodebug() just set some high bits which were masked out by applying PTE_PFN_MASK. After the change of the PAGE_OFFSET offset in commit d52888aa2753 __pa_nodebug(pgd_val(*pgd)) started to return a value with more high bits set and PTE_PFN_MASK wasn't enough to mask out all of them. So it returns a wrong not even canonical address and crashes on the attempt to dereference it. Switch back to pgd_val() & PTE_PFN_MASK to cure the issue. Fixes: 12a8cc7fcf54 ("x86/kasan: Use the same shadow offset for 4- and 5-level paging") Reported-by: Kirill A. Shutemov Signed-off-by: Andrey Ryabinin Signed-off-by: Thomas Gleixner Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: kasan-dev@googlegroups.com Cc: stable@vger.kernel.org Cc: Link: https://lkml.kernel.org/r/20190614143149.2227-1-aryabinin@virtuozzo.com Signed-off-by: Greg Kroah-Hartman

x86/microcode, cpuhotplug: Add a microcode loader CPU hotplug callback

2019-06-19T06:18:06Z

commit 78f4e932f7760d965fb1569025d1576ab77557c5 upstream. Adric Blake reported the following warning during suspend-resume: Enabling non-boot CPUs ... x86: Booting SMP configuration: smpboot: Booting Node 0 Processor 1 APIC 0x2 unchecked MSR access error: WRMSR to 0x10f (tried to write 0x0000000000000000) \ at rIP: 0xffffffff8d267924 (native_write_msr+0x4/0x20) Call Trace: intel_set_tfa intel_pmu_cpu_starting ? x86_pmu_dead_cpu x86_pmu_starting_cpu cpuhp_invoke_callback ? _raw_spin_lock_irqsave notify_cpu_starting start_secondary secondary_startup_64 microcode: sig=0x806ea, pf=0x80, revision=0x96 microcode: updated to revision 0xb4, date = 2019-04-01 CPU1 is up The MSR in question is MSR_TFA_RTM_FORCE_ABORT and that MSR is emulated by microcode. The log above shows that the microcode loader callback happens after the PMU restoration, leading to the conjecture that because the microcode hasn't been updated yet, that MSR is not present yet, leading to the #GP. Add a microcode loader-specific hotplug vector which comes before the PERF vectors and thus executes earlier and makes sure the MSR is present. Fixes: 400816f60c54 ("perf/x86/intel: Implement support for TSX Force Abort") Reported-by: Adric Blake Signed-off-by: Borislav Petkov Reviewed-by: Thomas Gleixner Cc: Peter Zijlstra Cc: Cc: x86@kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=203637 Signed-off-by: Greg Kroah-Hartman

RAS/CEC: Fix binary search function

2019-06-19T06:18:06Z

commit f3c74b38a55aefe1004200d15a83f109b510068c upstream. Switch to using Donald Knuth's binary search algorithm (The Art of Computer Programming, vol. 3, section 6.2.1). This should've been done from the very beginning but the author must've been smoking something very potent at the time. The problem with the current one was that it would return the wrong element index in certain situations: https://lkml.kernel.org/r/CAM_iQpVd02zkVJ846cj-Fg1yUNuz6tY5q1Vpj4LrXmE06dPYYg@mail.gmail.com and the noodling code after the loop was fishy at best. So switch to using Knuth's binary search. The final result is much cleaner and straightforward. Fixes: 011d82611172 ("RAS: Add a Corrected Errors Collector") Reported-by: Cong Wang Signed-off-by: Borislav Petkov Cc: Tony Luck Cc: linux-edac Cc: Signed-off-by: Greg Kroah-Hartman

RAS/CEC: Convert the timer callback to a workqueue

2019-06-19T06:18:06Z

commit 0ade0b6240c4853cf9725924c46c10f4251639d7 upstream. cec_timer_fn() is a timer callback which reads ce_arr.array[] and updates its decay values. However, it runs in interrupt context and the mutex protection the CEC uses for that array, is inadequate. Convert the used timer to a workqueue to keep the tasks the CEC performs preemptible and thus low-prio. [ bp: Rewrite commit message. s/timer/decay/gi to make it agnostic as to what facility is used. ] Fixes: 011d82611172 ("RAS: Add a Corrected Errors Collector") Signed-off-by: Cong Wang Signed-off-by: Borislav Petkov Cc: Thomas Gleixner Cc: Tony Luck Cc: linux-edac Cc: Link: https://lkml.kernel.org/r/20190416213351.28999-2-xiyou.wangcong@gmail.com Signed-off-by: Greg Kroah-Hartman