Hi Greg, hi Sasha,
Please consider to include following fixes in to stable tree.
The 6 patches from Ming was fixing a deadlock, they are included around kernel
5.3/4. Would be good to included in 4.19, we hit it during testing, with the fix
we no longer hit the deadlock.
The md fixes is for a panic regarding handle flush.
the last one is simple NULL pointer deref fix.
Thanks!
Jack Wang @ IONOS Cloud.
Ming Lei (6):
block: don't hold q->sysfs_lock in elevator_init_mq
blk-mq: don't hold q->sysfs_lock in blk_mq_map_swqueue
block: add helper for checking if queue is registered
block: split .sysfs_lock into two locks
block: fix race between switching elevator and removing queues
block: don't release queue's sysfs lock during switching elevator
Xiao Ni (1):
md: Set prev_flush_start and flush_bio in an atomic way
zhengbin (1):
block: fix NULL pointer dereference in register_disk
block/blk-core.c | 1 +
block/blk-mq-sysfs.c | 12 +++++------
block/blk-mq.c | 7 ------
block/blk-sysfs.c | 49 +++++++++++++++++++++++++++---------------
block/blk-wbt.c | 2 +-
block/blk.h | 2 +-
block/elevator.c | 44 +++++++++++++++++++++----------------
block/genhd.c | 10 +++++----
drivers/md/md.c | 2 ++
include/linux/blkdev.h | 2 ++
10 files changed, 76 insertions(+), 55 deletions(-)
--
2.25.1
On Mon, Jan 25, 2021 at 12:49:39PM -0800, Linus Torvalds wrote:
> On Mon, Jan 25, 2021 at 12:35 PM Chris Wilson <chris(a)chris-wilson.co.uk> wrote:
>
> Mike: should we perhaps revert the first patch too (commit
> bde9cfa3afe4: "x86/setup: don't remove E820_TYPE_RAM for pfn 0")?
Unfortunately, I was too optimistic and didn't take into account that this
commit changes the way /dev/mem sees the first page of memory.
There were reports of slackware users about issues with lilo after upgrade
from 5.10.11 to 5.10.12
https://www.linuxquestions.org/questions/slackware-14/slackware-current-lil…
The root cause is that lilo is no longer able to access the first memory
page via /dev/mem because its type was changed from E820_TYPE_RESERVED to
E820_TYPE_RAM, so this became a part of the "System RAM" resource and
devmem_is_allowed() considers it disallowed area.
So here's the revert of bde9cfa3afe4 as well.
>From a7fdc4117010d393dd77b99da5b573a5c98453ce Mon Sep 17 00:00:00 2001
From: Mike Rapoport <rppt(a)linux.ibm.com>
Date: Thu, 4 Feb 2021 20:12:37 +0200
Subject: [PATCH] Revert "x86/setup: don't remove E820_TYPE_RAM for pfn 0"
This reverts commit bde9cfa3afe4324ec251e4af80ebf9b7afaf7afe.
Changing the first memory page type from E820_TYPE_RESERVED to
E820_TYPE_RAM makes it a part of "System RAM" resource rather than a
reserved resource and this in turn causes devmem_is_allowed() to treat is
as area that can be accessed but it is filled with zeroes instead of the
actual data as previously.
The change in /dev/mem output causes lilo to fail as was reported at
slakware users forum [1], and probably other legacy applications will
experience similar problems.
[1] https://www.linuxquestions.org/questions/slackware-14/slackware-current-lil…
Signed-off-by: Mike Rapoport <rppt(a)linux.ibm.com>
---
arch/x86/kernel/setup.c | 20 +++++++++++---------
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 3412c4595efd..740f3bdb3f61 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -660,6 +660,17 @@ static void __init trim_platform_memory_ranges(void)
static void __init trim_bios_range(void)
{
+ /*
+ * A special case is the first 4Kb of memory;
+ * This is a BIOS owned area, not kernel ram, but generally
+ * not listed as such in the E820 table.
+ *
+ * This typically reserves additional memory (64KiB by default)
+ * since some BIOSes are known to corrupt low memory. See the
+ * Kconfig help text for X86_RESERVE_LOW.
+ */
+ e820__range_update(0, PAGE_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED);
+
/*
* special case: Some BIOSes report the PC BIOS
* area (640Kb -> 1Mb) as RAM even though it is not.
@@ -717,15 +728,6 @@ early_param("reservelow", parse_reservelow);
static void __init trim_low_memory_range(void)
{
- /*
- * A special case is the first 4Kb of memory;
- * This is a BIOS owned area, not kernel ram, but generally
- * not listed as such in the E820 table.
- *
- * This typically reserves additional memory (64KiB by default)
- * since some BIOSes are known to corrupt low memory. See the
- * Kconfig help text for X86_RESERVE_LOW.
- */
memblock_reserve(0, ALIGN(reserve_low, PAGE_SIZE));
}
--
2.29.2
> Linus
--
Sincerely yours,
Mike.
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
The BXT/GLK DPLL can't generate certain frequencies. We already
reject the 233-240MHz range on both. But on GLK the DPLL max
frequency was bumped from 300MHz to 594MHz, so now we get to
also worry about the 446-480MHz range (double the original
problem range). Reject any frequency within the higher
problematic range as well.
Cc: stable(a)vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3000
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 66e1ac3887c6..b593a71e6517 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2218,7 +2218,11 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi,
has_hdmi_sink))
return MODE_CLOCK_HIGH;
- /* BXT DPLL can't generate 223-240 MHz */
+ /* GLK DPLL can't generate 446-480 MHz */
+ if (IS_GEMINILAKE(dev_priv) && clock > 446666 && clock < 480000)
+ return MODE_CLOCK_RANGE;
+
+ /* BXT/GLK DPLL can't generate 223-240 MHz */
if (IS_GEN9_LP(dev_priv) && clock > 223333 && clock < 240000)
return MODE_CLOCK_RANGE;
--
2.26.2