This is a note to let you know that I've just added the patch titled
clocksource/drivers/stm32: Fix kernel panic with multiple timers
to the 4.14-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:
clocksource-drivers-stm32-fix-kernel-panic-with-multiple-timers.patch
and it can be found in the queue-4.14 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 e0aeca3d8cbaea514eb98df1149faa918f9ec42d Mon Sep 17 00:00:00 2001
From: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Date: Mon, 8 Jan 2018 14:28:50 +0100
Subject: clocksource/drivers/stm32: Fix kernel panic with multiple timers
From: Daniel Lezcano <daniel.lezcano(a)linaro.org>
commit e0aeca3d8cbaea514eb98df1149faa918f9ec42d upstream.
The current code hides a couple of bugs:
- The global variable 'clock_event_ddata' is overwritten each time the
init function is invoked.
This is fixed with a kmemdup() instead of assigning the global variable. That
prevents a memory corruption when several timers are defined in the DT.
- The clockevent's event_handler is NULL if the time framework does
not select the clockevent when registering it, this is fine but the init
code generates in any case an interrupt leading to dereference this
NULL pointer.
The stm32 timer works with shadow registers, a mechanism to cache the
registers. When a change is done in one buffered register, we need to
artificially generate an event to force the timer to copy the content
of the register to the shadowed register.
The auto-reload register (ARR) is one of the shadowed register as well as
the prescaler register (PSC), so in order to force the copy, we issue an
event which in turn leads to an interrupt and the NULL dereference.
This is fixed by inverting two lines where we clear the status register
before enabling the update event interrupt.
As this kernel crash is resulting from the combination of these two bugs,
the fixes are grouped into a single patch.
Tested-by: Benjamin Gaignard <benjamin.gaignard(a)st.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Acked-by: Benjamin Gaignard <benjamin.gaignard(a)st.com>
Cc: Alexandre Torgue <alexandre.torgue(a)st.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Maxime Coquelin <mcoquelin.stm32(a)gmail.com>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/1515418139-23276-11-git-send-email-daniel.lezcano@…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clocksource/timer-stm32.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -106,6 +106,10 @@ static int __init stm32_clockevent_init(
unsigned long rate, max_delta;
int irq, ret, bits, prescaler = 1;
+ data = kmemdup(&clock_event_ddata, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
clk = of_clk_get(np, 0);
if (IS_ERR(clk)) {
ret = PTR_ERR(clk);
@@ -156,8 +160,8 @@ static int __init stm32_clockevent_init(
writel_relaxed(prescaler - 1, data->base + TIM_PSC);
writel_relaxed(TIM_EGR_UG, data->base + TIM_EGR);
- writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
writel_relaxed(0, data->base + TIM_SR);
+ writel_relaxed(TIM_DIER_UIE, data->base + TIM_DIER);
data->periodic_top = DIV_ROUND_CLOSEST(rate, prescaler * HZ);
@@ -184,6 +188,7 @@ err_iomap:
err_clk_enable:
clk_put(clk);
err_clk_get:
+ kfree(data);
return ret;
}
Patches currently in stable-queue which might be from daniel.lezcano(a)linaro.org are
queue-4.14/clocksource-drivers-stm32-fix-kernel-panic-with-multiple-timers.patch
This is a note to let you know that I've just added the patch titled
Btrfs: raid56: iterate raid56 internal bio with bio_for_each_segment_all
to the 4.14-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:
btrfs-raid56-iterate-raid56-internal-bio-with-bio_for_each_segment_all.patch
and it can be found in the queue-4.14 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 0198e5b707cfeb5defbd1b71b1ec6e71580d7db9 Mon Sep 17 00:00:00 2001
From: Liu Bo <bo.li.liu(a)oracle.com>
Date: Fri, 12 Jan 2018 18:07:01 -0700
Subject: Btrfs: raid56: iterate raid56 internal bio with bio_for_each_segment_all
From: Liu Bo <bo.li.liu(a)oracle.com>
commit 0198e5b707cfeb5defbd1b71b1ec6e71580d7db9 upstream.
Bio iterated by set_bio_pages_uptodate() is raid56 internal one, so it
will never be a BIO_CLONED bio, and since this is called by end_io
functions, bio->bi_iter.bi_size is zero, we mustn't use
bio_for_each_segment() as that is a no-op if bi_size is zero.
Fixes: 6592e58c6b68e61f003a01ba29a3716e7e2e9484 ("Btrfs: fix write corruption due to bio cloning on raid5/6")
Signed-off-by: Liu Bo <bo.li.liu(a)oracle.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/btrfs/raid56.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--- a/fs/btrfs/raid56.c
+++ b/fs/btrfs/raid56.c
@@ -1432,14 +1432,13 @@ static int fail_bio_stripe(struct btrfs_
*/
static void set_bio_pages_uptodate(struct bio *bio)
{
- struct bio_vec bvec;
- struct bvec_iter iter;
+ struct bio_vec *bvec;
+ int i;
- if (bio_flagged(bio, BIO_CLONED))
- bio->bi_iter = btrfs_io_bio(bio)->iter;
+ ASSERT(!bio_flagged(bio, BIO_CLONED));
- bio_for_each_segment(bvec, bio, iter)
- SetPageUptodate(bvec.bv_page);
+ bio_for_each_segment_all(bvec, bio, i)
+ SetPageUptodate(bvec->bv_page);
}
/*
Patches currently in stable-queue which might be from bo.li.liu(a)oracle.com are
queue-4.14/btrfs-raid56-iterate-raid56-internal-bio-with-bio_for_each_segment_all.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
to the 4.14-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:
bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
and it can be found in the queue-4.14 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 61f5acea8737d9b717fcc22bb6679924f3c82b98 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Mon, 8 Jan 2018 10:44:16 +0100
Subject: Bluetooth: btusb: Restore QCA Rome suspend/resume fix with a "rewritten" version
From: Hans de Goede <hdegoede(a)redhat.com>
commit 61f5acea8737d9b717fcc22bb6679924f3c82b98 upstream.
Commit 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
removed the setting of the BTUSB_RESET_RESUME quirk for QCA Rome devices,
instead favoring adding USB_QUIRK_RESET_RESUME quirks in usb/core/quirks.c.
This was done because the DIY BTUSB_RESET_RESUME reset-resume handling
has several issues (see the original commit message). An added advantage
of moving over to the USB-core reset-resume handling is that it also
disables autosuspend for these devices, which is similarly broken on these.
But there are 2 issues with this approach:
1) It leaves the broken DIY BTUSB_RESET_RESUME code in place for Realtek
devices.
2) Sofar only 2 of the 10 QCA devices known to the btusb code have been
added to usb/core/quirks.c and if we fix the Realtek case the same way
we need to add an additional 14 entries. So in essence we need to
duplicate a large part of the usb_device_id table in btusb.c in
usb/core/quirks.c and manually keep them in sync.
This commit instead restores setting a reset-resume quirk for QCA devices
in the btusb.c code, avoiding the duplicate usb_device_id table problem.
This commit avoids the problems with the original DIY BTUSB_RESET_RESUME
code by simply setting the USB_QUIRK_RESET_RESUME quirk directly on the
usb_device.
This commit also moves the BTUSB_REALTEK case over to directly setting the
USB_QUIRK_RESET_RESUME on the usb_device and removes the now unused
BTUSB_RESET_RESUME code.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
Fixes: 7d06d5895c15 ("Revert "Bluetooth: btusb: fix QCA...suspend/resume"")
Cc: Leif Liddy <leif.linux(a)gmail.com>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Brian Norris <briannorris(a)chromium.org>
Cc: Daniel Drake <drake(a)endlessm.com>
Cc: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btusb.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -23,6 +23,7 @@
#include <linux/module.h>
#include <linux/usb.h>
+#include <linux/usb/quirks.h>
#include <linux/firmware.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
@@ -392,9 +393,8 @@ static const struct usb_device_id blackl
#define BTUSB_FIRMWARE_LOADED 7
#define BTUSB_FIRMWARE_FAILED 8
#define BTUSB_BOOTING 9
-#define BTUSB_RESET_RESUME 10
-#define BTUSB_DIAG_RUNNING 11
-#define BTUSB_OOB_WAKE_ENABLED 12
+#define BTUSB_DIAG_RUNNING 10
+#define BTUSB_OOB_WAKE_ENABLED 11
struct btusb_data {
struct hci_dev *hdev;
@@ -3099,6 +3099,12 @@ static int btusb_probe(struct usb_interf
if (id->driver_info & BTUSB_QCA_ROME) {
data->setup_on_usb = btusb_setup_qca;
hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
+
+ /* QCA Rome devices lose their updated firmware over suspend,
+ * but the USB hub doesn't notice any status change.
+ * explicitly request a device reset on resume.
+ */
+ interface_to_usbdev(intf)->quirks |= USB_QUIRK_RESET_RESUME;
}
#ifdef CONFIG_BT_HCIBTUSB_RTL
@@ -3109,7 +3115,7 @@ static int btusb_probe(struct usb_interf
* but the USB hub doesn't notice any status change.
* Explicitly request a device reset on resume.
*/
- set_bit(BTUSB_RESET_RESUME, &data->flags);
+ interface_to_usbdev(intf)->quirks |= USB_QUIRK_RESET_RESUME;
}
#endif
@@ -3274,14 +3280,6 @@ static int btusb_suspend(struct usb_inte
enable_irq(data->oob_wake_irq);
}
- /* Optionally request a device reset on resume, but only when
- * wakeups are disabled. If wakeups are enabled we assume the
- * device will stay powered up throughout suspend.
- */
- if (test_bit(BTUSB_RESET_RESUME, &data->flags) &&
- !device_may_wakeup(&data->udev->dev))
- data->udev->reset_resume = 1;
-
return 0;
}
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.14/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.14/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
queue-4.14/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
queue-4.14/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
queue-4.14/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btsdio: Do not bind to non-removable BCM43341
to the 4.14-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:
bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
and it can be found in the queue-4.14 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 b4cdaba274247c9c841c6a682c08fa91fb3aa549 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 29 Nov 2017 20:29:07 +0100
Subject: Bluetooth: btsdio: Do not bind to non-removable BCM43341
From: Hans de Goede <hdegoede(a)redhat.com>
commit b4cdaba274247c9c841c6a682c08fa91fb3aa549 upstream.
BCM43341 devices soldered onto the PCB (non-removable) always (AFAICT)
use an UART connection for bluetooth. But they also advertise btsdio
support on their 3th sdio function, this causes 2 problems:
1) A non functioning BT HCI getting registered
2) Since the btsdio driver does not have suspend/resume callbacks,
mmc_sdio_pre_suspend will return -ENOSYS, causing mmc_pm_notify()
to react as if the SDIO-card is removed and since the slot is
marked as non-removable it will never get detected as inserted again.
Which results in wifi no longer working after a suspend/resume.
This commit fixes both by making btsdio ignore BCM43341 devices
when connected to a slot which is marked non-removable.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btsdio.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -31,6 +31,7 @@
#include <linux/errno.h>
#include <linux/skbuff.h>
+#include <linux/mmc/host.h>
#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio_func.h>
@@ -292,6 +293,14 @@ static int btsdio_probe(struct sdio_func
tuple = tuple->next;
}
+ /* BCM43341 devices soldered onto the PCB (non-removable) use an
+ * uart connection for bluetooth, ignore the BT SDIO interface.
+ */
+ if (func->vendor == SDIO_VENDOR_ID_BROADCOM &&
+ func->device == SDIO_DEVICE_ID_BROADCOM_43341 &&
+ !mmc_card_is_removable(func->card->host))
+ return -ENODEV;
+
data = devm_kzalloc(&func->dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.14/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.14/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
queue-4.14/hid-quirks-fix-keyboard-touchpad-on-toshiba-click-mini-not-working.patch
queue-4.14/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
queue-4.14/bluetooth-btusb-restore-qca-rome-suspend-resume-fix-with-a-rewritten-version.patch
This is a note to let you know that I've just added the patch titled
ASoC: skl: Fix kernel warning due to zero NHTL entry
to the 4.14-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:
asoc-skl-fix-kernel-warning-due-to-zero-nhtl-entry.patch
and it can be found in the queue-4.14 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 20a1ea2222e7cbf96e9bf8579362e971491e6aea Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Wed, 3 Jan 2018 16:38:46 +0100
Subject: ASoC: skl: Fix kernel warning due to zero NHTL entry
From: Takashi Iwai <tiwai(a)suse.de>
commit 20a1ea2222e7cbf96e9bf8579362e971491e6aea upstream.
I got the following kernel warning when loading snd-soc-skl module on
Dell Latitude 7270 laptop:
memremap attempted on mixed range 0x0000000000000000 size: 0x0
WARNING: CPU: 0 PID: 484 at kernel/memremap.c:98 memremap+0x8a/0x180
Call Trace:
skl_nhlt_init+0x82/0xf0 [snd_soc_skl]
skl_probe+0x2ee/0x7c0 [snd_soc_skl]
....
It seems that the machine doesn't support the SKL DSP gives the empty
NHLT entry, and it triggers the warning. For avoiding it, let do the
zero check before calling memremap().
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/intel/skylake/skl-nhlt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/sound/soc/intel/skylake/skl-nhlt.c
+++ b/sound/soc/intel/skylake/skl-nhlt.c
@@ -41,7 +41,8 @@ struct nhlt_acpi_table *skl_nhlt_init(st
obj = acpi_evaluate_dsm(handle, &osc_guid, 1, 1, NULL);
if (obj && obj->type == ACPI_TYPE_BUFFER) {
nhlt_ptr = (struct nhlt_resource_desc *)obj->buffer.pointer;
- nhlt_table = (struct nhlt_acpi_table *)
+ if (nhlt_ptr->length)
+ nhlt_table = (struct nhlt_acpi_table *)
memremap(nhlt_ptr->min_addr, nhlt_ptr->length,
MEMREMAP_WB);
ACPI_FREE(obj);
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.14/asoc-skl-fix-kernel-warning-due-to-zero-nhtl-entry.patch
This is a note to let you know that I've just added the patch titled
ASoC: rockchip: i2s: fix playback after runtime resume
to the 4.14-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:
asoc-rockchip-i2s-fix-playback-after-runtime-resume.patch
and it can be found in the queue-4.14 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 c66234cfedfc3e6e3b62563a5f2c1562be09a35d Mon Sep 17 00:00:00 2001
From: John Keeping <john(a)metanate.com>
Date: Mon, 8 Jan 2018 16:01:04 +0000
Subject: ASoC: rockchip: i2s: fix playback after runtime resume
From: John Keeping <john(a)metanate.com>
commit c66234cfedfc3e6e3b62563a5f2c1562be09a35d upstream.
When restoring registers during runtime resume, we must not write to
I2S_TXDR which is the transmit FIFO as this queues up a sample to be
output and pushes all of the output channels down by one.
This can be demonstrated with the speaker-test utility:
for i in a b c; do speaker-test -c 2 -s 1; done
which should play a test through the left speaker three times but if the
I2S hardware starts runtime suspended the first sample will be played
through the right speaker.
Fix this by marking I2S_TXDR as volatile (which also requires marking it
as readble, even though it technically isn't). This seems to be the
most robust fix, the alternative of giving I2S_TXDR a default value is
more fragile since it does not prevent regcache writing to the register
in all circumstances.
While here, also fix the configuration of I2S_RXDR and I2S_FIFOLR; these
are not writable so they do not suffer from the same problem as I2S_TXDR
but reading from I2S_RXDR does suffer from a similar problem.
Fixes: f0447f6cbb20 ("ASoC: rockchip: i2s: restore register during runtime_suspend/resume cycle", 2016-09-07)
Signed-off-by: John Keeping <john(a)metanate.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/soc/rockchip/rockchip_i2s.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/sound/soc/rockchip/rockchip_i2s.c
+++ b/sound/soc/rockchip/rockchip_i2s.c
@@ -504,6 +504,7 @@ static bool rockchip_i2s_rd_reg(struct d
case I2S_INTCR:
case I2S_XFER:
case I2S_CLR:
+ case I2S_TXDR:
case I2S_RXDR:
case I2S_FIFOLR:
case I2S_INTSR:
@@ -518,6 +519,9 @@ static bool rockchip_i2s_volatile_reg(st
switch (reg) {
case I2S_INTSR:
case I2S_CLR:
+ case I2S_FIFOLR:
+ case I2S_TXDR:
+ case I2S_RXDR:
return true;
default:
return false;
@@ -527,6 +531,8 @@ static bool rockchip_i2s_volatile_reg(st
static bool rockchip_i2s_precious_reg(struct device *dev, unsigned int reg)
{
switch (reg) {
+ case I2S_RXDR:
+ return true;
default:
return false;
}
Patches currently in stable-queue which might be from john(a)metanate.com are
queue-4.14/asoc-rockchip-i2s-fix-playback-after-runtime-resume.patch
This is a note to let you know that I've just added the patch titled
arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
to the 4.14-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:
arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
and it can be found in the queue-4.14 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 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Tue, 6 Feb 2018 17:56:06 +0000
Subject: arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 upstream.
KVM doesn't follow the SMCCC when it comes to unimplemented calls,
and inject an UNDEF instead of returning an error. Since firmware
calls are now used for security mitigation, they are becoming more
common, and the undef is counter productive.
Instead, let's follow the SMCCC which states that -1 must be returned
to the caller when getting an unknown function number.
Tested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/kvm/handle_exit.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/arch/arm/kvm/handle_exit.c
+++ b/arch/arm/kvm/handle_exit.c
@@ -38,7 +38,7 @@ static int handle_hvc(struct kvm_vcpu *v
ret = kvm_hvc_call_handler(vcpu);
if (ret < 0) {
- kvm_inject_undefined(vcpu);
+ vcpu_set_reg(vcpu, 0, ~0UL);
return 1;
}
@@ -47,7 +47,16 @@ static int handle_hvc(struct kvm_vcpu *v
static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
- kvm_inject_undefined(vcpu);
+ /*
+ * "If an SMC instruction executed at Non-secure EL1 is
+ * trapped to EL2 because HCR_EL2.TSC is 1, the exception is a
+ * Trap exception, not a Secure Monitor Call exception [...]"
+ *
+ * We need to advance the PC after the trap, as it would
+ * otherwise return to the same address...
+ */
+ vcpu_set_reg(vcpu, 0, ~0UL);
+ kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
return 1;
}
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.14/arm-arm64-smccc-make-function-identifiers-an-unsigned-quantity.patch
queue-4.14/arm64-move-bp-hardening-to-check_and_switch_context.patch
queue-4.14/arm-arm64-kvm-advertise-smccc-v1.1.patch
queue-4.14/arm64-move-post_ttbr_update_workaround-to-c-code.patch
queue-4.14/firmware-psci-expose-psci-conduit.patch
queue-4.14/arm64-force-kpti-to-be-disabled-on-cavium-thunderx.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-high-priority-synchronous-exceptions.patch
queue-4.14/arm64-kpti-fix-the-interaction-between-asid-switching-and-software-pan.patch
queue-4.14/firmware-psci-expose-smccc-version-through-psci_ops.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-affected-cortex-a-cpus.patch
queue-4.14/arm-arm64-kvm-add-psci_version-helper.patch
queue-4.14/arm64-kill-psci_get_version-as-a-variant-2-workaround.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-suspicious-interrupts-from-el0.patch
queue-4.14/arm64-capabilities-handle-duplicate-entries-for-a-capability.patch
queue-4.14/arm64-add-arm_smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm-arm64-kvm-turn-kvm_psci_version-into-a-static-inline.patch
queue-4.14/arm-arm64-kvm-implement-psci-1.0-support.patch
queue-4.14/arm64-kvm-add-smccc_arch_workaround_1-fast-handling.patch
queue-4.14/arm64-kvm-report-smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm-arm64-smccc-implement-smccc-v1.1-inline-primitive.patch
queue-4.14/arm64-idmap-use-awx-flags-for-.idmap.text-.pushsection-directives.patch
queue-4.14/arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
queue-4.14/arm64-kvm-make-psci_version-a-fast-path.patch
queue-4.14/arm64-cpufeature-__this_cpu_has_cap-shouldn-t-stop-early.patch
queue-4.14/arm64-kpti-add-enable-callback-to-remap-swapper-using-ng-mappings.patch
queue-4.14/arm-arm64-kvm-consolidate-the-psci-include-files.patch
queue-4.14/arm64-add-skeleton-to-harden-the-branch-predictor-against-aliasing-attacks.patch
queue-4.14/arm-arm64-kvm-add-smccc-accessors-to-psci-code.patch
queue-4.14/arm64-kvm-use-per-cpu-vector-when-bp-hardening-is-enabled.patch
queue-4.14/arm64-kvm-increment-pc-after-handling-an-smc-trap.patch
This is a note to let you know that I've just added the patch titled
alpha: osf_sys.c: fix put_tv32 regression
to the 4.14-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:
alpha-osf_sys.c-fix-put_tv32-regression.patch
and it can be found in the queue-4.14 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 47669fb6b5951d0e09fc99719653e0ac92b50b99 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 8 Nov 2017 16:02:13 +0100
Subject: alpha: osf_sys.c: fix put_tv32 regression
From: Arnd Bergmann <arnd(a)arndb.de>
commit 47669fb6b5951d0e09fc99719653e0ac92b50b99 upstream.
There was a typo in the new version of put_tv32() that caused an unguarded
access of a user space pointer, and failed to return the correct result in
gettimeofday(), wait4(), usleep_thread() and old_adjtimex().
This fixes it to give the correct behavior again.
Fixes: 1cc6c4635e9f ("osf_sys.c: switch handling of timeval32/itimerval32 to copy_{to,from}_user()")
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/alpha/kernel/osf_sys.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/alpha/kernel/osf_sys.c
+++ b/arch/alpha/kernel/osf_sys.c
@@ -964,8 +964,8 @@ static inline long
put_tv32(struct timeval32 __user *o, struct timeval *i)
{
return copy_to_user(o, &(struct timeval32){
- .tv_sec = o->tv_sec,
- .tv_usec = o->tv_usec},
+ .tv_sec = i->tv_sec,
+ .tv_usec = i->tv_usec},
sizeof(struct timeval32));
}
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/kasan-rework-kconfig-settings.patch
queue-4.14/mtd-cfi-convert-inline-functions-to-macros.patch
queue-4.14/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-4.14/media-dvb-frontends-fix-i2c-access-helpers-for-kasan.patch
queue-4.14/alpha-osf_sys.c-fix-put_tv32-regression.patch
This is a note to let you know that I've just added the patch titled
alpha: fix reboot on Avanti platform
to the 4.14-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:
alpha-fix-reboot-on-avanti-platform.patch
and it can be found in the queue-4.14 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 55fc633c41a08ce9244ff5f528f420b16b1e04d6 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Tue, 2 Jan 2018 13:59:54 -0500
Subject: alpha: fix reboot on Avanti platform
From: Mikulas Patocka <mpatocka(a)redhat.com>
commit 55fc633c41a08ce9244ff5f528f420b16b1e04d6 upstream.
We need to define NEED_SRM_SAVE_RESTORE on the Avanti, otherwise we get
machine check exception when attempting to reboot the machine.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Matt Turner <mattst88(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/alpha/kernel/pci_impl.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/alpha/kernel/pci_impl.h
+++ b/arch/alpha/kernel/pci_impl.h
@@ -144,7 +144,8 @@ struct pci_iommu_arena
};
#if defined(CONFIG_ALPHA_SRM) && \
- (defined(CONFIG_ALPHA_CIA) || defined(CONFIG_ALPHA_LCA))
+ (defined(CONFIG_ALPHA_CIA) || defined(CONFIG_ALPHA_LCA) || \
+ defined(CONFIG_ALPHA_AVANTI))
# define NEED_SRM_SAVE_RESTORE
#else
# undef NEED_SRM_SAVE_RESTORE
Patches currently in stable-queue which might be from mpatocka(a)redhat.com are
queue-4.14/alpha-fix-formating-of-stack-content.patch
queue-4.14/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.14/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-4.14/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.14/alpha-fix-reboot-on-avanti-platform.patch
This is a note to let you know that I've just added the patch titled
alpha: Fix mixed up args in EXC macro in futex operations
to the 4.14-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:
alpha-fix-mixed-up-args-in-exc-macro-in-futex-operations.patch
and it can be found in the queue-4.14 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 84e455361ec97ea6037d31d42a2955628ea2094b Mon Sep 17 00:00:00 2001
From: Michael Cree <mcree(a)orcon.net.nz>
Date: Fri, 24 Nov 2017 21:25:01 +1300
Subject: alpha: Fix mixed up args in EXC macro in futex operations
From: Michael Cree <mcree(a)orcon.net.nz>
commit 84e455361ec97ea6037d31d42a2955628ea2094b upstream.
Fix the typo (mixed up arguments) in the EXC macro in the futex
definitions introduced by commit ca282f697381 (alpha: add a
helper for emitting exception table entries).
Signed-off-by: Michael Cree <mcree(a)orcon.net.nz>
Signed-off-by: Matt Turner <mattst88(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/alpha/include/asm/futex.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/arch/alpha/include/asm/futex.h
+++ b/arch/alpha/include/asm/futex.h
@@ -20,8 +20,8 @@
"3: .subsection 2\n" \
"4: br 1b\n" \
" .previous\n" \
- EXC(1b,3b,%1,$31) \
- EXC(2b,3b,%1,$31) \
+ EXC(1b,3b,$31,%1) \
+ EXC(2b,3b,$31,%1) \
: "=&r" (oldval), "=&r"(ret) \
: "r" (uaddr), "r"(oparg) \
: "memory")
@@ -82,8 +82,8 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
"3: .subsection 2\n"
"4: br 1b\n"
" .previous\n"
- EXC(1b,3b,%0,$31)
- EXC(2b,3b,%0,$31)
+ EXC(1b,3b,$31,%0)
+ EXC(2b,3b,$31,%0)
: "+r"(ret), "=&r"(prev), "=&r"(cmp)
: "r"(uaddr), "r"((long)(int)oldval), "r"(newval)
: "memory");
Patches currently in stable-queue which might be from mcree(a)orcon.net.nz are
queue-4.14/alpha-fix-mixed-up-args-in-exc-macro-in-futex-operations.patch
This is a note to let you know that I've just added the patch titled
alpha: fix formating of stack content
to the 4.14-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:
alpha-fix-formating-of-stack-content.patch
and it can be found in the queue-4.14 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 4b01abdb32fc36abe877503bfbd33019159fad71 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Tue, 2 Jan 2018 14:00:32 -0500
Subject: alpha: fix formating of stack content
From: Mikulas Patocka <mpatocka(a)redhat.com>
commit 4b01abdb32fc36abe877503bfbd33019159fad71 upstream.
Since version 4.9, the kernel automatically breaks printk calls into
multiple newlines unless pr_cont is used. Fix the alpha stacktrace code,
so that it prints stack trace in four columns, as it was initially
intended.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Matt Turner <mattst88(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/alpha/kernel/traps.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -160,11 +160,16 @@ void show_stack(struct task_struct *task
for(i=0; i < kstack_depth_to_print; i++) {
if (((long) stack & (THREAD_SIZE-1)) == 0)
break;
- if (i && ((i % 4) == 0))
- printk("\n ");
- printk("%016lx ", *stack++);
+ if ((i % 4) == 0) {
+ if (i)
+ pr_cont("\n");
+ printk(" ");
+ } else {
+ pr_cont(" ");
+ }
+ pr_cont("%016lx", *stack++);
}
- printk("\n");
+ pr_cont("\n");
dik_show_trace(sp);
}
Patches currently in stable-queue which might be from mpatocka(a)redhat.com are
queue-4.14/alpha-fix-formating-of-stack-content.patch
queue-4.14/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.14/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-4.14/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.14/alpha-fix-reboot-on-avanti-platform.patch
This is a note to let you know that I've just added the patch titled
alpha: fix crash if pthread_create races with signal delivery
to the 4.14-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:
alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
and it can be found in the queue-4.14 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 21ffceda1c8b3807615c40d440d7815e0c85d366 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Tue, 2 Jan 2018 14:01:34 -0500
Subject: alpha: fix crash if pthread_create races with signal delivery
From: Mikulas Patocka <mpatocka(a)redhat.com>
commit 21ffceda1c8b3807615c40d440d7815e0c85d366 upstream.
On alpha, a process will crash if it attempts to start a thread and a
signal is delivered at the same time. The crash can be reproduced with
this program: https://cygwin.com/ml/cygwin/2014-11/msg00473.html
The reason for the crash is this:
* we call the clone syscall
* we go to the function copy_process
* copy process calls copy_thread_tls, it is a wrapper around copy_thread
* copy_thread sets the tls pointer: childti->pcb.unique = regs->r20
* copy_thread sets regs->r20 to zero
* we go back to copy_process
* copy process checks "if (signal_pending(current))" and returns
-ERESTARTNOINTR
* the clone syscall is restarted, but this time, regs->r20 is zero, so
the new thread is created with zero tls pointer
* the new thread crashes in start_thread when attempting to access tls
The comment in the code says that setting the register r20 is some
compatibility with OSF/1. But OSF/1 doesn't use the CLONE_SETTLS flag, so
we don't have to zero r20 if CLONE_SETTLS is set. This patch fixes the bug
by zeroing regs->r20 only if CLONE_SETTLS is not set.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Matt Turner <mattst88(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/alpha/kernel/process.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -269,12 +269,13 @@ copy_thread(unsigned long clone_flags, u
application calling fork. */
if (clone_flags & CLONE_SETTLS)
childti->pcb.unique = regs->r20;
+ else
+ regs->r20 = 0; /* OSF/1 has some strange fork() semantics. */
childti->pcb.usp = usp ?: rdusp();
*childregs = *regs;
childregs->r0 = 0;
childregs->r19 = 0;
childregs->r20 = 1; /* OSF/1 has some strange fork() semantics. */
- regs->r20 = 0;
stack = ((struct switch_stack *) regs) - 1;
*childstack = *stack;
childstack->r26 = (unsigned long) ret_from_fork;
Patches currently in stable-queue which might be from mpatocka(a)redhat.com are
queue-4.14/alpha-fix-formating-of-stack-content.patch
queue-4.14/pipe-fix-off-by-one-error-when-checking-buffer-limits.patch
queue-4.14/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-4.14/pipe-actually-allow-root-to-exceed-the-pipe-buffer-limits.patch
queue-4.14/alpha-fix-reboot-on-avanti-platform.patch
This is a note to let you know that I've just added the patch titled
xtensa: fix futex_atomic_cmpxchg_inatomic
to the 3.18-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:
xtensa-fix-futex_atomic_cmpxchg_inatomic.patch
and it can be found in the queue-3.18 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 ca47480921587ae30417dd234a9f79af188e3666 Mon Sep 17 00:00:00 2001
From: Max Filippov <jcmvbkbc(a)gmail.com>
Date: Fri, 5 Jan 2018 14:27:58 -0800
Subject: xtensa: fix futex_atomic_cmpxchg_inatomic
From: Max Filippov <jcmvbkbc(a)gmail.com>
commit ca47480921587ae30417dd234a9f79af188e3666 upstream.
Return 0 if the operation was successful, not the userspace memory
value. Check that userspace value equals passed oldval, not itself.
Don't update *uval if the value wasn't read from userspace memory.
This fixes process hang due to infinite loop in futex_lock_pi.
It also fixes a bunch of glibc tests nptl/tst-mutexpi*.
Signed-off-by: Max Filippov <jcmvbkbc(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/xtensa/include/asm/futex.h | 23 ++++++++++-------------
1 file changed, 10 insertions(+), 13 deletions(-)
--- a/arch/xtensa/include/asm/futex.h
+++ b/arch/xtensa/include/asm/futex.h
@@ -109,7 +109,6 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
u32 oldval, u32 newval)
{
int ret = 0;
- u32 prev;
if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
@@ -120,26 +119,24 @@ futex_atomic_cmpxchg_inatomic(u32 *uval,
__asm__ __volatile__ (
" # futex_atomic_cmpxchg_inatomic\n"
- "1: l32i %1, %3, 0\n"
- " mov %0, %5\n"
- " wsr %1, scompare1\n"
- "2: s32c1i %0, %3, 0\n"
- "3:\n"
+ " wsr %5, scompare1\n"
+ "1: s32c1i %1, %4, 0\n"
+ " s32i %1, %6, 0\n"
+ "2:\n"
" .section .fixup,\"ax\"\n"
" .align 4\n"
- "4: .long 3b\n"
- "5: l32r %1, 4b\n"
- " movi %0, %6\n"
+ "3: .long 2b\n"
+ "4: l32r %1, 3b\n"
+ " movi %0, %7\n"
" jx %1\n"
" .previous\n"
" .section __ex_table,\"a\"\n"
- " .long 1b,5b,2b,5b\n"
+ " .long 1b,4b\n"
" .previous\n"
- : "+r" (ret), "=&r" (prev), "+m" (*uaddr)
- : "r" (uaddr), "r" (oldval), "r" (newval), "I" (-EFAULT)
+ : "+r" (ret), "+r" (newval), "+m" (*uaddr), "+m" (*uval)
+ : "r" (uaddr), "r" (oldval), "r" (uval), "I" (-EFAULT)
: "memory");
- *uval = prev;
return ret;
}
Patches currently in stable-queue which might be from jcmvbkbc(a)gmail.com are
queue-3.18/xtensa-fix-futex_atomic_cmpxchg_inatomic.patch
This is a note to let you know that I've just added the patch titled
signal/sh: Ensure si_signo is initialized in do_divide_error
to the 3.18-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:
signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
and it can be found in the queue-3.18 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 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Mon, 24 Jul 2017 17:30:30 -0500
Subject: signal/sh: Ensure si_signo is initialized in do_divide_error
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 0e88bb002a9b2ee8cc3cc9478ce2dc126f849696 upstream.
Set si_signo.
Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp>
Cc: Rich Felker <dalias(a)libc.org>
Cc: Paul Mundt <lethal(a)linux-sh.org>
Cc: linux-sh(a)vger.kernel.org
Fixes: 0983b31849bb ("sh: Wire up division and address error exceptions on SH-2A.")
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/sh/kernel/traps_32.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/sh/kernel/traps_32.c
+++ b/arch/sh/kernel/traps_32.c
@@ -607,7 +607,8 @@ asmlinkage void do_divide_error(unsigned
break;
}
- force_sig_info(SIGFPE, &info, current);
+ info.si_signo = SIGFPE;
+ force_sig_info(info.si_signo, &info, current);
}
#endif
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-3.18/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-3.18/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
This is a note to let you know that I've just added the patch titled
signal/openrisc: Fix do_unaligned_access to send the proper signal
to the 3.18-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:
signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
and it can be found in the queue-3.18 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 500d58300571b6602341b041f97c082a461ef994 Mon Sep 17 00:00:00 2001
From: "Eric W. Biederman" <ebiederm(a)xmission.com>
Date: Tue, 1 Aug 2017 04:16:47 -0500
Subject: signal/openrisc: Fix do_unaligned_access to send the proper signal
From: Eric W. Biederman <ebiederm(a)xmission.com>
commit 500d58300571b6602341b041f97c082a461ef994 upstream.
While reviewing the signal sending on openrisc the do_unaligned_access
function stood out because it is obviously wrong. A comment about an
si_code set above when actually si_code is never set. Leading to a
random si_code being sent to userspace in the event of an unaligned
access.
Looking further SIGBUS BUS_ADRALN is the proper pair of signal and
si_code to send for an unaligned access. That is what other
architectures do and what is required by posix.
Given that do_unaligned_access is broken in a way that no one can be
relying on it on openrisc fix the code to just do the right thing.
Fixes: 769a8a96229e ("OpenRISC: Traps")
Cc: Jonas Bonn <jonas(a)southpole.se>
Cc: Stefan Kristiansson <stefan.kristiansson(a)saunalahti.fi>
Cc: Stafford Horne <shorne(a)gmail.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: openrisc(a)lists.librecores.org
Acked-by: Stafford Horne <shorne(a)gmail.com>
Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/openrisc/kernel/traps.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/openrisc/kernel/traps.c
+++ b/arch/openrisc/kernel/traps.c
@@ -302,12 +302,12 @@ asmlinkage void do_unaligned_access(stru
siginfo_t info;
if (user_mode(regs)) {
- /* Send a SIGSEGV */
- info.si_signo = SIGSEGV;
+ /* Send a SIGBUS */
+ info.si_signo = SIGBUS;
info.si_errno = 0;
- /* info.si_code has been set above */
- info.si_addr = (void *)address;
- force_sig_info(SIGSEGV, &info, current);
+ info.si_code = BUS_ADRALN;
+ info.si_addr = (void __user *)address;
+ force_sig_info(SIGBUS, &info, current);
} else {
printk("KERNEL: Unaligned Access 0x%.8lx\n", address);
show_registers(regs);
Patches currently in stable-queue which might be from ebiederm(a)xmission.com are
queue-3.18/signal-openrisc-fix-do_unaligned_access-to-send-the-proper-signal.patch
queue-3.18/signal-sh-ensure-si_signo-is-initialized-in-do_divide_error.patch
This is a note to let you know that I've just added the patch titled
pktcdvd: Fix pkt_setup_dev() error path
to the 3.18-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:
pktcdvd-fix-pkt_setup_dev-error-path.patch
and it can be found in the queue-3.18 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 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd Mon Sep 17 00:00:00 2001
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Tue, 2 Jan 2018 11:39:47 -0800
Subject: pktcdvd: Fix pkt_setup_dev() error path
From: Bart Van Assche <bart.vanassche(a)wdc.com>
commit 5a0ec388ef0f6e33841aeb810d7fa23f049ec4cd upstream.
Commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
modified add_disk() and disk_release() but did not update any of the
error paths that trigger a put_disk() call after disk->queue has been
assigned. That introduced the following behavior in the pktcdvd driver
if pkt_new_dev() fails:
Kernel BUG at 00000000e98fd882 [verbose debug info unavailable]
Since disk_release() calls blk_put_queue() anyway if disk->queue != NULL,
fix this by removing the blk_cleanup_queue() call from the pkt_setup_dev()
error path.
Fixes: commit 523e1d399ce0 ("block: make gendisk hold a reference to its queue")
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Tejun Heo <tj(a)kernel.org>
Cc: Maciej S. Szmigiero <mail(a)maciej.szmigiero.name>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/block/pktcdvd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2798,7 +2798,7 @@ static int pkt_setup_dev(dev_t dev, dev_
pd->pkt_dev = MKDEV(pktdev_major, idx);
ret = pkt_new_dev(pd, dev);
if (ret)
- goto out_new_dev;
+ goto out_mem2;
/* inherit events of the host device */
disk->events = pd->bdev->bd_disk->events;
@@ -2816,8 +2816,6 @@ static int pkt_setup_dev(dev_t dev, dev_
mutex_unlock(&ctl_mutex);
return 0;
-out_new_dev:
- blk_cleanup_queue(disk->queue);
out_mem2:
put_disk(disk);
out_mem:
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-3.18/pktcdvd-fix-pkt_setup_dev-error-path.patch
This is a note to let you know that I've just added the patch titled
media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
to the 3.18-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:
media-cxusb-dib0700-ignore-xc2028_i2c_flush.patch
and it can be found in the queue-3.18 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 9893b905e743ded332575ca04486bd586c0772f7 Mon Sep 17 00:00:00 2001
From: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Date: Wed, 24 Jan 2018 06:01:57 -0500
Subject: media: cxusb, dib0700: ignore XC2028_I2C_FLUSH
From: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
commit 9893b905e743ded332575ca04486bd586c0772f7 upstream.
The XC2028_I2C_FLUSH only needs to be implemented on a few
devices. Others can safely ignore it.
That prevents filling the dmesg with lots of messages like:
dib0700: stk7700ph_xc3028_callback: unknown command 2, arg 0
Fixes: 4d37ece757a8 ("[media] tuner/xc2028: Add I2C flush callback")
Reported-by: Enrico Mioso <mrkiko.rs(a)gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/usb/dvb-usb/cxusb.c | 2 ++
drivers/media/usb/dvb-usb/dib0700_devices.c | 1 +
2 files changed, 3 insertions(+)
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -923,6 +923,8 @@ static int dvico_bluebird_xc2028_callbac
case XC2028_RESET_CLK:
deb_info("%s: XC2028_RESET_CLK %d\n", __func__, arg);
break;
+ case XC2028_I2C_FLUSH:
+ break;
default:
deb_info("%s: unknown command %d, arg %d\n", __func__,
command, arg);
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -431,6 +431,7 @@ static int stk7700ph_xc3028_callback(voi
state->dib7000p_ops.set_gpio(adap->fe_adap[0].fe, 8, 0, 1);
break;
case XC2028_RESET_CLK:
+ case XC2028_I2C_FLUSH:
break;
default:
err("%s: unknown command %d, arg %d\n", __func__,
Patches currently in stable-queue which might be from mchehab(a)osg.samsung.com are
queue-3.18/media-cxusb-dib0700-ignore-xc2028_i2c_flush.patch
This is a note to let you know that I've just added the patch titled
kernel/async.c: revert "async: simplify lowest_in_progress()"
to the 3.18-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:
kernel-async.c-revert-async-simplify-lowest_in_progress.patch
and it can be found in the queue-3.18 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 4f7e988e63e336827f4150de48163bed05d653bd Mon Sep 17 00:00:00 2001
From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Date: Tue, 6 Feb 2018 15:37:55 -0800
Subject: kernel/async.c: revert "async: simplify lowest_in_progress()"
From: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
commit 4f7e988e63e336827f4150de48163bed05d653bd upstream.
This reverts commit 92266d6ef60c ("async: simplify lowest_in_progress()")
which was simply wrong: In the case where domain is NULL, we now use the
wrong offsetof() in the list_first_entry macro, so we don't actually
fetch the ->cookie value, but rather the eight bytes located
sizeof(struct list_head) further into the struct async_entry.
On 64 bit, that's the data member, while on 32 bit, that's a u64 built
from func and data in some order.
I think the bug happens to be harmless in practice: It obviously only
affects callers which pass a NULL domain, and AFAICT the only such
caller is
async_synchronize_full() ->
async_synchronize_full_domain(NULL) ->
async_synchronize_cookie_domain(ASYNC_COOKIE_MAX, NULL)
and the ASYNC_COOKIE_MAX means that in practice we end up waiting for
the async_global_pending list to be empty - but it would break if
somebody happened to pass (void*)-1 as the data element to
async_schedule, and of course also if somebody ever does a
async_synchronize_cookie_domain(, NULL) with a "finite" cookie value.
Maybe the "harmless in practice" means this isn't -stable material. But
I'm not completely confident my quick git grep'ing is enough, and there
might be affected code in one of the earlier kernels that has since been
removed, so I'll leave the decision to the stable guys.
Link: http://lkml.kernel.org/r/20171128104938.3921-1-linux@rasmusvillemoes.dk
Fixes: 92266d6ef60c "async: simplify lowest_in_progress()"
Signed-off-by: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Acked-by: Tejun Heo <tj(a)kernel.org>
Cc: Arjan van de Ven <arjan(a)linux.intel.com>
Cc: Adam Wallis <awallis(a)codeaurora.org>
Cc: Lai Jiangshan <laijs(a)cn.fujitsu.com>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/async.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/kernel/async.c
+++ b/kernel/async.c
@@ -84,20 +84,24 @@ static atomic_t entry_count;
static async_cookie_t lowest_in_progress(struct async_domain *domain)
{
- struct list_head *pending;
+ struct async_entry *first = NULL;
async_cookie_t ret = ASYNC_COOKIE_MAX;
unsigned long flags;
spin_lock_irqsave(&async_lock, flags);
- if (domain)
- pending = &domain->pending;
- else
- pending = &async_global_pending;
+ if (domain) {
+ if (!list_empty(&domain->pending))
+ first = list_first_entry(&domain->pending,
+ struct async_entry, domain_list);
+ } else {
+ if (!list_empty(&async_global_pending))
+ first = list_first_entry(&async_global_pending,
+ struct async_entry, global_list);
+ }
- if (!list_empty(pending))
- ret = list_first_entry(pending, struct async_entry,
- domain_list)->cookie;
+ if (first)
+ ret = first->cookie;
spin_unlock_irqrestore(&async_lock, flags);
return ret;
Patches currently in stable-queue which might be from linux(a)rasmusvillemoes.dk are
queue-3.18/kernel-async.c-revert-async-simplify-lowest_in_progress.patch
This is a note to let you know that I've just added the patch titled
EDAC, octeon: Fix an uninitialized variable warning
to the 3.18-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:
edac-octeon-fix-an-uninitialized-variable-warning.patch
and it can be found in the queue-3.18 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 544e92581a2ac44607d7cc602c6b54d18656f56d Mon Sep 17 00:00:00 2001
From: James Hogan <jhogan(a)kernel.org>
Date: Mon, 13 Nov 2017 16:12:06 +0000
Subject: EDAC, octeon: Fix an uninitialized variable warning
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: James Hogan <jhogan(a)kernel.org>
commit 544e92581a2ac44607d7cc602c6b54d18656f56d upstream.
Fix an uninitialized variable warning in the Octeon EDAC driver, as seen
in MIPS cavium_octeon_defconfig builds since v4.14 with Codescape GNU
Tools 2016.05-03:
drivers/edac/octeon_edac-lmc.c In function ‘octeon_lmc_edac_poll_o2’:
drivers/edac/octeon_edac-lmc.c:87:24: warning: ‘((long unsigned int*)&int_reg)[1]’ may \
be used uninitialized in this function [-Wmaybe-uninitialized]
if (int_reg.s.sec_err || int_reg.s.ded_err) {
^
Iinitialise the whole int_reg variable to zero before the conditional
assignments in the error injection case.
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Acked-by: David Daney <david.daney(a)cavium.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Cc: linux-mips(a)linux-mips.org
Fixes: 1bc021e81565 ("EDAC: Octeon: Add error injection support")
Link: http://lkml.kernel.org/r/20171113161206.20990-1-james.hogan@mips.com
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/edac/octeon_edac-lmc.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/edac/octeon_edac-lmc.c
+++ b/drivers/edac/octeon_edac-lmc.c
@@ -79,6 +79,7 @@ static void octeon_lmc_edac_poll_o2(stru
if (!pvt->inject)
int_reg.u64 = cvmx_read_csr(CVMX_LMCX_INT(mci->mc_idx));
else {
+ int_reg.u64 = 0;
if (pvt->error_type == 1)
int_reg.s.sec_err = 1;
if (pvt->error_type == 2)
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-3.18/edac-octeon-fix-an-uninitialized-variable-warning.patch
This is a note to let you know that I've just added the patch titled
crypto: caam - fix endless loop when DECO acquire fails
to the 3.18-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:
crypto-caam-fix-endless-loop-when-deco-acquire-fails.patch
and it can be found in the queue-3.18 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 225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Horia=20Geant=C4=83?= <horia.geanta(a)nxp.com>
Date: Mon, 5 Feb 2018 11:15:52 +0200
Subject: crypto: caam - fix endless loop when DECO acquire fails
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Horia Geantă <horia.geanta(a)nxp.com>
commit 225ece3e7dad4cfc44cca38ce7a3a80f255ea8f1 upstream.
In case DECO0 cannot be acquired - i.e. run_descriptor_deco0() fails
with -ENODEV, caam_probe() enters an endless loop:
run_descriptor_deco0
ret -ENODEV
-> instantiate_rng
-ENODEV, overwritten by -EAGAIN
ret -EAGAIN
-> caam_probe
-EAGAIN results in endless loop
It turns out the error path in instantiate_rng() is incorrect,
the checks are done in the wrong order.
Fixes: 1005bccd7a4a6 ("crypto: caam - enable instantiation of all RNG4 state handles")
Reported-by: Bryan O'Donoghue <pure.logic(a)nexus-software.ie>
Suggested-by: Auer Lukas <lukas.auer(a)aisec.fraunhofer.de>
Signed-off-by: Horia Geantă <horia.geanta(a)nxp.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/crypto/caam/ctrl.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -209,12 +209,16 @@ static int instantiate_rng(struct device
* without any error (HW optimizations for later
* CAAM eras), then try again.
*/
+ if (ret)
+ break;
+
rdsta_val =
rd_reg32(&ctrl->r4tst[0].rdsta) & RDSTA_IFMASK;
- if (status || !(rdsta_val & (1 << sh_idx)))
+ if (status || !(rdsta_val & (1 << sh_idx))) {
ret = -EAGAIN;
- if (ret)
break;
+ }
+
dev_info(ctrldev, "Instantiated RNG4 SH%d\n", sh_idx);
/* Clear the contents before recreating the descriptor */
memset(desc, 0x00, CAAM_CMD_SZ * 7);
Patches currently in stable-queue which might be from horia.geanta(a)nxp.com are
queue-3.18/crypto-caam-fix-endless-loop-when-deco-acquire-fails.patch
This is a note to let you know that I've just added the patch titled
Bluetooth: btsdio: Do not bind to non-removable BCM43341
to the 3.18-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:
bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
and it can be found in the queue-3.18 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 b4cdaba274247c9c841c6a682c08fa91fb3aa549 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 29 Nov 2017 20:29:07 +0100
Subject: Bluetooth: btsdio: Do not bind to non-removable BCM43341
From: Hans de Goede <hdegoede(a)redhat.com>
commit b4cdaba274247c9c841c6a682c08fa91fb3aa549 upstream.
BCM43341 devices soldered onto the PCB (non-removable) always (AFAICT)
use an UART connection for bluetooth. But they also advertise btsdio
support on their 3th sdio function, this causes 2 problems:
1) A non functioning BT HCI getting registered
2) Since the btsdio driver does not have suspend/resume callbacks,
mmc_sdio_pre_suspend will return -ENOSYS, causing mmc_pm_notify()
to react as if the SDIO-card is removed and since the slot is
marked as non-removable it will never get detected as inserted again.
Which results in wifi no longer working after a suspend/resume.
This commit fixes both by making btsdio ignore BCM43341 devices
when connected to a slot which is marked non-removable.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/bluetooth/btsdio.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/bluetooth/btsdio.c
+++ b/drivers/bluetooth/btsdio.c
@@ -31,6 +31,7 @@
#include <linux/errno.h>
#include <linux/skbuff.h>
+#include <linux/mmc/host.h>
#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio_func.h>
@@ -303,6 +304,14 @@ static int btsdio_probe(struct sdio_func
tuple = tuple->next;
}
+ /* BCM43341 devices soldered onto the PCB (non-removable) use an
+ * uart connection for bluetooth, ignore the BT SDIO interface.
+ */
+ if (func->vendor == SDIO_VENDOR_ID_BROADCOM &&
+ func->device == SDIO_DEVICE_ID_BROADCOM_43341 &&
+ !mmc_card_is_removable(func->card->host))
+ return -ENODEV;
+
data = devm_kzalloc(&func->dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-3.18/bluetooth-btsdio-do-not-bind-to-non-removable-bcm43341.patch
This is a note to let you know that I've just added the patch titled
arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
to the 3.18-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:
arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
and it can be found in the queue-3.18 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 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Tue, 6 Feb 2018 17:56:06 +0000
Subject: arm: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
From: Marc Zyngier <marc.zyngier(a)arm.com>
commit 20e8175d246e9f9deb377f2784b3e7dfb2ad3e86 upstream.
KVM doesn't follow the SMCCC when it comes to unimplemented calls,
and inject an UNDEF instead of returning an error. Since firmware
calls are now used for security mitigation, they are becoming more
common, and the undef is counter productive.
Instead, let's follow the SMCCC which states that -1 must be returned
to the caller when getting an unknown function number.
Tested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm/kvm/handle_exit.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/arch/arm/kvm/handle_exit.c
+++ b/arch/arm/kvm/handle_exit.c
@@ -45,7 +45,7 @@ static int handle_hvc(struct kvm_vcpu *v
ret = kvm_psci_call(vcpu);
if (ret < 0) {
- kvm_inject_undefined(vcpu);
+ vcpu_set_reg(vcpu, 0, ~0UL);
return 1;
}
@@ -54,7 +54,16 @@ static int handle_hvc(struct kvm_vcpu *v
static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
{
- kvm_inject_undefined(vcpu);
+ /*
+ * "If an SMC instruction executed at Non-secure EL1 is
+ * trapped to EL2 because HCR_EL2.TSC is 1, the exception is a
+ * Trap exception, not a Secure Monitor Call exception [...]"
+ *
+ * We need to advance the PC after the trap, as it would
+ * otherwise return to the same address...
+ */
+ vcpu_set_reg(vcpu, 0, ~0UL);
+ kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
return 1;
}
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-3.18/arm-kvm-fix-smccc-handling-of-unimplemented-smc-hvc-calls.patch
This is a note to let you know that I've just added the patch titled
alpha: fix reboot on Avanti platform
to the 3.18-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:
alpha-fix-reboot-on-avanti-platform.patch
and it can be found in the queue-3.18 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 55fc633c41a08ce9244ff5f528f420b16b1e04d6 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Tue, 2 Jan 2018 13:59:54 -0500
Subject: alpha: fix reboot on Avanti platform
From: Mikulas Patocka <mpatocka(a)redhat.com>
commit 55fc633c41a08ce9244ff5f528f420b16b1e04d6 upstream.
We need to define NEED_SRM_SAVE_RESTORE on the Avanti, otherwise we get
machine check exception when attempting to reboot the machine.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Matt Turner <mattst88(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/alpha/kernel/pci_impl.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/alpha/kernel/pci_impl.h
+++ b/arch/alpha/kernel/pci_impl.h
@@ -143,7 +143,8 @@ struct pci_iommu_arena
};
#if defined(CONFIG_ALPHA_SRM) && \
- (defined(CONFIG_ALPHA_CIA) || defined(CONFIG_ALPHA_LCA))
+ (defined(CONFIG_ALPHA_CIA) || defined(CONFIG_ALPHA_LCA) || \
+ defined(CONFIG_ALPHA_AVANTI))
# define NEED_SRM_SAVE_RESTORE
#else
# undef NEED_SRM_SAVE_RESTORE
Patches currently in stable-queue which might be from mpatocka(a)redhat.com are
queue-3.18/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-3.18/alpha-fix-reboot-on-avanti-platform.patch
This is a note to let you know that I've just added the patch titled
alpha: fix crash if pthread_create races with signal delivery
to the 3.18-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:
alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
and it can be found in the queue-3.18 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 21ffceda1c8b3807615c40d440d7815e0c85d366 Mon Sep 17 00:00:00 2001
From: Mikulas Patocka <mpatocka(a)redhat.com>
Date: Tue, 2 Jan 2018 14:01:34 -0500
Subject: alpha: fix crash if pthread_create races with signal delivery
From: Mikulas Patocka <mpatocka(a)redhat.com>
commit 21ffceda1c8b3807615c40d440d7815e0c85d366 upstream.
On alpha, a process will crash if it attempts to start a thread and a
signal is delivered at the same time. The crash can be reproduced with
this program: https://cygwin.com/ml/cygwin/2014-11/msg00473.html
The reason for the crash is this:
* we call the clone syscall
* we go to the function copy_process
* copy process calls copy_thread_tls, it is a wrapper around copy_thread
* copy_thread sets the tls pointer: childti->pcb.unique = regs->r20
* copy_thread sets regs->r20 to zero
* we go back to copy_process
* copy process checks "if (signal_pending(current))" and returns
-ERESTARTNOINTR
* the clone syscall is restarted, but this time, regs->r20 is zero, so
the new thread is created with zero tls pointer
* the new thread crashes in start_thread when attempting to access tls
The comment in the code says that setting the register r20 is some
compatibility with OSF/1. But OSF/1 doesn't use the CLONE_SETTLS flag, so
we don't have to zero r20 if CLONE_SETTLS is set. This patch fixes the bug
by zeroing regs->r20 only if CLONE_SETTLS is not set.
Signed-off-by: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Matt Turner <mattst88(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/alpha/kernel/process.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/alpha/kernel/process.c
+++ b/arch/alpha/kernel/process.c
@@ -274,12 +274,13 @@ copy_thread(unsigned long clone_flags, u
application calling fork. */
if (clone_flags & CLONE_SETTLS)
childti->pcb.unique = regs->r20;
+ else
+ regs->r20 = 0; /* OSF/1 has some strange fork() semantics. */
childti->pcb.usp = usp ?: rdusp();
*childregs = *regs;
childregs->r0 = 0;
childregs->r19 = 0;
childregs->r20 = 1; /* OSF/1 has some strange fork() semantics. */
- regs->r20 = 0;
stack = ((struct switch_stack *) regs) - 1;
*childstack = *stack;
childstack->r26 = (unsigned long) ret_from_fork;
Patches currently in stable-queue which might be from mpatocka(a)redhat.com are
queue-3.18/alpha-fix-crash-if-pthread_create-races-with-signal-delivery.patch
queue-3.18/alpha-fix-reboot-on-avanti-platform.patch
The patch below does not apply to the 4.4-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 f5a26acf0162477af6ee4c11b4fb9cffe5d3e257 Mon Sep 17 00:00:00 2001
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Date: Wed, 29 Nov 2017 16:25:44 +0300
Subject: [PATCH] pinctrl: intel: Initialize GPIO properly when used through
irqchip
When a GPIO is requested using gpiod_get_* APIs the intel pinctrl driver
switches the pin to GPIO mode and makes sure interrupts are routed to
the GPIO hardware instead of IOAPIC. However, if the GPIO is used
directly through irqchip, as is the case with many I2C-HID devices where
I2C core automatically configures interrupt for the device, the pin is
not initialized as GPIO. Instead we rely that the BIOS configures the
pin accordingly which seems not to be the case at least in Asus X540NA
SKU3 with Focaltech touchpad.
When the pin is not properly configured it might result weird behaviour
like interrupts suddenly stop firing completely and the touchpad stops
responding to user input.
Fix this by properly initializing the pin to GPIO mode also when it is
used directly through irqchip.
Fixes: 7981c0015af2 ("pinctrl: intel: Add Intel Sunrisepoint pin controller and GPIO support")
Reported-by: Daniel Drake <drake(a)endlessm.com>
Reported-and-tested-by: Chris Chiu <chiu(a)endlessm.com>
Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c b/drivers/pinctrl/intel/pinctrl-intel.c
index 4c2369a8d926..359800fcb951 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -425,6 +425,18 @@ static void __intel_gpio_set_direction(void __iomem *padcfg0, bool input)
writel(value, padcfg0);
}
+static void intel_gpio_set_gpio_mode(void __iomem *padcfg0)
+{
+ u32 value;
+
+ /* Put the pad into GPIO mode */
+ value = readl(padcfg0) & ~PADCFG0_PMODE_MASK;
+ /* Disable SCI/SMI/NMI generation */
+ value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI);
+ value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI);
+ writel(value, padcfg0);
+}
+
static int intel_gpio_request_enable(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned pin)
@@ -432,7 +444,6 @@ static int intel_gpio_request_enable(struct pinctrl_dev *pctldev,
struct intel_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
void __iomem *padcfg0;
unsigned long flags;
- u32 value;
raw_spin_lock_irqsave(&pctrl->lock, flags);
@@ -442,13 +453,7 @@ static int intel_gpio_request_enable(struct pinctrl_dev *pctldev,
}
padcfg0 = intel_get_padcfg(pctrl, pin, PADCFG0);
- /* Put the pad into GPIO mode */
- value = readl(padcfg0) & ~PADCFG0_PMODE_MASK;
- /* Disable SCI/SMI/NMI generation */
- value &= ~(PADCFG0_GPIROUTIOXAPIC | PADCFG0_GPIROUTSCI);
- value &= ~(PADCFG0_GPIROUTSMI | PADCFG0_GPIROUTNMI);
- writel(value, padcfg0);
-
+ intel_gpio_set_gpio_mode(padcfg0);
/* Disable TX buffer and enable RX (this will be input) */
__intel_gpio_set_direction(padcfg0, true);
@@ -968,6 +973,8 @@ static int intel_gpio_irq_type(struct irq_data *d, unsigned type)
raw_spin_lock_irqsave(&pctrl->lock, flags);
+ intel_gpio_set_gpio_mode(reg);
+
value = readl(reg);
value &= ~(PADCFG0_RXEVCFG_MASK | PADCFG0_RXINV);
The patch below does not apply to the 4.4-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 01cffe9ded15c0d664e0beb33c594e00c0d57bba Mon Sep 17 00:00:00 2001
From: Dave Young <dyoung(a)redhat.com>
Date: Fri, 1 Dec 2017 20:19:34 +0800
Subject: [PATCH] HID: add quirk for another PIXART OEM mouse used by HP
This mouse keep disconnecting in runleve 3 like below, add it needs the
quirk to mute the anoying messages.
[ 111.230555] usb 2-2: USB disconnect, device number 6
[ 112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd
[ 112.941594] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
[ 112.984866] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 113.027731] usb 2-2: Product: HP USB Optical Mouse
[ 113.069977] usb 2-2: Manufacturer: PixArt
[ 113.113500] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0002/input/input14
[ 113.156787] hid-generic 0003:03F0:094A.0002: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
[ 173.262642] usb 2-2: USB disconnect, device number 7
[ 174.750244] usb 2-2: new low-speed USB device number 8 using xhci_hcd
[ 174.935740] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
[ 174.990435] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 175.014984] usb 2-2: Product: HP USB Optical Mouse
[ 175.037886] usb 2-2: Manufacturer: PixArt
[ 175.061794] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
[ 175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
Signed-off-by: Dave Young <dyoung(a)redhat.com>
Cc: stable(a)vger.kernel.org
Reviewed-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 5da3d6256d25..e75a2ad42ed8 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -535,6 +535,7 @@
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A 0x0a4a
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A 0x0b4a
#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE 0x134a
+#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A 0x094a
#define USB_VENDOR_ID_HUION 0x256c
#define USB_DEVICE_ID_HUION_TABLET 0x006e
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 20e68a7ac79f..8180c2740243 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -90,6 +90,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_IDEACOM, USB_DEVICE_ID_IDEACOM_IDC6680), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_INNOMEDIA, USB_DEVICE_ID_INNEX_GENESIS_ATARI), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X), HID_QUIRK_MULTI_INPUT },
The patch below does not apply to the 4.9-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 01cffe9ded15c0d664e0beb33c594e00c0d57bba Mon Sep 17 00:00:00 2001
From: Dave Young <dyoung(a)redhat.com>
Date: Fri, 1 Dec 2017 20:19:34 +0800
Subject: [PATCH] HID: add quirk for another PIXART OEM mouse used by HP
This mouse keep disconnecting in runleve 3 like below, add it needs the
quirk to mute the anoying messages.
[ 111.230555] usb 2-2: USB disconnect, device number 6
[ 112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd
[ 112.941594] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
[ 112.984866] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 113.027731] usb 2-2: Product: HP USB Optical Mouse
[ 113.069977] usb 2-2: Manufacturer: PixArt
[ 113.113500] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0002/input/input14
[ 113.156787] hid-generic 0003:03F0:094A.0002: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
[ 173.262642] usb 2-2: USB disconnect, device number 7
[ 174.750244] usb 2-2: new low-speed USB device number 8 using xhci_hcd
[ 174.935740] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
[ 174.990435] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 175.014984] usb 2-2: Product: HP USB Optical Mouse
[ 175.037886] usb 2-2: Manufacturer: PixArt
[ 175.061794] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
[ 175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
Signed-off-by: Dave Young <dyoung(a)redhat.com>
Cc: stable(a)vger.kernel.org
Reviewed-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 5da3d6256d25..e75a2ad42ed8 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -535,6 +535,7 @@
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A 0x0a4a
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A 0x0b4a
#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE 0x134a
+#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A 0x094a
#define USB_VENDOR_ID_HUION 0x256c
#define USB_DEVICE_ID_HUION_TABLET 0x006e
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 20e68a7ac79f..8180c2740243 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -90,6 +90,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_IDEACOM, USB_DEVICE_ID_IDEACOM_IDC6680), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_INNOMEDIA, USB_DEVICE_ID_INNEX_GENESIS_ATARI), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X), HID_QUIRK_MULTI_INPUT },
The patch below does not apply to the 4.19-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 01cffe9ded15c0d664e0beb33c594e00c0d57bba Mon Sep 17 00:00:00 2001
From: Dave Young <dyoung(a)redhat.com>
Date: Fri, 1 Dec 2017 20:19:34 +0800
Subject: [PATCH] HID: add quirk for another PIXART OEM mouse used by HP
This mouse keep disconnecting in runleve 3 like below, add it needs the
quirk to mute the anoying messages.
[ 111.230555] usb 2-2: USB disconnect, device number 6
[ 112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd
[ 112.941594] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
[ 112.984866] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 113.027731] usb 2-2: Product: HP USB Optical Mouse
[ 113.069977] usb 2-2: Manufacturer: PixArt
[ 113.113500] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0002/input/input14
[ 113.156787] hid-generic 0003:03F0:094A.0002: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
[ 173.262642] usb 2-2: USB disconnect, device number 7
[ 174.750244] usb 2-2: new low-speed USB device number 8 using xhci_hcd
[ 174.935740] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
[ 174.990435] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 175.014984] usb 2-2: Product: HP USB Optical Mouse
[ 175.037886] usb 2-2: Manufacturer: PixArt
[ 175.061794] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
[ 175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
Signed-off-by: Dave Young <dyoung(a)redhat.com>
Cc: stable(a)vger.kernel.org
Reviewed-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 5da3d6256d25..e75a2ad42ed8 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -535,6 +535,7 @@
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A 0x0a4a
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A 0x0b4a
#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE 0x134a
+#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A 0x094a
#define USB_VENDOR_ID_HUION 0x256c
#define USB_DEVICE_ID_HUION_TABLET 0x006e
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 20e68a7ac79f..8180c2740243 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -90,6 +90,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_IDEACOM, USB_DEVICE_ID_IDEACOM_IDC6680), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_INNOMEDIA, USB_DEVICE_ID_INNEX_GENESIS_ATARI), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X), HID_QUIRK_MULTI_INPUT },
The patch below does not apply to the 4.14-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 01cffe9ded15c0d664e0beb33c594e00c0d57bba Mon Sep 17 00:00:00 2001
From: Dave Young <dyoung(a)redhat.com>
Date: Fri, 1 Dec 2017 20:19:34 +0800
Subject: [PATCH] HID: add quirk for another PIXART OEM mouse used by HP
This mouse keep disconnecting in runleve 3 like below, add it needs the
quirk to mute the anoying messages.
[ 111.230555] usb 2-2: USB disconnect, device number 6
[ 112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd
[ 112.941594] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
[ 112.984866] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 113.027731] usb 2-2: Product: HP USB Optical Mouse
[ 113.069977] usb 2-2: Manufacturer: PixArt
[ 113.113500] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0002/input/input14
[ 113.156787] hid-generic 0003:03F0:094A.0002: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
[ 173.262642] usb 2-2: USB disconnect, device number 7
[ 174.750244] usb 2-2: new low-speed USB device number 8 using xhci_hcd
[ 174.935740] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
[ 174.990435] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 175.014984] usb 2-2: Product: HP USB Optical Mouse
[ 175.037886] usb 2-2: Manufacturer: PixArt
[ 175.061794] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
[ 175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
Signed-off-by: Dave Young <dyoung(a)redhat.com>
Cc: stable(a)vger.kernel.org
Reviewed-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 5da3d6256d25..e75a2ad42ed8 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -535,6 +535,7 @@
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A 0x0a4a
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A 0x0b4a
#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE 0x134a
+#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A 0x094a
#define USB_VENDOR_ID_HUION 0x256c
#define USB_DEVICE_ID_HUION_TABLET 0x006e
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 20e68a7ac79f..8180c2740243 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -90,6 +90,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_IDEACOM, USB_DEVICE_ID_IDEACOM_IDC6680), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_INNOMEDIA, USB_DEVICE_ID_INNEX_GENESIS_ATARI), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X), HID_QUIRK_MULTI_INPUT },
The patch below does not apply to the 4.15-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 01cffe9ded15c0d664e0beb33c594e00c0d57bba Mon Sep 17 00:00:00 2001
From: Dave Young <dyoung(a)redhat.com>
Date: Fri, 1 Dec 2017 20:19:34 +0800
Subject: [PATCH] HID: add quirk for another PIXART OEM mouse used by HP
This mouse keep disconnecting in runleve 3 like below, add it needs the
quirk to mute the anoying messages.
[ 111.230555] usb 2-2: USB disconnect, device number 6
[ 112.718156] usb 2-2: new low-speed USB device number 7 using xhci_hcd
[ 112.941594] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
[ 112.984866] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 113.027731] usb 2-2: Product: HP USB Optical Mouse
[ 113.069977] usb 2-2: Manufacturer: PixArt
[ 113.113500] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0002/input/input14
[ 113.156787] hid-generic 0003:03F0:094A.0002: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
[ 173.262642] usb 2-2: USB disconnect, device number 7
[ 174.750244] usb 2-2: new low-speed USB device number 8 using xhci_hcd
[ 174.935740] usb 2-2: New USB device found, idVendor=03f0, idProduct=094a
[ 174.990435] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 175.014984] usb 2-2: Product: HP USB Optical Mouse
[ 175.037886] usb 2-2: Manufacturer: PixArt
[ 175.061794] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/0003:03F0:094A.0003/input/input15
[ 175.084946] hid-generic 0003:03F0:094A.0003: input: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:00:14.0-2/input0
Signed-off-by: Dave Young <dyoung(a)redhat.com>
Cc: stable(a)vger.kernel.org
Reviewed-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 5da3d6256d25..e75a2ad42ed8 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -535,6 +535,7 @@
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A 0x0a4a
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A 0x0b4a
#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE 0x134a
+#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A 0x094a
#define USB_VENDOR_ID_HUION 0x256c
#define USB_DEVICE_ID_HUION_TABLET 0x006e
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 20e68a7ac79f..8180c2740243 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -90,6 +90,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE), HID_QUIRK_ALWAYS_POLL },
+ { HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_IDEACOM, USB_DEVICE_ID_IDEACOM_IDC6680), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_INNOMEDIA, USB_DEVICE_ID_INNEX_GENESIS_ATARI), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M610X), HID_QUIRK_MULTI_INPUT },
The patch below does not apply to the 4.4-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 0e410e158e5baa1300bdf678cea4f4e0cf9d8b94 Mon Sep 17 00:00:00 2001
From: Andrey Konovalov <andreyknvl(a)google.com>
Date: Tue, 6 Feb 2018 15:36:00 -0800
Subject: [PATCH] kasan: don't emit builtin calls when sanitization is off
With KASAN enabled the kernel has two different memset() functions, one
with KASAN checks (memset) and one without (__memset). KASAN uses some
macro tricks to use the proper version where required. For example
memset() calls in mm/slub.c are without KASAN checks, since they operate
on poisoned slab object metadata.
The issue is that clang emits memset() calls even when there is no
memset() in the source code. They get linked with improper memset()
implementation and the kernel fails to boot due to a huge amount of KASAN
reports during early boot stages.
The solution is to add -fno-builtin flag for files with KASAN_SANITIZE :=
n marker.
Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.151638459…
Signed-off-by: Andrey Konovalov <andreyknvl(a)google.com>
Acked-by: Nick Desaulniers <ndesaulniers(a)google.com>
Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Cc: Michal Marek <michal.lkml(a)markovi.net>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
diff --git a/Makefile b/Makefile
index 11aff0f9e105..0d49ff4022fb 100644
--- a/Makefile
+++ b/Makefile
@@ -434,7 +434,8 @@ export MAKE LEX YACC AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
-export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_KASAN CFLAGS_UBSAN
+export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
+export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE CFLAGS_UBSAN
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
index 1ce7115aa499..94c9e65cc83a 100644
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -31,4 +31,7 @@ else
endif
CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
+
+CFLAGS_KASAN_NOSANITIZE := -fno-builtin
+
endif
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 5fdc1a19b02c..5589bae34af6 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -121,7 +121,7 @@ endif
ifeq ($(CONFIG_KASAN),y)
_c_flags += $(if $(patsubst n%,, \
$(KASAN_SANITIZE_$(basetarget).o)$(KASAN_SANITIZE)y), \
- $(CFLAGS_KASAN))
+ $(CFLAGS_KASAN), $(CFLAGS_KASAN_NOSANITIZE))
endif
ifeq ($(CONFIG_UBSAN),y)
The patch below does not apply to the 4.9-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 0e410e158e5baa1300bdf678cea4f4e0cf9d8b94 Mon Sep 17 00:00:00 2001
From: Andrey Konovalov <andreyknvl(a)google.com>
Date: Tue, 6 Feb 2018 15:36:00 -0800
Subject: [PATCH] kasan: don't emit builtin calls when sanitization is off
With KASAN enabled the kernel has two different memset() functions, one
with KASAN checks (memset) and one without (__memset). KASAN uses some
macro tricks to use the proper version where required. For example
memset() calls in mm/slub.c are without KASAN checks, since they operate
on poisoned slab object metadata.
The issue is that clang emits memset() calls even when there is no
memset() in the source code. They get linked with improper memset()
implementation and the kernel fails to boot due to a huge amount of KASAN
reports during early boot stages.
The solution is to add -fno-builtin flag for files with KASAN_SANITIZE :=
n marker.
Link: http://lkml.kernel.org/r/8ffecfffe04088c52c42b92739c2bd8a0bcb3f5e.151638459…
Signed-off-by: Andrey Konovalov <andreyknvl(a)google.com>
Acked-by: Nick Desaulniers <ndesaulniers(a)google.com>
Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Cc: Michal Marek <michal.lkml(a)markovi.net>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Dmitry Vyukov <dvyukov(a)google.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
diff --git a/Makefile b/Makefile
index 11aff0f9e105..0d49ff4022fb 100644
--- a/Makefile
+++ b/Makefile
@@ -434,7 +434,8 @@ export MAKE LEX YACC AWK GENKSYMS INSTALLKERNEL PERL PYTHON UTS_MACHINE
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
-export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE CFLAGS_KASAN CFLAGS_UBSAN
+export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
+export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE CFLAGS_UBSAN
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
index 1ce7115aa499..94c9e65cc83a 100644
--- a/scripts/Makefile.kasan
+++ b/scripts/Makefile.kasan
@@ -31,4 +31,7 @@ else
endif
CFLAGS_KASAN += $(call cc-option, -fsanitize-address-use-after-scope)
+
+CFLAGS_KASAN_NOSANITIZE := -fno-builtin
+
endif
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 5fdc1a19b02c..5589bae34af6 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -121,7 +121,7 @@ endif
ifeq ($(CONFIG_KASAN),y)
_c_flags += $(if $(patsubst n%,, \
$(KASAN_SANITIZE_$(basetarget).o)$(KASAN_SANITIZE)y), \
- $(CFLAGS_KASAN))
+ $(CFLAGS_KASAN), $(CFLAGS_KASAN_NOSANITIZE))
endif
ifeq ($(CONFIG_UBSAN),y)
The patch below does not apply to the 4.4-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 f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb Mon Sep 17 00:00:00 2001
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Tue, 5 Dec 2017 09:29:19 +0200
Subject: [PATCH] btrfs: Handle btrfs_set_extent_delalloc failure in fixup
worker
This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers
to deal with pages that have been improperly dirtied") and it didn't do
any error handling then. This function might very well fail in ENOMEM
situation, yet it's not handled, this could lead to inconsistent state.
So let's handle the failure by setting the mapping error bit.
Cc: stable(a)vger.kernel.org
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 034d7333b14d..9ad8c9321c8f 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2116,8 +2116,15 @@ static void btrfs_writepage_fixup_worker(struct btrfs_work *work)
goto out;
}
- btrfs_set_extent_delalloc(inode, page_start, page_end, 0, &cached_state,
- 0);
+ ret = btrfs_set_extent_delalloc(inode, page_start, page_end, 0,
+ &cached_state, 0);
+ if (ret) {
+ mapping_set_error(page->mapping, ret);
+ end_extent_writepage(page, ret, page_start, page_end);
+ ClearPageChecked(page);
+ goto out;
+ }
+
ClearPageChecked(page);
set_page_dirty(page);
btrfs_delalloc_release_extents(BTRFS_I(inode), PAGE_SIZE);
The patch below does not apply to the 4.9-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 f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb Mon Sep 17 00:00:00 2001
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Tue, 5 Dec 2017 09:29:19 +0200
Subject: [PATCH] btrfs: Handle btrfs_set_extent_delalloc failure in fixup
worker
This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers
to deal with pages that have been improperly dirtied") and it didn't do
any error handling then. This function might very well fail in ENOMEM
situation, yet it's not handled, this could lead to inconsistent state.
So let's handle the failure by setting the mapping error bit.
Cc: stable(a)vger.kernel.org
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 034d7333b14d..9ad8c9321c8f 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2116,8 +2116,15 @@ static void btrfs_writepage_fixup_worker(struct btrfs_work *work)
goto out;
}
- btrfs_set_extent_delalloc(inode, page_start, page_end, 0, &cached_state,
- 0);
+ ret = btrfs_set_extent_delalloc(inode, page_start, page_end, 0,
+ &cached_state, 0);
+ if (ret) {
+ mapping_set_error(page->mapping, ret);
+ end_extent_writepage(page, ret, page_start, page_end);
+ ClearPageChecked(page);
+ goto out;
+ }
+
ClearPageChecked(page);
set_page_dirty(page);
btrfs_delalloc_release_extents(BTRFS_I(inode), PAGE_SIZE);
The patch below does not apply to the 4.14-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 f3038ee3a3f1017a1cbe9907e31fa12d366c5dcb Mon Sep 17 00:00:00 2001
From: Nikolay Borisov <nborisov(a)suse.com>
Date: Tue, 5 Dec 2017 09:29:19 +0200
Subject: [PATCH] btrfs: Handle btrfs_set_extent_delalloc failure in fixup
worker
This function was introduced by 247e743cbe6e ("Btrfs: Use async helpers
to deal with pages that have been improperly dirtied") and it didn't do
any error handling then. This function might very well fail in ENOMEM
situation, yet it's not handled, this could lead to inconsistent state.
So let's handle the failure by setting the mapping error bit.
Cc: stable(a)vger.kernel.org
Signed-off-by: Nikolay Borisov <nborisov(a)suse.com>
Reviewed-by: Qu Wenruo <wqu(a)suse.com>
Reviewed-by: David Sterba <dsterba(a)suse.com>
Signed-off-by: David Sterba <dsterba(a)suse.com>
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 034d7333b14d..9ad8c9321c8f 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2116,8 +2116,15 @@ static void btrfs_writepage_fixup_worker(struct btrfs_work *work)
goto out;
}
- btrfs_set_extent_delalloc(inode, page_start, page_end, 0, &cached_state,
- 0);
+ ret = btrfs_set_extent_delalloc(inode, page_start, page_end, 0,
+ &cached_state, 0);
+ if (ret) {
+ mapping_set_error(page->mapping, ret);
+ end_extent_writepage(page, ret, page_start, page_end);
+ ClearPageChecked(page);
+ goto out;
+ }
+
ClearPageChecked(page);
set_page_dirty(page);
btrfs_delalloc_release_extents(BTRFS_I(inode), PAGE_SIZE);
The patch below does not apply to the 4.14-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 5c256045b87b8aa8e5bc9d2e2fdc0802351c1f99 Mon Sep 17 00:00:00 2001
From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
Date: Fri, 5 Jan 2018 14:55:33 -0600
Subject: [PATCH] ASoC: acpi: fix machine driver selection based on quirk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The ACPI/machine-driver code refactoring introduced in 4.13 introduced
a regression for cases where we need a DMI-based quirk to select the
machine driver (the BIOS reports an invalid HID). The fix is just to
make sure the results of the quirk are actually used.
Fixes: 54746dabf770 ('ASoC: Improve machine driver selection based on quirk data')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96691
Tested-by: Nicole Færber <nicole.faerber(a)dpin.de>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
diff --git a/sound/soc/soc-acpi.c b/sound/soc/soc-acpi.c
index f21df28bc28e..d4dd2efea45e 100644
--- a/sound/soc/soc-acpi.c
+++ b/sound/soc/soc-acpi.c
@@ -84,11 +84,9 @@ snd_soc_acpi_find_machine(struct snd_soc_acpi_mach *machines)
for (mach = machines; mach->id[0]; mach++) {
if (snd_soc_acpi_check_hid(mach->id) == true) {
- if (mach->machine_quirk == NULL)
- return mach;
-
- if (mach->machine_quirk(mach) != NULL)
- return mach;
+ if (mach->machine_quirk)
+ mach = mach->machine_quirk(mach);
+ return mach;
}
}
return NULL;
On Sun, Feb 11, 2018 at 08:25:00AM +0100, Nikola Ciprich wrote:
> Hi,
> > My crashes started after switching from 4.9 to 4.14. Rumors have it they
> > started somewhere 4.13-ish and are gone 4.15. Will check if time
> > permits.
>
> it's been introduced by 4.14 and seems to be fixed by
> 2a266f23550be997d783f27e704b9b40c4010292 (no crash with it applied so
> far for me). Greg already has it queued for next 4.14.x release.
I do? I don't see it in my queue anywhere. Are you sure I've applied
it?
confused,
greg k-h
From: Hans Verkuil <hans.verkuil(a)cisco.com>
This patch series fixes a number of bugs and culminates in the removal
of the set_fs(KERNEL_DS) call in v4l2-compat-ioctl32.c.
This was tested with a VM running 4.9, the vivid driver (since that
emulates almost all V4L2 ioctls that need to pass through v4l2-compat-ioctl32.c)
and a 32-bit v4l2-compliance utility since that exercises almost all ioctls
as well. Combined this gives good test coverage.
Most of the v4l2-compat-ioctl32.c do cleanups and fix subtle issues that
v4l2-compliance complained about. The purpose is to 1) make it easy to
verify that the final patch didn't introduce errors by first eliminating
errors caused by other bugs, and 2) keep the final patch at least somewhat
readable.
Regards,
Hans
Daniel Mentz (2):
media: v4l2-compat-ioctl32: Copy v4l2_window->global_alpha
media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic
Hans Verkuil (11):
media: v4l2-ioctl.c: don't copy back the result for -ENOTTY
media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF
media: v4l2-compat-ioctl32.c: fix the indentation
media: v4l2-compat-ioctl32.c: move 'helper' functions to
__get/put_v4l2_format32
media: v4l2-compat-ioctl32.c: avoid sizeof(type)
media: v4l2-compat-ioctl32.c: copy m.userptr in put_v4l2_plane32
media: v4l2-compat-ioctl32.c: fix ctrl_is_pointer
media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs
media: v4l2-compat-ioctl32.c: copy clip list in put_v4l2_window32
media: v4l2-compat-ioctl32.c: drop pr_info for unknown buffer type
media: v4l2-compat-ioctl32.c: don't copy back the result for certain
errors
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 1023 +++++++++++++++----------
drivers/media/v4l2-core/v4l2-ioctl.c | 5 +-
2 files changed, 618 insertions(+), 410 deletions(-)
--
2.15.1
From: Hans Verkuil <hans.verkuil(a)cisco.com>
This patch series fixes a number of bugs and culminates in the removal
of the set_fs(KERNEL_DS) call in v4l2-compat-ioctl32.c.
This was tested with a VM running 4.14, the vivid driver (since that
emulates almost all V4L2 ioctls that need to pass through v4l2-compat-ioctl32.c)
and a 32-bit v4l2-compliance utility since that exercises almost all ioctls
as well. Combined this gives good test coverage.
Most of the v4l2-compat-ioctl32.c do cleanups and fix subtle issues that
v4l2-compliance complained about. The purpose is to 1) make it easy to
verify that the final patch didn't introduce errors by first eliminating
errors caused by other bugs, and 2) keep the final patch at least somewhat
readable.
Rgards,
Hans
Daniel Mentz (1):
media: v4l2-compat-ioctl32.c: refactor compat ioctl32 logic
Hans Verkuil (12):
media: v4l2-ioctl.c: use check_fmt for enum/g/s/try_fmt
media: v4l2-ioctl.c: don't copy back the result for -ENOTTY
media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF
media: v4l2-compat-ioctl32.c: fix the indentation
media: v4l2-compat-ioctl32.c: move 'helper' functions to
__get/put_v4l2_format32
media: v4l2-compat-ioctl32.c: avoid sizeof(type)
media: v4l2-compat-ioctl32.c: copy m.userptr in put_v4l2_plane32
media: v4l2-compat-ioctl32.c: fix ctrl_is_pointer
media: v4l2-compat-ioctl32.c: copy clip list in put_v4l2_window32
media: v4l2-compat-ioctl32.c: drop pr_info for unknown buffer type
media: v4l2-compat-ioctl32.c: don't copy back the result for certain
errors
media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 1032 +++++++++++++++----------
drivers/media/v4l2-core/v4l2-ioctl.c | 145 ++--
2 files changed, 665 insertions(+), 512 deletions(-)
--
2.15.1
This is a note to let you know that I've just added the patch titled
media: v4l2-ioctl.c: don't copy back the result for -ENOTTY
to the 4.15-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:
media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
and it can be found in the queue-4.15 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 181a4a2d5a0a7b43cab08a70710d727e7764ccdd Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hans.verkuil(a)cisco.com>
Date: Tue, 30 Jan 2018 03:50:01 -0500
Subject: media: v4l2-ioctl.c: don't copy back the result for -ENOTTY
From: Hans Verkuil <hans.verkuil(a)cisco.com>
commit 181a4a2d5a0a7b43cab08a70710d727e7764ccdd upstream.
If the ioctl returned -ENOTTY, then don't bother copying
back the result as there is no point.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-ioctl.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -2895,8 +2895,11 @@ video_usercopy(struct file *file, unsign
/* Handles IOCTL */
err = func(file, cmd, parg);
- if (err == -ENOIOCTLCMD)
+ if (err == -ENOTTY || err == -ENOIOCTLCMD) {
err = -ENOTTY;
+ goto out;
+ }
+
if (err == 0) {
if (cmd == VIDIOC_DQBUF)
trace_v4l2_dqbuf(video_devdata(file)->minor, parg);
Patches currently in stable-queue which might be from hans.verkuil(a)cisco.com are
queue-4.15/media-hdpvr-fix-an-error-handling-path-in-hdpvr_probe.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-4.15/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-4.15/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-4.15/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-4.15/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-4.15/media-v4l2-ioctl.c-use-check_fmt-for-enum-g-s-try_fmt.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
This is a note to let you know that I've just added the patch titled
media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs
to the 4.15-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:
media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
and it can be found in the queue-4.15 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 273caa260035c03d89ad63d72d8cd3d9e5c5e3f1 Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hansverk(a)cisco.com>
Date: Tue, 30 Jan 2018 10:18:32 -0500
Subject: media: v4l2-compat-ioctl32.c: make ctrl_is_pointer work for subdevs
From: Hans Verkuil <hansverk(a)cisco.com>
commit 273caa260035c03d89ad63d72d8cd3d9e5c5e3f1 upstream.
If the device is of type VFL_TYPE_SUBDEV then vdev->ioctl_ops
is NULL so the 'if (!ops->vidioc_query_ext_ctrl)' check would crash.
Add a test for !ops to the condition.
All sub-devices that have controls will use the control framework,
so they do not have an equivalent to ops->vidioc_query_ext_ctrl.
Returning false if ops is NULL is the correct thing to do here.
Fixes: b8c601e8af ("v4l2-compat-ioctl32.c: fix ctrl_is_pointer")
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Reported-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -770,7 +770,7 @@ static inline bool ctrl_is_pointer(struc
return ctrl && ctrl->is_ptr;
}
- if (!ops->vidioc_query_ext_ctrl)
+ if (!ops || !ops->vidioc_query_ext_ctrl)
return false;
return !ops->vidioc_query_ext_ctrl(file, fh, &qec) &&
Patches currently in stable-queue which might be from hansverk(a)cisco.com are
queue-4.15/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
This is a note to let you know that I've just added the patch titled
media: v4l2-compat-ioctl32.c: fix ctrl_is_pointer
to the 4.15-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:
media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
and it can be found in the queue-4.15 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 b8c601e8af2d08f733d74defa8465303391bb930 Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hans.verkuil(a)cisco.com>
Date: Wed, 24 Jan 2018 05:30:59 -0500
Subject: media: v4l2-compat-ioctl32.c: fix ctrl_is_pointer
From: Hans Verkuil <hans.verkuil(a)cisco.com>
commit b8c601e8af2d08f733d74defa8465303391bb930 upstream.
ctrl_is_pointer just hardcoded two known string controls, but that
caused problems when using e.g. custom controls that use a pointer
for the payload.
Reimplement this function: it now finds the v4l2_ctrl (if the driver
uses the control framework) or it calls vidioc_query_ext_ctrl (if the
driver implements that directly).
In both cases it can now check if the control is a pointer control
or not.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 59 +++++++++++++++++---------
1 file changed, 39 insertions(+), 20 deletions(-)
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -18,6 +18,8 @@
#include <linux/videodev2.h>
#include <linux/v4l2-subdev.h>
#include <media/v4l2-dev.h>
+#include <media/v4l2-fh.h>
+#include <media/v4l2-ctrls.h>
#include <media/v4l2-ioctl.h>
static long native_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
@@ -601,24 +603,39 @@ struct v4l2_ext_control32 {
};
} __attribute__ ((packed));
-/* The following function really belong in v4l2-common, but that causes
- a circular dependency between modules. We need to think about this, but
- for now this will do. */
-
-/* Return non-zero if this control is a pointer type. Currently only
- type STRING is a pointer type. */
-static inline int ctrl_is_pointer(u32 id)
-{
- switch (id) {
- case V4L2_CID_RDS_TX_PS_NAME:
- case V4L2_CID_RDS_TX_RADIO_TEXT:
- return 1;
- default:
- return 0;
+/* Return true if this control is a pointer type. */
+static inline bool ctrl_is_pointer(struct file *file, u32 id)
+{
+ struct video_device *vdev = video_devdata(file);
+ struct v4l2_fh *fh = NULL;
+ struct v4l2_ctrl_handler *hdl = NULL;
+ struct v4l2_query_ext_ctrl qec = { id };
+ const struct v4l2_ioctl_ops *ops = vdev->ioctl_ops;
+
+ if (test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags))
+ fh = file->private_data;
+
+ if (fh && fh->ctrl_handler)
+ hdl = fh->ctrl_handler;
+ else if (vdev->ctrl_handler)
+ hdl = vdev->ctrl_handler;
+
+ if (hdl) {
+ struct v4l2_ctrl *ctrl = v4l2_ctrl_find(hdl, id);
+
+ return ctrl && ctrl->is_ptr;
}
+
+ if (!ops->vidioc_query_ext_ctrl)
+ return false;
+
+ return !ops->vidioc_query_ext_ctrl(file, fh, &qec) &&
+ (qec.flags & V4L2_CTRL_FLAG_HAS_PAYLOAD);
}
-static int get_v4l2_ext_controls32(struct v4l2_ext_controls *kp, struct v4l2_ext_controls32 __user *up)
+static int get_v4l2_ext_controls32(struct file *file,
+ struct v4l2_ext_controls *kp,
+ struct v4l2_ext_controls32 __user *up)
{
struct v4l2_ext_control32 __user *ucontrols;
struct v4l2_ext_control __user *kcontrols;
@@ -651,7 +668,7 @@ static int get_v4l2_ext_controls32(struc
return -EFAULT;
if (get_user(id, &kcontrols->id))
return -EFAULT;
- if (ctrl_is_pointer(id)) {
+ if (ctrl_is_pointer(file, id)) {
void __user *s;
if (get_user(p, &ucontrols->string))
@@ -666,7 +683,9 @@ static int get_v4l2_ext_controls32(struc
return 0;
}
-static int put_v4l2_ext_controls32(struct v4l2_ext_controls *kp, struct v4l2_ext_controls32 __user *up)
+static int put_v4l2_ext_controls32(struct file *file,
+ struct v4l2_ext_controls *kp,
+ struct v4l2_ext_controls32 __user *up)
{
struct v4l2_ext_control32 __user *ucontrols;
struct v4l2_ext_control __user *kcontrols =
@@ -698,7 +717,7 @@ static int put_v4l2_ext_controls32(struc
/* Do not modify the pointer when copying a pointer control.
The contents of the pointer was changed, not the pointer
itself. */
- if (ctrl_is_pointer(id))
+ if (ctrl_is_pointer(file, id))
size -= sizeof(ucontrols->value64);
if (copy_in_user(ucontrols, kcontrols, size))
return -EFAULT;
@@ -912,7 +931,7 @@ static long do_video_ioctl(struct file *
case VIDIOC_G_EXT_CTRLS:
case VIDIOC_S_EXT_CTRLS:
case VIDIOC_TRY_EXT_CTRLS:
- err = get_v4l2_ext_controls32(&karg.v2ecs, up);
+ err = get_v4l2_ext_controls32(file, &karg.v2ecs, up);
compatible_arg = 0;
break;
case VIDIOC_DQEVENT:
@@ -939,7 +958,7 @@ static long do_video_ioctl(struct file *
case VIDIOC_G_EXT_CTRLS:
case VIDIOC_S_EXT_CTRLS:
case VIDIOC_TRY_EXT_CTRLS:
- if (put_v4l2_ext_controls32(&karg.v2ecs, up))
+ if (put_v4l2_ext_controls32(file, &karg.v2ecs, up))
err = -EFAULT;
break;
case VIDIOC_S_EDID:
Patches currently in stable-queue which might be from hans.verkuil(a)cisco.com are
queue-4.15/media-hdpvr-fix-an-error-handling-path-in-hdpvr_probe.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-4.15/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-4.15/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-4.15/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-4.15/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-4.15/media-v4l2-ioctl.c-use-check_fmt-for-enum-g-s-try_fmt.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
This is a note to let you know that I've just added the patch titled
media: v4l2-compat-ioctl32.c: don't copy back the result for certain errors
to the 4.15-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:
media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
and it can be found in the queue-4.15 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 d83a8243aaefe62ace433e4384a4f077bed86acb Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hans.verkuil(a)cisco.com>
Date: Fri, 26 Jan 2018 03:24:53 -0500
Subject: media: v4l2-compat-ioctl32.c: don't copy back the result for certain errors
From: Hans Verkuil <hans.verkuil(a)cisco.com>
commit d83a8243aaefe62ace433e4384a4f077bed86acb upstream.
Some ioctls need to copy back the result even if the ioctl returned
an error. However, don't do this for the error code -ENOTTY.
It makes no sense in that cases.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -968,6 +968,9 @@ static long do_video_ioctl(struct file *
set_fs(old_fs);
}
+ if (err == -ENOTTY)
+ return err;
+
/* Special case: even after an error we need to put the
results back for these ioctls since the error_idx will
contain information on which control failed. */
Patches currently in stable-queue which might be from hans.verkuil(a)cisco.com are
queue-4.15/media-hdpvr-fix-an-error-handling-path-in-hdpvr_probe.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-4.15/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-4.15/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-4.15/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-4.15/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-4.15/media-v4l2-ioctl.c-use-check_fmt-for-enum-g-s-try_fmt.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
This is a note to let you know that I've just added the patch titled
media: v4l2-compat-ioctl32.c: drop pr_info for unknown buffer type
to the 4.15-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:
media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
and it can be found in the queue-4.15 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 169f24ca68bf0f247d111aef07af00dd3a02ae88 Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hans.verkuil(a)cisco.com>
Date: Wed, 24 Jan 2018 09:33:57 -0500
Subject: media: v4l2-compat-ioctl32.c: drop pr_info for unknown buffer type
From: Hans Verkuil <hans.verkuil(a)cisco.com>
commit 169f24ca68bf0f247d111aef07af00dd3a02ae88 upstream.
There is nothing wrong with using an unknown buffer type. So
stop spamming the kernel log whenever this happens. The kernel
will just return -EINVAL to signal this.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 ----
1 file changed, 4 deletions(-)
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -179,8 +179,6 @@ static int __get_v4l2_format32(struct v4
return copy_from_user(&kp->fmt.meta, &up->fmt.meta,
sizeof(kp->fmt.meta)) ? -EFAULT : 0;
default:
- pr_info("compat_ioctl32: unexpected VIDIOC_FMT type %d\n",
- kp->type);
return -EINVAL;
}
}
@@ -233,8 +231,6 @@ static int __put_v4l2_format32(struct v4
return copy_to_user(&up->fmt.meta, &kp->fmt.meta,
sizeof(kp->fmt.meta)) ? -EFAULT : 0;
default:
- pr_info("compat_ioctl32: unexpected VIDIOC_FMT type %d\n",
- kp->type);
return -EINVAL;
}
}
Patches currently in stable-queue which might be from hans.verkuil(a)cisco.com are
queue-4.15/media-hdpvr-fix-an-error-handling-path-in-hdpvr_probe.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-4.15/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-4.15/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-4.15/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-4.15/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-4.15/media-v4l2-ioctl.c-use-check_fmt-for-enum-g-s-try_fmt.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
This is a note to let you know that I've just added the patch titled
media: v4l2-compat-ioctl32.c: copy m.userptr in put_v4l2_plane32
to the 4.15-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:
media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
and it can be found in the queue-4.15 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 8ed5a59dcb47a6f76034ee760b36e089f3e82529 Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hans.verkuil(a)cisco.com>
Date: Wed, 24 Jan 2018 05:19:59 -0500
Subject: media: v4l2-compat-ioctl32.c: copy m.userptr in put_v4l2_plane32
From: Hans Verkuil <hans.verkuil(a)cisco.com>
commit 8ed5a59dcb47a6f76034ee760b36e089f3e82529 upstream.
The struct v4l2_plane32 should set m.userptr as well. The same
happens in v4l2_buffer32 and v4l2-compliance tests for this.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 47 +++++++++++++++-----------
1 file changed, 28 insertions(+), 19 deletions(-)
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -310,19 +310,24 @@ static int get_v4l2_plane32(struct v4l2_
sizeof(up->data_offset)))
return -EFAULT;
- if (memory == V4L2_MEMORY_USERPTR) {
+ switch (memory) {
+ case V4L2_MEMORY_MMAP:
+ case V4L2_MEMORY_OVERLAY:
+ if (copy_in_user(&up->m.mem_offset, &up32->m.mem_offset,
+ sizeof(up32->m.mem_offset)))
+ return -EFAULT;
+ break;
+ case V4L2_MEMORY_USERPTR:
if (get_user(p, &up32->m.userptr))
return -EFAULT;
up_pln = compat_ptr(p);
if (put_user((unsigned long)up_pln, &up->m.userptr))
return -EFAULT;
- } else if (memory == V4L2_MEMORY_DMABUF) {
+ break;
+ case V4L2_MEMORY_DMABUF:
if (copy_in_user(&up->m.fd, &up32->m.fd, sizeof(up32->m.fd)))
return -EFAULT;
- } else {
- if (copy_in_user(&up->m.mem_offset, &up32->m.mem_offset,
- sizeof(up32->m.mem_offset)))
- return -EFAULT;
+ break;
}
return 0;
@@ -331,22 +336,32 @@ static int get_v4l2_plane32(struct v4l2_
static int put_v4l2_plane32(struct v4l2_plane __user *up, struct v4l2_plane32 __user *up32,
enum v4l2_memory memory)
{
+ unsigned long p;
+
if (copy_in_user(up32, up, 2 * sizeof(__u32)) ||
copy_in_user(&up32->data_offset, &up->data_offset,
sizeof(up->data_offset)))
return -EFAULT;
- /* For MMAP, driver might've set up the offset, so copy it back.
- * USERPTR stays the same (was userspace-provided), so no copying. */
- if (memory == V4L2_MEMORY_MMAP)
+ switch (memory) {
+ case V4L2_MEMORY_MMAP:
+ case V4L2_MEMORY_OVERLAY:
if (copy_in_user(&up32->m.mem_offset, &up->m.mem_offset,
sizeof(up->m.mem_offset)))
return -EFAULT;
- /* For DMABUF, driver might've set up the fd, so copy it back. */
- if (memory == V4L2_MEMORY_DMABUF)
+ break;
+ case V4L2_MEMORY_USERPTR:
+ if (get_user(p, &up->m.userptr) ||
+ put_user((compat_ulong_t)ptr_to_compat((__force void *)p),
+ &up32->m.userptr))
+ return -EFAULT;
+ break;
+ case V4L2_MEMORY_DMABUF:
if (copy_in_user(&up32->m.fd, &up->m.fd,
sizeof(up->m.fd)))
return -EFAULT;
+ break;
+ }
return 0;
}
@@ -408,6 +423,7 @@ static int get_v4l2_buffer32(struct v4l2
} else {
switch (kp->memory) {
case V4L2_MEMORY_MMAP:
+ case V4L2_MEMORY_OVERLAY:
if (get_user(kp->m.offset, &up->m.offset))
return -EFAULT;
break;
@@ -421,10 +437,6 @@ static int get_v4l2_buffer32(struct v4l2
kp->m.userptr = (unsigned long)compat_ptr(tmp);
}
break;
- case V4L2_MEMORY_OVERLAY:
- if (get_user(kp->m.offset, &up->m.offset))
- return -EFAULT;
- break;
case V4L2_MEMORY_DMABUF:
if (get_user(kp->m.fd, &up->m.fd))
return -EFAULT;
@@ -481,6 +493,7 @@ static int put_v4l2_buffer32(struct v4l2
} else {
switch (kp->memory) {
case V4L2_MEMORY_MMAP:
+ case V4L2_MEMORY_OVERLAY:
if (put_user(kp->m.offset, &up->m.offset))
return -EFAULT;
break;
@@ -488,10 +501,6 @@ static int put_v4l2_buffer32(struct v4l2
if (put_user(kp->m.userptr, &up->m.userptr))
return -EFAULT;
break;
- case V4L2_MEMORY_OVERLAY:
- if (put_user(kp->m.offset, &up->m.offset))
- return -EFAULT;
- break;
case V4L2_MEMORY_DMABUF:
if (put_user(kp->m.fd, &up->m.fd))
return -EFAULT;
Patches currently in stable-queue which might be from hans.verkuil(a)cisco.com are
queue-4.15/media-hdpvr-fix-an-error-handling-path-in-hdpvr_probe.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-4.15/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-4.15/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-4.15/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-4.15/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-4.15/media-v4l2-ioctl.c-use-check_fmt-for-enum-g-s-try_fmt.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
This is a note to let you know that I've just added the patch titled
media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF
to the 4.15-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:
media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
and it can be found in the queue-4.15 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 3ee6d040719ae09110e5cdf24d5386abe5d1b776 Mon Sep 17 00:00:00 2001
From: Hans Verkuil <hans.verkuil(a)cisco.com>
Date: Wed, 24 Jan 2018 08:37:04 -0500
Subject: media: v4l2-compat-ioctl32.c: add missing VIDIOC_PREPARE_BUF
From: Hans Verkuil <hans.verkuil(a)cisco.com>
commit 3ee6d040719ae09110e5cdf24d5386abe5d1b776 upstream.
The result of the VIDIOC_PREPARE_BUF ioctl was never copied back
to userspace since it was missing in the switch.
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Acked-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -1052,6 +1052,7 @@ static long do_video_ioctl(struct file *
err = put_v4l2_create32(&karg.v2crt, up);
break;
+ case VIDIOC_PREPARE_BUF:
case VIDIOC_QUERYBUF:
case VIDIOC_QBUF:
case VIDIOC_DQBUF:
Patches currently in stable-queue which might be from hans.verkuil(a)cisco.com are
queue-4.15/media-hdpvr-fix-an-error-handling-path-in-hdpvr_probe.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-m.userptr-in-put_v4l2_plane32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-avoid-sizeof-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-drop-pr_info-for-unknown-buffer-type.patch
queue-4.15/media-v4l2-compat-ioctl32.c-add-missing-vidioc_prepare_buf.patch
queue-4.15/media-v4l2-compat-ioctl32.c-refactor-compat-ioctl32-logic.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-ctrl_is_pointer.patch
queue-4.15/media-v4l2-compat-ioctl32.c-move-helper-functions-to-__get-put_v4l2_format32.patch
queue-4.15/media-v4l2-compat-ioctl32.c-don-t-copy-back-the-result-for-certain-errors.patch
queue-4.15/media-v4l2-compat-ioctl32.c-make-ctrl_is_pointer-work-for-subdevs.patch
queue-4.15/media-v4l2-compat-ioctl32.c-fix-the-indentation.patch
queue-4.15/media-v4l2-ioctl.c-don-t-copy-back-the-result-for-enotty.patch
queue-4.15/media-v4l2-ioctl.c-use-check_fmt-for-enum-g-s-try_fmt.patch
queue-4.15/media-v4l2-compat-ioctl32.c-copy-clip-list-in-put_v4l2_window32.patch
Hi Greg, can you please apply commit 073c516ff735 ("nsfs: mark dentry with
DCACHE_RCUACCESS") to 4.9-stable and 4.4-stable? I can reproduce the
use-after-free on those kernel versions (it was introduced in v3.19).
Thanks,
- Eric
This is a note to let you know that I've just added the patch titled
nsfs: mark dentry with DCACHE_RCUACCESS
to the 4.9-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:
nsfs-mark-dentry-with-dcache_rcuaccess.patch
and it can be found in the queue-4.9 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 073c516ff73557a8f7315066856c04b50383ac34 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Wed, 19 Apr 2017 15:11:00 -0700
Subject: nsfs: mark dentry with DCACHE_RCUACCESS
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit 073c516ff73557a8f7315066856c04b50383ac34 upstream.
Andrey reported a use-after-free in __ns_get_path():
spin_lock include/linux/spinlock.h:299 [inline]
lockref_get_not_dead+0x19/0x80 lib/lockref.c:179
__ns_get_path+0x197/0x860 fs/nsfs.c:66
open_related_ns+0xda/0x200 fs/nsfs.c:143
sock_ioctl+0x39d/0x440 net/socket.c:1001
vfs_ioctl fs/ioctl.c:45 [inline]
do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
SYSC_ioctl fs/ioctl.c:700 [inline]
SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
We are under rcu read lock protection at that point:
rcu_read_lock();
d = atomic_long_read(&ns->stashed);
if (!d)
goto slow;
dentry = (struct dentry *)d;
if (!lockref_get_not_dead(&dentry->d_lockref))
goto slow;
rcu_read_unlock();
but don't use a proper RCU API on the free path, therefore a parallel
__d_free() could free it at the same time. We need to mark the stashed
dentry with DCACHE_RCUACCESS so that __d_free() will be called after all
readers leave RCU.
Fixes: e149ed2b805f ("take the targets of /proc/*/ns/* symlinks to separate fs")
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nsfs.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/nsfs.c
+++ b/fs/nsfs.c
@@ -90,6 +90,7 @@ slow:
return ERR_PTR(-ENOMEM);
}
d_instantiate(dentry, inode);
+ dentry->d_flags |= DCACHE_RCUACCESS;
dentry->d_fsdata = (void *)ns->ops;
d = atomic_long_cmpxchg(&ns->stashed, 0, (unsigned long)dentry);
if (d) {
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.9/nsfs-mark-dentry-with-dcache_rcuaccess.patch
This is a note to let you know that I've just added the patch titled
nsfs: mark dentry with DCACHE_RCUACCESS
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:
nsfs-mark-dentry-with-dcache_rcuaccess.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 073c516ff73557a8f7315066856c04b50383ac34 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Wed, 19 Apr 2017 15:11:00 -0700
Subject: nsfs: mark dentry with DCACHE_RCUACCESS
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit 073c516ff73557a8f7315066856c04b50383ac34 upstream.
Andrey reported a use-after-free in __ns_get_path():
spin_lock include/linux/spinlock.h:299 [inline]
lockref_get_not_dead+0x19/0x80 lib/lockref.c:179
__ns_get_path+0x197/0x860 fs/nsfs.c:66
open_related_ns+0xda/0x200 fs/nsfs.c:143
sock_ioctl+0x39d/0x440 net/socket.c:1001
vfs_ioctl fs/ioctl.c:45 [inline]
do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
SYSC_ioctl fs/ioctl.c:700 [inline]
SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
We are under rcu read lock protection at that point:
rcu_read_lock();
d = atomic_long_read(&ns->stashed);
if (!d)
goto slow;
dentry = (struct dentry *)d;
if (!lockref_get_not_dead(&dentry->d_lockref))
goto slow;
rcu_read_unlock();
but don't use a proper RCU API on the free path, therefore a parallel
__d_free() could free it at the same time. We need to mark the stashed
dentry with DCACHE_RCUACCESS so that __d_free() will be called after all
readers leave RCU.
Fixes: e149ed2b805f ("take the targets of /proc/*/ns/* symlinks to separate fs")
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: Andrew Morton <akpm(a)linux-foundation.org>
Reported-by: Andrey Konovalov <andreyknvl(a)google.com>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Eric Biggers <ebiggers3(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nsfs.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/nsfs.c
+++ b/fs/nsfs.c
@@ -95,6 +95,7 @@ slow:
return ERR_PTR(-ENOMEM);
}
d_instantiate(dentry, inode);
+ dentry->d_flags |= DCACHE_RCUACCESS;
dentry->d_fsdata = (void *)ns_ops;
d = atomic_long_cmpxchg(&ns->stashed, 0, (unsigned long)dentry);
if (d) {
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.4/nsfs-mark-dentry-with-dcache_rcuaccess.patch
Nikola Ciprich wrote...
> it's been introduced by 4.14 and seems to be fixed by
> 2a266f23550be997d783f27e704b9b40c4010292 (no crash with it applied so
> far for me).
Thanks for sharing, running 4.14.19 with this additional one made all my
problems go away, although they were a bit different: Using the "Resume"
button in virt-manager after an earlier "Pause" caused the guest to
freeze and using 100% CPU - especially when the guest is the grml rescue
system, this happend almost always.
Christoph
This is a note to let you know that I've just added the patch titled
crypto: mcryptd - pass through absence of ->setkey()
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:
crypto-mcryptd-pass-through-absence-of-setkey.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 fa59b92d299f2787e6bae1ff078ee0982e80211f Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:24 -0800
Subject: crypto: mcryptd - pass through absence of ->setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit fa59b92d299f2787e6bae1ff078ee0982e80211f upstream.
When the mcryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the mcryptd instance. This change
is necessary for mcryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/mcryptd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/crypto/mcryptd.c
+++ b/crypto/mcryptd.c
@@ -540,7 +540,8 @@ static int mcryptd_create_hash(struct cr
inst->alg.finup = mcryptd_hash_finup_enqueue;
inst->alg.export = mcryptd_hash_export;
inst->alg.import = mcryptd_hash_import;
- inst->alg.setkey = mcryptd_hash_setkey;
+ if (crypto_hash_alg_has_setkey(halg))
+ inst->alg.setkey = mcryptd_hash_setkey;
inst->alg.digest = mcryptd_hash_digest_enqueue;
err = ahash_register_instance(tmpl, inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.4/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.4/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
queue-4.4/x86-kaiser-fix-build-error-with-kasan-function_graph_tracer.patch
queue-4.4/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.4/crypto-poly1305-remove-setkey-method.patch
queue-4.4/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.4/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: mcryptd - pass through absence of ->setkey()
to the 3.18-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:
crypto-mcryptd-pass-through-absence-of-setkey.patch
and it can be found in the queue-3.18 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 fa59b92d299f2787e6bae1ff078ee0982e80211f Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:24 -0800
Subject: crypto: mcryptd - pass through absence of ->setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit fa59b92d299f2787e6bae1ff078ee0982e80211f upstream.
When the mcryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the mcryptd instance. This change
is necessary for mcryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/mcryptd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/crypto/mcryptd.c
+++ b/crypto/mcryptd.c
@@ -514,7 +514,8 @@ static int mcryptd_create_hash(struct cr
inst->alg.finup = mcryptd_hash_finup_enqueue;
inst->alg.export = mcryptd_hash_export;
inst->alg.import = mcryptd_hash_import;
- inst->alg.setkey = mcryptd_hash_setkey;
+ if (crypto_hash_alg_has_setkey(halg))
+ inst->alg.setkey = mcryptd_hash_setkey;
inst->alg.digest = mcryptd_hash_digest_enqueue;
err = ahash_register_instance(tmpl, inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-3.18/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-3.18/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
queue-3.18/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-3.18/crypto-mcryptd-pass-through-absence-of-setkey.patch
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Turns out the VLV/CHV fixed function sprite CSC expects full range
data as input. We've been feeding it limited range data to it all
along. To expand the data out to full range we'll use the color
correction registers (brightness, contrast, and saturation).
On CHV pipe B we were actually doing the right thing already because we
progammed the custom CSC matrix to do expect limited range input. Now
that well pre-expand the data out with the color correction unit, we
need to change the CSC matrix to operate with full range input instead.
This should make the sprite output of the other pipes match the sprite
output of pipe B reasonably well. Looking at the resulting pipe CRCs,
there can be a slight difference in the output, but as I don't know
the formula used by the fixed function CSC of the other pipes, I don't
think it's worth the effort to try to match the output exactly. It
might not even be possible due to difference in internal precision etc.
One slight caveat here is that the color correction registers are single
bufferred, so we should really be updating them during vblank, but we
still don't have a mechanism for that, so just toss in another FIXME.
v2: Rebase
v3: s/bri/brightness/ s/con/contrast/ (Shashank)
v4: Clarify the constants and math (Shashank)
Cc: Harry Wentland <harry.wentland(a)amd.com>
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Cc: Daniel Stone <daniel(a)fooishbar.org>
Cc: Russell King - ARM Linux <linux(a)armlinux.org.uk>
Cc: Ilia Mirkin <imirkin(a)alum.mit.edu>
Cc: Hans Verkuil <hverkuil(a)xs4all.nl>
Cc: Shashank Sharma <shashank.sharma(a)intel.com>
Cc: Uma Shankar <uma.shankar(a)intel.com>
Cc: Jyri Sarha <jsarha(a)ti.com>
Cc: "Tang, Jun" <jun.tang(a)intel.com>
Reported-by: "Tang, Jun" <jun.tang(a)intel.com>
Cc: stable(a)vger.kernel.org
Fixes: 7f1f3851feb0 ("drm/i915: sprite support for ValleyView v4")
Reviewed-by: Shashank Sharma <shashank.sharma(a)intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
---
drivers/gpu/drm/i915/i915_reg.h | 10 +++++
drivers/gpu/drm/i915/intel_sprite.c | 81 ++++++++++++++++++++++++++++---------
2 files changed, 73 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f6afa5e5e7c1..28b36eac064e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6305,6 +6305,12 @@ enum {
#define _SPATILEOFF (VLV_DISPLAY_BASE + 0x721a4)
#define _SPACONSTALPHA (VLV_DISPLAY_BASE + 0x721a8)
#define SP_CONST_ALPHA_ENABLE (1<<31)
+#define _SPACLRC0 (VLV_DISPLAY_BASE + 0x721d0)
+#define SP_CONTRAST(x) ((x) << 18) /* u3.6 */
+#define SP_BRIGHTNESS(x) ((x) & 0xff) /* s8 */
+#define _SPACLRC1 (VLV_DISPLAY_BASE + 0x721d4)
+#define SP_SH_SIN(x) (((x) & 0x7ff) << 16) /* s4.7 */
+#define SP_SH_COS(x) (x) /* u3.7 */
#define _SPAGAMC (VLV_DISPLAY_BASE + 0x721f4)
#define _SPBCNTR (VLV_DISPLAY_BASE + 0x72280)
@@ -6318,6 +6324,8 @@ enum {
#define _SPBKEYMAXVAL (VLV_DISPLAY_BASE + 0x722a0)
#define _SPBTILEOFF (VLV_DISPLAY_BASE + 0x722a4)
#define _SPBCONSTALPHA (VLV_DISPLAY_BASE + 0x722a8)
+#define _SPBCLRC0 (VLV_DISPLAY_BASE + 0x722d0)
+#define _SPBCLRC1 (VLV_DISPLAY_BASE + 0x722d4)
#define _SPBGAMC (VLV_DISPLAY_BASE + 0x722f4)
#define _MMIO_VLV_SPR(pipe, plane_id, reg_a, reg_b) \
@@ -6334,6 +6342,8 @@ enum {
#define SPKEYMAXVAL(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id), _SPAKEYMAXVAL, _SPBKEYMAXVAL)
#define SPTILEOFF(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id), _SPATILEOFF, _SPBTILEOFF)
#define SPCONSTALPHA(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id), _SPACONSTALPHA, _SPBCONSTALPHA)
+#define SPCLRC0(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id), _SPACLRC0, _SPBCLRC0)
+#define SPCLRC1(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id), _SPACLRC1, _SPBCLRC1)
#define SPGAMC(pipe, plane_id) _MMIO_VLV_SPR((pipe), (plane_id), _SPAGAMC, _SPBGAMC)
/*
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index e098e4b2c85c..fac9e01b4795 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -346,44 +346,87 @@ skl_plane_get_hw_state(struct intel_plane *plane)
}
static void
-chv_update_csc(struct intel_plane *plane, uint32_t format)
+chv_update_csc(const struct intel_plane_state *plane_state)
{
+ struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ const struct drm_framebuffer *fb = plane_state->base.fb;
enum plane_id plane_id = plane->id;
/* Seems RGB data bypasses the CSC always */
- if (!format_is_yuv(format))
+ if (!format_is_yuv(fb->format->format))
return;
/*
- * BT.601 limited range YCbCr -> full range RGB
+ * BT.601 full range YCbCr -> full range RGB
*
- * |r| | 6537 4769 0| |cr |
- * |g| = |-3330 4769 -1605| x |y-64|
- * |b| | 0 4769 8263| |cb |
+ * |r| | 5743 4096 0| |cr|
+ * |g| = |-2925 4096 -1410| x |y |
+ * |b| | 0 4096 7258| |cb|
*
- * Cb and Cr apparently come in as signed already, so no
- * need for any offset. For Y we need to remove the offset.
+ * Cb and Cr apparently come in as signed already,
+ * and we get full range data in on account of CLRC0/1
*/
- I915_WRITE_FW(SPCSCYGOFF(plane_id), SPCSC_OOFF(0) | SPCSC_IOFF(-64));
+ I915_WRITE_FW(SPCSCYGOFF(plane_id), SPCSC_OOFF(0) | SPCSC_IOFF(0));
I915_WRITE_FW(SPCSCCBOFF(plane_id), SPCSC_OOFF(0) | SPCSC_IOFF(0));
I915_WRITE_FW(SPCSCCROFF(plane_id), SPCSC_OOFF(0) | SPCSC_IOFF(0));
- I915_WRITE_FW(SPCSCC01(plane_id), SPCSC_C1(4769) | SPCSC_C0(6537));
- I915_WRITE_FW(SPCSCC23(plane_id), SPCSC_C1(-3330) | SPCSC_C0(0));
- I915_WRITE_FW(SPCSCC45(plane_id), SPCSC_C1(-1605) | SPCSC_C0(4769));
- I915_WRITE_FW(SPCSCC67(plane_id), SPCSC_C1(4769) | SPCSC_C0(0));
- I915_WRITE_FW(SPCSCC8(plane_id), SPCSC_C0(8263));
+ I915_WRITE_FW(SPCSCC01(plane_id), SPCSC_C1(4096) | SPCSC_C0(5743));
+ I915_WRITE_FW(SPCSCC23(plane_id), SPCSC_C1(-2925) | SPCSC_C0(0));
+ I915_WRITE_FW(SPCSCC45(plane_id), SPCSC_C1(-1410) | SPCSC_C0(4096));
+ I915_WRITE_FW(SPCSCC67(plane_id), SPCSC_C1(4096) | SPCSC_C0(0));
+ I915_WRITE_FW(SPCSCC8(plane_id), SPCSC_C0(7258));
- I915_WRITE_FW(SPCSCYGICLAMP(plane_id), SPCSC_IMAX(940) | SPCSC_IMIN(64));
- I915_WRITE_FW(SPCSCCBICLAMP(plane_id), SPCSC_IMAX(448) | SPCSC_IMIN(-448));
- I915_WRITE_FW(SPCSCCRICLAMP(plane_id), SPCSC_IMAX(448) | SPCSC_IMIN(-448));
+ I915_WRITE_FW(SPCSCYGICLAMP(plane_id), SPCSC_IMAX(1023) | SPCSC_IMIN(0));
+ I915_WRITE_FW(SPCSCCBICLAMP(plane_id), SPCSC_IMAX(512) | SPCSC_IMIN(-512));
+ I915_WRITE_FW(SPCSCCRICLAMP(plane_id), SPCSC_IMAX(512) | SPCSC_IMIN(-512));
I915_WRITE_FW(SPCSCYGOCLAMP(plane_id), SPCSC_OMAX(1023) | SPCSC_OMIN(0));
I915_WRITE_FW(SPCSCCBOCLAMP(plane_id), SPCSC_OMAX(1023) | SPCSC_OMIN(0));
I915_WRITE_FW(SPCSCCROCLAMP(plane_id), SPCSC_OMAX(1023) | SPCSC_OMIN(0));
}
+#define SIN_0 0
+#define COS_0 1
+
+static void
+vlv_update_clrc(const struct intel_plane_state *plane_state)
+{
+ struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ const struct drm_framebuffer *fb = plane_state->base.fb;
+ enum pipe pipe = plane->pipe;
+ enum plane_id plane_id = plane->id;
+ int contrast, brightness, sh_scale, sh_sin, sh_cos;
+
+ if (format_is_yuv(fb->format->format)) {
+ /*
+ * Expand limited range to full range:
+ * Contrast is applied first and is used to expand Y range.
+ * Brightness is applied second and is used to remove the
+ * offset from Y. Saturation/hue is used to expand CbCr range.
+ */
+ contrast = DIV_ROUND_CLOSEST(255 << 6, 235 - 16);
+ brightness = -DIV_ROUND_CLOSEST(16 * 255, 235 - 16);
+ sh_scale = DIV_ROUND_CLOSEST(128 << 7, 240 - 128);
+ sh_sin = SIN_0 * sh_scale;
+ sh_cos = COS_0 * sh_scale;
+ } else {
+ /* Pass-through everything. */
+ contrast = 1 << 6;
+ brightness = 0;
+ sh_scale = 1 << 7;
+ sh_sin = SIN_0 * sh_scale;
+ sh_cos = COS_0 * sh_scale;
+ }
+
+ /* FIXME these register are single buffered :( */
+ I915_WRITE_FW(SPCLRC0(pipe, plane_id),
+ SP_CONTRAST(contrast) | SP_BRIGHTNESS(brightness));
+ I915_WRITE_FW(SPCLRC1(pipe, plane_id),
+ SP_SH_SIN(sh_sin) | SP_SH_COS(sh_cos));
+}
+
static u32 vlv_sprite_ctl(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state)
{
@@ -477,8 +520,10 @@ vlv_update_plane(struct intel_plane *plane,
spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+ vlv_update_clrc(plane_state);
+
if (IS_CHERRYVIEW(dev_priv) && pipe == PIPE_B)
- chv_update_csc(plane, fb->format->format);
+ chv_update_csc(plane_state);
if (key->flags) {
I915_WRITE_FW(SPKEYMINVAL(pipe, plane_id), key->min_value);
--
2.13.6
This is a note to let you know that I've just added the patch titled
crypto: poly1305 - remove ->setkey() method
to the 4.9-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:
crypto-poly1305-remove-setkey-method.patch
and it can be found in the queue-4.9 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 a16e772e664b9a261424107784804cffc8894977 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:25 -0800
Subject: crypto: poly1305 - remove ->setkey() method
From: Eric Biggers <ebiggers(a)google.com>
commit a16e772e664b9a261424107784804cffc8894977 upstream.
Since Poly1305 requires a nonce per invocation, the Linux kernel
implementations of Poly1305 don't use the crypto API's keying mechanism
and instead expect the key and nonce as the first 32 bytes of the data.
But ->setkey() is still defined as a stub returning an error code. This
prevents Poly1305 from being used through AF_ALG and will also break it
completely once we start enforcing that all crypto API users (not just
AF_ALG) call ->setkey() if present.
Fix it by removing crypto_poly1305_setkey(), leaving ->setkey as NULL.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/poly1305_glue.c | 1 -
crypto/poly1305_generic.c | 17 +++++------------
include/crypto/poly1305.h | 2 --
3 files changed, 5 insertions(+), 15 deletions(-)
--- a/arch/x86/crypto/poly1305_glue.c
+++ b/arch/x86/crypto/poly1305_glue.c
@@ -164,7 +164,6 @@ static struct shash_alg alg = {
.init = poly1305_simd_init,
.update = poly1305_simd_update,
.final = crypto_poly1305_final,
- .setkey = crypto_poly1305_setkey,
.descsize = sizeof(struct poly1305_simd_desc_ctx),
.base = {
.cra_name = "poly1305",
--- a/crypto/poly1305_generic.c
+++ b/crypto/poly1305_generic.c
@@ -51,17 +51,6 @@ int crypto_poly1305_init(struct shash_de
}
EXPORT_SYMBOL_GPL(crypto_poly1305_init);
-int crypto_poly1305_setkey(struct crypto_shash *tfm,
- const u8 *key, unsigned int keylen)
-{
- /* Poly1305 requires a unique key for each tag, which implies that
- * we can't set it on the tfm that gets accessed by multiple users
- * simultaneously. Instead we expect the key as the first 32 bytes in
- * the update() call. */
- return -ENOTSUPP;
-}
-EXPORT_SYMBOL_GPL(crypto_poly1305_setkey);
-
static void poly1305_setrkey(struct poly1305_desc_ctx *dctx, const u8 *key)
{
/* r &= 0xffffffc0ffffffc0ffffffc0fffffff */
@@ -80,6 +69,11 @@ static void poly1305_setskey(struct poly
dctx->s[3] = le32_to_cpuvp(key + 12);
}
+/*
+ * Poly1305 requires a unique key for each tag, which implies that we can't set
+ * it on the tfm that gets accessed by multiple users simultaneously. Instead we
+ * expect the key as the first 32 bytes in the update() call.
+ */
unsigned int crypto_poly1305_setdesckey(struct poly1305_desc_ctx *dctx,
const u8 *src, unsigned int srclen)
{
@@ -285,7 +279,6 @@ static struct shash_alg poly1305_alg = {
.init = crypto_poly1305_init,
.update = crypto_poly1305_update,
.final = crypto_poly1305_final,
- .setkey = crypto_poly1305_setkey,
.descsize = sizeof(struct poly1305_desc_ctx),
.base = {
.cra_name = "poly1305",
--- a/include/crypto/poly1305.h
+++ b/include/crypto/poly1305.h
@@ -30,8 +30,6 @@ struct poly1305_desc_ctx {
};
int crypto_poly1305_init(struct shash_desc *desc);
-int crypto_poly1305_setkey(struct crypto_shash *tfm,
- const u8 *key, unsigned int keylen);
unsigned int crypto_poly1305_setdesckey(struct poly1305_desc_ctx *dctx,
const u8 *src, unsigned int srclen);
int crypto_poly1305_update(struct shash_desc *desc,
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.9/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.9/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.9/crypto-poly1305-remove-setkey-method.patch
queue-4.9/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.9/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: mcryptd - pass through absence of ->setkey()
to the 4.9-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:
crypto-mcryptd-pass-through-absence-of-setkey.patch
and it can be found in the queue-4.9 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 fa59b92d299f2787e6bae1ff078ee0982e80211f Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:24 -0800
Subject: crypto: mcryptd - pass through absence of ->setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit fa59b92d299f2787e6bae1ff078ee0982e80211f upstream.
When the mcryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the mcryptd instance. This change
is necessary for mcryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/mcryptd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/crypto/mcryptd.c
+++ b/crypto/mcryptd.c
@@ -534,7 +534,8 @@ static int mcryptd_create_hash(struct cr
inst->alg.finup = mcryptd_hash_finup_enqueue;
inst->alg.export = mcryptd_hash_export;
inst->alg.import = mcryptd_hash_import;
- inst->alg.setkey = mcryptd_hash_setkey;
+ if (crypto_hash_alg_has_setkey(halg))
+ inst->alg.setkey = mcryptd_hash_setkey;
inst->alg.digest = mcryptd_hash_digest_enqueue;
err = ahash_register_instance(tmpl, inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.9/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.9/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.9/crypto-poly1305-remove-setkey-method.patch
queue-4.9/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.9/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: hash - introduce crypto_hash_alg_has_setkey()
to the 4.9-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:
crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
and it can be found in the queue-4.9 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 cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:22 -0800
Subject: crypto: hash - introduce crypto_hash_alg_has_setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba upstream.
Templates that use an shash spawn can use crypto_shash_alg_has_setkey()
to determine whether the underlying algorithm requires a key or not.
But there was no corresponding function for ahash spawns. Add it.
Note that the new function actually has to support both shash and ahash
algorithms, since the ahash API can be used with either.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/ahash.c | 11 +++++++++++
include/crypto/internal/hash.h | 2 ++
2 files changed, 13 insertions(+)
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -625,5 +625,16 @@ struct hash_alg_common *ahash_attr_alg(s
}
EXPORT_SYMBOL_GPL(ahash_attr_alg);
+bool crypto_hash_alg_has_setkey(struct hash_alg_common *halg)
+{
+ struct crypto_alg *alg = &halg->base;
+
+ if (alg->cra_type != &crypto_ahash_type)
+ return crypto_shash_alg_has_setkey(__crypto_shash_alg(alg));
+
+ return __crypto_ahash_alg(alg)->setkey != NULL;
+}
+EXPORT_SYMBOL_GPL(crypto_hash_alg_has_setkey);
+
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Asynchronous cryptographic hash type");
--- a/include/crypto/internal/hash.h
+++ b/include/crypto/internal/hash.h
@@ -88,6 +88,8 @@ static inline bool crypto_shash_alg_has_
return alg->setkey != shash_no_setkey;
}
+bool crypto_hash_alg_has_setkey(struct hash_alg_common *halg);
+
int crypto_init_ahash_spawn(struct crypto_ahash_spawn *spawn,
struct hash_alg_common *alg,
struct crypto_instance *inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.9/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.9/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.9/crypto-poly1305-remove-setkey-method.patch
queue-4.9/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.9/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: cryptd - pass through absence of ->setkey()
to the 4.9-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:
crypto-cryptd-pass-through-absence-of-setkey.patch
and it can be found in the queue-4.9 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 841a3ff329713f796a63356fef6e2f72e4a3f6a3 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:23 -0800
Subject: crypto: cryptd - pass through absence of ->setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit 841a3ff329713f796a63356fef6e2f72e4a3f6a3 upstream.
When the cryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the cryptd instance. This change
is necessary for cryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/cryptd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -691,7 +691,8 @@ static int cryptd_create_hash(struct cry
inst->alg.finup = cryptd_hash_finup_enqueue;
inst->alg.export = cryptd_hash_export;
inst->alg.import = cryptd_hash_import;
- inst->alg.setkey = cryptd_hash_setkey;
+ if (crypto_shash_alg_has_setkey(salg))
+ inst->alg.setkey = cryptd_hash_setkey;
inst->alg.digest = cryptd_hash_digest_enqueue;
err = ahash_register_instance(tmpl, inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.9/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.9/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.9/crypto-poly1305-remove-setkey-method.patch
queue-4.9/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.9/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: poly1305 - remove ->setkey() method
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:
crypto-poly1305-remove-setkey-method.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 a16e772e664b9a261424107784804cffc8894977 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:25 -0800
Subject: crypto: poly1305 - remove ->setkey() method
From: Eric Biggers <ebiggers(a)google.com>
commit a16e772e664b9a261424107784804cffc8894977 upstream.
Since Poly1305 requires a nonce per invocation, the Linux kernel
implementations of Poly1305 don't use the crypto API's keying mechanism
and instead expect the key and nonce as the first 32 bytes of the data.
But ->setkey() is still defined as a stub returning an error code. This
prevents Poly1305 from being used through AF_ALG and will also break it
completely once we start enforcing that all crypto API users (not just
AF_ALG) call ->setkey() if present.
Fix it by removing crypto_poly1305_setkey(), leaving ->setkey as NULL.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/poly1305_glue.c | 1 -
crypto/poly1305_generic.c | 17 +++++------------
include/crypto/poly1305.h | 2 --
3 files changed, 5 insertions(+), 15 deletions(-)
--- a/arch/x86/crypto/poly1305_glue.c
+++ b/arch/x86/crypto/poly1305_glue.c
@@ -164,7 +164,6 @@ static struct shash_alg alg = {
.init = poly1305_simd_init,
.update = poly1305_simd_update,
.final = crypto_poly1305_final,
- .setkey = crypto_poly1305_setkey,
.descsize = sizeof(struct poly1305_simd_desc_ctx),
.base = {
.cra_name = "poly1305",
--- a/crypto/poly1305_generic.c
+++ b/crypto/poly1305_generic.c
@@ -51,17 +51,6 @@ int crypto_poly1305_init(struct shash_de
}
EXPORT_SYMBOL_GPL(crypto_poly1305_init);
-int crypto_poly1305_setkey(struct crypto_shash *tfm,
- const u8 *key, unsigned int keylen)
-{
- /* Poly1305 requires a unique key for each tag, which implies that
- * we can't set it on the tfm that gets accessed by multiple users
- * simultaneously. Instead we expect the key as the first 32 bytes in
- * the update() call. */
- return -ENOTSUPP;
-}
-EXPORT_SYMBOL_GPL(crypto_poly1305_setkey);
-
static void poly1305_setrkey(struct poly1305_desc_ctx *dctx, const u8 *key)
{
/* r &= 0xffffffc0ffffffc0ffffffc0fffffff */
@@ -80,6 +69,11 @@ static void poly1305_setskey(struct poly
dctx->s[3] = le32_to_cpuvp(key + 12);
}
+/*
+ * Poly1305 requires a unique key for each tag, which implies that we can't set
+ * it on the tfm that gets accessed by multiple users simultaneously. Instead we
+ * expect the key as the first 32 bytes in the update() call.
+ */
unsigned int crypto_poly1305_setdesckey(struct poly1305_desc_ctx *dctx,
const u8 *src, unsigned int srclen)
{
@@ -285,7 +279,6 @@ static struct shash_alg poly1305_alg = {
.init = crypto_poly1305_init,
.update = crypto_poly1305_update,
.final = crypto_poly1305_final,
- .setkey = crypto_poly1305_setkey,
.descsize = sizeof(struct poly1305_desc_ctx),
.base = {
.cra_name = "poly1305",
--- a/include/crypto/poly1305.h
+++ b/include/crypto/poly1305.h
@@ -30,8 +30,6 @@ struct poly1305_desc_ctx {
};
int crypto_poly1305_init(struct shash_desc *desc);
-int crypto_poly1305_setkey(struct crypto_shash *tfm,
- const u8 *key, unsigned int keylen);
unsigned int crypto_poly1305_setdesckey(struct poly1305_desc_ctx *dctx,
const u8 *src, unsigned int srclen);
int crypto_poly1305_update(struct shash_desc *desc,
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.4/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.4/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
queue-4.4/x86-kaiser-fix-build-error-with-kasan-function_graph_tracer.patch
queue-4.4/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.4/crypto-poly1305-remove-setkey-method.patch
queue-4.4/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.4/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: hash - introduce crypto_hash_alg_has_setkey()
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:
crypto-hash-introduce-crypto_hash_alg_has_setkey.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 cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:22 -0800
Subject: crypto: hash - introduce crypto_hash_alg_has_setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba upstream.
Templates that use an shash spawn can use crypto_shash_alg_has_setkey()
to determine whether the underlying algorithm requires a key or not.
But there was no corresponding function for ahash spawns. Add it.
Note that the new function actually has to support both shash and ahash
algorithms, since the ahash API can be used with either.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/ahash.c | 11 +++++++++++
include/crypto/internal/hash.h | 2 ++
2 files changed, 13 insertions(+)
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -637,5 +637,16 @@ struct hash_alg_common *ahash_attr_alg(s
}
EXPORT_SYMBOL_GPL(ahash_attr_alg);
+bool crypto_hash_alg_has_setkey(struct hash_alg_common *halg)
+{
+ struct crypto_alg *alg = &halg->base;
+
+ if (alg->cra_type != &crypto_ahash_type)
+ return crypto_shash_alg_has_setkey(__crypto_shash_alg(alg));
+
+ return __crypto_ahash_alg(alg)->setkey != NULL;
+}
+EXPORT_SYMBOL_GPL(crypto_hash_alg_has_setkey);
+
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Asynchronous cryptographic hash type");
--- a/include/crypto/internal/hash.h
+++ b/include/crypto/internal/hash.h
@@ -91,6 +91,8 @@ static inline bool crypto_shash_alg_has_
return alg->setkey != shash_no_setkey;
}
+bool crypto_hash_alg_has_setkey(struct hash_alg_common *halg);
+
int crypto_init_ahash_spawn(struct crypto_ahash_spawn *spawn,
struct hash_alg_common *alg,
struct crypto_instance *inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.4/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.4/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
queue-4.4/x86-kaiser-fix-build-error-with-kasan-function_graph_tracer.patch
queue-4.4/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.4/crypto-poly1305-remove-setkey-method.patch
queue-4.4/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.4/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: cryptd - pass through absence of ->setkey()
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:
crypto-cryptd-pass-through-absence-of-setkey.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 841a3ff329713f796a63356fef6e2f72e4a3f6a3 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:23 -0800
Subject: crypto: cryptd - pass through absence of ->setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit 841a3ff329713f796a63356fef6e2f72e4a3f6a3 upstream.
When the cryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the cryptd instance. This change
is necessary for cryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/cryptd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -654,7 +654,8 @@ static int cryptd_create_hash(struct cry
inst->alg.finup = cryptd_hash_finup_enqueue;
inst->alg.export = cryptd_hash_export;
inst->alg.import = cryptd_hash_import;
- inst->alg.setkey = cryptd_hash_setkey;
+ if (crypto_shash_alg_has_setkey(salg))
+ inst->alg.setkey = cryptd_hash_setkey;
inst->alg.digest = cryptd_hash_digest_enqueue;
err = ahash_register_instance(tmpl, inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.4/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.4/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
queue-4.4/x86-kaiser-fix-build-error-with-kasan-function_graph_tracer.patch
queue-4.4/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.4/crypto-poly1305-remove-setkey-method.patch
queue-4.4/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.4/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: poly1305 - remove ->setkey() method
to the 4.15-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:
crypto-poly1305-remove-setkey-method.patch
and it can be found in the queue-4.15 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 a16e772e664b9a261424107784804cffc8894977 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:25 -0800
Subject: crypto: poly1305 - remove ->setkey() method
From: Eric Biggers <ebiggers(a)google.com>
commit a16e772e664b9a261424107784804cffc8894977 upstream.
Since Poly1305 requires a nonce per invocation, the Linux kernel
implementations of Poly1305 don't use the crypto API's keying mechanism
and instead expect the key and nonce as the first 32 bytes of the data.
But ->setkey() is still defined as a stub returning an error code. This
prevents Poly1305 from being used through AF_ALG and will also break it
completely once we start enforcing that all crypto API users (not just
AF_ALG) call ->setkey() if present.
Fix it by removing crypto_poly1305_setkey(), leaving ->setkey as NULL.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/poly1305_glue.c | 1 -
crypto/poly1305_generic.c | 17 +++++------------
include/crypto/poly1305.h | 2 --
3 files changed, 5 insertions(+), 15 deletions(-)
--- a/arch/x86/crypto/poly1305_glue.c
+++ b/arch/x86/crypto/poly1305_glue.c
@@ -164,7 +164,6 @@ static struct shash_alg alg = {
.init = poly1305_simd_init,
.update = poly1305_simd_update,
.final = crypto_poly1305_final,
- .setkey = crypto_poly1305_setkey,
.descsize = sizeof(struct poly1305_simd_desc_ctx),
.base = {
.cra_name = "poly1305",
--- a/crypto/poly1305_generic.c
+++ b/crypto/poly1305_generic.c
@@ -47,17 +47,6 @@ int crypto_poly1305_init(struct shash_de
}
EXPORT_SYMBOL_GPL(crypto_poly1305_init);
-int crypto_poly1305_setkey(struct crypto_shash *tfm,
- const u8 *key, unsigned int keylen)
-{
- /* Poly1305 requires a unique key for each tag, which implies that
- * we can't set it on the tfm that gets accessed by multiple users
- * simultaneously. Instead we expect the key as the first 32 bytes in
- * the update() call. */
- return -ENOTSUPP;
-}
-EXPORT_SYMBOL_GPL(crypto_poly1305_setkey);
-
static void poly1305_setrkey(struct poly1305_desc_ctx *dctx, const u8 *key)
{
/* r &= 0xffffffc0ffffffc0ffffffc0fffffff */
@@ -76,6 +65,11 @@ static void poly1305_setskey(struct poly
dctx->s[3] = get_unaligned_le32(key + 12);
}
+/*
+ * Poly1305 requires a unique key for each tag, which implies that we can't set
+ * it on the tfm that gets accessed by multiple users simultaneously. Instead we
+ * expect the key as the first 32 bytes in the update() call.
+ */
unsigned int crypto_poly1305_setdesckey(struct poly1305_desc_ctx *dctx,
const u8 *src, unsigned int srclen)
{
@@ -281,7 +275,6 @@ static struct shash_alg poly1305_alg = {
.init = crypto_poly1305_init,
.update = crypto_poly1305_update,
.final = crypto_poly1305_final,
- .setkey = crypto_poly1305_setkey,
.descsize = sizeof(struct poly1305_desc_ctx),
.base = {
.cra_name = "poly1305",
--- a/include/crypto/poly1305.h
+++ b/include/crypto/poly1305.h
@@ -31,8 +31,6 @@ struct poly1305_desc_ctx {
};
int crypto_poly1305_init(struct shash_desc *desc);
-int crypto_poly1305_setkey(struct crypto_shash *tfm,
- const u8 *key, unsigned int keylen);
unsigned int crypto_poly1305_setdesckey(struct poly1305_desc_ctx *dctx,
const u8 *src, unsigned int srclen);
int crypto_poly1305_update(struct shash_desc *desc,
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.15/crypto-hash-annotate-algorithms-taking-optional-key.patch
queue-4.15/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.15/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.15/ubifs-free-the-encrypted-symlink-target.patch
queue-4.15/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.15/crypto-poly1305-remove-setkey-method.patch
queue-4.15/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.15/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: mcryptd - pass through absence of ->setkey()
to the 4.15-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:
crypto-mcryptd-pass-through-absence-of-setkey.patch
and it can be found in the queue-4.15 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 fa59b92d299f2787e6bae1ff078ee0982e80211f Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:24 -0800
Subject: crypto: mcryptd - pass through absence of ->setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit fa59b92d299f2787e6bae1ff078ee0982e80211f upstream.
When the mcryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the mcryptd instance. This change
is necessary for mcryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/mcryptd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/crypto/mcryptd.c
+++ b/crypto/mcryptd.c
@@ -535,7 +535,8 @@ static int mcryptd_create_hash(struct cr
inst->alg.finup = mcryptd_hash_finup_enqueue;
inst->alg.export = mcryptd_hash_export;
inst->alg.import = mcryptd_hash_import;
- inst->alg.setkey = mcryptd_hash_setkey;
+ if (crypto_hash_alg_has_setkey(halg))
+ inst->alg.setkey = mcryptd_hash_setkey;
inst->alg.digest = mcryptd_hash_digest_enqueue;
err = ahash_register_instance(tmpl, inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.15/crypto-hash-annotate-algorithms-taking-optional-key.patch
queue-4.15/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.15/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.15/ubifs-free-the-encrypted-symlink-target.patch
queue-4.15/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.15/crypto-poly1305-remove-setkey-method.patch
queue-4.15/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.15/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: hash - introduce crypto_hash_alg_has_setkey()
to the 4.15-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:
crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
and it can be found in the queue-4.15 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 cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:22 -0800
Subject: crypto: hash - introduce crypto_hash_alg_has_setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba upstream.
Templates that use an shash spawn can use crypto_shash_alg_has_setkey()
to determine whether the underlying algorithm requires a key or not.
But there was no corresponding function for ahash spawns. Add it.
Note that the new function actually has to support both shash and ahash
algorithms, since the ahash API can be used with either.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/ahash.c | 11 +++++++++++
include/crypto/internal/hash.h | 2 ++
2 files changed, 13 insertions(+)
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -649,5 +649,16 @@ struct hash_alg_common *ahash_attr_alg(s
}
EXPORT_SYMBOL_GPL(ahash_attr_alg);
+bool crypto_hash_alg_has_setkey(struct hash_alg_common *halg)
+{
+ struct crypto_alg *alg = &halg->base;
+
+ if (alg->cra_type != &crypto_ahash_type)
+ return crypto_shash_alg_has_setkey(__crypto_shash_alg(alg));
+
+ return __crypto_ahash_alg(alg)->setkey != NULL;
+}
+EXPORT_SYMBOL_GPL(crypto_hash_alg_has_setkey);
+
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Asynchronous cryptographic hash type");
--- a/include/crypto/internal/hash.h
+++ b/include/crypto/internal/hash.h
@@ -90,6 +90,8 @@ static inline bool crypto_shash_alg_has_
return alg->setkey != shash_no_setkey;
}
+bool crypto_hash_alg_has_setkey(struct hash_alg_common *halg);
+
int crypto_init_ahash_spawn(struct crypto_ahash_spawn *spawn,
struct hash_alg_common *alg,
struct crypto_instance *inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.15/crypto-hash-annotate-algorithms-taking-optional-key.patch
queue-4.15/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.15/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.15/ubifs-free-the-encrypted-symlink-target.patch
queue-4.15/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.15/crypto-poly1305-remove-setkey-method.patch
queue-4.15/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.15/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: cryptd - pass through absence of ->setkey()
to the 4.15-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:
crypto-cryptd-pass-through-absence-of-setkey.patch
and it can be found in the queue-4.15 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 841a3ff329713f796a63356fef6e2f72e4a3f6a3 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:23 -0800
Subject: crypto: cryptd - pass through absence of ->setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit 841a3ff329713f796a63356fef6e2f72e4a3f6a3 upstream.
When the cryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the cryptd instance. This change
is necessary for cryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/cryptd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -911,7 +911,8 @@ static int cryptd_create_hash(struct cry
inst->alg.finup = cryptd_hash_finup_enqueue;
inst->alg.export = cryptd_hash_export;
inst->alg.import = cryptd_hash_import;
- inst->alg.setkey = cryptd_hash_setkey;
+ if (crypto_shash_alg_has_setkey(salg))
+ inst->alg.setkey = cryptd_hash_setkey;
inst->alg.digest = cryptd_hash_digest_enqueue;
err = ahash_register_instance(tmpl, inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.15/crypto-hash-annotate-algorithms-taking-optional-key.patch
queue-4.15/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.15/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.15/ubifs-free-the-encrypted-symlink-target.patch
queue-4.15/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.15/crypto-poly1305-remove-setkey-method.patch
queue-4.15/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.15/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: poly1305 - remove ->setkey() method
to the 4.14-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:
crypto-poly1305-remove-setkey-method.patch
and it can be found in the queue-4.14 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 a16e772e664b9a261424107784804cffc8894977 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:25 -0800
Subject: crypto: poly1305 - remove ->setkey() method
From: Eric Biggers <ebiggers(a)google.com>
commit a16e772e664b9a261424107784804cffc8894977 upstream.
Since Poly1305 requires a nonce per invocation, the Linux kernel
implementations of Poly1305 don't use the crypto API's keying mechanism
and instead expect the key and nonce as the first 32 bytes of the data.
But ->setkey() is still defined as a stub returning an error code. This
prevents Poly1305 from being used through AF_ALG and will also break it
completely once we start enforcing that all crypto API users (not just
AF_ALG) call ->setkey() if present.
Fix it by removing crypto_poly1305_setkey(), leaving ->setkey as NULL.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/crypto/poly1305_glue.c | 1 -
crypto/poly1305_generic.c | 17 +++++------------
include/crypto/poly1305.h | 2 --
3 files changed, 5 insertions(+), 15 deletions(-)
--- a/arch/x86/crypto/poly1305_glue.c
+++ b/arch/x86/crypto/poly1305_glue.c
@@ -164,7 +164,6 @@ static struct shash_alg alg = {
.init = poly1305_simd_init,
.update = poly1305_simd_update,
.final = crypto_poly1305_final,
- .setkey = crypto_poly1305_setkey,
.descsize = sizeof(struct poly1305_simd_desc_ctx),
.base = {
.cra_name = "poly1305",
--- a/crypto/poly1305_generic.c
+++ b/crypto/poly1305_generic.c
@@ -47,17 +47,6 @@ int crypto_poly1305_init(struct shash_de
}
EXPORT_SYMBOL_GPL(crypto_poly1305_init);
-int crypto_poly1305_setkey(struct crypto_shash *tfm,
- const u8 *key, unsigned int keylen)
-{
- /* Poly1305 requires a unique key for each tag, which implies that
- * we can't set it on the tfm that gets accessed by multiple users
- * simultaneously. Instead we expect the key as the first 32 bytes in
- * the update() call. */
- return -ENOTSUPP;
-}
-EXPORT_SYMBOL_GPL(crypto_poly1305_setkey);
-
static void poly1305_setrkey(struct poly1305_desc_ctx *dctx, const u8 *key)
{
/* r &= 0xffffffc0ffffffc0ffffffc0fffffff */
@@ -76,6 +65,11 @@ static void poly1305_setskey(struct poly
dctx->s[3] = get_unaligned_le32(key + 12);
}
+/*
+ * Poly1305 requires a unique key for each tag, which implies that we can't set
+ * it on the tfm that gets accessed by multiple users simultaneously. Instead we
+ * expect the key as the first 32 bytes in the update() call.
+ */
unsigned int crypto_poly1305_setdesckey(struct poly1305_desc_ctx *dctx,
const u8 *src, unsigned int srclen)
{
@@ -281,7 +275,6 @@ static struct shash_alg poly1305_alg = {
.init = crypto_poly1305_init,
.update = crypto_poly1305_update,
.final = crypto_poly1305_final,
- .setkey = crypto_poly1305_setkey,
.descsize = sizeof(struct poly1305_desc_ctx),
.base = {
.cra_name = "poly1305",
--- a/include/crypto/poly1305.h
+++ b/include/crypto/poly1305.h
@@ -31,8 +31,6 @@ struct poly1305_desc_ctx {
};
int crypto_poly1305_init(struct shash_desc *desc);
-int crypto_poly1305_setkey(struct crypto_shash *tfm,
- const u8 *key, unsigned int keylen);
unsigned int crypto_poly1305_setdesckey(struct poly1305_desc_ctx *dctx,
const u8 *src, unsigned int srclen);
int crypto_poly1305_update(struct shash_desc *desc,
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/crypto-hash-annotate-algorithms-taking-optional-key.patch
queue-4.14/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.14/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.14/ubifs-free-the-encrypted-symlink-target.patch
queue-4.14/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.14/crypto-poly1305-remove-setkey-method.patch
queue-4.14/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.14/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: mcryptd - pass through absence of ->setkey()
to the 4.14-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:
crypto-mcryptd-pass-through-absence-of-setkey.patch
and it can be found in the queue-4.14 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 fa59b92d299f2787e6bae1ff078ee0982e80211f Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:24 -0800
Subject: crypto: mcryptd - pass through absence of ->setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit fa59b92d299f2787e6bae1ff078ee0982e80211f upstream.
When the mcryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the mcryptd instance. This change
is necessary for mcryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/mcryptd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/crypto/mcryptd.c
+++ b/crypto/mcryptd.c
@@ -535,7 +535,8 @@ static int mcryptd_create_hash(struct cr
inst->alg.finup = mcryptd_hash_finup_enqueue;
inst->alg.export = mcryptd_hash_export;
inst->alg.import = mcryptd_hash_import;
- inst->alg.setkey = mcryptd_hash_setkey;
+ if (crypto_hash_alg_has_setkey(halg))
+ inst->alg.setkey = mcryptd_hash_setkey;
inst->alg.digest = mcryptd_hash_digest_enqueue;
err = ahash_register_instance(tmpl, inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/crypto-hash-annotate-algorithms-taking-optional-key.patch
queue-4.14/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.14/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.14/ubifs-free-the-encrypted-symlink-target.patch
queue-4.14/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.14/crypto-poly1305-remove-setkey-method.patch
queue-4.14/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.14/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: hash - introduce crypto_hash_alg_has_setkey()
to the 4.14-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:
crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
and it can be found in the queue-4.14 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 cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:22 -0800
Subject: crypto: hash - introduce crypto_hash_alg_has_setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba upstream.
Templates that use an shash spawn can use crypto_shash_alg_has_setkey()
to determine whether the underlying algorithm requires a key or not.
But there was no corresponding function for ahash spawns. Add it.
Note that the new function actually has to support both shash and ahash
algorithms, since the ahash API can be used with either.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/ahash.c | 11 +++++++++++
include/crypto/internal/hash.h | 2 ++
2 files changed, 13 insertions(+)
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -655,5 +655,16 @@ struct hash_alg_common *ahash_attr_alg(s
}
EXPORT_SYMBOL_GPL(ahash_attr_alg);
+bool crypto_hash_alg_has_setkey(struct hash_alg_common *halg)
+{
+ struct crypto_alg *alg = &halg->base;
+
+ if (alg->cra_type != &crypto_ahash_type)
+ return crypto_shash_alg_has_setkey(__crypto_shash_alg(alg));
+
+ return __crypto_ahash_alg(alg)->setkey != NULL;
+}
+EXPORT_SYMBOL_GPL(crypto_hash_alg_has_setkey);
+
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Asynchronous cryptographic hash type");
--- a/include/crypto/internal/hash.h
+++ b/include/crypto/internal/hash.h
@@ -90,6 +90,8 @@ static inline bool crypto_shash_alg_has_
return alg->setkey != shash_no_setkey;
}
+bool crypto_hash_alg_has_setkey(struct hash_alg_common *halg);
+
int crypto_init_ahash_spawn(struct crypto_ahash_spawn *spawn,
struct hash_alg_common *alg,
struct crypto_instance *inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/crypto-hash-annotate-algorithms-taking-optional-key.patch
queue-4.14/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.14/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.14/ubifs-free-the-encrypted-symlink-target.patch
queue-4.14/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.14/crypto-poly1305-remove-setkey-method.patch
queue-4.14/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.14/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: cryptd - pass through absence of ->setkey()
to the 4.14-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:
crypto-cryptd-pass-through-absence-of-setkey.patch
and it can be found in the queue-4.14 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 841a3ff329713f796a63356fef6e2f72e4a3f6a3 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:23 -0800
Subject: crypto: cryptd - pass through absence of ->setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit 841a3ff329713f796a63356fef6e2f72e4a3f6a3 upstream.
When the cryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the cryptd instance. This change
is necessary for cryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/cryptd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -913,7 +913,8 @@ static int cryptd_create_hash(struct cry
inst->alg.finup = cryptd_hash_finup_enqueue;
inst->alg.export = cryptd_hash_export;
inst->alg.import = cryptd_hash_import;
- inst->alg.setkey = cryptd_hash_setkey;
+ if (crypto_shash_alg_has_setkey(salg))
+ inst->alg.setkey = cryptd_hash_setkey;
inst->alg.digest = cryptd_hash_digest_enqueue;
err = ahash_register_instance(tmpl, inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/crypto-hash-annotate-algorithms-taking-optional-key.patch
queue-4.14/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-4.14/crypto-hash-prevent-using-keyed-hashes-without-setting-key.patch
queue-4.14/ubifs-free-the-encrypted-symlink-target.patch
queue-4.14/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
queue-4.14/crypto-poly1305-remove-setkey-method.patch
queue-4.14/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-4.14/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: hash - introduce crypto_hash_alg_has_setkey()
to the 3.18-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:
crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
and it can be found in the queue-3.18 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 cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:22 -0800
Subject: crypto: hash - introduce crypto_hash_alg_has_setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit cd6ed77ad5d223dc6299fb58f62e0f5267f7e2ba upstream.
Templates that use an shash spawn can use crypto_shash_alg_has_setkey()
to determine whether the underlying algorithm requires a key or not.
But there was no corresponding function for ahash spawns. Add it.
Note that the new function actually has to support both shash and ahash
algorithms, since the ahash API can be used with either.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/ahash.c | 11 +++++++++++
include/crypto/internal/hash.h | 2 ++
2 files changed, 13 insertions(+)
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -636,5 +636,16 @@ struct hash_alg_common *ahash_attr_alg(s
}
EXPORT_SYMBOL_GPL(ahash_attr_alg);
+bool crypto_hash_alg_has_setkey(struct hash_alg_common *halg)
+{
+ struct crypto_alg *alg = &halg->base;
+
+ if (alg->cra_type != &crypto_ahash_type)
+ return crypto_shash_alg_has_setkey(__crypto_shash_alg(alg));
+
+ return __crypto_ahash_alg(alg)->setkey != NULL;
+}
+EXPORT_SYMBOL_GPL(crypto_hash_alg_has_setkey);
+
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Asynchronous cryptographic hash type");
--- a/include/crypto/internal/hash.h
+++ b/include/crypto/internal/hash.h
@@ -91,6 +91,8 @@ static inline bool crypto_shash_alg_has_
return alg->setkey != shash_no_setkey;
}
+bool crypto_hash_alg_has_setkey(struct hash_alg_common *halg);
+
int crypto_init_ahash_spawn(struct crypto_ahash_spawn *spawn,
struct hash_alg_common *alg,
struct crypto_instance *inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-3.18/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-3.18/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
queue-3.18/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-3.18/crypto-mcryptd-pass-through-absence-of-setkey.patch
This is a note to let you know that I've just added the patch titled
crypto: cryptd - pass through absence of ->setkey()
to the 3.18-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:
crypto-cryptd-pass-through-absence-of-setkey.patch
and it can be found in the queue-3.18 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 841a3ff329713f796a63356fef6e2f72e4a3f6a3 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:23 -0800
Subject: crypto: cryptd - pass through absence of ->setkey()
From: Eric Biggers <ebiggers(a)google.com>
commit 841a3ff329713f796a63356fef6e2f72e4a3f6a3 upstream.
When the cryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the cryptd instance. This change
is necessary for cryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/cryptd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/crypto/cryptd.c
+++ b/crypto/cryptd.c
@@ -618,7 +618,8 @@ static int cryptd_create_hash(struct cry
inst->alg.finup = cryptd_hash_finup_enqueue;
inst->alg.export = cryptd_hash_export;
inst->alg.import = cryptd_hash_import;
- inst->alg.setkey = cryptd_hash_setkey;
+ if (crypto_shash_alg_has_setkey(salg))
+ inst->alg.setkey = cryptd_hash_setkey;
inst->alg.digest = cryptd_hash_digest_enqueue;
err = ahash_register_instance(tmpl, inst);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-3.18/crypto-cryptd-pass-through-absence-of-setkey.patch
queue-3.18/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
queue-3.18/crypto-hash-introduce-crypto_hash_alg_has_setkey.patch
queue-3.18/crypto-mcryptd-pass-through-absence-of-setkey.patch
The patch below does not apply to the 3.18-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 a16e772e664b9a261424107784804cffc8894977 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Wed, 3 Jan 2018 11:16:25 -0800
Subject: [PATCH] crypto: poly1305 - remove ->setkey() method
Since Poly1305 requires a nonce per invocation, the Linux kernel
implementations of Poly1305 don't use the crypto API's keying mechanism
and instead expect the key and nonce as the first 32 bytes of the data.
But ->setkey() is still defined as a stub returning an error code. This
prevents Poly1305 from being used through AF_ALG and will also break it
completely once we start enforcing that all crypto API users (not just
AF_ALG) call ->setkey() if present.
Fix it by removing crypto_poly1305_setkey(), leaving ->setkey as NULL.
Cc: stable(a)vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
diff --git a/arch/x86/crypto/poly1305_glue.c b/arch/x86/crypto/poly1305_glue.c
index f58f89b05a7f..790377797544 100644
--- a/arch/x86/crypto/poly1305_glue.c
+++ b/arch/x86/crypto/poly1305_glue.c
@@ -164,7 +164,6 @@ static struct shash_alg alg = {
.init = poly1305_simd_init,
.update = poly1305_simd_update,
.final = crypto_poly1305_final,
- .setkey = crypto_poly1305_setkey,
.descsize = sizeof(struct poly1305_simd_desc_ctx),
.base = {
.cra_name = "poly1305",
diff --git a/crypto/poly1305_generic.c b/crypto/poly1305_generic.c
index d92617aeb783..b7a3a0613a30 100644
--- a/crypto/poly1305_generic.c
+++ b/crypto/poly1305_generic.c
@@ -47,17 +47,6 @@ int crypto_poly1305_init(struct shash_desc *desc)
}
EXPORT_SYMBOL_GPL(crypto_poly1305_init);
-int crypto_poly1305_setkey(struct crypto_shash *tfm,
- const u8 *key, unsigned int keylen)
-{
- /* Poly1305 requires a unique key for each tag, which implies that
- * we can't set it on the tfm that gets accessed by multiple users
- * simultaneously. Instead we expect the key as the first 32 bytes in
- * the update() call. */
- return -ENOTSUPP;
-}
-EXPORT_SYMBOL_GPL(crypto_poly1305_setkey);
-
static void poly1305_setrkey(struct poly1305_desc_ctx *dctx, const u8 *key)
{
/* r &= 0xffffffc0ffffffc0ffffffc0fffffff */
@@ -76,6 +65,11 @@ static void poly1305_setskey(struct poly1305_desc_ctx *dctx, const u8 *key)
dctx->s[3] = get_unaligned_le32(key + 12);
}
+/*
+ * Poly1305 requires a unique key for each tag, which implies that we can't set
+ * it on the tfm that gets accessed by multiple users simultaneously. Instead we
+ * expect the key as the first 32 bytes in the update() call.
+ */
unsigned int crypto_poly1305_setdesckey(struct poly1305_desc_ctx *dctx,
const u8 *src, unsigned int srclen)
{
@@ -280,7 +274,6 @@ static struct shash_alg poly1305_alg = {
.init = crypto_poly1305_init,
.update = crypto_poly1305_update,
.final = crypto_poly1305_final,
- .setkey = crypto_poly1305_setkey,
.descsize = sizeof(struct poly1305_desc_ctx),
.base = {
.cra_name = "poly1305",
diff --git a/include/crypto/poly1305.h b/include/crypto/poly1305.h
index c65567d01e8e..f718a19da82f 100644
--- a/include/crypto/poly1305.h
+++ b/include/crypto/poly1305.h
@@ -31,8 +31,6 @@ struct poly1305_desc_ctx {
};
int crypto_poly1305_init(struct shash_desc *desc);
-int crypto_poly1305_setkey(struct crypto_shash *tfm,
- const u8 *key, unsigned int keylen);
unsigned int crypto_poly1305_setdesckey(struct poly1305_desc_ctx *dctx,
const u8 *src, unsigned int srclen);
int crypto_poly1305_update(struct shash_desc *desc,
This is a note to let you know that I've just added the patch titled
ubifs: Massage assert in ubifs_xattr_set() wrt. init_xattrs
to the 4.9-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:
ubifs-massage-assert-in-ubifs_xattr_set-wrt.-init_xattrs.patch
and it can be found in the queue-4.9 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 d8db5b1ca9d4c57e49893d0f78e6d5ce81450cc8 Mon Sep 17 00:00:00 2001
From: Xiaolei Li <xiaolei.li(a)mediatek.com>
Date: Fri, 23 Jun 2017 10:37:23 +0800
Subject: ubifs: Massage assert in ubifs_xattr_set() wrt. init_xattrs
From: Xiaolei Li <xiaolei.li(a)mediatek.com>
commit d8db5b1ca9d4c57e49893d0f78e6d5ce81450cc8 upstream.
The inode is not locked in init_xattrs when creating a new inode.
Without this patch, there will occurs assert when booting or creating
a new file, if the kernel config CONFIG_SECURITY_SMACK is enabled.
Log likes:
UBIFS assert failed in ubifs_xattr_set at 298 (pid 1156)
CPU: 1 PID: 1156 Comm: ldconfig Tainted: G S 4.12.0-rc1-207440-g1e70b02 #2
Hardware name: MediaTek MT2712 evaluation board (DT)
Call trace:
[<ffff000008088538>] dump_backtrace+0x0/0x238
[<ffff000008088834>] show_stack+0x14/0x20
[<ffff0000083d98d4>] dump_stack+0x9c/0xc0
[<ffff00000835d524>] ubifs_xattr_set+0x374/0x5e0
[<ffff00000835d7ec>] init_xattrs+0x5c/0xb8
[<ffff000008385788>] security_inode_init_security+0x110/0x190
[<ffff00000835e058>] ubifs_init_security+0x30/0x68
[<ffff00000833ada0>] ubifs_mkdir+0x100/0x200
[<ffff00000820669c>] vfs_mkdir+0x11c/0x1b8
[<ffff00000820b73c>] SyS_mkdirat+0x74/0xd0
[<ffff000008082f8c>] __sys_trace_return+0x0/0x4
Signed-off-by: Xiaolei Li <xiaolei.li(a)mediatek.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Cc: stable(a)vger.kernel.org
(julia: massaged to apply to 4.9.y, which doesn't contain fscrypto support)
Signed-off-by: Julia Cartwright <julia(a)ni.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ubifs/xattr.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
--- a/fs/ubifs/xattr.c
+++ b/fs/ubifs/xattr.c
@@ -270,7 +270,8 @@ static struct inode *iget_xattr(struct u
}
static int __ubifs_setxattr(struct inode *host, const char *name,
- const void *value, size_t size, int flags)
+ const void *value, size_t size, int flags,
+ bool check_lock)
{
struct inode *inode;
struct ubifs_info *c = host->i_sb->s_fs_info;
@@ -279,7 +280,8 @@ static int __ubifs_setxattr(struct inode
union ubifs_key key;
int err;
- ubifs_assert(inode_is_locked(host));
+ if (check_lock)
+ ubifs_assert(inode_is_locked(host));
if (size > UBIFS_MAX_INO_DATA)
return -ERANGE;
@@ -548,7 +550,8 @@ static int init_xattrs(struct inode *ino
}
strcpy(name, XATTR_SECURITY_PREFIX);
strcpy(name + XATTR_SECURITY_PREFIX_LEN, xattr->name);
- err = __ubifs_setxattr(inode, name, xattr->value, xattr->value_len, 0);
+ err = __ubifs_setxattr(inode, name, xattr->value,
+ xattr->value_len, 0, false);
kfree(name);
if (err < 0)
break;
@@ -594,7 +597,8 @@ static int ubifs_xattr_set(const struct
name = xattr_full_name(handler, name);
if (value)
- return __ubifs_setxattr(inode, name, value, size, flags);
+ return __ubifs_setxattr(inode, name, value, size, flags,
+ true);
else
return __ubifs_removexattr(inode, name);
}
Patches currently in stable-queue which might be from xiaolei.li(a)mediatek.com are
queue-4.9/ubifs-massage-assert-in-ubifs_xattr_set-wrt.-init_xattrs.patch
This is a note to let you know that I've just added the patch titled
ubi: block: Fix locking for idr_alloc/idr_remove
to the 4.9-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:
ubi-block-fix-locking-for-idr_alloc-idr_remove.patch
and it can be found in the queue-4.9 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 7f29ae9f977bcdc3654e68bc36d170223c52fd48 Mon Sep 17 00:00:00 2001
From: Bradley Bolen <bradleybolen(a)gmail.com>
Date: Thu, 18 Jan 2018 08:55:20 -0500
Subject: ubi: block: Fix locking for idr_alloc/idr_remove
From: Bradley Bolen <bradleybolen(a)gmail.com>
commit 7f29ae9f977bcdc3654e68bc36d170223c52fd48 upstream.
This fixes a race with idr_alloc where gd->first_minor can be set to the
same value for two simultaneous calls to ubiblock_create. Each instance
calls device_add_disk with the same first_minor. device_add_disk calls
bdi_register_owner which generates several warnings.
WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
sysfs_warn_dup+0x68/0x88
sysfs: cannot create duplicate filename '/devices/virtual/bdi/252:2'
WARNING: CPU: 1 PID: 179 at kernel-source/lib/kobject.c:240
kobject_add_internal+0x1ec/0x2f8
kobject_add_internal failed for 252:2 with -EEXIST, don't try to
register things with the same name in the same directory
WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
sysfs_warn_dup+0x68/0x88
sysfs: cannot create duplicate filename '/dev/block/252:2'
However, device_add_disk does not error out when bdi_register_owner
returns an error. Control continues until reaching blk_register_queue.
It then BUGs.
kernel BUG at kernel-source/fs/sysfs/group.c:113!
[<c01e26cc>] (internal_create_group) from [<c01e2950>]
(sysfs_create_group+0x20/0x24)
[<c01e2950>] (sysfs_create_group) from [<c00e3d38>]
(blk_trace_init_sysfs+0x18/0x20)
[<c00e3d38>] (blk_trace_init_sysfs) from [<c02bdfbc>]
(blk_register_queue+0xd8/0x154)
[<c02bdfbc>] (blk_register_queue) from [<c02cec84>]
(device_add_disk+0x194/0x44c)
[<c02cec84>] (device_add_disk) from [<c0436ec8>]
(ubiblock_create+0x284/0x2e0)
[<c0436ec8>] (ubiblock_create) from [<c0427bb8>]
(vol_cdev_ioctl+0x450/0x554)
[<c0427bb8>] (vol_cdev_ioctl) from [<c0189110>] (vfs_ioctl+0x30/0x44)
[<c0189110>] (vfs_ioctl) from [<c01892e0>] (do_vfs_ioctl+0xa0/0x790)
[<c01892e0>] (do_vfs_ioctl) from [<c0189a14>] (SyS_ioctl+0x44/0x68)
[<c0189a14>] (SyS_ioctl) from [<c0010640>] (ret_fast_syscall+0x0/0x34)
Locking idr_alloc/idr_remove removes the race and keeps gd->first_minor
unique.
Fixes: 2bf50d42f3a4 ("UBI: block: Dynamically allocate minor numbers")
Signed-off-by: Bradley Bolen <bradleybolen(a)gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/ubi/block.c | 42 ++++++++++++++++++++++++++----------------
1 file changed, 26 insertions(+), 16 deletions(-)
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
@@ -99,6 +99,8 @@ struct ubiblock {
/* Linked list of all ubiblock instances */
static LIST_HEAD(ubiblock_devices);
+static DEFINE_IDR(ubiblock_minor_idr);
+/* Protects ubiblock_devices and ubiblock_minor_idr */
static DEFINE_MUTEX(devices_mutex);
static int ubiblock_major;
@@ -353,8 +355,6 @@ static struct blk_mq_ops ubiblock_mq_ops
.init_request = ubiblock_init_request,
};
-static DEFINE_IDR(ubiblock_minor_idr);
-
int ubiblock_create(struct ubi_volume_info *vi)
{
struct ubiblock *dev;
@@ -367,14 +367,15 @@ int ubiblock_create(struct ubi_volume_in
/* Check that the volume isn't already handled */
mutex_lock(&devices_mutex);
if (find_dev_nolock(vi->ubi_num, vi->vol_id)) {
- mutex_unlock(&devices_mutex);
- return -EEXIST;
+ ret = -EEXIST;
+ goto out_unlock;
}
- mutex_unlock(&devices_mutex);
dev = kzalloc(sizeof(struct ubiblock), GFP_KERNEL);
- if (!dev)
- return -ENOMEM;
+ if (!dev) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
mutex_init(&dev->dev_mutex);
@@ -439,14 +440,13 @@ int ubiblock_create(struct ubi_volume_in
goto out_free_queue;
}
- mutex_lock(&devices_mutex);
list_add_tail(&dev->list, &ubiblock_devices);
- mutex_unlock(&devices_mutex);
/* Must be the last step: anyone can call file ops from now on */
add_disk(dev->gd);
dev_info(disk_to_dev(dev->gd), "created from ubi%d:%d(%s)",
dev->ubi_num, dev->vol_id, vi->name);
+ mutex_unlock(&devices_mutex);
return 0;
out_free_queue:
@@ -459,6 +459,8 @@ out_put_disk:
put_disk(dev->gd);
out_free_dev:
kfree(dev);
+out_unlock:
+ mutex_unlock(&devices_mutex);
return ret;
}
@@ -480,30 +482,36 @@ static void ubiblock_cleanup(struct ubib
int ubiblock_remove(struct ubi_volume_info *vi)
{
struct ubiblock *dev;
+ int ret;
mutex_lock(&devices_mutex);
dev = find_dev_nolock(vi->ubi_num, vi->vol_id);
if (!dev) {
- mutex_unlock(&devices_mutex);
- return -ENODEV;
+ ret = -ENODEV;
+ goto out_unlock;
}
/* Found a device, let's lock it so we can check if it's busy */
mutex_lock(&dev->dev_mutex);
if (dev->refcnt > 0) {
- mutex_unlock(&dev->dev_mutex);
- mutex_unlock(&devices_mutex);
- return -EBUSY;
+ ret = -EBUSY;
+ goto out_unlock_dev;
}
/* Remove from device list */
list_del(&dev->list);
- mutex_unlock(&devices_mutex);
-
ubiblock_cleanup(dev);
mutex_unlock(&dev->dev_mutex);
+ mutex_unlock(&devices_mutex);
+
kfree(dev);
return 0;
+
+out_unlock_dev:
+ mutex_unlock(&dev->dev_mutex);
+out_unlock:
+ mutex_unlock(&devices_mutex);
+ return ret;
}
static int ubiblock_resize(struct ubi_volume_info *vi)
@@ -632,6 +640,7 @@ static void ubiblock_remove_all(void)
struct ubiblock *next;
struct ubiblock *dev;
+ mutex_lock(&devices_mutex);
list_for_each_entry_safe(dev, next, &ubiblock_devices, list) {
/* The module is being forcefully removed */
WARN_ON(dev->desc);
@@ -640,6 +649,7 @@ static void ubiblock_remove_all(void)
ubiblock_cleanup(dev);
kfree(dev);
}
+ mutex_unlock(&devices_mutex);
}
int __init ubiblock_init(void)
Patches currently in stable-queue which might be from bradleybolen(a)gmail.com are
queue-4.9/ubi-block-fix-locking-for-idr_alloc-idr_remove.patch
This is a note to let you know that I've just added the patch titled
ubi: fastmap: Erase outdated anchor PEBs during attach
to the 4.9-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:
ubi-fastmap-erase-outdated-anchor-pebs-during-attach.patch
and it can be found in the queue-4.9 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 f78e5623f45bab2b726eec29dc5cefbbab2d0b1c Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer(a)pengutronix.de>
Date: Tue, 5 Dec 2017 16:01:20 +0100
Subject: ubi: fastmap: Erase outdated anchor PEBs during attach
From: Sascha Hauer <s.hauer(a)pengutronix.de>
commit f78e5623f45bab2b726eec29dc5cefbbab2d0b1c upstream.
The fastmap update code might erase the current fastmap anchor PEB
in case it doesn't find any new free PEB. When a power cut happens
in this situation we must not have any outdated fastmap anchor PEB
on the device, because that would be used to attach during next
boot.
The easiest way to make that sure is to erase all outdated fastmap
anchor PEBs synchronously during attach.
Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de>
Reviewed-by: Richard Weinberger <richard(a)nod.at>
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/ubi/wl.c | 77 +++++++++++++++++++++++++++++++++++++--------------
1 file changed, 57 insertions(+), 20 deletions(-)
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1529,6 +1529,46 @@ static void shutdown_work(struct ubi_dev
}
/**
+ * erase_aeb - erase a PEB given in UBI attach info PEB
+ * @ubi: UBI device description object
+ * @aeb: UBI attach info PEB
+ * @sync: If true, erase synchronously. Otherwise schedule for erasure
+ */
+static int erase_aeb(struct ubi_device *ubi, struct ubi_ainf_peb *aeb, bool sync)
+{
+ struct ubi_wl_entry *e;
+ int err;
+
+ e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
+ if (!e)
+ return -ENOMEM;
+
+ e->pnum = aeb->pnum;
+ e->ec = aeb->ec;
+ ubi->lookuptbl[e->pnum] = e;
+
+ if (sync) {
+ err = sync_erase(ubi, e, false);
+ if (err)
+ goto out_free;
+
+ wl_tree_add(e, &ubi->free);
+ ubi->free_count++;
+ } else {
+ err = schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false);
+ if (err)
+ goto out_free;
+ }
+
+ return 0;
+
+out_free:
+ wl_entry_destroy(ubi, e);
+
+ return err;
+}
+
+/**
* ubi_wl_init - initialize the WL sub-system using attaching information.
* @ubi: UBI device description object
* @ai: attaching information
@@ -1566,17 +1606,9 @@ int ubi_wl_init(struct ubi_device *ubi,
list_for_each_entry_safe(aeb, tmp, &ai->erase, u.list) {
cond_resched();
- e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
- if (!e)
- goto out_free;
-
- e->pnum = aeb->pnum;
- e->ec = aeb->ec;
- ubi->lookuptbl[e->pnum] = e;
- if (schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false)) {
- wl_entry_destroy(ubi, e);
+ err = erase_aeb(ubi, aeb, false);
+ if (err)
goto out_free;
- }
found_pebs++;
}
@@ -1635,6 +1667,8 @@ int ubi_wl_init(struct ubi_device *ubi,
ubi_assert(!ubi->lookuptbl[e->pnum]);
ubi->lookuptbl[e->pnum] = e;
} else {
+ bool sync = false;
+
/*
* Usually old Fastmap PEBs are scheduled for erasure
* and we don't have to care about them but if we face
@@ -1644,18 +1678,21 @@ int ubi_wl_init(struct ubi_device *ubi,
if (ubi->lookuptbl[aeb->pnum])
continue;
- e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
- if (!e)
- goto out_free;
+ /*
+ * The fastmap update code might not find a free PEB for
+ * writing the fastmap anchor to and then reuses the
+ * current fastmap anchor PEB. When this PEB gets erased
+ * and a power cut happens before it is written again we
+ * must make sure that the fastmap attach code doesn't
+ * find any outdated fastmap anchors, hence we erase the
+ * outdated fastmap anchor PEBs synchronously here.
+ */
+ if (aeb->vol_id == UBI_FM_SB_VOLUME_ID)
+ sync = true;
- e->pnum = aeb->pnum;
- e->ec = aeb->ec;
- ubi_assert(!ubi->lookuptbl[e->pnum]);
- ubi->lookuptbl[e->pnum] = e;
- if (schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false)) {
- wl_entry_destroy(ubi, e);
+ err = erase_aeb(ubi, aeb, sync);
+ if (err)
goto out_free;
- }
}
found_pebs++;
Patches currently in stable-queue which might be from s.hauer(a)pengutronix.de are
queue-4.9/ubi-fastmap-erase-outdated-anchor-pebs-during-attach.patch
This is a note to let you know that I've just added the patch titled
NFS: reject request for id_legacy key without auxdata
to the 4.9-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:
nfs-reject-request-for-id_legacy-key-without-auxdata.patch
and it can be found in the queue-4.9 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 49686cbbb3ebafe42e63868222f269d8053ead00 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Fri, 19 Jan 2018 15:15:34 -0800
Subject: NFS: reject request for id_legacy key without auxdata
From: Eric Biggers <ebiggers(a)google.com>
commit 49686cbbb3ebafe42e63868222f269d8053ead00 upstream.
nfs_idmap_legacy_upcall() is supposed to be called with 'aux' pointing
to a 'struct idmap', via the call to request_key_with_auxdata() in
nfs_idmap_request_key().
However it can also be reached via the request_key() system call in
which case 'aux' will be NULL, causing a NULL pointer dereference in
nfs_idmap_prepare_pipe_upcall(), assuming that the key description is
valid enough to get that far.
Fix this by making nfs_idmap_legacy_upcall() negate the key if no
auxdata is provided.
As usual, this bug was found by syzkaller. A simple reproducer using
the command-line keyctl program is:
keyctl request2 id_legacy uid:0 '' @s
Fixes: 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring")
Reported-by: syzbot+5dfdbcf7b3eb5912abbb(a)syzkaller.appspotmail.com
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Trond Myklebust <trondmy(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/nfs4idmap.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/nfs/nfs4idmap.c
+++ b/fs/nfs/nfs4idmap.c
@@ -567,9 +567,13 @@ static int nfs_idmap_legacy_upcall(struc
struct idmap_msg *im;
struct idmap *idmap = (struct idmap *)aux;
struct key *key = cons->key;
- int ret = -ENOMEM;
+ int ret = -ENOKEY;
+
+ if (!aux)
+ goto out1;
/* msg and im are freed in idmap_pipe_destroy_msg */
+ ret = -ENOMEM;
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
goto out1;
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
This is a note to let you know that I've just added the patch titled
nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds
to the 4.9-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:
nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
and it can be found in the queue-4.9 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 ba4a76f703ab7eb72941fdaac848502073d6e9ee Mon Sep 17 00:00:00 2001
From: Scott Mayhew <smayhew(a)redhat.com>
Date: Fri, 15 Dec 2017 16:12:32 -0500
Subject: nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds
From: Scott Mayhew <smayhew(a)redhat.com>
commit ba4a76f703ab7eb72941fdaac848502073d6e9ee upstream.
Currently when falling back to doing I/O through the MDS (via
pnfs_{read|write}_through_mds), the client frees the nfs_pgio_header
without releasing the reference taken on the dreq
via pnfs_generic_pg_{read|write}pages -> nfs_pgheader_init ->
nfs_direct_pgio_init. It then takes another reference on the dreq via
nfs_generic_pg_pgios -> nfs_pgheader_init -> nfs_direct_pgio_init and
as a result the requester will become stuck in inode_dio_wait. Once
that happens, other processes accessing the inode will become stuck as
well.
Ensure that pnfs_read_through_mds() and pnfs_write_through_mds() clean
up correctly by calling hdr->completion_ops->completion() instead of
calling hdr->release() directly.
This can be reproduced (sometimes) by performing "storage failover
takeover" commands on NetApp filer while doing direct I/O from a client.
This can also be reproduced using SystemTap to simulate a failure while
doing direct I/O from a client (from Dave Wysochanski
<dwysocha(a)redhat.com>):
stap -v -g -e 'probe module("nfs_layout_nfsv41_files").function("nfs4_fl_prepare_ds").return { $return=NULL; exit(); }'
Suggested-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Scott Mayhew <smayhew(a)redhat.com>
Fixes: 1ca018d28d ("pNFS: Fix a memory leak when attempted pnfs fails")
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/pnfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -2145,7 +2145,7 @@ pnfs_write_through_mds(struct nfs_pageio
nfs_pageio_reset_write_mds(desc);
mirror->pg_recoalesce = 1;
}
- hdr->release(hdr);
+ hdr->completion_ops->completion(hdr);
}
static enum pnfs_try_status
@@ -2256,7 +2256,7 @@ pnfs_read_through_mds(struct nfs_pageio_
nfs_pageio_reset_read_mds(desc);
mirror->pg_recoalesce = 1;
}
- hdr->release(hdr);
+ hdr->completion_ops->completion(hdr);
}
/*
Patches currently in stable-queue which might be from smayhew(a)redhat.com are
queue-4.9/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
This is a note to let you know that I've just added the patch titled
NFS: Fix a race between mmap() and O_DIRECT
to the 4.9-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:
nfs-fix-a-race-between-mmap-and-o_direct.patch
and it can be found in the queue-4.9 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 e231c6879cfd44e4fffd384bb6dd7d313249a523 Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Sun, 28 Jan 2018 09:29:41 -0500
Subject: NFS: Fix a race between mmap() and O_DIRECT
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
commit e231c6879cfd44e4fffd384bb6dd7d313249a523 upstream.
When locking the file in order to do O_DIRECT on it, we must unmap
any mmapped ranges on the pagecache so that we can flush out the
dirty data.
Fixes: a5864c999de67 ("NFS: Do not serialise O_DIRECT reads and writes")
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/io.c
+++ b/fs/nfs/io.c
@@ -98,7 +98,7 @@ static void nfs_block_buffered(struct nf
{
if (!test_bit(NFS_INO_ODIRECT, &nfsi->flags)) {
set_bit(NFS_INO_ODIRECT, &nfsi->flags);
- nfs_wb_all(inode);
+ nfs_sync_mapping(inode->i_mapping);
}
}
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.9/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
queue-4.9/nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
queue-4.9/nfs-commit-direct-writes-even-if-they-fail-partially.patch
queue-4.9/nfs-fix-a-race-between-mmap-and-o_direct.patch
This is a note to let you know that I've just added the patch titled
NFS: commit direct writes even if they fail partially
to the 4.9-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:
nfs-commit-direct-writes-even-if-they-fail-partially.patch
and it can be found in the queue-4.9 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 1b8d97b0a837beaf48a8449955b52c650a7114b4 Mon Sep 17 00:00:00 2001
From: "J. Bruce Fields" <bfields(a)redhat.com>
Date: Tue, 16 Jan 2018 10:08:00 -0500
Subject: NFS: commit direct writes even if they fail partially
From: J. Bruce Fields <bfields(a)redhat.com>
commit 1b8d97b0a837beaf48a8449955b52c650a7114b4 upstream.
If some of the WRITE calls making up an O_DIRECT write syscall fail,
we neglect to commit, even if some of the WRITEs succeed.
We also depend on the commit code to free the reference count on the
nfs_page taken in the "if (request_commit)" case at the end of
nfs_direct_write_completion(). The problem was originally noticed
because ENOSPC's encountered partway through a write would result in a
closed file being sillyrenamed when it should have been unlinked.
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/direct.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -787,10 +787,8 @@ static void nfs_direct_write_completion(
spin_lock(&dreq->lock);
- if (test_bit(NFS_IOHDR_ERROR, &hdr->flags)) {
- dreq->flags = 0;
+ if (test_bit(NFS_IOHDR_ERROR, &hdr->flags))
dreq->error = hdr->error;
- }
if (dreq->error == 0) {
nfs_direct_good_bytes(dreq, hdr);
if (nfs_write_need_commit(hdr)) {
Patches currently in stable-queue which might be from bfields(a)redhat.com are
queue-4.9/nfs-commit-direct-writes-even-if-they-fail-partially.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: sunxi: Fix ECC strength choice
to the 4.9-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:
mtd-nand-sunxi-fix-ecc-strength-choice.patch
and it can be found in the queue-4.9 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 f4c6cd1a7f2275d5bc0e494b21fff26f8dde80f0 Mon Sep 17 00:00:00 2001
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Date: Wed, 24 Jan 2018 23:49:31 +0100
Subject: mtd: nand: sunxi: Fix ECC strength choice
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
commit f4c6cd1a7f2275d5bc0e494b21fff26f8dde80f0 upstream.
When the requested ECC strength does not exactly match the strengths
supported by the ECC engine, the driver is selecting the closest
strength meeting the 'selected_strength > requested_strength'
constraint. Fix the fact that, in this particular case, ecc->strength
value was not updated to match the 'selected_strength'.
For instance, one can encounter this issue when no ECC requirement is
filled in the device tree while the NAND chip minimum requirement is not
a strength/step_size combo natively supported by the ECC engine.
Fixes: 1fef62c1423b ("mtd: nand: add sunxi NAND flash controller support")
Suggested-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/sunxi_nand.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -1835,8 +1835,14 @@ static int sunxi_nand_hw_common_ecc_ctrl
/* Add ECC info retrieval from DT */
for (i = 0; i < ARRAY_SIZE(strengths); i++) {
- if (ecc->strength <= strengths[i])
+ if (ecc->strength <= strengths[i]) {
+ /*
+ * Update ecc->strength value with the actual strength
+ * that will be used by the ECC engine.
+ */
+ ecc->strength = strengths[i];
break;
+ }
}
if (i >= ARRAY_SIZE(strengths)) {
Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are
queue-4.9/mtd-nand-sunxi-fix-ecc-strength-choice.patch
queue-4.9/mtd-nand-fix-nand_do_read_oob-return-value.patch
This is a note to let you know that I've just added the patch titled
NFS: Add a cond_resched() to nfs_commit_release_pages()
to the 4.9-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:
nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
and it can be found in the queue-4.9 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 7f1bda447c9bd48b415acedba6b830f61591601f Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Mon, 18 Dec 2017 14:39:13 -0500
Subject: NFS: Add a cond_resched() to nfs_commit_release_pages()
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
commit 7f1bda447c9bd48b415acedba6b830f61591601f upstream.
The commit list can get very large, and so we need a cond_resched()
in nfs_commit_release_pages() in order to ensure we don't hog the CPU
for excessive periods of time.
Reported-by: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/write.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1806,6 +1806,8 @@ static void nfs_commit_release_pages(str
set_bit(NFS_CONTEXT_RESEND_WRITES, &req->wb_context->flags);
next:
nfs_unlock_and_release_request(req);
+ /* Latency breaker */
+ cond_resched();
}
nfss = NFS_SERVER(data->inode);
if (atomic_long_read(&nfss->writeback) < NFS_CONGESTION_OFF_THRESH)
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.9/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
queue-4.9/nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
queue-4.9/nfs-commit-direct-writes-even-if-they-fail-partially.patch
queue-4.9/nfs-fix-a-race-between-mmap-and-o_direct.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: Fix nand_do_read_oob() return value
to the 4.9-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:
mtd-nand-fix-nand_do_read_oob-return-value.patch
and it can be found in the queue-4.9 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 87e89ce8d0d14f573c068c61bec2117751fb5103 Mon Sep 17 00:00:00 2001
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Date: Fri, 12 Jan 2018 10:13:36 +0100
Subject: mtd: nand: Fix nand_do_read_oob() return value
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
commit 87e89ce8d0d14f573c068c61bec2117751fb5103 upstream.
Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in
OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a
negative error, and the MTD layer expected it.
However, the trend for the NAND layer is now to return an error or a
positive number of bitflips. Deciding which status to return to the user
belongs to the MTD layer.
Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
brought this logic to the mtd_read_oob() function while the return value
coming from nand_do_read_oob() (called by the ->_read_oob() hook) was
left unchanged.
Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/nand_base.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2320,6 +2320,7 @@ EXPORT_SYMBOL(nand_write_oob_syndrome);
static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
struct mtd_oob_ops *ops)
{
+ unsigned int max_bitflips = 0;
int page, realpage, chipnr;
struct nand_chip *chip = mtd_to_nand(mtd);
struct mtd_ecc_stats stats;
@@ -2377,6 +2378,8 @@ static int nand_do_read_oob(struct mtd_i
nand_wait_ready(mtd);
}
+ max_bitflips = max_t(unsigned int, max_bitflips, ret);
+
readlen -= len;
if (!readlen)
break;
@@ -2402,7 +2405,7 @@ static int nand_do_read_oob(struct mtd_i
if (mtd->ecc_stats.failed - stats.failed)
return -EBADMSG;
- return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
+ return max_bitflips;
}
/**
Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are
queue-4.9/mtd-nand-sunxi-fix-ecc-strength-choice.patch
queue-4.9/mtd-nand-fix-nand_do_read_oob-return-value.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: brcmnand: Disable prefetch by default
to the 4.9-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:
mtd-nand-brcmnand-disable-prefetch-by-default.patch
and it can be found in the queue-4.9 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 f953f0f89663c39f08f4baaa8a4a881401b65654 Mon Sep 17 00:00:00 2001
From: Kamal Dasu <kdasu.kdev(a)gmail.com>
Date: Mon, 8 Jan 2018 15:36:48 -0500
Subject: mtd: nand: brcmnand: Disable prefetch by default
From: Kamal Dasu <kdasu.kdev(a)gmail.com>
commit f953f0f89663c39f08f4baaa8a4a881401b65654 upstream.
Brcm nand controller prefetch feature needs to be disabled
by default. Enabling affects performance on random reads as
well as dma reads.
Signed-off-by: Kamal Dasu <kdasu.kdev(a)gmail.com>
Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
Acked-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/brcmnand/brcmnand.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -2193,16 +2193,9 @@ static int brcmnand_setup_dev(struct brc
if (ctrl->nand_version >= 0x0702)
tmp |= ACC_CONTROL_RD_ERASED;
tmp &= ~ACC_CONTROL_FAST_PGM_RDIN;
- if (ctrl->features & BRCMNAND_HAS_PREFETCH) {
- /*
- * FIXME: Flash DMA + prefetch may see spurious erased-page ECC
- * errors
- */
- if (has_flash_dma(ctrl))
- tmp &= ~ACC_CONTROL_PREFETCH;
- else
- tmp |= ACC_CONTROL_PREFETCH;
- }
+ if (ctrl->features & BRCMNAND_HAS_PREFETCH)
+ tmp &= ~ACC_CONTROL_PREFETCH;
+
nand_writereg(ctrl, offs, tmp);
return 0;
Patches currently in stable-queue which might be from kdasu.kdev(a)gmail.com are
queue-4.9/mtd-nand-brcmnand-disable-prefetch-by-default.patch
This is a note to let you know that I've just added the patch titled
mtd: cfi: convert inline functions to macros
to the 4.9-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:
mtd-cfi-convert-inline-functions-to-macros.patch
and it can be found in the queue-4.9 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 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 11 Oct 2017 15:54:10 +0200
Subject: mtd: cfi: convert inline functions to macros
From: Arnd Bergmann <arnd(a)arndb.de>
commit 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 upstream.
The map_word_() functions, dating back to linux-2.6.8, try to perform
bitwise operations on a 'map_word' structure. This may have worked
with compilers that were current then (gcc-3.4 or earlier), but end
up being rather inefficient on any version I could try now (gcc-4.4 or
higher). Specifically we hit a problem analyzed in gcc PR81715 where we
fail to reuse the stack space for local variables.
This can be seen immediately in the stack consumption for
cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN)
can be up to 2200 bytes. Changing the inline functions into macros brings
this down to 1280 bytes. Without KASAN, the same problem exists, but
the stack consumption is lower to start with, my patch shrinks it from
920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around
1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word
structures for each call to one of these helpers.
With the latest gcc-8 snapshot, the problem is fixed in upstream gcc,
but nobody uses that yet, so we should still work around it in mainline
kernels and probably backport the workaround to stable kernels as well.
We had a couple of other functions that suffered from the same gcc bug,
and all of those had a simpler workaround involving dummy variables
in the inline function. Unfortunately that did not work here, the
macro hack was the best I could come up with.
It would also be helpful to have someone to a little performance testing
on the patch, to see how much it helps in terms of CPU utilitzation.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Acked-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/mtd/map.h | 130 ++++++++++++++++++++++--------------------------
1 file changed, 61 insertions(+), 69 deletions(-)
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -270,75 +270,67 @@ void map_destroy(struct mtd_info *mtd);
#define INVALIDATE_CACHED_RANGE(map, from, size) \
do { if (map->inval_cache) map->inval_cache(map, from, size); } while (0)
-
-static inline int map_word_equal(struct map_info *map, map_word val1, map_word val2)
-{
- int i;
-
- for (i = 0; i < map_words(map); i++) {
- if (val1.x[i] != val2.x[i])
- return 0;
- }
-
- return 1;
-}
-
-static inline map_word map_word_and(struct map_info *map, map_word val1, map_word val2)
-{
- map_word r;
- int i;
-
- for (i = 0; i < map_words(map); i++)
- r.x[i] = val1.x[i] & val2.x[i];
-
- return r;
-}
-
-static inline map_word map_word_clr(struct map_info *map, map_word val1, map_word val2)
-{
- map_word r;
- int i;
-
- for (i = 0; i < map_words(map); i++)
- r.x[i] = val1.x[i] & ~val2.x[i];
-
- return r;
-}
-
-static inline map_word map_word_or(struct map_info *map, map_word val1, map_word val2)
-{
- map_word r;
- int i;
-
- for (i = 0; i < map_words(map); i++)
- r.x[i] = val1.x[i] | val2.x[i];
-
- return r;
-}
-
-static inline int map_word_andequal(struct map_info *map, map_word val1, map_word val2, map_word val3)
-{
- int i;
-
- for (i = 0; i < map_words(map); i++) {
- if ((val1.x[i] & val2.x[i]) != val3.x[i])
- return 0;
- }
-
- return 1;
-}
-
-static inline int map_word_bitsset(struct map_info *map, map_word val1, map_word val2)
-{
- int i;
-
- for (i = 0; i < map_words(map); i++) {
- if (val1.x[i] & val2.x[i])
- return 1;
- }
-
- return 0;
-}
+#define map_word_equal(map, val1, val2) \
+({ \
+ int i, ret = 1; \
+ for (i = 0; i < map_words(map); i++) \
+ if ((val1).x[i] != (val2).x[i]) { \
+ ret = 0; \
+ break; \
+ } \
+ ret; \
+})
+
+#define map_word_and(map, val1, val2) \
+({ \
+ map_word r; \
+ int i; \
+ for (i = 0; i < map_words(map); i++) \
+ r.x[i] = (val1).x[i] & (val2).x[i]; \
+ r; \
+})
+
+#define map_word_clr(map, val1, val2) \
+({ \
+ map_word r; \
+ int i; \
+ for (i = 0; i < map_words(map); i++) \
+ r.x[i] = (val1).x[i] & ~(val2).x[i]; \
+ r; \
+})
+
+#define map_word_or(map, val1, val2) \
+({ \
+ map_word r; \
+ int i; \
+ for (i = 0; i < map_words(map); i++) \
+ r.x[i] = (val1).x[i] | (val2).x[i]; \
+ r; \
+})
+
+#define map_word_andequal(map, val1, val2, val3) \
+({ \
+ int i, ret = 1; \
+ for (i = 0; i < map_words(map); i++) { \
+ if (((val1).x[i] & (val2).x[i]) != (val2).x[i]) { \
+ ret = 0; \
+ break; \
+ } \
+ } \
+ ret; \
+})
+
+#define map_word_bitsset(map, val1, val2) \
+({ \
+ int i, ret = 0; \
+ for (i = 0; i < map_words(map); i++) { \
+ if ((val1).x[i] & (val2).x[i]) { \
+ ret = 1; \
+ break; \
+ } \
+ } \
+ ret; \
+})
static inline map_word map_word_load(struct map_info *map, const void *ptr)
{
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.9/mtd-cfi-convert-inline-functions-to-macros.patch
This is a note to let you know that I've just added the patch titled
kernfs: fix regression in kernfs_fop_write caused by wrong type
to the 4.9-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:
kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.patch
and it can be found in the queue-4.9 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 ba87977a49913129962af8ac35b0e13e0fa4382d Mon Sep 17 00:00:00 2001
From: Ivan Vecera <ivecera(a)redhat.com>
Date: Fri, 19 Jan 2018 09:18:54 +0100
Subject: kernfs: fix regression in kernfs_fop_write caused by wrong type
From: Ivan Vecera <ivecera(a)redhat.com>
commit ba87977a49913129962af8ac35b0e13e0fa4382d upstream.
Commit b7ce40cff0b9 ("kernfs: cache atomic_write_len in
kernfs_open_file") changes type of local variable 'len' from ssize_t
to size_t. This change caused that the *ppos value is updated also
when the previous write callback failed.
Mentioned snippet:
...
len = ops->write(...); <- return value can be negative
...
if (len > 0) <- true here in this case
*ppos += len;
...
Fixes: b7ce40cff0b9 ("kernfs: cache atomic_write_len in kernfs_open_file")
Acked-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Ivan Vecera <ivecera(a)redhat.com>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/kernfs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -275,7 +275,7 @@ static ssize_t kernfs_fop_write(struct f
{
struct kernfs_open_file *of = kernfs_of(file);
const struct kernfs_ops *ops;
- size_t len;
+ ssize_t len;
char *buf;
if (of->atomic_write_len) {
Patches currently in stable-queue which might be from ivecera(a)redhat.com are
queue-4.9/kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.patch
This is a note to let you know that I've just added the patch titled
ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
to the 4.9-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:
ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
and it can be found in the queue-4.9 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 998008b779e424bd7513c434d0ab9c1268459009 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 6 Dec 2017 16:41:09 +0100
Subject: ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
From: Hans de Goede <hdegoede(a)redhat.com>
commit 998008b779e424bd7513c434d0ab9c1268459009 upstream.
Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
SATA controllers. This commit is a preparation patch for allowing a
different default sata link powermanagement policy for mobile chipsets.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/ahci.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -383,6 +383,10 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(INTEL, 0xa206), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa252), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa256), board_ahci }, /* Lewisburg RAID*/
+ { PCI_VDEVICE(INTEL, 0x0f22), board_ahci }, /* Bay Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x0f23), board_ahci }, /* Bay Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x22a3), board_ahci }, /* Cherry Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x5ae3), board_ahci }, /* Apollo Lake AHCI */
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.9/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.9/ahci-allow-setting-a-default-lpm-policy-for-mobile-chipsets.patch
queue-4.9/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
This is a note to let you know that I've just added the patch titled
ahci: Add Intel Cannon Lake PCH-H PCI ID
to the 4.9-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:
ahci-add-intel-cannon-lake-pch-h-pci-id.patch
and it can be found in the queue-4.9 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 f919dde0772a894c693a1eeabc77df69d6a9b937 Mon Sep 17 00:00:00 2001
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Date: Thu, 11 Jan 2018 15:55:50 +0300
Subject: ahci: Add Intel Cannon Lake PCH-H PCI ID
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
commit f919dde0772a894c693a1eeabc77df69d6a9b937 upstream.
Add Intel Cannon Lake PCH-H PCI ID to the list of supported controllers.
Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/ahci.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -391,6 +391,7 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(INTEL, 0xa206), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa252), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa256), board_ahci }, /* Lewisburg RAID*/
+ { PCI_VDEVICE(INTEL, 0xa356), board_ahci }, /* Cannon Lake PCH-H RAID */
{ PCI_VDEVICE(INTEL, 0x0f22), board_ahci_mobile }, /* Bay Trail AHCI */
{ PCI_VDEVICE(INTEL, 0x0f23), board_ahci_mobile }, /* Bay Trail AHCI */
{ PCI_VDEVICE(INTEL, 0x22a3), board_ahci_mobile }, /* Cherry Tr. AHCI */
Patches currently in stable-queue which might be from mika.westerberg(a)linux.intel.com are
queue-4.9/ahci-add-intel-cannon-lake-pch-h-pci-id.patch
This is a note to let you know that I've just added the patch titled
ubi: block: Fix locking for idr_alloc/idr_remove
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:
ubi-block-fix-locking-for-idr_alloc-idr_remove.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 7f29ae9f977bcdc3654e68bc36d170223c52fd48 Mon Sep 17 00:00:00 2001
From: Bradley Bolen <bradleybolen(a)gmail.com>
Date: Thu, 18 Jan 2018 08:55:20 -0500
Subject: ubi: block: Fix locking for idr_alloc/idr_remove
From: Bradley Bolen <bradleybolen(a)gmail.com>
commit 7f29ae9f977bcdc3654e68bc36d170223c52fd48 upstream.
This fixes a race with idr_alloc where gd->first_minor can be set to the
same value for two simultaneous calls to ubiblock_create. Each instance
calls device_add_disk with the same first_minor. device_add_disk calls
bdi_register_owner which generates several warnings.
WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
sysfs_warn_dup+0x68/0x88
sysfs: cannot create duplicate filename '/devices/virtual/bdi/252:2'
WARNING: CPU: 1 PID: 179 at kernel-source/lib/kobject.c:240
kobject_add_internal+0x1ec/0x2f8
kobject_add_internal failed for 252:2 with -EEXIST, don't try to
register things with the same name in the same directory
WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
sysfs_warn_dup+0x68/0x88
sysfs: cannot create duplicate filename '/dev/block/252:2'
However, device_add_disk does not error out when bdi_register_owner
returns an error. Control continues until reaching blk_register_queue.
It then BUGs.
kernel BUG at kernel-source/fs/sysfs/group.c:113!
[<c01e26cc>] (internal_create_group) from [<c01e2950>]
(sysfs_create_group+0x20/0x24)
[<c01e2950>] (sysfs_create_group) from [<c00e3d38>]
(blk_trace_init_sysfs+0x18/0x20)
[<c00e3d38>] (blk_trace_init_sysfs) from [<c02bdfbc>]
(blk_register_queue+0xd8/0x154)
[<c02bdfbc>] (blk_register_queue) from [<c02cec84>]
(device_add_disk+0x194/0x44c)
[<c02cec84>] (device_add_disk) from [<c0436ec8>]
(ubiblock_create+0x284/0x2e0)
[<c0436ec8>] (ubiblock_create) from [<c0427bb8>]
(vol_cdev_ioctl+0x450/0x554)
[<c0427bb8>] (vol_cdev_ioctl) from [<c0189110>] (vfs_ioctl+0x30/0x44)
[<c0189110>] (vfs_ioctl) from [<c01892e0>] (do_vfs_ioctl+0xa0/0x790)
[<c01892e0>] (do_vfs_ioctl) from [<c0189a14>] (SyS_ioctl+0x44/0x68)
[<c0189a14>] (SyS_ioctl) from [<c0010640>] (ret_fast_syscall+0x0/0x34)
Locking idr_alloc/idr_remove removes the race and keeps gd->first_minor
unique.
Fixes: 2bf50d42f3a4 ("UBI: block: Dynamically allocate minor numbers")
Signed-off-by: Bradley Bolen <bradleybolen(a)gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/ubi/block.c | 42 ++++++++++++++++++++++++++----------------
1 file changed, 26 insertions(+), 16 deletions(-)
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
@@ -99,6 +99,8 @@ struct ubiblock {
/* Linked list of all ubiblock instances */
static LIST_HEAD(ubiblock_devices);
+static DEFINE_IDR(ubiblock_minor_idr);
+/* Protects ubiblock_devices and ubiblock_minor_idr */
static DEFINE_MUTEX(devices_mutex);
static int ubiblock_major;
@@ -354,8 +356,6 @@ static struct blk_mq_ops ubiblock_mq_ops
.map_queue = blk_mq_map_queue,
};
-static DEFINE_IDR(ubiblock_minor_idr);
-
int ubiblock_create(struct ubi_volume_info *vi)
{
struct ubiblock *dev;
@@ -368,14 +368,15 @@ int ubiblock_create(struct ubi_volume_in
/* Check that the volume isn't already handled */
mutex_lock(&devices_mutex);
if (find_dev_nolock(vi->ubi_num, vi->vol_id)) {
- mutex_unlock(&devices_mutex);
- return -EEXIST;
+ ret = -EEXIST;
+ goto out_unlock;
}
- mutex_unlock(&devices_mutex);
dev = kzalloc(sizeof(struct ubiblock), GFP_KERNEL);
- if (!dev)
- return -ENOMEM;
+ if (!dev) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
mutex_init(&dev->dev_mutex);
@@ -440,14 +441,13 @@ int ubiblock_create(struct ubi_volume_in
goto out_free_queue;
}
- mutex_lock(&devices_mutex);
list_add_tail(&dev->list, &ubiblock_devices);
- mutex_unlock(&devices_mutex);
/* Must be the last step: anyone can call file ops from now on */
add_disk(dev->gd);
dev_info(disk_to_dev(dev->gd), "created from ubi%d:%d(%s)",
dev->ubi_num, dev->vol_id, vi->name);
+ mutex_unlock(&devices_mutex);
return 0;
out_free_queue:
@@ -460,6 +460,8 @@ out_put_disk:
put_disk(dev->gd);
out_free_dev:
kfree(dev);
+out_unlock:
+ mutex_unlock(&devices_mutex);
return ret;
}
@@ -481,30 +483,36 @@ static void ubiblock_cleanup(struct ubib
int ubiblock_remove(struct ubi_volume_info *vi)
{
struct ubiblock *dev;
+ int ret;
mutex_lock(&devices_mutex);
dev = find_dev_nolock(vi->ubi_num, vi->vol_id);
if (!dev) {
- mutex_unlock(&devices_mutex);
- return -ENODEV;
+ ret = -ENODEV;
+ goto out_unlock;
}
/* Found a device, let's lock it so we can check if it's busy */
mutex_lock(&dev->dev_mutex);
if (dev->refcnt > 0) {
- mutex_unlock(&dev->dev_mutex);
- mutex_unlock(&devices_mutex);
- return -EBUSY;
+ ret = -EBUSY;
+ goto out_unlock_dev;
}
/* Remove from device list */
list_del(&dev->list);
- mutex_unlock(&devices_mutex);
-
ubiblock_cleanup(dev);
mutex_unlock(&dev->dev_mutex);
+ mutex_unlock(&devices_mutex);
+
kfree(dev);
return 0;
+
+out_unlock_dev:
+ mutex_unlock(&dev->dev_mutex);
+out_unlock:
+ mutex_unlock(&devices_mutex);
+ return ret;
}
static int ubiblock_resize(struct ubi_volume_info *vi)
@@ -633,6 +641,7 @@ static void ubiblock_remove_all(void)
struct ubiblock *next;
struct ubiblock *dev;
+ mutex_lock(&devices_mutex);
list_for_each_entry_safe(dev, next, &ubiblock_devices, list) {
/* The module is being forcefully removed */
WARN_ON(dev->desc);
@@ -641,6 +650,7 @@ static void ubiblock_remove_all(void)
ubiblock_cleanup(dev);
kfree(dev);
}
+ mutex_unlock(&devices_mutex);
}
int __init ubiblock_init(void)
Patches currently in stable-queue which might be from bradleybolen(a)gmail.com are
queue-4.4/ubi-block-fix-locking-for-idr_alloc-idr_remove.patch
This is a note to let you know that I've just added the patch titled
NFS: reject request for id_legacy key without auxdata
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:
nfs-reject-request-for-id_legacy-key-without-auxdata.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 49686cbbb3ebafe42e63868222f269d8053ead00 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Fri, 19 Jan 2018 15:15:34 -0800
Subject: NFS: reject request for id_legacy key without auxdata
From: Eric Biggers <ebiggers(a)google.com>
commit 49686cbbb3ebafe42e63868222f269d8053ead00 upstream.
nfs_idmap_legacy_upcall() is supposed to be called with 'aux' pointing
to a 'struct idmap', via the call to request_key_with_auxdata() in
nfs_idmap_request_key().
However it can also be reached via the request_key() system call in
which case 'aux' will be NULL, causing a NULL pointer dereference in
nfs_idmap_prepare_pipe_upcall(), assuming that the key description is
valid enough to get that far.
Fix this by making nfs_idmap_legacy_upcall() negate the key if no
auxdata is provided.
As usual, this bug was found by syzkaller. A simple reproducer using
the command-line keyctl program is:
keyctl request2 id_legacy uid:0 '' @s
Fixes: 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring")
Reported-by: syzbot+5dfdbcf7b3eb5912abbb(a)syzkaller.appspotmail.com
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Trond Myklebust <trondmy(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/nfs4idmap.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/nfs/nfs4idmap.c
+++ b/fs/nfs/nfs4idmap.c
@@ -567,9 +567,13 @@ static int nfs_idmap_legacy_upcall(struc
struct idmap_msg *im;
struct idmap *idmap = (struct idmap *)aux;
struct key *key = cons->key;
- int ret = -ENOMEM;
+ int ret = -ENOKEY;
+
+ if (!aux)
+ goto out1;
/* msg and im are freed in idmap_pipe_destroy_msg */
+ ret = -ENOMEM;
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
goto out1;
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.4/keys-encrypted-fix-buffer-overread-in-valid_master_desc.patch
queue-4.4/x86-kaiser-fix-build-error-with-kasan-function_graph_tracer.patch
queue-4.4/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
This is a note to let you know that I've just added the patch titled
nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds
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:
nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.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 ba4a76f703ab7eb72941fdaac848502073d6e9ee Mon Sep 17 00:00:00 2001
From: Scott Mayhew <smayhew(a)redhat.com>
Date: Fri, 15 Dec 2017 16:12:32 -0500
Subject: nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds
From: Scott Mayhew <smayhew(a)redhat.com>
commit ba4a76f703ab7eb72941fdaac848502073d6e9ee upstream.
Currently when falling back to doing I/O through the MDS (via
pnfs_{read|write}_through_mds), the client frees the nfs_pgio_header
without releasing the reference taken on the dreq
via pnfs_generic_pg_{read|write}pages -> nfs_pgheader_init ->
nfs_direct_pgio_init. It then takes another reference on the dreq via
nfs_generic_pg_pgios -> nfs_pgheader_init -> nfs_direct_pgio_init and
as a result the requester will become stuck in inode_dio_wait. Once
that happens, other processes accessing the inode will become stuck as
well.
Ensure that pnfs_read_through_mds() and pnfs_write_through_mds() clean
up correctly by calling hdr->completion_ops->completion() instead of
calling hdr->release() directly.
This can be reproduced (sometimes) by performing "storage failover
takeover" commands on NetApp filer while doing direct I/O from a client.
This can also be reproduced using SystemTap to simulate a failure while
doing direct I/O from a client (from Dave Wysochanski
<dwysocha(a)redhat.com>):
stap -v -g -e 'probe module("nfs_layout_nfsv41_files").function("nfs4_fl_prepare_ds").return { $return=NULL; exit(); }'
Suggested-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Scott Mayhew <smayhew(a)redhat.com>
Fixes: 1ca018d28d ("pNFS: Fix a memory leak when attempted pnfs fails")
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/pnfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -1943,7 +1943,7 @@ pnfs_write_through_mds(struct nfs_pageio
nfs_pageio_reset_write_mds(desc);
mirror->pg_recoalesce = 1;
}
- hdr->release(hdr);
+ hdr->completion_ops->completion(hdr);
}
static enum pnfs_try_status
@@ -2058,7 +2058,7 @@ pnfs_read_through_mds(struct nfs_pageio_
nfs_pageio_reset_read_mds(desc);
mirror->pg_recoalesce = 1;
}
- hdr->release(hdr);
+ hdr->completion_ops->completion(hdr);
}
/*
Patches currently in stable-queue which might be from smayhew(a)redhat.com are
queue-4.4/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
This is a note to let you know that I've just added the patch titled
NFS: commit direct writes even if they fail partially
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:
nfs-commit-direct-writes-even-if-they-fail-partially.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 1b8d97b0a837beaf48a8449955b52c650a7114b4 Mon Sep 17 00:00:00 2001
From: "J. Bruce Fields" <bfields(a)redhat.com>
Date: Tue, 16 Jan 2018 10:08:00 -0500
Subject: NFS: commit direct writes even if they fail partially
From: J. Bruce Fields <bfields(a)redhat.com>
commit 1b8d97b0a837beaf48a8449955b52c650a7114b4 upstream.
If some of the WRITE calls making up an O_DIRECT write syscall fail,
we neglect to commit, even if some of the WRITEs succeed.
We also depend on the commit code to free the reference count on the
nfs_page taken in the "if (request_commit)" case at the end of
nfs_direct_write_completion(). The problem was originally noticed
because ENOSPC's encountered partway through a write would result in a
closed file being sillyrenamed when it should have been unlinked.
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/direct.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -787,10 +787,8 @@ static void nfs_direct_write_completion(
spin_lock(&dreq->lock);
- if (test_bit(NFS_IOHDR_ERROR, &hdr->flags)) {
- dreq->flags = 0;
+ if (test_bit(NFS_IOHDR_ERROR, &hdr->flags))
dreq->error = hdr->error;
- }
if (dreq->error == 0) {
nfs_direct_good_bytes(dreq, hdr);
if (nfs_write_need_commit(hdr)) {
Patches currently in stable-queue which might be from bfields(a)redhat.com are
queue-4.4/nfs-commit-direct-writes-even-if-they-fail-partially.patch
This is a note to let you know that I've just added the patch titled
NFS: Add a cond_resched() to nfs_commit_release_pages()
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:
nfs-add-a-cond_resched-to-nfs_commit_release_pages.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 7f1bda447c9bd48b415acedba6b830f61591601f Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Mon, 18 Dec 2017 14:39:13 -0500
Subject: NFS: Add a cond_resched() to nfs_commit_release_pages()
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
commit 7f1bda447c9bd48b415acedba6b830f61591601f upstream.
The commit list can get very large, and so we need a cond_resched()
in nfs_commit_release_pages() in order to ensure we don't hog the CPU
for excessive periods of time.
Reported-by: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/write.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1746,6 +1746,8 @@ static void nfs_commit_release_pages(str
set_bit(NFS_CONTEXT_RESEND_WRITES, &req->wb_context->flags);
next:
nfs_unlock_and_release_request(req);
+ /* Latency breaker */
+ cond_resched();
}
nfss = NFS_SERVER(data->inode);
if (atomic_long_read(&nfss->writeback) < NFS_CONGESTION_OFF_THRESH)
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.4/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
queue-4.4/nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
queue-4.4/nfs-commit-direct-writes-even-if-they-fail-partially.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: sunxi: Fix ECC strength choice
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:
mtd-nand-sunxi-fix-ecc-strength-choice.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 f4c6cd1a7f2275d5bc0e494b21fff26f8dde80f0 Mon Sep 17 00:00:00 2001
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Date: Wed, 24 Jan 2018 23:49:31 +0100
Subject: mtd: nand: sunxi: Fix ECC strength choice
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
commit f4c6cd1a7f2275d5bc0e494b21fff26f8dde80f0 upstream.
When the requested ECC strength does not exactly match the strengths
supported by the ECC engine, the driver is selecting the closest
strength meeting the 'selected_strength > requested_strength'
constraint. Fix the fact that, in this particular case, ecc->strength
value was not updated to match the 'selected_strength'.
For instance, one can encounter this issue when no ECC requirement is
filled in the device tree while the NAND chip minimum requirement is not
a strength/step_size combo natively supported by the ECC engine.
Fixes: 1fef62c1423b ("mtd: nand: add sunxi NAND flash controller support")
Suggested-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/sunxi_nand.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -1046,8 +1046,14 @@ static int sunxi_nand_hw_common_ecc_ctrl
/* Add ECC info retrieval from DT */
for (i = 0; i < ARRAY_SIZE(strengths); i++) {
- if (ecc->strength <= strengths[i])
+ if (ecc->strength <= strengths[i]) {
+ /*
+ * Update ecc->strength value with the actual strength
+ * that will be used by the ECC engine.
+ */
+ ecc->strength = strengths[i];
break;
+ }
}
if (i >= ARRAY_SIZE(strengths)) {
Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are
queue-4.4/mtd-nand-sunxi-fix-ecc-strength-choice.patch
queue-4.4/mtd-nand-fix-nand_do_read_oob-return-value.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: Fix nand_do_read_oob() return value
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:
mtd-nand-fix-nand_do_read_oob-return-value.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 87e89ce8d0d14f573c068c61bec2117751fb5103 Mon Sep 17 00:00:00 2001
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Date: Fri, 12 Jan 2018 10:13:36 +0100
Subject: mtd: nand: Fix nand_do_read_oob() return value
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
commit 87e89ce8d0d14f573c068c61bec2117751fb5103 upstream.
Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in
OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a
negative error, and the MTD layer expected it.
However, the trend for the NAND layer is now to return an error or a
positive number of bitflips. Deciding which status to return to the user
belongs to the MTD layer.
Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
brought this logic to the mtd_read_oob() function while the return value
coming from nand_do_read_oob() (called by the ->_read_oob() hook) was
left unchanged.
Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/nand_base.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2023,6 +2023,7 @@ static int nand_write_oob_syndrome(struc
static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
struct mtd_oob_ops *ops)
{
+ unsigned int max_bitflips = 0;
int page, realpage, chipnr;
struct nand_chip *chip = mtd->priv;
struct mtd_ecc_stats stats;
@@ -2083,6 +2084,8 @@ static int nand_do_read_oob(struct mtd_i
nand_wait_ready(mtd);
}
+ max_bitflips = max_t(unsigned int, max_bitflips, ret);
+
readlen -= len;
if (!readlen)
break;
@@ -2108,7 +2111,7 @@ static int nand_do_read_oob(struct mtd_i
if (mtd->ecc_stats.failed - stats.failed)
return -EBADMSG;
- return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
+ return max_bitflips;
}
/**
Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are
queue-4.4/mtd-nand-sunxi-fix-ecc-strength-choice.patch
queue-4.4/mtd-nand-fix-nand_do_read_oob-return-value.patch
This is a note to let you know that I've just added the patch titled
mtd: cfi: convert inline functions to macros
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:
mtd-cfi-convert-inline-functions-to-macros.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 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 11 Oct 2017 15:54:10 +0200
Subject: mtd: cfi: convert inline functions to macros
From: Arnd Bergmann <arnd(a)arndb.de>
commit 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 upstream.
The map_word_() functions, dating back to linux-2.6.8, try to perform
bitwise operations on a 'map_word' structure. This may have worked
with compilers that were current then (gcc-3.4 or earlier), but end
up being rather inefficient on any version I could try now (gcc-4.4 or
higher). Specifically we hit a problem analyzed in gcc PR81715 where we
fail to reuse the stack space for local variables.
This can be seen immediately in the stack consumption for
cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN)
can be up to 2200 bytes. Changing the inline functions into macros brings
this down to 1280 bytes. Without KASAN, the same problem exists, but
the stack consumption is lower to start with, my patch shrinks it from
920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around
1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word
structures for each call to one of these helpers.
With the latest gcc-8 snapshot, the problem is fixed in upstream gcc,
but nobody uses that yet, so we should still work around it in mainline
kernels and probably backport the workaround to stable kernels as well.
We had a couple of other functions that suffered from the same gcc bug,
and all of those had a simpler workaround involving dummy variables
in the inline function. Unfortunately that did not work here, the
macro hack was the best I could come up with.
It would also be helpful to have someone to a little performance testing
on the patch, to see how much it helps in terms of CPU utilitzation.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Acked-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/mtd/map.h | 130 ++++++++++++++++++++++--------------------------
1 file changed, 61 insertions(+), 69 deletions(-)
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -265,75 +265,67 @@ void map_destroy(struct mtd_info *mtd);
#define INVALIDATE_CACHED_RANGE(map, from, size) \
do { if (map->inval_cache) map->inval_cache(map, from, size); } while (0)
-
-static inline int map_word_equal(struct map_info *map, map_word val1, map_word val2)
-{
- int i;
-
- for (i = 0; i < map_words(map); i++) {
- if (val1.x[i] != val2.x[i])
- return 0;
- }
-
- return 1;
-}
-
-static inline map_word map_word_and(struct map_info *map, map_word val1, map_word val2)
-{
- map_word r;
- int i;
-
- for (i = 0; i < map_words(map); i++)
- r.x[i] = val1.x[i] & val2.x[i];
-
- return r;
-}
-
-static inline map_word map_word_clr(struct map_info *map, map_word val1, map_word val2)
-{
- map_word r;
- int i;
-
- for (i = 0; i < map_words(map); i++)
- r.x[i] = val1.x[i] & ~val2.x[i];
-
- return r;
-}
-
-static inline map_word map_word_or(struct map_info *map, map_word val1, map_word val2)
-{
- map_word r;
- int i;
-
- for (i = 0; i < map_words(map); i++)
- r.x[i] = val1.x[i] | val2.x[i];
-
- return r;
-}
-
-static inline int map_word_andequal(struct map_info *map, map_word val1, map_word val2, map_word val3)
-{
- int i;
-
- for (i = 0; i < map_words(map); i++) {
- if ((val1.x[i] & val2.x[i]) != val3.x[i])
- return 0;
- }
-
- return 1;
-}
-
-static inline int map_word_bitsset(struct map_info *map, map_word val1, map_word val2)
-{
- int i;
-
- for (i = 0; i < map_words(map); i++) {
- if (val1.x[i] & val2.x[i])
- return 1;
- }
-
- return 0;
-}
+#define map_word_equal(map, val1, val2) \
+({ \
+ int i, ret = 1; \
+ for (i = 0; i < map_words(map); i++) \
+ if ((val1).x[i] != (val2).x[i]) { \
+ ret = 0; \
+ break; \
+ } \
+ ret; \
+})
+
+#define map_word_and(map, val1, val2) \
+({ \
+ map_word r; \
+ int i; \
+ for (i = 0; i < map_words(map); i++) \
+ r.x[i] = (val1).x[i] & (val2).x[i]; \
+ r; \
+})
+
+#define map_word_clr(map, val1, val2) \
+({ \
+ map_word r; \
+ int i; \
+ for (i = 0; i < map_words(map); i++) \
+ r.x[i] = (val1).x[i] & ~(val2).x[i]; \
+ r; \
+})
+
+#define map_word_or(map, val1, val2) \
+({ \
+ map_word r; \
+ int i; \
+ for (i = 0; i < map_words(map); i++) \
+ r.x[i] = (val1).x[i] | (val2).x[i]; \
+ r; \
+})
+
+#define map_word_andequal(map, val1, val2, val3) \
+({ \
+ int i, ret = 1; \
+ for (i = 0; i < map_words(map); i++) { \
+ if (((val1).x[i] & (val2).x[i]) != (val2).x[i]) { \
+ ret = 0; \
+ break; \
+ } \
+ } \
+ ret; \
+})
+
+#define map_word_bitsset(map, val1, val2) \
+({ \
+ int i, ret = 0; \
+ for (i = 0; i < map_words(map); i++) { \
+ if ((val1).x[i] & (val2).x[i]) { \
+ ret = 1; \
+ break; \
+ } \
+ } \
+ ret; \
+})
static inline map_word map_word_load(struct map_info *map, const void *ptr)
{
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.4/mtd-cfi-convert-inline-functions-to-macros.patch
queue-4.4/x86-asm-fix-inline-asm-call-constraints-for-gcc-4.4.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: brcmnand: Disable prefetch by default
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:
mtd-nand-brcmnand-disable-prefetch-by-default.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 f953f0f89663c39f08f4baaa8a4a881401b65654 Mon Sep 17 00:00:00 2001
From: Kamal Dasu <kdasu.kdev(a)gmail.com>
Date: Mon, 8 Jan 2018 15:36:48 -0500
Subject: mtd: nand: brcmnand: Disable prefetch by default
From: Kamal Dasu <kdasu.kdev(a)gmail.com>
commit f953f0f89663c39f08f4baaa8a4a881401b65654 upstream.
Brcm nand controller prefetch feature needs to be disabled
by default. Enabling affects performance on random reads as
well as dma reads.
Signed-off-by: Kamal Dasu <kdasu.kdev(a)gmail.com>
Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
Acked-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/brcmnand/brcmnand.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1922,16 +1922,9 @@ static int brcmnand_setup_dev(struct brc
tmp &= ~ACC_CONTROL_PARTIAL_PAGE;
tmp &= ~ACC_CONTROL_RD_ERASED;
tmp &= ~ACC_CONTROL_FAST_PGM_RDIN;
- if (ctrl->features & BRCMNAND_HAS_PREFETCH) {
- /*
- * FIXME: Flash DMA + prefetch may see spurious erased-page ECC
- * errors
- */
- if (has_flash_dma(ctrl))
- tmp &= ~ACC_CONTROL_PREFETCH;
- else
- tmp |= ACC_CONTROL_PREFETCH;
- }
+ if (ctrl->features & BRCMNAND_HAS_PREFETCH)
+ tmp &= ~ACC_CONTROL_PREFETCH;
+
nand_writereg(ctrl, offs, tmp);
return 0;
Patches currently in stable-queue which might be from kdasu.kdev(a)gmail.com are
queue-4.4/mtd-nand-brcmnand-disable-prefetch-by-default.patch
This is a note to let you know that I've just added the patch titled
kernfs: fix regression in kernfs_fop_write caused by wrong type
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:
kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.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 ba87977a49913129962af8ac35b0e13e0fa4382d Mon Sep 17 00:00:00 2001
From: Ivan Vecera <ivecera(a)redhat.com>
Date: Fri, 19 Jan 2018 09:18:54 +0100
Subject: kernfs: fix regression in kernfs_fop_write caused by wrong type
From: Ivan Vecera <ivecera(a)redhat.com>
commit ba87977a49913129962af8ac35b0e13e0fa4382d upstream.
Commit b7ce40cff0b9 ("kernfs: cache atomic_write_len in
kernfs_open_file") changes type of local variable 'len' from ssize_t
to size_t. This change caused that the *ppos value is updated also
when the previous write callback failed.
Mentioned snippet:
...
len = ops->write(...); <- return value can be negative
...
if (len > 0) <- true here in this case
*ppos += len;
...
Fixes: b7ce40cff0b9 ("kernfs: cache atomic_write_len in kernfs_open_file")
Acked-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Ivan Vecera <ivecera(a)redhat.com>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/kernfs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -272,7 +272,7 @@ static ssize_t kernfs_fop_write(struct f
{
struct kernfs_open_file *of = kernfs_of(file);
const struct kernfs_ops *ops;
- size_t len;
+ ssize_t len;
char *buf;
if (of->atomic_write_len) {
Patches currently in stable-queue which might be from ivecera(a)redhat.com are
queue-4.4/kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.patch
This is a note to let you know that I've just added the patch titled
ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
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:
ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.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 998008b779e424bd7513c434d0ab9c1268459009 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 6 Dec 2017 16:41:09 +0100
Subject: ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
From: Hans de Goede <hdegoede(a)redhat.com>
commit 998008b779e424bd7513c434d0ab9c1268459009 upstream.
Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
SATA controllers. This commit is a preparation patch for allowing a
different default sata link powermanagement policy for mobile chipsets.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/ahci.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -382,6 +382,10 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(INTEL, 0xa20e), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa252), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa256), board_ahci }, /* Lewisburg RAID*/
+ { PCI_VDEVICE(INTEL, 0x0f22), board_ahci }, /* Bay Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x0f23), board_ahci }, /* Bay Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x22a3), board_ahci }, /* Cherry Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x5ae3), board_ahci }, /* Apollo Lake AHCI */
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.4/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.4/ahci-allow-setting-a-default-lpm-policy-for-mobile-chipsets.patch
queue-4.4/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
This is a note to let you know that I've just added the patch titled
ahci: Add Intel Cannon Lake PCH-H PCI ID
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:
ahci-add-intel-cannon-lake-pch-h-pci-id.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 f919dde0772a894c693a1eeabc77df69d6a9b937 Mon Sep 17 00:00:00 2001
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Date: Thu, 11 Jan 2018 15:55:50 +0300
Subject: ahci: Add Intel Cannon Lake PCH-H PCI ID
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
commit f919dde0772a894c693a1eeabc77df69d6a9b937 upstream.
Add Intel Cannon Lake PCH-H PCI ID to the list of supported controllers.
Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/ahci.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -390,6 +390,7 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(INTEL, 0xa20e), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa252), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa256), board_ahci }, /* Lewisburg RAID*/
+ { PCI_VDEVICE(INTEL, 0xa356), board_ahci }, /* Cannon Lake PCH-H RAID */
{ PCI_VDEVICE(INTEL, 0x0f22), board_ahci_mobile }, /* Bay Trail AHCI */
{ PCI_VDEVICE(INTEL, 0x0f23), board_ahci_mobile }, /* Bay Trail AHCI */
{ PCI_VDEVICE(INTEL, 0x22a3), board_ahci_mobile }, /* Cherry Tr. AHCI */
Patches currently in stable-queue which might be from mika.westerberg(a)linux.intel.com are
queue-4.4/ahci-add-intel-cannon-lake-pch-h-pci-id.patch
This is a note to let you know that I've just added the patch titled
ubifs: free the encrypted symlink target
to the 4.15-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:
ubifs-free-the-encrypted-symlink-target.patch
and it can be found in the queue-4.15 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 6b46d444146eb8d0b99562795cea8086639d7282 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 11 Jan 2018 23:27:00 -0500
Subject: ubifs: free the encrypted symlink target
From: Eric Biggers <ebiggers(a)google.com>
commit 6b46d444146eb8d0b99562795cea8086639d7282 upstream.
ubifs_symlink() forgot to free the kmalloc()'ed buffer holding the
encrypted symlink target, creating a memory leak. Fix it.
(UBIFS could actually encrypt directly into ui->data, removing the
temporary buffer, but that is left for the patch that switches to use
the symlink helper functions.)
Fixes: ca7f85be8d6c ("ubifs: Add support for encrypted symlinks")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ubifs/dir.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -1216,10 +1216,8 @@ static int ubifs_symlink(struct inode *d
ostr.len = disk_link.len;
err = fscrypt_fname_usr_to_disk(inode, &istr, &ostr);
- if (err) {
- kfree(sd);
+ if (err)
goto out_inode;
- }
sd->len = cpu_to_le16(ostr.len);
disk_link.name = (char *)sd;
@@ -1251,11 +1249,10 @@ static int ubifs_symlink(struct inode *d
goto out_cancel;
mutex_unlock(&dir_ui->ui_mutex);
- ubifs_release_budget(c, &req);
insert_inode_hash(inode);
d_instantiate(dentry, inode);
- fscrypt_free_filename(&nm);
- return 0;
+ err = 0;
+ goto out_fname;
out_cancel:
dir->i_size -= sz_change;
@@ -1268,6 +1265,7 @@ out_fname:
fscrypt_free_filename(&nm);
out_budg:
ubifs_release_budget(c, &req);
+ kfree(sd);
return err;
}
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.15/ubifs-free-the-encrypted-symlink-target.patch
queue-4.15/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
This is a note to let you know that I've just added the patch titled
ubi: Fix race condition between ubi volume creation and udev
to the 4.15-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:
ubi-fix-race-condition-between-ubi-volume-creation-and-udev.patch
and it can be found in the queue-4.15 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 a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 Mon Sep 17 00:00:00 2001
From: Clay McClure <clay(a)daemons.net>
Date: Thu, 21 Sep 2017 19:01:34 -0700
Subject: ubi: Fix race condition between ubi volume creation and udev
From: Clay McClure <clay(a)daemons.net>
commit a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 upstream.
Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi
device creation and udev"), we should make the volume active before
registering it.
Signed-off-by: Clay McClure <clay(a)daemons.net>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/ubi/vmt.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
--- a/drivers/mtd/ubi/vmt.c
+++ b/drivers/mtd/ubi/vmt.c
@@ -270,6 +270,12 @@ int ubi_create_volume(struct ubi_device
vol->last_eb_bytes = vol->usable_leb_size;
}
+ /* Make volume "available" before it becomes accessible via sysfs */
+ spin_lock(&ubi->volumes_lock);
+ ubi->volumes[vol_id] = vol;
+ ubi->vol_count += 1;
+ spin_unlock(&ubi->volumes_lock);
+
/* Register character device for the volume */
cdev_init(&vol->cdev, &ubi_vol_cdev_operations);
vol->cdev.owner = THIS_MODULE;
@@ -298,11 +304,6 @@ int ubi_create_volume(struct ubi_device
if (err)
goto out_sysfs;
- spin_lock(&ubi->volumes_lock);
- ubi->volumes[vol_id] = vol;
- ubi->vol_count += 1;
- spin_unlock(&ubi->volumes_lock);
-
ubi_volume_notify(ubi, vol, UBI_VOLUME_ADDED);
self_check_volumes(ubi);
return err;
@@ -315,6 +316,10 @@ out_sysfs:
*/
cdev_device_del(&vol->cdev, &vol->dev);
out_mapping:
+ spin_lock(&ubi->volumes_lock);
+ ubi->volumes[vol_id] = NULL;
+ ubi->vol_count -= 1;
+ spin_unlock(&ubi->volumes_lock);
ubi_eba_destroy_table(eba_tbl);
out_acc:
spin_lock(&ubi->volumes_lock);
Patches currently in stable-queue which might be from clay(a)daemons.net are
queue-4.15/ubi-fix-race-condition-between-ubi-volume-creation-and-udev.patch
This is a note to let you know that I've just added the patch titled
ubi: fastmap: Erase outdated anchor PEBs during attach
to the 4.15-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:
ubi-fastmap-erase-outdated-anchor-pebs-during-attach.patch
and it can be found in the queue-4.15 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 f78e5623f45bab2b726eec29dc5cefbbab2d0b1c Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer(a)pengutronix.de>
Date: Tue, 5 Dec 2017 16:01:20 +0100
Subject: ubi: fastmap: Erase outdated anchor PEBs during attach
From: Sascha Hauer <s.hauer(a)pengutronix.de>
commit f78e5623f45bab2b726eec29dc5cefbbab2d0b1c upstream.
The fastmap update code might erase the current fastmap anchor PEB
in case it doesn't find any new free PEB. When a power cut happens
in this situation we must not have any outdated fastmap anchor PEB
on the device, because that would be used to attach during next
boot.
The easiest way to make that sure is to erase all outdated fastmap
anchor PEBs synchronously during attach.
Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de>
Reviewed-by: Richard Weinberger <richard(a)nod.at>
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/ubi/wl.c | 77 +++++++++++++++++++++++++++++++++++++--------------
1 file changed, 57 insertions(+), 20 deletions(-)
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1529,6 +1529,46 @@ static void shutdown_work(struct ubi_dev
}
/**
+ * erase_aeb - erase a PEB given in UBI attach info PEB
+ * @ubi: UBI device description object
+ * @aeb: UBI attach info PEB
+ * @sync: If true, erase synchronously. Otherwise schedule for erasure
+ */
+static int erase_aeb(struct ubi_device *ubi, struct ubi_ainf_peb *aeb, bool sync)
+{
+ struct ubi_wl_entry *e;
+ int err;
+
+ e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
+ if (!e)
+ return -ENOMEM;
+
+ e->pnum = aeb->pnum;
+ e->ec = aeb->ec;
+ ubi->lookuptbl[e->pnum] = e;
+
+ if (sync) {
+ err = sync_erase(ubi, e, false);
+ if (err)
+ goto out_free;
+
+ wl_tree_add(e, &ubi->free);
+ ubi->free_count++;
+ } else {
+ err = schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false);
+ if (err)
+ goto out_free;
+ }
+
+ return 0;
+
+out_free:
+ wl_entry_destroy(ubi, e);
+
+ return err;
+}
+
+/**
* ubi_wl_init - initialize the WL sub-system using attaching information.
* @ubi: UBI device description object
* @ai: attaching information
@@ -1566,17 +1606,9 @@ int ubi_wl_init(struct ubi_device *ubi,
list_for_each_entry_safe(aeb, tmp, &ai->erase, u.list) {
cond_resched();
- e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
- if (!e)
- goto out_free;
-
- e->pnum = aeb->pnum;
- e->ec = aeb->ec;
- ubi->lookuptbl[e->pnum] = e;
- if (schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false)) {
- wl_entry_destroy(ubi, e);
+ err = erase_aeb(ubi, aeb, false);
+ if (err)
goto out_free;
- }
found_pebs++;
}
@@ -1635,6 +1667,8 @@ int ubi_wl_init(struct ubi_device *ubi,
ubi_assert(!ubi->lookuptbl[e->pnum]);
ubi->lookuptbl[e->pnum] = e;
} else {
+ bool sync = false;
+
/*
* Usually old Fastmap PEBs are scheduled for erasure
* and we don't have to care about them but if we face
@@ -1644,18 +1678,21 @@ int ubi_wl_init(struct ubi_device *ubi,
if (ubi->lookuptbl[aeb->pnum])
continue;
- e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
- if (!e)
- goto out_free;
+ /*
+ * The fastmap update code might not find a free PEB for
+ * writing the fastmap anchor to and then reuses the
+ * current fastmap anchor PEB. When this PEB gets erased
+ * and a power cut happens before it is written again we
+ * must make sure that the fastmap attach code doesn't
+ * find any outdated fastmap anchors, hence we erase the
+ * outdated fastmap anchor PEBs synchronously here.
+ */
+ if (aeb->vol_id == UBI_FM_SB_VOLUME_ID)
+ sync = true;
- e->pnum = aeb->pnum;
- e->ec = aeb->ec;
- ubi_assert(!ubi->lookuptbl[e->pnum]);
- ubi->lookuptbl[e->pnum] = e;
- if (schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false)) {
- wl_entry_destroy(ubi, e);
+ err = erase_aeb(ubi, aeb, sync);
+ if (err)
goto out_free;
- }
}
found_pebs++;
Patches currently in stable-queue which might be from s.hauer(a)pengutronix.de are
queue-4.15/ubi-fastmap-erase-outdated-anchor-pebs-during-attach.patch
This is a note to let you know that I've just added the patch titled
ubi: block: Fix locking for idr_alloc/idr_remove
to the 4.15-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:
ubi-block-fix-locking-for-idr_alloc-idr_remove.patch
and it can be found in the queue-4.15 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 7f29ae9f977bcdc3654e68bc36d170223c52fd48 Mon Sep 17 00:00:00 2001
From: Bradley Bolen <bradleybolen(a)gmail.com>
Date: Thu, 18 Jan 2018 08:55:20 -0500
Subject: ubi: block: Fix locking for idr_alloc/idr_remove
From: Bradley Bolen <bradleybolen(a)gmail.com>
commit 7f29ae9f977bcdc3654e68bc36d170223c52fd48 upstream.
This fixes a race with idr_alloc where gd->first_minor can be set to the
same value for two simultaneous calls to ubiblock_create. Each instance
calls device_add_disk with the same first_minor. device_add_disk calls
bdi_register_owner which generates several warnings.
WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
sysfs_warn_dup+0x68/0x88
sysfs: cannot create duplicate filename '/devices/virtual/bdi/252:2'
WARNING: CPU: 1 PID: 179 at kernel-source/lib/kobject.c:240
kobject_add_internal+0x1ec/0x2f8
kobject_add_internal failed for 252:2 with -EEXIST, don't try to
register things with the same name in the same directory
WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
sysfs_warn_dup+0x68/0x88
sysfs: cannot create duplicate filename '/dev/block/252:2'
However, device_add_disk does not error out when bdi_register_owner
returns an error. Control continues until reaching blk_register_queue.
It then BUGs.
kernel BUG at kernel-source/fs/sysfs/group.c:113!
[<c01e26cc>] (internal_create_group) from [<c01e2950>]
(sysfs_create_group+0x20/0x24)
[<c01e2950>] (sysfs_create_group) from [<c00e3d38>]
(blk_trace_init_sysfs+0x18/0x20)
[<c00e3d38>] (blk_trace_init_sysfs) from [<c02bdfbc>]
(blk_register_queue+0xd8/0x154)
[<c02bdfbc>] (blk_register_queue) from [<c02cec84>]
(device_add_disk+0x194/0x44c)
[<c02cec84>] (device_add_disk) from [<c0436ec8>]
(ubiblock_create+0x284/0x2e0)
[<c0436ec8>] (ubiblock_create) from [<c0427bb8>]
(vol_cdev_ioctl+0x450/0x554)
[<c0427bb8>] (vol_cdev_ioctl) from [<c0189110>] (vfs_ioctl+0x30/0x44)
[<c0189110>] (vfs_ioctl) from [<c01892e0>] (do_vfs_ioctl+0xa0/0x790)
[<c01892e0>] (do_vfs_ioctl) from [<c0189a14>] (SyS_ioctl+0x44/0x68)
[<c0189a14>] (SyS_ioctl) from [<c0010640>] (ret_fast_syscall+0x0/0x34)
Locking idr_alloc/idr_remove removes the race and keeps gd->first_minor
unique.
Fixes: 2bf50d42f3a4 ("UBI: block: Dynamically allocate minor numbers")
Signed-off-by: Bradley Bolen <bradleybolen(a)gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/ubi/block.c | 42 ++++++++++++++++++++++++++----------------
1 file changed, 26 insertions(+), 16 deletions(-)
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
@@ -99,6 +99,8 @@ struct ubiblock {
/* Linked list of all ubiblock instances */
static LIST_HEAD(ubiblock_devices);
+static DEFINE_IDR(ubiblock_minor_idr);
+/* Protects ubiblock_devices and ubiblock_minor_idr */
static DEFINE_MUTEX(devices_mutex);
static int ubiblock_major;
@@ -351,8 +353,6 @@ static const struct blk_mq_ops ubiblock_
.init_request = ubiblock_init_request,
};
-static DEFINE_IDR(ubiblock_minor_idr);
-
int ubiblock_create(struct ubi_volume_info *vi)
{
struct ubiblock *dev;
@@ -365,14 +365,15 @@ int ubiblock_create(struct ubi_volume_in
/* Check that the volume isn't already handled */
mutex_lock(&devices_mutex);
if (find_dev_nolock(vi->ubi_num, vi->vol_id)) {
- mutex_unlock(&devices_mutex);
- return -EEXIST;
+ ret = -EEXIST;
+ goto out_unlock;
}
- mutex_unlock(&devices_mutex);
dev = kzalloc(sizeof(struct ubiblock), GFP_KERNEL);
- if (!dev)
- return -ENOMEM;
+ if (!dev) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
mutex_init(&dev->dev_mutex);
@@ -437,14 +438,13 @@ int ubiblock_create(struct ubi_volume_in
goto out_free_queue;
}
- mutex_lock(&devices_mutex);
list_add_tail(&dev->list, &ubiblock_devices);
- mutex_unlock(&devices_mutex);
/* Must be the last step: anyone can call file ops from now on */
add_disk(dev->gd);
dev_info(disk_to_dev(dev->gd), "created from ubi%d:%d(%s)",
dev->ubi_num, dev->vol_id, vi->name);
+ mutex_unlock(&devices_mutex);
return 0;
out_free_queue:
@@ -457,6 +457,8 @@ out_put_disk:
put_disk(dev->gd);
out_free_dev:
kfree(dev);
+out_unlock:
+ mutex_unlock(&devices_mutex);
return ret;
}
@@ -478,30 +480,36 @@ static void ubiblock_cleanup(struct ubib
int ubiblock_remove(struct ubi_volume_info *vi)
{
struct ubiblock *dev;
+ int ret;
mutex_lock(&devices_mutex);
dev = find_dev_nolock(vi->ubi_num, vi->vol_id);
if (!dev) {
- mutex_unlock(&devices_mutex);
- return -ENODEV;
+ ret = -ENODEV;
+ goto out_unlock;
}
/* Found a device, let's lock it so we can check if it's busy */
mutex_lock(&dev->dev_mutex);
if (dev->refcnt > 0) {
- mutex_unlock(&dev->dev_mutex);
- mutex_unlock(&devices_mutex);
- return -EBUSY;
+ ret = -EBUSY;
+ goto out_unlock_dev;
}
/* Remove from device list */
list_del(&dev->list);
- mutex_unlock(&devices_mutex);
-
ubiblock_cleanup(dev);
mutex_unlock(&dev->dev_mutex);
+ mutex_unlock(&devices_mutex);
+
kfree(dev);
return 0;
+
+out_unlock_dev:
+ mutex_unlock(&dev->dev_mutex);
+out_unlock:
+ mutex_unlock(&devices_mutex);
+ return ret;
}
static int ubiblock_resize(struct ubi_volume_info *vi)
@@ -630,6 +638,7 @@ static void ubiblock_remove_all(void)
struct ubiblock *next;
struct ubiblock *dev;
+ mutex_lock(&devices_mutex);
list_for_each_entry_safe(dev, next, &ubiblock_devices, list) {
/* The module is being forcefully removed */
WARN_ON(dev->desc);
@@ -638,6 +647,7 @@ static void ubiblock_remove_all(void)
ubiblock_cleanup(dev);
kfree(dev);
}
+ mutex_unlock(&devices_mutex);
}
int __init ubiblock_init(void)
Patches currently in stable-queue which might be from bradleybolen(a)gmail.com are
queue-4.15/ubi-block-fix-locking-for-idr_alloc-idr_remove.patch
This is a note to let you know that I've just added the patch titled
nfsd: Detect unhashed stids in nfsd4_verify_open_stid()
to the 4.15-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:
nfsd-detect-unhashed-stids-in-nfsd4_verify_open_stid.patch
and it can be found in the queue-4.15 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 4f1764172a0aa7395d12b96cae640ca1438c5085 Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Fri, 12 Jan 2018 17:42:30 -0500
Subject: nfsd: Detect unhashed stids in nfsd4_verify_open_stid()
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
commit 4f1764172a0aa7395d12b96cae640ca1438c5085 upstream.
The state of the stid is guaranteed by 2 locks:
- The nfs4_client 'cl_lock' spinlock
- The nfs4_ol_stateid 'st_mutex' mutex
so it is quite possible for the stid to be unhashed after lookup,
but before calling nfsd4_lock_ol_stateid(). So we do need to check
for a zero value for 'sc_type' in nfsd4_verify_open_stid().
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Tested-by: Checuk Lever <chuck.lever(a)oracle.com>
Fixes: 659aefb68eca "nfsd: Ensure we don't recognise lock stateids..."
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfsd/nfs4state.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -3590,6 +3590,7 @@ nfsd4_verify_open_stid(struct nfs4_stid
switch (s->sc_type) {
default:
break;
+ case 0:
case NFS4_CLOSED_STID:
case NFS4_CLOSED_DELEG_STID:
ret = nfserr_bad_stateid;
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.15/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
queue-4.15/nfsd-detect-unhashed-stids-in-nfsd4_verify_open_stid.patch
queue-4.15/nfs-fix-nfsstat-breakage-due-to-lookupp.patch
queue-4.15/nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
queue-4.15/nfs41-do-not-return-enomem-on-layoutunavailable.patch
queue-4.15/nfs-commit-direct-writes-even-if-they-fail-partially.patch
queue-4.15/nfs-fix-a-race-between-mmap-and-o_direct.patch
This is a note to let you know that I've just added the patch titled
nfs41: do not return ENOMEM on LAYOUTUNAVAILABLE
to the 4.15-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:
nfs41-do-not-return-enomem-on-layoutunavailable.patch
and it can be found in the queue-4.15 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 7ff4cff637aa0bd2abbd81f53b2a6206c50afd95 Mon Sep 17 00:00:00 2001
From: Tigran Mkrtchyan <tigran.mkrtchyan(a)desy.de>
Date: Tue, 16 Jan 2018 22:38:50 +0100
Subject: nfs41: do not return ENOMEM on LAYOUTUNAVAILABLE
From: Tigran Mkrtchyan <tigran.mkrtchyan(a)desy.de>
commit 7ff4cff637aa0bd2abbd81f53b2a6206c50afd95 upstream.
A pNFS server may return LAYOUTUNAVAILABLE error on LAYOUTGET for files
which don't have any layout. In this situation pnfs_update_layout
currently returns NULL. As this NULL is converted into ENOMEM, IO
requests fails instead of falling back to MDS.
Do not return ENOMEM on LAYOUTUNAVAILABLE and let client retry through
MDS.
Fixes 8d40b0f14846f. I will suggest to backport this fix to affected
stable branches.
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan(a)desy.de>
[trondmy: Use IS_ERR_OR_NULL()]
Fixes: 8d40b0f14846 ("NFS filelayout:call GETDEVICEINFO after...")
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/filelayout/filelayout.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/fs/nfs/filelayout/filelayout.c
+++ b/fs/nfs/filelayout/filelayout.c
@@ -895,9 +895,7 @@ fl_pnfs_update_layout(struct inode *ino,
lseg = pnfs_update_layout(ino, ctx, pos, count, iomode, strict_iomode,
gfp_flags);
- if (!lseg)
- lseg = ERR_PTR(-ENOMEM);
- if (IS_ERR(lseg))
+ if (IS_ERR_OR_NULL(lseg))
goto out;
lo = NFS_I(ino)->layout;
Patches currently in stable-queue which might be from tigran.mkrtchyan(a)desy.de are
queue-4.15/nfs41-do-not-return-enomem-on-layoutunavailable.patch
This is a note to let you know that I've just added the patch titled
NFS: reject request for id_legacy key without auxdata
to the 4.15-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:
nfs-reject-request-for-id_legacy-key-without-auxdata.patch
and it can be found in the queue-4.15 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 49686cbbb3ebafe42e63868222f269d8053ead00 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Fri, 19 Jan 2018 15:15:34 -0800
Subject: NFS: reject request for id_legacy key without auxdata
From: Eric Biggers <ebiggers(a)google.com>
commit 49686cbbb3ebafe42e63868222f269d8053ead00 upstream.
nfs_idmap_legacy_upcall() is supposed to be called with 'aux' pointing
to a 'struct idmap', via the call to request_key_with_auxdata() in
nfs_idmap_request_key().
However it can also be reached via the request_key() system call in
which case 'aux' will be NULL, causing a NULL pointer dereference in
nfs_idmap_prepare_pipe_upcall(), assuming that the key description is
valid enough to get that far.
Fix this by making nfs_idmap_legacy_upcall() negate the key if no
auxdata is provided.
As usual, this bug was found by syzkaller. A simple reproducer using
the command-line keyctl program is:
keyctl request2 id_legacy uid:0 '' @s
Fixes: 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring")
Reported-by: syzbot+5dfdbcf7b3eb5912abbb(a)syzkaller.appspotmail.com
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Trond Myklebust <trondmy(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/nfs4idmap.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/nfs/nfs4idmap.c
+++ b/fs/nfs/nfs4idmap.c
@@ -568,9 +568,13 @@ static int nfs_idmap_legacy_upcall(struc
struct idmap_msg *im;
struct idmap *idmap = (struct idmap *)aux;
struct key *key = cons->key;
- int ret = -ENOMEM;
+ int ret = -ENOKEY;
+
+ if (!aux)
+ goto out1;
/* msg and im are freed in idmap_pipe_destroy_msg */
+ ret = -ENOMEM;
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
goto out1;
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.15/ubifs-free-the-encrypted-symlink-target.patch
queue-4.15/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
This is a note to let you know that I've just added the patch titled
nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds
to the 4.15-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:
nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
and it can be found in the queue-4.15 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 ba4a76f703ab7eb72941fdaac848502073d6e9ee Mon Sep 17 00:00:00 2001
From: Scott Mayhew <smayhew(a)redhat.com>
Date: Fri, 15 Dec 2017 16:12:32 -0500
Subject: nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds
From: Scott Mayhew <smayhew(a)redhat.com>
commit ba4a76f703ab7eb72941fdaac848502073d6e9ee upstream.
Currently when falling back to doing I/O through the MDS (via
pnfs_{read|write}_through_mds), the client frees the nfs_pgio_header
without releasing the reference taken on the dreq
via pnfs_generic_pg_{read|write}pages -> nfs_pgheader_init ->
nfs_direct_pgio_init. It then takes another reference on the dreq via
nfs_generic_pg_pgios -> nfs_pgheader_init -> nfs_direct_pgio_init and
as a result the requester will become stuck in inode_dio_wait. Once
that happens, other processes accessing the inode will become stuck as
well.
Ensure that pnfs_read_through_mds() and pnfs_write_through_mds() clean
up correctly by calling hdr->completion_ops->completion() instead of
calling hdr->release() directly.
This can be reproduced (sometimes) by performing "storage failover
takeover" commands on NetApp filer while doing direct I/O from a client.
This can also be reproduced using SystemTap to simulate a failure while
doing direct I/O from a client (from Dave Wysochanski
<dwysocha(a)redhat.com>):
stap -v -g -e 'probe module("nfs_layout_nfsv41_files").function("nfs4_fl_prepare_ds").return { $return=NULL; exit(); }'
Suggested-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Scott Mayhew <smayhew(a)redhat.com>
Fixes: 1ca018d28d ("pNFS: Fix a memory leak when attempted pnfs fails")
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/pnfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -2255,7 +2255,7 @@ pnfs_write_through_mds(struct nfs_pageio
nfs_pageio_reset_write_mds(desc);
mirror->pg_recoalesce = 1;
}
- hdr->release(hdr);
+ hdr->completion_ops->completion(hdr);
}
static enum pnfs_try_status
@@ -2378,7 +2378,7 @@ pnfs_read_through_mds(struct nfs_pageio_
nfs_pageio_reset_read_mds(desc);
mirror->pg_recoalesce = 1;
}
- hdr->release(hdr);
+ hdr->completion_ops->completion(hdr);
}
/*
Patches currently in stable-queue which might be from smayhew(a)redhat.com are
queue-4.15/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
This is a note to let you know that I've just added the patch titled
NFS: Fix a race between mmap() and O_DIRECT
to the 4.15-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:
nfs-fix-a-race-between-mmap-and-o_direct.patch
and it can be found in the queue-4.15 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 e231c6879cfd44e4fffd384bb6dd7d313249a523 Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Sun, 28 Jan 2018 09:29:41 -0500
Subject: NFS: Fix a race between mmap() and O_DIRECT
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
commit e231c6879cfd44e4fffd384bb6dd7d313249a523 upstream.
When locking the file in order to do O_DIRECT on it, we must unmap
any mmapped ranges on the pagecache so that we can flush out the
dirty data.
Fixes: a5864c999de67 ("NFS: Do not serialise O_DIRECT reads and writes")
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/io.c
+++ b/fs/nfs/io.c
@@ -99,7 +99,7 @@ static void nfs_block_buffered(struct nf
{
if (!test_bit(NFS_INO_ODIRECT, &nfsi->flags)) {
set_bit(NFS_INO_ODIRECT, &nfsi->flags);
- nfs_wb_all(inode);
+ nfs_sync_mapping(inode->i_mapping);
}
}
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.15/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
queue-4.15/nfsd-detect-unhashed-stids-in-nfsd4_verify_open_stid.patch
queue-4.15/nfs-fix-nfsstat-breakage-due-to-lookupp.patch
queue-4.15/nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
queue-4.15/nfs41-do-not-return-enomem-on-layoutunavailable.patch
queue-4.15/nfs-commit-direct-writes-even-if-they-fail-partially.patch
queue-4.15/nfs-fix-a-race-between-mmap-and-o_direct.patch
This is a note to let you know that I've just added the patch titled
NFS: commit direct writes even if they fail partially
to the 4.15-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:
nfs-commit-direct-writes-even-if-they-fail-partially.patch
and it can be found in the queue-4.15 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 1b8d97b0a837beaf48a8449955b52c650a7114b4 Mon Sep 17 00:00:00 2001
From: "J. Bruce Fields" <bfields(a)redhat.com>
Date: Tue, 16 Jan 2018 10:08:00 -0500
Subject: NFS: commit direct writes even if they fail partially
From: J. Bruce Fields <bfields(a)redhat.com>
commit 1b8d97b0a837beaf48a8449955b52c650a7114b4 upstream.
If some of the WRITE calls making up an O_DIRECT write syscall fail,
we neglect to commit, even if some of the WRITEs succeed.
We also depend on the commit code to free the reference count on the
nfs_page taken in the "if (request_commit)" case at the end of
nfs_direct_write_completion(). The problem was originally noticed
because ENOSPC's encountered partway through a write would result in a
closed file being sillyrenamed when it should have been unlinked.
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/direct.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -775,10 +775,8 @@ static void nfs_direct_write_completion(
spin_lock(&dreq->lock);
- if (test_bit(NFS_IOHDR_ERROR, &hdr->flags)) {
- dreq->flags = 0;
+ if (test_bit(NFS_IOHDR_ERROR, &hdr->flags))
dreq->error = hdr->error;
- }
if (dreq->error == 0) {
nfs_direct_good_bytes(dreq, hdr);
if (nfs_write_need_commit(hdr)) {
Patches currently in stable-queue which might be from bfields(a)redhat.com are
queue-4.15/nfsd-detect-unhashed-stids-in-nfsd4_verify_open_stid.patch
queue-4.15/nfs-commit-direct-writes-even-if-they-fail-partially.patch
This is a note to let you know that I've just added the patch titled
NFS: Add a cond_resched() to nfs_commit_release_pages()
to the 4.15-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:
nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
and it can be found in the queue-4.15 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 7f1bda447c9bd48b415acedba6b830f61591601f Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Mon, 18 Dec 2017 14:39:13 -0500
Subject: NFS: Add a cond_resched() to nfs_commit_release_pages()
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
commit 7f1bda447c9bd48b415acedba6b830f61591601f upstream.
The commit list can get very large, and so we need a cond_resched()
in nfs_commit_release_pages() in order to ensure we don't hog the CPU
for excessive periods of time.
Reported-by: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/write.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1837,6 +1837,8 @@ static void nfs_commit_release_pages(str
set_bit(NFS_CONTEXT_RESEND_WRITES, &req->wb_context->flags);
next:
nfs_unlock_and_release_request(req);
+ /* Latency breaker */
+ cond_resched();
}
nfss = NFS_SERVER(data->inode);
if (atomic_long_read(&nfss->writeback) < NFS_CONGESTION_OFF_THRESH)
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.15/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
queue-4.15/nfsd-detect-unhashed-stids-in-nfsd4_verify_open_stid.patch
queue-4.15/nfs-fix-nfsstat-breakage-due-to-lookupp.patch
queue-4.15/nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
queue-4.15/nfs41-do-not-return-enomem-on-layoutunavailable.patch
queue-4.15/nfs-commit-direct-writes-even-if-they-fail-partially.patch
queue-4.15/nfs-fix-a-race-between-mmap-and-o_direct.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: sunxi: Fix ECC strength choice
to the 4.15-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:
mtd-nand-sunxi-fix-ecc-strength-choice.patch
and it can be found in the queue-4.15 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 f4c6cd1a7f2275d5bc0e494b21fff26f8dde80f0 Mon Sep 17 00:00:00 2001
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Date: Wed, 24 Jan 2018 23:49:31 +0100
Subject: mtd: nand: sunxi: Fix ECC strength choice
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
commit f4c6cd1a7f2275d5bc0e494b21fff26f8dde80f0 upstream.
When the requested ECC strength does not exactly match the strengths
supported by the ECC engine, the driver is selecting the closest
strength meeting the 'selected_strength > requested_strength'
constraint. Fix the fact that, in this particular case, ecc->strength
value was not updated to match the 'selected_strength'.
For instance, one can encounter this issue when no ECC requirement is
filled in the device tree while the NAND chip minimum requirement is not
a strength/step_size combo natively supported by the ECC engine.
Fixes: 1fef62c1423b ("mtd: nand: add sunxi NAND flash controller support")
Suggested-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/sunxi_nand.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -1853,8 +1853,14 @@ static int sunxi_nand_hw_common_ecc_ctrl
/* Add ECC info retrieval from DT */
for (i = 0; i < ARRAY_SIZE(strengths); i++) {
- if (ecc->strength <= strengths[i])
+ if (ecc->strength <= strengths[i]) {
+ /*
+ * Update ecc->strength value with the actual strength
+ * that will be used by the ECC engine.
+ */
+ ecc->strength = strengths[i];
break;
+ }
}
if (i >= ARRAY_SIZE(strengths)) {
Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are
queue-4.15/mtd-nand-sunxi-fix-ecc-strength-choice.patch
queue-4.15/mtd-nand-fix-nand_do_read_oob-return-value.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: Fix nand_do_read_oob() return value
to the 4.15-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:
mtd-nand-fix-nand_do_read_oob-return-value.patch
and it can be found in the queue-4.15 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 87e89ce8d0d14f573c068c61bec2117751fb5103 Mon Sep 17 00:00:00 2001
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Date: Fri, 12 Jan 2018 10:13:36 +0100
Subject: mtd: nand: Fix nand_do_read_oob() return value
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
commit 87e89ce8d0d14f573c068c61bec2117751fb5103 upstream.
Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in
OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a
negative error, and the MTD layer expected it.
However, the trend for the NAND layer is now to return an error or a
positive number of bitflips. Deciding which status to return to the user
belongs to the MTD layer.
Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
brought this logic to the mtd_read_oob() function while the return value
coming from nand_do_read_oob() (called by the ->_read_oob() hook) was
left unchanged.
Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/nand_base.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2199,6 +2199,7 @@ EXPORT_SYMBOL(nand_write_oob_syndrome);
static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
struct mtd_oob_ops *ops)
{
+ unsigned int max_bitflips = 0;
int page, realpage, chipnr;
struct nand_chip *chip = mtd_to_nand(mtd);
struct mtd_ecc_stats stats;
@@ -2256,6 +2257,8 @@ static int nand_do_read_oob(struct mtd_i
nand_wait_ready(mtd);
}
+ max_bitflips = max_t(unsigned int, max_bitflips, ret);
+
readlen -= len;
if (!readlen)
break;
@@ -2281,7 +2284,7 @@ static int nand_do_read_oob(struct mtd_i
if (mtd->ecc_stats.failed - stats.failed)
return -EBADMSG;
- return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
+ return max_bitflips;
}
/**
Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are
queue-4.15/mtd-nand-sunxi-fix-ecc-strength-choice.patch
queue-4.15/mtd-nand-fix-nand_do_read_oob-return-value.patch
This is a note to let you know that I've just added the patch titled
mtd: cfi: convert inline functions to macros
to the 4.15-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:
mtd-cfi-convert-inline-functions-to-macros.patch
and it can be found in the queue-4.15 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 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 11 Oct 2017 15:54:10 +0200
Subject: mtd: cfi: convert inline functions to macros
From: Arnd Bergmann <arnd(a)arndb.de>
commit 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 upstream.
The map_word_() functions, dating back to linux-2.6.8, try to perform
bitwise operations on a 'map_word' structure. This may have worked
with compilers that were current then (gcc-3.4 or earlier), but end
up being rather inefficient on any version I could try now (gcc-4.4 or
higher). Specifically we hit a problem analyzed in gcc PR81715 where we
fail to reuse the stack space for local variables.
This can be seen immediately in the stack consumption for
cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN)
can be up to 2200 bytes. Changing the inline functions into macros brings
this down to 1280 bytes. Without KASAN, the same problem exists, but
the stack consumption is lower to start with, my patch shrinks it from
920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around
1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word
structures for each call to one of these helpers.
With the latest gcc-8 snapshot, the problem is fixed in upstream gcc,
but nobody uses that yet, so we should still work around it in mainline
kernels and probably backport the workaround to stable kernels as well.
We had a couple of other functions that suffered from the same gcc bug,
and all of those had a simpler workaround involving dummy variables
in the inline function. Unfortunately that did not work here, the
macro hack was the best I could come up with.
It would also be helpful to have someone to a little performance testing
on the patch, to see how much it helps in terms of CPU utilitzation.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Acked-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/mtd/map.h | 130 ++++++++++++++++++++++--------------------------
1 file changed, 61 insertions(+), 69 deletions(-)
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -270,75 +270,67 @@ void map_destroy(struct mtd_info *mtd);
#define INVALIDATE_CACHED_RANGE(map, from, size) \
do { if (map->inval_cache) map->inval_cache(map, from, size); } while (0)
-
-static inline int map_word_equal(struct map_info *map, map_word val1, map_word val2)
-{
- int i;
-
- for (i = 0; i < map_words(map); i++) {
- if (val1.x[i] != val2.x[i])
- return 0;
- }
-
- return 1;
-}
-
-static inline map_word map_word_and(struct map_info *map, map_word val1, map_word val2)
-{
- map_word r;
- int i;
-
- for (i = 0; i < map_words(map); i++)
- r.x[i] = val1.x[i] & val2.x[i];
-
- return r;
-}
-
-static inline map_word map_word_clr(struct map_info *map, map_word val1, map_word val2)
-{
- map_word r;
- int i;
-
- for (i = 0; i < map_words(map); i++)
- r.x[i] = val1.x[i] & ~val2.x[i];
-
- return r;
-}
-
-static inline map_word map_word_or(struct map_info *map, map_word val1, map_word val2)
-{
- map_word r;
- int i;
-
- for (i = 0; i < map_words(map); i++)
- r.x[i] = val1.x[i] | val2.x[i];
-
- return r;
-}
-
-static inline int map_word_andequal(struct map_info *map, map_word val1, map_word val2, map_word val3)
-{
- int i;
-
- for (i = 0; i < map_words(map); i++) {
- if ((val1.x[i] & val2.x[i]) != val3.x[i])
- return 0;
- }
-
- return 1;
-}
-
-static inline int map_word_bitsset(struct map_info *map, map_word val1, map_word val2)
-{
- int i;
-
- for (i = 0; i < map_words(map); i++) {
- if (val1.x[i] & val2.x[i])
- return 1;
- }
-
- return 0;
-}
+#define map_word_equal(map, val1, val2) \
+({ \
+ int i, ret = 1; \
+ for (i = 0; i < map_words(map); i++) \
+ if ((val1).x[i] != (val2).x[i]) { \
+ ret = 0; \
+ break; \
+ } \
+ ret; \
+})
+
+#define map_word_and(map, val1, val2) \
+({ \
+ map_word r; \
+ int i; \
+ for (i = 0; i < map_words(map); i++) \
+ r.x[i] = (val1).x[i] & (val2).x[i]; \
+ r; \
+})
+
+#define map_word_clr(map, val1, val2) \
+({ \
+ map_word r; \
+ int i; \
+ for (i = 0; i < map_words(map); i++) \
+ r.x[i] = (val1).x[i] & ~(val2).x[i]; \
+ r; \
+})
+
+#define map_word_or(map, val1, val2) \
+({ \
+ map_word r; \
+ int i; \
+ for (i = 0; i < map_words(map); i++) \
+ r.x[i] = (val1).x[i] | (val2).x[i]; \
+ r; \
+})
+
+#define map_word_andequal(map, val1, val2, val3) \
+({ \
+ int i, ret = 1; \
+ for (i = 0; i < map_words(map); i++) { \
+ if (((val1).x[i] & (val2).x[i]) != (val2).x[i]) { \
+ ret = 0; \
+ break; \
+ } \
+ } \
+ ret; \
+})
+
+#define map_word_bitsset(map, val1, val2) \
+({ \
+ int i, ret = 0; \
+ for (i = 0; i < map_words(map); i++) { \
+ if ((val1).x[i] & (val2).x[i]) { \
+ ret = 1; \
+ break; \
+ } \
+ } \
+ ret; \
+})
static inline map_word map_word_load(struct map_info *map, const void *ptr)
{
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.15/mtd-cfi-convert-inline-functions-to-macros.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: brcmnand: Disable prefetch by default
to the 4.15-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:
mtd-nand-brcmnand-disable-prefetch-by-default.patch
and it can be found in the queue-4.15 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 f953f0f89663c39f08f4baaa8a4a881401b65654 Mon Sep 17 00:00:00 2001
From: Kamal Dasu <kdasu.kdev(a)gmail.com>
Date: Mon, 8 Jan 2018 15:36:48 -0500
Subject: mtd: nand: brcmnand: Disable prefetch by default
From: Kamal Dasu <kdasu.kdev(a)gmail.com>
commit f953f0f89663c39f08f4baaa8a4a881401b65654 upstream.
Brcm nand controller prefetch feature needs to be disabled
by default. Enabling affects performance on random reads as
well as dma reads.
Signed-off-by: Kamal Dasu <kdasu.kdev(a)gmail.com>
Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
Acked-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/brcmnand/brcmnand.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -2193,16 +2193,9 @@ static int brcmnand_setup_dev(struct brc
if (ctrl->nand_version >= 0x0702)
tmp |= ACC_CONTROL_RD_ERASED;
tmp &= ~ACC_CONTROL_FAST_PGM_RDIN;
- if (ctrl->features & BRCMNAND_HAS_PREFETCH) {
- /*
- * FIXME: Flash DMA + prefetch may see spurious erased-page ECC
- * errors
- */
- if (has_flash_dma(ctrl))
- tmp &= ~ACC_CONTROL_PREFETCH;
- else
- tmp |= ACC_CONTROL_PREFETCH;
- }
+ if (ctrl->features & BRCMNAND_HAS_PREFETCH)
+ tmp &= ~ACC_CONTROL_PREFETCH;
+
nand_writereg(ctrl, offs, tmp);
return 0;
Patches currently in stable-queue which might be from kdasu.kdev(a)gmail.com are
queue-4.15/mtd-nand-brcmnand-disable-prefetch-by-default.patch
This is a note to let you know that I've just added the patch titled
kernfs: fix regression in kernfs_fop_write caused by wrong type
to the 4.15-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:
kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.patch
and it can be found in the queue-4.15 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 ba87977a49913129962af8ac35b0e13e0fa4382d Mon Sep 17 00:00:00 2001
From: Ivan Vecera <ivecera(a)redhat.com>
Date: Fri, 19 Jan 2018 09:18:54 +0100
Subject: kernfs: fix regression in kernfs_fop_write caused by wrong type
From: Ivan Vecera <ivecera(a)redhat.com>
commit ba87977a49913129962af8ac35b0e13e0fa4382d upstream.
Commit b7ce40cff0b9 ("kernfs: cache atomic_write_len in
kernfs_open_file") changes type of local variable 'len' from ssize_t
to size_t. This change caused that the *ppos value is updated also
when the previous write callback failed.
Mentioned snippet:
...
len = ops->write(...); <- return value can be negative
...
if (len > 0) <- true here in this case
*ppos += len;
...
Fixes: b7ce40cff0b9 ("kernfs: cache atomic_write_len in kernfs_open_file")
Acked-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Ivan Vecera <ivecera(a)redhat.com>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/kernfs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -275,7 +275,7 @@ static ssize_t kernfs_fop_write(struct f
{
struct kernfs_open_file *of = kernfs_of(file);
const struct kernfs_ops *ops;
- size_t len;
+ ssize_t len;
char *buf;
if (of->atomic_write_len) {
Patches currently in stable-queue which might be from ivecera(a)redhat.com are
queue-4.15/kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.patch
This is a note to let you know that I've just added the patch titled
ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
to the 4.15-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:
ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
and it can be found in the queue-4.15 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 998008b779e424bd7513c434d0ab9c1268459009 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 6 Dec 2017 16:41:09 +0100
Subject: ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
From: Hans de Goede <hdegoede(a)redhat.com>
commit 998008b779e424bd7513c434d0ab9c1268459009 upstream.
Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
SATA controllers. This commit is a preparation patch for allowing a
different default sata link powermanagement policy for mobile chipsets.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/ahci.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -386,6 +386,10 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(INTEL, 0xa206), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa252), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa256), board_ahci }, /* Lewisburg RAID*/
+ { PCI_VDEVICE(INTEL, 0x0f22), board_ahci }, /* Bay Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x0f23), board_ahci }, /* Bay Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x22a3), board_ahci }, /* Cherry Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x5ae3), board_ahci }, /* Apollo Lake AHCI */
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.15/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.15/ahci-allow-setting-a-default-lpm-policy-for-mobile-chipsets.patch
queue-4.15/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
This is a note to let you know that I've just added the patch titled
ahci: Add Intel Cannon Lake PCH-H PCI ID
to the 4.15-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:
ahci-add-intel-cannon-lake-pch-h-pci-id.patch
and it can be found in the queue-4.15 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 f919dde0772a894c693a1eeabc77df69d6a9b937 Mon Sep 17 00:00:00 2001
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Date: Thu, 11 Jan 2018 15:55:50 +0300
Subject: ahci: Add Intel Cannon Lake PCH-H PCI ID
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
commit f919dde0772a894c693a1eeabc77df69d6a9b937 upstream.
Add Intel Cannon Lake PCH-H PCI ID to the list of supported controllers.
Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/ahci.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -394,6 +394,7 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(INTEL, 0xa206), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa252), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa256), board_ahci }, /* Lewisburg RAID*/
+ { PCI_VDEVICE(INTEL, 0xa356), board_ahci }, /* Cannon Lake PCH-H RAID */
{ PCI_VDEVICE(INTEL, 0x0f22), board_ahci_mobile }, /* Bay Trail AHCI */
{ PCI_VDEVICE(INTEL, 0x0f23), board_ahci_mobile }, /* Bay Trail AHCI */
{ PCI_VDEVICE(INTEL, 0x22a3), board_ahci_mobile }, /* Cherry Tr. AHCI */
Patches currently in stable-queue which might be from mika.westerberg(a)linux.intel.com are
queue-4.15/ahci-add-intel-cannon-lake-pch-h-pci-id.patch
This is a note to let you know that I've just added the patch titled
ubifs: free the encrypted symlink target
to the 4.14-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:
ubifs-free-the-encrypted-symlink-target.patch
and it can be found in the queue-4.14 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 6b46d444146eb8d0b99562795cea8086639d7282 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Thu, 11 Jan 2018 23:27:00 -0500
Subject: ubifs: free the encrypted symlink target
From: Eric Biggers <ebiggers(a)google.com>
commit 6b46d444146eb8d0b99562795cea8086639d7282 upstream.
ubifs_symlink() forgot to free the kmalloc()'ed buffer holding the
encrypted symlink target, creating a memory leak. Fix it.
(UBIFS could actually encrypt directly into ui->data, removing the
temporary buffer, but that is left for the patch that switches to use
the symlink helper functions.)
Fixes: ca7f85be8d6c ("ubifs: Add support for encrypted symlinks")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Theodore Ts'o <tytso(a)mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/ubifs/dir.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
--- a/fs/ubifs/dir.c
+++ b/fs/ubifs/dir.c
@@ -1216,10 +1216,8 @@ static int ubifs_symlink(struct inode *d
ostr.len = disk_link.len;
err = fscrypt_fname_usr_to_disk(inode, &istr, &ostr);
- if (err) {
- kfree(sd);
+ if (err)
goto out_inode;
- }
sd->len = cpu_to_le16(ostr.len);
disk_link.name = (char *)sd;
@@ -1251,11 +1249,10 @@ static int ubifs_symlink(struct inode *d
goto out_cancel;
mutex_unlock(&dir_ui->ui_mutex);
- ubifs_release_budget(c, &req);
insert_inode_hash(inode);
d_instantiate(dentry, inode);
- fscrypt_free_filename(&nm);
- return 0;
+ err = 0;
+ goto out_fname;
out_cancel:
dir->i_size -= sz_change;
@@ -1268,6 +1265,7 @@ out_fname:
fscrypt_free_filename(&nm);
out_budg:
ubifs_release_budget(c, &req);
+ kfree(sd);
return err;
}
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/ubifs-free-the-encrypted-symlink-target.patch
queue-4.14/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
This is a note to let you know that I've just added the patch titled
ubi: Fix race condition between ubi volume creation and udev
to the 4.14-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:
ubi-fix-race-condition-between-ubi-volume-creation-and-udev.patch
and it can be found in the queue-4.14 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 a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 Mon Sep 17 00:00:00 2001
From: Clay McClure <clay(a)daemons.net>
Date: Thu, 21 Sep 2017 19:01:34 -0700
Subject: ubi: Fix race condition between ubi volume creation and udev
From: Clay McClure <clay(a)daemons.net>
commit a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 upstream.
Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi
device creation and udev"), we should make the volume active before
registering it.
Signed-off-by: Clay McClure <clay(a)daemons.net>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/ubi/vmt.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
--- a/drivers/mtd/ubi/vmt.c
+++ b/drivers/mtd/ubi/vmt.c
@@ -270,6 +270,12 @@ int ubi_create_volume(struct ubi_device
vol->last_eb_bytes = vol->usable_leb_size;
}
+ /* Make volume "available" before it becomes accessible via sysfs */
+ spin_lock(&ubi->volumes_lock);
+ ubi->volumes[vol_id] = vol;
+ ubi->vol_count += 1;
+ spin_unlock(&ubi->volumes_lock);
+
/* Register character device for the volume */
cdev_init(&vol->cdev, &ubi_vol_cdev_operations);
vol->cdev.owner = THIS_MODULE;
@@ -298,11 +304,6 @@ int ubi_create_volume(struct ubi_device
if (err)
goto out_sysfs;
- spin_lock(&ubi->volumes_lock);
- ubi->volumes[vol_id] = vol;
- ubi->vol_count += 1;
- spin_unlock(&ubi->volumes_lock);
-
ubi_volume_notify(ubi, vol, UBI_VOLUME_ADDED);
self_check_volumes(ubi);
return err;
@@ -315,6 +316,10 @@ out_sysfs:
*/
cdev_device_del(&vol->cdev, &vol->dev);
out_mapping:
+ spin_lock(&ubi->volumes_lock);
+ ubi->volumes[vol_id] = NULL;
+ ubi->vol_count -= 1;
+ spin_unlock(&ubi->volumes_lock);
ubi_eba_destroy_table(eba_tbl);
out_acc:
spin_lock(&ubi->volumes_lock);
Patches currently in stable-queue which might be from clay(a)daemons.net are
queue-4.14/ubi-fix-race-condition-between-ubi-volume-creation-and-udev.patch
This is a note to let you know that I've just added the patch titled
ubi: fastmap: Erase outdated anchor PEBs during attach
to the 4.14-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:
ubi-fastmap-erase-outdated-anchor-pebs-during-attach.patch
and it can be found in the queue-4.14 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 f78e5623f45bab2b726eec29dc5cefbbab2d0b1c Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer(a)pengutronix.de>
Date: Tue, 5 Dec 2017 16:01:20 +0100
Subject: ubi: fastmap: Erase outdated anchor PEBs during attach
From: Sascha Hauer <s.hauer(a)pengutronix.de>
commit f78e5623f45bab2b726eec29dc5cefbbab2d0b1c upstream.
The fastmap update code might erase the current fastmap anchor PEB
in case it doesn't find any new free PEB. When a power cut happens
in this situation we must not have any outdated fastmap anchor PEB
on the device, because that would be used to attach during next
boot.
The easiest way to make that sure is to erase all outdated fastmap
anchor PEBs synchronously during attach.
Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de>
Reviewed-by: Richard Weinberger <richard(a)nod.at>
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/ubi/wl.c | 77 +++++++++++++++++++++++++++++++++++++--------------
1 file changed, 57 insertions(+), 20 deletions(-)
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1529,6 +1529,46 @@ static void shutdown_work(struct ubi_dev
}
/**
+ * erase_aeb - erase a PEB given in UBI attach info PEB
+ * @ubi: UBI device description object
+ * @aeb: UBI attach info PEB
+ * @sync: If true, erase synchronously. Otherwise schedule for erasure
+ */
+static int erase_aeb(struct ubi_device *ubi, struct ubi_ainf_peb *aeb, bool sync)
+{
+ struct ubi_wl_entry *e;
+ int err;
+
+ e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
+ if (!e)
+ return -ENOMEM;
+
+ e->pnum = aeb->pnum;
+ e->ec = aeb->ec;
+ ubi->lookuptbl[e->pnum] = e;
+
+ if (sync) {
+ err = sync_erase(ubi, e, false);
+ if (err)
+ goto out_free;
+
+ wl_tree_add(e, &ubi->free);
+ ubi->free_count++;
+ } else {
+ err = schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false);
+ if (err)
+ goto out_free;
+ }
+
+ return 0;
+
+out_free:
+ wl_entry_destroy(ubi, e);
+
+ return err;
+}
+
+/**
* ubi_wl_init - initialize the WL sub-system using attaching information.
* @ubi: UBI device description object
* @ai: attaching information
@@ -1566,17 +1606,9 @@ int ubi_wl_init(struct ubi_device *ubi,
list_for_each_entry_safe(aeb, tmp, &ai->erase, u.list) {
cond_resched();
- e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
- if (!e)
- goto out_free;
-
- e->pnum = aeb->pnum;
- e->ec = aeb->ec;
- ubi->lookuptbl[e->pnum] = e;
- if (schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false)) {
- wl_entry_destroy(ubi, e);
+ err = erase_aeb(ubi, aeb, false);
+ if (err)
goto out_free;
- }
found_pebs++;
}
@@ -1635,6 +1667,8 @@ int ubi_wl_init(struct ubi_device *ubi,
ubi_assert(!ubi->lookuptbl[e->pnum]);
ubi->lookuptbl[e->pnum] = e;
} else {
+ bool sync = false;
+
/*
* Usually old Fastmap PEBs are scheduled for erasure
* and we don't have to care about them but if we face
@@ -1644,18 +1678,21 @@ int ubi_wl_init(struct ubi_device *ubi,
if (ubi->lookuptbl[aeb->pnum])
continue;
- e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
- if (!e)
- goto out_free;
+ /*
+ * The fastmap update code might not find a free PEB for
+ * writing the fastmap anchor to and then reuses the
+ * current fastmap anchor PEB. When this PEB gets erased
+ * and a power cut happens before it is written again we
+ * must make sure that the fastmap attach code doesn't
+ * find any outdated fastmap anchors, hence we erase the
+ * outdated fastmap anchor PEBs synchronously here.
+ */
+ if (aeb->vol_id == UBI_FM_SB_VOLUME_ID)
+ sync = true;
- e->pnum = aeb->pnum;
- e->ec = aeb->ec;
- ubi_assert(!ubi->lookuptbl[e->pnum]);
- ubi->lookuptbl[e->pnum] = e;
- if (schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false)) {
- wl_entry_destroy(ubi, e);
+ err = erase_aeb(ubi, aeb, sync);
+ if (err)
goto out_free;
- }
}
found_pebs++;
Patches currently in stable-queue which might be from s.hauer(a)pengutronix.de are
queue-4.14/ubi-fastmap-erase-outdated-anchor-pebs-during-attach.patch
This is a note to let you know that I've just added the patch titled
ubi: block: Fix locking for idr_alloc/idr_remove
to the 4.14-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:
ubi-block-fix-locking-for-idr_alloc-idr_remove.patch
and it can be found in the queue-4.14 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 7f29ae9f977bcdc3654e68bc36d170223c52fd48 Mon Sep 17 00:00:00 2001
From: Bradley Bolen <bradleybolen(a)gmail.com>
Date: Thu, 18 Jan 2018 08:55:20 -0500
Subject: ubi: block: Fix locking for idr_alloc/idr_remove
From: Bradley Bolen <bradleybolen(a)gmail.com>
commit 7f29ae9f977bcdc3654e68bc36d170223c52fd48 upstream.
This fixes a race with idr_alloc where gd->first_minor can be set to the
same value for two simultaneous calls to ubiblock_create. Each instance
calls device_add_disk with the same first_minor. device_add_disk calls
bdi_register_owner which generates several warnings.
WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
sysfs_warn_dup+0x68/0x88
sysfs: cannot create duplicate filename '/devices/virtual/bdi/252:2'
WARNING: CPU: 1 PID: 179 at kernel-source/lib/kobject.c:240
kobject_add_internal+0x1ec/0x2f8
kobject_add_internal failed for 252:2 with -EEXIST, don't try to
register things with the same name in the same directory
WARNING: CPU: 1 PID: 179 at kernel-source/fs/sysfs/dir.c:31
sysfs_warn_dup+0x68/0x88
sysfs: cannot create duplicate filename '/dev/block/252:2'
However, device_add_disk does not error out when bdi_register_owner
returns an error. Control continues until reaching blk_register_queue.
It then BUGs.
kernel BUG at kernel-source/fs/sysfs/group.c:113!
[<c01e26cc>] (internal_create_group) from [<c01e2950>]
(sysfs_create_group+0x20/0x24)
[<c01e2950>] (sysfs_create_group) from [<c00e3d38>]
(blk_trace_init_sysfs+0x18/0x20)
[<c00e3d38>] (blk_trace_init_sysfs) from [<c02bdfbc>]
(blk_register_queue+0xd8/0x154)
[<c02bdfbc>] (blk_register_queue) from [<c02cec84>]
(device_add_disk+0x194/0x44c)
[<c02cec84>] (device_add_disk) from [<c0436ec8>]
(ubiblock_create+0x284/0x2e0)
[<c0436ec8>] (ubiblock_create) from [<c0427bb8>]
(vol_cdev_ioctl+0x450/0x554)
[<c0427bb8>] (vol_cdev_ioctl) from [<c0189110>] (vfs_ioctl+0x30/0x44)
[<c0189110>] (vfs_ioctl) from [<c01892e0>] (do_vfs_ioctl+0xa0/0x790)
[<c01892e0>] (do_vfs_ioctl) from [<c0189a14>] (SyS_ioctl+0x44/0x68)
[<c0189a14>] (SyS_ioctl) from [<c0010640>] (ret_fast_syscall+0x0/0x34)
Locking idr_alloc/idr_remove removes the race and keeps gd->first_minor
unique.
Fixes: 2bf50d42f3a4 ("UBI: block: Dynamically allocate minor numbers")
Signed-off-by: Bradley Bolen <bradleybolen(a)gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/ubi/block.c | 42 ++++++++++++++++++++++++++----------------
1 file changed, 26 insertions(+), 16 deletions(-)
--- a/drivers/mtd/ubi/block.c
+++ b/drivers/mtd/ubi/block.c
@@ -99,6 +99,8 @@ struct ubiblock {
/* Linked list of all ubiblock instances */
static LIST_HEAD(ubiblock_devices);
+static DEFINE_IDR(ubiblock_minor_idr);
+/* Protects ubiblock_devices and ubiblock_minor_idr */
static DEFINE_MUTEX(devices_mutex);
static int ubiblock_major;
@@ -351,8 +353,6 @@ static const struct blk_mq_ops ubiblock_
.init_request = ubiblock_init_request,
};
-static DEFINE_IDR(ubiblock_minor_idr);
-
int ubiblock_create(struct ubi_volume_info *vi)
{
struct ubiblock *dev;
@@ -365,14 +365,15 @@ int ubiblock_create(struct ubi_volume_in
/* Check that the volume isn't already handled */
mutex_lock(&devices_mutex);
if (find_dev_nolock(vi->ubi_num, vi->vol_id)) {
- mutex_unlock(&devices_mutex);
- return -EEXIST;
+ ret = -EEXIST;
+ goto out_unlock;
}
- mutex_unlock(&devices_mutex);
dev = kzalloc(sizeof(struct ubiblock), GFP_KERNEL);
- if (!dev)
- return -ENOMEM;
+ if (!dev) {
+ ret = -ENOMEM;
+ goto out_unlock;
+ }
mutex_init(&dev->dev_mutex);
@@ -437,14 +438,13 @@ int ubiblock_create(struct ubi_volume_in
goto out_free_queue;
}
- mutex_lock(&devices_mutex);
list_add_tail(&dev->list, &ubiblock_devices);
- mutex_unlock(&devices_mutex);
/* Must be the last step: anyone can call file ops from now on */
add_disk(dev->gd);
dev_info(disk_to_dev(dev->gd), "created from ubi%d:%d(%s)",
dev->ubi_num, dev->vol_id, vi->name);
+ mutex_unlock(&devices_mutex);
return 0;
out_free_queue:
@@ -457,6 +457,8 @@ out_put_disk:
put_disk(dev->gd);
out_free_dev:
kfree(dev);
+out_unlock:
+ mutex_unlock(&devices_mutex);
return ret;
}
@@ -478,30 +480,36 @@ static void ubiblock_cleanup(struct ubib
int ubiblock_remove(struct ubi_volume_info *vi)
{
struct ubiblock *dev;
+ int ret;
mutex_lock(&devices_mutex);
dev = find_dev_nolock(vi->ubi_num, vi->vol_id);
if (!dev) {
- mutex_unlock(&devices_mutex);
- return -ENODEV;
+ ret = -ENODEV;
+ goto out_unlock;
}
/* Found a device, let's lock it so we can check if it's busy */
mutex_lock(&dev->dev_mutex);
if (dev->refcnt > 0) {
- mutex_unlock(&dev->dev_mutex);
- mutex_unlock(&devices_mutex);
- return -EBUSY;
+ ret = -EBUSY;
+ goto out_unlock_dev;
}
/* Remove from device list */
list_del(&dev->list);
- mutex_unlock(&devices_mutex);
-
ubiblock_cleanup(dev);
mutex_unlock(&dev->dev_mutex);
+ mutex_unlock(&devices_mutex);
+
kfree(dev);
return 0;
+
+out_unlock_dev:
+ mutex_unlock(&dev->dev_mutex);
+out_unlock:
+ mutex_unlock(&devices_mutex);
+ return ret;
}
static int ubiblock_resize(struct ubi_volume_info *vi)
@@ -630,6 +638,7 @@ static void ubiblock_remove_all(void)
struct ubiblock *next;
struct ubiblock *dev;
+ mutex_lock(&devices_mutex);
list_for_each_entry_safe(dev, next, &ubiblock_devices, list) {
/* The module is being forcefully removed */
WARN_ON(dev->desc);
@@ -638,6 +647,7 @@ static void ubiblock_remove_all(void)
ubiblock_cleanup(dev);
kfree(dev);
}
+ mutex_unlock(&devices_mutex);
}
int __init ubiblock_init(void)
Patches currently in stable-queue which might be from bradleybolen(a)gmail.com are
queue-4.14/ubi-block-fix-locking-for-idr_alloc-idr_remove.patch
This is a note to let you know that I've just added the patch titled
nfs41: do not return ENOMEM on LAYOUTUNAVAILABLE
to the 4.14-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:
nfs41-do-not-return-enomem-on-layoutunavailable.patch
and it can be found in the queue-4.14 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 7ff4cff637aa0bd2abbd81f53b2a6206c50afd95 Mon Sep 17 00:00:00 2001
From: Tigran Mkrtchyan <tigran.mkrtchyan(a)desy.de>
Date: Tue, 16 Jan 2018 22:38:50 +0100
Subject: nfs41: do not return ENOMEM on LAYOUTUNAVAILABLE
From: Tigran Mkrtchyan <tigran.mkrtchyan(a)desy.de>
commit 7ff4cff637aa0bd2abbd81f53b2a6206c50afd95 upstream.
A pNFS server may return LAYOUTUNAVAILABLE error on LAYOUTGET for files
which don't have any layout. In this situation pnfs_update_layout
currently returns NULL. As this NULL is converted into ENOMEM, IO
requests fails instead of falling back to MDS.
Do not return ENOMEM on LAYOUTUNAVAILABLE and let client retry through
MDS.
Fixes 8d40b0f14846f. I will suggest to backport this fix to affected
stable branches.
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan(a)desy.de>
[trondmy: Use IS_ERR_OR_NULL()]
Fixes: 8d40b0f14846 ("NFS filelayout:call GETDEVICEINFO after...")
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/filelayout/filelayout.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/fs/nfs/filelayout/filelayout.c
+++ b/fs/nfs/filelayout/filelayout.c
@@ -895,9 +895,7 @@ fl_pnfs_update_layout(struct inode *ino,
lseg = pnfs_update_layout(ino, ctx, pos, count, iomode, strict_iomode,
gfp_flags);
- if (!lseg)
- lseg = ERR_PTR(-ENOMEM);
- if (IS_ERR(lseg))
+ if (IS_ERR_OR_NULL(lseg))
goto out;
lo = NFS_I(ino)->layout;
Patches currently in stable-queue which might be from tigran.mkrtchyan(a)desy.de are
queue-4.14/nfs41-do-not-return-enomem-on-layoutunavailable.patch
This is a note to let you know that I've just added the patch titled
NFS: reject request for id_legacy key without auxdata
to the 4.14-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:
nfs-reject-request-for-id_legacy-key-without-auxdata.patch
and it can be found in the queue-4.14 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 49686cbbb3ebafe42e63868222f269d8053ead00 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Fri, 19 Jan 2018 15:15:34 -0800
Subject: NFS: reject request for id_legacy key without auxdata
From: Eric Biggers <ebiggers(a)google.com>
commit 49686cbbb3ebafe42e63868222f269d8053ead00 upstream.
nfs_idmap_legacy_upcall() is supposed to be called with 'aux' pointing
to a 'struct idmap', via the call to request_key_with_auxdata() in
nfs_idmap_request_key().
However it can also be reached via the request_key() system call in
which case 'aux' will be NULL, causing a NULL pointer dereference in
nfs_idmap_prepare_pipe_upcall(), assuming that the key description is
valid enough to get that far.
Fix this by making nfs_idmap_legacy_upcall() negate the key if no
auxdata is provided.
As usual, this bug was found by syzkaller. A simple reproducer using
the command-line keyctl program is:
keyctl request2 id_legacy uid:0 '' @s
Fixes: 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring")
Reported-by: syzbot+5dfdbcf7b3eb5912abbb(a)syzkaller.appspotmail.com
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Trond Myklebust <trondmy(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/nfs4idmap.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/nfs/nfs4idmap.c
+++ b/fs/nfs/nfs4idmap.c
@@ -568,9 +568,13 @@ static int nfs_idmap_legacy_upcall(struc
struct idmap_msg *im;
struct idmap *idmap = (struct idmap *)aux;
struct key *key = cons->key;
- int ret = -ENOMEM;
+ int ret = -ENOKEY;
+
+ if (!aux)
+ goto out1;
/* msg and im are freed in idmap_pipe_destroy_msg */
+ ret = -ENOMEM;
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
goto out1;
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.14/ubifs-free-the-encrypted-symlink-target.patch
queue-4.14/nfs-reject-request-for-id_legacy-key-without-auxdata.patch
This is a note to let you know that I've just added the patch titled
nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds
to the 4.14-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:
nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
and it can be found in the queue-4.14 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 ba4a76f703ab7eb72941fdaac848502073d6e9ee Mon Sep 17 00:00:00 2001
From: Scott Mayhew <smayhew(a)redhat.com>
Date: Fri, 15 Dec 2017 16:12:32 -0500
Subject: nfs/pnfs: fix nfs_direct_req ref leak when i/o falls back to the mds
From: Scott Mayhew <smayhew(a)redhat.com>
commit ba4a76f703ab7eb72941fdaac848502073d6e9ee upstream.
Currently when falling back to doing I/O through the MDS (via
pnfs_{read|write}_through_mds), the client frees the nfs_pgio_header
without releasing the reference taken on the dreq
via pnfs_generic_pg_{read|write}pages -> nfs_pgheader_init ->
nfs_direct_pgio_init. It then takes another reference on the dreq via
nfs_generic_pg_pgios -> nfs_pgheader_init -> nfs_direct_pgio_init and
as a result the requester will become stuck in inode_dio_wait. Once
that happens, other processes accessing the inode will become stuck as
well.
Ensure that pnfs_read_through_mds() and pnfs_write_through_mds() clean
up correctly by calling hdr->completion_ops->completion() instead of
calling hdr->release() directly.
This can be reproduced (sometimes) by performing "storage failover
takeover" commands on NetApp filer while doing direct I/O from a client.
This can also be reproduced using SystemTap to simulate a failure while
doing direct I/O from a client (from Dave Wysochanski
<dwysocha(a)redhat.com>):
stap -v -g -e 'probe module("nfs_layout_nfsv41_files").function("nfs4_fl_prepare_ds").return { $return=NULL; exit(); }'
Suggested-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Scott Mayhew <smayhew(a)redhat.com>
Fixes: 1ca018d28d ("pNFS: Fix a memory leak when attempted pnfs fails")
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/pnfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -2237,7 +2237,7 @@ pnfs_write_through_mds(struct nfs_pageio
nfs_pageio_reset_write_mds(desc);
mirror->pg_recoalesce = 1;
}
- hdr->release(hdr);
+ hdr->completion_ops->completion(hdr);
}
static enum pnfs_try_status
@@ -2360,7 +2360,7 @@ pnfs_read_through_mds(struct nfs_pageio_
nfs_pageio_reset_read_mds(desc);
mirror->pg_recoalesce = 1;
}
- hdr->release(hdr);
+ hdr->completion_ops->completion(hdr);
}
/*
Patches currently in stable-queue which might be from smayhew(a)redhat.com are
queue-4.14/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
This is a note to let you know that I've just added the patch titled
NFS: Fix a race between mmap() and O_DIRECT
to the 4.14-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:
nfs-fix-a-race-between-mmap-and-o_direct.patch
and it can be found in the queue-4.14 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 e231c6879cfd44e4fffd384bb6dd7d313249a523 Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Sun, 28 Jan 2018 09:29:41 -0500
Subject: NFS: Fix a race between mmap() and O_DIRECT
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
commit e231c6879cfd44e4fffd384bb6dd7d313249a523 upstream.
When locking the file in order to do O_DIRECT on it, we must unmap
any mmapped ranges on the pagecache so that we can flush out the
dirty data.
Fixes: a5864c999de67 ("NFS: Do not serialise O_DIRECT reads and writes")
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/nfs/io.c
+++ b/fs/nfs/io.c
@@ -99,7 +99,7 @@ static void nfs_block_buffered(struct nf
{
if (!test_bit(NFS_INO_ODIRECT, &nfsi->flags)) {
set_bit(NFS_INO_ODIRECT, &nfsi->flags);
- nfs_wb_all(inode);
+ nfs_sync_mapping(inode->i_mapping);
}
}
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.14/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
queue-4.14/nfs-fix-nfsstat-breakage-due-to-lookupp.patch
queue-4.14/nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
queue-4.14/nfs41-do-not-return-enomem-on-layoutunavailable.patch
queue-4.14/nfs-commit-direct-writes-even-if-they-fail-partially.patch
queue-4.14/nfs-fix-a-race-between-mmap-and-o_direct.patch
This is a note to let you know that I've just added the patch titled
NFS: commit direct writes even if they fail partially
to the 4.14-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:
nfs-commit-direct-writes-even-if-they-fail-partially.patch
and it can be found in the queue-4.14 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 1b8d97b0a837beaf48a8449955b52c650a7114b4 Mon Sep 17 00:00:00 2001
From: "J. Bruce Fields" <bfields(a)redhat.com>
Date: Tue, 16 Jan 2018 10:08:00 -0500
Subject: NFS: commit direct writes even if they fail partially
From: J. Bruce Fields <bfields(a)redhat.com>
commit 1b8d97b0a837beaf48a8449955b52c650a7114b4 upstream.
If some of the WRITE calls making up an O_DIRECT write syscall fail,
we neglect to commit, even if some of the WRITEs succeed.
We also depend on the commit code to free the reference count on the
nfs_page taken in the "if (request_commit)" case at the end of
nfs_direct_write_completion(). The problem was originally noticed
because ENOSPC's encountered partway through a write would result in a
closed file being sillyrenamed when it should have been unlinked.
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/direct.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -775,10 +775,8 @@ static void nfs_direct_write_completion(
spin_lock(&dreq->lock);
- if (test_bit(NFS_IOHDR_ERROR, &hdr->flags)) {
- dreq->flags = 0;
+ if (test_bit(NFS_IOHDR_ERROR, &hdr->flags))
dreq->error = hdr->error;
- }
if (dreq->error == 0) {
nfs_direct_good_bytes(dreq, hdr);
if (nfs_write_need_commit(hdr)) {
Patches currently in stable-queue which might be from bfields(a)redhat.com are
queue-4.14/nfs-commit-direct-writes-even-if-they-fail-partially.patch
This is a note to let you know that I've just added the patch titled
NFS: Add a cond_resched() to nfs_commit_release_pages()
to the 4.14-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:
nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
and it can be found in the queue-4.14 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 7f1bda447c9bd48b415acedba6b830f61591601f Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Mon, 18 Dec 2017 14:39:13 -0500
Subject: NFS: Add a cond_resched() to nfs_commit_release_pages()
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
commit 7f1bda447c9bd48b415acedba6b830f61591601f upstream.
The commit list can get very large, and so we need a cond_resched()
in nfs_commit_release_pages() in order to ensure we don't hog the CPU
for excessive periods of time.
Reported-by: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/write.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1836,6 +1836,8 @@ static void nfs_commit_release_pages(str
set_bit(NFS_CONTEXT_RESEND_WRITES, &req->wb_context->flags);
next:
nfs_unlock_and_release_request(req);
+ /* Latency breaker */
+ cond_resched();
}
nfss = NFS_SERVER(data->inode);
if (atomic_long_read(&nfss->writeback) < NFS_CONGESTION_OFF_THRESH)
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-4.14/nfs-pnfs-fix-nfs_direct_req-ref-leak-when-i-o-falls-back-to-the-mds.patch
queue-4.14/nfs-fix-nfsstat-breakage-due-to-lookupp.patch
queue-4.14/nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
queue-4.14/nfs41-do-not-return-enomem-on-layoutunavailable.patch
queue-4.14/nfs-commit-direct-writes-even-if-they-fail-partially.patch
queue-4.14/nfs-fix-a-race-between-mmap-and-o_direct.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: sunxi: Fix ECC strength choice
to the 4.14-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:
mtd-nand-sunxi-fix-ecc-strength-choice.patch
and it can be found in the queue-4.14 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 f4c6cd1a7f2275d5bc0e494b21fff26f8dde80f0 Mon Sep 17 00:00:00 2001
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Date: Wed, 24 Jan 2018 23:49:31 +0100
Subject: mtd: nand: sunxi: Fix ECC strength choice
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
commit f4c6cd1a7f2275d5bc0e494b21fff26f8dde80f0 upstream.
When the requested ECC strength does not exactly match the strengths
supported by the ECC engine, the driver is selecting the closest
strength meeting the 'selected_strength > requested_strength'
constraint. Fix the fact that, in this particular case, ecc->strength
value was not updated to match the 'selected_strength'.
For instance, one can encounter this issue when no ECC requirement is
filled in the device tree while the NAND chip minimum requirement is not
a strength/step_size combo natively supported by the ECC engine.
Fixes: 1fef62c1423b ("mtd: nand: add sunxi NAND flash controller support")
Suggested-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/sunxi_nand.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -1853,8 +1853,14 @@ static int sunxi_nand_hw_common_ecc_ctrl
/* Add ECC info retrieval from DT */
for (i = 0; i < ARRAY_SIZE(strengths); i++) {
- if (ecc->strength <= strengths[i])
+ if (ecc->strength <= strengths[i]) {
+ /*
+ * Update ecc->strength value with the actual strength
+ * that will be used by the ECC engine.
+ */
+ ecc->strength = strengths[i];
break;
+ }
}
if (i >= ARRAY_SIZE(strengths)) {
Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are
queue-4.14/mtd-nand-sunxi-fix-ecc-strength-choice.patch
queue-4.14/mtd-nand-fix-nand_do_read_oob-return-value.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: Fix nand_do_read_oob() return value
to the 4.14-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:
mtd-nand-fix-nand_do_read_oob-return-value.patch
and it can be found in the queue-4.14 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 87e89ce8d0d14f573c068c61bec2117751fb5103 Mon Sep 17 00:00:00 2001
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Date: Fri, 12 Jan 2018 10:13:36 +0100
Subject: mtd: nand: Fix nand_do_read_oob() return value
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
commit 87e89ce8d0d14f573c068c61bec2117751fb5103 upstream.
Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in
OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a
negative error, and the MTD layer expected it.
However, the trend for the NAND layer is now to return an error or a
positive number of bitflips. Deciding which status to return to the user
belongs to the MTD layer.
Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
brought this logic to the mtd_read_oob() function while the return value
coming from nand_do_read_oob() (called by the ->_read_oob() hook) was
left unchanged.
Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/nand_base.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2201,6 +2201,7 @@ EXPORT_SYMBOL(nand_write_oob_syndrome);
static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
struct mtd_oob_ops *ops)
{
+ unsigned int max_bitflips = 0;
int page, realpage, chipnr;
struct nand_chip *chip = mtd_to_nand(mtd);
struct mtd_ecc_stats stats;
@@ -2258,6 +2259,8 @@ static int nand_do_read_oob(struct mtd_i
nand_wait_ready(mtd);
}
+ max_bitflips = max_t(unsigned int, max_bitflips, ret);
+
readlen -= len;
if (!readlen)
break;
@@ -2283,7 +2286,7 @@ static int nand_do_read_oob(struct mtd_i
if (mtd->ecc_stats.failed - stats.failed)
return -EBADMSG;
- return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
+ return max_bitflips;
}
/**
Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are
queue-4.14/mtd-nand-sunxi-fix-ecc-strength-choice.patch
queue-4.14/mtd-nand-fix-nand_do_read_oob-return-value.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: brcmnand: Disable prefetch by default
to the 4.14-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:
mtd-nand-brcmnand-disable-prefetch-by-default.patch
and it can be found in the queue-4.14 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 f953f0f89663c39f08f4baaa8a4a881401b65654 Mon Sep 17 00:00:00 2001
From: Kamal Dasu <kdasu.kdev(a)gmail.com>
Date: Mon, 8 Jan 2018 15:36:48 -0500
Subject: mtd: nand: brcmnand: Disable prefetch by default
From: Kamal Dasu <kdasu.kdev(a)gmail.com>
commit f953f0f89663c39f08f4baaa8a4a881401b65654 upstream.
Brcm nand controller prefetch feature needs to be disabled
by default. Enabling affects performance on random reads as
well as dma reads.
Signed-off-by: Kamal Dasu <kdasu.kdev(a)gmail.com>
Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller")
Acked-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/brcmnand/brcmnand.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -2193,16 +2193,9 @@ static int brcmnand_setup_dev(struct brc
if (ctrl->nand_version >= 0x0702)
tmp |= ACC_CONTROL_RD_ERASED;
tmp &= ~ACC_CONTROL_FAST_PGM_RDIN;
- if (ctrl->features & BRCMNAND_HAS_PREFETCH) {
- /*
- * FIXME: Flash DMA + prefetch may see spurious erased-page ECC
- * errors
- */
- if (has_flash_dma(ctrl))
- tmp &= ~ACC_CONTROL_PREFETCH;
- else
- tmp |= ACC_CONTROL_PREFETCH;
- }
+ if (ctrl->features & BRCMNAND_HAS_PREFETCH)
+ tmp &= ~ACC_CONTROL_PREFETCH;
+
nand_writereg(ctrl, offs, tmp);
return 0;
Patches currently in stable-queue which might be from kdasu.kdev(a)gmail.com are
queue-4.14/mtd-nand-brcmnand-disable-prefetch-by-default.patch
This is a note to let you know that I've just added the patch titled
mtd: cfi: convert inline functions to macros
to the 4.14-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:
mtd-cfi-convert-inline-functions-to-macros.patch
and it can be found in the queue-4.14 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 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Wed, 11 Oct 2017 15:54:10 +0200
Subject: mtd: cfi: convert inline functions to macros
From: Arnd Bergmann <arnd(a)arndb.de>
commit 9e343e87d2c4c707ef8fae2844864d4dde3a2d13 upstream.
The map_word_() functions, dating back to linux-2.6.8, try to perform
bitwise operations on a 'map_word' structure. This may have worked
with compilers that were current then (gcc-3.4 or earlier), but end
up being rather inefficient on any version I could try now (gcc-4.4 or
higher). Specifically we hit a problem analyzed in gcc PR81715 where we
fail to reuse the stack space for local variables.
This can be seen immediately in the stack consumption for
cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN)
can be up to 2200 bytes. Changing the inline functions into macros brings
this down to 1280 bytes. Without KASAN, the same problem exists, but
the stack consumption is lower to start with, my patch shrinks it from
920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around
1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word
structures for each call to one of these helpers.
With the latest gcc-8 snapshot, the problem is fixed in upstream gcc,
but nobody uses that yet, so we should still work around it in mainline
kernels and probably backport the workaround to stable kernels as well.
We had a couple of other functions that suffered from the same gcc bug,
and all of those had a simpler workaround involving dummy variables
in the inline function. Unfortunately that did not work here, the
macro hack was the best I could come up with.
It would also be helpful to have someone to a little performance testing
on the patch, to see how much it helps in terms of CPU utilitzation.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Acked-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/mtd/map.h | 130 ++++++++++++++++++++++--------------------------
1 file changed, 61 insertions(+), 69 deletions(-)
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -270,75 +270,67 @@ void map_destroy(struct mtd_info *mtd);
#define INVALIDATE_CACHED_RANGE(map, from, size) \
do { if (map->inval_cache) map->inval_cache(map, from, size); } while (0)
-
-static inline int map_word_equal(struct map_info *map, map_word val1, map_word val2)
-{
- int i;
-
- for (i = 0; i < map_words(map); i++) {
- if (val1.x[i] != val2.x[i])
- return 0;
- }
-
- return 1;
-}
-
-static inline map_word map_word_and(struct map_info *map, map_word val1, map_word val2)
-{
- map_word r;
- int i;
-
- for (i = 0; i < map_words(map); i++)
- r.x[i] = val1.x[i] & val2.x[i];
-
- return r;
-}
-
-static inline map_word map_word_clr(struct map_info *map, map_word val1, map_word val2)
-{
- map_word r;
- int i;
-
- for (i = 0; i < map_words(map); i++)
- r.x[i] = val1.x[i] & ~val2.x[i];
-
- return r;
-}
-
-static inline map_word map_word_or(struct map_info *map, map_word val1, map_word val2)
-{
- map_word r;
- int i;
-
- for (i = 0; i < map_words(map); i++)
- r.x[i] = val1.x[i] | val2.x[i];
-
- return r;
-}
-
-static inline int map_word_andequal(struct map_info *map, map_word val1, map_word val2, map_word val3)
-{
- int i;
-
- for (i = 0; i < map_words(map); i++) {
- if ((val1.x[i] & val2.x[i]) != val3.x[i])
- return 0;
- }
-
- return 1;
-}
-
-static inline int map_word_bitsset(struct map_info *map, map_word val1, map_word val2)
-{
- int i;
-
- for (i = 0; i < map_words(map); i++) {
- if (val1.x[i] & val2.x[i])
- return 1;
- }
-
- return 0;
-}
+#define map_word_equal(map, val1, val2) \
+({ \
+ int i, ret = 1; \
+ for (i = 0; i < map_words(map); i++) \
+ if ((val1).x[i] != (val2).x[i]) { \
+ ret = 0; \
+ break; \
+ } \
+ ret; \
+})
+
+#define map_word_and(map, val1, val2) \
+({ \
+ map_word r; \
+ int i; \
+ for (i = 0; i < map_words(map); i++) \
+ r.x[i] = (val1).x[i] & (val2).x[i]; \
+ r; \
+})
+
+#define map_word_clr(map, val1, val2) \
+({ \
+ map_word r; \
+ int i; \
+ for (i = 0; i < map_words(map); i++) \
+ r.x[i] = (val1).x[i] & ~(val2).x[i]; \
+ r; \
+})
+
+#define map_word_or(map, val1, val2) \
+({ \
+ map_word r; \
+ int i; \
+ for (i = 0; i < map_words(map); i++) \
+ r.x[i] = (val1).x[i] | (val2).x[i]; \
+ r; \
+})
+
+#define map_word_andequal(map, val1, val2, val3) \
+({ \
+ int i, ret = 1; \
+ for (i = 0; i < map_words(map); i++) { \
+ if (((val1).x[i] & (val2).x[i]) != (val2).x[i]) { \
+ ret = 0; \
+ break; \
+ } \
+ } \
+ ret; \
+})
+
+#define map_word_bitsset(map, val1, val2) \
+({ \
+ int i, ret = 0; \
+ for (i = 0; i < map_words(map); i++) { \
+ if ((val1).x[i] & (val2).x[i]) { \
+ ret = 1; \
+ break; \
+ } \
+ } \
+ ret; \
+})
static inline map_word map_word_load(struct map_info *map, const void *ptr)
{
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/mtd-cfi-convert-inline-functions-to-macros.patch
This is a note to let you know that I've just added the patch titled
kernfs: fix regression in kernfs_fop_write caused by wrong type
to the 4.14-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:
kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.patch
and it can be found in the queue-4.14 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 ba87977a49913129962af8ac35b0e13e0fa4382d Mon Sep 17 00:00:00 2001
From: Ivan Vecera <ivecera(a)redhat.com>
Date: Fri, 19 Jan 2018 09:18:54 +0100
Subject: kernfs: fix regression in kernfs_fop_write caused by wrong type
From: Ivan Vecera <ivecera(a)redhat.com>
commit ba87977a49913129962af8ac35b0e13e0fa4382d upstream.
Commit b7ce40cff0b9 ("kernfs: cache atomic_write_len in
kernfs_open_file") changes type of local variable 'len' from ssize_t
to size_t. This change caused that the *ppos value is updated also
when the previous write callback failed.
Mentioned snippet:
...
len = ops->write(...); <- return value can be negative
...
if (len > 0) <- true here in this case
*ppos += len;
...
Fixes: b7ce40cff0b9 ("kernfs: cache atomic_write_len in kernfs_open_file")
Acked-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Ivan Vecera <ivecera(a)redhat.com>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/kernfs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -275,7 +275,7 @@ static ssize_t kernfs_fop_write(struct f
{
struct kernfs_open_file *of = kernfs_of(file);
const struct kernfs_ops *ops;
- size_t len;
+ ssize_t len;
char *buf;
if (of->atomic_write_len) {
Patches currently in stable-queue which might be from ivecera(a)redhat.com are
queue-4.14/kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.patch
This is a note to let you know that I've just added the patch titled
ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
to the 4.14-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:
ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
and it can be found in the queue-4.14 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 998008b779e424bd7513c434d0ab9c1268459009 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede(a)redhat.com>
Date: Wed, 6 Dec 2017 16:41:09 +0100
Subject: ahci: Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
From: Hans de Goede <hdegoede(a)redhat.com>
commit 998008b779e424bd7513c434d0ab9c1268459009 upstream.
Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
SATA controllers. This commit is a preparation patch for allowing a
different default sata link powermanagement policy for mobile chipsets.
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/ahci.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -385,6 +385,10 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(INTEL, 0xa206), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa252), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa256), board_ahci }, /* Lewisburg RAID*/
+ { PCI_VDEVICE(INTEL, 0x0f22), board_ahci }, /* Bay Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x0f23), board_ahci }, /* Bay Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x22a3), board_ahci }, /* Cherry Trail AHCI */
+ { PCI_VDEVICE(INTEL, 0x5ae3), board_ahci }, /* Apollo Lake AHCI */
/* JMicron 360/1/3/5/6, match class to avoid IDE function */
{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
Patches currently in stable-queue which might be from hdegoede(a)redhat.com are
queue-4.14/ahci-add-pci-ids-for-intel-bay-trail-cherry-trail-and-apollo-lake-ahci.patch
queue-4.14/ahci-allow-setting-a-default-lpm-policy-for-mobile-chipsets.patch
queue-4.14/ahci-annotate-pci-ids-for-mobile-intel-chipsets-as-such.patch
This is a note to let you know that I've just added the patch titled
ahci: Add Intel Cannon Lake PCH-H PCI ID
to the 4.14-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:
ahci-add-intel-cannon-lake-pch-h-pci-id.patch
and it can be found in the queue-4.14 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 f919dde0772a894c693a1eeabc77df69d6a9b937 Mon Sep 17 00:00:00 2001
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Date: Thu, 11 Jan 2018 15:55:50 +0300
Subject: ahci: Add Intel Cannon Lake PCH-H PCI ID
From: Mika Westerberg <mika.westerberg(a)linux.intel.com>
commit f919dde0772a894c693a1eeabc77df69d6a9b937 upstream.
Add Intel Cannon Lake PCH-H PCI ID to the list of supported controllers.
Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/ata/ahci.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -393,6 +393,7 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(INTEL, 0xa206), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa252), board_ahci }, /* Lewisburg RAID*/
{ PCI_VDEVICE(INTEL, 0xa256), board_ahci }, /* Lewisburg RAID*/
+ { PCI_VDEVICE(INTEL, 0xa356), board_ahci }, /* Cannon Lake PCH-H RAID */
{ PCI_VDEVICE(INTEL, 0x0f22), board_ahci_mobile }, /* Bay Trail AHCI */
{ PCI_VDEVICE(INTEL, 0x0f23), board_ahci_mobile }, /* Bay Trail AHCI */
{ PCI_VDEVICE(INTEL, 0x22a3), board_ahci_mobile }, /* Cherry Tr. AHCI */
Patches currently in stable-queue which might be from mika.westerberg(a)linux.intel.com are
queue-4.14/ahci-add-intel-cannon-lake-pch-h-pci-id.patch
This is a note to let you know that I've just added the patch titled
NFS: commit direct writes even if they fail partially
to the 3.18-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:
nfs-commit-direct-writes-even-if-they-fail-partially.patch
and it can be found in the queue-3.18 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 1b8d97b0a837beaf48a8449955b52c650a7114b4 Mon Sep 17 00:00:00 2001
From: "J. Bruce Fields" <bfields(a)redhat.com>
Date: Tue, 16 Jan 2018 10:08:00 -0500
Subject: NFS: commit direct writes even if they fail partially
From: J. Bruce Fields <bfields(a)redhat.com>
commit 1b8d97b0a837beaf48a8449955b52c650a7114b4 upstream.
If some of the WRITE calls making up an O_DIRECT write syscall fail,
we neglect to commit, even if some of the WRITEs succeed.
We also depend on the commit code to free the reference count on the
nfs_page taken in the "if (request_commit)" case at the end of
nfs_direct_write_completion(). The problem was originally noticed
because ENOSPC's encountered partway through a write would result in a
closed file being sillyrenamed when it should have been unlinked.
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/direct.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/fs/nfs/direct.c
+++ b/fs/nfs/direct.c
@@ -716,10 +716,8 @@ static void nfs_direct_write_completion(
spin_lock(&dreq->lock);
- if (test_bit(NFS_IOHDR_ERROR, &hdr->flags)) {
- dreq->flags = 0;
+ if (test_bit(NFS_IOHDR_ERROR, &hdr->flags))
dreq->error = hdr->error;
- }
if (dreq->error == 0) {
dreq->count += hdr->good_bytes;
if (nfs_write_need_commit(hdr)) {
Patches currently in stable-queue which might be from bfields(a)redhat.com are
queue-3.18/nfs-commit-direct-writes-even-if-they-fail-partially.patch
This is a note to let you know that I've just added the patch titled
NFS: Add a cond_resched() to nfs_commit_release_pages()
to the 3.18-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:
nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
and it can be found in the queue-3.18 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 7f1bda447c9bd48b415acedba6b830f61591601f Mon Sep 17 00:00:00 2001
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
Date: Mon, 18 Dec 2017 14:39:13 -0500
Subject: NFS: Add a cond_resched() to nfs_commit_release_pages()
From: Trond Myklebust <trond.myklebust(a)primarydata.com>
commit 7f1bda447c9bd48b415acedba6b830f61591601f upstream.
The commit list can get very large, and so we need a cond_resched()
in nfs_commit_release_pages() in order to ensure we don't hog the CPU
for excessive periods of time.
Reported-by: Mike Galbraith <efault(a)gmx.de>
Signed-off-by: Trond Myklebust <trond.myklebust(a)primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/write.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/nfs/write.c
+++ b/fs/nfs/write.c
@@ -1646,6 +1646,8 @@ static void nfs_commit_release_pages(str
set_bit(NFS_CONTEXT_RESEND_WRITES, &req->wb_context->flags);
next:
nfs_unlock_and_release_request(req);
+ /* Latency breaker */
+ cond_resched();
}
nfss = NFS_SERVER(data->inode);
if (atomic_long_read(&nfss->writeback) < NFS_CONGESTION_OFF_THRESH)
Patches currently in stable-queue which might be from trond.myklebust(a)primarydata.com are
queue-3.18/nfs-add-a-cond_resched-to-nfs_commit_release_pages.patch
queue-3.18/nfs-commit-direct-writes-even-if-they-fail-partially.patch
This is a note to let you know that I've just added the patch titled
mtd: nand: Fix nand_do_read_oob() return value
to the 3.18-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:
mtd-nand-fix-nand_do_read_oob-return-value.patch
and it can be found in the queue-3.18 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 87e89ce8d0d14f573c068c61bec2117751fb5103 Mon Sep 17 00:00:00 2001
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Date: Fri, 12 Jan 2018 10:13:36 +0100
Subject: mtd: nand: Fix nand_do_read_oob() return value
From: Miquel Raynal <miquel.raynal(a)free-electrons.com>
commit 87e89ce8d0d14f573c068c61bec2117751fb5103 upstream.
Starting from commit 041e4575f034 ("mtd: nand: handle ECC errors in
OOB"), nand_do_read_oob() (from the NAND core) did return 0 or a
negative error, and the MTD layer expected it.
However, the trend for the NAND layer is now to return an error or a
positive number of bitflips. Deciding which status to return to the user
belongs to the MTD layer.
Commit e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
brought this logic to the mtd_read_oob() function while the return value
coming from nand_do_read_oob() (called by the ->_read_oob() hook) was
left unchanged.
Fixes: e47f68587b82 ("mtd: check for max_bitflips in mtd_read_oob()")
Signed-off-by: Miquel Raynal <miquel.raynal(a)free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/nand/nand_base.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1872,6 +1872,7 @@ static int nand_write_oob_syndrome(struc
static int nand_do_read_oob(struct mtd_info *mtd, loff_t from,
struct mtd_oob_ops *ops)
{
+ unsigned int max_bitflips = 0;
int page, realpage, chipnr;
struct nand_chip *chip = mtd->priv;
struct mtd_ecc_stats stats;
@@ -1932,6 +1933,8 @@ static int nand_do_read_oob(struct mtd_i
nand_wait_ready(mtd);
}
+ max_bitflips = max_t(unsigned int, max_bitflips, ret);
+
readlen -= len;
if (!readlen)
break;
@@ -1957,7 +1960,7 @@ static int nand_do_read_oob(struct mtd_i
if (mtd->ecc_stats.failed - stats.failed)
return -EBADMSG;
- return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
+ return max_bitflips;
}
/**
Patches currently in stable-queue which might be from miquel.raynal(a)free-electrons.com are
queue-3.18/mtd-nand-fix-nand_do_read_oob-return-value.patch
This is a note to let you know that I've just added the patch titled
kernfs: fix regression in kernfs_fop_write caused by wrong type
to the 3.18-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:
kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.patch
and it can be found in the queue-3.18 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 ba87977a49913129962af8ac35b0e13e0fa4382d Mon Sep 17 00:00:00 2001
From: Ivan Vecera <ivecera(a)redhat.com>
Date: Fri, 19 Jan 2018 09:18:54 +0100
Subject: kernfs: fix regression in kernfs_fop_write caused by wrong type
From: Ivan Vecera <ivecera(a)redhat.com>
commit ba87977a49913129962af8ac35b0e13e0fa4382d upstream.
Commit b7ce40cff0b9 ("kernfs: cache atomic_write_len in
kernfs_open_file") changes type of local variable 'len' from ssize_t
to size_t. This change caused that the *ppos value is updated also
when the previous write callback failed.
Mentioned snippet:
...
len = ops->write(...); <- return value can be negative
...
if (len > 0) <- true here in this case
*ppos += len;
...
Fixes: b7ce40cff0b9 ("kernfs: cache atomic_write_len in kernfs_open_file")
Acked-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Ivan Vecera <ivecera(a)redhat.com>
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/kernfs/file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/kernfs/file.c
+++ b/fs/kernfs/file.c
@@ -267,7 +267,7 @@ static ssize_t kernfs_fop_write(struct f
{
struct kernfs_open_file *of = kernfs_of(file);
const struct kernfs_ops *ops;
- size_t len;
+ ssize_t len;
char *buf;
if (of->atomic_write_len) {
Patches currently in stable-queue which might be from ivecera(a)redhat.com are
queue-3.18/kernfs-fix-regression-in-kernfs_fop_write-caused-by-wrong-type.patch
The patch below does not apply to the 3.18-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 49686cbbb3ebafe42e63868222f269d8053ead00 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Fri, 19 Jan 2018 15:15:34 -0800
Subject: [PATCH] NFS: reject request for id_legacy key without auxdata
nfs_idmap_legacy_upcall() is supposed to be called with 'aux' pointing
to a 'struct idmap', via the call to request_key_with_auxdata() in
nfs_idmap_request_key().
However it can also be reached via the request_key() system call in
which case 'aux' will be NULL, causing a NULL pointer dereference in
nfs_idmap_prepare_pipe_upcall(), assuming that the key description is
valid enough to get that far.
Fix this by making nfs_idmap_legacy_upcall() negate the key if no
auxdata is provided.
As usual, this bug was found by syzkaller. A simple reproducer using
the command-line keyctl program is:
keyctl request2 id_legacy uid:0 '' @s
Fixes: 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring")
Reported-by: syzbot+5dfdbcf7b3eb5912abbb(a)syzkaller.appspotmail.com
Cc: <stable(a)vger.kernel.org> # v3.4+
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Trond Myklebust <trondmy(a)gmail.com>
diff --git a/fs/nfs/nfs4idmap.c b/fs/nfs/nfs4idmap.c
index 30426c1a1bbd..22dc30a679a0 100644
--- a/fs/nfs/nfs4idmap.c
+++ b/fs/nfs/nfs4idmap.c
@@ -568,9 +568,13 @@ static int nfs_idmap_legacy_upcall(struct key_construction *cons,
struct idmap_msg *im;
struct idmap *idmap = (struct idmap *)aux;
struct key *key = cons->key;
- int ret = -ENOMEM;
+ int ret = -ENOKEY;
+
+ if (!aux)
+ goto out1;
/* msg and im are freed in idmap_pipe_destroy_msg */
+ ret = -ENOMEM;
data = kzalloc(sizeof(*data), GFP_KERNEL);
if (!data)
goto out1;
From: Xiaolei Li <xiaolei.li(a)mediatek.com>
This is a conceptual cherry-pick of commit
d8db5b1ca9d4c57e49893d0f78e6d5ce81450cc8 upstream.
The inode is not locked in init_xattrs when creating a new inode.
Without this patch, there will occurs assert when booting or creating
a new file, if the kernel config CONFIG_SECURITY_SMACK is enabled.
Log likes:
UBIFS assert failed in ubifs_xattr_set at 298 (pid 1156)
CPU: 1 PID: 1156 Comm: ldconfig Tainted: G S 4.12.0-rc1-207440-g1e70b02 #2
Hardware name: MediaTek MT2712 evaluation board (DT)
Call trace:
[<ffff000008088538>] dump_backtrace+0x0/0x238
[<ffff000008088834>] show_stack+0x14/0x20
[<ffff0000083d98d4>] dump_stack+0x9c/0xc0
[<ffff00000835d524>] ubifs_xattr_set+0x374/0x5e0
[<ffff00000835d7ec>] init_xattrs+0x5c/0xb8
[<ffff000008385788>] security_inode_init_security+0x110/0x190
[<ffff00000835e058>] ubifs_init_security+0x30/0x68
[<ffff00000833ada0>] ubifs_mkdir+0x100/0x200
[<ffff00000820669c>] vfs_mkdir+0x11c/0x1b8
[<ffff00000820b73c>] SyS_mkdirat+0x74/0xd0
[<ffff000008082f8c>] __sys_trace_return+0x0/0x4
Signed-off-by: Xiaolei Li <xiaolei.li(a)mediatek.com>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Cc: stable(a)vger.kernel.org
(julia: massaged to apply to 4.9.y, which doesn't contain fscrypto support)
Signed-off-by: Julia Cartwright <julia(a)ni.com>
---
Hey all-
We reproduced the issue fixed upstream by Xiaolei Li's commit in 4.9.y,
with the very similar backtrace:
UBIFS assert failed in __ubifs_setxattr at 282 (pid 1362)
CPU: 1 PID: 1362 Comm: sed Not tainted 4.9.47-rt37 #1
Backtrace:
(dump_backtrace) from (show_stack+0x20/0x24)
(show_stack) from (dump_stack+0x80/0xa0)
(dump_stack) from (__ubifs_setxattr+0x84/0x634)
(__ubifs_setxattr) from (init_xattrs+0x70/0xac)
(init_xattrs) from (security_inode_init_security+0x100/0x144)
(security_inode_init_security) from (ubifs_init_security+0x38/0x6c)
(ubifs_init_security) from (ubifs_create+0xe8/0x1fc)
(ubifs_create) from (path_openat+0x97c/0x1090)
(path_openat) from (do_filp_open+0x48/0x94)
(do_filp_open) from (do_sys_open+0x134/0x1d8)
(do_sys_open) from (SyS_open+0x30/0x34)
(SyS_open) from (ret_fast_syscall+0x0/0x3c)
Please consider applying this to 4.9.y at the very least, it may apply
further back as well.
Thanks!
Julia
fs/ubifs/xattr.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c
index d9f9615bfd71..3979d767a0cb 100644
--- a/fs/ubifs/xattr.c
+++ b/fs/ubifs/xattr.c
@@ -270,7 +270,8 @@ static struct inode *iget_xattr(struct ubifs_info *c, ino_t inum)
}
static int __ubifs_setxattr(struct inode *host, const char *name,
- const void *value, size_t size, int flags)
+ const void *value, size_t size, int flags,
+ bool check_lock)
{
struct inode *inode;
struct ubifs_info *c = host->i_sb->s_fs_info;
@@ -279,7 +280,8 @@ static int __ubifs_setxattr(struct inode *host, const char *name,
union ubifs_key key;
int err;
- ubifs_assert(inode_is_locked(host));
+ if (check_lock)
+ ubifs_assert(inode_is_locked(host));
if (size > UBIFS_MAX_INO_DATA)
return -ERANGE;
@@ -548,7 +550,8 @@ static int init_xattrs(struct inode *inode, const struct xattr *xattr_array,
}
strcpy(name, XATTR_SECURITY_PREFIX);
strcpy(name + XATTR_SECURITY_PREFIX_LEN, xattr->name);
- err = __ubifs_setxattr(inode, name, xattr->value, xattr->value_len, 0);
+ err = __ubifs_setxattr(inode, name, xattr->value,
+ xattr->value_len, 0, false);
kfree(name);
if (err < 0)
break;
@@ -594,7 +597,8 @@ static int ubifs_xattr_set(const struct xattr_handler *handler,
name = xattr_full_name(handler, name);
if (value)
- return __ubifs_setxattr(inode, name, value, size, flags);
+ return __ubifs_setxattr(inode, name, value, size, flags,
+ true);
else
return __ubifs_removexattr(inode, name);
}
--
2.16.1
The patch below does not apply to the 3.18-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 f78e5623f45bab2b726eec29dc5cefbbab2d0b1c Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer(a)pengutronix.de>
Date: Tue, 5 Dec 2017 16:01:20 +0100
Subject: [PATCH] ubi: fastmap: Erase outdated anchor PEBs during attach
The fastmap update code might erase the current fastmap anchor PEB
in case it doesn't find any new free PEB. When a power cut happens
in this situation we must not have any outdated fastmap anchor PEB
on the device, because that would be used to attach during next
boot.
The easiest way to make that sure is to erase all outdated fastmap
anchor PEBs synchronously during attach.
Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de>
Reviewed-by: Richard Weinberger <richard(a)nod.at>
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index b5b8cd6f481c..668b46202507 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1528,6 +1528,46 @@ static void shutdown_work(struct ubi_device *ubi)
}
}
+/**
+ * erase_aeb - erase a PEB given in UBI attach info PEB
+ * @ubi: UBI device description object
+ * @aeb: UBI attach info PEB
+ * @sync: If true, erase synchronously. Otherwise schedule for erasure
+ */
+static int erase_aeb(struct ubi_device *ubi, struct ubi_ainf_peb *aeb, bool sync)
+{
+ struct ubi_wl_entry *e;
+ int err;
+
+ e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
+ if (!e)
+ return -ENOMEM;
+
+ e->pnum = aeb->pnum;
+ e->ec = aeb->ec;
+ ubi->lookuptbl[e->pnum] = e;
+
+ if (sync) {
+ err = sync_erase(ubi, e, false);
+ if (err)
+ goto out_free;
+
+ wl_tree_add(e, &ubi->free);
+ ubi->free_count++;
+ } else {
+ err = schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false);
+ if (err)
+ goto out_free;
+ }
+
+ return 0;
+
+out_free:
+ wl_entry_destroy(ubi, e);
+
+ return err;
+}
+
/**
* ubi_wl_init - initialize the WL sub-system using attaching information.
* @ubi: UBI device description object
@@ -1566,18 +1606,10 @@ int ubi_wl_init(struct ubi_device *ubi, struct ubi_attach_info *ai)
list_for_each_entry_safe(aeb, tmp, &ai->erase, u.list) {
cond_resched();
- e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
- if (!e)
+ err = erase_aeb(ubi, aeb, false);
+ if (err)
goto out_free;
- e->pnum = aeb->pnum;
- e->ec = aeb->ec;
- ubi->lookuptbl[e->pnum] = e;
- if (schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false)) {
- wl_entry_destroy(ubi, e);
- goto out_free;
- }
-
found_pebs++;
}
@@ -1635,6 +1667,8 @@ int ubi_wl_init(struct ubi_device *ubi, struct ubi_attach_info *ai)
ubi_assert(!ubi->lookuptbl[e->pnum]);
ubi->lookuptbl[e->pnum] = e;
} else {
+ bool sync = false;
+
/*
* Usually old Fastmap PEBs are scheduled for erasure
* and we don't have to care about them but if we face
@@ -1644,18 +1678,21 @@ int ubi_wl_init(struct ubi_device *ubi, struct ubi_attach_info *ai)
if (ubi->lookuptbl[aeb->pnum])
continue;
- e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
- if (!e)
- goto out_free;
+ /*
+ * The fastmap update code might not find a free PEB for
+ * writing the fastmap anchor to and then reuses the
+ * current fastmap anchor PEB. When this PEB gets erased
+ * and a power cut happens before it is written again we
+ * must make sure that the fastmap attach code doesn't
+ * find any outdated fastmap anchors, hence we erase the
+ * outdated fastmap anchor PEBs synchronously here.
+ */
+ if (aeb->vol_id == UBI_FM_SB_VOLUME_ID)
+ sync = true;
- e->pnum = aeb->pnum;
- e->ec = aeb->ec;
- ubi_assert(!ubi->lookuptbl[e->pnum]);
- ubi->lookuptbl[e->pnum] = e;
- if (schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false)) {
- wl_entry_destroy(ubi, e);
+ err = erase_aeb(ubi, aeb, sync);
+ if (err)
goto out_free;
- }
}
found_pebs++;
The patch below does not apply to the 4.4-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 f78e5623f45bab2b726eec29dc5cefbbab2d0b1c Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer(a)pengutronix.de>
Date: Tue, 5 Dec 2017 16:01:20 +0100
Subject: [PATCH] ubi: fastmap: Erase outdated anchor PEBs during attach
The fastmap update code might erase the current fastmap anchor PEB
in case it doesn't find any new free PEB. When a power cut happens
in this situation we must not have any outdated fastmap anchor PEB
on the device, because that would be used to attach during next
boot.
The easiest way to make that sure is to erase all outdated fastmap
anchor PEBs synchronously during attach.
Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de>
Reviewed-by: Richard Weinberger <richard(a)nod.at>
Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index b5b8cd6f481c..668b46202507 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1528,6 +1528,46 @@ static void shutdown_work(struct ubi_device *ubi)
}
}
+/**
+ * erase_aeb - erase a PEB given in UBI attach info PEB
+ * @ubi: UBI device description object
+ * @aeb: UBI attach info PEB
+ * @sync: If true, erase synchronously. Otherwise schedule for erasure
+ */
+static int erase_aeb(struct ubi_device *ubi, struct ubi_ainf_peb *aeb, bool sync)
+{
+ struct ubi_wl_entry *e;
+ int err;
+
+ e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
+ if (!e)
+ return -ENOMEM;
+
+ e->pnum = aeb->pnum;
+ e->ec = aeb->ec;
+ ubi->lookuptbl[e->pnum] = e;
+
+ if (sync) {
+ err = sync_erase(ubi, e, false);
+ if (err)
+ goto out_free;
+
+ wl_tree_add(e, &ubi->free);
+ ubi->free_count++;
+ } else {
+ err = schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false);
+ if (err)
+ goto out_free;
+ }
+
+ return 0;
+
+out_free:
+ wl_entry_destroy(ubi, e);
+
+ return err;
+}
+
/**
* ubi_wl_init - initialize the WL sub-system using attaching information.
* @ubi: UBI device description object
@@ -1566,18 +1606,10 @@ int ubi_wl_init(struct ubi_device *ubi, struct ubi_attach_info *ai)
list_for_each_entry_safe(aeb, tmp, &ai->erase, u.list) {
cond_resched();
- e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
- if (!e)
+ err = erase_aeb(ubi, aeb, false);
+ if (err)
goto out_free;
- e->pnum = aeb->pnum;
- e->ec = aeb->ec;
- ubi->lookuptbl[e->pnum] = e;
- if (schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false)) {
- wl_entry_destroy(ubi, e);
- goto out_free;
- }
-
found_pebs++;
}
@@ -1635,6 +1667,8 @@ int ubi_wl_init(struct ubi_device *ubi, struct ubi_attach_info *ai)
ubi_assert(!ubi->lookuptbl[e->pnum]);
ubi->lookuptbl[e->pnum] = e;
} else {
+ bool sync = false;
+
/*
* Usually old Fastmap PEBs are scheduled for erasure
* and we don't have to care about them but if we face
@@ -1644,18 +1678,21 @@ int ubi_wl_init(struct ubi_device *ubi, struct ubi_attach_info *ai)
if (ubi->lookuptbl[aeb->pnum])
continue;
- e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
- if (!e)
- goto out_free;
+ /*
+ * The fastmap update code might not find a free PEB for
+ * writing the fastmap anchor to and then reuses the
+ * current fastmap anchor PEB. When this PEB gets erased
+ * and a power cut happens before it is written again we
+ * must make sure that the fastmap attach code doesn't
+ * find any outdated fastmap anchors, hence we erase the
+ * outdated fastmap anchor PEBs synchronously here.
+ */
+ if (aeb->vol_id == UBI_FM_SB_VOLUME_ID)
+ sync = true;
- e->pnum = aeb->pnum;
- e->ec = aeb->ec;
- ubi_assert(!ubi->lookuptbl[e->pnum]);
- ubi->lookuptbl[e->pnum] = e;
- if (schedule_erase(ubi, e, aeb->vol_id, aeb->lnum, 0, false)) {
- wl_entry_destroy(ubi, e);
+ err = erase_aeb(ubi, aeb, sync);
+ if (err)
goto out_free;
- }
}
found_pebs++;
The patch below does not apply to the 4.4-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 a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 Mon Sep 17 00:00:00 2001
From: Clay McClure <clay(a)daemons.net>
Date: Thu, 21 Sep 2017 19:01:34 -0700
Subject: [PATCH] ubi: Fix race condition between ubi volume creation and udev
Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi
device creation and udev"), we should make the volume active before
registering it.
Signed-off-by: Clay McClure <clay(a)daemons.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
diff --git a/drivers/mtd/ubi/vmt.c b/drivers/mtd/ubi/vmt.c
index 85237cf661f9..3fd8d7ff7a02 100644
--- a/drivers/mtd/ubi/vmt.c
+++ b/drivers/mtd/ubi/vmt.c
@@ -270,6 +270,12 @@ int ubi_create_volume(struct ubi_device *ubi, struct ubi_mkvol_req *req)
vol->last_eb_bytes = vol->usable_leb_size;
}
+ /* Make volume "available" before it becomes accessible via sysfs */
+ spin_lock(&ubi->volumes_lock);
+ ubi->volumes[vol_id] = vol;
+ ubi->vol_count += 1;
+ spin_unlock(&ubi->volumes_lock);
+
/* Register character device for the volume */
cdev_init(&vol->cdev, &ubi_vol_cdev_operations);
vol->cdev.owner = THIS_MODULE;
@@ -298,11 +304,6 @@ int ubi_create_volume(struct ubi_device *ubi, struct ubi_mkvol_req *req)
if (err)
goto out_sysfs;
- spin_lock(&ubi->volumes_lock);
- ubi->volumes[vol_id] = vol;
- ubi->vol_count += 1;
- spin_unlock(&ubi->volumes_lock);
-
ubi_volume_notify(ubi, vol, UBI_VOLUME_ADDED);
self_check_volumes(ubi);
return err;
@@ -315,6 +316,10 @@ int ubi_create_volume(struct ubi_device *ubi, struct ubi_mkvol_req *req)
*/
cdev_device_del(&vol->cdev, &vol->dev);
out_mapping:
+ spin_lock(&ubi->volumes_lock);
+ ubi->volumes[vol_id] = NULL;
+ ubi->vol_count -= 1;
+ spin_unlock(&ubi->volumes_lock);
ubi_eba_destroy_table(eba_tbl);
out_acc:
spin_lock(&ubi->volumes_lock);
The patch below does not apply to the 4.9-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 a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 Mon Sep 17 00:00:00 2001
From: Clay McClure <clay(a)daemons.net>
Date: Thu, 21 Sep 2017 19:01:34 -0700
Subject: [PATCH] ubi: Fix race condition between ubi volume creation and udev
Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi
device creation and udev"), we should make the volume active before
registering it.
Signed-off-by: Clay McClure <clay(a)daemons.net>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
diff --git a/drivers/mtd/ubi/vmt.c b/drivers/mtd/ubi/vmt.c
index 85237cf661f9..3fd8d7ff7a02 100644
--- a/drivers/mtd/ubi/vmt.c
+++ b/drivers/mtd/ubi/vmt.c
@@ -270,6 +270,12 @@ int ubi_create_volume(struct ubi_device *ubi, struct ubi_mkvol_req *req)
vol->last_eb_bytes = vol->usable_leb_size;
}
+ /* Make volume "available" before it becomes accessible via sysfs */
+ spin_lock(&ubi->volumes_lock);
+ ubi->volumes[vol_id] = vol;
+ ubi->vol_count += 1;
+ spin_unlock(&ubi->volumes_lock);
+
/* Register character device for the volume */
cdev_init(&vol->cdev, &ubi_vol_cdev_operations);
vol->cdev.owner = THIS_MODULE;
@@ -298,11 +304,6 @@ int ubi_create_volume(struct ubi_device *ubi, struct ubi_mkvol_req *req)
if (err)
goto out_sysfs;
- spin_lock(&ubi->volumes_lock);
- ubi->volumes[vol_id] = vol;
- ubi->vol_count += 1;
- spin_unlock(&ubi->volumes_lock);
-
ubi_volume_notify(ubi, vol, UBI_VOLUME_ADDED);
self_check_volumes(ubi);
return err;
@@ -315,6 +316,10 @@ int ubi_create_volume(struct ubi_device *ubi, struct ubi_mkvol_req *req)
*/
cdev_device_del(&vol->cdev, &vol->dev);
out_mapping:
+ spin_lock(&ubi->volumes_lock);
+ ubi->volumes[vol_id] = NULL;
+ ubi->vol_count -= 1;
+ spin_unlock(&ubi->volumes_lock);
ubi_eba_destroy_table(eba_tbl);
out_acc:
spin_lock(&ubi->volumes_lock);
Tree/Branch: v3.16.54
Git describe: v3.16.54
Commit: 0b9f4cdd4d Linux 3.16.54
Build Time: 34 min 32 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 9
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
1 warnings 0 mismatches : arm64-allnoconfig
3 warnings 0 mismatches : arm64-allmodconfig
1 warnings 0 mismatches : arm-multi_v5_defconfig
1 warnings 0 mismatches : arm-multi_v7_defconfig
1 warnings 0 mismatches : x86_64-defconfig
6 warnings 0 mismatches : arm-allmodconfig
1 warnings 0 mismatches : arm-allnoconfig
1 warnings 0 mismatches : x86_64-allnoconfig
3 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 9
7 ../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
2 ../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized]
2 ../drivers/net/ethernet/broadcom/genet/bcmgenet.c:2106:1: warning: label 'err_clk_disable' defined but not used [-Wunused-label]
2 ../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable]
1 ../drivers/platform/x86/eeepc-laptop.c:279:10: warning: 'value' may be used uninitialized in this function [-Wmaybe-uninitialized]
1 ../drivers/mtd/nand/omap2.c:1318:12: warning: 'omap_calculate_ecc_bch_multi' defined but not used [-Wunused-function]
1 ../drivers/media/platform/davinci/vpfe_capture.c:291:12: warning: 'vpfe_get_ccdc_image_format' defined but not used [-Wunused-function]
1 ../drivers/media/platform/davinci/vpfe_capture.c:1718:1: warning: label 'unlock_out' defined but not used [-Wunused-label]
1 ../arch/x86/kernel/cpu/common.c:1022:13: warning: 'syscall32_cpu_init' defined but not used [-Wunused-function]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable]
../drivers/net/ethernet/broadcom/genet/bcmgenet.c:2106:1: warning: label 'err_clk_disable' defined but not used [-Wunused-label]
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
-------------------------------------------------------------------------------
arm-multi_v5_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
-------------------------------------------------------------------------------
arm-multi_v7_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
-------------------------------------------------------------------------------
x86_64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../drivers/platform/x86/eeepc-laptop.c:279:10: warning: 'value' may be used uninitialized in this function [-Wmaybe-uninitialized]
-------------------------------------------------------------------------------
arm-allmodconfig : PASS, 0 errors, 6 warnings, 0 section mismatches
Warnings:
../drivers/mtd/nand/omap2.c:1318:12: warning: 'omap_calculate_ecc_bch_multi' defined but not used [-Wunused-function]
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
../drivers/media/platform/davinci/vpfe_capture.c:1718:1: warning: label 'unlock_out' defined but not used [-Wunused-label]
../drivers/media/platform/davinci/vpfe_capture.c:291:12: warning: 'vpfe_get_ccdc_image_format' defined but not used [-Wunused-function]
../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable]
../drivers/net/ethernet/broadcom/genet/bcmgenet.c:2106:1: warning: label 'err_clk_disable' defined but not used [-Wunused-label]
-------------------------------------------------------------------------------
arm-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
-------------------------------------------------------------------------------
x86_64-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../arch/x86/kernel/cpu/common.c:1022:13: warning: 'syscall32_cpu_init' defined but not used [-Wunused-function]
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 0 errors, 3 warnings, 0 section mismatches
Warnings:
../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized]
../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized]
../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
This is a note to let you know that I've just added the patch titled
[Variant 2/Spectre-v2] firmware/psci: Expose SMCCC version through psci_ops
to the 4.14-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:
firmware-psci-expose-smccc-version-through-psci_ops.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Tue, 6 Feb 2018 17:56:17 +0000
Subject: [Variant 2/Spectre-v2] firmware/psci: Expose SMCCC version through psci_ops
From: Marc Zyngier <marc.zyngier(a)arm.com>
Commit e78eef554a91 upstream.
Since PSCI 1.0 allows the SMCCC version to be (indirectly) probed,
let's do that at boot time, and expose the version of the calling
convention as part of the psci_ops structure.
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Reviewed-by: Robin Murphy <robin.murphy(a)arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/firmware/psci.c | 27 +++++++++++++++++++++++++++
include/linux/psci.h | 6 ++++++
2 files changed, 33 insertions(+)
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -61,6 +61,7 @@ bool psci_tos_resident_on(int cpu)
struct psci_operations psci_ops = {
.conduit = PSCI_CONDUIT_NONE,
+ .smccc_version = SMCCC_VERSION_1_0,
};
typedef unsigned long (psci_fn)(unsigned long, unsigned long,
@@ -511,6 +512,31 @@ static void __init psci_init_migrate(voi
pr_info("Trusted OS resident on physical CPU 0x%lx\n", cpuid);
}
+static void __init psci_init_smccc(void)
+{
+ u32 ver = ARM_SMCCC_VERSION_1_0;
+ int feature;
+
+ feature = psci_features(ARM_SMCCC_VERSION_FUNC_ID);
+
+ if (feature != PSCI_RET_NOT_SUPPORTED) {
+ u32 ret;
+ ret = invoke_psci_fn(ARM_SMCCC_VERSION_FUNC_ID, 0, 0, 0);
+ if (ret == ARM_SMCCC_VERSION_1_1) {
+ psci_ops.smccc_version = SMCCC_VERSION_1_1;
+ ver = ret;
+ }
+ }
+
+ /*
+ * Conveniently, the SMCCC and PSCI versions are encoded the
+ * same way. No, this isn't accidental.
+ */
+ pr_info("SMC Calling Convention v%d.%d\n",
+ PSCI_VERSION_MAJOR(ver), PSCI_VERSION_MINOR(ver));
+
+}
+
static void __init psci_0_2_set_functions(void)
{
pr_info("Using standard PSCI v0.2 function IDs\n");
@@ -559,6 +585,7 @@ static int __init psci_probe(void)
psci_init_migrate();
if (PSCI_VERSION_MAJOR(ver) >= 1) {
+ psci_init_smccc();
psci_init_cpu_suspend();
psci_init_system_suspend();
}
--- a/include/linux/psci.h
+++ b/include/linux/psci.h
@@ -31,6 +31,11 @@ enum psci_conduit {
PSCI_CONDUIT_HVC,
};
+enum smccc_version {
+ SMCCC_VERSION_1_0,
+ SMCCC_VERSION_1_1,
+};
+
struct psci_operations {
u32 (*get_version)(void);
int (*cpu_suspend)(u32 state, unsigned long entry_point);
@@ -41,6 +46,7 @@ struct psci_operations {
unsigned long lowest_affinity_level);
int (*migrate_info_type)(void);
enum psci_conduit conduit;
+ enum smccc_version smccc_version;
};
extern struct psci_operations psci_ops;
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.14/arm-arm64-smccc-make-function-identifiers-an-unsigned-quantity.patch
queue-4.14/arm64-move-bp-hardening-to-check_and_switch_context.patch
queue-4.14/arm-arm64-kvm-advertise-smccc-v1.1.patch
queue-4.14/arm64-move-post_ttbr_update_workaround-to-c-code.patch
queue-4.14/firmware-psci-expose-psci-conduit.patch
queue-4.14/arm64-force-kpti-to-be-disabled-on-cavium-thunderx.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-high-priority-synchronous-exceptions.patch
queue-4.14/arm64-kpti-fix-the-interaction-between-asid-switching-and-software-pan.patch
queue-4.14/firmware-psci-expose-smccc-version-through-psci_ops.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-affected-cortex-a-cpus.patch
queue-4.14/arm-arm64-kvm-add-psci_version-helper.patch
queue-4.14/arm64-kill-psci_get_version-as-a-variant-2-workaround.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-suspicious-interrupts-from-el0.patch
queue-4.14/arm64-capabilities-handle-duplicate-entries-for-a-capability.patch
queue-4.14/arm64-add-arm_smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm-arm64-kvm-turn-kvm_psci_version-into-a-static-inline.patch
queue-4.14/arm-arm64-kvm-implement-psci-1.0-support.patch
queue-4.14/arm64-kvm-add-smccc_arch_workaround_1-fast-handling.patch
queue-4.14/arm64-kvm-report-smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm-arm64-smccc-implement-smccc-v1.1-inline-primitive.patch
queue-4.14/arm64-idmap-use-awx-flags-for-.idmap.text-.pushsection-directives.patch
queue-4.14/arm64-kvm-make-psci_version-a-fast-path.patch
queue-4.14/arm64-cpufeature-__this_cpu_has_cap-shouldn-t-stop-early.patch
queue-4.14/arm64-kpti-add-enable-callback-to-remap-swapper-using-ng-mappings.patch
queue-4.14/arm-arm64-kvm-consolidate-the-psci-include-files.patch
queue-4.14/arm64-add-skeleton-to-harden-the-branch-predictor-against-aliasing-attacks.patch
queue-4.14/arm-arm64-kvm-add-smccc-accessors-to-psci-code.patch
queue-4.14/arm64-kvm-use-per-cpu-vector-when-bp-hardening-is-enabled.patch
queue-4.14/arm64-kvm-increment-pc-after-handling-an-smc-trap.patch
This is a note to let you know that I've just added the patch titled
[Variant 3/Meltdown] arm64: use RET instruction for exiting the trampoline
to the 4.14-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:
arm64-use-ret-instruction-for-exiting-the-trampoline.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Will Deacon <will.deacon(a)arm.com>
Date: Tue, 14 Nov 2017 16:15:59 +0000
Subject: [Variant 3/Meltdown] arm64: use RET instruction for exiting the trampoline
From: Will Deacon <will.deacon(a)arm.com>
Commit be04a6d1126b upstream.
Speculation attacks against the entry trampoline can potentially resteer
the speculative instruction stream through the indirect branch and into
arbitrary gadgets within the kernel.
This patch defends against these attacks by forcing a misprediction
through the return stack: a dummy BL instruction loads an entry into
the stack, so that the predicted program flow of the subsequent RET
instruction is to a branch-to-self instruction which is finally resolved
as a branch to the kernel vectors with speculation suppressed.
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/entry.S | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -981,6 +981,14 @@ alternative_else_nop_endif
.if \regsize == 64
msr tpidrro_el0, x30 // Restored in kernel_ventry
.endif
+ /*
+ * Defend against branch aliasing attacks by pushing a dummy
+ * entry onto the return stack and using a RET instruction to
+ * enter the full-fat kernel vectors.
+ */
+ bl 2f
+ b .
+2:
tramp_map_kernel x30
#ifdef CONFIG_RANDOMIZE_BASE
adr x30, tramp_vectors + PAGE_SIZE
@@ -993,7 +1001,7 @@ alternative_insn isb, nop, ARM64_WORKARO
msr vbar_el1, x30
add x30, x30, #(1b - tramp_vectors)
isb
- br x30
+ ret
.endm
.macro tramp_exit, regsize = 64
Patches currently in stable-queue which might be from will.deacon(a)arm.com are
queue-4.14/arm64-make-user_ds-an-inclusive-limit.patch
queue-4.14/arm64-mm-remove-pre_ttbr0_update_workaround-for-falkor-erratum-e1003.patch
queue-4.14/arm64-uaccess-don-t-bother-eliding-access_ok-checks-in-__-get-put-_user.patch
queue-4.14/arm64-cpufeature-pass-capability-structure-to-enable-callback.patch
queue-4.14/arm64-uaccess-mask-__user-pointers-for-__arch_-clear-copy_-_user.patch
queue-4.14/arm64-mm-add-arm64_kernel_unmapped_at_el0-helper.patch
queue-4.14/arm64-entry-reword-comment-about-post_ttbr_update_workaround.patch
queue-4.14/arm64-kaslr-put-kernel-vectors-address-in-separate-data-page.patch
queue-4.14/arm-arm64-smccc-make-function-identifiers-an-unsigned-quantity.patch
queue-4.14/arm64-move-bp-hardening-to-check_and_switch_context.patch
queue-4.14/arm-arm64-kvm-advertise-smccc-v1.1.patch
queue-4.14/arm64-move-post_ttbr_update_workaround-to-c-code.patch
queue-4.14/arm64-turn-on-kpti-only-on-cpus-that-need-it.patch
queue-4.14/firmware-psci-expose-psci-conduit.patch
queue-4.14/arm64-force-kpti-to-be-disabled-on-cavium-thunderx.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-high-priority-synchronous-exceptions.patch
queue-4.14/arm64-kpti-fix-the-interaction-between-asid-switching-and-software-pan.patch
queue-4.14/firmware-psci-expose-smccc-version-through-psci_ops.patch
queue-4.14/arm64-mm-permit-transitioning-from-global-to-non-global-without-bbm.patch
queue-4.14/arm64-mm-allocate-asids-in-pairs.patch
queue-4.14/arm64-tls-avoid-unconditional-zeroing-of-tpidrro_el0-for-native-tasks.patch
queue-4.14/arm64-use-ret-instruction-for-exiting-the-trampoline.patch
queue-4.14/arm64-futex-mask-__user-pointers-prior-to-dereference.patch
queue-4.14/arm64-entry-explicitly-pass-exception-level-to-kernel_ventry-macro.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-affected-cortex-a-cpus.patch
queue-4.14/arm64-kpti-make-use-of-ng-dependent-on-arm64_kernel_unmapped_at_el0.patch
queue-4.14/arm-arm64-kvm-add-psci_version-helper.patch
queue-4.14/arm64-kill-psci_get_version-as-a-variant-2-workaround.patch
queue-4.14/arm64-entry-ensure-branch-through-syscall-table-is-bounded-under-speculation.patch
queue-4.14/arm64-mm-use-non-global-mappings-for-kernel-space.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-suspicious-interrupts-from-el0.patch
queue-4.14/arm64-capabilities-handle-duplicate-entries-for-a-capability.patch
queue-4.14/arm64-entry-hook-up-entry-trampoline-to-exception-vectors.patch
queue-4.14/arm64-branch-predictor-hardening-for-cavium-thunderx2.patch
queue-4.14/arm64-uaccess-prevent-speculative-use-of-the-current-addr_limit.patch
queue-4.14/.arm64-add-software-workaround-for-falkor-erratum-1041.patch.swp
queue-4.14/arm64-use-pointer-masking-to-limit-uaccess-speculation.patch
queue-4.14/arm64-add-arm_smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm64-erratum-work-around-falkor-erratum-e1003-in-trampoline-code.patch
queue-4.14/arm64-mm-fix-and-re-enable-arm64_sw_ttbr0_pan.patch
queue-4.14/arm64-mm-invalidate-both-kernel-and-user-asids-when-performing-tlbi.patch
queue-4.14/drivers-firmware-expose-psci_get_version-through-psci_ops-structure.patch
queue-4.14/arm64-mm-rename-post_ttbr0_update_workaround.patch
queue-4.14/arm64-mm-map-entry-trampoline-into-trampoline-and-kernel-page-tables.patch
queue-4.14/arm-arm64-kvm-turn-kvm_psci_version-into-a-static-inline.patch
queue-4.14/arm-arm64-kvm-implement-psci-1.0-support.patch
queue-4.14/arm64-move-task_-definitions-to-asm-processor.h.patch
queue-4.14/arm64-kconfig-reword-unmap_kernel_at_el0-kconfig-entry.patch
queue-4.14/arm64-mm-move-asid-from-ttbr0-to-ttbr1.patch
queue-4.14/arm64-mm-introduce-ttbr_asid_mask-for-getting-at-the-asid-in-the-ttbr.patch
queue-4.14/arm64-kvm-add-smccc_arch_workaround_1-fast-handling.patch
queue-4.14/arm64-take-into-account-id_aa64pfr0_el1.csv3.patch
queue-4.14/arm64-cputype-add-missing-midr-values-for-cortex-a72-and-cortex-a75.patch
queue-4.14/arm64-kvm-report-smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm64-barrier-add-csdb-macros-to-control-data-value-prediction.patch
queue-4.14/arm-arm64-smccc-implement-smccc-v1.1-inline-primitive.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-falkor.patch
queue-4.14/arm64-kconfig-add-config_unmap_kernel_at_el0.patch
queue-4.14/arm64-add-software-workaround-for-falkor-erratum-1041.patch
queue-4.14/arm64-idmap-use-awx-flags-for-.idmap.text-.pushsection-directives.patch
queue-4.14/arm64-run-enable-method-for-errata-work-arounds-on-late-cpus.patch
queue-4.14/arm64-mm-temporarily-disable-arm64_sw_ttbr0_pan.patch
queue-4.14/arm64-entry-add-exception-trampoline-page-for-exceptions-from-el0.patch
queue-4.14/arm64-kvm-make-psci_version-a-fast-path.patch
queue-4.14/arm64-cpufeature-__this_cpu_has_cap-shouldn-t-stop-early.patch
queue-4.14/arm64-implement-array_index_mask_nospec.patch
queue-4.14/arm64-kpti-add-enable-callback-to-remap-swapper-using-ng-mappings.patch
queue-4.14/arm-arm64-kvm-consolidate-the-psci-include-files.patch
queue-4.14/arm64-add-skeleton-to-harden-the-branch-predictor-against-aliasing-attacks.patch
queue-4.14/arm64-define-cputype-macros-for-falkor-cpu.patch
queue-4.14/arm64-cpu_errata-add-kryo-to-falkor-1003-errata.patch
queue-4.14/arm-arm64-kvm-add-smccc-accessors-to-psci-code.patch
queue-4.14/arm64-entry-add-fake-cpu-feature-for-unmapping-the-kernel-at-el0.patch
queue-4.14/arm64-kvm-use-per-cpu-vector-when-bp-hardening-is-enabled.patch
queue-4.14/arm64-cputype-add-midr-values-for-cavium-thunderx2-cpus.patch
queue-4.14/arm64-kvm-increment-pc-after-handling-an-smc-trap.patch
This is a note to let you know that I've just added the patch titled
[Variant 2/Spectre-v2] drivers/firmware: Expose psci_get_version through psci_ops structure
to the 4.14-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:
drivers-firmware-expose-psci_get_version-through-psci_ops-structure.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Will Deacon <will.deacon(a)arm.com>
Date: Tue, 2 Jan 2018 21:45:41 +0000
Subject: [Variant 2/Spectre-v2] drivers/firmware: Expose psci_get_version through psci_ops structure
From: Will Deacon <will.deacon(a)arm.com>
Commit d68e3ba5303f upstream.
Entry into recent versions of ARM Trusted Firmware will invalidate the CPU
branch predictor state in order to protect against aliasing attacks.
This patch exposes the PSCI "VERSION" function via psci_ops, so that it
can be invoked outside of the PSCI driver where necessary.
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/firmware/psci.c | 2 ++
include/linux/psci.h | 1 +
2 files changed, 3 insertions(+)
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -496,6 +496,8 @@ static void __init psci_init_migrate(voi
static void __init psci_0_2_set_functions(void)
{
pr_info("Using standard PSCI v0.2 function IDs\n");
+ psci_ops.get_version = psci_get_version;
+
psci_function_id[PSCI_FN_CPU_SUSPEND] =
PSCI_FN_NATIVE(0_2, CPU_SUSPEND);
psci_ops.cpu_suspend = psci_cpu_suspend;
--- a/include/linux/psci.h
+++ b/include/linux/psci.h
@@ -26,6 +26,7 @@ int psci_cpu_init_idle(unsigned int cpu)
int psci_cpu_suspend_enter(unsigned long index);
struct psci_operations {
+ u32 (*get_version)(void);
int (*cpu_suspend)(u32 state, unsigned long entry_point);
int (*cpu_off)(u32 state);
int (*cpu_on)(unsigned long cpuid, unsigned long entry_point);
Patches currently in stable-queue which might be from will.deacon(a)arm.com are
queue-4.14/arm64-make-user_ds-an-inclusive-limit.patch
queue-4.14/arm64-mm-remove-pre_ttbr0_update_workaround-for-falkor-erratum-e1003.patch
queue-4.14/arm64-uaccess-don-t-bother-eliding-access_ok-checks-in-__-get-put-_user.patch
queue-4.14/arm64-cpufeature-pass-capability-structure-to-enable-callback.patch
queue-4.14/arm64-uaccess-mask-__user-pointers-for-__arch_-clear-copy_-_user.patch
queue-4.14/arm64-mm-add-arm64_kernel_unmapped_at_el0-helper.patch
queue-4.14/arm64-entry-reword-comment-about-post_ttbr_update_workaround.patch
queue-4.14/arm64-kaslr-put-kernel-vectors-address-in-separate-data-page.patch
queue-4.14/arm-arm64-smccc-make-function-identifiers-an-unsigned-quantity.patch
queue-4.14/arm64-move-bp-hardening-to-check_and_switch_context.patch
queue-4.14/arm-arm64-kvm-advertise-smccc-v1.1.patch
queue-4.14/arm64-move-post_ttbr_update_workaround-to-c-code.patch
queue-4.14/arm64-turn-on-kpti-only-on-cpus-that-need-it.patch
queue-4.14/firmware-psci-expose-psci-conduit.patch
queue-4.14/arm64-force-kpti-to-be-disabled-on-cavium-thunderx.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-high-priority-synchronous-exceptions.patch
queue-4.14/arm64-kpti-fix-the-interaction-between-asid-switching-and-software-pan.patch
queue-4.14/firmware-psci-expose-smccc-version-through-psci_ops.patch
queue-4.14/arm64-mm-permit-transitioning-from-global-to-non-global-without-bbm.patch
queue-4.14/arm64-mm-allocate-asids-in-pairs.patch
queue-4.14/arm64-tls-avoid-unconditional-zeroing-of-tpidrro_el0-for-native-tasks.patch
queue-4.14/arm64-use-ret-instruction-for-exiting-the-trampoline.patch
queue-4.14/arm64-futex-mask-__user-pointers-prior-to-dereference.patch
queue-4.14/arm64-entry-explicitly-pass-exception-level-to-kernel_ventry-macro.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-affected-cortex-a-cpus.patch
queue-4.14/arm64-kpti-make-use-of-ng-dependent-on-arm64_kernel_unmapped_at_el0.patch
queue-4.14/arm-arm64-kvm-add-psci_version-helper.patch
queue-4.14/arm64-kill-psci_get_version-as-a-variant-2-workaround.patch
queue-4.14/arm64-entry-ensure-branch-through-syscall-table-is-bounded-under-speculation.patch
queue-4.14/arm64-mm-use-non-global-mappings-for-kernel-space.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-suspicious-interrupts-from-el0.patch
queue-4.14/arm64-capabilities-handle-duplicate-entries-for-a-capability.patch
queue-4.14/arm64-entry-hook-up-entry-trampoline-to-exception-vectors.patch
queue-4.14/arm64-branch-predictor-hardening-for-cavium-thunderx2.patch
queue-4.14/arm64-uaccess-prevent-speculative-use-of-the-current-addr_limit.patch
queue-4.14/.arm64-add-software-workaround-for-falkor-erratum-1041.patch.swp
queue-4.14/arm64-use-pointer-masking-to-limit-uaccess-speculation.patch
queue-4.14/arm64-add-arm_smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm64-erratum-work-around-falkor-erratum-e1003-in-trampoline-code.patch
queue-4.14/arm64-mm-fix-and-re-enable-arm64_sw_ttbr0_pan.patch
queue-4.14/arm64-mm-invalidate-both-kernel-and-user-asids-when-performing-tlbi.patch
queue-4.14/drivers-firmware-expose-psci_get_version-through-psci_ops-structure.patch
queue-4.14/arm64-mm-rename-post_ttbr0_update_workaround.patch
queue-4.14/arm64-mm-map-entry-trampoline-into-trampoline-and-kernel-page-tables.patch
queue-4.14/arm-arm64-kvm-turn-kvm_psci_version-into-a-static-inline.patch
queue-4.14/arm-arm64-kvm-implement-psci-1.0-support.patch
queue-4.14/arm64-move-task_-definitions-to-asm-processor.h.patch
queue-4.14/arm64-kconfig-reword-unmap_kernel_at_el0-kconfig-entry.patch
queue-4.14/arm64-mm-move-asid-from-ttbr0-to-ttbr1.patch
queue-4.14/arm64-mm-introduce-ttbr_asid_mask-for-getting-at-the-asid-in-the-ttbr.patch
queue-4.14/arm64-kvm-add-smccc_arch_workaround_1-fast-handling.patch
queue-4.14/arm64-take-into-account-id_aa64pfr0_el1.csv3.patch
queue-4.14/arm64-cputype-add-missing-midr-values-for-cortex-a72-and-cortex-a75.patch
queue-4.14/arm64-kvm-report-smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm64-barrier-add-csdb-macros-to-control-data-value-prediction.patch
queue-4.14/arm-arm64-smccc-implement-smccc-v1.1-inline-primitive.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-falkor.patch
queue-4.14/arm64-kconfig-add-config_unmap_kernel_at_el0.patch
queue-4.14/arm64-add-software-workaround-for-falkor-erratum-1041.patch
queue-4.14/arm64-idmap-use-awx-flags-for-.idmap.text-.pushsection-directives.patch
queue-4.14/arm64-run-enable-method-for-errata-work-arounds-on-late-cpus.patch
queue-4.14/arm64-mm-temporarily-disable-arm64_sw_ttbr0_pan.patch
queue-4.14/arm64-entry-add-exception-trampoline-page-for-exceptions-from-el0.patch
queue-4.14/arm64-kvm-make-psci_version-a-fast-path.patch
queue-4.14/arm64-cpufeature-__this_cpu_has_cap-shouldn-t-stop-early.patch
queue-4.14/arm64-implement-array_index_mask_nospec.patch
queue-4.14/arm64-kpti-add-enable-callback-to-remap-swapper-using-ng-mappings.patch
queue-4.14/arm-arm64-kvm-consolidate-the-psci-include-files.patch
queue-4.14/arm64-add-skeleton-to-harden-the-branch-predictor-against-aliasing-attacks.patch
queue-4.14/arm64-define-cputype-macros-for-falkor-cpu.patch
queue-4.14/arm64-cpu_errata-add-kryo-to-falkor-1003-errata.patch
queue-4.14/arm-arm64-kvm-add-smccc-accessors-to-psci-code.patch
queue-4.14/arm64-entry-add-fake-cpu-feature-for-unmapping-the-kernel-at-el0.patch
queue-4.14/arm64-kvm-use-per-cpu-vector-when-bp-hardening-is-enabled.patch
queue-4.14/arm64-cputype-add-midr-values-for-cavium-thunderx2-cpus.patch
queue-4.14/arm64-kvm-increment-pc-after-handling-an-smc-trap.patch
This is a note to let you know that I've just added the patch titled
[Variant 1/Spectre-v1] arm64: uaccess: Prevent speculative use of the current addr_limit
to the 4.14-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:
arm64-uaccess-prevent-speculative-use-of-the-current-addr_limit.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Will Deacon <will.deacon(a)arm.com>
Date: Mon, 5 Feb 2018 15:34:21 +0000
Subject: [Variant 1/Spectre-v1] arm64: uaccess: Prevent speculative use of the current addr_limit
From: Will Deacon <will.deacon(a)arm.com>
Commit c2f0ad4fc089 upstream.
A mispredicted conditional call to set_fs could result in the wrong
addr_limit being forwarded under speculation to a subsequent access_ok
check, potentially forming part of a spectre-v1 attack using uaccess
routines.
This patch prevents this forwarding from taking place, but putting heavy
barriers in set_fs after writing the addr_limit.
Reviewed-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/uaccess.h | 7 +++++++
1 file changed, 7 insertions(+)
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -42,6 +42,13 @@ static inline void set_fs(mm_segment_t f
{
current_thread_info()->addr_limit = fs;
+ /*
+ * Prevent a mispredicted conditional call to set_fs from forwarding
+ * the wrong address limit to access_ok under speculation.
+ */
+ dsb(nsh);
+ isb();
+
/* On user-mode return, check fs is correct */
set_thread_flag(TIF_FSCHECK);
Patches currently in stable-queue which might be from will.deacon(a)arm.com are
queue-4.14/arm64-make-user_ds-an-inclusive-limit.patch
queue-4.14/arm64-mm-remove-pre_ttbr0_update_workaround-for-falkor-erratum-e1003.patch
queue-4.14/arm64-uaccess-don-t-bother-eliding-access_ok-checks-in-__-get-put-_user.patch
queue-4.14/arm64-cpufeature-pass-capability-structure-to-enable-callback.patch
queue-4.14/arm64-uaccess-mask-__user-pointers-for-__arch_-clear-copy_-_user.patch
queue-4.14/arm64-mm-add-arm64_kernel_unmapped_at_el0-helper.patch
queue-4.14/arm64-entry-reword-comment-about-post_ttbr_update_workaround.patch
queue-4.14/arm64-kaslr-put-kernel-vectors-address-in-separate-data-page.patch
queue-4.14/arm-arm64-smccc-make-function-identifiers-an-unsigned-quantity.patch
queue-4.14/arm64-move-bp-hardening-to-check_and_switch_context.patch
queue-4.14/arm-arm64-kvm-advertise-smccc-v1.1.patch
queue-4.14/arm64-move-post_ttbr_update_workaround-to-c-code.patch
queue-4.14/arm64-turn-on-kpti-only-on-cpus-that-need-it.patch
queue-4.14/firmware-psci-expose-psci-conduit.patch
queue-4.14/arm64-force-kpti-to-be-disabled-on-cavium-thunderx.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-high-priority-synchronous-exceptions.patch
queue-4.14/arm64-kpti-fix-the-interaction-between-asid-switching-and-software-pan.patch
queue-4.14/firmware-psci-expose-smccc-version-through-psci_ops.patch
queue-4.14/arm64-mm-permit-transitioning-from-global-to-non-global-without-bbm.patch
queue-4.14/arm64-mm-allocate-asids-in-pairs.patch
queue-4.14/arm64-tls-avoid-unconditional-zeroing-of-tpidrro_el0-for-native-tasks.patch
queue-4.14/arm64-use-ret-instruction-for-exiting-the-trampoline.patch
queue-4.14/arm64-futex-mask-__user-pointers-prior-to-dereference.patch
queue-4.14/arm64-entry-explicitly-pass-exception-level-to-kernel_ventry-macro.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-affected-cortex-a-cpus.patch
queue-4.14/arm64-kpti-make-use-of-ng-dependent-on-arm64_kernel_unmapped_at_el0.patch
queue-4.14/arm-arm64-kvm-add-psci_version-helper.patch
queue-4.14/arm64-kill-psci_get_version-as-a-variant-2-workaround.patch
queue-4.14/arm64-entry-ensure-branch-through-syscall-table-is-bounded-under-speculation.patch
queue-4.14/arm64-mm-use-non-global-mappings-for-kernel-space.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-suspicious-interrupts-from-el0.patch
queue-4.14/arm64-capabilities-handle-duplicate-entries-for-a-capability.patch
queue-4.14/arm64-entry-hook-up-entry-trampoline-to-exception-vectors.patch
queue-4.14/arm64-branch-predictor-hardening-for-cavium-thunderx2.patch
queue-4.14/arm64-uaccess-prevent-speculative-use-of-the-current-addr_limit.patch
queue-4.14/.arm64-add-software-workaround-for-falkor-erratum-1041.patch.swp
queue-4.14/arm64-use-pointer-masking-to-limit-uaccess-speculation.patch
queue-4.14/arm64-add-arm_smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm64-erratum-work-around-falkor-erratum-e1003-in-trampoline-code.patch
queue-4.14/arm64-mm-fix-and-re-enable-arm64_sw_ttbr0_pan.patch
queue-4.14/arm64-mm-invalidate-both-kernel-and-user-asids-when-performing-tlbi.patch
queue-4.14/drivers-firmware-expose-psci_get_version-through-psci_ops-structure.patch
queue-4.14/arm64-mm-rename-post_ttbr0_update_workaround.patch
queue-4.14/arm64-mm-map-entry-trampoline-into-trampoline-and-kernel-page-tables.patch
queue-4.14/arm-arm64-kvm-turn-kvm_psci_version-into-a-static-inline.patch
queue-4.14/arm-arm64-kvm-implement-psci-1.0-support.patch
queue-4.14/arm64-move-task_-definitions-to-asm-processor.h.patch
queue-4.14/arm64-kconfig-reword-unmap_kernel_at_el0-kconfig-entry.patch
queue-4.14/arm64-mm-move-asid-from-ttbr0-to-ttbr1.patch
queue-4.14/arm64-mm-introduce-ttbr_asid_mask-for-getting-at-the-asid-in-the-ttbr.patch
queue-4.14/arm64-kvm-add-smccc_arch_workaround_1-fast-handling.patch
queue-4.14/arm64-take-into-account-id_aa64pfr0_el1.csv3.patch
queue-4.14/arm64-cputype-add-missing-midr-values-for-cortex-a72-and-cortex-a75.patch
queue-4.14/arm64-kvm-report-smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm64-barrier-add-csdb-macros-to-control-data-value-prediction.patch
queue-4.14/arm-arm64-smccc-implement-smccc-v1.1-inline-primitive.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-falkor.patch
queue-4.14/arm64-kconfig-add-config_unmap_kernel_at_el0.patch
queue-4.14/arm64-add-software-workaround-for-falkor-erratum-1041.patch
queue-4.14/arm64-idmap-use-awx-flags-for-.idmap.text-.pushsection-directives.patch
queue-4.14/arm64-run-enable-method-for-errata-work-arounds-on-late-cpus.patch
queue-4.14/arm64-mm-temporarily-disable-arm64_sw_ttbr0_pan.patch
queue-4.14/arm64-entry-add-exception-trampoline-page-for-exceptions-from-el0.patch
queue-4.14/arm64-kvm-make-psci_version-a-fast-path.patch
queue-4.14/arm64-cpufeature-__this_cpu_has_cap-shouldn-t-stop-early.patch
queue-4.14/arm64-implement-array_index_mask_nospec.patch
queue-4.14/arm64-kpti-add-enable-callback-to-remap-swapper-using-ng-mappings.patch
queue-4.14/arm-arm64-kvm-consolidate-the-psci-include-files.patch
queue-4.14/arm64-add-skeleton-to-harden-the-branch-predictor-against-aliasing-attacks.patch
queue-4.14/arm64-define-cputype-macros-for-falkor-cpu.patch
queue-4.14/arm64-cpu_errata-add-kryo-to-falkor-1003-errata.patch
queue-4.14/arm-arm64-kvm-add-smccc-accessors-to-psci-code.patch
queue-4.14/arm64-entry-add-fake-cpu-feature-for-unmapping-the-kernel-at-el0.patch
queue-4.14/arm64-kvm-use-per-cpu-vector-when-bp-hardening-is-enabled.patch
queue-4.14/arm64-cputype-add-midr-values-for-cavium-thunderx2-cpus.patch
queue-4.14/arm64-kvm-increment-pc-after-handling-an-smc-trap.patch
This is a note to let you know that I've just added the patch titled
[Variant 1/Spectre-v1] arm64: Use pointer masking to limit uaccess speculation
to the 4.14-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:
arm64-use-pointer-masking-to-limit-uaccess-speculation.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Robin Murphy <robin.murphy(a)arm.com>
Date: Mon, 5 Feb 2018 15:34:19 +0000
Subject: [Variant 1/Spectre-v1] arm64: Use pointer masking to limit uaccess speculation
From: Robin Murphy <robin.murphy(a)arm.com>
Commit 4d8efc2d5ee4 upstream.
Similarly to x86, mitigate speculation past an access_ok() check by
masking the pointer against the address limit before use.
Even if we don't expect speculative writes per se, it is plausible that
a CPU may still speculate at least as far as fetching a cache line for
writing, hence we also harden put_user() and clear_user() for peace of
mind.
Signed-off-by: Robin Murphy <robin.murphy(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/uaccess.h | 26 +++++++++++++++++++++++---
1 file changed, 23 insertions(+), 3 deletions(-)
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -216,6 +216,26 @@ static inline void uaccess_enable_not_ua
}
/*
+ * Sanitise a uaccess pointer such that it becomes NULL if above the
+ * current addr_limit.
+ */
+#define uaccess_mask_ptr(ptr) (__typeof__(ptr))__uaccess_mask_ptr(ptr)
+static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
+{
+ void __user *safe_ptr;
+
+ asm volatile(
+ " bics xzr, %1, %2\n"
+ " csel %0, %1, xzr, eq\n"
+ : "=&r" (safe_ptr)
+ : "r" (ptr), "r" (current_thread_info()->addr_limit)
+ : "cc");
+
+ csdb();
+ return safe_ptr;
+}
+
+/*
* The "__xxx" versions of the user access functions do not verify the address
* space - it must have been done previously with a separate "access_ok()"
* call.
@@ -285,7 +305,7 @@ do { \
__typeof__(*(ptr)) __user *__p = (ptr); \
might_fault(); \
access_ok(VERIFY_READ, __p, sizeof(*__p)) ? \
- __get_user((x), __p) : \
+ __p = uaccess_mask_ptr(__p), __get_user((x), __p) : \
((x) = 0, -EFAULT); \
})
@@ -349,7 +369,7 @@ do { \
__typeof__(*(ptr)) __user *__p = (ptr); \
might_fault(); \
access_ok(VERIFY_WRITE, __p, sizeof(*__p)) ? \
- __put_user((x), __p) : \
+ __p = uaccess_mask_ptr(__p), __put_user((x), __p) : \
-EFAULT; \
})
@@ -365,7 +385,7 @@ extern unsigned long __must_check __clea
static inline unsigned long __must_check clear_user(void __user *to, unsigned long n)
{
if (access_ok(VERIFY_WRITE, to, n))
- n = __clear_user(to, n);
+ n = __clear_user(__uaccess_mask_ptr(to), n);
return n;
}
Patches currently in stable-queue which might be from robin.murphy(a)arm.com are
queue-4.14/arm64-make-user_ds-an-inclusive-limit.patch
queue-4.14/arm64-uaccess-don-t-bother-eliding-access_ok-checks-in-__-get-put-_user.patch
queue-4.14/arm-arm64-smccc-make-function-identifiers-an-unsigned-quantity.patch
queue-4.14/firmware-psci-expose-psci-conduit.patch
queue-4.14/firmware-psci-expose-smccc-version-through-psci_ops.patch
queue-4.14/arm64-use-pointer-masking-to-limit-uaccess-speculation.patch
queue-4.14/arm-arm64-smccc-implement-smccc-v1.1-inline-primitive.patch
queue-4.14/arm64-implement-array_index_mask_nospec.patch
This is a note to let you know that I've just added the patch titled
[Variant 3/Meltdown] arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks
to the 4.14-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:
arm64-tls-avoid-unconditional-zeroing-of-tpidrro_el0-for-native-tasks.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Will Deacon <will.deacon(a)arm.com>
Date: Tue, 14 Nov 2017 14:33:28 +0000
Subject: [Variant 3/Meltdown] arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks
From: Will Deacon <will.deacon(a)arm.com>
Commit 18011eac28c7 upstream.
When unmapping the kernel at EL0, we use tpidrro_el0 as a scratch register
during exception entry from native tasks and subsequently zero it in
the kernel_ventry macro. We can therefore avoid zeroing tpidrro_el0
in the context-switch path for native tasks using the entry trampoline.
Reviewed-by: Mark Rutland <mark.rutland(a)arm.com>
Tested-by: Laura Abbott <labbott(a)redhat.com>
Tested-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/process.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -314,16 +314,14 @@ void tls_preserve_current_state(void)
static void tls_thread_switch(struct task_struct *next)
{
- unsigned long tpidr, tpidrro;
-
tls_preserve_current_state();
- tpidr = *task_user_tls(next);
- tpidrro = is_compat_thread(task_thread_info(next)) ?
- next->thread.tp_value : 0;
+ if (is_compat_thread(task_thread_info(next)))
+ write_sysreg(next->thread.tp_value, tpidrro_el0);
+ else if (!arm64_kernel_unmapped_at_el0())
+ write_sysreg(0, tpidrro_el0);
- write_sysreg(tpidr, tpidr_el0);
- write_sysreg(tpidrro, tpidrro_el0);
+ write_sysreg(*task_user_tls(next), tpidr_el0);
}
/* Restore the UAO state depending on next's addr_limit */
Patches currently in stable-queue which might be from will.deacon(a)arm.com are
queue-4.14/arm64-make-user_ds-an-inclusive-limit.patch
queue-4.14/arm64-mm-remove-pre_ttbr0_update_workaround-for-falkor-erratum-e1003.patch
queue-4.14/arm64-uaccess-don-t-bother-eliding-access_ok-checks-in-__-get-put-_user.patch
queue-4.14/arm64-cpufeature-pass-capability-structure-to-enable-callback.patch
queue-4.14/arm64-uaccess-mask-__user-pointers-for-__arch_-clear-copy_-_user.patch
queue-4.14/arm64-mm-add-arm64_kernel_unmapped_at_el0-helper.patch
queue-4.14/arm64-entry-reword-comment-about-post_ttbr_update_workaround.patch
queue-4.14/arm64-kaslr-put-kernel-vectors-address-in-separate-data-page.patch
queue-4.14/arm-arm64-smccc-make-function-identifiers-an-unsigned-quantity.patch
queue-4.14/arm64-move-bp-hardening-to-check_and_switch_context.patch
queue-4.14/arm-arm64-kvm-advertise-smccc-v1.1.patch
queue-4.14/arm64-move-post_ttbr_update_workaround-to-c-code.patch
queue-4.14/arm64-turn-on-kpti-only-on-cpus-that-need-it.patch
queue-4.14/firmware-psci-expose-psci-conduit.patch
queue-4.14/arm64-force-kpti-to-be-disabled-on-cavium-thunderx.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-high-priority-synchronous-exceptions.patch
queue-4.14/arm64-kpti-fix-the-interaction-between-asid-switching-and-software-pan.patch
queue-4.14/firmware-psci-expose-smccc-version-through-psci_ops.patch
queue-4.14/arm64-mm-permit-transitioning-from-global-to-non-global-without-bbm.patch
queue-4.14/arm64-mm-allocate-asids-in-pairs.patch
queue-4.14/arm64-tls-avoid-unconditional-zeroing-of-tpidrro_el0-for-native-tasks.patch
queue-4.14/arm64-use-ret-instruction-for-exiting-the-trampoline.patch
queue-4.14/arm64-futex-mask-__user-pointers-prior-to-dereference.patch
queue-4.14/arm64-entry-explicitly-pass-exception-level-to-kernel_ventry-macro.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-affected-cortex-a-cpus.patch
queue-4.14/arm64-kpti-make-use-of-ng-dependent-on-arm64_kernel_unmapped_at_el0.patch
queue-4.14/arm-arm64-kvm-add-psci_version-helper.patch
queue-4.14/arm64-kill-psci_get_version-as-a-variant-2-workaround.patch
queue-4.14/arm64-entry-ensure-branch-through-syscall-table-is-bounded-under-speculation.patch
queue-4.14/arm64-mm-use-non-global-mappings-for-kernel-space.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-suspicious-interrupts-from-el0.patch
queue-4.14/arm64-capabilities-handle-duplicate-entries-for-a-capability.patch
queue-4.14/arm64-entry-hook-up-entry-trampoline-to-exception-vectors.patch
queue-4.14/arm64-branch-predictor-hardening-for-cavium-thunderx2.patch
queue-4.14/arm64-uaccess-prevent-speculative-use-of-the-current-addr_limit.patch
queue-4.14/.arm64-add-software-workaround-for-falkor-erratum-1041.patch.swp
queue-4.14/arm64-use-pointer-masking-to-limit-uaccess-speculation.patch
queue-4.14/arm64-add-arm_smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm64-erratum-work-around-falkor-erratum-e1003-in-trampoline-code.patch
queue-4.14/arm64-mm-fix-and-re-enable-arm64_sw_ttbr0_pan.patch
queue-4.14/arm64-mm-invalidate-both-kernel-and-user-asids-when-performing-tlbi.patch
queue-4.14/drivers-firmware-expose-psci_get_version-through-psci_ops-structure.patch
queue-4.14/arm64-mm-rename-post_ttbr0_update_workaround.patch
queue-4.14/arm64-mm-map-entry-trampoline-into-trampoline-and-kernel-page-tables.patch
queue-4.14/arm-arm64-kvm-turn-kvm_psci_version-into-a-static-inline.patch
queue-4.14/arm-arm64-kvm-implement-psci-1.0-support.patch
queue-4.14/arm64-move-task_-definitions-to-asm-processor.h.patch
queue-4.14/arm64-kconfig-reword-unmap_kernel_at_el0-kconfig-entry.patch
queue-4.14/arm64-mm-move-asid-from-ttbr0-to-ttbr1.patch
queue-4.14/arm64-mm-introduce-ttbr_asid_mask-for-getting-at-the-asid-in-the-ttbr.patch
queue-4.14/arm64-kvm-add-smccc_arch_workaround_1-fast-handling.patch
queue-4.14/arm64-take-into-account-id_aa64pfr0_el1.csv3.patch
queue-4.14/arm64-cputype-add-missing-midr-values-for-cortex-a72-and-cortex-a75.patch
queue-4.14/arm64-kvm-report-smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm64-barrier-add-csdb-macros-to-control-data-value-prediction.patch
queue-4.14/arm-arm64-smccc-implement-smccc-v1.1-inline-primitive.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-falkor.patch
queue-4.14/arm64-kconfig-add-config_unmap_kernel_at_el0.patch
queue-4.14/arm64-add-software-workaround-for-falkor-erratum-1041.patch
queue-4.14/arm64-idmap-use-awx-flags-for-.idmap.text-.pushsection-directives.patch
queue-4.14/arm64-run-enable-method-for-errata-work-arounds-on-late-cpus.patch
queue-4.14/arm64-mm-temporarily-disable-arm64_sw_ttbr0_pan.patch
queue-4.14/arm64-entry-add-exception-trampoline-page-for-exceptions-from-el0.patch
queue-4.14/arm64-kvm-make-psci_version-a-fast-path.patch
queue-4.14/arm64-cpufeature-__this_cpu_has_cap-shouldn-t-stop-early.patch
queue-4.14/arm64-implement-array_index_mask_nospec.patch
queue-4.14/arm64-kpti-add-enable-callback-to-remap-swapper-using-ng-mappings.patch
queue-4.14/arm-arm64-kvm-consolidate-the-psci-include-files.patch
queue-4.14/arm64-add-skeleton-to-harden-the-branch-predictor-against-aliasing-attacks.patch
queue-4.14/arm64-define-cputype-macros-for-falkor-cpu.patch
queue-4.14/arm64-cpu_errata-add-kryo-to-falkor-1003-errata.patch
queue-4.14/arm-arm64-kvm-add-smccc-accessors-to-psci-code.patch
queue-4.14/arm64-entry-add-fake-cpu-feature-for-unmapping-the-kernel-at-el0.patch
queue-4.14/arm64-kvm-use-per-cpu-vector-when-bp-hardening-is-enabled.patch
queue-4.14/arm64-cputype-add-midr-values-for-cavium-thunderx2-cpus.patch
queue-4.14/arm64-kvm-increment-pc-after-handling-an-smc-trap.patch
This is a note to let you know that I've just added the patch titled
[Variant 3/Meltdown] arm64: Turn on KPTI only on CPUs that need it
to the 4.14-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:
arm64-turn-on-kpti-only-on-cpus-that-need-it.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Jayachandran C <jnair(a)caviumnetworks.com>
Date: Fri, 19 Jan 2018 04:22:48 -0800
Subject: [Variant 3/Meltdown] arm64: Turn on KPTI only on CPUs that need it
From: Jayachandran C <jnair(a)caviumnetworks.com>
Commit 0ba2e29c7fc1 upstream.
Whitelist Broadcom Vulcan/Cavium ThunderX2 processors in
unmap_kernel_at_el0(). These CPUs are not vulnerable to
CVE-2017-5754 and do not need KPTI when KASLR is off.
Acked-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Jayachandran C <jnair(a)caviumnetworks.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/cpufeature.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -816,6 +816,13 @@ static bool unmap_kernel_at_el0(const st
if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
return true;
+ /* Don't force KPTI for CPUs that are not vulnerable */
+ switch (read_cpuid_id() & MIDR_CPU_MODEL_MASK) {
+ case MIDR_CAVIUM_THUNDERX2:
+ case MIDR_BRCM_VULCAN:
+ return false;
+ }
+
/* Defer to CPU feature registers */
return !cpuid_feature_extract_unsigned_field(pfr0,
ID_AA64PFR0_CSV3_SHIFT);
Patches currently in stable-queue which might be from jnair(a)caviumnetworks.com are
queue-4.14/arm64-turn-on-kpti-only-on-cpus-that-need-it.patch
queue-4.14/arm64-branch-predictor-hardening-for-cavium-thunderx2.patch
queue-4.14/arm64-cputype-add-midr-values-for-cavium-thunderx2-cpus.patch
This is a note to let you know that I've just added the patch titled
[Variant 2/Spectre-v2] arm64: Run enable method for errata work arounds on late CPUs
to the 4.14-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:
arm64-run-enable-method-for-errata-work-arounds-on-late-cpus.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Date: Wed, 17 Jan 2018 17:42:20 +0000
Subject: [Variant 2/Spectre-v2] arm64: Run enable method for errata work arounds on late CPUs
From: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Commit 55b35d070c25 upstream.
When a CPU is brought up after we have finalised the system
wide capabilities (i.e, features and errata), we make sure the
new CPU doesn't need a new errata work around which has not been
detected already. However we don't run enable() method on the new
CPU for the errata work arounds already detected. This could
cause the new CPU running without potential work arounds.
It is upto the "enable()" method to decide if this CPU should
do something about the errata.
Fixes: commit 6a6efbb45b7d95c84 ("arm64: Verify CPU errata work arounds on hotplugged CPU")
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: Mark Rutland <mark.rutland(a)arm.com>
Cc: Andre Przywara <andre.przywara(a)arm.com>
Cc: Dave Martin <dave.martin(a)arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/kernel/cpu_errata.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -221,15 +221,18 @@ void verify_local_cpu_errata_workarounds
{
const struct arm64_cpu_capabilities *caps = arm64_errata;
- for (; caps->matches; caps++)
- if (!cpus_have_cap(caps->capability) &&
- caps->matches(caps, SCOPE_LOCAL_CPU)) {
+ for (; caps->matches; caps++) {
+ if (cpus_have_cap(caps->capability)) {
+ if (caps->enable)
+ caps->enable((void *)caps);
+ } else if (caps->matches(caps, SCOPE_LOCAL_CPU)) {
pr_crit("CPU%d: Requires work around for %s, not detected"
" at boot time\n",
smp_processor_id(),
caps->desc ? : "an erratum");
cpu_die_early();
}
+ }
}
void update_cpu_errata_workarounds(void)
Patches currently in stable-queue which might be from suzuki.poulose(a)arm.com are
queue-4.14/arm64-cpufeature-pass-capability-structure-to-enable-callback.patch
queue-4.14/arm64-capabilities-handle-duplicate-entries-for-a-capability.patch
queue-4.14/arm64-take-into-account-id_aa64pfr0_el1.csv3.patch
queue-4.14/arm64-run-enable-method-for-errata-work-arounds-on-late-cpus.patch
queue-4.14/arm64-cpufeature-__this_cpu_has_cap-shouldn-t-stop-early.patch
This is a note to let you know that I've just added the patch titled
[Variant 2/Spectre-v2] arm64: Move post_ttbr_update_workaround to C code
to the 4.14-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:
arm64-move-post_ttbr_update_workaround-to-c-code.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Tue, 2 Jan 2018 18:19:39 +0000
Subject: [Variant 2/Spectre-v2] arm64: Move post_ttbr_update_workaround to C code
From: Marc Zyngier <marc.zyngier(a)arm.com>
Commit 95e3de3590e3 upstream.
We will soon need to invoke a CPU-specific function pointer after changing
page tables, so move post_ttbr_update_workaround out into C code to make
this possible.
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/assembler.h | 23 -----------------------
arch/arm64/kernel/entry.S | 2 +-
arch/arm64/mm/context.c | 9 +++++++++
arch/arm64/mm/proc.S | 3 +--
4 files changed, 11 insertions(+), 26 deletions(-)
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -481,29 +481,6 @@ alternative_endif
mrs \rd, sp_el0
.endm
-/*
- * Errata workaround post TTBRx_EL1 update.
- */
- .macro post_ttbr_update_workaround
-#ifdef CONFIG_CAVIUM_ERRATUM_27456
-alternative_if ARM64_WORKAROUND_CAVIUM_27456
- ic iallu
- dsb nsh
- isb
-alternative_else_nop_endif
-#endif
- .endm
-
-/**
- * Errata workaround prior to disable MMU. Insert an ISB immediately prior
- * to executing the MSR that will change SCTLR_ELn[M] from a value of 1 to 0.
- */
- .macro pre_disable_mmu_workaround
-#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1041
- isb
-#endif
- .endm
-
.macro pte_to_phys, phys, pte
and \phys, \pte, #(((1 << (48 - PAGE_SHIFT)) - 1) << PAGE_SHIFT)
.endm
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -275,7 +275,7 @@ alternative_else_nop_endif
* Cavium erratum 27456 (broadcast TLBI instructions may cause I-cache
* corruption).
*/
- post_ttbr_update_workaround
+ bl post_ttbr_update_workaround
.endif
1:
.if \el != 0
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -235,6 +235,15 @@ switch_mm_fastpath:
cpu_switch_mm(mm->pgd, mm);
}
+/* Errata workaround post TTBRx_EL1 update. */
+asmlinkage void post_ttbr_update_workaround(void)
+{
+ asm(ALTERNATIVE("nop; nop; nop",
+ "ic iallu; dsb nsh; isb",
+ ARM64_WORKAROUND_CAVIUM_27456,
+ CONFIG_CAVIUM_ERRATUM_27456));
+}
+
static int asids_init(void)
{
asid_bits = get_cpu_asid_bits();
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -148,8 +148,7 @@ ENTRY(cpu_do_switch_mm)
isb
msr ttbr0_el1, x0 // now update TTBR0
isb
- post_ttbr_update_workaround
- ret
+ b post_ttbr_update_workaround // Back to C code...
ENDPROC(cpu_do_switch_mm)
.pushsection ".idmap.text", "awx"
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.14/arm-arm64-smccc-make-function-identifiers-an-unsigned-quantity.patch
queue-4.14/arm64-move-bp-hardening-to-check_and_switch_context.patch
queue-4.14/arm-arm64-kvm-advertise-smccc-v1.1.patch
queue-4.14/arm64-move-post_ttbr_update_workaround-to-c-code.patch
queue-4.14/firmware-psci-expose-psci-conduit.patch
queue-4.14/arm64-force-kpti-to-be-disabled-on-cavium-thunderx.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-high-priority-synchronous-exceptions.patch
queue-4.14/arm64-kpti-fix-the-interaction-between-asid-switching-and-software-pan.patch
queue-4.14/firmware-psci-expose-smccc-version-through-psci_ops.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-affected-cortex-a-cpus.patch
queue-4.14/arm-arm64-kvm-add-psci_version-helper.patch
queue-4.14/arm64-kill-psci_get_version-as-a-variant-2-workaround.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-suspicious-interrupts-from-el0.patch
queue-4.14/arm64-capabilities-handle-duplicate-entries-for-a-capability.patch
queue-4.14/arm64-add-arm_smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm-arm64-kvm-turn-kvm_psci_version-into-a-static-inline.patch
queue-4.14/arm-arm64-kvm-implement-psci-1.0-support.patch
queue-4.14/arm64-kvm-add-smccc_arch_workaround_1-fast-handling.patch
queue-4.14/arm64-kvm-report-smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm-arm64-smccc-implement-smccc-v1.1-inline-primitive.patch
queue-4.14/arm64-idmap-use-awx-flags-for-.idmap.text-.pushsection-directives.patch
queue-4.14/arm64-kvm-make-psci_version-a-fast-path.patch
queue-4.14/arm64-cpufeature-__this_cpu_has_cap-shouldn-t-stop-early.patch
queue-4.14/arm64-kpti-add-enable-callback-to-remap-swapper-using-ng-mappings.patch
queue-4.14/arm-arm64-kvm-consolidate-the-psci-include-files.patch
queue-4.14/arm64-add-skeleton-to-harden-the-branch-predictor-against-aliasing-attacks.patch
queue-4.14/arm-arm64-kvm-add-smccc-accessors-to-psci-code.patch
queue-4.14/arm64-kvm-use-per-cpu-vector-when-bp-hardening-is-enabled.patch
queue-4.14/arm64-kvm-increment-pc-after-handling-an-smc-trap.patch
This is a note to let you know that I've just added the patch titled
arm64: move TASK_* definitions to <asm/processor.h>
to the 4.14-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:
arm64-move-task_-definitions-to-asm-processor.h.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Yury Norov <ynorov(a)caviumnetworks.com>
Date: Thu, 31 Aug 2017 11:30:50 +0300
Subject: arm64: move TASK_* definitions to <asm/processor.h>
From: Yury Norov <ynorov(a)caviumnetworks.com>
Commit eef94a3d09aa upstream.
ILP32 series [1] introduces the dependency on <asm/is_compat.h> for
TASK_SIZE macro. Which in turn requires <asm/thread_info.h>, and
<asm/thread_info.h> include <asm/memory.h>, giving a circular dependency,
because TASK_SIZE is currently located in <asm/memory.h>.
In other architectures, TASK_SIZE is defined in <asm/processor.h>, and
moving TASK_SIZE there fixes the problem.
Discussion: https://patchwork.kernel.org/patch/9929107/
[1] https://github.com/norov/linux/tree/ilp32-next
CC: Will Deacon <will.deacon(a)arm.com>
CC: Laura Abbott <labbott(a)redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: James Morse <james.morse(a)arm.com>
Suggested-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Yury Norov <ynorov(a)caviumnetworks.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/memory.h | 15 ---------------
arch/arm64/include/asm/processor.h | 21 +++++++++++++++++++++
arch/arm64/kernel/entry.S | 2 +-
3 files changed, 22 insertions(+), 16 deletions(-)
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -61,8 +61,6 @@
* KIMAGE_VADDR - the virtual address of the start of the kernel image
* VA_BITS - the maximum number of bits for virtual addresses.
* VA_START - the first kernel virtual address.
- * TASK_SIZE - the maximum size of a user space task.
- * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
*/
#define VA_BITS (CONFIG_ARM64_VA_BITS)
#define VA_START (UL(0xffffffffffffffff) - \
@@ -77,19 +75,6 @@
#define PCI_IO_END (VMEMMAP_START - SZ_2M)
#define PCI_IO_START (PCI_IO_END - PCI_IO_SIZE)
#define FIXADDR_TOP (PCI_IO_START - SZ_2M)
-#define TASK_SIZE_64 (UL(1) << VA_BITS)
-
-#ifdef CONFIG_COMPAT
-#define TASK_SIZE_32 UL(0x100000000)
-#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
- TASK_SIZE_32 : TASK_SIZE_64)
-#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
- TASK_SIZE_32 : TASK_SIZE_64)
-#else
-#define TASK_SIZE TASK_SIZE_64
-#endif /* CONFIG_COMPAT */
-
-#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 4))
#define KERNEL_START _text
#define KERNEL_END _end
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -19,6 +19,10 @@
#ifndef __ASM_PROCESSOR_H
#define __ASM_PROCESSOR_H
+#define TASK_SIZE_64 (UL(1) << VA_BITS)
+
+#ifndef __ASSEMBLY__
+
/*
* Default implementation of macro that returns current
* instruction pointer ("program counter").
@@ -37,6 +41,22 @@
#include <asm/ptrace.h>
#include <asm/types.h>
+/*
+ * TASK_SIZE - the maximum size of a user space task.
+ * TASK_UNMAPPED_BASE - the lower boundary of the mmap VM area.
+ */
+#ifdef CONFIG_COMPAT
+#define TASK_SIZE_32 UL(0x100000000)
+#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
+ TASK_SIZE_32 : TASK_SIZE_64)
+#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
+ TASK_SIZE_32 : TASK_SIZE_64)
+#else
+#define TASK_SIZE TASK_SIZE_64
+#endif /* CONFIG_COMPAT */
+
+#define TASK_UNMAPPED_BASE (PAGE_ALIGN(TASK_SIZE / 4))
+
#define STACK_TOP_MAX TASK_SIZE_64
#ifdef CONFIG_COMPAT
#define AARCH32_VECTORS_BASE 0xffff0000
@@ -194,4 +214,5 @@ static inline void spin_lock_prefetch(co
int cpu_enable_pan(void *__unused);
int cpu_enable_cache_maint_trap(void *__unused);
+#endif /* __ASSEMBLY__ */
#endif /* __ASM_PROCESSOR_H */
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -28,7 +28,7 @@
#include <asm/errno.h>
#include <asm/esr.h>
#include <asm/irq.h>
-#include <asm/memory.h>
+#include <asm/processor.h>
#include <asm/ptrace.h>
#include <asm/thread_info.h>
#include <asm/asm-uaccess.h>
Patches currently in stable-queue which might be from ynorov(a)caviumnetworks.com are
queue-4.14/arm64-move-task_-definitions-to-asm-processor.h.patch
This is a note to let you know that I've just added the patch titled
[Variant 2/Spectre-v2] arm64: Move BP hardening to check_and_switch_context
to the 4.14-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:
arm64-move-bp-hardening-to-check_and_switch_context.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Fri, 19 Jan 2018 15:42:09 +0000
Subject: [Variant 2/Spectre-v2] arm64: Move BP hardening to check_and_switch_context
From: Marc Zyngier <marc.zyngier(a)arm.com>
Commit a8e4c0a919ae upstream.
We call arm64_apply_bp_hardening() from post_ttbr_update_workaround,
which has the unexpected consequence of being triggered on every
exception return to userspace when ARM64_SW_TTBR0_PAN is selected,
even if no context switch actually occured.
This is a bit suboptimal, and it would be more logical to only
invalidate the branch predictor when we actually switch to
a different mm.
In order to solve this, move the call to arm64_apply_bp_hardening()
into check_and_switch_context(), where we're guaranteed to pick
a different mm context.
Acked-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas(a)arm.com>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/mm/context.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -227,6 +227,9 @@ void check_and_switch_context(struct mm_
raw_spin_unlock_irqrestore(&cpu_asid_lock, flags);
switch_mm_fastpath:
+
+ arm64_apply_bp_hardening();
+
/*
* Defer TTBR0_EL1 setting for user threads to uaccess_enable() when
* emulating PAN.
@@ -242,8 +245,6 @@ asmlinkage void post_ttbr_update_workaro
"ic iallu; dsb nsh; isb",
ARM64_WORKAROUND_CAVIUM_27456,
CONFIG_CAVIUM_ERRATUM_27456));
-
- arm64_apply_bp_hardening();
}
static int asids_init(void)
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.14/arm-arm64-smccc-make-function-identifiers-an-unsigned-quantity.patch
queue-4.14/arm64-move-bp-hardening-to-check_and_switch_context.patch
queue-4.14/arm-arm64-kvm-advertise-smccc-v1.1.patch
queue-4.14/arm64-move-post_ttbr_update_workaround-to-c-code.patch
queue-4.14/firmware-psci-expose-psci-conduit.patch
queue-4.14/arm64-force-kpti-to-be-disabled-on-cavium-thunderx.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-high-priority-synchronous-exceptions.patch
queue-4.14/arm64-kpti-fix-the-interaction-between-asid-switching-and-software-pan.patch
queue-4.14/firmware-psci-expose-smccc-version-through-psci_ops.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-affected-cortex-a-cpus.patch
queue-4.14/arm-arm64-kvm-add-psci_version-helper.patch
queue-4.14/arm64-kill-psci_get_version-as-a-variant-2-workaround.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-suspicious-interrupts-from-el0.patch
queue-4.14/arm64-capabilities-handle-duplicate-entries-for-a-capability.patch
queue-4.14/arm64-add-arm_smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm-arm64-kvm-turn-kvm_psci_version-into-a-static-inline.patch
queue-4.14/arm-arm64-kvm-implement-psci-1.0-support.patch
queue-4.14/arm64-kvm-add-smccc_arch_workaround_1-fast-handling.patch
queue-4.14/arm64-kvm-report-smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm-arm64-smccc-implement-smccc-v1.1-inline-primitive.patch
queue-4.14/arm64-idmap-use-awx-flags-for-.idmap.text-.pushsection-directives.patch
queue-4.14/arm64-kvm-make-psci_version-a-fast-path.patch
queue-4.14/arm64-cpufeature-__this_cpu_has_cap-shouldn-t-stop-early.patch
queue-4.14/arm64-kpti-add-enable-callback-to-remap-swapper-using-ng-mappings.patch
queue-4.14/arm-arm64-kvm-consolidate-the-psci-include-files.patch
queue-4.14/arm64-add-skeleton-to-harden-the-branch-predictor-against-aliasing-attacks.patch
queue-4.14/arm-arm64-kvm-add-smccc-accessors-to-psci-code.patch
queue-4.14/arm64-kvm-use-per-cpu-vector-when-bp-hardening-is-enabled.patch
queue-4.14/arm64-kvm-increment-pc-after-handling-an-smc-trap.patch
This is a note to let you know that I've just added the patch titled
[Variant 3/Meltdown] arm64: mm: Remove pre_ttbr0_update_workaround for Falkor erratum #E1003
to the 4.14-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:
arm64-mm-remove-pre_ttbr0_update_workaround-for-falkor-erratum-e1003.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Will Deacon <will.deacon(a)arm.com>
Date: Thu, 10 Aug 2017 13:29:06 +0100
Subject: [Variant 3/Meltdown] arm64: mm: Remove pre_ttbr0_update_workaround for Falkor erratum #E1003
From: Will Deacon <will.deacon(a)arm.com>
Commit 85d13c001497 upstream.
The pre_ttbr0_update_workaround hook is called prior to context-switching
TTBR0 because Falkor erratum E1003 can cause TLB allocation with the wrong
ASID if both the ASID and the base address of the TTBR are updated at
the same time.
With the ASID sitting safely in TTBR1, we no longer update things
atomically, so we can remove the pre_ttbr0_update_workaround macro as
it's no longer required. The erratum infrastructure and documentation
is left around for #E1003, as it will be required by the entry
trampoline code in a future patch.
Reviewed-by: Mark Rutland <mark.rutland(a)arm.com>
Tested-by: Laura Abbott <labbott(a)redhat.com>
Tested-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/include/asm/assembler.h | 22 ----------------------
arch/arm64/include/asm/mmu_context.h | 2 --
arch/arm64/mm/context.c | 11 -----------
arch/arm64/mm/proc.S | 1 -
4 files changed, 36 deletions(-)
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -25,7 +25,6 @@
#include <asm/asm-offsets.h>
#include <asm/cpufeature.h>
-#include <asm/mmu_context.h>
#include <asm/page.h>
#include <asm/pgtable-hwdef.h>
#include <asm/ptrace.h>
@@ -465,27 +464,6 @@ alternative_endif
.endm
/*
- * Errata workaround prior to TTBR0_EL1 update
- *
- * val: TTBR value with new BADDR, preserved
- * tmp0: temporary register, clobbered
- * tmp1: other temporary register, clobbered
- */
- .macro pre_ttbr0_update_workaround, val, tmp0, tmp1
-#ifdef CONFIG_QCOM_FALKOR_ERRATUM_1003
-alternative_if ARM64_WORKAROUND_QCOM_FALKOR_E1003
- mrs \tmp0, ttbr0_el1
- mov \tmp1, #FALKOR_RESERVED_ASID
- bfi \tmp0, \tmp1, #48, #16 // reserved ASID + old BADDR
- msr ttbr0_el1, \tmp0
- isb
- bfi \tmp0, \val, #0, #48 // reserved ASID + new BADDR
- msr ttbr0_el1, \tmp0
- isb
-alternative_else_nop_endif
-#endif
- .endm
-
/*
* Errata workaround post TTBR0_EL1 update.
*/
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -19,8 +19,6 @@
#ifndef __ASM_MMU_CONTEXT_H
#define __ASM_MMU_CONTEXT_H
-#define FALKOR_RESERVED_ASID 1
-
#ifndef __ASSEMBLY__
#include <linux/compiler.h>
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -79,13 +79,6 @@ void verify_cpu_asid_bits(void)
}
}
-static void set_reserved_asid_bits(void)
-{
- if (IS_ENABLED(CONFIG_QCOM_FALKOR_ERRATUM_1003) &&
- cpus_have_const_cap(ARM64_WORKAROUND_QCOM_FALKOR_E1003))
- __set_bit(FALKOR_RESERVED_ASID, asid_map);
-}
-
static void flush_context(unsigned int cpu)
{
int i;
@@ -94,8 +87,6 @@ static void flush_context(unsigned int c
/* Update the list of reserved ASIDs and the ASID bitmap. */
bitmap_clear(asid_map, 0, NUM_USER_ASIDS);
- set_reserved_asid_bits();
-
/*
* Ensure the generation bump is observed before we xchg the
* active_asids.
@@ -250,8 +241,6 @@ static int asids_init(void)
panic("Failed to allocate bitmap for %lu ASIDs\n",
NUM_USER_ASIDS);
- set_reserved_asid_bits();
-
pr_info("ASID allocator initialised with %lu entries\n", NUM_USER_ASIDS);
return 0;
}
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -138,7 +138,6 @@ ENDPROC(cpu_do_resume)
* - pgd_phys - physical address of new TTB
*/
ENTRY(cpu_do_switch_mm)
- pre_ttbr0_update_workaround x0, x2, x3
mrs x2, ttbr1_el1
mmid x1, x1 // get mm->context.id
bfi x2, x1, #48, #16 // set the ASID
Patches currently in stable-queue which might be from will.deacon(a)arm.com are
queue-4.14/arm64-make-user_ds-an-inclusive-limit.patch
queue-4.14/arm64-mm-remove-pre_ttbr0_update_workaround-for-falkor-erratum-e1003.patch
queue-4.14/arm64-uaccess-don-t-bother-eliding-access_ok-checks-in-__-get-put-_user.patch
queue-4.14/arm64-cpufeature-pass-capability-structure-to-enable-callback.patch
queue-4.14/arm64-uaccess-mask-__user-pointers-for-__arch_-clear-copy_-_user.patch
queue-4.14/arm64-mm-add-arm64_kernel_unmapped_at_el0-helper.patch
queue-4.14/arm64-entry-reword-comment-about-post_ttbr_update_workaround.patch
queue-4.14/arm64-kaslr-put-kernel-vectors-address-in-separate-data-page.patch
queue-4.14/arm-arm64-smccc-make-function-identifiers-an-unsigned-quantity.patch
queue-4.14/arm64-move-bp-hardening-to-check_and_switch_context.patch
queue-4.14/arm-arm64-kvm-advertise-smccc-v1.1.patch
queue-4.14/arm64-move-post_ttbr_update_workaround-to-c-code.patch
queue-4.14/arm64-turn-on-kpti-only-on-cpus-that-need-it.patch
queue-4.14/firmware-psci-expose-psci-conduit.patch
queue-4.14/arm64-force-kpti-to-be-disabled-on-cavium-thunderx.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-high-priority-synchronous-exceptions.patch
queue-4.14/arm64-kpti-fix-the-interaction-between-asid-switching-and-software-pan.patch
queue-4.14/firmware-psci-expose-smccc-version-through-psci_ops.patch
queue-4.14/arm64-mm-permit-transitioning-from-global-to-non-global-without-bbm.patch
queue-4.14/arm64-mm-allocate-asids-in-pairs.patch
queue-4.14/arm64-tls-avoid-unconditional-zeroing-of-tpidrro_el0-for-native-tasks.patch
queue-4.14/arm64-use-ret-instruction-for-exiting-the-trampoline.patch
queue-4.14/arm64-futex-mask-__user-pointers-prior-to-dereference.patch
queue-4.14/arm64-entry-explicitly-pass-exception-level-to-kernel_ventry-macro.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-affected-cortex-a-cpus.patch
queue-4.14/arm64-kpti-make-use-of-ng-dependent-on-arm64_kernel_unmapped_at_el0.patch
queue-4.14/arm-arm64-kvm-add-psci_version-helper.patch
queue-4.14/arm64-kill-psci_get_version-as-a-variant-2-workaround.patch
queue-4.14/arm64-entry-ensure-branch-through-syscall-table-is-bounded-under-speculation.patch
queue-4.14/arm64-mm-use-non-global-mappings-for-kernel-space.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-suspicious-interrupts-from-el0.patch
queue-4.14/arm64-capabilities-handle-duplicate-entries-for-a-capability.patch
queue-4.14/arm64-entry-hook-up-entry-trampoline-to-exception-vectors.patch
queue-4.14/arm64-branch-predictor-hardening-for-cavium-thunderx2.patch
queue-4.14/arm64-uaccess-prevent-speculative-use-of-the-current-addr_limit.patch
queue-4.14/.arm64-add-software-workaround-for-falkor-erratum-1041.patch.swp
queue-4.14/arm64-use-pointer-masking-to-limit-uaccess-speculation.patch
queue-4.14/arm64-add-arm_smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm64-erratum-work-around-falkor-erratum-e1003-in-trampoline-code.patch
queue-4.14/arm64-mm-fix-and-re-enable-arm64_sw_ttbr0_pan.patch
queue-4.14/arm64-mm-invalidate-both-kernel-and-user-asids-when-performing-tlbi.patch
queue-4.14/drivers-firmware-expose-psci_get_version-through-psci_ops-structure.patch
queue-4.14/arm64-mm-rename-post_ttbr0_update_workaround.patch
queue-4.14/arm64-mm-map-entry-trampoline-into-trampoline-and-kernel-page-tables.patch
queue-4.14/arm-arm64-kvm-turn-kvm_psci_version-into-a-static-inline.patch
queue-4.14/arm-arm64-kvm-implement-psci-1.0-support.patch
queue-4.14/arm64-move-task_-definitions-to-asm-processor.h.patch
queue-4.14/arm64-kconfig-reword-unmap_kernel_at_el0-kconfig-entry.patch
queue-4.14/arm64-mm-move-asid-from-ttbr0-to-ttbr1.patch
queue-4.14/arm64-mm-introduce-ttbr_asid_mask-for-getting-at-the-asid-in-the-ttbr.patch
queue-4.14/arm64-kvm-add-smccc_arch_workaround_1-fast-handling.patch
queue-4.14/arm64-take-into-account-id_aa64pfr0_el1.csv3.patch
queue-4.14/arm64-cputype-add-missing-midr-values-for-cortex-a72-and-cortex-a75.patch
queue-4.14/arm64-kvm-report-smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm64-barrier-add-csdb-macros-to-control-data-value-prediction.patch
queue-4.14/arm-arm64-smccc-implement-smccc-v1.1-inline-primitive.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-falkor.patch
queue-4.14/arm64-kconfig-add-config_unmap_kernel_at_el0.patch
queue-4.14/arm64-add-software-workaround-for-falkor-erratum-1041.patch
queue-4.14/arm64-idmap-use-awx-flags-for-.idmap.text-.pushsection-directives.patch
queue-4.14/arm64-run-enable-method-for-errata-work-arounds-on-late-cpus.patch
queue-4.14/arm64-mm-temporarily-disable-arm64_sw_ttbr0_pan.patch
queue-4.14/arm64-entry-add-exception-trampoline-page-for-exceptions-from-el0.patch
queue-4.14/arm64-kvm-make-psci_version-a-fast-path.patch
queue-4.14/arm64-cpufeature-__this_cpu_has_cap-shouldn-t-stop-early.patch
queue-4.14/arm64-implement-array_index_mask_nospec.patch
queue-4.14/arm64-kpti-add-enable-callback-to-remap-swapper-using-ng-mappings.patch
queue-4.14/arm-arm64-kvm-consolidate-the-psci-include-files.patch
queue-4.14/arm64-add-skeleton-to-harden-the-branch-predictor-against-aliasing-attacks.patch
queue-4.14/arm64-define-cputype-macros-for-falkor-cpu.patch
queue-4.14/arm64-cpu_errata-add-kryo-to-falkor-1003-errata.patch
queue-4.14/arm-arm64-kvm-add-smccc-accessors-to-psci-code.patch
queue-4.14/arm64-entry-add-fake-cpu-feature-for-unmapping-the-kernel-at-el0.patch
queue-4.14/arm64-kvm-use-per-cpu-vector-when-bp-hardening-is-enabled.patch
queue-4.14/arm64-cputype-add-midr-values-for-cavium-thunderx2-cpus.patch
queue-4.14/arm64-kvm-increment-pc-after-handling-an-smc-trap.patch
This is a note to let you know that I've just added the patch titled
[Variant 3/Meltdown] arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN
to the 4.14-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:
arm64-mm-temporarily-disable-arm64_sw_ttbr0_pan.patch
and it can be found in the queue-4.14 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 foo@baz Wed Feb 14 14:44:54 CET 2018
From: Will Deacon <will.deacon(a)arm.com>
Date: Thu, 10 Aug 2017 13:04:48 +0100
Subject: [Variant 3/Meltdown] arm64: mm: Temporarily disable ARM64_SW_TTBR0_PAN
From: Will Deacon <will.deacon(a)arm.com>
Commit 376133b7edc2 upstream.
We're about to rework the way ASIDs are allocated, switch_mm is
implemented and low-level kernel entry/exit is handled, so keep the
ARM64_SW_TTBR0_PAN code out of the way whilst we do the heavy lifting.
It will be re-enabled in a subsequent patch.
Reviewed-by: Mark Rutland <mark.rutland(a)arm.com>
Tested-by: Laura Abbott <labbott(a)redhat.com>
Tested-by: Shanker Donthineni <shankerd(a)codeaurora.org>
Signed-off-by: Will Deacon <will.deacon(a)arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -882,6 +882,7 @@ endif
config ARM64_SW_TTBR0_PAN
bool "Emulate Privileged Access Never using TTBR0_EL1 switching"
+ depends on BROKEN # Temporary while switch_mm is reworked
help
Enabling this option prevents the kernel from accessing
user-space memory directly by pointing TTBR0_EL1 to a reserved
Patches currently in stable-queue which might be from will.deacon(a)arm.com are
queue-4.14/arm64-make-user_ds-an-inclusive-limit.patch
queue-4.14/arm64-mm-remove-pre_ttbr0_update_workaround-for-falkor-erratum-e1003.patch
queue-4.14/arm64-uaccess-don-t-bother-eliding-access_ok-checks-in-__-get-put-_user.patch
queue-4.14/arm64-cpufeature-pass-capability-structure-to-enable-callback.patch
queue-4.14/arm64-uaccess-mask-__user-pointers-for-__arch_-clear-copy_-_user.patch
queue-4.14/arm64-mm-add-arm64_kernel_unmapped_at_el0-helper.patch
queue-4.14/arm64-entry-reword-comment-about-post_ttbr_update_workaround.patch
queue-4.14/arm64-kaslr-put-kernel-vectors-address-in-separate-data-page.patch
queue-4.14/arm-arm64-smccc-make-function-identifiers-an-unsigned-quantity.patch
queue-4.14/arm64-move-bp-hardening-to-check_and_switch_context.patch
queue-4.14/arm-arm64-kvm-advertise-smccc-v1.1.patch
queue-4.14/arm64-move-post_ttbr_update_workaround-to-c-code.patch
queue-4.14/arm64-turn-on-kpti-only-on-cpus-that-need-it.patch
queue-4.14/firmware-psci-expose-psci-conduit.patch
queue-4.14/arm64-force-kpti-to-be-disabled-on-cavium-thunderx.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-high-priority-synchronous-exceptions.patch
queue-4.14/arm64-kpti-fix-the-interaction-between-asid-switching-and-software-pan.patch
queue-4.14/firmware-psci-expose-smccc-version-through-psci_ops.patch
queue-4.14/arm64-mm-permit-transitioning-from-global-to-non-global-without-bbm.patch
queue-4.14/arm64-mm-allocate-asids-in-pairs.patch
queue-4.14/arm64-tls-avoid-unconditional-zeroing-of-tpidrro_el0-for-native-tasks.patch
queue-4.14/arm64-use-ret-instruction-for-exiting-the-trampoline.patch
queue-4.14/arm64-futex-mask-__user-pointers-prior-to-dereference.patch
queue-4.14/arm64-entry-explicitly-pass-exception-level-to-kernel_ventry-macro.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-affected-cortex-a-cpus.patch
queue-4.14/arm64-kpti-make-use-of-ng-dependent-on-arm64_kernel_unmapped_at_el0.patch
queue-4.14/arm-arm64-kvm-add-psci_version-helper.patch
queue-4.14/arm64-kill-psci_get_version-as-a-variant-2-workaround.patch
queue-4.14/arm64-entry-ensure-branch-through-syscall-table-is-bounded-under-speculation.patch
queue-4.14/arm64-mm-use-non-global-mappings-for-kernel-space.patch
queue-4.14/arm64-entry-apply-bp-hardening-for-suspicious-interrupts-from-el0.patch
queue-4.14/arm64-capabilities-handle-duplicate-entries-for-a-capability.patch
queue-4.14/arm64-entry-hook-up-entry-trampoline-to-exception-vectors.patch
queue-4.14/arm64-branch-predictor-hardening-for-cavium-thunderx2.patch
queue-4.14/arm64-uaccess-prevent-speculative-use-of-the-current-addr_limit.patch
queue-4.14/.arm64-add-software-workaround-for-falkor-erratum-1041.patch.swp
queue-4.14/arm64-use-pointer-masking-to-limit-uaccess-speculation.patch
queue-4.14/arm64-add-arm_smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm64-erratum-work-around-falkor-erratum-e1003-in-trampoline-code.patch
queue-4.14/arm64-mm-fix-and-re-enable-arm64_sw_ttbr0_pan.patch
queue-4.14/arm64-mm-invalidate-both-kernel-and-user-asids-when-performing-tlbi.patch
queue-4.14/drivers-firmware-expose-psci_get_version-through-psci_ops-structure.patch
queue-4.14/arm64-mm-rename-post_ttbr0_update_workaround.patch
queue-4.14/arm64-mm-map-entry-trampoline-into-trampoline-and-kernel-page-tables.patch
queue-4.14/arm-arm64-kvm-turn-kvm_psci_version-into-a-static-inline.patch
queue-4.14/arm-arm64-kvm-implement-psci-1.0-support.patch
queue-4.14/arm64-move-task_-definitions-to-asm-processor.h.patch
queue-4.14/arm64-kconfig-reword-unmap_kernel_at_el0-kconfig-entry.patch
queue-4.14/arm64-mm-move-asid-from-ttbr0-to-ttbr1.patch
queue-4.14/arm64-mm-introduce-ttbr_asid_mask-for-getting-at-the-asid-in-the-ttbr.patch
queue-4.14/arm64-kvm-add-smccc_arch_workaround_1-fast-handling.patch
queue-4.14/arm64-take-into-account-id_aa64pfr0_el1.csv3.patch
queue-4.14/arm64-cputype-add-missing-midr-values-for-cortex-a72-and-cortex-a75.patch
queue-4.14/arm64-kvm-report-smccc_arch_workaround_1-bp-hardening-support.patch
queue-4.14/arm64-barrier-add-csdb-macros-to-control-data-value-prediction.patch
queue-4.14/arm-arm64-smccc-implement-smccc-v1.1-inline-primitive.patch
queue-4.14/arm64-implement-branch-predictor-hardening-for-falkor.patch
queue-4.14/arm64-kconfig-add-config_unmap_kernel_at_el0.patch
queue-4.14/arm64-add-software-workaround-for-falkor-erratum-1041.patch
queue-4.14/arm64-idmap-use-awx-flags-for-.idmap.text-.pushsection-directives.patch
queue-4.14/arm64-run-enable-method-for-errata-work-arounds-on-late-cpus.patch
queue-4.14/arm64-mm-temporarily-disable-arm64_sw_ttbr0_pan.patch
queue-4.14/arm64-entry-add-exception-trampoline-page-for-exceptions-from-el0.patch
queue-4.14/arm64-kvm-make-psci_version-a-fast-path.patch
queue-4.14/arm64-cpufeature-__this_cpu_has_cap-shouldn-t-stop-early.patch
queue-4.14/arm64-implement-array_index_mask_nospec.patch
queue-4.14/arm64-kpti-add-enable-callback-to-remap-swapper-using-ng-mappings.patch
queue-4.14/arm-arm64-kvm-consolidate-the-psci-include-files.patch
queue-4.14/arm64-add-skeleton-to-harden-the-branch-predictor-against-aliasing-attacks.patch
queue-4.14/arm64-define-cputype-macros-for-falkor-cpu.patch
queue-4.14/arm64-cpu_errata-add-kryo-to-falkor-1003-errata.patch
queue-4.14/arm-arm64-kvm-add-smccc-accessors-to-psci-code.patch
queue-4.14/arm64-entry-add-fake-cpu-feature-for-unmapping-the-kernel-at-el0.patch
queue-4.14/arm64-kvm-use-per-cpu-vector-when-bp-hardening-is-enabled.patch
queue-4.14/arm64-cputype-add-midr-values-for-cavium-thunderx2-cpus.patch
queue-4.14/arm64-kvm-increment-pc-after-handling-an-smc-trap.patch