This is a note to let you know that I've just added the patch titled
x86/spectre: Fix an error message
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-spectre-fix-an-error-message.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 9de29eac8d2189424d81c0d840cd0469aa3d41c8 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Wed, 14 Feb 2018 10:14:17 +0300
Subject: x86/spectre: Fix an error message
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 9de29eac8d2189424d81c0d840cd0469aa3d41c8 upstream.
If i == ARRAY_SIZE(mitigation_options) then we accidentally print
garbage from one space beyond the end of the mitigation_options[] array.
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bp(a)suse.de>
Cc: David Woodhouse <dwmw(a)amazon.co.uk>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: KarimAllah Ahmed <karahmed(a)amazon.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: kernel-janitors(a)vger.kernel.org
Fixes: 9005c6834c0f ("x86/spectre: Simplify spectre_v2 command line parsing")
Link: http://lkml.kernel.org/r/20180214071416.GA26677@mwanda
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/bugs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -175,8 +175,7 @@ static enum spectre_v2_mitigation_cmd __
}
if (i >= ARRAY_SIZE(mitigation_options)) {
- pr_err("unknown option (%s). Switching to AUTO select\n",
- mitigation_options[i].option);
+ pr_err("unknown option (%s). Switching to AUTO select\n", arg);
return SPECTRE_V2_CMD_AUTO;
}
}
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.4/x86-spectre-fix-an-error-message.patch
This reverts commit 20ac8f72514b3af8b62c520d55656ded865eff00, which
was commit 2b83ff96f51d0b039c4561b9f95c824d7bddb85c upstream.
The bug that it should fix was only introduced in Linux 4.7, and
in 4.4 it causes a regression.
Reported-by: Jacek Anaszewski <jacek.anaszewski(a)gmail.com>
Cc: Matthieu CASTET <matthieu.castet(a)parrot.com>
Signed-off-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
---
drivers/leds/led-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 92b6798ef5b3..c1c3af089634 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -149,7 +149,7 @@ void led_blink_set(struct led_classdev *led_cdev,
unsigned long *delay_on,
unsigned long *delay_off)
{
- led_stop_software_blink(led_cdev);
+ del_timer_sync(&led_cdev->blink_timer);
led_cdev->flags &= ~LED_BLINK_ONESHOT;
led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP;
--
2.15.0.rc0
Please pick this fix for 4.4-stable:
commit 9de29eac8d2189424d81c0d840cd0469aa3d41c8
Author: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Wed Feb 14 10:14:17 2018 +0300
x86/spectre: Fix an error message
(It has already been applied to your later branches.)
Ben.
--
Ben Hutchings
Software Developer, Codethink Ltd.
2018-03-08 16:09 GMT+09:00 James Hogan <jhogan(a)kernel.org>:
> On Wed, Mar 07, 2018 at 03:19:11PM -0800, Frank Rowand wrote:
>> On 03/07/18 12:25, James Hogan wrote:
>> > On Wed, Mar 07, 2018 at 12:11:41PM -0800, Frank Rowand wrote:
>> >> On 03/07/18 06:06, James Hogan wrote:
>> >>> Quite a lot of dts files have hyphens, but its only a problem on MIPS
>> >>> where such files can be built into the kernel. For example when
>> >>> CONFIG_DT_NETGEAR_CVG834G=y, or on BMIPS kernels when the dtbs target is
>> >>> used (in the latter case it admitedly shouldn't really build all the
>> >>> dtb.o files, but thats a separate issue).
>
>> > I'll keep the paragraph about MIPS and the example configuration though,
>> > as I think its important information to reproduce the problem, and to
>> > justify why it wouldn't be appropriate to just rename the files (which
>> > was my first reaction).
>>
>> Other than the part that says "its only a problem on MIPS". That is
>> pedantically correct because no other architecture (that I am aware
>> of, not that I searched) currently has a devicetree source file name
>> with a hyphen in it, where that file is compiled into the kernel as
>> an asm file. But it is potentially a problem on any architecture
>> to it is misleading to label it as MIPS only.
>
> Okay I'll reword to make it clearer and do a v2.
>
> Thanks
> James
The code looks good.
If you send v2, I can shortly apply it to the fixes branch.
If possible, I want to send a PR this weekend.
--
Best Regards
Masahiro Yamada
While UBI and UBIFS seem to work at first sight with MLC NAND, you will
most likely lose all your data upon a power-cut or due to read/write
disturb.
In order to protect users from bad surprises, refuse to attach to MLC
NAND.
Cc: stable(a)vger.kernel.org
Signed-off-by: Richard Weinberger <richard(a)nod.at>
---
drivers/mtd/ubi/build.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c
index e941395de3ae..753494e042d5 100644
--- a/drivers/mtd/ubi/build.c
+++ b/drivers/mtd/ubi/build.c
@@ -854,6 +854,17 @@ int ubi_attach_mtd_dev(struct mtd_info *mtd, int ubi_num,
return -EINVAL;
}
+ /*
+ * Both UBI and UBIFS have been designed for SLC NAND and NOR flashes.
+ * MLC NAND is different and needs special care, otherwise UBI or UBIFS
+ * will die soon and you will lose all your data.
+ */
+ if (mtd->type == MTD_MLCNANDFLASH) {
+ pr_err("ubi: refuse attaching mtd%d - MLC NAND is not supported\n",
+ mtd->index);
+ return -EINVAL;
+ }
+
if (ubi_num == UBI_DEV_NUM_AUTO) {
/* Search for an empty slot in the @ubi_devices array */
for (ubi_num = 0; ubi_num < UBI_MAX_DEVICES; ubi_num++)
--
2.13.6
PARTITION_CONFIG is cached in mmc_card->ext_csd.part_config and the
currently active partition in mmc_blk_data->part_curr. These caches do
not always reflect changes if the ioctl call modifies the
PARTITION_CONFIG registers, e.g. by changing BOOT_PARTITION_ENABLE.
Write the PARTITION_CONFIG value extracted from the ioctl call to the
cache and update the currently active partition accordingly. This
ensures that the user space cannot change the values behind the
kernel's back. The next call to mmc_blk_part_switch() will operate on
the data set by the ioctl and reflect the changes appropriately.
Signed-off-by: Bastian Stender <bst(a)pengutronix.de>
Signed-off-by: Jan Luebbe <jlu(a)pengutronix.de>
Cc: stable(a)vger.kernel.org
---
drivers/mmc/core/block.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 20135a5de748..2cfb963d9f37 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -72,6 +72,7 @@ MODULE_ALIAS("mmc:block");
#define MMC_BLK_TIMEOUT_MS (10 * 1000)
#define MMC_SANITIZE_REQ_TIMEOUT 240000
#define MMC_EXTRACT_INDEX_FROM_ARG(x) ((x & 0x00FF0000) >> 16)
+#define MMC_EXTRACT_VALUE_FROM_ARG(x) ((x & 0x0000FF00) >> 8)
#define mmc_req_rel_wr(req) ((req->cmd_flags & REQ_FUA) && \
(rq_data_dir(req) == WRITE))
@@ -586,6 +587,24 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data *md,
return data.error;
}
+ /*
+ * Make sure the cache of the PARTITION_CONFIG register and
+ * PARTITION_ACCESS bits is updated in case the ioctl ext_csd write
+ * changed it successfully.
+ */
+ if ((MMC_EXTRACT_INDEX_FROM_ARG(cmd.arg) == EXT_CSD_PART_CONFIG) &&
+ (cmd.opcode == MMC_SWITCH)) {
+ struct mmc_blk_data *main_md = dev_get_drvdata(&card->dev);
+ u8 value = MMC_EXTRACT_VALUE_FROM_ARG(cmd.arg);
+
+ /*
+ * Update cache so the next mmc_blk_part_switch call operates
+ * on up-to-date data.
+ */
+ card->ext_csd.part_config = value;
+ main_md->part_curr = value & EXT_CSD_PART_CONFIG_ACC_MASK;
+ }
+
/*
* According to the SD specs, some commands require a delay after
* issuing the command.
--
2.16.1
This is a note to let you know that I've just added the patch titled
usb: dwc3: Fix lock-up on ID change during system suspend/resume
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus 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 hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 084a804e01205bcd74cd0849bc72cb5c88f8e648 Mon Sep 17 00:00:00 2001
From: Roger Quadros <rogerq(a)ti.com>
Date: Tue, 27 Feb 2018 12:41:41 +0200
Subject: usb: dwc3: Fix lock-up on ID change during system suspend/resume
To reproduce the lock up do the following
- connect otg host adapter and a USB device to the dual-role port
so that it is in host mode.
- suspend to mem.
- disconnect otg adapter.
- resume the system.
If we call dwc3_host_exit() before tasks are thawed
xhci_plat_remove() seems to lock up at the second usb_remove_hcd() call.
To work around this we queue the _dwc3_set_mode() work on
the system_freezable_wq.
Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly")
Cc: <stable(a)vger.kernel.org> # v4.12+
Suggested-by: Manu Gautam <mgautam(a)codeaurora.org>
Signed-off-by: Roger Quadros <rogerq(a)ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
---
drivers/usb/dwc3/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index f1d838a4acd6..e94bf91cc58a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -175,7 +175,7 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
dwc->desired_dr_role = mode;
spin_unlock_irqrestore(&dwc->lock, flags);
- queue_work(system_power_efficient_wq, &dwc->drd_work);
+ queue_work(system_freezable_wq, &dwc->drd_work);
}
u32 dwc3_core_fifo_space(struct dwc3_ep *dep, u8 type)
--
2.16.2
On Wed, Mar 07, 2018 at 09:29:10PM +0100, Nikola Ciprich wrote:
> Hi,
>
> > > > I'd like to report that when upgrading our cluster from 4.14.18 to
> > > > 4.14.24-rc1 (with live guests migration), almost none of guests survived..
> > > What's your hardware setup, intel with IBPB enabled microcode?
> > Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz
> >
> > therefore I suppose no IBPB (at least meltdown checker reports so)
> >
> >
> > > Does guests hang right after live migration?
> > yes, just tried it.
> >
> >
> > >
> > > Are you able to reproduce the problem, does it work with latest upstream?
> > yup, so I'm able to reproduce quickly. I'll revert the cluster to 4.14.18 now,
> > but setup test system just afterwards, so and test the patch you've proposed.
> >
> > >
> > > Not sure it helps, but following patch is missing in 4.14.24
> > >
> > > commit 37b95951c58fdf08dc10afa9d02066ed9f176fb5 upstream.
> > >
> > > kvm_valid_sregs() should use X86_CR0_PG and X86_CR4_PAE to check bit
> > > status rather than X86_CR0_PG_BIT and X86_CR4_PAE_BIT. This patch is
> > > to fix it.
> > >
> > > Fixes: f29810335965a(KVM/x86: Check input paging mode when cs.l is set)
> > > Reported-by: Jeremi Piotrowski <jeremi.piotrowski(a)gmail.com>
> > > Cc: Paolo Bonzini <pbonzini(a)redhat.com>
> > > Cc: Radim Krčmář <rkrcmar(a)redhat.com>
> > > Signed-off-by: Tianyu Lan <Tianyu.Lan(a)microsoft.com>
> > > Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
> >
> > I'll test and report.
>
> so indeed, this one on top of 4.14.24-rc1 fixes the migration for me.
> Greg, could you queue this one up please?
As was already pointed out, this is already queued up to be in the next
release.
thanks,
greg k-h