Greetings,
this series is the backport of 18 upstream patches to add the
current s390 spectre mitigation to kernel version 4.14. One
less patch than 4.14 and 4.9 as there is no nested KVM guest
support (aka vsie) in 4.4.
It follows the x86 approach with array_index_nospec for the v1
spectre attack and retpoline/expoline for v2. As a fallback
there is the ppa-12/ppa-13 based defense which requires an
micro-code update.
Christian Borntraeger (2):
KVM: s390: wire up bpb feature
s390/entry.S: fix spurious zeroing of r0
Eugeniu Rosca (1):
s390: Replace IS_ENABLED(EXPOLINE_*) with
IS_ENABLED(CONFIG_EXPOLINE_*)
Heiko Carstens (1):
s390: enable CPU alternatives unconditionally
Martin Schwidefsky (13):
s390: scrub registers on kernel entry and KVM exit
s390: add optimized array_index_mask_nospec
s390/alternative: use a copy of the facility bit mask
s390: add options to change branch prediction behaviour for the kernel
s390: run user space and KVM guests with modified branch prediction
s390: introduce execute-trampolines for branches
s390: do not bypass BPENTER for interrupt system calls
s390: move nobp parameter functions to nospec-branch.c
s390: add automatic detection of the spectre defense
s390: report spectre mitigation via syslog
s390: add sysfs attributes for spectre
s390: correct nospec auto detection init order
s390: correct module section names for expoline code revert
Vasily Gorbik (1):
s390: introduce CPU alternatives
Documentation/kernel-parameters.txt | 3 +
arch/s390/Kconfig | 47 +++++++
arch/s390/Makefile | 10 ++
arch/s390/include/asm/alternative.h | 149 ++++++++++++++++++++
arch/s390/include/asm/barrier.h | 24 ++++
arch/s390/include/asm/facility.h | 18 +++
arch/s390/include/asm/kvm_host.h | 3 +-
arch/s390/include/asm/lowcore.h | 7 +-
arch/s390/include/asm/nospec-branch.h | 17 +++
arch/s390/include/asm/processor.h | 4 +
arch/s390/include/asm/thread_info.h | 4 +
arch/s390/include/uapi/asm/kvm.h | 3 +
arch/s390/kernel/Makefile | 5 +-
arch/s390/kernel/alternative.c | 112 +++++++++++++++
arch/s390/kernel/early.c | 5 +
arch/s390/kernel/entry.S | 250 ++++++++++++++++++++++++++++++----
arch/s390/kernel/ipl.c | 1 +
arch/s390/kernel/module.c | 65 ++++++++-
arch/s390/kernel/nospec-branch.c | 169 +++++++++++++++++++++++
arch/s390/kernel/processor.c | 18 +++
arch/s390/kernel/setup.c | 14 +-
arch/s390/kernel/smp.c | 7 +-
arch/s390/kernel/vmlinux.lds.S | 37 +++++
arch/s390/kvm/kvm-s390.c | 13 +-
drivers/s390/char/Makefile | 2 +
include/uapi/linux/kvm.h | 1 +
26 files changed, 952 insertions(+), 36 deletions(-)
create mode 100644 arch/s390/include/asm/alternative.h
create mode 100644 arch/s390/include/asm/nospec-branch.h
create mode 100644 arch/s390/kernel/alternative.c
create mode 100644 arch/s390/kernel/nospec-branch.c
--
2.13.5
Update SECONDARY_EXEC_DESC in SECONDARY_VM_EXEC_CONTROL for UMIP
emulation if and only if CR4.UMIP is being modified and UMIP is
not supported by hardware, i.e. we're emulating UMIP. If CR4.UMIP
is not being changed then it's safe to assume that the previous
invocation of vmx_set_cr4() correctly set SECONDARY_EXEC_DESC,
i.e. the desired value is already the current value. This avoids
unnecessary VMREAD/VMWRITE to SECONDARY_VM_EXEC_CONTROL, which
is critical as not all processors support SECONDARY_VM_EXEC_CONTROL.
WARN once and signal a fault if CR4.UMIP is changing and UMIP can't
be emulated, i.e. SECONDARY_EXEC_DESC can't be set. Prior checks
should prevent setting UMIP if it can't be emulated, i.e. UMIP
shouldn't have been advertised to the guest if it can't be emulated,
regardless of whether or not UMIP is supported in bare metal.
Fixes: 0367f205a3b7 ("KVM: vmx: add support for emulating UMIP")
Cc: stable(a)vger.kernel.org #4.16
Reported-by: Paolo Zeppegno <pzeppegno(a)gmail.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson(a)intel.com>
---
arch/x86/kvm/vmx.c | 34 ++++++++++++++++++++--------------
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index aafcc9881e88..1502a2ac7884 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1494,6 +1494,12 @@ static inline bool cpu_has_vmx_vmfunc(void)
SECONDARY_EXEC_ENABLE_VMFUNC;
}
+static bool vmx_umip_emulated(void)
+{
+ return vmcs_config.cpu_based_2nd_exec_ctrl &
+ SECONDARY_EXEC_DESC;
+}
+
static inline bool report_flexpriority(void)
{
return flexpriority_enabled;
@@ -4776,14 +4782,20 @@ static int vmx_set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4)
else
hw_cr4 |= KVM_PMODE_VM_CR4_ALWAYS_ON;
- if ((cr4 & X86_CR4_UMIP) && !boot_cpu_has(X86_FEATURE_UMIP)) {
- vmcs_set_bits(SECONDARY_VM_EXEC_CONTROL,
- SECONDARY_EXEC_DESC);
- hw_cr4 &= ~X86_CR4_UMIP;
- } else if (!is_guest_mode(vcpu) ||
- !nested_cpu_has2(get_vmcs12(vcpu), SECONDARY_EXEC_DESC))
- vmcs_clear_bits(SECONDARY_VM_EXEC_CONTROL,
- SECONDARY_EXEC_DESC);
+ if (((cr4 ^ kvm_read_cr4(vcpu)) & X86_CR4_UMIP) &&
+ !boot_cpu_has(X86_FEATURE_UMIP)) {
+ if (WARN_ON_ONCE(!vmx_umip_emulated()))
+ return 1;
+
+ if (cr4 & X86_CR4_UMIP) {
+ vmcs_set_bits(SECONDARY_VM_EXEC_CONTROL,
+ SECONDARY_EXEC_DESC);
+ hw_cr4 &= ~X86_CR4_UMIP;
+ } else if (!is_guest_mode(vcpu) ||
+ !nested_cpu_has2(get_vmcs12(vcpu), SECONDARY_EXEC_DESC))
+ vmcs_clear_bits(SECONDARY_VM_EXEC_CONTROL,
+ SECONDARY_EXEC_DESC);
+ }
if (cr4 & X86_CR4_VMXE) {
/*
@@ -9512,12 +9524,6 @@ static bool vmx_xsaves_supported(void)
SECONDARY_EXEC_XSAVES;
}
-static bool vmx_umip_emulated(void)
-{
- return vmcs_config.cpu_based_2nd_exec_ctrl &
- SECONDARY_EXEC_DESC;
-}
-
static void vmx_recover_nmi_blocking(struct vcpu_vmx *vmx)
{
u32 exit_intr_info;
--
2.16.2
On Fri, Apr 27, 2018 at 08:43:03AM -0600, Scott Bauer wrote:
>
>
> On 04/27/2018 06:41 AM, Dan Carpenter wrote:
> > I sent you an email to send this patch, but reviewing it now it's not
> > actually a run time bug. The cdrom_slot_status() function takes an
> > integer argument so it works.
>
> It's still runtime bug... I should reword the commit a bit to reflect that it's not
> like the upper 32 bit issue that you had found. Look at it this way, ints can be negative, right?
>
Oh. Yeah. Duh...
> The check is as follows:
>
> 2545: if (((int)arg >= cdi->capacity))
> return -EINVAL <https://elixir.bootlin.com/linux/v4.17-rc2/ident/EINVAL>;
> return cdrom_slot_status <https://elixir.bootlin.com/linux/v4.17-rc2/ident/cdrom_slot_status>(cdi, arg); so if (-65536 >= cdi->capacity) it's not so we don't return -einval. And we pass a negative index into cdrom_slot_status.
>
>
> where we do the following (https://elixir.bootlin.com/linux/v4.17-rc2/source/drivers/cdrom/cdrom.c#L13…):
>
> 1336:
> if (info->slots <https://elixir.bootlin.com/linux/v4.17-rc2/ident/slots>[slot <https://elixir.bootlin.com/linux/v4.17-rc2/ident/slot>].disc_present)
> ret = CDS_DISC_OK <https://elixir.bootlin.com/linux/v4.17-rc2/ident/CDS_DISC_OK>;
>
>
>
> >
> > I'm working on a static checker warning for these kinds of bugs:
> >
> > drivers/cdrom/cdrom.c:2444 cdrom_ioctl_select_disc() warn: truncated comparison 'arg' 'u64max' to 's32max'
> >
> > drivers/cdrom/cdrom.c
> > 2435 static int cdrom_ioctl_select_disc(struct cdrom_device_info *cdi,
> > 2436 unsigned long arg)
> > 2437 {
> > 2438 cd_dbg(CD_DO_IOCTL, "entering CDROM_SELECT_DISC\n");
> > 2439
> > 2440 if (!CDROM_CAN(CDC_SELECT_DISC))
> > 2441 return -ENOSYS;
> > 2442
> > 2443 if (arg != CDSL_CURRENT && arg != CDSL_NONE) {
> > 2444 if ((int)arg >= cdi->capacity)
> > ^^^^^^^^^^^^^^^^^^^^^^^^^
> > 2445 return -EINVAL;
> > 2446 }
> > 2447
> > 2448 /*
> > 2449 * ->select_disc is a hook to allow a driver-specific way of
> > 2450 * seleting disc. However, since there is no equivalent hook for
> > 2451 * cdrom_slot_status this may not actually be useful...
> > 2452 */
> > 2453 if (cdi->ops->select_disc)
> > 2454 return cdi->ops->select_disc(cdi, arg);
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > ->select_disc() also take an int so it's fine (plus there is no such
> > function so it's dead code).
> >
> > 2455
> > 2456 cd_dbg(CD_CHANGER, "Using generic cdrom_select_disc()\n");
> > 2457 return cdrom_select_disc(cdi, arg);
> > ^^^
> > Also an int.
> >
> > 2458 }
> >
> > So I think it's a good idea to fix these just for cleanliness and to
> > silence the static checker warnings but it doesn't affect runtime.
>
> Yeah, this one was "fine" aside from being messy, that's why I didn't send a patch for it.
>
I'm not convinced any more. Could you patch it and resend? We could
end up sending invalid commands to the cdrom firmware when we do
cdrom_load_unload() at the end of the cdrom_select_disc() function.
Proably there is no impact but we may as well fix it. Here is my
analysis if you are curious:
1371 /* If SLOT < 0, unload the current slot. Otherwise, try to load SLOT. */
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
CDSL_CURRENT is INT_MAX and CDSL_NONE is "INT_MAX - 1" but
cdrom_select_disc() calls this with slot set to -1.
1372 static int cdrom_load_unload(struct cdrom_device_info *cdi, int slot)
1373 {
1374 struct packet_command cgc;
1375
1376 cd_dbg(CD_CHANGER, "entering cdrom_load_unload()\n");
1377 if (cdi->sanyo_slot && slot < 0)
1378 return 0;
1379
1380 init_cdrom_command(&cgc, NULL, 0, CGC_DATA_NONE);
1381 cgc.cmd[0] = GPCMD_LOAD_UNLOAD;
1382 cgc.cmd[4] = 2 + (slot >= 0);
^^^^^^^^^^
So cmd[4] is 2.
1383 cgc.cmd[8] = slot;
^^^^^^^^^^^^^^^^^
Here were setting cmd[8] to any u8 value we choose.
1384 cgc.timeout = 60 * HZ;
1385
1386 /* The Sanyo 3 CD changer uses byte 7 of the
1387 GPCMD_TEST_UNIT_READY to command to switch CDs instead of
1388 using the GPCMD_LOAD_UNLOAD opcode. */
1389 if (cdi->sanyo_slot && -1 < slot) {
1390 cgc.cmd[0] = GPCMD_TEST_UNIT_READY;
1391 cgc.cmd[7] = slot;
1392 cgc.cmd[4] = cgc.cmd[8] = 0;
1393 cdi->sanyo_slot = slot ? slot : 3;
1394 }
1395
1396 return cdi->ops->generic_packet(cdi, &cgc);
1397 }
> P.S. Is your static analysis tooling available for the general public to look at?
Sure. I've been dorking with it for a couple days and I haven't tested
the latest version except on drivers/cdrom/cdrom.c so let me do some
more testing and then I'll post it.
regards,
dan carpenter
Hi,
This 2nd version of the series which fixes %p uses in kprobes.
Some by replacing with %pS, some by replacing with %px but
masking with kallsyms_show_value().
V1 series is here:
https://lkml.org/lkml/2018/1/25/1
I've read the thread about %pK and if I understand correctly
we shouldn't print kernel addresses. However, kprobes debugfs
interface can not stop to show the actual probe address because
it should be compared with addresses in kallsyms for debugging.
So, it depends on that kallsyms_show_value() allows to show
address to user, because if it returns true, anyway that user
can dump /proc/kallsyms.
Other error messages are replaced it with %pS, and one critical
function uses %px which is called right before BUG().
Also, I tried to fix this issue on each arch port. I searched
it by
# find arch/* | grep -e 'kprobe.*c' | xargs grep -w %p
And fixed all %p uses in those files.
Changes in this version;
- [1/7] is newly added.
- patches for MN10300(deleted) and s390(merged) are removed.
Thank you,
---
Masami Hiramatsu (7):
kprobes: Make blacklist root user read only
kprobes: Show blacklist addresses as same as kallsyms does
kprobes: Show address of kprobes if kallsyms does
kprobes: Replace %p with other pointer types
kprobes/x86: Fix %p uses in error messages
kprobes/arm: Fix %p uses in error messages
kprobes/arm64: Fix %p uses in error messages
arch/arm/probes/kprobes/core.c | 10 ++++----
arch/arm/probes/kprobes/test-core.c | 1 -
arch/arm64/kernel/probes/kprobes.c | 4 ++-
arch/x86/kernel/kprobes/core.c | 12 +++------
kernel/kprobes.c | 46 ++++++++++++++++++++++-------------
5 files changed, 40 insertions(+), 33 deletions(-)
--
Masami Hiramatsu (Linaro) <mhiramat(a)kernel.org>
The patch below does not apply to the 4.16-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 6cf09958f32b9667bb3ebadf74367c791112771b Mon Sep 17 00:00:00 2001
From: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Date: Fri, 20 Apr 2018 12:48:52 +0200
Subject: [PATCH] s390: correct module section names for expoline code revert
The main linker script vmlinux.lds.S for the kernel image merges
the expoline code patch tables into two section ".nospec_call_table"
and ".nospec_return_table". This is *not* done for the modules,
there the sections retain their original names as generated by gcc:
".s390_indirect_call", ".s390_return_mem" and ".s390_return_reg".
The module_finalize code has to check for the compiler generated
section names, otherwise no code patching is done. This slows down
the module code in case of "spectre_v2=off".
Cc: stable(a)vger.kernel.org # 4.16
Fixes: f19fbd5ed6 ("s390: introduce execute-trampolines for branches")
Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
diff --git a/arch/s390/kernel/module.c b/arch/s390/kernel/module.c
index 5a83be955c70..0dc8ac8548ee 100644
--- a/arch/s390/kernel/module.c
+++ b/arch/s390/kernel/module.c
@@ -465,11 +465,11 @@ int module_finalize(const Elf_Ehdr *hdr,
apply_alternatives(aseg, aseg + s->sh_size);
if (IS_ENABLED(CONFIG_EXPOLINE) &&
- (!strcmp(".nospec_call_table", secname)))
+ (!strncmp(".s390_indirect", secname, 14)))
nospec_revert(aseg, aseg + s->sh_size);
if (IS_ENABLED(CONFIG_EXPOLINE) &&
- (!strcmp(".nospec_return_table", secname)))
+ (!strncmp(".s390_return", secname, 12)))
nospec_revert(aseg, aseg + s->sh_size);
}
The patch
ASoC: mediatek: preallocate pages use platform device
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 5845e6155d8f4a4a9bae2d4c1d1bb4a4d9a925c2 Mon Sep 17 00:00:00 2001
From: Kai Chieh Chuang <kaichieh.chuang(a)mediatek.com>
Date: Fri, 27 Apr 2018 10:11:35 +0800
Subject: [PATCH] ASoC: mediatek: preallocate pages use platform device
preallocate pages should use platform device,
since we set dma mask for platform device.
Signed-off-by: KaiChieh Chuang <kaichieh.chuang(a)mediatek.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/mediatek/common/mtk-afe-platform-driver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/mediatek/common/mtk-afe-platform-driver.c b/sound/soc/mediatek/common/mtk-afe-platform-driver.c
index 53215b52e4f2..f8a06709f76d 100644
--- a/sound/soc/mediatek/common/mtk-afe-platform-driver.c
+++ b/sound/soc/mediatek/common/mtk-afe-platform-driver.c
@@ -64,14 +64,14 @@ static const struct snd_pcm_ops mtk_afe_pcm_ops = {
static int mtk_afe_pcm_new(struct snd_soc_pcm_runtime *rtd)
{
size_t size;
- struct snd_card *card = rtd->card->snd_card;
struct snd_pcm *pcm = rtd->pcm;
struct snd_soc_component *component = snd_soc_rtdcom_lookup(rtd, AFE_PCM_NAME);
struct mtk_base_afe *afe = snd_soc_component_get_drvdata(component);
size = afe->mtk_afe_hardware->buffer_bytes_max;
return snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV,
- card->dev, size, size);
+ rtd->platform->dev,
+ size, size);
}
static void mtk_afe_pcm_free(struct snd_pcm *pcm)
--
2.17.0
On Wed, Feb 28, 2018 at 1:12 PM, Olof's autobuilder <build(a)lixom.net> wrote:
> Here are the build results from automated periodic testing.
> Warnings:
>
> arm64.allmodconfig:
> WARNING: modpost: missing MODULE_LICENSE() in drivers/phy/qualcomm/phy-qcom-ufs.o
Hi Greg,
It seems we're still missing one backport for a clean allmodconfig build:
59fba0869aca phy: qcom-ufs: add MODULE_LICENSE tag
Arnd
Dear Greg,
a fix for a voltage instability on our rk3399-puma board went into 4.15
(commit 87eba0716011, quoted below). As we have users who prefer to stay
on longterm 4.14, would you consider cherry-picking the commit into
4.14.y? It applies cleanly and has no effect outside of our rk3399-puma
board, where it fixes the instability.
Thank you and best regards,
Jakob
> commit 87eba0716011e528f7841026f2cc65683219d0ad
> Author: Klaus Goger <klaus.goger(a)theobroma-systems.com>
> Date: Tue Dec 5 08:11:58 2017 +0100
>
> arm64: dts: rockchip: remove vdd_log from rk3399-puma
>
> vdd_log has no consumer and therefore will not be set to a specific
> voltage. Still the PWM output pin gets configured and thence the vdd_log
> output voltage will changed from it's default. Depending on the idle
> state of the PWM this will slightly over or undervoltage the logic supply
> of the RK3399 and cause instability with GbE (undervoltage) and PCIe
> (overvoltage). Since the default value set by a voltage divider is the
> correct supply voltage and we don't need to change it during runtime we
> remove the rail from the devicetree completely so the PWM pin will not
> be configured.
>
> Signed-off-by: Klaus Goger <klaus.goger(a)theobroma-systems.com>
> Signed-off-by: Heiko Stuebner <heiko(a)sntech.de>
>
> arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi | 11 -----------
> 1 file changed, 11 deletions(-)
From: Robert Kolchmeyer <rkolchmeyer(a)google.com>
BugLink: http://bugs.launchpad.net/bugs/1765564
fsnotify() acquires a reference to a fsnotify_mark_connector through
the SRCU-protected pointer to_tell->i_fsnotify_marks. However, it
appears that no precautions are taken in fsnotify_put_mark() to
ensure that fsnotify() drops its reference to this
fsnotify_mark_connector before assigning a value to its 'destroy_next'
field. This can result in fsnotify_put_mark() assigning a value
to a connector's 'destroy_next' field right before fsnotify() tries to
traverse the linked list referenced by the connector's 'list' field.
Since these two fields are members of the same union, this behavior
results in a kernel panic.
This issue is resolved by moving the connector's 'destroy_next' field
into the object pointer union. This should work since the object pointer
access is protected by both a spinlock and the value of the 'flags'
field, and the 'flags' field is cleared while holding the spinlock in
fsnotify_put_mark() before 'destroy_next' is updated. It shouldn't be
possible for another thread to accidentally read from the object pointer
after the 'destroy_next' field is updated.
The offending behavior here is extremely unlikely; since
fsnotify_put_mark() removes references to a connector (specifically,
it ensures that the connector is unreachable from the inode it was
formerly attached to) before updating its 'destroy_next' field, a
sizeable chunk of code in fsnotify_put_mark() has to execute in the
short window between when fsnotify() acquires the connector reference
and saves the value of its 'list' field. On the HEAD kernel, I've only
been able to reproduce this by inserting a udelay(1) in fsnotify().
However, I've been able to reproduce this issue without inserting a
udelay(1) anywhere on older unmodified release kernels, so I believe
it's worth fixing at HEAD.
References: https://bugzilla.kernel.org/show_bug.cgi?id=199437
Fixes: 08991e83b7286635167bab40927665a90fb00d81
CC: stable(a)vger.kernel.org
Signed-off-by: Robert Kolchmeyer <rkolchmeyer(a)google.com>
Signed-off-by: Jan Kara <jack(a)suse.cz>
(cherry picked from commit d90a10e2444ba5a351fa695917258ff4c5709fa5)
Signed-off-by: Seyeong Kim <seyeong.kim(a)canonical.com>
---
include/linux/fsnotify_backend.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
index 067d52e..d719194 100644
--- a/include/linux/fsnotify_backend.h
+++ b/include/linux/fsnotify_backend.h
@@ -217,12 +217,10 @@ struct fsnotify_mark_connector {
union { /* Object pointer [lock] */
struct inode *inode;
struct vfsmount *mnt;
- };
- union {
- struct hlist_head list;
/* Used listing heads to free after srcu period expires */
struct fsnotify_mark_connector *destroy_next;
};
+ struct hlist_head list;
};
/*
--
2.7.4
From: Sean Wang <sean.wang(a)mediatek.com>
Recently kernelCI reported the board mt7622-rfb1 has a fail test with
kernel: ERROR: did not start booting whose details could be seen at [1].
The cause is that UART0 can't output anything when it's missing a proper
pin setup with current DTS, so the essential driver is always getting
enabled to fix up the issue.
[1] https://kernelci.org/boot/id/5ad7d62759b51461bfb1f829/
Cc: Kevin Hilman <khilman(a)baylibre.com>
Cc: stable(a)vger.kernel.org
Fixes: ae457b7679c4 ("arm64: dts: mt7622: add SoC and peripheral related device nodes")
Signed-off-by: Sean Wang <sean.wang(a)mediatek.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ecf6137..fe005df 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -320,6 +320,7 @@ CONFIG_PINCTRL_MAX77620=y
CONFIG_PINCTRL_MSM8916=y
CONFIG_PINCTRL_MSM8994=y
CONFIG_PINCTRL_MSM8996=y
+CONFIG_PINCTRL_MT7622=y
CONFIG_PINCTRL_QDF2XXX=y
CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
CONFIG_GPIO_DWAPB=y
--
2.7.4
Hi Greg,
Upstream commit 821cdad5c46c ("PCI: Wait up to 60 seconds for
device to become ready after FLR") fixes a virtualization issue
for Intel 750 NVMe drive and potentially other PCIe devices taking
longer to recover from functional resets.
problem description below from the commit:
'Sporadic reset issues have been observed with an Intel 750 NVMe drive while
assigning the physical function to the guest machine. The sequence of
events observed is as follows:
- perform a Function Level Reset (FLR)
- sleep up to 1000ms total
- read ~0 from PCI_COMMAND (CRS completion for config read)
- warn that the device didn't return from FLR
- touch the device before it's ready
- device drops config writes when we restore register settings (there's
no mechanism for software to learn about CRS completions for writes)
- incomplete register restore leaves device in inconsistent state
- device probe fails because device is in inconsistent state
After reset, an endpoint may respond to config requests with Configuration
Request Retry Status (CRS) to indicate that it is not ready to accept new
requests. See PCIe r3.1, sec 2.3.1 and 6.6.2.'
Please apply commit 821cdad5c46c to fix the resulting regression.
Thanks,
Sinan
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Memory hotplug, and hotremove operate with per-block granularity. If
machine has large amount of memory (more than 64G), the size of memory
block can span multiple sections. By mistake, during hotremove we set
only the first section to offline state.
The bug was discovered because kernel selftest started to fail:
https://lkml.kernel.org/r/20180423011247.GK5563@yexl-desktop
After commit, "mm/memory_hotplug: optimize probe routine". But, the bug is
older than this commit. In this optimization we also added a check for
sections to be in a proper state during hotplug operation.
Fixes: 2d070eab2e82 ("mm: consider zone which is not fully populated to have holes")
Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Acked-by: Michal Hocko <mhocko(a)suse.com>
---
mm/sparse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/sparse.c b/mm/sparse.c
index 62eef264a7bd..73dc2fcc0eab 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -629,7 +629,7 @@ void offline_mem_sections(unsigned long start_pfn, unsigned long end_pfn)
unsigned long pfn;
for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
- unsigned long section_nr = pfn_to_section_nr(start_pfn);
+ unsigned long section_nr = pfn_to_section_nr(pfn);
struct mem_section *ms;
/*
--
2.17.0
Add support to specify platform specific transition_delay_us instead
of using the transition delay derived from PCC.
With commit "3d41386d556d: cpufreq: CPPC: Use transition_delay_us
depending transition_latency" we are setting transition_delay_us
directly and not applying the LATENCY_MULTIPLIER. With this on Qualcomm
Centriq we can end up with a very high rate of frequency change requests
when using schedutil governor (default rate_limit_us=10 compared to an
earlier value of 10000).
The PCC subspace describes the rate at which the platform can accept
commands on the CPPC's PCC channel. This includes read and write
command on the PCC channel that can be used for reasons other than
frequency transitions. Moreover the same PCC subspace can be used by
multiple freq domains and deriving transition_delay_us from it as we do
now can be sub-optimal.
Moreover if a platform does not use PCC for desired_perf register then
there is no way to compute the transition latency or the delay_us.
CPPC does not have a standard defined mechanism to get the transition
rate or the latency at the moment.
Given the above limitations, it is simpler to have a platform specific
transition_delay_us and rely on PCC derived value only if a platform
specific value is not available.
Signed-off-by: Prashanth Prakash <pprakash(a)codeaurora.org>
Cc: Viresh Kumar <viresh.kumar(a)linaro.org>
Cc: Rafael J. Wysocki <rjw(a)rjwysocki.net>
Cc: 4.14+ <stable(a)vger.kernel.org>
Fixes: 3d41386d556d ("cpufreq: CPPC: Use transition_delay_us depending
transition_latency)
---
v2:
* Return final delay_us from cppc_cpufreq_get_transition_delay_us (Viresh)
---
drivers/cpufreq/cppc_cpufreq.c | 43 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
index bc5fc16..b1e32ad 100644
--- a/drivers/cpufreq/cppc_cpufreq.c
+++ b/drivers/cpufreq/cppc_cpufreq.c
@@ -126,6 +126,46 @@ static void cppc_cpufreq_stop_cpu(struct cpufreq_policy *policy)
cpu->perf_caps.lowest_perf, cpu_num, ret);
}
+/*
+ * The PCC subspace describes the rate at which platform can accept commands
+ * on the shared PCC channel (including READs which do not count towards freq
+ * trasition requests), so ideally we need to use the PCC values as a fallback
+ * if we don't have a platform specific transition_delay_us
+ */
+#if defined(CONFIG_ARM64)
+#include <asm/cputype.h>
+
+static unsigned int cppc_cpufreq_get_transition_delay_us(int cpu)
+{
+ unsigned long implementor = read_cpuid_implementor();
+ unsigned long part_num = read_cpuid_part_number();
+ unsigned int delay_us = 0;
+
+ switch (implementor) {
+ case ARM_CPU_IMP_QCOM:
+ switch (part_num) {
+ case QCOM_CPU_PART_FALKOR_V1:
+ case QCOM_CPU_PART_FALKOR:
+ delay_us = 10000;
+ break;
+ }
+ break;
+ }
+
+ if (!delay_us)
+ delay_us = cppc_get_transition_latency(cpu) / NSEC_PER_USEC;
+
+ return delay_us;
+}
+
+#else
+
+static unsigned int cppc_cpufreq_get_transition_delay_us(int cpu)
+{
+ return cppc_get_transition_latency(cpu) / NSEC_PER_USEC;
+}
+#endif
+
static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
struct cppc_cpudata *cpu;
@@ -162,8 +202,7 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
cpu->perf_caps.highest_perf;
policy->cpuinfo.max_freq = cppc_dmi_max_khz;
- policy->transition_delay_us = cppc_get_transition_latency(cpu_num) /
- NSEC_PER_USEC;
+ policy->transition_delay_us = cppc_cpufreq_get_transition_delay_us(cpu_num);
policy->shared_type = cpu->shared_type;
if (policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) {
--
Qualcomm Datacenter Technologies on behalf of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
Richard Jones has reported that using med_power_with_dipm on a T450s
with a Sandisk SD7UB3Q256G1001 SSD (firmware version X2180501) is
causing the machine to hang.
Switching the LPM to max_performance fixes this, so it seems that
this Sandisk SSD does not handle LPM well.
Note in the past there have been bug-reports about the following
Sandisk models not working with min_power, so we may need to extend
the quirk list in the future: name - firmware
Sandisk SD6SB2M512G1022I - X210400
Sandisk SD6PP4M-256G-1006 - A200906
Cc: stable(a)vger.kernel.org
Cc: Richard W.M. Jones <rjones(a)redhat.com>
Reported-and-tested-by: Richard W.M. Jones <rjones(a)redhat.com>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/ata/libata-core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 6e400ff2b5db..68596bd4cf06 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4552,6 +4552,9 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
/* This specific Samsung model/firmware-rev does not handle LPM well */
{ "SAMSUNG MZMPC128HBFU-000MV", "CXM14M1Q", ATA_HORKAGE_NOLPM, },
+ /* Sandisk devices which are known to not handle LPM well */
+ { "SanDisk SD7UB3Q*G1001", NULL, ATA_HORKAGE_NOLPM, },
+
/* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
--
2.17.0
Please add this patch to stable 4.14
commit f54450ad1942287cc76b38021c0441fc4901d2de
Author: Kees Cook <keescook(a)chromium.org>
Date: Tue Feb 27 13:11:21 2018 -0800
console: Drop added "static" for newport_con
Commit 4fe505119778 ("console: Expand dummy functions for CFI") accidentally
added "static" to newport_con instance of struct consw, while trying to
normalize the declarations. This, however, needed to stay non-static as it
has an extern.
Reported-by: kbuild test robot <fengguang.wu(a)intel.com>
Fixes: 4fe505119778 ("console: Expand dummy functions for CFI")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>