From: Aleksandr Yashkin <a.yashkin(a)inango-systems.com>
[ Upstream commit 9e5f1c19800b808a37fb9815a26d382132c26c3d ]
The ram_core.c routines treat przs as circular buffers. When writing a
new crash dump, the old buffer needs to be cleared so that the new dump
doesn't end up in the wrong place (i.e. at the end).
The solution to this problem is to reset the circular buffer state before
writing a new Oops dump.
Signed-off-by: Aleksandr Yashkin <a.yashkin(a)inango-systems.com>
Signed-off-by: Nikolay Merinov <n.merinov(a)inango-systems.com>
Signed-off-by: Ariel Gilman <a.gilman(a)inango-systems.com>
Link: https://lore.kernel.org/r/20191223133816.28155-1-n.merinov@inango-systems.c…
Fixes: 896fc1f0c4c6 ("pstore/ram: Switch to persistent_ram routines")
[kees: backport to v4.9]
Signed-off-by: Kees Cook <keescook(a)chromium.org>
---
fs/pstore/ram.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 59d93acc29c7..fa0e89edb62d 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -319,6 +319,17 @@ static int notrace ramoops_pstore_write_buf(enum pstore_type_id type,
prz = cxt->przs[cxt->dump_write_cnt];
+ /*
+ * Since this is a new crash dump, we need to reset the buffer in
+ * case it still has an old dump present. Without this, the new dump
+ * will get appended, which would seriously confuse anything trying
+ * to check dump file contents. Specifically, ramoops_read_kmsg_hdr()
+ * expects to find a dump header in the beginning of buffer data, so
+ * we must to reset the buffer values, in order to ensure that the
+ * header will be written to the beginning of the buffer.
+ */
+ persistent_ram_zap(prz);
+
hlen = ramoops_write_kmsg_hdr(prz, compressed);
if (size + hlen > prz->buffer_size)
size = prz->buffer_size - hlen;
--
2.20.1
--
Kees Cook
On Sat, 2020-01-25 at 22:16 -0500, Woody Suwalski wrote:
> Trying to use an AMD64 3.16 kernel built on a new Debian system fails
> because
> most of the kernel modules can not be loaded.
I don't recommend using the latest toolchain for 3.16 (certainly gcc 9
won't work). But I will apply this since it's such a simple fix.
Thanks for the backport.
Ben.
> This patch handles the PLT32 relocation errors for kernels modules built
> with binutils
> newer then 2.31, similar to:
> [ 5.742485] module: autofs4: Unknown rela relocation: 4
> [ 5.742536] systemd[1]: Failed to insert module 'autofs4': Exec
> format error
>
> This patch is based on a mainline kernel patch
> b21ebf2fb4cde1618915a97cc773e287ff49173e
> From: "H.J. Lu" <hjl.tools(a)gmail.com>
> Date: Wed, 7 Feb 2018 14:20:09 -0800
> Subject: x86: Treat R_X86_64_PLT32 as R_X86_64_PC32
>
> Signed-off-by: Woody Suwalski <terraluna977(a)gmail.com>
>
> --- a/arch/x86/tools/relocs.c 2020-01-24 18:48:09.477919152 -0500
> +++ b/arch/x86/tools/relocs.c 2020-01-24 18:48:53.645612045 -0500
> @@ -763,6 +763,7 @@ static int do_reloc64(struct section *se
> switch (r_type) {
> case R_X86_64_NONE:
> case R_X86_64_PC32:
> + case R_X86_64_PLT32:
> /*
> * NONE can be ignored and PC relative relocations don't
> * need to be adjusted.
> --- a/arch/x86/kernel/module.c 2020-01-24 18:46:54.922670590 -0500
> +++ b/arch/x86/kernel/module.c 2020-01-24 18:47:46.714112016 -0500
> @@ -180,6 +180,7 @@ int apply_relocate_add(Elf64_Shdr *sechd
> goto overflow;
> break;
> case R_X86_64_PC32:
> + case R_X86_64_PLT32:
> val -= (u64)loc;
> *(u32 *)loc = val;
> #if 0
>
--
Ben Hutchings
The program is absolutely right; therefore, the computer must be wrong.
On devices with an AXP288, we need to wakeup from suspend when a charger
is plugged in, so that we can do charger-type detection and so that the
axp288-charger driver, which listens for our extcon events, can configure
the input-current-limit accordingly.
Cc: stable(a)vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/extcon/extcon-axp288.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
index a7f216191493..710a3bb66e95 100644
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -443,9 +443,40 @@ static int axp288_extcon_probe(struct platform_device *pdev)
/* Start charger cable type detection */
axp288_extcon_enable(info);
+ device_init_wakeup(dev, true);
+ platform_set_drvdata(pdev, info);
+
+ return 0;
+}
+
+static int __maybe_unused axp288_extcon_suspend(struct device *dev)
+{
+ struct axp288_extcon_info *info = dev_get_drvdata(dev);
+
+ if (device_may_wakeup(dev))
+ enable_irq_wake(info->irq[VBUS_RISING_IRQ]);
+
return 0;
}
+static int __maybe_unused axp288_extcon_resume(struct device *dev)
+{
+ struct axp288_extcon_info *info = dev_get_drvdata(dev);
+
+ /*
+ * Wakeup when a charger is connected to do charger-type
+ * connection and generate an extcon event which makes the
+ * axp288 charger driver set the input current limit.
+ */
+ if (device_may_wakeup(dev))
+ disable_irq_wake(info->irq[VBUS_RISING_IRQ]);
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(axp288_extcon_pm_ops, axp288_extcon_suspend,
+ axp288_extcon_resume);
+
static const struct platform_device_id axp288_extcon_table[] = {
{ .name = "axp288_extcon" },
{},
@@ -457,6 +488,7 @@ static struct platform_driver axp288_extcon_driver = {
.id_table = axp288_extcon_table,
.driver = {
.name = "axp288_extcon",
+ .pm = &axp288_extcon_pm_ops,
},
};
--
2.24.1
Hi,
On 26-01-2020 02:38, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.4.14, v4.19.98, v4.14.167, v4.9.211, v4.4.211.
>
> v5.4.14: Build OK!
> v4.19.98: Build OK!
> v4.14.167: Failed to apply! Possible dependencies:
> 38d9c12c0a6d ("ALSA: hda: Add Gigabyte P55A-UD3 and Z87-D3HP to the power_save blacklist")
> 5cb6b5fc013e ("ALSA: hda: Add 2 more models to the power_save blacklist")
> b529ef2464ad ("ALSA: hda: Add Clevo W35xSS_370SS to the power_save blacklist")
> dd6dd5365404 ("ALSA: hda: Add Intel NUC7i3BNB to the power_save blacklist")
> f91f1806530d ("ALSA: hda: Add Intel NUC5i7RY to the power_save blacklist")
>
> v4.9.211: Failed to apply! Possible dependencies:
> 38d9c12c0a6d ("ALSA: hda: Add Gigabyte P55A-UD3 and Z87-D3HP to the power_save blacklist")
> 5cb6b5fc013e ("ALSA: hda: Add 2 more models to the power_save blacklist")
> b529ef2464ad ("ALSA: hda: Add Clevo W35xSS_370SS to the power_save blacklist")
> dd6dd5365404 ("ALSA: hda: Add Intel NUC7i3BNB to the power_save blacklist")
> f91f1806530d ("ALSA: hda: Add Intel NUC5i7RY to the power_save blacklist")
>
> v4.4.211: Failed to apply! Possible dependencies:
> 38d9c12c0a6d ("ALSA: hda: Add Gigabyte P55A-UD3 and Z87-D3HP to the power_save blacklist")
> 5cb6b5fc013e ("ALSA: hda: Add 2 more models to the power_save blacklist")
> b529ef2464ad ("ALSA: hda: Add Clevo W35xSS_370SS to the power_save blacklist")
> dd6dd5365404 ("ALSA: hda: Add Intel NUC7i3BNB to the power_save blacklist")
> f91f1806530d ("ALSA: hda: Add Intel NUC5i7RY to the power_save blacklist")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
Just adding it to 4.19.98 and 5.4 (and 5.5) is fine.
Regards,
Hans
Using HDA power-saving on the Clevo W65_67SB causes the first 0.5
seconds of audio to be missing every time audio starts playing.
This commit adds the Clevo W65_67SB the power_save blacklist to avoid
this issue.
Cc: stable(a)vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1525104
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
sound/pci/hda/hda_intel.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 5b92f290cbb0..54d9ea1750f9 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2185,6 +2185,8 @@ static struct snd_pci_quirk power_save_blacklist[] = {
/* https://bugzilla.redhat.com/show_bug.cgi?id=1581607 */
SND_PCI_QUIRK(0x1558, 0x3501, "Clevo W35xSS_370SS", 0),
/* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
+ SND_PCI_QUIRK(0x1558, 0x6504, "Clevo W65_67SB", 0),
+ /* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
SND_PCI_QUIRK(0x1028, 0x0497, "Dell Precision T3600", 0),
/* https://bugzilla.redhat.com/show_bug.cgi?id=1525104 */
/* Note the P55A-UD3 and Z87-D3HP share the subsys id for the HDA dev */
--
2.23.0
This is a note to let you know that I've just added the patch titled
mei: me: add jasper point DID
to my char-misc git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
in the char-misc-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From 0db4a15d4c2787b1112001790d4f95bd2c5fed6f Mon Sep 17 00:00:00 2001
From: Tomas Winkler <tomas.winkler(a)intel.com>
Date: Fri, 24 Jan 2020 02:14:55 +0200
Subject: mei: me: add jasper point DID
Add Jasper Point (Jasper Lake) device id for MEI
Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com>
Cc: stable <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20200124001455.24176-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/mei/hw-me-regs.h | 2 ++
drivers/misc/mei/pci-me.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/misc/mei/hw-me-regs.h b/drivers/misc/mei/hw-me-regs.h
index 9d24db38e8bc..87a0201ba6b3 100644
--- a/drivers/misc/mei/hw-me-regs.h
+++ b/drivers/misc/mei/hw-me-regs.h
@@ -89,6 +89,8 @@
#define MEI_DEV_ID_ICP_LP 0x34E0 /* Ice Lake Point LP */
+#define MEI_DEV_ID_JSP_N 0x4DE0 /* Jasper Lake Point N */
+
#define MEI_DEV_ID_TGP_LP 0xA0E0 /* Tiger Lake Point LP */
#define MEI_DEV_ID_MCC 0x4B70 /* Mule Creek Canyon (EHL) */
diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
index c14261d735db..2711451b3d87 100644
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -106,6 +106,8 @@ static const struct pci_device_id mei_me_pci_tbl[] = {
{MEI_PCI_DEVICE(MEI_DEV_ID_TGP_LP, MEI_ME_PCH15_CFG)},
+ {MEI_PCI_DEVICE(MEI_DEV_ID_JSP_N, MEI_ME_PCH15_CFG)},
+
{MEI_PCI_DEVICE(MEI_DEV_ID_MCC, MEI_ME_PCH15_CFG)},
{MEI_PCI_DEVICE(MEI_DEV_ID_MCC_4, MEI_ME_PCH8_CFG)},
--
2.25.0
From: Tianyu Lan <Tianyu.Lan(a)microsoft.com>
Current code has assumption that balloon request memory size aligns
with 2MB. But actually Hyper-V doesn't guarantee such alignment. When
balloon driver receives non-aligned balloon request, it produces warning
and balloon up more memory than requested in order to keep 2MB alignment.
Remove the warning and balloon up memory according to actual requested
memory size.
Fixes: f6712238471a ("hv: hv_balloon: avoid memory leak on alloc_error of 2MB memory block")
Cc: stable(a)vger.kernel.org
Reviewed-by: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Signed-off-by: Tianyu Lan <Tianyu.Lan(a)microsoft.com>
---
Change since v3:
- Revert optimization of swtiching alloc_unit
Change since v2:
- Remove check between request page number and alloc_unit
in the alloc_balloon_pages() because it's redundant with
new change.
- Remove the "continue" just follwoing alloc_unit switch
from 2MB to 4K in order to avoid skipping allocated
memory.
Change since v1:
- Change logic of switching alloc_unit from 2MB to 4KB
in the balloon_up() to avoid redundant iteration when
handle non-aligned page request.
- Remove 2MB alignment operation and comment in balloon_up()
---
drivers/hv/hv_balloon.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 7f3e7ab22d5d..a03c5191101e 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -1681,10 +1681,7 @@ static unsigned int alloc_balloon_pages(struct hv_dynmem_device *dm,
unsigned int i, j;
struct page *pg;
- if (num_pages < alloc_unit)
- return 0;
-
- for (i = 0; (i * alloc_unit) < num_pages; i++) {
+ for (i = 0; i < num_pages / alloc_unit; i++) {
if (bl_resp->hdr.size + sizeof(union dm_mem_page_range) >
HV_HYP_PAGE_SIZE)
return i * alloc_unit;
@@ -1722,7 +1719,7 @@ static unsigned int alloc_balloon_pages(struct hv_dynmem_device *dm,
}
- return num_pages;
+ return i * alloc_unit;
}
static void balloon_up(union dm_msg_info *msg_info)
@@ -1737,9 +1734,6 @@ static void balloon_up(union dm_msg_info *msg_info)
long avail_pages;
unsigned long floor;
- /* The host balloons pages in 2M granularity. */
- WARN_ON_ONCE(num_pages % PAGES_IN_2M != 0);
-
/*
* We will attempt 2M allocations. However, if we fail to
* allocate 2M chunks, we will go back to PAGE_SIZE allocations.
@@ -1749,14 +1743,13 @@ static void balloon_up(union dm_msg_info *msg_info)
avail_pages = si_mem_available();
floor = compute_balloon_floor();
- /* Refuse to balloon below the floor, keep the 2M granularity. */
+ /* Refuse to balloon below the floor. */
if (avail_pages < num_pages || avail_pages - num_pages < floor) {
pr_warn("Balloon request will be partially fulfilled. %s\n",
avail_pages < num_pages ? "Not enough memory." :
"Balloon floor reached.");
num_pages = avail_pages > floor ? (avail_pages - floor) : 0;
- num_pages -= num_pages % PAGES_IN_2M;
}
while (!done) {
--
2.14.5