Hello Greg,
I'd like to request the following commits (in that order) be merged into
4.4/4.9 stable branches:
b7f8a09f8097 ("btrfs: Don't clear SGID when inheriting ACLs") - this one
landed in 4.13 and was tagged for stable but it seems it got missed.
d7d824966530 ("btrfs: preserve i_mode if __btrfs_set_acl() fails") -
this one depends on the first commit for context but otherwise, should
be trivial to backport.
This is a note to let you know that I've just added the patch titled
staging: comedi: fix comedi_nsamples_left.
to my staging git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
in the staging-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From a42ae5905140c324362fe5036ae1dbb16e4d359c Mon Sep 17 00:00:00 2001
From: Frank Mori Hess <fmh6jj(a)gmail.com>
Date: Thu, 15 Feb 2018 15:13:42 -0500
Subject: staging: comedi: fix comedi_nsamples_left.
A rounding error was causing comedi_nsamples_left to
return the wrong value when nsamples was not a multiple
of the scan length.
Cc: <stable(a)vger.kernel.org> # v4.4+
Signed-off-by: Frank Mori Hess <fmh6jj(a)gmail.com>
Reviewed-by: Ian Abbott <abbotti(a)mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/comedi/drivers.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/comedi/drivers.c b/drivers/staging/comedi/drivers.c
index e618a87521a3..9d733471ca2e 100644
--- a/drivers/staging/comedi/drivers.c
+++ b/drivers/staging/comedi/drivers.c
@@ -475,8 +475,7 @@ unsigned int comedi_nsamples_left(struct comedi_subdevice *s,
struct comedi_cmd *cmd = &async->cmd;
if (cmd->stop_src == TRIG_COUNT) {
- unsigned int nscans = nsamples / cmd->scan_end_arg;
- unsigned int scans_left = __comedi_nscans_left(s, nscans);
+ unsigned int scans_left = __comedi_nscans_left(s, cmd->stop_arg);
unsigned int scan_pos =
comedi_bytes_to_samples(s, async->scan_progress);
unsigned long long samples_left = 0;
--
2.16.2
On 6 March 2018 at 15:20, Mark Brown <broonie(a)kernel.org> wrote:
> On Tue, Mar 06, 2018 at 02:42:43PM +0100, Jonas Gorski wrote:
>> On 5 March 2018 at 21:35, Mark Brown <broonie(a)kernel.org> wrote:
>
>> > It's exposing more capability information but it's in the "how did this
>> > ever work without the fix" range, and I'd worry that this might cause us
>> > to do something like start exercising handling code in client drivers
>> > that had never been tested. Not that I can immediately see any client
>> > drivers in mainline that actually pay attention... :/
>
>> I would assume that most spi client drivers use short messages, so
>> they aren't affected unless the max message size is really short.
>> m25p80 on the other hand will do arbitrarily large transfers/reads, so
>> there it was supported first.
>
> There's a bunch of SPI drivers that do firmware downloads which I'd
> expect to be affected, the limit the device has is tiny so it's
> relatively easy to bump into it. It's very rare for devices to be so
> limited so unfortunately client drivers don't generally check though.
Well, at least for bcm63xx it's very rare to have something other than
a flash chip, a (broadcom) ethernet switch management interface, or a
SLIC/SLAC attached to the SPI controller. And AFAICT of these three
only the flash chip uses large SPI transfers. Furthermore, unless you
have a development board, you won't be able to attach anything
different to it. So the chance to bump into the limits with other
drivers is rather low.
I would assume that this is true for most systems with a limited SPI
controller. I would hope that most board designers are sensible enough
to not add devices that won't work ;-)
Regards
Jonas
If there is IR in the raw kfifo when ir_raw_event_unregister() is called,
then kthread_stop() causes ir_raw_event_thread to be scheduled, decode
some scancodes and re-arm timer_keyup. The timer_keyup then fires when
the rc device is long gone.
Cc: stable(a)vger.kernel.org
Signed-off-by: Sean Young <sean(a)mess.org>
---
drivers/media/rc/rc-main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 4a952108ba1e..8621761a680f 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1932,12 +1932,12 @@ void rc_unregister_device(struct rc_dev *dev)
if (!dev)
return;
- del_timer_sync(&dev->timer_keyup);
- del_timer_sync(&dev->timer_repeat);
-
if (dev->driver_type == RC_DRIVER_IR_RAW)
ir_raw_event_unregister(dev);
+ del_timer_sync(&dev->timer_keyup);
+ del_timer_sync(&dev->timer_repeat);
+
rc_free_rx_device(dev);
mutex_lock(&dev->lock);
--
2.14.3
On 5 March 2018 at 21:35, Mark Brown <broonie(a)kernel.org> wrote:
> On Mon, Mar 05, 2018 at 08:07:46PM +0000, Sasha Levin wrote:
>> On Mon, Mar 05, 2018 at 10:23:10AM +0000, Mark Brown wrote:
>> >On Sat, Mar 03, 2018 at 10:27:56PM +0000, Sasha Levin wrote:
>
>> >> The bcm63xx SPI controller does not allow manual control of the CS
>> >> lines and will toggle it automatically before and after sending data,
>> >> so we are limited to messages that fit in the FIFO buffer. Since the CS
>> >> lines aren't available as GPIOs either, we will need to make slave
>> >> drivers aware of this limitation so they can handle them accordingly.
>
>> >This seems really aggressive for stable...
>
>> Why so?
>
> It's exposing more capability information but it's in the "how did this
> ever work without the fix" range, and I'd worry that this might cause us
> to do something like start exercising handling code in client drivers
> that had never been tested. Not that I can immediately see any client
> drivers in mainline that actually pay attention... :/
I would assume that most spi client drivers use short messages, so
they aren't affected unless the max message size is really short.
m25p80 on the other hand will do arbitrarily large transfers/reads, so
there it was supported first.
m25p80 supports max_transfer_size since 4,9, and max_message_size
since 4.11 with commit 9e276de6a367cde07c1a63522152985d4e5cca8b. So
that one would need to be backported as well for the max_message_size
being actually meaningful.
tinydrm-helpers also observes max_transfers_size since 4.11 with
commit 9f69eb5c36a644571cca6b2f8dc5f6a7cba04a8b where it was added,
but since this is a larger commit and not just a "bugfix" one, this
doesn't seem like a candidate for backporting.
Regards
Jonas
Corsair Strafe RGB keyboard does not respond to usb control messages
sometimes and hence generates timeouts.
Commit de3af5bf259d ("usb: quirks: add delay init quirk for Corsair
Strafe RGB keyboard") tried to fix those timeouts by adding
USB_QUIRK_DELAY_INIT.
Unfortunately, even with this quirk timeouts of usb_control_msg()
can still be seen, but with a lower frequency (approx. 1 out of 15):
[ 29.103520] usb 1-8: string descriptor 0 read error: -110
[ 34.363097] usb 1-8: can't set config #1, error -110
Adding further delays to different locations where usb control
messages are issued just moves the timeouts to other locations,
e.g.:
[ 35.400533] usbhid 1-8:1.0: can't add hid device: -110
[ 35.401014] usbhid: probe of 1-8:1.0 failed with error -110
The only way to reliably avoid those issues is having a pause after
each usb control message. In approx. 200 boot cycles no more timeouts
were seen.
Addionaly, keep USB_QUIRK_DELAY_INIT as it turned out to be necessary
to have the delay in hub_port_connect() after hub_port_init().
The overall boot time seems not to be influenced by these additional
delays, even on fast machines and lightweight distributions.
Fixes: de3af5bf259d ("usb: quirks: add delay init quirk for Corsair Strafe RGB keyboard")
Cc: stable(a)vger.kernel.org
Signed-off-by: Danilo Krummrich <danilokrummrich(a)dk-develop.de>
---
drivers/usb/core/message.c | 4 ++++
drivers/usb/core/quirks.c | 3 ++-
include/linux/usb/quirks.h | 3 +++
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index c64cf6c4a83d..0c11d40a12bc 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -151,6 +151,10 @@ int usb_control_msg(struct usb_device *dev, unsigned int pipe, __u8 request,
ret = usb_internal_control_msg(dev, pipe, dr, data, size, timeout);
+ /* Linger a bit, prior to the next control message. */
+ if (dev->quirks & USB_QUIRK_DELAY_CTRL_MSG)
+ msleep(200);
+
kfree(dr);
return ret;
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index f4a548471f0f..54b019e267c5 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -230,7 +230,8 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
/* Corsair Strafe RGB */
- { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
+ { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT |
+ USB_QUIRK_DELAY_CTRL_MSG },
/* Corsair K70 LUX */
{ USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT },
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index f1fcec2fd5f8..b7a99ce56bc9 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -63,4 +63,7 @@
*/
#define USB_QUIRK_DISCONNECT_SUSPEND BIT(12)
+/* Device needs a pause after every control message. */
+#define USB_QUIRK_DELAY_CTRL_MSG BIT(13)
+
#endif /* __LINUX_USB_QUIRKS_H */
--
2.16.2
If there is a pending work, we just need to add the new dr into
the dr_list.
This is suggested by Michael Kelley.
Signed-off-by: Dexuan Cui <decui(a)microsoft.com>
Cc: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Cc: Jack Morgenstein <jackm(a)mellanox.com>
Cc: stable(a)vger.kernel.org
Cc: Stephen Hemminger <sthemmin(a)microsoft.com>
Cc: K. Y. Srinivasan <kys(a)microsoft.com>
Cc: Michael Kelley (EOSG) <Michael.H.Kelley(a)microsoft.com>
---
drivers/pci/host/pci-hyperv.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 3a385212f666..d3aa6736a9bb 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1733,6 +1733,7 @@ static void hv_pci_devices_present(struct hv_pcibus_device *hbus,
struct hv_dr_state *dr;
struct hv_dr_work *dr_wrk;
unsigned long flags;
+ bool pending_dr;
dr_wrk = kzalloc(sizeof(*dr_wrk), GFP_NOWAIT);
if (!dr_wrk)
@@ -1756,11 +1757,23 @@ static void hv_pci_devices_present(struct hv_pcibus_device *hbus,
}
spin_lock_irqsave(&hbus->device_list_lock, flags);
+
+ /*
+ * If pending_dr is true, we have already queued a work,
+ * which will see the new dr. Otherwise, we need to
+ * queue a new work.
+ */
+ pending_dr = !list_empty(&hbus->dr_list);
list_add_tail(&dr->list_entry, &hbus->dr_list);
- spin_unlock_irqrestore(&hbus->device_list_lock, flags);
- get_hvpcibus(hbus);
- queue_work(hbus->wq, &dr_wrk->wrk);
+ if (pending_dr) {
+ kfree(dr_wrk);
+ } else {
+ get_hvpcibus(hbus);
+ queue_work(hbus->wq, &dr_wrk->wrk);
+ }
+
+ spin_unlock_irqrestore(&hbus->device_list_lock, flags);
}
/**
--
2.7.4
The patch titled
Subject: zboot: fix stack protector in compressed boot phase
has been added to the -mm tree. Its filename is
zboot-fix-stack-protector-in-compressed-boot-phase.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/zboot-fix-stack-protector-in-compr…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/zboot-fix-stack-protector-in-compr…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Huacai Chen <chenhc(a)lemote.com>
Subject: zboot: fix stack protector in compressed boot phase
Calling __stack_chk_guard_setup() in decompress_kernel() is too late
because stack checking always fails for decompress_kernel() itself. So
remove __stack_chk_guard_setup() and initialize __stack_chk_guard at
compile time.
Original code comes from ARM but also used for MIPS and SH, so fix them
together. Without this fix, compressed booting of these archs will fail
because stack checking is enabled by default (>=4.16).
Link: http://lkml.kernel.org/r/1520230721-1839-1-git-send-email-chenhc@lemote.com
Signed-off-by: Huacai Chen <chenhc(a)lemote.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: James Hogan <james.hogan(a)mips.com>
Cc: Russell King <linux(a)arm.linux.org.uk>
Cc: Yoshinori Sato <ysato(a)users.sourceforge.jp>
Cc: Rich Felker <dalias(a)libc.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
arch/arm/boot/compressed/misc.c | 9 +--------
arch/mips/boot/compressed/decompress.c | 9 +--------
arch/sh/boot/compressed/misc.c | 9 +--------
3 files changed, 3 insertions(+), 24 deletions(-)
diff -puN arch/arm/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase arch/arm/boot/compressed/misc.c
--- a/arch/arm/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase
+++ a/arch/arm/boot/compressed/misc.c
@@ -128,12 +128,7 @@ asmlinkage void __div0(void)
error("Attempting division by 0!");
}
-unsigned long __stack_chk_guard;
-
-void __stack_chk_guard_setup(void)
-{
- __stack_chk_guard = 0x000a0dff;
-}
+unsigned long __stack_chk_guard = 0x000a0dff;
void __stack_chk_fail(void)
{
@@ -150,8 +145,6 @@ decompress_kernel(unsigned long output_s
{
int ret;
- __stack_chk_guard_setup();
-
output_data = (unsigned char *)output_start;
free_mem_ptr = free_mem_ptr_p;
free_mem_end_ptr = free_mem_ptr_end_p;
diff -puN arch/mips/boot/compressed/decompress.c~zboot-fix-stack-protector-in-compressed-boot-phase arch/mips/boot/compressed/decompress.c
--- a/arch/mips/boot/compressed/decompress.c~zboot-fix-stack-protector-in-compressed-boot-phase
+++ a/arch/mips/boot/compressed/decompress.c
@@ -76,12 +76,7 @@ void error(char *x)
#include "../../../../lib/decompress_unxz.c"
#endif
-unsigned long __stack_chk_guard;
-
-void __stack_chk_guard_setup(void)
-{
- __stack_chk_guard = 0x000a0dff;
-}
+unsigned long __stack_chk_guard = 0x000a0dff;
void __stack_chk_fail(void)
{
@@ -92,8 +87,6 @@ void decompress_kernel(unsigned long boo
{
unsigned long zimage_start, zimage_size;
- __stack_chk_guard_setup();
-
zimage_start = (unsigned long)(&__image_begin);
zimage_size = (unsigned long)(&__image_end) -
(unsigned long)(&__image_begin);
diff -puN arch/sh/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase arch/sh/boot/compressed/misc.c
--- a/arch/sh/boot/compressed/misc.c~zboot-fix-stack-protector-in-compressed-boot-phase
+++ a/arch/sh/boot/compressed/misc.c
@@ -104,12 +104,7 @@ static void error(char *x)
while(1); /* Halt */
}
-unsigned long __stack_chk_guard;
-
-void __stack_chk_guard_setup(void)
-{
- __stack_chk_guard = 0x000a0dff;
-}
+unsigned long __stack_chk_guard = 0x000a0dff;
void __stack_chk_fail(void)
{
@@ -130,8 +125,6 @@ void decompress_kernel(void)
{
unsigned long output_addr;
- __stack_chk_guard_setup();
-
#ifdef CONFIG_SUPERH64
output_addr = (CONFIG_MEMORY_START + 0x2000);
#else
_
Patches currently in -mm which might be from chenhc(a)lemote.com are
zboot-fix-stack-protector-in-compressed-boot-phase.patch
This can happen e.g. during disk cloning.
This is an incomplete fix: it does not catch duplicate UUIDs earlier
when things are still unattached. It does not unregister the device.
Further changes to cope better with this are planned but conflict with
Coly's ongoing improvements to handling device errors. In the meantime,
one can manually stop the device after this has happened.
Attempts to attach a duplicate device result in:
[ 136.372404] loop: module loaded
[ 136.424461] bcache: register_bdev() registered backing device loop0
[ 136.424464] bcache: bch_cached_dev_attach() Tried to attach loop0 but duplicate UUID already attached
My test procedure is:
dd if=/dev/sdb1 of=imgfile bs=1024 count=262144
losetup -f imgfile
Signed-off-by: Michael Lyle <mlyle(a)lyle.org>
Reviewed-by: Tang Junhui <tang.junhui(a)zte.com.cn>
Cc: <stable(a)vger.kernel.org>
---
drivers/md/bcache/super.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 9c141a8aaacc..5cace6892958 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -963,6 +963,7 @@ int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c,
uint32_t rtime = cpu_to_le32(get_seconds());
struct uuid_entry *u;
char buf[BDEVNAME_SIZE];
+ struct cached_dev *exist_dc, *t;
bdevname(dc->bdev, buf);
@@ -987,6 +988,16 @@ int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c,
return -EINVAL;
}
+ /* Check whether already attached */
+ list_for_each_entry_safe(exist_dc, t, &c->cached_devs, list) {
+ if (!memcmp(dc->sb.uuid, exist_dc->sb.uuid, 16)) {
+ pr_err("Tried to attach %s but duplicate UUID already attached",
+ buf);
+
+ return -EINVAL;
+ }
+ }
+
u = uuid_find(c, dc->sb.uuid);
if (u &&
--
2.14.1
From: Benjamin Poirier <bpoirier(a)suse.com>
When autoneg is off, the .check_for_link callback functions clear the
get_link_status flag and systematically return a "pseudo-error". This means
that the link is not detected as up until the next execution of the
e1000_watchdog_task() 2 seconds later.
CC: stable <stable(a)vger.kernel.org>
Fixes: 19110cfbb34d ("e1000e: Separate signaling for link check/link up")
Signed-off-by: Benjamin Poirier <bpoirier(a)suse.com>
Acked-by: Sasha Neftin <sasha.neftin(a)intel.com>
Tested-by: Aaron Brown <aaron.f.brown(a)intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 +-
drivers/net/ethernet/intel/e1000e/mac.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 31277d3bb7dc..ff308b05d68c 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1602,7 +1602,7 @@ static s32 e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
* we have already determined whether we have link or not.
*/
if (!mac->autoneg)
- return -E1000_ERR_CONFIG;
+ return 1;
/* Auto-Neg is enabled. Auto Speed Detection takes care
* of MAC speed/duplex configuration. So we only need to
diff --git a/drivers/net/ethernet/intel/e1000e/mac.c b/drivers/net/ethernet/intel/e1000e/mac.c
index f457c5703d0c..db735644b312 100644
--- a/drivers/net/ethernet/intel/e1000e/mac.c
+++ b/drivers/net/ethernet/intel/e1000e/mac.c
@@ -450,7 +450,7 @@ s32 e1000e_check_for_copper_link(struct e1000_hw *hw)
* we have already determined whether we have link or not.
*/
if (!mac->autoneg)
- return -E1000_ERR_CONFIG;
+ return 1;
/* Auto-Neg is enabled. Auto Speed Detection takes care
* of MAC speed/duplex configuration. So we only need to
--
2.14.3
On Mon, Mar 05, 2018 at 10:21:24AM +0000, Mark Brown wrote:
>On Sat, Mar 03, 2018 at 10:24:34PM +0000, Sasha Levin wrote:
>
>> Currently BCLK inverting is only handled when the DAI format is
>> DSP, but the BCLK may be inverted in any supported mode. Without
>> this using this CODEC in any other mode than DSP with the BCLK
>> inverted leads to bad sampling timing and very poor audio quality.
>
>This is a new feature, if this makes a difference to anyone in
>production it's most likely going to break their system and introduce
>the problems described in the commit log.
I'll drop it, thank you!
--
Thanks,
Sasha
On Mon, Mar 05, 2018 at 10:20:09AM +0000, Mark Brown wrote:
>On Sat, Mar 03, 2018 at 10:24:24PM +0000, Sasha Levin wrote:
>
>> We need to make sure that only proper channel slots (in SACCST register)
>> are enabled at playback start time since some AC'97 CODECs (like VT1613 on
>> UDOO board) were observed requesting via SLOTREQ spurious ones just after
>> an AC'97 link is started but before the CODEC is configured by its driver.
>
>This was part of a wider AC'97 rework IIRC and I'm very suspicious of
>backporting it independently.
I'll drop it. Thank you!
--
Thanks,
Sasha
On Mon, Mar 05, 2018 at 10:42:03AM +0000, Mark Brown wrote:
>On Sat, Mar 03, 2018 at 10:29:00PM +0000, Sasha Levin wrote:
>> From: Javier Martinez Canillas <javier(a)osg.samsung.com>
>>
>> [ Upstream commit 9ba2da5f5d18daaa365ab5426b05e16f1d114786 ]
>>
>> The driver doesn't have a struct of_device_id table but supported devices
>> are registered via Device Trees. This is working on the assumption that a
>> I2C device registered via OF will always match a legacy I2C device ID and
>> that the MODALIAS reported will always be of the form i2c:<device>.
>>
>> But this could change in the future so the correct approach is to have an
>> OF device ID table if the devices are registered via OF.
>
>As the commit message itself says this is not fixing anything, it's
>defence against future changes.
I was under the impression that this refers to future HW changes rather
than code, I'll drop all 3. Thanks!
--
Thanks,
Sasha
On Mon, Mar 05, 2018 at 10:23:10AM +0000, Mark Brown wrote:
>On Sat, Mar 03, 2018 at 10:27:56PM +0000, Sasha Levin wrote:
>> From: Jonas Gorski <jonas.gorski(a)gmail.com>
>>
>> [ Upstream commit 0135c03df914f0481c61f097c78d37cece84f330 ]
>
>Why are there so many more patches for v4.9 than for more recent
>kernels?
The v4.11..v4.14 range got processed, and all those commits are now
being pushed into 4.9 and older.
>> The bcm63xx SPI controller does not allow manual control of the CS
>> lines and will toggle it automatically before and after sending data,
>> so we are limited to messages that fit in the FIFO buffer. Since the CS
>> lines aren't available as GPIOs either, we will need to make slave
>> drivers aware of this limitation so they can handle them accordingly.
>
>This seems really aggressive for stable...
Why so?
--
Thanks,
Sasha
From: Martijn Coenen <maco(a)android.com>
binder_poll() passes the thread->wait waitqueue that
can be slept on for work. When a thread that uses
epoll explicitly exits using BINDER_THREAD_EXIT,
the waitqueue is freed, but it is never removed
from the corresponding epoll data structure. When
the process subsequently exits, the epoll cleanup
code tries to access the waitlist, which results in
a use-after-free.
Prevent this by using POLLFREE when the thread exits.
Signed-off-by: Martijn Coenen <maco(a)android.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Cc: stable <stable(a)vger.kernel.org> # 4.14
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index c96623d..77b1b95 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -4269,6 +4269,18 @@ static int binder_thread_release(struct binder_proc *proc,
if (t)
spin_lock(&t->lock);
}
+
+ /*
+ * If this thread used poll, make sure we remove the waitqueue
+ * from any epoll data structures holding it with POLLFREE.
+ * waitqueue_active() is safe to use here because we're holding
+ * the inner lock.
+ */
+ if ((thread->looper & BINDER_LOOPER_STATE_POLL) &&
+ waitqueue_active(&thread->wait)) {
+ wake_up_poll(&thread->wait, POLLHUP | POLLFREE);
+ }
+
binder_inner_proc_unlock(thread->proc);
if (send_reply)
--
2.7.4
From: Ganesh Mahendran <opensource.ganesh(a)gmail.com>
VM_IOREMAP is used to access hardware through a mechanism called
I/O mapped memory. Android binder is a IPC machanism which will
not access I/O memory.
And VM_IOREMAP has alignment requiement which may not needed in
binder.
__get_vm_area_node()
{
...
if (flags & VM_IOREMAP)
align = 1ul << clamp_t(int, fls_long(size),
PAGE_SHIFT, IOREMAP_MAX_ORDER);
...
}
This patch will save some kernel vm area, especially for 32bit os.
In 32bit OS, kernel vm area is only 240MB. We may got below
error when launching a app:
<3>[ 4482.440053] binder_alloc: binder_alloc_mmap_handler: 15728 8ce67000-8cf65000 get_vm_area failed -12
<3>[ 4483.218817] binder_alloc: binder_alloc_mmap_handler: 15745 8ce67000-8cf65000 get_vm_area failed -12
Signed-off-by: Ganesh Mahendran <opensource.ganesh(a)gmail.com>
Acked-by: Martijn Coenen <maco(a)android.com>
Acked-by: Todd Kjos <tkjos(a)google.com>
Cc: stable <stable(a)vger.kernel.org>
----
V3: update comments
V2: update comments
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
index 8989e31..6da12c5 100644
--- a/drivers/android/binder_alloc.c
+++ b/drivers/android/binder_alloc.c
@@ -626,7 +626,7 @@ int binder_alloc_mmap_handler(struct binder_alloc *alloc,
goto err_already_mapped;
}
- area = get_vm_area(vma->vm_end - vma->vm_start, VM_IOREMAP);
+ area = get_vm_area(vma->vm_end - vma->vm_start, VM_ALLOC);
if (area == NULL) {
ret = -ENOMEM;
failure_string = "get_vm_area";
--
2.7.4
From: Todd Kjos <tkjos(a)android.com>
binder_send_failed_reply() is called when a synchronous
transaction fails. It reports an error to the thread that
is waiting for the completion. Given that the transaction
is synchronous, there should never be more than 1 error
response to that thread -- this was being asserted with
a WARN().
However, when exercising the driver with syzbot tests, cases
were observed where multiple "synchronous" requests were
sent without waiting for responses, so it is possible that
multiple errors would be reported to the thread. This testing
was conducted with panic_on_warn set which forced the crash.
This is easily reproduced by sending back-to-back
"synchronous" transactions without checking for any
response (eg, set read_size to 0):
bwr.write_buffer = (uintptr_t)&bc1;
bwr.write_size = sizeof(bc1);
bwr.read_buffer = (uintptr_t)&br;
bwr.read_size = 0;
ioctl(fd, BINDER_WRITE_READ, &bwr);
sleep(1);
bwr2.write_buffer = (uintptr_t)&bc2;
bwr2.write_size = sizeof(bc2);
bwr2.read_buffer = (uintptr_t)&br;
bwr2.read_size = 0;
ioctl(fd, BINDER_WRITE_READ, &bwr2);
sleep(1);
The first transaction is sent to the servicemanager and the reply
fails because no VMA is set up by this client. After
binder_send_failed_reply() is called, the BINDER_WORK_RETURN_ERROR
is sitting on the thread's todo list since the read_size was 0 and
the client is not waiting for a response.
The 2nd transaction is sent and the BINDER_WORK_RETURN_ERROR has not
been consumed, so the thread's reply_error.cmd is still set (normally
cleared when the BINDER_WORK_RETURN_ERROR is handled). Therefore
when the servicemanager attempts to reply to the 2nd failed
transaction, the error is already set and it triggers this warning.
This is a user error since it is not waiting for the synchronous
transaction to complete. If it ever does check, it will see an
error.
Changed the WARN() to a pr_warn().
Signed-off-by: Todd Kjos <tkjos(a)android.com>
Reported-by: syzbot <syzkaller(a)googlegroups.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index c88582a..abf05aa 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -1919,8 +1919,14 @@ static void binder_send_failed_reply(struct binder_transaction *t,
&target_thread->todo);
wake_up_interruptible(&target_thread->wait);
} else {
- WARN(1, "Unexpected reply error: %u\n",
- target_thread->reply_error.cmd);
+ /*
+ * Cannot get here for normal operation, but
+ * we can if multiple synchronous transactions
+ * are sent without blocking for responses.
+ * Just ignore the 2nd error in this case.
+ */
+ pr_warn("Unexpected reply error: %u\n",
+ target_thread->reply_error.cmd);
}
binder_inner_proc_unlock(target_thread->proc);
binder_thread_dec_tmpref(target_thread);
--
2.7.4
From: Todd Kjos <tkjos(a)android.com>
User-space normally keeps the node alive when creating a transaction
since it has a reference to the target. The local strong ref keeps it
alive if the sending process dies before the target process processes
the transaction. If the source process is malicious or has a reference
counting bug, this can fail.
In this case, when we attempt to decrement the node in the failure
path, the node has already been freed.
This is fixed by taking a tmpref on the node while constructing
the transaction. To avoid re-acquiring the node lock and inner
proc lock to increment the proc's tmpref, a helper is used that
does the ref increments on both the node and proc.
Signed-off-by: Todd Kjos <tkjos(a)google.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 93 ++++++++++++++++++++++++++++++++++--------------
1 file changed, 66 insertions(+), 27 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 3f9d702..fa23e45 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -2582,6 +2582,48 @@ static bool binder_proc_transaction(struct binder_transaction *t,
return true;
}
+/**
+ * binder_get_node_refs_for_txn() - Get required refs on node for txn
+ * @node: struct binder_node for which to get refs
+ * @proc: returns @node->proc if valid
+ * @error: if no @proc then returns BR_DEAD_REPLY
+ *
+ * User-space normally keeps the node alive when creating a transaction
+ * since it has a reference to the target. The local strong ref keeps it
+ * alive if the sending process dies before the target process processes
+ * the transaction. If the source process is malicious or has a reference
+ * counting bug, relying on the local strong ref can fail.
+ *
+ * Since user-space can cause the local strong ref to go away, we also take
+ * a tmpref on the node to ensure it survives while we are constructing
+ * the transaction. We also need a tmpref on the proc while we are
+ * constructing the transaction, so we take that here as well.
+ *
+ * Return: The target_node with refs taken or NULL if no @node->proc is NULL.
+ * Also sets @proc if valid. If the @node->proc is NULL indicating that the
+ * target proc has died, @error is set to BR_DEAD_REPLY
+ */
+static struct binder_node *binder_get_node_refs_for_txn(
+ struct binder_node *node,
+ struct binder_proc **procp,
+ uint32_t *error)
+{
+ struct binder_node *target_node = NULL;
+
+ binder_node_inner_lock(node);
+ if (node->proc) {
+ target_node = node;
+ binder_inc_node_nilocked(node, 1, 0, NULL);
+ binder_inc_node_tmpref_ilocked(node);
+ node->proc->tmp_ref++;
+ *procp = node->proc;
+ } else
+ *error = BR_DEAD_REPLY;
+ binder_node_inner_unlock(node);
+
+ return target_node;
+}
+
static void binder_transaction(struct binder_proc *proc,
struct binder_thread *thread,
struct binder_transaction_data *tr, int reply,
@@ -2685,43 +2727,35 @@ static void binder_transaction(struct binder_proc *proc,
ref = binder_get_ref_olocked(proc, tr->target.handle,
true);
if (ref) {
- binder_inc_node(ref->node, 1, 0, NULL);
- target_node = ref->node;
- }
- binder_proc_unlock(proc);
- if (target_node == NULL) {
+ target_node = binder_get_node_refs_for_txn(
+ ref->node, &target_proc,
+ &return_error);
+ } else {
binder_user_error("%d:%d got transaction to invalid handle\n",
- proc->pid, thread->pid);
+ proc->pid, thread->pid);
return_error = BR_FAILED_REPLY;
- return_error_param = -EINVAL;
- return_error_line = __LINE__;
- goto err_invalid_target_handle;
}
+ binder_proc_unlock(proc);
} else {
mutex_lock(&context->context_mgr_node_lock);
target_node = context->binder_context_mgr_node;
- if (target_node == NULL) {
+ if (target_node)
+ target_node = binder_get_node_refs_for_txn(
+ target_node, &target_proc,
+ &return_error);
+ else
return_error = BR_DEAD_REPLY;
- mutex_unlock(&context->context_mgr_node_lock);
- return_error_line = __LINE__;
- goto err_no_context_mgr_node;
- }
- binder_inc_node(target_node, 1, 0, NULL);
mutex_unlock(&context->context_mgr_node_lock);
}
- e->to_node = target_node->debug_id;
- binder_node_lock(target_node);
- target_proc = target_node->proc;
- if (target_proc == NULL) {
- binder_node_unlock(target_node);
- return_error = BR_DEAD_REPLY;
+ if (!target_node) {
+ /*
+ * return_error is set above
+ */
+ return_error_param = -EINVAL;
return_error_line = __LINE__;
goto err_dead_binder;
}
- binder_inner_proc_lock(target_proc);
- target_proc->tmp_ref++;
- binder_inner_proc_unlock(target_proc);
- binder_node_unlock(target_node);
+ e->to_node = target_node->debug_id;
if (security_binder_transaction(proc->tsk,
target_proc->tsk) < 0) {
return_error = BR_FAILED_REPLY;
@@ -3071,6 +3105,8 @@ static void binder_transaction(struct binder_proc *proc,
if (target_thread)
binder_thread_dec_tmpref(target_thread);
binder_proc_dec_tmpref(target_proc);
+ if (target_node)
+ binder_dec_node_tmpref(target_node);
/*
* write barrier to synchronize with initialization
* of log entry
@@ -3089,6 +3125,8 @@ err_bad_parent:
err_copy_data_failed:
trace_binder_transaction_failed_buffer_release(t->buffer);
binder_transaction_buffer_release(target_proc, t->buffer, offp);
+ if (target_node)
+ binder_dec_node_tmpref(target_node);
target_node = NULL;
t->buffer->transaction = NULL;
binder_alloc_free_buf(&target_proc->alloc, t->buffer);
@@ -3103,13 +3141,14 @@ err_bad_call_stack:
err_empty_call_stack:
err_dead_binder:
err_invalid_target_handle:
-err_no_context_mgr_node:
if (target_thread)
binder_thread_dec_tmpref(target_thread);
if (target_proc)
binder_proc_dec_tmpref(target_proc);
- if (target_node)
+ if (target_node) {
binder_dec_node(target_node, 1, 0);
+ binder_dec_node_tmpref(target_node);
+ }
binder_debug(BINDER_DEBUG_FAILED_TRANSACTION,
"%d:%d transaction failed %d/%d, size %lld-%lld line %d\n",
--
2.7.4
From: Todd Kjos <tkjos(a)android.com>
The binder allocator assumes that the thread that
called binder_open will never die for the lifetime of
that proc. That thread is normally the group_leader,
however it may not be. Use the group_leader instead
of current.
Signed-off-by: Todd Kjos <tkjos(a)google.com>
Cc: stable <stable(a)vger.kernel.org> # 4.4+
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index fbe0eb9..a24ad74 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -3039,8 +3039,8 @@ static int binder_open(struct inode *nodp, struct file *filp)
proc = kzalloc(sizeof(*proc), GFP_KERNEL);
if (proc == NULL)
return -ENOMEM;
- get_task_struct(current);
- proc->tsk = current;
+ get_task_struct(current->group_leader);
+ proc->tsk = current->group_leader;
INIT_LIST_HEAD(&proc->todo);
init_waitqueue_head(&proc->wait);
proc->default_priority = task_nice(current);
--
2.7.4
From: Todd Kjos <tkjos(a)android.com>
This reverts commit a906d6931f3ccaf7de805643190765ddd7378e27.
The patch introduced a race in the binder driver. An attempt to fix the
race was submitted in "[PATCH v2] android: binder: fix dangling pointer
comparison", however the conclusion in the discussion for that patch
was that the original patch should be reverted.
The reversion is being done as part of the fine-grained locking
patchset since the patch would need to be refactored when
proc->vmm_vm_mm is removed from struct binder_proc and added
in the binder allocator.
Signed-off-by: Todd Kjos <tkjos(a)google.com>
Cc: stable <stable(a)vger.kernel.org> # 4.6+
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 15b263a..b51fedc 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -3246,10 +3246,6 @@ static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
/*pr_info("binder_ioctl: %d:%d %x %lx\n",
proc->pid, current->pid, cmd, arg);*/
- if (unlikely(current->mm != proc->vma_vm_mm)) {
- pr_err("current mm mismatch proc mm\n");
- return -EINVAL;
- }
trace_binder_ioctl(cmd, arg);
ret = wait_event_interruptible(binder_user_error_wait, binder_stop_on_user_error < 2);
@@ -3465,7 +3461,6 @@ static int binder_open(struct inode *nodp, struct file *filp)
return -ENOMEM;
get_task_struct(current);
proc->tsk = current;
- proc->vma_vm_mm = current->mm;
INIT_LIST_HEAD(&proc->todo);
init_waitqueue_head(&proc->wait);
proc->default_priority = task_nice(current);
--
2.7.4
From: Martijn Coenen <maco(a)android.com>
binder_fd_array_object starts with a 4-byte header,
followed by a few fields that are 8 bytes when
ANDROID_BINDER_IPC_32BIT=N.
This can cause alignment issues in a 64-bit kernel
with a 32-bit userspace, as on x86_32 an 8-byte primitive
may be aligned to a 4-byte address. Pad with a __u32
to fix this.
Signed-off-by: Martijn Coenen <maco(a)android.com>
Cc: stable <stable(a)vger.kernel.org> # 4.11+
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/uapi/linux/android/binder.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/android/binder.h b/include/uapi/linux/android/binder.h
index 51f891f..7668b57 100644
--- a/include/uapi/linux/android/binder.h
+++ b/include/uapi/linux/android/binder.h
@@ -132,6 +132,7 @@ enum {
/* struct binder_fd_array_object - object describing an array of fds in a buffer
* @hdr: common header structure
+ * @pad: padding to ensure correct alignment
* @num_fds: number of file descriptors in the buffer
* @parent: index in offset array to buffer holding the fd array
* @parent_offset: start offset of fd array in the buffer
@@ -152,6 +153,7 @@ enum {
*/
struct binder_fd_array_object {
struct binder_object_header hdr;
+ __u32 pad;
binder_size_t num_fds;
binder_size_t parent;
binder_size_t parent_offset;
--
2.7.4
From: Lisa Du <cldu(a)marvell.com>
There's one point was missed in the patch commit da49889deb34 ("staging:
binder: Support concurrent 32 bit and 64 bit processes."). When configure
BINDER_IPC_32BIT, the size of binder_uintptr_t was 32bits, but size of
void * is 64bit on 64bit system. Correct it here.
Signed-off-by: Lisa Du <cldu(a)marvell.com>
Signed-off-by: Nicolas Boichat <drinkcat(a)chromium.org>
Fixes: da49889deb34 ("staging: binder: Support concurrent 32 bit and 64 bit processes.")
Cc: <stable(a)vger.kernel.org>
Acked-by: Olof Johansson <olof(a)lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/android/binder.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 796301a..16288e7 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -2081,7 +2081,7 @@ static int binder_thread_write(struct binder_proc *proc,
if (get_user(cookie, (binder_uintptr_t __user *)ptr))
return -EFAULT;
- ptr += sizeof(void *);
+ ptr += sizeof(cookie);
list_for_each_entry(w, &proc->delivered_death, entry) {
struct binder_ref_death *tmp_death = container_of(w, struct binder_ref_death, work);
--
2.7.4
1. With the patch "x86/vector/msi: Switch to global reservation mode"
(4900be8360), the recent v4.15 and newer kernels always hang for 1-vCPU
Hyper-V VM with SR-IOV. This is because when we reach hv_compose_msi_msg()
by request_irq() -> request_threaded_irq() -> __setup_irq()->irq_startup()
-> __irq_startup() -> irq_domain_activate_irq() -> ... ->
msi_domain_activate() -> ... -> hv_compose_msi_msg(), local irq is
disabled in __setup_irq().
Fix this by polling the channel.
2. If the host is ejecting the VF device before we reach
hv_compose_msi_msg(), in a UP VM, we can hang in hv_compose_msi_msg()
forever, because at this time the host doesn't respond to the
CREATE_INTERRUPT request. This issue also happens to old kernels like
v4.14, v4.13, etc.
Fix this by polling the channel for the PCI_EJECT message and
hpdev->state, and by checking the PCI vendor ID.
Note: actually the above issues also happen to a SMP VM, if
"hbus->hdev->channel->target_cpu == smp_processor_id()" is true.
Signed-off-by: Dexuan Cui <decui(a)microsoft.com>
Tested-by: Adrian Suhov <v-adsuho(a)microsoft.com>
Tested-by: Chris Valean <v-chvale(a)microsoft.com>
Cc: stable(a)vger.kernel.org
Cc: Stephen Hemminger <sthemmin(a)microsoft.com>
Cc: K. Y. Srinivasan <kys(a)microsoft.com>
Cc: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Cc: Jack Morgenstein <jackm(a)mellanox.com>
---
drivers/pci/host/pci-hyperv.c | 58 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index d3aa6736a9bb..114624dfbd97 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -521,6 +521,8 @@ struct hv_pci_compl {
s32 completion_status;
};
+static void hv_pci_onchannelcallback(void *context);
+
/**
* hv_pci_generic_compl() - Invoked for a completion packet
* @context: Set up by the sender of the packet.
@@ -665,6 +667,31 @@ static void _hv_pcifront_read_config(struct hv_pci_dev *hpdev, int where,
}
}
+static u16 hv_pcifront_get_vendor_id(struct hv_pci_dev *hpdev)
+{
+ u16 ret;
+ unsigned long flags;
+ void __iomem *addr = hpdev->hbus->cfg_addr + CFG_PAGE_OFFSET +
+ PCI_VENDOR_ID;
+
+ spin_lock_irqsave(&hpdev->hbus->config_lock, flags);
+
+ /* Choose the function to be read. (See comment above) */
+ writel(hpdev->desc.win_slot.slot, hpdev->hbus->cfg_addr);
+ /* Make sure the function was chosen before we start reading. */
+ mb();
+ /* Read from that function's config space. */
+ ret = readw(addr);
+ /*
+ * mb() is not required here, because the spin_unlock_irqrestore()
+ * is a barrier.
+ */
+
+ spin_unlock_irqrestore(&hpdev->hbus->config_lock, flags);
+
+ return ret;
+}
+
/**
* _hv_pcifront_write_config() - Internal PCI config write
* @hpdev: The PCI driver's representation of the device
@@ -1107,8 +1134,37 @@ static void hv_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
* Since this function is called with IRQ locks held, can't
* do normal wait for completion; instead poll.
*/
- while (!try_wait_for_completion(&comp.comp_pkt.host_event))
+ while (!try_wait_for_completion(&comp.comp_pkt.host_event)) {
+ /* 0xFFFF means an invalid PCI VENDOR ID. */
+ if (hv_pcifront_get_vendor_id(hpdev) == 0xFFFF) {
+ dev_err_once(&hbus->hdev->device,
+ "the device has gone\n");
+ goto free_int_desc;
+ }
+
+ /*
+ * When the higher level interrupt code calls us with
+ * interrupt disabled, we must poll the channel by calling
+ * the channel callback directly when channel->target_cpu is
+ * the current CPU. When the higher level interrupt code
+ * calls us with interrupt enabled, let's add the
+ * local_bh_disable()/enable() to avoid race.
+ */
+ local_bh_disable();
+
+ if (hbus->hdev->channel->target_cpu == smp_processor_id())
+ hv_pci_onchannelcallback(hbus);
+
+ local_bh_enable();
+
+ if (hpdev->state == hv_pcichild_ejecting) {
+ dev_err_once(&hbus->hdev->device,
+ "the device is being ejected\n");
+ goto free_int_desc;
+ }
+
udelay(100);
+ }
if (comp.comp_pkt.completion_status < 0) {
dev_err(&hbus->hdev->device,
--
2.7.4
Since we serialize the present/eject work items now, we don't need the
semaphore any more.
This is suggested by Michael Kelley.
Signed-off-by: Dexuan Cui <decui(a)microsoft.com>
Cc: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Cc: Jack Morgenstein <jackm(a)mellanox.com>
Cc: stable(a)vger.kernel.org
Cc: Stephen Hemminger <sthemmin(a)microsoft.com>
Cc: K. Y. Srinivasan <kys(a)microsoft.com>
Cc: Michael Kelley (EOSG) <Michael.H.Kelley(a)microsoft.com>
---
drivers/pci/host/pci-hyperv.c | 17 ++---------------
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index aaee41faf55f..3a385212f666 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -447,7 +447,6 @@ struct hv_pcibus_device {
spinlock_t device_list_lock; /* Protect lists below */
void __iomem *cfg_addr;
- struct semaphore enum_sem;
struct list_head resources_for_children;
struct list_head children;
@@ -1592,12 +1591,8 @@ static struct hv_pci_dev *get_pcichild_wslot(struct hv_pcibus_device *hbus,
* It must also treat the omission of a previously observed device as
* notification that the device no longer exists.
*
- * Note that this function is a work item, and it may not be
- * invoked in the order that it was queued. Back to back
- * updates of the list of present devices may involve queuing
- * multiple work items, and this one may run before ones that
- * were sent later. As such, this function only does something
- * if is the last one in the queue.
+ * Note that this function is serialized with hv_eject_device_work(),
+ * because both are pushed to the ordered workqueue hbus->wq.
*/
static void pci_devices_present_work(struct work_struct *work)
{
@@ -1618,11 +1613,6 @@ static void pci_devices_present_work(struct work_struct *work)
INIT_LIST_HEAD(&removed);
- if (down_interruptible(&hbus->enum_sem)) {
- put_hvpcibus(hbus);
- return;
- }
-
/* Pull this off the queue and process it if it was the last one. */
spin_lock_irqsave(&hbus->device_list_lock, flags);
while (!list_empty(&hbus->dr_list)) {
@@ -1639,7 +1629,6 @@ static void pci_devices_present_work(struct work_struct *work)
spin_unlock_irqrestore(&hbus->device_list_lock, flags);
if (!dr) {
- up(&hbus->enum_sem);
put_hvpcibus(hbus);
return;
}
@@ -1726,7 +1715,6 @@ static void pci_devices_present_work(struct work_struct *work)
break;
}
- up(&hbus->enum_sem);
put_hvpcibus(hbus);
kfree(dr);
}
@@ -2460,7 +2448,6 @@ static int hv_pci_probe(struct hv_device *hdev,
spin_lock_init(&hbus->config_lock);
spin_lock_init(&hbus->device_list_lock);
spin_lock_init(&hbus->retarget_msi_interrupt_lock);
- sema_init(&hbus->enum_sem, 1);
init_completion(&hbus->remove_event);
hbus->wq = alloc_ordered_workqueue("hv_pci_%x", 0,
hbus->sysdata.domain);
--
2.7.4
When we're in the function, hpdev->state must be hv_pcichild_ejecting:
see hv_pci_eject_device().
Signed-off-by: Dexuan Cui <decui(a)microsoft.com>
Cc: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Cc: Jack Morgenstein <jackm(a)mellanox.com>
Cc: stable(a)vger.kernel.org
Cc: Stephen Hemminger <sthemmin(a)microsoft.com>
Cc: K. Y. Srinivasan <kys(a)microsoft.com>
Cc: Michael Kelley (EOSG) <Michael.H.Kelley(a)microsoft.com>
---
drivers/pci/host/pci-hyperv.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 1233300f41c6..04edb24c92ee 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1796,10 +1796,7 @@ static void hv_eject_device_work(struct work_struct *work)
hpdev = container_of(work, struct hv_pci_dev, wrk);
- if (hpdev->state != hv_pcichild_ejecting) {
- put_pcichild(hpdev, hv_pcidev_ref_pnp);
- return;
- }
+ WARN_ON(hpdev->state != hv_pcichild_ejecting);
/*
* Ejection can come before or after the PCI bus has been set up, so
--
2.7.4
No functional change.
Signed-off-by: Dexuan Cui <decui(a)microsoft.com>
Fixes: bdd74440d9e8 ("PCI: hv: Add explicit barriers to config space access")
Cc: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Cc: stable(a)vger.kernel.org
Cc: Stephen Hemminger <sthemmin(a)microsoft.com>
Cc: K. Y. Srinivasan <kys(a)microsoft.com>
---
drivers/pci/host/pci-hyperv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 2faf38eab785..1233300f41c6 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -653,7 +653,7 @@ static void _hv_pcifront_read_config(struct hv_pci_dev *hpdev, int where,
break;
}
/*
- * Make sure the write was done before we release the spinlock
+ * Make sure the read was done before we release the spinlock
* allowing consecutive reads/writes.
*/
mb();
--
2.7.4
From: James Bottomley <James.Bottomley(a)HansenPartnership.com>
My Nuvoton 6xx in a Dell XPS-13 has been intermittently failing to work
(necessitating a reboot). The problem seems to be that the TPM gets into a
state where the partial self-test doesn't return TPM_RC_SUCCESS (meaning
all tests have run to completion), but instead returns TPM_RC_TESTING
(meaning some tests are still running in the background). There are
various theories that resending the self-test command actually causes the
tests to restart and thus triggers more TPM_RC_TESTING returns until the
timeout is exceeded.
There are several issues here: firstly being we shouldn't slow down the
boot sequence waiting for the self test to complete once the TPM
backgrounds them. It will actually make available all functions that have
passed and if it gets a failure return TPM_RC_FAILURE to every subsequent
command. So the fix is to kick off self tests once and if they return
TPM_RC_TESTING log that as a backgrounded self test and continue on. In
order to prevent other tpm users from seeing any TPM_RC_TESTING returns
(which it might if they send a command that needs a TPM subsystem which is
still under test), we loop in tpm_transmit_cmd until either a timeout or we
don't get a TPM_RC_TESTING return.
Finally, there have been observations of strange returns from a partial
test. One Nuvoton is occasionally returning TPM_RC_COMMAND_CODE, so treat
any unexpected return from a partial self test as an indication we need to
run a full self test.
[jarkko.sakkinen(a)linux.intel.com: cleaned up James' original commit and
added a proper Fixes line]
Fixes: 2482b1bba5122 ("tpm: Trigger only missing TPM 2.0 self tests")
Cc: stable(a)vger.kernel.org
Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkine(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkine(a)linux.intel.com>
---
drivers/char/tpm/tpm-interface.c | 20 ++++++++++++---
drivers/char/tpm/tpm.h | 1 +
drivers/char/tpm/tpm2-cmd.c | 54 ++++++++++++----------------------------
3 files changed, 33 insertions(+), 42 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 9e80a953d693..1adb976a2e37 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -537,14 +537,26 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_space *space,
const char *desc)
{
const struct tpm_output_header *header = buf;
+ unsigned int delay_msec = TPM2_DURATION_SHORT;
int err;
ssize_t len;
- len = tpm_transmit(chip, space, (u8 *)buf, bufsiz, flags);
- if (len < 0)
- return len;
+ for (;;) {
+ len = tpm_transmit(chip, space, (u8 *)buf, bufsiz, flags);
+ if (len < 0)
+ return len;
+ err = be32_to_cpu(header->return_code);
+ if (err != TPM2_RC_TESTING)
+ break;
+
+ delay_msec *= 2;
+ if (delay_msec > TPM2_DURATION_LONG) {
+ dev_err(&chip->dev, "the self test is still running\n");
+ break;
+ }
+ tpm_msleep(delay_msec);
+ }
- err = be32_to_cpu(header->return_code);
if (err != 0 && desc)
dev_err(&chip->dev, "A TPM error (%d) occurred %s\n", err,
desc);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f895fba4e20d..cccd5994a0e1 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -104,6 +104,7 @@ enum tpm2_return_codes {
TPM2_RC_HASH = 0x0083, /* RC_FMT1 */
TPM2_RC_HANDLE = 0x008B,
TPM2_RC_INITIALIZE = 0x0100, /* RC_VER1 */
+ TPM2_RC_FAILURE = 0x0101,
TPM2_RC_DISABLED = 0x0120,
TPM2_RC_COMMAND_CODE = 0x0143,
TPM2_RC_TESTING = 0x090A, /* RC_WARN */
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index a700f8f9ead7..89a5397b18d2 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -31,10 +31,6 @@ struct tpm2_startup_in {
__be16 startup_type;
} __packed;
-struct tpm2_self_test_in {
- u8 full_test;
-} __packed;
-
struct tpm2_get_tpm_pt_in {
__be32 cap_id;
__be32 property_id;
@@ -60,7 +56,6 @@ struct tpm2_get_random_out {
union tpm2_cmd_params {
struct tpm2_startup_in startup_in;
- struct tpm2_self_test_in selftest_in;
struct tpm2_get_tpm_pt_in get_tpm_pt_in;
struct tpm2_get_tpm_pt_out get_tpm_pt_out;
struct tpm2_get_random_in getrandom_in;
@@ -827,16 +822,6 @@ unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal)
}
EXPORT_SYMBOL_GPL(tpm2_calc_ordinal_duration);
-#define TPM2_SELF_TEST_IN_SIZE \
- (sizeof(struct tpm_input_header) + \
- sizeof(struct tpm2_self_test_in))
-
-static const struct tpm_input_header tpm2_selftest_header = {
- .tag = cpu_to_be16(TPM2_ST_NO_SESSIONS),
- .length = cpu_to_be32(TPM2_SELF_TEST_IN_SIZE),
- .ordinal = cpu_to_be32(TPM2_CC_SELF_TEST)
-};
-
/**
* tpm2_do_selftest() - ensure that all self tests have passed
*
@@ -852,27 +837,24 @@ static const struct tpm_input_header tpm2_selftest_header = {
*/
static int tpm2_do_selftest(struct tpm_chip *chip)
{
+ struct tpm_buf buf;
+ int full;
int rc;
- unsigned int delay_msec = 10;
- long duration;
- struct tpm2_cmd cmd;
- duration = jiffies_to_msecs(
- tpm2_calc_ordinal_duration(chip, TPM2_CC_SELF_TEST));
-
- while (1) {
- cmd.header.in = tpm2_selftest_header;
- cmd.params.selftest_in.full_test = 0;
-
- rc = tpm_transmit_cmd(chip, NULL, &cmd, TPM2_SELF_TEST_IN_SIZE,
- 0, 0, "continue selftest");
+ for (full = 0; full < 2; full++) {
+ rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_SELF_TEST);
+ if (rc)
+ return rc;
- if (rc != TPM2_RC_TESTING || delay_msec >= duration)
- break;
+ tpm_buf_append_u8(&buf, full);
+ rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0,
+ "attempting the self test");
+ tpm_buf_destroy(&buf);
- /* wait longer than before */
- delay_msec *= 2;
- tpm_msleep(delay_msec);
+ if (rc == TPM2_RC_TESTING)
+ rc = TPM2_RC_SUCCESS;
+ if (rc == TPM2_RC_INITIALIZE || rc == TPM2_RC_SUCCESS)
+ return rc;
}
return rc;
@@ -1058,10 +1040,8 @@ int tpm2_auto_startup(struct tpm_chip *chip)
goto out;
rc = tpm2_do_selftest(chip);
- if (rc != 0 && rc != TPM2_RC_INITIALIZE) {
- dev_err(&chip->dev, "TPM self test failed\n");
+ if (rc && rc != TPM2_RC_INITIALIZE)
goto out;
- }
if (rc == TPM2_RC_INITIALIZE) {
rc = tpm_startup(chip);
@@ -1069,10 +1049,8 @@ int tpm2_auto_startup(struct tpm_chip *chip)
goto out;
rc = tpm2_do_selftest(chip);
- if (rc) {
- dev_err(&chip->dev, "TPM self test failed\n");
+ if (rc)
goto out;
- }
}
rc = tpm2_get_pcr_allocation(chip);
--
2.15.1
This is an automatic generated email to let you know that the following patch were queued:
Subject: media: tegra-cec: reset rx_buf_cnt when start bit detected
Author: Hans Verkuil <hverkuil(a)xs4all.nl>
Date: Wed Feb 28 05:47:07 2018 -0500
If a start bit is detected, then reset the receive buffer counter to 0.
This ensures that no stale data is in the buffer if a message is
broken off midstream due to e.g. a Low Drive condition and then
retransmitted.
The only Rx interrupts we need to listen to are RX_REGISTER_FULL (i.e.
a valid byte was received) and RX_START_BIT_DETECTED (i.e. a new
message starts and we need to reset the counter).
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Cc: <stable(a)vger.kernel.org> # for v4.15 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
drivers/media/platform/tegra-cec/tegra_cec.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
---
diff --git a/drivers/media/platform/tegra-cec/tegra_cec.c b/drivers/media/platform/tegra-cec/tegra_cec.c
index 92f93a880015..aba488cd0e64 100644
--- a/drivers/media/platform/tegra-cec/tegra_cec.c
+++ b/drivers/media/platform/tegra-cec/tegra_cec.c
@@ -172,16 +172,13 @@ static irqreturn_t tegra_cec_irq_handler(int irq, void *data)
}
}
- if (status & (TEGRA_CEC_INT_STAT_RX_REGISTER_OVERRUN |
- TEGRA_CEC_INT_STAT_RX_BUS_ANOMALY_DETECTED |
- TEGRA_CEC_INT_STAT_RX_START_BIT_DETECTED |
- TEGRA_CEC_INT_STAT_RX_BUS_ERROR_DETECTED)) {
+ if (status & TEGRA_CEC_INT_STAT_RX_START_BIT_DETECTED) {
cec_write(cec, TEGRA_CEC_INT_STAT,
- (TEGRA_CEC_INT_STAT_RX_REGISTER_OVERRUN |
- TEGRA_CEC_INT_STAT_RX_BUS_ANOMALY_DETECTED |
- TEGRA_CEC_INT_STAT_RX_START_BIT_DETECTED |
- TEGRA_CEC_INT_STAT_RX_BUS_ERROR_DETECTED));
- } else if (status & TEGRA_CEC_INT_STAT_RX_REGISTER_FULL) {
+ TEGRA_CEC_INT_STAT_RX_START_BIT_DETECTED);
+ cec->rx_done = false;
+ cec->rx_buf_cnt = 0;
+ }
+ if (status & TEGRA_CEC_INT_STAT_RX_REGISTER_FULL) {
u32 v;
cec_write(cec, TEGRA_CEC_INT_STAT,
@@ -255,7 +252,7 @@ static int tegra_cec_adap_enable(struct cec_adapter *adap, bool enable)
TEGRA_CEC_INT_MASK_TX_BUS_ANOMALY_DETECTED |
TEGRA_CEC_INT_MASK_TX_FRAME_TRANSMITTED |
TEGRA_CEC_INT_MASK_RX_REGISTER_FULL |
- TEGRA_CEC_INT_MASK_RX_REGISTER_OVERRUN);
+ TEGRA_CEC_INT_MASK_RX_START_BIT_DETECTED);
cec_write(cec, TEGRA_CEC_HW_CONTROL, TEGRA_CEC_HWCTRL_TX_RX_MODE);
return 0;
From: Alexander Steffen <Alexander.Steffen(a)infineon.com>
My Nuvoton 6xx in a Dell XPS-13 has been intermittently failing to work
(necessitating a reboot). The problem seems to be that the TPM gets into a
state where the partial self-test doesn't return TPM_RC_SUCCESS (meaning
all tests have run to completion), but instead returns TPM_RC_TESTING
(meaning some tests are still running in the background). There are
various theories that resending the self-test command actually causes the
tests to restart and thus triggers more TPM_RC_TESTING returns until the
timeout is exceeded.
There are several issues here: firstly being we shouldn't slow down the
boot sequence waiting for the self test to complete once the TPM
backgrounds them. It will actually make available all functions that have
passed and if it gets a failure return TPM_RC_FAILURE to every subsequent
command. So the fix is to kick off self tests once and if they return
TPM_RC_TESTING log that as a backgrounded self test and continue on. In
order to prevent other tpm users from seeing any TPM_RC_TESTING returns
(which it might if they send a command that needs a TPM subsystem which is
still under test), we loop in tpm_transmit_cmd until either a timeout or we
don't get a TPM_RC_TESTING return.
Finally, there have been observations of strange returns from a partial
test. One Nuvoton is occasionally returning TPM_RC_COMMAND_CODE, so treat
any unexpected return from a partial self test as an indication we need to
run a full self test.
Fixes: 2482b1bba5122 ("tpm: Trigger only missing TPM 2.0 self tests")
Cc: stable(a)vger.kernel.org
Signed-off-by: Alexander Steffen <Alexander.Steffen(a)infineon.com>
Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkine(a)linux.intel.com>
---
drivers/char/tpm/tpm-interface.c | 20 ++++++++++++---
drivers/char/tpm/tpm.h | 1 +
drivers/char/tpm/tpm2-cmd.c | 54 ++++++++++++----------------------------
3 files changed, 33 insertions(+), 42 deletions(-)
diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
index 9e80a953d693..1adb976a2e37 100644
--- a/drivers/char/tpm/tpm-interface.c
+++ b/drivers/char/tpm/tpm-interface.c
@@ -537,14 +537,26 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_space *space,
const char *desc)
{
const struct tpm_output_header *header = buf;
+ unsigned int delay_msec = TPM2_DURATION_SHORT;
int err;
ssize_t len;
- len = tpm_transmit(chip, space, (u8 *)buf, bufsiz, flags);
- if (len < 0)
- return len;
+ for (;;) {
+ len = tpm_transmit(chip, space, (u8 *)buf, bufsiz, flags);
+ if (len < 0)
+ return len;
+ err = be32_to_cpu(header->return_code);
+ if (err != TPM2_RC_TESTING)
+ break;
+
+ delay_msec *= 2;
+ if (delay_msec > TPM2_DURATION_LONG) {
+ dev_err(&chip->dev, "the self test is still running\n");
+ break;
+ }
+ tpm_msleep(delay_msec);
+ }
- err = be32_to_cpu(header->return_code);
if (err != 0 && desc)
dev_err(&chip->dev, "A TPM error (%d) occurred %s\n", err,
desc);
diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index f895fba4e20d..cccd5994a0e1 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -104,6 +104,7 @@ enum tpm2_return_codes {
TPM2_RC_HASH = 0x0083, /* RC_FMT1 */
TPM2_RC_HANDLE = 0x008B,
TPM2_RC_INITIALIZE = 0x0100, /* RC_VER1 */
+ TPM2_RC_FAILURE = 0x0101,
TPM2_RC_DISABLED = 0x0120,
TPM2_RC_COMMAND_CODE = 0x0143,
TPM2_RC_TESTING = 0x090A, /* RC_WARN */
diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
index a700f8f9ead7..6eeff3a60003 100644
--- a/drivers/char/tpm/tpm2-cmd.c
+++ b/drivers/char/tpm/tpm2-cmd.c
@@ -31,10 +31,6 @@ struct tpm2_startup_in {
__be16 startup_type;
} __packed;
-struct tpm2_self_test_in {
- u8 full_test;
-} __packed;
-
struct tpm2_get_tpm_pt_in {
__be32 cap_id;
__be32 property_id;
@@ -60,7 +56,6 @@ struct tpm2_get_random_out {
union tpm2_cmd_params {
struct tpm2_startup_in startup_in;
- struct tpm2_self_test_in selftest_in;
struct tpm2_get_tpm_pt_in get_tpm_pt_in;
struct tpm2_get_tpm_pt_out get_tpm_pt_out;
struct tpm2_get_random_in getrandom_in;
@@ -827,16 +822,6 @@ unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal)
}
EXPORT_SYMBOL_GPL(tpm2_calc_ordinal_duration);
-#define TPM2_SELF_TEST_IN_SIZE \
- (sizeof(struct tpm_input_header) + \
- sizeof(struct tpm2_self_test_in))
-
-static const struct tpm_input_header tpm2_selftest_header = {
- .tag = cpu_to_be16(TPM2_ST_NO_SESSIONS),
- .length = cpu_to_be32(TPM2_SELF_TEST_IN_SIZE),
- .ordinal = cpu_to_be32(TPM2_CC_SELF_TEST)
-};
-
/**
* tpm2_do_selftest() - ensure that all self tests have passed
*
@@ -852,27 +837,24 @@ static const struct tpm_input_header tpm2_selftest_header = {
*/
static int tpm2_do_selftest(struct tpm_chip *chip)
{
+ struct tpm_buf buf;
+ int full;
int rc;
- unsigned int delay_msec = 10;
- long duration;
- struct tpm2_cmd cmd;
- duration = jiffies_to_msecs(
- tpm2_calc_ordinal_duration(chip, TPM2_CC_SELF_TEST));
-
- while (1) {
- cmd.header.in = tpm2_selftest_header;
- cmd.params.selftest_in.full_test = 0;
-
- rc = tpm_transmit_cmd(chip, NULL, &cmd, TPM2_SELF_TEST_IN_SIZE,
- 0, 0, "continue selftest");
+ for (full = 0; full < 2; full++) {
+ rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_SELF_TEST);
+ if (rc)
+ return rc;
- if (rc != TPM2_RC_TESTING || delay_msec >= duration)
- break;
+ tpm_buf_append_u8(&buf, full);
+ rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0,
+ "attempting the self test\n");
+ tpm_buf_destroy(&buf);
- /* wait longer than before */
- delay_msec *= 2;
- tpm_msleep(delay_msec);
+ if (rc == TPM2_RC_TESTING)
+ rc = TPM2_RC_SUCCESS;
+ if (rc == TPM2_RC_INITIALIZE || rc == TPM2_RC_SUCCESS)
+ return rc;
}
return rc;
@@ -1058,10 +1040,8 @@ int tpm2_auto_startup(struct tpm_chip *chip)
goto out;
rc = tpm2_do_selftest(chip);
- if (rc != 0 && rc != TPM2_RC_INITIALIZE) {
- dev_err(&chip->dev, "TPM self test failed\n");
+ if (rc && rc != TPM2_RC_INITIALIZE)
goto out;
- }
if (rc == TPM2_RC_INITIALIZE) {
rc = tpm_startup(chip);
@@ -1069,10 +1049,8 @@ int tpm2_auto_startup(struct tpm_chip *chip)
goto out;
rc = tpm2_do_selftest(chip);
- if (rc) {
- dev_err(&chip->dev, "TPM self test failed\n");
+ if (rc)
goto out;
- }
}
rc = tpm2_get_pcr_allocation(chip);
--
2.15.1
On Mon, Mar 5, 2018 at 11:42 AM, Mark Brown <broonie(a)kernel.org> wrote:
> On Sat, Mar 03, 2018 at 10:29:00PM +0000, Sasha Levin wrote:
>> From: Javier Martinez Canillas <javier(a)osg.samsung.com>
>>
>> [ Upstream commit 9ba2da5f5d18daaa365ab5426b05e16f1d114786 ]
>>
>> The driver doesn't have a struct of_device_id table but supported devices
>> are registered via Device Trees. This is working on the assumption that a
>> I2C device registered via OF will always match a legacy I2C device ID and
>> that the MODALIAS reported will always be of the form i2c:<device>.
>>
>> But this could change in the future so the correct approach is to have an
>> OF device ID table if the devices are registered via OF.
>
> As the commit message itself says this is not fixing anything, it's
> defence against future changes.
That's correct.
These were just preparatory patches for a change in the I2C subsystem
to properly report OF module aliases [0]. So these will only be
relevant once [0] is merged, but that patch will never be backported
to a stable kernel.
[0]: https://patchwork.kernel.org/patch/10089425/
Best regards,
Javier
From: Alexander Steffen <Alexander.Steffen(a)infineon.com>
commit ee70bc1e7b63ac8023c9ff9475d8741e397316e7 upstream.
tpm_transmit() does not offer an explicit interface to indicate the number
of valid bytes in the communication buffer. Instead, it relies on the
commandSize field in the TPM header that is encoded within the buffer.
Therefore, ensure that a) enough data has been written to the buffer, so
that the commandSize field is present and b) the commandSize field does not
announce more data than has been written to the buffer.
This should have been fixed with CVE-2011-1161 long ago, but apparently
a correct version of that patch never made it into the kernel.
Cc: stable(a)vger.kernel.org
Signed-off-by: Alexander Steffen <Alexander.Steffen(a)infineon.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
---
drivers/char/tpm/tpm-dev.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/char/tpm/tpm-dev.c b/drivers/char/tpm/tpm-dev.c
index 912ad30be585..65b824954bdc 100644
--- a/drivers/char/tpm/tpm-dev.c
+++ b/drivers/char/tpm/tpm-dev.c
@@ -136,6 +136,12 @@ static ssize_t tpm_write(struct file *file, const char __user *buf,
return -EFAULT;
}
+ if (in_size < 6 ||
+ in_size < be32_to_cpu(*((__be32 *) (priv->data_buffer + 2)))) {
+ mutex_unlock(&priv->buffer_mutex);
+ return -EINVAL;
+ }
+
/* atomic tpm command send and result receive. We only hold the ops
* lock during this period so that the tpm can be unregistered even if
* the char dev is held open.
--
2.15.1
No functional change.
Signed-off-by: Dexuan Cui <decui(a)microsoft.com>
Fixes: bdd74440d9e8 ("PCI: hv: Add explicit barriers to config space access")
Cc: Vitaly Kuznetsov <vkuznets(a)redhat.com>
Cc: stable(a)vger.kernel.org
Cc: Stephen Hemminger <sthemmin(a)microsoft.com>
Cc: K. Y. Srinivasan <kys(a)microsoft.com>
---
drivers/pci/host/pci-hyperv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-hyperv.c b/drivers/pci/host/pci-hyperv.c
index 2faf38eab785..1233300f41c6 100644
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -653,7 +653,7 @@ static void _hv_pcifront_read_config(struct hv_pci_dev *hpdev, int where,
break;
}
/*
- * Make sure the write was done before we release the spinlock
+ * Make sure the read was done before we release the spinlock
* allowing consecutive reads/writes.
*/
mb();
--
2.7.4
Tree/Branch: v3.2.100
Git describe: v3.2.100
Commit: 1c7cb8cda9 Linux 3.2.100
Build Time: 0 min 4 sec
Passed: 0 / 4 ( 0.00 %)
Failed: 4 / 4 (100.00 %)
Errors: 6
Warnings: 20
Section Mismatches: 0
Failed defconfigs:
x86_64-allnoconfig
arm-allmodconfig
arm-allnoconfig
x86_64-defconfig
Errors:
x86_64-allnoconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
arm-allnoconfig
/home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
x86_64-defconfig
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
2 warnings 0 mismatches : arm-allmodconfig
19 warnings 0 mismatches : arm-allnoconfig
-------------------------------------------------------------------------------
Errors summary: 6
2 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
2 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
1 /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
Warnings Summary: 20
2 .config:27:warning: symbol value '' invalid for PHYS_OFFSET
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
1 /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches
Warnings:
.config:27:warning: symbol value '' invalid for PHYS_OFFSET
.config:27:warning: symbol value '' invalid for PHYS_OFFSET
-------------------------------------------------------------------------------
arm-allnoconfig : FAIL, 4 errors, 19 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function)
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type
/home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type
Warnings:
/home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
/home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef]
-------------------------------------------------------------------------------
x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches
Errors:
/home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode
/home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
Tree/Branch: v3.16.55
Git describe: v3.16.55
Commit: 3e50cd97ed Linux 3.16.55
Build Time: 34 min 38 sec
Passed: 9 / 9 (100.00 %)
Failed: 0 / 9 ( 0.00 %)
Errors: 0
Warnings: 7
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
1 warnings 0 mismatches : x86_64-allnoconfig
1 warnings 0 mismatches : arm64-allmodconfig
1 warnings 0 mismatches : x86_64-defconfig
4 warnings 0 mismatches : arm-allmodconfig
2 warnings 0 mismatches : arm64-defconfig
-------------------------------------------------------------------------------
Warnings Summary: 7
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: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:
-------------------------------------------------------------------------------
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-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
Warnings:
../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable]
-------------------------------------------------------------------------------
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, 4 warnings, 0 section mismatches
Warnings:
../drivers/mtd/nand/omap2.c:1318:12: warning: 'omap_calculate_ecc_bch_multi' defined but not used [-Wunused-function]
../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable]
../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]
-------------------------------------------------------------------------------
arm64-defconfig : PASS, 0 errors, 2 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]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm-multi_v7_defconfig
arm-allnoconfig
arm-multi_v5_defconfig
On Sun, Mar 4, 2018 at 7:21 AM, kbuild test robot
<fengguang.wu(a)intel.com> wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
> head: 85afb4e51ccfdb10f2969b24439ae2887fe0fcff
> commit: c0ecbd663fe6961c6ff181a211f090005858656f [6083/6211] scsi: advansys: fix uninitialized data access
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
> reproduce:
> git checkout c0ecbd663fe6961c6ff181a211f090005858656f
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All warnings (new ones prefixed by >>):
>
>>> warning: __mcount_loc already exists: drivers/net/wireless/intel/iwlwifi/mvm/rx.o
I'm pretty sure this is unrelated to my patch, but it's a recurring
problem that we should get
to the bottom of. Olof's autobuilder has reported the same thing for
the 3.18-stable tree
but not any others (for every single file in the kernel, not sure if
this warning only
shows up for all of them, or just one module).
Arnd
From: Jani Nikula <jani.nikula(a)intel.com>
[ Upstream commit 1d1c36650752b7fb81cee515a9bba4131cac4b7c ]
Since drm_edid_to_eld() knows the connector type, we can set the type in
ELD while at it. Most connectors this gets called on are not DP
encoders, and with the HDMI type being 0, this does not change behaviour
for non-DP.
For i915 having this in place earlier would have saved a considerable
amount of debugging that lead to the fix 2d8f63297b9f ("drm/i915: always
update ELD connector type after get modes"). I don't see other drivers,
even the ones calling drm_edid_to_eld() on DP connectors, setting the
connector type in ELD.
Cc: Alex Deucher <alexander.deucher(a)amd.com>
Cc: Christian König <christian.koenig(a)amd.com>
Cc: Archit Taneja <architt(a)codeaurora.org>
Cc: Andrzej Hajda <a.hajda(a)samsung.com>
Cc: Russell King <linux(a)armlinux.org.uk>
Cc: CK Hu <ck.hu(a)mediatek.com>
Cc: Philipp Zabel <p.zabel(a)pengutronix.de>
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Mark Yao <mark.yao(a)rock-chips.com>
Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
Cc: Vincent Abriou <vincent.abriou(a)st.com>
Cc: Thierry Reding <thierry.reding(a)gmail.com>
Cc: Eric Anholt <eric(a)anholt.net>
Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com>
Acked-by: Thierry Reding <treding(a)nvidia.com>
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d527b31619528c477c2c136f25cdf…
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
---
drivers/gpu/drm/drm_edid.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d52c9758d8cf..1f1fd3139c5b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3823,8 +3823,7 @@ EXPORT_SYMBOL(drm_edid_get_monitor_name);
* @edid: EDID to parse
*
* Fill the ELD (EDID-Like Data) buffer for passing to the audio driver. The
- * Conn_Type, HDCP and Port_ID ELD fields are left for the graphics driver to
- * fill in.
+ * HDCP and Port_ID ELD fields are left for the graphics driver to fill in.
*/
void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
{
@@ -3905,6 +3904,12 @@ void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid)
}
eld[5] |= total_sad_count << 4;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+ connector->connector_type == DRM_MODE_CONNECTOR_eDP)
+ eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_DP;
+ else
+ eld[DRM_ELD_SAD_COUNT_CONN_TYPE] |= DRM_ELD_CONN_TYPE_HDMI;
+
eld[DRM_ELD_BASELINE_ELD_LEN] =
DIV_ROUND_UP(drm_eld_calc_baseline_block_size(eld), 4);
--
2.14.1
Hi Sasha,
This is a backport to v4.1 of the RFI flush series that went upstream recently.
There's also a few other commits I noticed had not made it to v4.1.
cheers
From: Eric Biggers <ebiggers(a)google.com>
Hi Sasha, can you please apply these backports of ext4 encryption fixes
to 4.1-stable? They all have equivalent fixes in 4.4-stable. Most
important is patch 1 which prevents unprivileged users from using (or
abusing) ext4 encryption when it hasn't been enabled on the filesystem
by a system administrator. Patch 2 adds a missing permission check
(CVE-2016-10318), and patch 3 is a backport that Ted sent out some
months ago that seems to have been missed, for a bug in 4.1 that is very
similar to the bug in 4.2+ that was assigned CVE-2017-7374.
Note that ext4 encryption in 4.1 is still pretty broken and should not
be used (even just 4.4-stable is much better); these are just the most
important fixes that really ought to be in 4.1-stable.
Eric Biggers (1):
fscrypto: add authorization check for setting encryption policy
Richard Weinberger (1):
ext4: require encryption feature for EXT4_IOC_SET_ENCRYPTION_POLICY
Theodore Ts'o (1):
ext4 crypto: don't regenerate the per-inode encryption key
unnecessarily
fs/ext4/crypto_fname.c | 5 +++--
fs/ext4/crypto_key.c | 15 ++++++++++++---
fs/ext4/crypto_policy.c | 3 +++
fs/ext4/ext4.h | 1 +
fs/ext4/ioctl.c | 3 +++
fs/ext4/super.c | 3 +++
6 files changed, 25 insertions(+), 5 deletions(-)
--
2.16.2.395.g2e18187dfd-goog
On Fri, Mar 02, 2018 at 02:58:54PM +0100, Wolfram Sang wrote:
>
> > It needs platform maintainers to be motivated to fix it, and one way to
> > provide that motivation is for subsystem maintainers to say no to patches
> > like this. If patches like this get accepted, then the "problem" gets
> > solved, and there is very little motivation to fix the platform itself.
>
> Yes, I can see this. I will drop / revert the patch.
>
TBH, I can't find the threads from November so I feel a bit lost and
there is no documentation for platform_get_irq().
regards,
dan carpenter
With the alc289, the Pin 0x1b is Headphone-Mic, so we should assign
ALC269_FIXUP_DELL4_MIC_NO_PRESENCE rather than
ALC225_FIXUP_DELL1_MIC_NO_PRESENCE to it. And this change is suggested
by Kailang of Realtek and is verified on the machine.
(This fixes the commit 3f2f7c55)
Cc: Kailang Yang <kailang(a)realtek.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang(a)canonical.com>
---
sound/pci/hda/patch_realtek.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index b9c93fa..7a9a867 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -6872,7 +6872,7 @@ static const struct snd_hda_pin_quirk alc269_pin_fixup_tbl[] = {
{0x12, 0x90a60120},
{0x14, 0x90170110},
{0x21, 0x0321101f}),
- SND_HDA_PIN_QUIRK(0x10ec0289, 0x1028, "Dell", ALC225_FIXUP_DELL1_MIC_NO_PRESENCE,
+ SND_HDA_PIN_QUIRK(0x10ec0289, 0x1028, "Dell", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE,
{0x12, 0xb7a60130},
{0x14, 0x90170110},
{0x21, 0x04211020}),
--
2.7.4
This is the start of the stable review cycle for the 4.4.115 release.
There are 67 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Feb 4 14:07:31 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.115-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.4.115-rc1
Stefan Agner <stefan(a)agner.ch>
spi: imx: do not access registers while clocks disabled
Fabio Estevam <fabio.estevam(a)nxp.com>
serial: imx: Only wakeup via RTSDEN bit if the system has RTS/CTS
Mark Salyzyn <salyzyn(a)android.com>
selinux: general protection fault in sock_has_perm
Oliver Neukum <oneukum(a)suse.com>
usb: uas: unconditionally bring back host after reset
Hemant Kumar <hemantk(a)codeaurora.org>
usb: f_fs: Prevent gadget unbind if it is already unbound
Johan Hovold <johan(a)kernel.org>
USB: serial: simple: add Motorola Tetra driver
Shuah Khan <shuahkh(a)osg.samsung.com>
usbip: list: don't list devices attached to vhci_hcd
Shuah Khan <shuahkh(a)osg.samsung.com>
usbip: prevent bind loops on devices attached to vhci_hcd
Jia-Ju Bai <baijiaju1990(a)gmail.com>
USB: serial: io_edgeport: fix possible sleep-in-atomic
Oliver Neukum <oneukum(a)suse.com>
CDC-ACM: apply quirk for card reader
Hans de Goede <hdegoede(a)redhat.com>
USB: cdc-acm: Do not log urb submission errors on disconnect
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
USB: serial: pl2303: new device id for Chilitag
OKAMOTO Yoshiaki <yokamoto(a)allied-telesis.co.jp>
usb: option: Add support for FS040U modem
Larry Finger <Larry.Finger(a)lwfinger.net>
staging: rtl8188eu: Fix incorrect response to SIOCGIWESSID
Colin Ian King <colin.king(a)canonical.com>
usb: gadget: don't dereference g until after it has been null checked
Icenowy Zheng <icenowy(a)aosc.io>
media: usbtv: add a new usbid
Gustavo A. R. Silva <garsilva(a)embeddedor.com>
scsi: ufs: ufshcd: fix potential NULL pointer dereference in ufshcd_config_vreg
Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com>
scsi: aacraid: Prevent crash in case of free interrupt during scsi EH path
Darrick J. Wong <darrick.wong(a)oracle.com>
xfs: ubsan fixes
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
drm/omap: Fix error handling path in 'omap_dmm_probe()'
Yisheng Xie <xieyisheng1(a)huawei.com>
kmemleak: add scheduling point to kmemleak_scan()
Trond Myklebust <trond.myklebust(a)primarydata.com>
SUNRPC: Allow connect to return EHOSTUNREACH
Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
quota: Check for register_shrinker() failure.
Geert Uytterhoeven <geert+renesas(a)glider.be>
net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit
Robert Lippert <roblip(a)gmail.com>
hwmon: (pmbus) Use 64bit math for DIRECT format values
Vasily Averin <vvs(a)virtuozzo.com>
lockd: fix "list_add double add" caused by legacy signal interface
Andrew Elble <aweits(a)rit.edu>
nfsd: check for use of the closed special stateid
Vasily Averin <vvs(a)virtuozzo.com>
grace: replace BUG_ON by WARN_ONCE in exit_net hook
Trond Myklebust <trond.myklebust(a)primarydata.com>
nfsd: Ensure we check stateid validity in the seqid operation checks
Trond Myklebust <trond.myklebust(a)primarydata.com>
nfsd: CLOSE SHOULD return the invalid special stateid for NFSv4.x (x>0)
Eduardo Otubo <otubo(a)redhat.com>
xen-netfront: remove warning when unloading module
Wanpeng Li <wanpeng.li(a)hotmail.com>
KVM: VMX: Fix rflags cache during vCPU reset
Josef Bacik <jbacik(a)fb.com>
btrfs: fix deadlock when writing out space cache
Chun-Yeow Yeoh <yeohchunyeow(a)gmail.com>
mac80211: fix the update of path metric for RANN frame
zhangliping <zhangliping02(a)baidu.com>
openvswitch: fix the incorrect flow action alloc size
Felix Kuehling <Felix.Kuehling(a)amd.com>
drm/amdkfd: Fix SDMA oversubsription handling
shaoyunl <Shaoyun.Liu(a)amd.com>
drm/amdkfd: Fix SDMA ring buffer size calculation
Felix Kuehling <Felix.Kuehling(a)amd.com>
drm/amdgpu: Fix SDMA load/unload sequence on HWS disabled mode
Michael Lyle <mlyle(a)lyle.org>
bcache: check return value of register_shrinker
James Hogan <jhogan(a)kernel.org>
cpufreq: Add Loongson machine dependencies
Hans de Goede <hdegoede(a)redhat.com>
ACPI / bus: Leave modalias empty for devices which are not present
Nikita Leshenko <nikita.leshchenko(a)oracle.com>
KVM: x86: ioapic: Preserve read-only values in the redirection table
Nikita Leshenko <nikita.leshchenko(a)oracle.com>
KVM: x86: ioapic: Clear Remote IRR when entry is switched to edge-triggered
Nikita Leshenko <nikita.leshchenko(a)oracle.com>
KVM: x86: ioapic: Fix level-triggered EOI and IOAPIC reconfigure race
Wanpeng Li <wanpeng.li(a)hotmail.com>
KVM: X86: Fix operand/address-size during instruction decoding
Liran Alon <liran.alon(a)oracle.com>
KVM: x86: Don't re-execute instruction when not passing CR2 value
Liran Alon <liran.alon(a)oracle.com>
KVM: x86: emulator: Return to user-mode on L1 CPL=0 emulation failure
Lyude Paul <lyude(a)redhat.com>
igb: Free IRQs when device is hotplugged
Jesse Chan <jc(a)linux.com>
mtd: nand: denali_pci: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Jesse Chan <jc(a)linux.com>
gpio: ath79: add missing MODULE_DESCRIPTION/LICENSE
Jesse Chan <jc(a)linux.com>
gpio: iop: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Jesse Chan <jc(a)linux.com>
power: reset: zx-reboot: add missing MODULE_DESCRIPTION/AUTHOR/LICENSE
Stephan Mueller <smueller(a)chronox.de>
crypto: af_alg - whitelist mask and type
Stephan Mueller <smueller(a)chronox.de>
crypto: aesni - handle zero length dst buffer
Takashi Iwai <tiwai(a)suse.de>
ALSA: seq: Make ioctls race-free
Hugh Dickins <hughd(a)google.com>
kaiser: fix intel_bts perf crashes
Dave Hansen <dave.hansen(a)linux.intel.com>
x86/pti: Make unpoison of pgd for trusted boot work for real
Daniel Borkmann <daniel(a)iogearbox.net>
bpf: reject stores into ctx via st and xadd
Alexei Starovoitov <ast(a)kernel.org>
bpf: fix 32-bit divide by zero
Eric Dumazet <edumazet(a)google.com>
bpf: fix divides by zero
Daniel Borkmann <daniel(a)iogearbox.net>
bpf: avoid false sharing of map refcount with max_entries
Daniel Borkmann <daniel(a)iogearbox.net>
bpf: arsh is not supported in 32 bit alu thus reject it
Alexei Starovoitov <ast(a)kernel.org>
bpf: introduce BPF_JIT_ALWAYS_ON config
Alexei Starovoitov <ast(a)fb.com>
bpf: fix bpf_tail_call() x64 JIT
Eric Dumazet <edumazet(a)google.com>
x86: bpf_jit: small optimization in emit_bpf_tail_call()
Alexei Starovoitov <ast(a)fb.com>
bpf: fix branch pruning logic
Linus Torvalds <torvalds(a)linux-foundation.org>
loop: fix concurrent lo_open/lo_release
-------------
Diffstat:
Makefile | 4 +-
arch/arm64/Kconfig | 1 +
arch/s390/Kconfig | 1 +
arch/x86/Kconfig | 1 +
arch/x86/crypto/aesni-intel_glue.c | 2 +-
arch/x86/include/asm/kvm_host.h | 3 +-
arch/x86/kernel/cpu/perf_event_intel_bts.c | 44 ++++++++++----
arch/x86/kernel/tboot.c | 10 ++++
arch/x86/kvm/emulate.c | 7 +++
arch/x86/kvm/ioapic.c | 20 ++++++-
arch/x86/kvm/vmx.c | 4 +-
arch/x86/kvm/x86.c | 2 +-
arch/x86/net/bpf_jit_comp.c | 13 ++--
crypto/af_alg.c | 10 ++--
drivers/acpi/device_sysfs.c | 4 ++
drivers/block/loop.c | 10 +++-
drivers/cpufreq/Kconfig | 2 +
drivers/gpio/gpio-ath79.c | 3 +
drivers/gpio/gpio-iop.c | 4 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 47 +++++++++++----
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 4 +-
.../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 18 ++++++
drivers/gpu/drm/omapdrm/omap_dmm_tiler.c | 3 +-
drivers/hwmon/pmbus/pmbus_core.c | 21 ++++---
drivers/md/bcache/btree.c | 5 +-
drivers/media/usb/usbtv/usbtv-core.c | 1 +
drivers/mtd/nand/denali_pci.c | 4 ++
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
drivers/net/ethernet/xilinx/Kconfig | 1 +
drivers/net/xen-netfront.c | 18 ++++++
drivers/power/reset/zx-reboot.c | 4 ++
drivers/scsi/aacraid/commsup.c | 2 +-
drivers/scsi/ufs/ufshcd.c | 7 ++-
drivers/spi/spi-imx.c | 15 ++++-
drivers/staging/rtl8188eu/os_dep/ioctl_linux.c | 14 ++---
drivers/tty/serial/imx.c | 14 +++--
drivers/usb/class/cdc-acm.c | 5 +-
drivers/usb/gadget/composite.c | 7 ++-
drivers/usb/gadget/function/f_fs.c | 3 +-
drivers/usb/serial/Kconfig | 1 +
drivers/usb/serial/io_edgeport.c | 1 -
drivers/usb/serial/option.c | 5 ++
drivers/usb/serial/pl2303.c | 1 +
drivers/usb/serial/pl2303.h | 1 +
drivers/usb/serial/usb-serial-simple.c | 7 +++
drivers/usb/storage/uas.c | 7 +--
fs/btrfs/free-space-cache.c | 3 +-
fs/nfs_common/grace.c | 10 +++-
fs/nfsd/nfs4state.c | 34 ++++++-----
fs/quota/dquot.c | 3 +-
fs/xfs/xfs_aops.c | 6 +-
include/linux/bpf.h | 16 +++--
init/Kconfig | 7 +++
kernel/bpf/core.c | 30 ++++++++--
kernel/bpf/verifier.c | 70 ++++++++++++++++++++++
lib/test_bpf.c | 13 ++--
mm/kmemleak.c | 2 +
net/Kconfig | 3 +
net/core/filter.c | 8 ++-
net/core/sysctl_net_core.c | 6 ++
net/mac80211/mesh_hwmp.c | 15 +++--
net/openvswitch/flow_netlink.c | 16 ++---
net/socket.c | 9 +++
net/sunrpc/xprtsock.c | 1 +
security/selinux/hooks.c | 2 +
sound/core/seq/seq_clientmgr.c | 10 +++-
sound/core/seq/seq_clientmgr.h | 1 +
tools/usb/usbip/src/usbip_bind.c | 9 +++
tools/usb/usbip/src/usbip_list.c | 9 +++
69 files changed, 504 insertions(+), 142 deletions(-)
Rediffed for RHEL7.4.z.
Conflicts:
The return value of md_make_request is different from RHEL to upstream.
And RHEL7 MD code does not use bio->bi_opf, but bio->bi_rw.
-Nigel Croxon
commit 393debc23c7820211d1c8253dd6a8408a7628fe7
Author: Shaohua Li <shli(a)fb.com>
Date: Thu Sep 21 10:23:35 2017 -0700
md: separate request handling
With commit cc27b0c78c79, pers->make_request could bail out without handling
the bio. If that happens, we should retry. The commit fixes md_make_request
but not other call sites. Separate the request handling part, so other call
sites can use it.
Reported-by: Nate Dailey <nate.dailey(a)stratus.com>
Fix: cc27b0c78c79(md: fix deadlock between mddev_suspend() and md_write_start())
Cc: stable(a)vger.kernel.org
Reviewed-by: NeilBrown <neilb(a)suse.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Denys Vlasenko <dvlasenk(a)redhat.com>
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 85fe7a99290..407e15f4bfe 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -248,21 +248,8 @@ static DEFINE_SPINLOCK(all_mddevs_lock);
* call has finished, the bio has been linked into some internal structure
* and so is visible to ->quiesce(), so we don't need the refcount any more.
*/
-static void md_make_request(struct request_queue *q, struct bio *bio)
+void md_handle_request(struct mddev *mddev, struct bio *bio)
{
- const int rw = bio_data_dir(bio);
- struct mddev *mddev = q->queuedata;
- int cpu;
- unsigned int sectors;
-
- if (mddev == NULL || mddev->pers == NULL) {
- bio_io_error(bio);
- return;
- }
- if (mddev->ro == 1 && unlikely(rw == WRITE)) {
- bio_endio(bio, bio_sectors(bio) == 0 ? 0 : -EROFS);
- return;
- }
check_suspended:
smp_rmb(); /* Ensure implications of 'active' are visible */
rcu_read_lock();
@@ -282,24 +269,45 @@ check_suspended:
atomic_inc(&mddev->active_io);
rcu_read_unlock();
- /*
- * save the sectors now since our bio can
- * go away inside make_request
- */
- sectors = bio_sectors(bio);
if (!mddev->pers->make_request(mddev, bio)) {
atomic_dec(&mddev->active_io);
wake_up(&mddev->sb_wait);
goto check_suspended;
}
+ if (atomic_dec_and_test(&mddev->active_io) && mddev->suspended)
+ wake_up(&mddev->sb_wait);
+}
+EXPORT_SYMBOL(md_handle_request);
+
+static void md_make_request(struct request_queue *q, struct bio *bio)
+{
+ const int rw = bio_data_dir(bio);
+ struct mddev *mddev = q->queuedata;
+ int cpu;
+ unsigned int sectors;
+
+ if (mddev == NULL || mddev->pers == NULL) {
+ bio_io_error(bio);
+ return;
+ }
+ if (mddev->ro == 1 && unlikely(rw == WRITE)) {
+ bio_endio(bio, bio_sectors(bio) == 0 ? 0 : -EROFS);
+ return;
+ }
+
+ /*
+ * save the sectors now since our bio can
+ * go away inside make_request
+ */
+ sectors = bio_sectors(bio);
+
+ md_handle_request(mddev, bio);
+
cpu = part_stat_lock();
part_stat_inc(cpu, &mddev->gendisk->part0, ios[rw]);
part_stat_add(cpu, &mddev->gendisk->part0, sectors[rw], sectors);
part_stat_unlock();
-
- if (atomic_dec_and_test(&mddev->active_io) && mddev->suspended)
- wake_up(&mddev->sb_wait);
}
/* mddev_suspend makes sure no new requests are submitted
diff --git a/drivers/md/md.h b/drivers/md/md.h
index 0d13bf88f41..12e19d6d373 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -679,6 +679,7 @@ extern void md_stop_writes(struct mddev *mddev);
extern int md_rdev_init(struct md_rdev *rdev);
extern void md_rdev_clear(struct md_rdev *rdev);
+extern void md_handle_request(struct mddev *mddev, struct bio *bio);
extern void mddev_suspend(struct mddev *mddev);
extern void mddev_resume(struct mddev *mddev);
extern struct bio *bio_clone_mddev(struct bio *bio, gfp_t gfp_mask,
--
2.16.2
Changes since v4 [1]:
* Fix the changelog of "dax: introduce IS_DEVDAX() and IS_FSDAX()" to
better clarify the need for new helpers (Jan)
* Replace dax_sem_is_locked() with dax_sem_assert_held() (Jan)
* Use file_inode() in vma_is_dax() (Jan)
* Resend the full series to linux-xfs@ (Dave)
* Collect Jan's Reviewed-by
[1]: https://lists.01.org/pipermail/linux-nvdimm/2018-February/014271.html
---
The vfio interface, like RDMA, wants to setup long term (indefinite)
pins of the pages backing an address range so that a guest or userspace
driver can perform DMA to the with physical address. Given that this
pinning may lead to filesystem operations deadlocking in the
filesystem-dax case, the pinning request needs to be rejected.
The longer term fix for vfio, RDMA, and any other long term pin user, is
to provide a 'pin with lease' mechanism. Similar to the leases that are
hold for pNFS RDMA layouts, this userspace lease gives the kernel a way
to notify userspace that the block layout of the file is changing and
the kernel is revoking access to pinned pages.
Related to this change is the discovery that vma_is_fsdax() was causing
device-dax inode detection to fail. That lead to series of fixes and
cleanups to make sure that S_DAX is defined correctly in the
CONFIG_FS_DAX=n + CONFIG_DEV_DAX=y case.
---
Dan Williams (12):
dax: fix vma_is_fsdax() helper
dax: introduce IS_DEVDAX() and IS_FSDAX()
ext2, dax: finish implementing dax_sem helpers
ext2, dax: define ext2_dax_*() infrastructure in all cases
ext4, dax: define ext4_dax_*() infrastructure in all cases
ext2, dax: replace IS_DAX() with IS_FSDAX()
ext4, dax: replace IS_DAX() with IS_FSDAX()
xfs, dax: replace IS_DAX() with IS_FSDAX()
mm, dax: replace IS_DAX() with IS_DEVDAX() or IS_FSDAX()
fs, dax: kill IS_DAX()
dax: fix S_DAX definition
vfio: disable filesystem-dax page pinning
drivers/vfio/vfio_iommu_type1.c | 18 ++++++++++++++--
fs/ext2/ext2.h | 6 +++++
fs/ext2/file.c | 19 +++++------------
fs/ext2/inode.c | 10 ++++-----
fs/ext4/file.c | 18 +++++-----------
fs/ext4/inode.c | 4 ++--
fs/ext4/ioctl.c | 2 +-
fs/ext4/super.c | 2 +-
fs/iomap.c | 2 +-
fs/xfs/xfs_file.c | 14 ++++++-------
fs/xfs/xfs_ioctl.c | 4 ++--
fs/xfs/xfs_iomap.c | 6 +++--
fs/xfs/xfs_reflink.c | 2 +-
include/linux/dax.h | 12 ++++++++---
include/linux/fs.h | 43 ++++++++++++++++++++++++++++-----------
mm/fadvise.c | 3 ++-
mm/filemap.c | 4 ++--
mm/huge_memory.c | 4 +++-
mm/madvise.c | 3 ++-
19 files changed, 102 insertions(+), 74 deletions(-)
The patch titled
Subject: mm/page_alloc: fix memmap_init_zone pageblock alignment
has been added to the -mm tree. Its filename is
mm-page_alloc-fix-memmap_init_zone-pageblock-alignment.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-page_alloc-fix-memmap_init_zone…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-page_alloc-fix-memmap_init_zone…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Daniel Vacek <neelx(a)redhat.com>
Subject: mm/page_alloc: fix memmap_init_zone pageblock alignment
b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where
possible") introduced a bug where move_freepages() triggers a VM_BUG_ON()
on uninitialized page structure due to pageblock alignment. To fix this,
simply align the skipped pfns in memmap_init_zone() the same way as in
move_freepages_block().
Seen in one of the RHEL reports:
crash> log | grep -e BUG -e RIP -e Call.Trace -e move_freepages_block -e rmqueue -e freelist -A1
kernel BUG at mm/page_alloc.c:1389!
invalid opcode: 0000 [#1] SMP
--
RIP: 0010:[<ffffffff8118833e>] [<ffffffff8118833e>] move_freepages+0x15e/0x160
RSP: 0018:ffff88054d727688 EFLAGS: 00010087
--
Call Trace:
[<ffffffff811883b3>] move_freepages_block+0x73/0x80
[<ffffffff81189e63>] __rmqueue+0x263/0x460
[<ffffffff8118c781>] get_page_from_freelist+0x7e1/0x9e0
[<ffffffff8118caf6>] __alloc_pages_nodemask+0x176/0x420
--
RIP [<ffffffff8118833e>] move_freepages+0x15e/0x160
RSP <ffff88054d727688>
crash> page_init_bug -v | grep RAM
<struct resource 0xffff88067fffd2f8> 1000 - 9bfff System RAM (620.00 KiB)
<struct resource 0xffff88067fffd3a0> 100000 - 430bffff System RAM ( 1.05 GiB = 1071.75 MiB = 1097472.00 KiB)
<struct resource 0xffff88067fffd410> 4b0c8000 - 4bf9cfff System RAM ( 14.83 MiB = 15188.00 KiB)
<struct resource 0xffff88067fffd480> 4bfac000 - 646b1fff System RAM (391.02 MiB = 400408.00 KiB)
<struct resource 0xffff88067fffd560> 7b788000 - 7b7fffff System RAM (480.00 KiB)
<struct resource 0xffff88067fffd640> 100000000 - 67fffffff System RAM ( 22.00 GiB)
crash> page_init_bug | head -6
<struct resource 0xffff88067fffd560> 7b788000 - 7b7fffff System RAM (480.00 KiB)
<struct page 0xffffea0001ede200> 1fffff00000000 0 <struct pglist_data 0xffff88047ffd9000> 1 <struct zone 0xffff88047ffd9800> DMA32 4096 1048575
<struct page 0xffffea0001ede200> 505736 505344 <struct page 0xffffea0001ed8000> 505855 <struct page 0xffffea0001edffc0>
<struct page 0xffffea0001ed8000> 0 0 <struct pglist_data 0xffff88047ffd9000> 0 <struct zone 0xffff88047ffd9000> DMA 1 4095
<struct page 0xffffea0001edffc0> 1fffff00000400 0 <struct pglist_data 0xffff88047ffd9000> 1 <struct zone 0xffff88047ffd9800> DMA32 4096 1048575
BUG, zones differ!
Note that this range follows two not populated sections 68000000-77ffffff
in this zone. 7b788000-7b7fffff is the first one after a gap. This makes
memmap_init_zone() skip all the pfns up to the beginning of this range.
But this range is not pageblock (2M) aligned. In fact no range has to be.
crash> kmem -p 77fff000 78000000 7b5ff000 7b600000 7b787000 7b788000
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffea0001e00000 78000000 0 0 0 0
ffffea0001ed7fc0 7b5ff000 0 0 0 0
ffffea0001ed8000 7b600000 0 0 0 0 <<<<
ffffea0001ede1c0 7b787000 0 0 0 0
ffffea0001ede200 7b788000 0 0 1 1fffff00000000
Top part of page flags should contain nodeid and zonenr, which is not
the case for page ffffea0001ed8000 here (<<<<).
crash> log | grep -o fffea0001ed[^\ ]* | sort -u
fffea0001ed8000
fffea0001eded20
fffea0001edffc0
crash> bt -r | grep -o fffea0001ed[^\ ]* | sort -u
fffea0001ed8000
fffea0001eded00
fffea0001eded20
fffea0001edffc0
Initialization of the whole beginning of the section is skipped up to the
start of the range due to the commit b92df1de5d28. Now any code calling
move_freepages_block() (like reusing the page from a freelist as in this
example) with a page from the beginning of the range will get the page
rounded down to start_page ffffea0001ed8000 and passed to move_freepages()
which crashes on assertion getting wrong zonenr.
> VM_BUG_ON(page_zone(start_page) != page_zone(end_page));
Note, page_zone() derives the zone from page flags here.
>From similar machine before commit b92df1de5d28:
crash> kmem -p 77fff000 78000000 7b5ff000 7b600000 7b7fe000 7b7ff000
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
fffff73941e00000 78000000 0 0 1 1fffff00000000
fffff73941ed7fc0 7b5ff000 0 0 1 1fffff00000000
fffff73941ed8000 7b600000 0 0 1 1fffff00000000
fffff73941edff80 7b7fe000 0 0 1 1fffff00000000
fffff73941edffc0 7b7ff000 ffff8e67e04d3ae0 ad84 1 1fffff00020068 uptodate,lru,active,mappedtodisk
All the pages since the beginning of the section are initialized.
move_freepages()' not gonna blow up.
The same machine with this fix applied:
crash> kmem -p 77fff000 78000000 7b5ff000 7b600000 7b7fe000 7b7ff000
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
ffffea0001e00000 78000000 0 0 0 0
ffffea0001e00000 7b5ff000 0 0 0 0
ffffea0001ed8000 7b600000 0 0 1 1fffff00000000
ffffea0001edff80 7b7fe000 0 0 1 1fffff00000000
ffffea0001edffc0 7b7ff000 ffff88017fb13720 8 2 1fffff00020068 uptodate,lru,active,mappedtodisk
At least the bare minimum of pages is initialized preventing the crash as well.
Link: http://lkml.kernel.org/r/0485727b2e82da7efbce5f6ba42524b429d0391a.152001194…
Fixes: b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where possible")
Signed-off-by: Daniel Vacek <neelx(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Paul Burton <paul.burton(a)imgtec.com>
Cc: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_alloc.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff -puN mm/page_alloc.c~mm-page_alloc-fix-memmap_init_zone-pageblock-alignment mm/page_alloc.c
--- a/mm/page_alloc.c~mm-page_alloc-fix-memmap_init_zone-pageblock-alignment
+++ a/mm/page_alloc.c
@@ -5359,9 +5359,14 @@ void __meminit memmap_init_zone(unsigned
/*
* Skip to the pfn preceding the next valid one (or
* end_pfn), such that we hit a valid pfn (or end_pfn)
- * on our next iteration of the loop.
+ * on our next iteration of the loop. Note that it needs
+ * to be pageblock aligned even when the region itself
+ * is not. move_freepages_block() can shift ahead of
+ * the valid region but still depends on correct page
+ * metadata.
*/
- pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
+ pfn = (memblock_next_valid_pfn(pfn, end_pfn) &
+ ~(pageblock_nr_pages-1)) - 1;
#endif
continue;
}
_
Patches currently in -mm which might be from neelx(a)redhat.com are
mm-memblock-hardcode-the-end_pfn-being-1.patch
mm-page_alloc-fix-memmap_init_zone-pageblock-alignment.patch
Hi All,
Resent without non-upstream patches.
This backport patchset fixed the spectre issue, it's original branch:
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti
A few dependency or fixingpatches are also picked up, if they are necessary
and no functional changes.
No bug found from kernelci.org and lkft testing. It also could be gotten from:
git://git.linaro.org/kernel/linux-linaro-stable.git v4.9-spectre-upstream-only
Comments are appreciated!
Regards
Alex
[PATCH 01/45] mm: Introduce lm_alias
[PATCH 02/45] arm64: alternatives: apply boot time fixups via the
[PATCH 03/45] arm64: barrier: Add CSDB macros to control data-value
[PATCH 04/45] arm64: Implement array_index_mask_nospec()
[PATCH 05/45] arm64: move TASK_* definitions to <asm/processor.h>
[PATCH 06/45] arm64: Factor out PAN enabling/disabling into separate
[PATCH 07/45] arm64: Factor out TTBR0_EL1 post-update workaround into
[PATCH 08/45] arm64: uaccess: consistently check object sizes
[PATCH 09/45] arm64: Make USER_DS an inclusive limit
[PATCH 10/45] arm64: Use pointer masking to limit uaccess speculation
[PATCH 11/45] arm64: syscallno is secretly an int, make it official
[PATCH 12/45] arm64: entry: Ensure branch through syscall table is
[PATCH 13/45] arm64: uaccess: Prevent speculative use of the current
[PATCH 14/45] arm64: uaccess: Don't bother eliding access_ok checks
[PATCH 15/45] arm64: uaccess: Mask __user pointers for __arch_{clear,
[PATCH 16/45] arm64: futex: Mask __user pointers prior to dereference
[PATCH 17/45] drivers/firmware: Expose psci_get_version through
[PATCH 18/45] arm64: cpufeature: __this_cpu_has_cap() shouldn't stop
[PATCH 19/45] arm64: cpu_errata: Allow an erratum to be match for all
[PATCH 20/45] arm64: Run enable method for errata work arounds on
[PATCH 21/45] arm64: cpufeature: Pass capability structure to
[PATCH 22/45] arm64: Move post_ttbr_update_workaround to C code
[PATCH 23/45] arm64: Add skeleton to harden the branch predictor
[PATCH 24/45] arm64: Move BP hardening to check_and_switch_context
[PATCH 25/45] arm64: KVM: Use per-CPU vector when BP hardening is
[PATCH 26/45] arm64: entry: Apply BP hardening for high-priority
[PATCH 27/45] arm64: entry: Apply BP hardening for suspicious
[PATCH 28/45] arm64: cputype: Add missing MIDR values for Cortex-A72
[PATCH 29/45] arm64: Implement branch predictor hardening for
[PATCH 30/45] arm64: KVM: Increment PC after handling an SMC trap
[PATCH 31/45] arm/arm64: KVM: Consolidate the PSCI include files
[PATCH 32/45] arm/arm64: KVM: Add PSCI_VERSION helper
[PATCH 33/45] arm/arm64: KVM: Add smccc accessors to PSCI code
[PATCH 34/45] arm/arm64: KVM: Implement PSCI 1.0 support
[PATCH 35/45] arm/arm64: KVM: Advertise SMCCC v1.1
[PATCH 36/45] arm64: KVM: Make PSCI_VERSION a fast path
[PATCH 37/45] arm/arm64: KVM: Turn kvm_psci_version into a static
[PATCH 38/45] arm64: KVM: Report SMCCC_ARCH_WORKAROUND_1 BP hardening
[PATCH 39/45] arm64: KVM: Add SMCCC_ARCH_WORKAROUND_1 fast handling
[PATCH 40/45] firmware/psci: Expose PSCI conduit
[PATCH 41/45] firmware/psci: Expose SMCCC version through psci_ops
[PATCH 42/45] arm/arm64: smccc: Make function identifiers an unsigned
[PATCH 43/45] arm/arm64: smccc: Implement SMCCC v1.1 inline primitive
[PATCH 44/45] arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening
[PATCH 45/45] arm64: Kill PSCI_GET_VERSION as a variant-2 workaround
The patch titled
Subject: mm-memblock-hardcode-the-end_pfn-being-1-fix
has been added to the -mm tree. Its filename is
mm-memblock-hardcode-the-end_pfn-being-1-fix.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-memblock-hardcode-the-end_pfn-b…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-memblock-hardcode-the-end_pfn-b…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Andrew Morton <akpm(a)linux-foundation.org>
Subject: mm-memblock-hardcode-the-end_pfn-being-1-fix
make it work against current -linus, not against -mm
Cc: Daniel Vacek <neelx(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Paul Burton <paul.burton(a)imgtec.com>
Cc: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/page_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/page_alloc.c~mm-memblock-hardcode-the-end_pfn-being-1-fix mm/page_alloc.c
--- a/mm/page_alloc.c~mm-memblock-hardcode-the-end_pfn-being-1-fix
+++ a/mm/page_alloc.c
@@ -5361,7 +5361,7 @@ void __meminit memmap_init_zone(unsigned
* end_pfn), such that we hit a valid pfn (or end_pfn)
* on our next iteration of the loop.
*/
- pfn = memblock_next_valid_pfn(pfn) - 1;
+ pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
#endif
continue;
}
_
Patches currently in -mm which might be from akpm(a)linux-foundation.org are
i-need-old-gcc.patch
mm-memblock-hardcode-the-end_pfn-being-1-fix.patch
arm-arch-arm-include-asm-pageh-needs-personalityh.patch
mm.patch
mm-page_alloc-skip-over-regions-of-invalid-pfns-on-uma-fix.patch
direct-io-minor-cleanups-in-do_blockdev_direct_io-fix.patch
list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix.patch
mm-oom-cgroup-aware-oom-killer-fix.patch
mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2-fix.patch
proc-add-seq_put_decimal_ull_width-to-speed-up-proc-pid-smaps-fix.patch
sysctl-add-flags-to-support-min-max-range-clamping-fix.patch
linux-next-git-rejects.patch
kernel-forkc-export-kernel_thread-to-modules.patch
slab-leaks3-default-y.patch
The patch titled
Subject: mm/memblock.c: hardcode the end_pfn being -1
has been added to the -mm tree. Its filename is
mm-memblock-hardcode-the-end_pfn-being-1.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-memblock-hardcode-the-end_pfn-b…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-memblock-hardcode-the-end_pfn-b…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Daniel Vacek <neelx(a)redhat.com>
Subject: mm/memblock.c: hardcode the end_pfn being -1
This is just a cleanup. It aids handling the special end case in the next
commit.
Link: http://lkml.kernel.org/r/1ca478d4269125a99bcfb1ca04d7b88ac1aee924.152001194…
Signed-off-by: Daniel Vacek <neelx(a)redhat.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Cc: Paul Burton <paul.burton(a)imgtec.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/memblock.c | 13 ++++++-------
mm/page_alloc.c | 2 +-
2 files changed, 7 insertions(+), 8 deletions(-)
diff -puN mm/memblock.c~mm-memblock-hardcode-the-end_pfn-being-1 mm/memblock.c
--- a/mm/memblock.c~mm-memblock-hardcode-the-end_pfn-being-1
+++ a/mm/memblock.c
@@ -1101,13 +1101,12 @@ void __init_memblock __next_mem_pfn_rang
*out_nid = r->nid;
}
-unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn,
- unsigned long max_pfn)
+unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn)
{
struct memblock_type *type = &memblock.memory;
unsigned int right = type->cnt;
unsigned int mid, left = 0;
- phys_addr_t addr = PFN_PHYS(pfn + 1);
+ phys_addr_t addr = PFN_PHYS(++pfn);
do {
mid = (right + left) / 2;
@@ -1118,15 +1117,15 @@ unsigned long __init_memblock memblock_n
type->regions[mid].size))
left = mid + 1;
else {
- /* addr is within the region, so pfn + 1 is valid */
- return min(pfn + 1, max_pfn);
+ /* addr is within the region, so pfn is valid */
+ return pfn;
}
} while (left < right);
if (right == type->cnt)
- return max_pfn;
+ return -1UL;
else
- return min(PHYS_PFN(type->regions[right].base), max_pfn);
+ return PHYS_PFN(type->regions[right].base);
}
/**
diff -puN mm/page_alloc.c~mm-memblock-hardcode-the-end_pfn-being-1 mm/page_alloc.c
--- a/mm/page_alloc.c~mm-memblock-hardcode-the-end_pfn-being-1
+++ a/mm/page_alloc.c
@@ -5361,7 +5361,7 @@ void __meminit memmap_init_zone(unsigned
* end_pfn), such that we hit a valid pfn (or end_pfn)
* on our next iteration of the loop.
*/
- pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
+ pfn = memblock_next_valid_pfn(pfn) - 1;
#endif
continue;
}
_
Patches currently in -mm which might be from neelx(a)redhat.com are
mm-memblock-hardcode-the-end_pfn-being-1.patch
mm-page_alloc-fix-memmap_init_zone-pageblock-alignment.patch
The patch titled
Subject: mm/page_alloc: fix memmap_init_zone pageblock alignment
has been removed from the -mm tree. Its filename was
mm-page_alloc-fix-memmap_init_zone-pageblock-alignment.patch
This patch was dropped because an updated version will be merged
------------------------------------------------------
From: Daniel Vacek <neelx(a)redhat.com>
Subject: mm/page_alloc: fix memmap_init_zone pageblock alignment
BUG at mm/page_alloc.c:1913
> VM_BUG_ON(page_zone(start_page) != page_zone(end_page));
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") introduced a bug where move_freepages() triggers a
VM_BUG_ON() on uninitialized page structure due to pageblock alignment.
To fix this, simply align the skipped pfns in memmap_init_zone() the same
way as in move_freepages_block().
Link: http://lkml.kernel.org/r/1519988497-28941-1-git-send-email-neelx@redhat.com
Fixes: b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where possible")
Signed-off-by: Daniel Vacek <neelx(a)redhat.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Cc: Paul Burton <paul.burton(a)imgtec.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/memblock.c | 13 ++++++-------
mm/page_alloc.c | 9 +++++++--
2 files changed, 13 insertions(+), 9 deletions(-)
diff -puN mm/memblock.c~mm-page_alloc-fix-memmap_init_zone-pageblock-alignment mm/memblock.c
--- a/mm/memblock.c~mm-page_alloc-fix-memmap_init_zone-pageblock-alignment
+++ a/mm/memblock.c
@@ -1101,13 +1101,12 @@ void __init_memblock __next_mem_pfn_rang
*out_nid = r->nid;
}
-unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn,
- unsigned long max_pfn)
+unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn)
{
struct memblock_type *type = &memblock.memory;
unsigned int right = type->cnt;
unsigned int mid, left = 0;
- phys_addr_t addr = PFN_PHYS(pfn + 1);
+ phys_addr_t addr = PFN_PHYS(++pfn);
do {
mid = (right + left) / 2;
@@ -1118,15 +1117,15 @@ unsigned long __init_memblock memblock_n
type->regions[mid].size))
left = mid + 1;
else {
- /* addr is within the region, so pfn + 1 is valid */
- return min(pfn + 1, max_pfn);
+ /* addr is within the region, so pfn is valid */
+ return pfn;
}
} while (left < right);
if (right == type->cnt)
- return max_pfn;
+ return -1UL;
else
- return min(PHYS_PFN(type->regions[right].base), max_pfn);
+ return PHYS_PFN(type->regions[right].base);
}
/**
diff -puN mm/page_alloc.c~mm-page_alloc-fix-memmap_init_zone-pageblock-alignment mm/page_alloc.c
--- a/mm/page_alloc.c~mm-page_alloc-fix-memmap_init_zone-pageblock-alignment
+++ a/mm/page_alloc.c
@@ -5359,9 +5359,14 @@ void __meminit memmap_init_zone(unsigned
/*
* Skip to the pfn preceding the next valid one (or
* end_pfn), such that we hit a valid pfn (or end_pfn)
- * on our next iteration of the loop.
+ * on our next iteration of the loop. Note that it needs
+ * to be pageblock aligned even when the region itself
+ * is not as move_freepages_block() can shift ahead of
+ * the valid region but still depends on correct page
+ * metadata.
*/
- pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
+ pfn = (memblock_next_valid_pfn(pfn) &
+ ~(pageblock_nr_pages-1)) - 1;
#endif
continue;
}
_
Patches currently in -mm which might be from neelx(a)redhat.com are
mm-memblock-hardcode-the-end_pfn-being-1.patch
The patch titled
Subject: mm/page_alloc: fix memmap_init_zone pageblock alignment
has been added to the -mm tree. Its filename is
mm-page_alloc-fix-memmap_init_zone-pageblock-alignment.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-page_alloc-fix-memmap_init_zone…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-page_alloc-fix-memmap_init_zone…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Daniel Vacek <neelx(a)redhat.com>
Subject: mm/page_alloc: fix memmap_init_zone pageblock alignment
BUG at mm/page_alloc.c:1913
> VM_BUG_ON(page_zone(start_page) != page_zone(end_page));
Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns
where possible") introduced a bug where move_freepages() triggers a
VM_BUG_ON() on uninitialized page structure due to pageblock alignment.
To fix this, simply align the skipped pfns in memmap_init_zone() the same
way as in move_freepages_block().
Link: http://lkml.kernel.org/r/1519988497-28941-1-git-send-email-neelx@redhat.com
Fixes: b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns where possible")
Signed-off-by: Daniel Vacek <neelx(a)redhat.com>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Pavel Tatashin <pasha.tatashin(a)oracle.com>
Cc: Paul Burton <paul.burton(a)imgtec.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/memblock.c | 13 ++++++-------
mm/page_alloc.c | 9 +++++++--
2 files changed, 13 insertions(+), 9 deletions(-)
diff -puN mm/memblock.c~mm-page_alloc-fix-memmap_init_zone-pageblock-alignment mm/memblock.c
--- a/mm/memblock.c~mm-page_alloc-fix-memmap_init_zone-pageblock-alignment
+++ a/mm/memblock.c
@@ -1101,13 +1101,12 @@ void __init_memblock __next_mem_pfn_rang
*out_nid = r->nid;
}
-unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn,
- unsigned long max_pfn)
+unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn)
{
struct memblock_type *type = &memblock.memory;
unsigned int right = type->cnt;
unsigned int mid, left = 0;
- phys_addr_t addr = PFN_PHYS(pfn + 1);
+ phys_addr_t addr = PFN_PHYS(++pfn);
do {
mid = (right + left) / 2;
@@ -1118,15 +1117,15 @@ unsigned long __init_memblock memblock_n
type->regions[mid].size))
left = mid + 1;
else {
- /* addr is within the region, so pfn + 1 is valid */
- return min(pfn + 1, max_pfn);
+ /* addr is within the region, so pfn is valid */
+ return pfn;
}
} while (left < right);
if (right == type->cnt)
- return max_pfn;
+ return -1UL;
else
- return min(PHYS_PFN(type->regions[right].base), max_pfn);
+ return PHYS_PFN(type->regions[right].base);
}
/**
diff -puN mm/page_alloc.c~mm-page_alloc-fix-memmap_init_zone-pageblock-alignment mm/page_alloc.c
--- a/mm/page_alloc.c~mm-page_alloc-fix-memmap_init_zone-pageblock-alignment
+++ a/mm/page_alloc.c
@@ -5359,9 +5359,14 @@ void __meminit memmap_init_zone(unsigned
/*
* Skip to the pfn preceding the next valid one (or
* end_pfn), such that we hit a valid pfn (or end_pfn)
- * on our next iteration of the loop.
+ * on our next iteration of the loop. Note that it needs
+ * to be pageblock aligned even when the region itself
+ * is not as move_freepages_block() can shift ahead of
+ * the valid region but still depends on correct page
+ * metadata.
*/
- pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
+ pfn = (memblock_next_valid_pfn(pfn) &
+ ~(pageblock_nr_pages-1)) - 1;
#endif
continue;
}
_
Patches currently in -mm which might be from neelx(a)redhat.com are
mm-page_alloc-fix-memmap_init_zone-pageblock-alignment.patch
This is the start of the stable review cycle for the 3.18.98 release.
There are 24 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Mar 4 08:42:22 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.98-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 3.18.98-rc1
Yangbo Lu <yangbo.lu(a)nxp.com>
net: gianfar_ptp: move set_fipers() to spinlock protecting area
Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
sctp: make use of pre-calculated len
Ross Lagerwall <ross.lagerwall(a)citrix.com>
xen/gntdev: Fix partial gntdev_mmap() cleanup
Ross Lagerwall <ross.lagerwall(a)citrix.com>
xen/gntdev: Fix off-by-one error when unmapping with holes
Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
SolutionEngine771x: fix Ether platform data
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
mdio-sun4i: Fix a memory leak
Eduardo Otubo <otubo(a)redhat.com>
xen-netfront: enable device after manual module load
Xiongwei Song <sxwjean(a)gmail.com>
drm/ttm: check the return value of kzalloc
Tushar Dave <tushar.n.dave(a)oracle.com>
e1000: fix disabling already-disabled warning
Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
xfs: quota: check result of register_shrinker()
Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
xfs: quota: fix missed destroy of qi_tree_lock
Stefan Haberland <sth(a)linux.vnet.ibm.com>
s390/dasd: fix wrongly assigned configuration data
Matthieu CASTET <matthieu.castet(a)parrot.com>
led: core: Fix brightness setting when setting delay_off=0
Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com>
bnx2x: Improve reliability in case of nested PCI errors
Siva Reddy Kallam <siva.kallam(a)broadcom.com>
tg3: Enable PHY reset in MTU change path for 5720
Siva Reddy Kallam <siva.kallam(a)broadcom.com>
tg3: Add workaround to restrict 5762 MRRS to 2048
Cathy Avery <cavery(a)redhat.com>
scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error
Alexander Kochetkov <al.kochet(a)gmail.com>
net: arc_emac: fix arc_emac_rx() error paths
Radu Pirea <radu.pirea(a)microchip.com>
spi: atmel: fixed spin_lock usage inside atmel_spi_remove
Al Viro <viro(a)zeniv.linux.org.uk>
sget(): handle failures of register_shrinker()
Brendan McGrath <redmcg(a)redmandi.dyndns.org>
ipv6: icmp6: Allow icmp messages to be looped back
Sascha Hauer <s.hauer(a)pengutronix.de>
mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM
Anna-Maria Gleixner <anna-maria(a)linutronix.de>
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
Jakub Sitnicki <jkbs(a)redhat.com>
ipv6: Skip XFRM lookup if dst_entry in socket cache is valid
-------------
Diffstat:
Makefile | 4 +-
arch/sh/boards/mach-se/770x/setup.c | 10 ++++-
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +
drivers/leds/led-core.c | 2 +-
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 6 +--
drivers/net/ethernet/arc/emac_main.c | 53 ++++++++++++++----------
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 4 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 ++++++-
drivers/net/ethernet/broadcom/tg3.c | 13 +++++-
drivers/net/ethernet/broadcom/tg3.h | 4 ++
drivers/net/ethernet/freescale/gianfar_ptp.c | 3 +-
drivers/net/ethernet/intel/e1000/e1000.h | 3 +-
drivers/net/ethernet/intel/e1000/e1000_main.c | 27 +++++++++---
drivers/net/phy/mdio-sun4i.c | 6 ++-
drivers/net/xen-netfront.c | 1 +
drivers/s390/block/dasd_3990_erp.c | 10 +++++
drivers/scsi/storvsc_drv.c | 3 +-
drivers/spi/spi-atmel.c | 2 +-
drivers/xen/gntdev.c | 8 ++--
fs/super.c | 6 ++-
fs/xfs/xfs_qm.c | 46 +++++++++++++-------
kernel/time/hrtimer.c | 7 +++-
net/ipv6/ip6_output.c | 11 ++---
net/ipv6/route.c | 1 +
net/sctp/socket.c | 16 ++++---
25 files changed, 180 insertions(+), 82 deletions(-)
This is the start of the stable review cycle for the 4.9.86 release.
There are 56 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Mar 4 08:44:26 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.86-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.9.86-rc1
James Hogan <jhogan(a)kernel.org>
MIPS: Implement __multi3 for GCC7 MIPS64r6 builds
Punit Agrawal <punit.agrawal(a)arm.com>
KVM: arm/arm64: Fix check for hugepage size when allocating at Stage 2
Yangbo Lu <yangbo.lu(a)nxp.com>
net: gianfar_ptp: move set_fipers() to spinlock protecting area
Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
sctp: make use of pre-calculated len
Ross Lagerwall <ross.lagerwall(a)citrix.com>
xen/gntdev: Fix partial gntdev_mmap() cleanup
Ross Lagerwall <ross.lagerwall(a)citrix.com>
xen/gntdev: Fix off-by-one error when unmapping with holes
Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
SolutionEngine771x: fix Ether platform data
Christophe JAILLET <christophe.jaillet(a)wanadoo.fr>
mdio-sun4i: Fix a memory leak
Eduardo Otubo <otubo(a)redhat.com>
xen-netfront: enable device after manual module load
Venkat Duvvuru <venkatkumar.duvvuru(a)broadcom.com>
bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine.
Luu An Phu <phu.luuan(a)nxp.com>
can: flex_can: Correct the checking for frame length in flexcan_start_xmit()
Johannes Berg <johannes.berg(a)intel.com>
mac80211: mesh: drop frames appearing to be from us
Hao Chen <flank3rsky(a)gmail.com>
nl80211: Check for the required netlink attribute presence
Alexander Duyck <alexander.h.duyck(a)intel.com>
i40e/i40evf: Account for frags split over multiple descriptors in check linearize
Felix Janda <felix.janda(a)posteo.de>
uapi libc compat: add fallback for unsupported libcs
Xiongwei Song <sxwjean(a)gmail.com>
drm/ttm: check the return value of kzalloc
SZ Lin (林上智) <sz.lin(a)moxa.com>
NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625
Tushar Dave <tushar.n.dave(a)oracle.com>
e1000: fix disabling already-disabled warning
Gao Feng <gfree.wind(a)vip.163.com>
macvlan: Fix one possible double free
Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
xfs: quota: check result of register_shrinker()
Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
xfs: quota: fix missed destroy of qi_tree_lock
Erez Shitrit <erezsh(a)mellanox.com>
IB/ipoib: Fix race condition in neigh creation
Leon Romanovsky <leonro(a)mellanox.com>
IB/mlx4: Fix mlx4_ib_alloc_mr error flow
Stefan Haberland <sth(a)linux.vnet.ibm.com>
s390/dasd: fix wrongly assigned configuration data
Guenter Roeck <linux(a)roeck-us.net>
genirq: Guard handle_bad_irq log messages
Nitzan Carmi <nitzanc(a)mellanox.com>
IB/mlx5: Fix mlx5_ib_alloc_mr error flow
Matthieu CASTET <matthieu.castet(a)parrot.com>
led: core: Fix brightness setting when setting delay_off=0
Guilherme G. Piccoli <gpiccoli(a)linux.vnet.ibm.com>
bnx2x: Improve reliability in case of nested PCI errors
Siva Reddy Kallam <siva.kallam(a)broadcom.com>
tg3: Enable PHY reset in MTU change path for 5720
Siva Reddy Kallam <siva.kallam(a)broadcom.com>
tg3: Add workaround to restrict 5762 MRRS to 2048
Tommi Rantala <tommi.t.rantala(a)nokia.com>
tipc: fix tipc_mon_delete() oops in tipc_enable_bearer() error path
Tommi Rantala <tommi.t.rantala(a)nokia.com>
tipc: error path leak fixes in tipc_enable_bearer()
James Hogan <jhogan(a)kernel.org>
lib/mpi: Fix umul_ppmm() for MIPS64r6
Arnd Bergmann <arnd(a)arndb.de>
ARM: dts: ls1021a: fix incorrect clock references
Cathy Avery <cavery(a)redhat.com>
scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error
Fredrik Hallenberg <megahallon(a)gmail.com>
net: stmmac: Fix TX timestamp calculation
Xin Long <lucien.xin(a)gmail.com>
ip6_tunnel: get the min mtu properly in ip6_tnl_xmit
Alexander Kochetkov <al.kochet(a)gmail.com>
net: arc_emac: fix arc_emac_rx() error paths
Sean Wang <sean.wang(a)mediatek.com>
net: mediatek: setup proper state for disabled GMAC on the default
Abhijeet Kumar <abhijeet.kumar(a)intel.com>
ASoC: nau8825: fix issue that pop noise when start capture
Radu Pirea <radu.pirea(a)microchip.com>
spi: atmel: fixed spin_lock usage inside atmel_spi_remove
Jia-Ju Bai <baijiaju1990(a)163.com>
mac80211_hwsim: Fix a possible sleep-in-atomic bug in hwsim_get_radio_nl
Karol Herbst <kherbst(a)redhat.com>
drm/nouveau/pci: do a msi rearm on init
Alexey Khoroshilov <khoroshilov(a)ispras.ru>
net: phy: xgene: disable clk on error paths
Al Viro <viro(a)zeniv.linux.org.uk>
sget(): handle failures of register_shrinker()
Arnaldo Carvalho de Melo <acme(a)redhat.com>
x86/asm: Allow again using asm.h when building for the 'bpf' clang target
Chunyan Zhang <zhang.lyra(a)gmail.com>
ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch
Brendan McGrath <redmcg(a)redmandi.dyndns.org>
ipv6: icmp6: Allow icmp messages to be looped back
Albert Hsieh <wen.hsieh(a)broadcom.com>
mtd: nand: brcmnand: Zero bitflip is not an error
Sascha Hauer <s.hauer(a)pengutronix.de>
mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM
Daniele Palmas <dnlplm(a)gmail.com>
net: usb: qmi_wwan: add Telit ME910 PID 0x1101 support
Keith Busch <keith.busch(a)intel.com>
nvme: check hw sectors before setting chunk sectors
Andreas Platschek <andreas.platschek(a)opentech.at>
dmaengine: fsl-edma: disable clks on all error paths
Yunlei He <heyunlei(a)huawei.com>
f2fs: fix a bug caused by NULL extent tree
Ben Gardner <gardner.ben(a)gmail.com>
i2c: designware: must wait for enable
Anna-Maria Gleixner <anna-maria(a)linutronix.de>
hrtimer: Ensure POSIX compliance (relative CLOCK_REALTIME hrtimers)
-------------
Diffstat:
Makefile | 4 +-
arch/arm/boot/dts/ls1021a-qds.dts | 2 +-
arch/arm/boot/dts/ls1021a-twr.dts | 2 +-
arch/arm/kvm/mmu.c | 2 +-
arch/arm/lib/csumpartialcopyuser.S | 4 ++
arch/mips/lib/Makefile | 3 +-
arch/mips/lib/libgcc.h | 17 +++++++
arch/mips/lib/multi3.c | 54 +++++++++++++++++++++
arch/sh/boards/mach-se/770x/setup.c | 10 +++-
arch/x86/include/asm/asm.h | 2 +
drivers/dma/fsl-edma.c | 28 +++++------
drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c | 7 +++
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +
drivers/i2c/busses/i2c-designware-core.c | 2 +-
drivers/infiniband/hw/mlx4/mr.c | 2 +-
drivers/infiniband/hw/mlx5/mr.c | 1 +
drivers/infiniband/ulp/ipoib/ipoib_main.c | 25 +++++++---
drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 5 +-
drivers/leds/led-core.c | 2 +-
drivers/mtd/nand/brcmnand/brcmnand.c | 2 +-
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 6 +--
drivers/net/can/flexcan.c | 2 +-
drivers/net/ethernet/arc/emac_main.c | 53 ++++++++++++---------
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 4 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 +++++-
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 2 +-
drivers/net/ethernet/broadcom/tg3.c | 13 ++++-
drivers/net/ethernet/broadcom/tg3.h | 4 ++
drivers/net/ethernet/freescale/gianfar_ptp.c | 3 +-
drivers/net/ethernet/intel/e1000/e1000.h | 3 +-
drivers/net/ethernet/intel/e1000/e1000_main.c | 27 +++++++++--
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 26 ++++++++--
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 26 ++++++++--
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 11 +++--
.../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 6 ++-
drivers/net/macvlan.c | 7 ++-
drivers/net/phy/mdio-sun4i.c | 6 ++-
drivers/net/phy/mdio-xgene.c | 21 ++++++---
drivers/net/usb/qmi_wwan.c | 2 +
drivers/net/wireless/mac80211_hwsim.c | 2 +-
drivers/net/xen-netfront.c | 1 +
drivers/nvme/host/core.c | 3 +-
drivers/s390/block/dasd_3990_erp.c | 10 ++++
drivers/scsi/storvsc_drv.c | 3 +-
drivers/spi/spi-atmel.c | 2 +-
drivers/xen/gntdev.c | 8 ++--
fs/f2fs/extent_cache.c | 12 ++++-
fs/super.c | 6 ++-
fs/xfs/xfs_qm.c | 46 +++++++++++-------
include/uapi/linux/libc-compat.h | 55 +++++++++++++++++++++-
kernel/irq/debug.h | 5 ++
kernel/time/hrtimer.c | 7 ++-
lib/mpi/longlong.h | 18 ++++++-
net/ipv6/ip6_tunnel.c | 9 +++-
net/ipv6/route.c | 1 +
net/mac80211/rx.c | 2 +
net/sctp/socket.c | 16 ++++---
net/tipc/bearer.c | 5 +-
net/tipc/monitor.c | 6 ++-
net/wireless/nl80211.c | 3 +-
sound/soc/codecs/nau8825.c | 1 +
61 files changed, 498 insertions(+), 135 deletions(-)
The patch titled
Subject: mm/gup.c: teach get_user_pages_unlocked to handle FOLL_NOWAIT
has been added to the -mm tree. Its filename is
mm-gup-teach-get_user_pages_unlocked-to-handle-foll_nowait.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-gup-teach-get_user_pages_unlock…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-gup-teach-get_user_pages_unlock…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Andrea Arcangeli <aarcange(a)redhat.com>
Subject: mm/gup.c: teach get_user_pages_unlocked to handle FOLL_NOWAIT
KVM is hanging during postcopy live migration with userfaultfd because
get_user_pages_unlocked is not capable to handle FOLL_NOWAIT.
Earlier FOLL_NOWAIT was only ever passed to get_user_pages.
Specifically faultin_page (the callee of get_user_pages_unlocked caller)
doesn't know that if FAULT_FLAG_RETRY_NOWAIT was set in the page fault
flags, when VM_FAULT_RETRY is returned, the mmap_sem wasn't actually
released (even if nonblocking is not NULL). So it sets *nonblocking to
zero and the caller won't release the mmap_sem thinking it was already
released, but it wasn't because of FOLL_NOWAIT.
Link: http://lkml.kernel.org/r/20180302174343.5421-2-aarcange@redhat.com
Fixes: ce53053ce378c ("kvm: switch get_user_page_nowait() to get_user_pages_unlocked()")
Signed-off-by: Andrea Arcangeli <aarcange(a)redhat.com>
Reported-by: Dr. David Alan Gilbert <dgilbert(a)redhat.com>
Tested-by: Dr. David Alan Gilbert <dgilbert(a)redhat.com>
Cc: Al Viro <viro(a)zeniv.linux.org.uk>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/gup.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff -puN mm/gup.c~mm-gup-teach-get_user_pages_unlocked-to-handle-foll_nowait mm/gup.c
--- a/mm/gup.c~mm-gup-teach-get_user_pages_unlocked-to-handle-foll_nowait
+++ a/mm/gup.c
@@ -516,7 +516,7 @@ static int faultin_page(struct task_stru
}
if (ret & VM_FAULT_RETRY) {
- if (nonblocking)
+ if (nonblocking && !(fault_flags & FAULT_FLAG_RETRY_NOWAIT))
*nonblocking = 0;
return -EBUSY;
}
@@ -890,7 +890,10 @@ static __always_inline long __get_user_p
break;
}
if (*locked) {
- /* VM_FAULT_RETRY didn't trigger */
+ /*
+ * VM_FAULT_RETRY didn't trigger or it was a
+ * FOLL_NOWAIT.
+ */
if (!pages_done)
pages_done = ret;
break;
_
Patches currently in -mm which might be from aarcange(a)redhat.com are
mm-gup-teach-get_user_pages_unlocked-to-handle-foll_nowait.patch
On Fri, Mar 02, 2018 at 05:41:28PM +0000, Harsh Shandilya wrote:
> On Fri 2 Mar, 2018, 2:25 PM Greg Kroah-Hartman, <gregkh(a)linuxfoundation.org>
> wrote:
>
> > This is the start of the stable review cycle for the 3.18.98 release.
> > There are 24 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sun Mar 4 08:42:22 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >
> > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.98-rc…
> > or in the git tree and branch at:
> > git://
> > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > linux-3.18.y
> > and the diffstat can be found below.
> >
>
> Builds and boots on the OnePlus 3T, no merge issues with CAF's msm-3.18
> tree.
Great, thanks for testing and letting me know.
greg k-h
> >
When SPI transfers can be offloaded using DMA, the SPI core need to
build a scatterlist to make sure that the buffer to be transferred is
dma-able.
This patch fixes the scatterlist entry size computation in the case
where the maximum acceptable scatterlist entry supported by the DMA
controller is less than PAGE_SIZE, when the buffer is vmalloced.
For each entry, the actual size is given by the minimum between the
desc_len (which is the max buffer size supported by the DMA controller)
and the remaining buffer length until we cross a page boundary.
Fixes: 65598c13fd66 ("spi: Fix per-page mapping of unaligned vmalloc-ed buffer")
Signed-off-by: Maxime Chevallier <maxime.chevallier(a)bootlin.com>
---
drivers/spi/spi.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index b33a727a0158..4153f959f28c 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -779,8 +779,14 @@ static int spi_map_buf(struct spi_controller *ctlr, struct device *dev,
for (i = 0; i < sgs; i++) {
if (vmalloced_buf || kmap_buf) {
- min = min_t(size_t,
- len, desc_len - offset_in_page(buf));
+ /*
+ * Next scatterlist entry size is the minimum between
+ * the desc_len and the remaining buffer length that
+ * fits in a page.
+ */
+ min = min_t(size_t, desc_len,
+ min_t(size_t, len,
+ PAGE_SIZE - offset_in_page(buf)));
if (vmalloced_buf)
vm_page = vmalloc_to_page(buf);
else
--
2.11.0
On 02/03/18 15:58, Simon Gaiser wrote:
> Juergen Gross:
>> On 20/02/18 05:56, Simon Gaiser wrote:
>>> Juergen Gross:
>>>> On 07/02/18 23:22, Simon Gaiser wrote:
>>>>> Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
>>>>> concurrent xenstore accesses") made a subtle change to the semantic of
>>>>> xenbus_dev_request_and_reply() and xenbus_transaction_end().
>>>>>
>>>>> Before on an error response to XS_TRANSACTION_END
>>>>> xenbus_dev_request_and_reply() would not decrement the active
>>>>> transaction counter. But xenbus_transaction_end() has always counted the
>>>>> transaction as finished regardless of the response.
>>>>
>>>> Which is correct now. Xenstore will free all transaction related
>>>> data regardless of the response. A once failed transaction can't
>>>> be repaired, it has to be repeated completely.
>>>
>>> So if xenstore frees the transaction why should we keep it in the list
>>> with pending transaction in xenbus_dev_frontend? That's exactly what
>>> this patch fixes by always removing it from the list, not only on a
>>> successful response (See below for the EINVAL case).
>>
>> Aah, sorry, I seem to have misread my own coding. :-(
>>
>> Yes, you are right. Sorry for not seeing it before.
>>
>>>
>>> [...]
>>>>> But xenbus_dev_frontend tries to end a transaction on closing of the
>>>>> device if the XS_TRANSACTION_END failed before. Trying to close the
>>>>> transaction twice corrupts the reference count. So fix this by also
>>>>> considering a transaction closed if we have sent XS_TRANSACTION_END once
>>>>> regardless of the return code.
>>>>
>>>> A transaction in the list of transactions should not considered to be
>>>> finished. Either it is not on the list or it is still pending.
>>>
>>> With "considering a transaction closed" I mean "take the code path which
>>> removes the transaction from the list with pending transactions".
>>>
>>> From the follow-up mail:
>>>>>> The new behavior is that xenbus_dev_request_and_reply() and
>>>>>> xenbus_transaction_end() will always count the transaction as finished
>>>>>> regardless the response code (handled in xs_request_exit()).
>>>>>
>>>>> ENOENT should not decrement the transaction counter, while all
>>>>> other responses to XS_TRANSACTION_END should still do so.
>>>>
>>>> Sorry, I stand corrected: the ENOENT case should never happen, as this
>>>> case is tested in xenbus_write_transaction(). It doesn't hurt to test
>>>> for ENOENT, though.
>>>>
>>>> What should be handled is EINVAL: this would happen if a user specified
>>>> a string different from "T" and "F".
>>>
>>> Ok, I will handle those cases in xs_request_exit(). Although I don't
>>> like that this depends on the internals of xenstore (At least to me it's
>>> not obvious why it should only return ENOENT or EINVAL in this case).
>>>
>>> In the xenbus_write_transaction() case checking the string before
>>> sending the transaction (like the transaction itself is verified) would
>>> avoid this problem.
>>
>> Right. I'd prefer this solution.
>>
>> Remains the only problem you tried to tackle with your second patch: a
>> kernel driver going crazy and ending transactions it never started (or
>> ending them multiple times). The EINVAL case can't happen here, but
>> ENOENT can. Either ENOENT has to be handled in xs_request_exit() or you
>> need to keep track of the transactions like in the user interface and
>> refuse ending an unknown transaction. Or you trust the kernel users.
>> Trying to fix the usage counter seems to be the wrong approach IMO.
>
> The point of the second patch was to detect such bugs. This would have
> saved quite some time to find this bug. I added the "fix" of the counter
> I just because it was trivial after having the if there.
>
> Adding tracking seems to be a quite complex solution for a _potential_
> problem.
I agree.
> So I would go with checking ENOENT in xs_request_exit(). Should this be
> WARN_ON_ONCE()? Since this normally should not happen I would say yes.
Yes, having a WARN_ON_ONCE here will help.
> Should I keep the reference counter sanity check? And if yes, with the
> "fix" to the counter?
I'd drop it. This really should not happen and blowing up kernel size
with checks of impossible situations isn't the way to go.
In case you really want to do something here you can add something like
ASSERT(xs_state_users) before decrementing the counter.
Juergen
On 20/02/18 05:56, Simon Gaiser wrote:
> Juergen Gross:
>> On 07/02/18 23:22, Simon Gaiser wrote:
>>> Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple
>>> concurrent xenstore accesses") made a subtle change to the semantic of
>>> xenbus_dev_request_and_reply() and xenbus_transaction_end().
>>>
>>> Before on an error response to XS_TRANSACTION_END
>>> xenbus_dev_request_and_reply() would not decrement the active
>>> transaction counter. But xenbus_transaction_end() has always counted the
>>> transaction as finished regardless of the response.
>>
>> Which is correct now. Xenstore will free all transaction related
>> data regardless of the response. A once failed transaction can't
>> be repaired, it has to be repeated completely.
>
> So if xenstore frees the transaction why should we keep it in the list
> with pending transaction in xenbus_dev_frontend? That's exactly what
> this patch fixes by always removing it from the list, not only on a
> successful response (See below for the EINVAL case).
Aah, sorry, I seem to have misread my own coding. :-(
Yes, you are right. Sorry for not seeing it before.
>
> [...]
>>> But xenbus_dev_frontend tries to end a transaction on closing of the
>>> device if the XS_TRANSACTION_END failed before. Trying to close the
>>> transaction twice corrupts the reference count. So fix this by also
>>> considering a transaction closed if we have sent XS_TRANSACTION_END once
>>> regardless of the return code.
>>
>> A transaction in the list of transactions should not considered to be
>> finished. Either it is not on the list or it is still pending.
>
> With "considering a transaction closed" I mean "take the code path which
> removes the transaction from the list with pending transactions".
>
> From the follow-up mail:
>>>> The new behavior is that xenbus_dev_request_and_reply() and
>>>> xenbus_transaction_end() will always count the transaction as finished
>>>> regardless the response code (handled in xs_request_exit()).
>>>
>>> ENOENT should not decrement the transaction counter, while all
>>> other responses to XS_TRANSACTION_END should still do so.
>>
>> Sorry, I stand corrected: the ENOENT case should never happen, as this
>> case is tested in xenbus_write_transaction(). It doesn't hurt to test
>> for ENOENT, though.
>>
>> What should be handled is EINVAL: this would happen if a user specified
>> a string different from "T" and "F".
>
> Ok, I will handle those cases in xs_request_exit(). Although I don't
> like that this depends on the internals of xenstore (At least to me it's
> not obvious why it should only return ENOENT or EINVAL in this case).
>
> In the xenbus_write_transaction() case checking the string before
> sending the transaction (like the transaction itself is verified) would
> avoid this problem.
Right. I'd prefer this solution.
Remains the only problem you tried to tackle with your second patch: a
kernel driver going crazy and ending transactions it never started (or
ending them multiple times). The EINVAL case can't happen here, but
ENOENT can. Either ENOENT has to be handled in xs_request_exit() or you
need to keep track of the transactions like in the user interface and
refuse ending an unknown transaction. Or you trust the kernel users.
Trying to fix the usage counter seems to be the wrong approach IMO.
Juergen
On Fri, Mar 02, 2018 at 01:46:47PM +0100, Wolfram Sang wrote:
>
> So, maybe some words why I accepted this patch.
>
> On Fri, Mar 02, 2018 at 11:19:31AM +0000, Russell King - ARM Linux wrote:
> > Note that there have been patches proposed to make platform_get_irq()
> > return an error rather than returning a value of zero, so changing
> > the driver in this way is not a good idea.
>
> I'd much agree to such an approach, yet I didn't see it coming along so
> far for years(?) now.
It needs platform maintainers to be motivated to fix it, and one way to
provide that motivation is for subsystem maintainers to say no to patches
like this. If patches like this get accepted, then the "problem" gets
solved, and there is very little motivation to fix the platform itself.
If you look back at the history of this, the times when platforms have
been fixed is when they have a problem exactly like this, and they're
told to fix their platforms IRQ numbering instead of the patch to "fix"
the driver being accepted.
Why fix the interrupt numbering if patches to "fix" drivers get
accepted?
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
Interrupt number 0 (returned by platform_get_irq()) might be a valid IRQ
so do not treat it as an error. If interrupt 0 was configured, the driver
would exit the probe early, before finishing initialization, but with
0-exit status.
Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: stable(a)vger.kernel.org
Fixes: e0d1ec97853f ("i2c-s3c2410: Change IRQ to be plain integer.")
Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org>
---
drivers/i2c/busses/i2c-s3c2410.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 5d97510ee48b..783a93404f47 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -1178,7 +1178,7 @@ static int s3c24xx_i2c_probe(struct platform_device *pdev)
*/
if (!(i2c->quirks & QUIRK_POLL)) {
i2c->irq = ret = platform_get_irq(pdev, 0);
- if (ret <= 0) {
+ if (ret < 0) {
dev_err(&pdev->dev, "cannot find IRQ\n");
clk_unprepare(i2c->clk);
return ret;
--
2.7.4
On Fri, Mar 02, 2018 at 11:29:26AM +0100, Wolfram Sang wrote:
> On Thu, Mar 01, 2018 at 09:34:44PM +0100, Krzysztof Kozlowski wrote:
> > Interrupt number 0 (returned by platform_get_irq()) might be a valid IRQ
> > so do not treat it as an error. If interrupt 0 was configured, the driver
> > would exit the probe early, before finishing initialization, but with
> > 0-exit status.
> >
> > Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com>
> > Cc: stable(a)vger.kernel.org
> > Fixes: e0d1ec97853f ("i2c-s3c2410: Change IRQ to be plain integer.")
>
> Please configure git to use 14 digits here.
Wait, when did we decide that 12 wasn't enough?
I just did a `git log | grep Fixes | tee baz | head -n 200` and only on
my git tree tehre were only 2 which used exactly 14 digits. The
standard is 12.
regards,
dan carpenter
The Highpoint RocketRAID 644L uses a Marvel 88SE9235 controller, as with
other Marvel controllers this needs a function 1 DMA alias quirk.
Note the RocketRAID 642L uses the same Marvel 88SE9235 controller and
already is listed with a function 1 DMA alias quirk.
Cc: stable(a)vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1534106
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/pci/quirks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 8b14bd326d4a..46d47bd6ca1f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3908,6 +3908,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9230,
quirk_dma_func1_alias);
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TTI, 0x0642,
quirk_dma_func1_alias);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TTI, 0x0645,
+ quirk_dma_func1_alias);
/* https://bugs.gentoo.org/show_bug.cgi?id=497630 */
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_JMICRON,
PCI_DEVICE_ID_JMICRON_JMB388_ESD,
--
2.14.3
Like the Highpoint Rocketraid 642L and cards using a Marvel 88SE9235
controller in general, this RAID card also supports AHCI mode and short
of a custom driver, this is the only way to make it work under Linux.
Note that even though the card is called to 644L, it has a product-id
of 0x0645.
Cc: stable(a)vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1534106
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/ata/ahci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 355a95a83a34..1ff17799769d 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -550,7 +550,9 @@ static const struct pci_device_id ahci_pci_tbl[] = {
.driver_data = board_ahci_yes_fbs },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x9230),
.driver_data = board_ahci_yes_fbs },
- { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x0642),
+ { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x0642), /* highpoint rocketraid 642L */
+ .driver_data = board_ahci_yes_fbs },
+ { PCI_DEVICE(PCI_VENDOR_ID_TTI, 0x0645), /* highpoint rocketraid 644L */
.driver_data = board_ahci_yes_fbs },
/* Promise */
--
2.14.3
This is a note to let you know that I've just added the patch titled
net_sched: get rid of rcu_barrier() in tcf_block_put_ext()
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:
net_sched-get-rid-of-rcu_barrier-in-tcf_block_put_ext.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 efbf78973978b0d25af59bc26c8013a942af6e64 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong(a)gmail.com>
Date: Mon, 4 Dec 2017 10:48:18 -0800
Subject: net_sched: get rid of rcu_barrier() in tcf_block_put_ext()
From: Cong Wang <xiyou.wangcong(a)gmail.com>
commit efbf78973978b0d25af59bc26c8013a942af6e64 upstream.
Both Eric and Paolo noticed the rcu_barrier() we use in
tcf_block_put_ext() could be a performance bottleneck when
we have a lot of tc classes.
Paolo provided the following to demonstrate the issue:
tc qdisc add dev lo root htb
for I in `seq 1 1000`; do
tc class add dev lo parent 1: classid 1:$I htb rate 100kbit
tc qdisc add dev lo parent 1:$I handle $((I + 1)): htb
for J in `seq 1 10`; do
tc filter add dev lo parent $((I + 1)): u32 match ip src 1.1.1.$J
done
done
time tc qdisc del dev root
real 0m54.764s
user 0m0.023s
sys 0m0.000s
The rcu_barrier() there is to ensure we free the block after all chains
are gone, that is, to queue tcf_block_put_final() at the tail of workqueue.
We can achieve this ordering requirement by refcnt'ing tcf block instead,
that is, the tcf block is freed only when the last chain in this block is
gone. This also simplifies the code.
Paolo reported after this patch we get:
real 0m0.017s
user 0m0.000s
sys 0m0.017s
Tested-by: Paolo Abeni <pabeni(a)redhat.com>
Cc: Eric Dumazet <edumazet(a)google.com>
Cc: Jiri Pirko <jiri(a)mellanox.com>
Cc: Jamal Hadi Salim <jhs(a)mojatatu.com>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/net/sch_generic.h | 1 -
net/sched/cls_api.c | 29 +++++++++--------------------
2 files changed, 9 insertions(+), 21 deletions(-)
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -273,7 +273,6 @@ struct tcf_chain {
struct tcf_block {
struct list_head chain_list;
- struct work_struct work;
};
static inline void qdisc_cb_private_validate(const struct sk_buff *skb, int sz)
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -211,8 +211,12 @@ static void tcf_chain_flush(struct tcf_c
static void tcf_chain_destroy(struct tcf_chain *chain)
{
+ struct tcf_block *block = chain->block;
+
list_del(&chain->list);
kfree(chain);
+ if (list_empty(&block->chain_list))
+ kfree(block);
}
static void tcf_chain_hold(struct tcf_chain *chain)
@@ -276,26 +280,12 @@ err_chain_create:
}
EXPORT_SYMBOL(tcf_block_get);
-static void tcf_block_put_final(struct work_struct *work)
-{
- struct tcf_block *block = container_of(work, struct tcf_block, work);
- struct tcf_chain *chain, *tmp;
-
- rtnl_lock();
-
- /* At this point, all the chains should have refcnt == 1. */
- list_for_each_entry_safe(chain, tmp, &block->chain_list, list)
- tcf_chain_put(chain);
- rtnl_unlock();
- kfree(block);
-}
-
/* XXX: Standalone actions are not allowed to jump to any chain, and bound
* actions should be all removed after flushing.
*/
void tcf_block_put(struct tcf_block *block)
{
- struct tcf_chain *chain;
+ struct tcf_chain *chain, *tmp;
if (!block)
return;
@@ -310,12 +300,11 @@ void tcf_block_put(struct tcf_block *blo
list_for_each_entry(chain, &block->chain_list, list)
tcf_chain_flush(chain);
- INIT_WORK(&block->work, tcf_block_put_final);
- /* Wait for RCU callbacks to release the reference count and make
- * sure their works have been queued before this.
+ /* At this point, all the chains should have refcnt >= 1. Block will be
+ * freed after all chains are gone.
*/
- rcu_barrier();
- tcf_queue_work(&block->work);
+ list_for_each_entry_safe(chain, tmp, &block->chain_list, list)
+ tcf_chain_put(chain);
}
EXPORT_SYMBOL(tcf_block_put);
Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are
queue-4.14/net_sched-get-rid-of-rcu_barrier-in-tcf_block_put_ext.patch
queue-4.14/net-sched-crash-on-blocks-with-goto-chain-action.patch
queue-4.14/net-sched-fix-use-after-free-in-tcf_block_put_ext.patch
queue-4.14/net-sched-fix-crash-when-deleting-secondary-chains.patch
This is a note to let you know that I've just added the patch titled
net: sched: fix use-after-free in tcf_block_put_ext
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:
net-sched-fix-use-after-free-in-tcf_block_put_ext.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 df45bf84e4f5a48f23d4b1a07d21d566e8b587b2 Mon Sep 17 00:00:00 2001
From: Jiri Pirko <jiri(a)mellanox.com>
Date: Fri, 8 Dec 2017 19:27:27 +0100
Subject: net: sched: fix use-after-free in tcf_block_put_ext
From: Jiri Pirko <jiri(a)mellanox.com>
commit df45bf84e4f5a48f23d4b1a07d21d566e8b587b2 upstream.
Since the block is freed with last chain being put, once we reach the
end of iteration of list_for_each_entry_safe, the block may be
already freed. I'm hitting this only by creating and deleting clsact:
[ 202.171952] ==================================================================
[ 202.180182] BUG: KASAN: use-after-free in tcf_block_put_ext+0x240/0x390
[ 202.187590] Read of size 8 at addr ffff880225539a80 by task tc/796
[ 202.194508]
[ 202.196185] CPU: 0 PID: 796 Comm: tc Not tainted 4.15.0-rc2jiri+ #5
[ 202.203200] Hardware name: Mellanox Technologies Ltd. "MSN2100-CB2F"/"SA001017", BIOS 5.6.5 06/07/2016
[ 202.213613] Call Trace:
[ 202.216369] dump_stack+0xda/0x169
[ 202.220192] ? dma_virt_map_sg+0x147/0x147
[ 202.224790] ? show_regs_print_info+0x54/0x54
[ 202.229691] ? tcf_chain_destroy+0x1dc/0x250
[ 202.234494] print_address_description+0x83/0x3d0
[ 202.239781] ? tcf_block_put_ext+0x240/0x390
[ 202.244575] kasan_report+0x1ba/0x460
[ 202.248707] ? tcf_block_put_ext+0x240/0x390
[ 202.253518] tcf_block_put_ext+0x240/0x390
[ 202.258117] ? tcf_chain_flush+0x290/0x290
[ 202.262708] ? qdisc_hash_del+0x82/0x1a0
[ 202.267111] ? qdisc_hash_add+0x50/0x50
[ 202.271411] ? __lock_is_held+0x5f/0x1a0
[ 202.275843] clsact_destroy+0x3d/0x80 [sch_ingress]
[ 202.281323] qdisc_destroy+0xcb/0x240
[ 202.285445] qdisc_graft+0x216/0x7b0
[ 202.289497] tc_get_qdisc+0x260/0x560
Fix this by holding the block also by chain 0 and put chain 0
explicitly, out of the list_for_each_entry_safe loop at the very
end of tcf_block_put_ext.
Fixes: efbf78973978 ("net_sched: get rid of rcu_barrier() in tcf_block_put_ext()")
Signed-off-by: Jiri Pirko <jiri(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Cc: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sched/cls_api.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -290,21 +290,22 @@ void tcf_block_put(struct tcf_block *blo
if (!block)
return;
- /* Hold a refcnt for all chains, except 0, so that they don't disappear
+ /* Hold a refcnt for all chains, so that they don't disappear
* while we are iterating.
*/
list_for_each_entry(chain, &block->chain_list, list)
- if (chain->index)
- tcf_chain_hold(chain);
+ tcf_chain_hold(chain);
list_for_each_entry(chain, &block->chain_list, list)
tcf_chain_flush(chain);
- /* At this point, all the chains should have refcnt >= 1. Block will be
- * freed after all chains are gone.
- */
+ /* At this point, all the chains should have refcnt >= 1. */
list_for_each_entry_safe(chain, tmp, &block->chain_list, list)
tcf_chain_put(chain);
+
+ /* Finally, put chain 0 and allow block to be freed. */
+ chain = list_first_entry(&block->chain_list, struct tcf_chain, list);
+ tcf_chain_put(chain);
}
EXPORT_SYMBOL(tcf_block_put);
Patches currently in stable-queue which might be from jiri(a)mellanox.com are
queue-4.14/net_sched-get-rid-of-rcu_barrier-in-tcf_block_put_ext.patch
queue-4.14/mlxsw-pci-wait-after-reset-before-accessing-hw.patch
queue-4.14/net-sched-crash-on-blocks-with-goto-chain-action.patch
queue-4.14/net-sched-fix-use-after-free-in-tcf_block_put_ext.patch
queue-4.14/net-sched-fix-crash-when-deleting-secondary-chains.patch
This is a note to let you know that I've just added the patch titled
net: sched: fix crash when deleting secondary chains
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:
net-sched-fix-crash-when-deleting-secondary-chains.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 d7aa04a5e82b4f254d306926c81eae8df69e5200 Mon Sep 17 00:00:00 2001
From: Roman Kapl <code(a)rkapl.cz>
Date: Mon, 20 Nov 2017 22:21:13 +0100
Subject: net: sched: fix crash when deleting secondary chains
From: Roman Kapl <code(a)rkapl.cz>
commit d7aa04a5e82b4f254d306926c81eae8df69e5200 upstream.
If you flush (delete) a filter chain other than chain 0 (such as when
deleting the device), the kernel may run into a use-after-free. The
chain refcount must not be decremented unless we are sure we are done
with the chain.
To reproduce the bug, run:
ip link add dtest type dummy
tc qdisc add dev dtest ingress
tc filter add dev dtest chain 1 parent ffff: flower
ip link del dtest
Introduced in: commit f93e1cdcf42c ("net/sched: fix filter flushing"),
but unless you have KAsan or luck, you won't notice it until
commit 0dadc117ac8b ("cls_flower: use tcf_exts_get_net() before call_rcu()")
Fixes: f93e1cdcf42c ("net/sched: fix filter flushing")
Acked-by: Jiri Pirko <jiri(a)mellanox.com>
Signed-off-by: Roman Kapl <code(a)rkapl.cz>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Cc: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sched/cls_api.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -197,14 +197,15 @@ static struct tcf_chain *tcf_chain_creat
static void tcf_chain_flush(struct tcf_chain *chain)
{
- struct tcf_proto *tp;
+ struct tcf_proto *tp = rtnl_dereference(chain->filter_chain);
if (chain->p_filter_chain)
RCU_INIT_POINTER(*chain->p_filter_chain, NULL);
- while ((tp = rtnl_dereference(chain->filter_chain)) != NULL) {
+ while (tp) {
RCU_INIT_POINTER(chain->filter_chain, tp->next);
- tcf_chain_put(chain);
tcf_proto_destroy(tp);
+ tp = rtnl_dereference(chain->filter_chain);
+ tcf_chain_put(chain);
}
}
Patches currently in stable-queue which might be from code(a)rkapl.cz are
queue-4.14/net-sched-crash-on-blocks-with-goto-chain-action.patch
queue-4.14/net-sched-fix-crash-when-deleting-secondary-chains.patch
This is a note to let you know that I've just added the patch titled
net: sched: crash on blocks with goto chain action
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:
net-sched-crash-on-blocks-with-goto-chain-action.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 a60b3f515d30d0fe8537c64671926879a3548103 Mon Sep 17 00:00:00 2001
From: Roman Kapl <code(a)rkapl.cz>
Date: Fri, 24 Nov 2017 12:27:58 +0100
Subject: net: sched: crash on blocks with goto chain action
From: Roman Kapl <code(a)rkapl.cz>
commit a60b3f515d30d0fe8537c64671926879a3548103 upstream.
tcf_block_put_ext has assumed that all filters (and thus their goto
actions) are destroyed in RCU callback and thus can not race with our
list iteration. However, that is not true during netns cleanup (see
tcf_exts_get_net comment).
Prevent the user after free by holding all chains (except 0, that one is
already held). foreach_safe is not enough in this case.
To reproduce, run the following in a netns and then delete the ns:
ip link add dtest type dummy
tc qdisc add dev dtest ingress
tc filter add dev dtest chain 1 parent ffff: handle 1 prio 1 flower action goto chain 2
Fixes: 822e86d997 ("net_sched: remove tcf_block_put_deferred()")
Signed-off-by: Roman Kapl <code(a)rkapl.cz>
Acked-by: Jiri Pirko <jiri(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Cc: Cong Wang <xiyou.wangcong(a)gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sched/cls_api.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -282,7 +282,8 @@ static void tcf_block_put_final(struct w
struct tcf_chain *chain, *tmp;
rtnl_lock();
- /* Only chain 0 should be still here. */
+
+ /* At this point, all the chains should have refcnt == 1. */
list_for_each_entry_safe(chain, tmp, &block->chain_list, list)
tcf_chain_put(chain);
rtnl_unlock();
@@ -290,17 +291,23 @@ static void tcf_block_put_final(struct w
}
/* XXX: Standalone actions are not allowed to jump to any chain, and bound
- * actions should be all removed after flushing. However, filters are now
- * destroyed in tc filter workqueue with RTNL lock, they can not race here.
+ * actions should be all removed after flushing.
*/
void tcf_block_put(struct tcf_block *block)
{
- struct tcf_chain *chain, *tmp;
+ struct tcf_chain *chain;
if (!block)
return;
- list_for_each_entry_safe(chain, tmp, &block->chain_list, list)
+ /* Hold a refcnt for all chains, except 0, so that they don't disappear
+ * while we are iterating.
+ */
+ list_for_each_entry(chain, &block->chain_list, list)
+ if (chain->index)
+ tcf_chain_hold(chain);
+
+ list_for_each_entry(chain, &block->chain_list, list)
tcf_chain_flush(chain);
INIT_WORK(&block->work, tcf_block_put_final);
Patches currently in stable-queue which might be from code(a)rkapl.cz are
queue-4.14/net-sched-crash-on-blocks-with-goto-chain-action.patch
queue-4.14/net-sched-fix-crash-when-deleting-secondary-chains.patch
This is a note to let you know that I've just added the patch titled
arm64: dts: marvell: mcbin: add comphy references to Ethernet ports
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-dts-marvell-mcbin-add-comphy-references-to-ethernet-ports.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 760b3843fcd88f2a46e66eec08e2e6023a425809 Mon Sep 17 00:00:00 2001
From: Antoine Tenart <antoine.tenart(a)free-electrons.com>
Date: Thu, 21 Sep 2017 09:54:07 +0200
Subject: arm64: dts: marvell: mcbin: add comphy references to Ethernet ports
From: Antoine Tenart <antoine.tenart(a)free-electrons.com>
commit 760b3843fcd88f2a46e66eec08e2e6023a425809 upstream.
This patch adds comphy phandles to the Ethernet ports in the mcbin
device tree. The comphy is used to configure the serdes PHYs used by
these ports.
Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com>
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement(a)free-electrons.com>
Cc: Mikulas Patocka <mpatocka(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -228,8 +228,11 @@
&cpm_eth0 {
status = "okay";
+ /* Network PHY */
phy = <&phy0>;
phy-mode = "10gbase-kr";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cpm_comphy4 0>;
};
&cpm_sata0 {
@@ -263,15 +266,21 @@
&cps_eth0 {
status = "okay";
+ /* Network PHY */
phy = <&phy8>;
phy-mode = "10gbase-kr";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cps_comphy4 0>;
};
&cps_eth1 {
/* CPS Lane 0 - J5 (Gigabit RJ45) */
status = "okay";
+ /* Network PHY */
phy = <&ge_phy>;
phy-mode = "sgmii";
+ /* Generic PHY, providing serdes lanes */
+ phys = <&cps_comphy0 1>;
};
&cps_pinctrl {
Patches currently in stable-queue which might be from antoine.tenart(a)free-electrons.com are
queue-4.14/arm64-dts-marvell-mcbin-add-comphy-references-to-ethernet-ports.patch
queue-4.14/crypto-inside-secure-per-request-invalidation.patch
queue-4.14/arm64-dts-marvell-add-comphy-nodes-on-cp110-master-and-slave.patch
queue-4.14/crypto-inside-secure-fix-request-allocations-in-invalidation-path.patch
queue-4.14/crypto-inside-secure-free-requests-even-if-their-handling-failed.patch
This patchset backports 4 important bug fixes for tc filter to
4.14 stable branch. Due to some big changes between 4.14 and 4.15,
the backports are not trivial, I have to adjust and fix the conflicts
manually.
Thanks to Roland for reporting the kernel warning and testing
the patches.
Reported-by: Roland Franke <fli4l(a)franke-prem.de>
Tested-by: Roland Franke <fli4l(a)franke-prem.de>
Cc: Jiri Pirko <jiri(a)mellanox.com>
Cc: Roman Kapl <code(a)rkapl.cz>
Cc: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com>
---
Cong Wang (1):
net_sched: get rid of rcu_barrier() in tcf_block_put_ext()
Jiri Pirko (1):
net: sched: fix use-after-free in tcf_block_put_ext
Roman Kapl (2):
net: sched: fix crash when deleting secondary chains
net: sched: crash on blocks with goto chain action
include/net/sch_generic.h | 1 -
net/sched/cls_api.c | 48 +++++++++++++++++++++++------------------------
2 files changed, 23 insertions(+), 26 deletions(-)
--
2.13.0
This is a note to let you know that I've just added the patch titled
MIPS: Implement __multi3 for GCC7 MIPS64r6 builds
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:
mips-implement-__multi3-for-gcc7-mips64r6-builds.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 ebabcf17bcd7ce968b1631ebe08236275698f39b Mon Sep 17 00:00:00 2001
From: James Hogan <jhogan(a)kernel.org>
Date: Thu, 7 Dec 2017 07:20:46 +0000
Subject: MIPS: Implement __multi3 for GCC7 MIPS64r6 builds
From: James Hogan <jhogan(a)kernel.org>
commit ebabcf17bcd7ce968b1631ebe08236275698f39b upstream.
GCC7 is a bit too eager to generate suboptimal __multi3 calls (128bit
multiply with 128bit result) for MIPS64r6 builds, even in code which
doesn't explicitly use 128bit types, such as the following:
unsigned long func(unsigned long a, unsigned long b)
{
return a > (~0UL) / b;
}
Which GCC rearanges to:
return (unsigned __int128)a * (unsigned __int128)b > 0xffffffffffffffff;
Therefore implement __multi3, but only for MIPS64r6 with GCC7 as under
normal circumstances we wouldn't expect any calls to __multi3 to be
generated from kernel code.
Reported-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Tested-by: Waldemar Brodkorb <wbx(a)openadk.org>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Maciej W. Rozycki <macro(a)mips.com>
Cc: Matthew Fortune <matthew.fortune(a)mips.com>
Cc: Florian Fainelli <florian(a)openwrt.org>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17890/
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/lib/Makefile | 3 +-
arch/mips/lib/libgcc.h | 17 +++++++++++++++
arch/mips/lib/multi3.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 73 insertions(+), 1 deletion(-)
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -15,4 +15,5 @@ obj-$(CONFIG_CPU_R3000) += r3k_dump_tlb
obj-$(CONFIG_CPU_TX39XX) += r3k_dump_tlb.o
# libgcc-style stuff needed in the kernel
-obj-y += ashldi3.o ashrdi3.o bswapsi.o bswapdi.o cmpdi2.o lshrdi3.o ucmpdi2.o
+obj-y += ashldi3.o ashrdi3.o bswapsi.o bswapdi.o cmpdi2.o lshrdi3.o multi3.o \
+ ucmpdi2.o
--- a/arch/mips/lib/libgcc.h
+++ b/arch/mips/lib/libgcc.h
@@ -9,10 +9,18 @@ typedef int word_type __attribute__ ((mo
struct DWstruct {
int high, low;
};
+
+struct TWstruct {
+ long long high, low;
+};
#elif defined(__LITTLE_ENDIAN)
struct DWstruct {
int low, high;
};
+
+struct TWstruct {
+ long long low, high;
+};
#else
#error I feel sick.
#endif
@@ -22,4 +30,13 @@ typedef union {
long long ll;
} DWunion;
+#if defined(CONFIG_64BIT) && defined(CONFIG_CPU_MIPSR6)
+typedef int ti_type __attribute__((mode(TI)));
+
+typedef union {
+ struct TWstruct s;
+ ti_type ti;
+} TWunion;
+#endif
+
#endif /* __ASM_LIBGCC_H */
--- /dev/null
+++ b/arch/mips/lib/multi3.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/export.h>
+
+#include "libgcc.h"
+
+/*
+ * GCC 7 suboptimally generates __multi3 calls for mips64r6, so for that
+ * specific case only we'll implement it here.
+ *
+ * See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981
+ */
+#if defined(CONFIG_64BIT) && defined(CONFIG_CPU_MIPSR6) && (__GNUC__ == 7)
+
+/* multiply 64-bit values, low 64-bits returned */
+static inline long long notrace dmulu(long long a, long long b)
+{
+ long long res;
+
+ asm ("dmulu %0,%1,%2" : "=r" (res) : "r" (a), "r" (b));
+ return res;
+}
+
+/* multiply 64-bit unsigned values, high 64-bits of 128-bit result returned */
+static inline long long notrace dmuhu(long long a, long long b)
+{
+ long long res;
+
+ asm ("dmuhu %0,%1,%2" : "=r" (res) : "r" (a), "r" (b));
+ return res;
+}
+
+/* multiply 128-bit values, low 128-bits returned */
+ti_type notrace __multi3(ti_type a, ti_type b)
+{
+ TWunion res, aa, bb;
+
+ aa.ti = a;
+ bb.ti = b;
+
+ /*
+ * a * b = (a.lo * b.lo)
+ * + 2^64 * (a.hi * b.lo + a.lo * b.hi)
+ * [+ 2^128 * (a.hi * b.hi)]
+ */
+ res.s.low = dmulu(aa.s.low, bb.s.low);
+ res.s.high = dmuhu(aa.s.low, bb.s.low);
+ res.s.high += dmulu(aa.s.high, bb.s.low);
+ res.s.high += dmulu(aa.s.low, bb.s.high);
+
+ return res.ti;
+}
+EXPORT_SYMBOL(__multi3);
+
+#endif /* 64BIT && CPU_MIPSR6 && GCC7 */
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.9/lib-mpi-fix-umul_ppmm-for-mips64r6.patch
queue-4.9/mips-implement-__multi3-for-gcc7-mips64r6-builds.patch
This is a note to let you know that I've just added the patch titled
MIPS: Implement __multi3 for GCC7 MIPS64r6 builds
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:
mips-implement-__multi3-for-gcc7-mips64r6-builds.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 ebabcf17bcd7ce968b1631ebe08236275698f39b Mon Sep 17 00:00:00 2001
From: James Hogan <jhogan(a)kernel.org>
Date: Thu, 7 Dec 2017 07:20:46 +0000
Subject: MIPS: Implement __multi3 for GCC7 MIPS64r6 builds
From: James Hogan <jhogan(a)kernel.org>
commit ebabcf17bcd7ce968b1631ebe08236275698f39b upstream.
GCC7 is a bit too eager to generate suboptimal __multi3 calls (128bit
multiply with 128bit result) for MIPS64r6 builds, even in code which
doesn't explicitly use 128bit types, such as the following:
unsigned long func(unsigned long a, unsigned long b)
{
return a > (~0UL) / b;
}
Which GCC rearanges to:
return (unsigned __int128)a * (unsigned __int128)b > 0xffffffffffffffff;
Therefore implement __multi3, but only for MIPS64r6 with GCC7 as under
normal circumstances we wouldn't expect any calls to __multi3 to be
generated from kernel code.
Reported-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Tested-by: Waldemar Brodkorb <wbx(a)openadk.org>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Maciej W. Rozycki <macro(a)mips.com>
Cc: Matthew Fortune <matthew.fortune(a)mips.com>
Cc: Florian Fainelli <florian(a)openwrt.org>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17890/
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/lib/Makefile | 3 +-
arch/mips/lib/libgcc.h | 17 +++++++++++++++
arch/mips/lib/multi3.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 73 insertions(+), 1 deletion(-)
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -15,4 +15,5 @@ obj-$(CONFIG_CPU_R3000) += r3k_dump_tlb
obj-$(CONFIG_CPU_TX39XX) += r3k_dump_tlb.o
# libgcc-style stuff needed in the kernel
-obj-y += ashldi3.o ashrdi3.o bswapsi.o bswapdi.o cmpdi2.o lshrdi3.o ucmpdi2.o
+obj-y += ashldi3.o ashrdi3.o bswapsi.o bswapdi.o cmpdi2.o lshrdi3.o multi3.o \
+ ucmpdi2.o
--- a/arch/mips/lib/libgcc.h
+++ b/arch/mips/lib/libgcc.h
@@ -9,10 +9,18 @@ typedef int word_type __attribute__ ((mo
struct DWstruct {
int high, low;
};
+
+struct TWstruct {
+ long long high, low;
+};
#elif defined(__LITTLE_ENDIAN)
struct DWstruct {
int low, high;
};
+
+struct TWstruct {
+ long long low, high;
+};
#else
#error I feel sick.
#endif
@@ -22,4 +30,13 @@ typedef union {
long long ll;
} DWunion;
+#if defined(CONFIG_64BIT) && defined(CONFIG_CPU_MIPSR6)
+typedef int ti_type __attribute__((mode(TI)));
+
+typedef union {
+ struct TWstruct s;
+ ti_type ti;
+} TWunion;
+#endif
+
#endif /* __ASM_LIBGCC_H */
--- /dev/null
+++ b/arch/mips/lib/multi3.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/export.h>
+
+#include "libgcc.h"
+
+/*
+ * GCC 7 suboptimally generates __multi3 calls for mips64r6, so for that
+ * specific case only we'll implement it here.
+ *
+ * See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981
+ */
+#if defined(CONFIG_64BIT) && defined(CONFIG_CPU_MIPSR6) && (__GNUC__ == 7)
+
+/* multiply 64-bit values, low 64-bits returned */
+static inline long long notrace dmulu(long long a, long long b)
+{
+ long long res;
+
+ asm ("dmulu %0,%1,%2" : "=r" (res) : "r" (a), "r" (b));
+ return res;
+}
+
+/* multiply 64-bit unsigned values, high 64-bits of 128-bit result returned */
+static inline long long notrace dmuhu(long long a, long long b)
+{
+ long long res;
+
+ asm ("dmuhu %0,%1,%2" : "=r" (res) : "r" (a), "r" (b));
+ return res;
+}
+
+/* multiply 128-bit values, low 128-bits returned */
+ti_type notrace __multi3(ti_type a, ti_type b)
+{
+ TWunion res, aa, bb;
+
+ aa.ti = a;
+ bb.ti = b;
+
+ /*
+ * a * b = (a.lo * b.lo)
+ * + 2^64 * (a.hi * b.lo + a.lo * b.hi)
+ * [+ 2^128 * (a.hi * b.hi)]
+ */
+ res.s.low = dmulu(aa.s.low, bb.s.low);
+ res.s.high = dmuhu(aa.s.low, bb.s.low);
+ res.s.high += dmulu(aa.s.high, bb.s.low);
+ res.s.high += dmulu(aa.s.low, bb.s.high);
+
+ return res.ti;
+}
+EXPORT_SYMBOL(__multi3);
+
+#endif /* 64BIT && CPU_MIPSR6 && GCC7 */
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.4/lib-mpi-fix-umul_ppmm-for-mips64r6.patch
queue-4.4/mips-implement-__multi3-for-gcc7-mips64r6-builds.patch
This is a note to let you know that I've just added the patch titled
powerpc/pseries: Enable RAS hotplug events later
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:
powerpc-pseries-enable-ras-hotplug-events-later.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 c9dccf1d074a67d36c510845f663980d69e3409b Mon Sep 17 00:00:00 2001
From: Sam Bobroff <sam.bobroff(a)au1.ibm.com>
Date: Mon, 12 Feb 2018 11:19:29 +1100
Subject: powerpc/pseries: Enable RAS hotplug events later
From: Sam Bobroff <sam.bobroff(a)au1.ibm.com>
commit c9dccf1d074a67d36c510845f663980d69e3409b upstream.
Currently if the kernel receives a memory hot-unplug event early
enough, it may get stuck in an infinite loop in
dissolve_free_huge_pages(). This appears as a stall just after:
pseries-hotplug-mem: Attempting to hot-remove XX LMB(s) at YYYYYYYY
It appears to be caused by "minimum_order" being uninitialized, due to
init_ras_IRQ() executing before hugetlb_init().
To correct this, extract the part of init_ras_IRQ() that enables
hotplug event processing and place it in the machine_late_initcall
phase, which is guaranteed to be after hugetlb_init() is called.
Signed-off-by: Sam Bobroff <sam.bobroff(a)au1.ibm.com>
Acked-by: Balbir Singh <bsingharora(a)gmail.com>
[mpe: Reorder the functions to make the diff readable]
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/platforms/pseries/ras.c | 31 ++++++++++++++++++++++---------
1 file changed, 22 insertions(+), 9 deletions(-)
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -49,6 +49,28 @@ static irqreturn_t ras_error_interrupt(i
/*
+ * Enable the hotplug interrupt late because processing them may touch other
+ * devices or systems (e.g. hugepages) that have not been initialized at the
+ * subsys stage.
+ */
+int __init init_ras_hotplug_IRQ(void)
+{
+ struct device_node *np;
+
+ /* Hotplug Events */
+ np = of_find_node_by_path("/event-sources/hot-plug-events");
+ if (np != NULL) {
+ if (dlpar_workqueue_init() == 0)
+ request_event_sources_irqs(np, ras_hotplug_interrupt,
+ "RAS_HOTPLUG");
+ of_node_put(np);
+ }
+
+ return 0;
+}
+machine_late_initcall(pseries, init_ras_hotplug_IRQ);
+
+/*
* Initialize handlers for the set of interrupts caused by hardware errors
* and power system events.
*/
@@ -66,15 +88,6 @@ static int __init init_ras_IRQ(void)
of_node_put(np);
}
- /* Hotplug Events */
- np = of_find_node_by_path("/event-sources/hot-plug-events");
- if (np != NULL) {
- if (dlpar_workqueue_init() == 0)
- request_event_sources_irqs(np, ras_hotplug_interrupt,
- "RAS_HOTPLUG");
- of_node_put(np);
- }
-
/* EPOW Events */
np = of_find_node_by_path("/event-sources/epow-events");
if (np != NULL) {
Patches currently in stable-queue which might be from sam.bobroff(a)au1.ibm.com are
queue-4.15/powerpc-pseries-enable-ras-hotplug-events-later.patch
This is a note to let you know that I've just added the patch titled
powerpc/pseries: Make RAS IRQ explicitly dependent on DLPAR WQ
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:
powerpc-pseries-make-ras-irq-explicitly-dependent-on-dlpar-wq.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 28 16:23:28 CET 2018
From: Michael Ellerman <mpe(a)ellerman.id.au>
Date: Mon, 8 Jan 2018 14:54:32 +1100
Subject: powerpc/pseries: Make RAS IRQ explicitly dependent on DLPAR WQ
From: Michael Ellerman <mpe(a)ellerman.id.au>
[ Upstream commit e2d5915293ffdff977ddcfc12b817b08c53ffa7a ]
The hotplug code uses its own workqueue to handle IRQ requests
(pseries_hp_wq), however that workqueue is initialized after
init_ras_IRQ(). That can lead to a kernel panic if any hotplug
interrupts fire after init_ras_IRQ() but before pseries_hp_wq is
initialised. eg:
UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
NET: Registered protocol family 1
Unpacking initramfs...
(qemu) object_add memory-backend-ram,id=mem1,size=10G
(qemu) device_add pc-dimm,id=dimm1,memdev=mem1
Unable to handle kernel paging request for data at address 0xf94d03007c421378
Faulting instruction address: 0xc00000000012d744
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-ziviani+ #26
task: (ptrval) task.stack: (ptrval)
NIP: c00000000012d744 LR: c00000000012d744 CTR: 0000000000000000
REGS: (ptrval) TRAP: 0380 Not tainted (4.15.0-rc2-ziviani+)
MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 28088042 XER: 20040000
CFAR: c00000000012d3c4 SOFTE: 0
...
NIP [c00000000012d744] __queue_work+0xd4/0x5c0
LR [c00000000012d744] __queue_work+0xd4/0x5c0
Call Trace:
[c0000000fffefb90] [c00000000012d744] __queue_work+0xd4/0x5c0 (unreliable)
[c0000000fffefc70] [c00000000012dce4] queue_work_on+0xb4/0xf0
This commit makes the RAS IRQ registration explicitly dependent on the
creation of the pseries_hp_wq.
Reported-by: Min Deng <mdeng(a)redhat.com>
Reported-by: Daniel Henrique Barboza <danielhb(a)linux.vnet.ibm.com>
Tested-by: Jose Ricardo Ziviani <joserz(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Reviewed-by: David Gibson <david(a)gibson.dropbear.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/platforms/pseries/dlpar.c | 21 ++++++++++++++++++---
arch/powerpc/platforms/pseries/pseries.h | 2 ++
arch/powerpc/platforms/pseries/ras.c | 3 ++-
3 files changed, 22 insertions(+), 4 deletions(-)
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -586,11 +586,26 @@ static ssize_t dlpar_show(struct class *
static CLASS_ATTR_RW(dlpar);
-static int __init pseries_dlpar_init(void)
+int __init dlpar_workqueue_init(void)
{
+ if (pseries_hp_wq)
+ return 0;
+
pseries_hp_wq = alloc_workqueue("pseries hotplug workqueue",
- WQ_UNBOUND, 1);
+ WQ_UNBOUND, 1);
+
+ return pseries_hp_wq ? 0 : -ENOMEM;
+}
+
+static int __init dlpar_sysfs_init(void)
+{
+ int rc;
+
+ rc = dlpar_workqueue_init();
+ if (rc)
+ return rc;
+
return sysfs_create_file(kernel_kobj, &class_attr_dlpar.attr);
}
-machine_device_initcall(pseries, pseries_dlpar_init);
+machine_device_initcall(pseries, dlpar_sysfs_init);
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -98,4 +98,6 @@ static inline unsigned long cmo_get_page
return CMO_PageSize;
}
+int dlpar_workqueue_init(void);
+
#endif /* _PSERIES_PSERIES_H */
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -69,7 +69,8 @@ static int __init init_ras_IRQ(void)
/* Hotplug Events */
np = of_find_node_by_path("/event-sources/hot-plug-events");
if (np != NULL) {
- request_event_sources_irqs(np, ras_hotplug_interrupt,
+ if (dlpar_workqueue_init() == 0)
+ request_event_sources_irqs(np, ras_hotplug_interrupt,
"RAS_HOTPLUG");
of_node_put(np);
}
Patches currently in stable-queue which might be from mpe(a)ellerman.id.au are
queue-4.14/powerpc-pseries-make-ras-irq-explicitly-dependent-on-dlpar-wq.patch
This is a note to let you know that I've just added the patch titled
powerpc/pseries: Enable RAS hotplug events later
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:
powerpc-pseries-enable-ras-hotplug-events-later.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 c9dccf1d074a67d36c510845f663980d69e3409b Mon Sep 17 00:00:00 2001
From: Sam Bobroff <sam.bobroff(a)au1.ibm.com>
Date: Mon, 12 Feb 2018 11:19:29 +1100
Subject: powerpc/pseries: Enable RAS hotplug events later
From: Sam Bobroff <sam.bobroff(a)au1.ibm.com>
commit c9dccf1d074a67d36c510845f663980d69e3409b upstream.
Currently if the kernel receives a memory hot-unplug event early
enough, it may get stuck in an infinite loop in
dissolve_free_huge_pages(). This appears as a stall just after:
pseries-hotplug-mem: Attempting to hot-remove XX LMB(s) at YYYYYYYY
It appears to be caused by "minimum_order" being uninitialized, due to
init_ras_IRQ() executing before hugetlb_init().
To correct this, extract the part of init_ras_IRQ() that enables
hotplug event processing and place it in the machine_late_initcall
phase, which is guaranteed to be after hugetlb_init() is called.
Signed-off-by: Sam Bobroff <sam.bobroff(a)au1.ibm.com>
Acked-by: Balbir Singh <bsingharora(a)gmail.com>
[mpe: Reorder the functions to make the diff readable]
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/platforms/pseries/ras.c | 31 ++++++++++++++++++++++---------
1 file changed, 22 insertions(+), 9 deletions(-)
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -49,6 +49,28 @@ static irqreturn_t ras_error_interrupt(i
/*
+ * Enable the hotplug interrupt late because processing them may touch other
+ * devices or systems (e.g. hugepages) that have not been initialized at the
+ * subsys stage.
+ */
+int __init init_ras_hotplug_IRQ(void)
+{
+ struct device_node *np;
+
+ /* Hotplug Events */
+ np = of_find_node_by_path("/event-sources/hot-plug-events");
+ if (np != NULL) {
+ if (dlpar_workqueue_init() == 0)
+ request_event_sources_irqs(np, ras_hotplug_interrupt,
+ "RAS_HOTPLUG");
+ of_node_put(np);
+ }
+
+ return 0;
+}
+machine_late_initcall(pseries, init_ras_hotplug_IRQ);
+
+/*
* Initialize handlers for the set of interrupts caused by hardware errors
* and power system events.
*/
@@ -66,15 +88,6 @@ static int __init init_ras_IRQ(void)
of_node_put(np);
}
- /* Hotplug Events */
- np = of_find_node_by_path("/event-sources/hot-plug-events");
- if (np != NULL) {
- if (dlpar_workqueue_init() == 0)
- request_event_sources_irqs(np, ras_hotplug_interrupt,
- "RAS_HOTPLUG");
- of_node_put(np);
- }
-
/* EPOW Events */
np = of_find_node_by_path("/event-sources/epow-events");
if (np != NULL) {
Patches currently in stable-queue which might be from sam.bobroff(a)au1.ibm.com are
queue-4.14/powerpc-pseries-enable-ras-hotplug-events-later.patch
This is a note to let you know that I've just added the patch titled
MIPS: Implement __multi3 for GCC7 MIPS64r6 builds
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:
mips-implement-__multi3-for-gcc7-mips64r6-builds.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 ebabcf17bcd7ce968b1631ebe08236275698f39b Mon Sep 17 00:00:00 2001
From: James Hogan <jhogan(a)kernel.org>
Date: Thu, 7 Dec 2017 07:20:46 +0000
Subject: MIPS: Implement __multi3 for GCC7 MIPS64r6 builds
From: James Hogan <jhogan(a)kernel.org>
commit ebabcf17bcd7ce968b1631ebe08236275698f39b upstream.
GCC7 is a bit too eager to generate suboptimal __multi3 calls (128bit
multiply with 128bit result) for MIPS64r6 builds, even in code which
doesn't explicitly use 128bit types, such as the following:
unsigned long func(unsigned long a, unsigned long b)
{
return a > (~0UL) / b;
}
Which GCC rearanges to:
return (unsigned __int128)a * (unsigned __int128)b > 0xffffffffffffffff;
Therefore implement __multi3, but only for MIPS64r6 with GCC7 as under
normal circumstances we wouldn't expect any calls to __multi3 to be
generated from kernel code.
Reported-by: Thomas Petazzoni <thomas.petazzoni(a)free-electrons.com>
Signed-off-by: James Hogan <jhogan(a)kernel.org>
Tested-by: Waldemar Brodkorb <wbx(a)openadk.org>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Maciej W. Rozycki <macro(a)mips.com>
Cc: Matthew Fortune <matthew.fortune(a)mips.com>
Cc: Florian Fainelli <florian(a)openwrt.org>
Cc: linux-mips(a)linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17890/
Cc: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/mips/lib/Makefile | 3 +-
arch/mips/lib/libgcc.h | 17 +++++++++++++++
arch/mips/lib/multi3.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 73 insertions(+), 1 deletion(-)
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -16,4 +16,5 @@ obj-$(CONFIG_CPU_R3000) += r3k_dump_tlb
obj-$(CONFIG_CPU_TX39XX) += r3k_dump_tlb.o
# libgcc-style stuff needed in the kernel
-obj-y += ashldi3.o ashrdi3.o bswapsi.o bswapdi.o cmpdi2.o lshrdi3.o ucmpdi2.o
+obj-y += ashldi3.o ashrdi3.o bswapsi.o bswapdi.o cmpdi2.o lshrdi3.o multi3.o \
+ ucmpdi2.o
--- a/arch/mips/lib/libgcc.h
+++ b/arch/mips/lib/libgcc.h
@@ -10,10 +10,18 @@ typedef int word_type __attribute__ ((mo
struct DWstruct {
int high, low;
};
+
+struct TWstruct {
+ long long high, low;
+};
#elif defined(__LITTLE_ENDIAN)
struct DWstruct {
int low, high;
};
+
+struct TWstruct {
+ long long low, high;
+};
#else
#error I feel sick.
#endif
@@ -23,4 +31,13 @@ typedef union {
long long ll;
} DWunion;
+#if defined(CONFIG_64BIT) && defined(CONFIG_CPU_MIPSR6)
+typedef int ti_type __attribute__((mode(TI)));
+
+typedef union {
+ struct TWstruct s;
+ ti_type ti;
+} TWunion;
+#endif
+
#endif /* __ASM_LIBGCC_H */
--- /dev/null
+++ b/arch/mips/lib/multi3.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/export.h>
+
+#include "libgcc.h"
+
+/*
+ * GCC 7 suboptimally generates __multi3 calls for mips64r6, so for that
+ * specific case only we'll implement it here.
+ *
+ * See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82981
+ */
+#if defined(CONFIG_64BIT) && defined(CONFIG_CPU_MIPSR6) && (__GNUC__ == 7)
+
+/* multiply 64-bit values, low 64-bits returned */
+static inline long long notrace dmulu(long long a, long long b)
+{
+ long long res;
+
+ asm ("dmulu %0,%1,%2" : "=r" (res) : "r" (a), "r" (b));
+ return res;
+}
+
+/* multiply 64-bit unsigned values, high 64-bits of 128-bit result returned */
+static inline long long notrace dmuhu(long long a, long long b)
+{
+ long long res;
+
+ asm ("dmuhu %0,%1,%2" : "=r" (res) : "r" (a), "r" (b));
+ return res;
+}
+
+/* multiply 128-bit values, low 128-bits returned */
+ti_type notrace __multi3(ti_type a, ti_type b)
+{
+ TWunion res, aa, bb;
+
+ aa.ti = a;
+ bb.ti = b;
+
+ /*
+ * a * b = (a.lo * b.lo)
+ * + 2^64 * (a.hi * b.lo + a.lo * b.hi)
+ * [+ 2^128 * (a.hi * b.hi)]
+ */
+ res.s.low = dmulu(aa.s.low, bb.s.low);
+ res.s.high = dmuhu(aa.s.low, bb.s.low);
+ res.s.high += dmulu(aa.s.high, bb.s.low);
+ res.s.high += dmulu(aa.s.low, bb.s.high);
+
+ return res.ti;
+}
+EXPORT_SYMBOL(__multi3);
+
+#endif /* 64BIT && CPU_MIPSR6 && GCC7 */
Patches currently in stable-queue which might be from jhogan(a)kernel.org are
queue-4.14/lib-mpi-fix-umul_ppmm-for-mips64r6.patch
queue-4.14/mips-implement-__multi3-for-gcc7-mips64r6-builds.patch
Hi Greg,
please apply commit ebabcf17bcd7 ("MIPS: Implement __multi3 for GCC7 MIPS64r6 builds")
to linux-4.4.y .. linux-4.14.y to fix the following build problem, seen when building
mipsr6 images with gcc 7.3.0.
crypto/scompress.o: In function `kmalloc_array':
include/linux/slab.h:603: undefined reference to `__multi3'
Thanks,
Guenter
On Mon, Feb 26, 2018 at 4:22 AM, Jerry Hoemann <jerry.hoemann(a)hpe.com> wrote:
> Gen8 and prior Proliant systems supported the "CRU" interface
> to firmware. This interfaces allows linux to "call back" into firmware
> to source the cause of an NMI. This feature isn't fully utilized
> as the actual source of the NMI isn't printed, the driver only
> indicates that the source couldn't be determined when the call
> fails.
>
> With the advent of Gen9, iCRU replaces the CRU. The call back
> feature is no longer available in firmware. To be compatible and
> not attempt to call back into firmware on system not supporting CRU,
> the SMBIOS table is consulted to determine if it is safe to
> make the call back or not.
>
> This results in about half of the driver code being devoted
> to either making CRU calls or determing if it is safe to make
> CRU calls. As noted, the driver isn't really using the results of
> the CRU calls.
>
> Furthermore, as a consequence of the Spectre security issue, the
> BIOS/EFI calls are being wrapped into Spectre-disabling section.
> Removing the call back in hpwdt_pretimeout assists in this effort.
>
> As the CRU sourcing of the NMI isn't required for handling the
> NMI and there are security concerns with making the call back, remove
> the legacy (pre Gen9) NMI sourcing and the DMI code to determine if
> the system had the CRU interface.
>
> Signed-off-by: Jerry Hoemann <jerry.hoemann(a)hpe.com>
This avoids a warning in mainline kernels, so that's great:
drivers/watchdog/hpwdt.o: warning: objtool: .text+0x24: indirect call
found in RETPOLINE build
I wonder what we do about stable kernels. Are both this patch and the patch
that added the objtool warning message candidates for backports to
stable kernels?
Arnd
From: Leif Liddy <leif.linux(a)gmail.com>
This patch has been added to the 4.1 stable tree. If you have any
objections, please let us know.
===============
[ Upstream commit fd865802c66bc451dc515ed89360f84376ce1a56 ]
There's been numerous reported instances where BTUSB_QCA_ROME
bluetooth controllers stop functioning upon resume from suspend. These
devices seem to be losing power during suspend. Patch will detect a status
change on resume and perform a reset.
Signed-off-by: Leif Liddy <leif.linux(a)gmail.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
---
drivers/bluetooth/btusb.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 32f5b87fe93c..b17bd3fc74cb 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3207,6 +3207,12 @@ static int btusb_probe(struct usb_interface *intf,
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.
+ */
+ set_bit(BTUSB_RESET_RESUME, &data->flags);
}
if (id->driver_info & BTUSB_REALTEK)
--
2.14.1
The patch titled
Subject: lib/bug.c: exclude non-BUG/WARN exceptions from report_bug()
has been added to the -mm tree. Its filename is
bug-exclude-non-bug-warn-exceptions-from-report_bug.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/bug-exclude-non-bug-warn-exception…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/bug-exclude-non-bug-warn-exception…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Kees Cook <keescook(a)chromium.org>
Subject: lib/bug.c: exclude non-BUG/WARN exceptions from report_bug()
b8347c219649 ("x86/debug: Handle warnings before the notifier chain, to
fix KGDB crash") changed the ordering of fixups, and did not take into
account the case of x86 processing non-WARN() and non-BUG() exceptions.
This would lead to output of a false BUG line with no other information.
In the case of a refcount exception, it would be immediately followed by
the refcount WARN(), producing very strange double-"cut here":
lkdtm: attempting bad refcount_inc() overflow
------------[ cut here ]------------
Kernel BUG at 0000000065f29de5 [verbose debug info unavailable]
------------[ cut here ]------------
refcount_t overflow at lkdtm_REFCOUNT_INC_OVERFLOW+0x6b/0x90 in cat[3065], uid/euid: 0/0
WARNING: CPU: 0 PID: 3065 at kernel/panic.c:657 refcount_error_report+0x9a/0xa4
...
In the prior ordering, exceptions were searched first:
do_trap_no_signal(struct task_struct *tsk, int trapnr, char *str,
...
if (fixup_exception(regs, trapnr))
return 0;
- if (fixup_bug(regs, trapnr))
- return 0;
-
As a result, fixup_bugs()'s is_valid_bugaddr() didn't take into account
needing to search the exception list first, since that had already
happened.
So, instead of searching the exception list twice (once in
is_valid_bugaddr() and then again in fixup_exception()), just add a simple
sanity check to report_bug() that will immediately bail out if a BUG() (or
WARN()) entry is not found.
Link: http://lkml.kernel.org/r/20180301225934.GA34350@beast
Fixes: b8347c219649 ("x86/debug: Handle warnings before the notifier chain, to fix KGDB crash")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Richard Weinberger <richard.weinberger(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
lib/bug.c | 2 ++
1 file changed, 2 insertions(+)
diff -puN lib/bug.c~bug-exclude-non-bug-warn-exceptions-from-report_bug lib/bug.c
--- a/lib/bug.c~bug-exclude-non-bug-warn-exceptions-from-report_bug
+++ a/lib/bug.c
@@ -150,6 +150,8 @@ enum bug_trap_type report_bug(unsigned l
return BUG_TRAP_TYPE_NONE;
bug = find_bug(bugaddr);
+ if (!bug)
+ return BUG_TRAP_TYPE_NONE;
file = NULL;
line = 0;
_
Patches currently in -mm which might be from keescook(a)chromium.org are
bug-use-%pb-in-bug-and-stack-protector-failure.patch
bug-exclude-non-bug-warn-exceptions-from-report_bug.patch
taint-convert-to-indexed-initialization.patch
taint-consolidate-documentation.patch
taint-add-taint-for-randstruct.patch
fork-unconditionally-clear-stack-on-fork.patch
exec-pass-stack-rlimit-into-mm-layout-functions.patch
exec-introduce-finalize_exec-before-start_thread.patch
exec-pin-stack-limit-during-exec.patch
The patch titled
Subject: bug: use %pB in BUG and stack protector failure
has been added to the -mm tree. Its filename is
bug-use-%pb-in-bug-and-stack-protector-failure.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/bug-use-%25pb-in-bug-and-stack-pro…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/bug-use-%25pb-in-bug-and-stack-pro…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Kees Cook <keescook(a)chromium.org>
Subject: bug: use %pB in BUG and stack protector failure
The BUG and stack protector reports were still using a raw %p. This
changes it to %pB for more meaningful output.
Link: http://lkml.kernel.org/r/20180301225704.GA34198@beast
Fixes: ad67b74d2469 ("printk: hash addresses printed with %p")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Borislav Petkov <bp(a)alien8.de>
Cc: Richard Weinberger <richard.weinberger(a)gmail.com>,
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
kernel/panic.c | 2 +-
lib/bug.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -puN kernel/panic.c~bug-use-%pb-in-bug-and-stack-protector-failure kernel/panic.c
--- a/kernel/panic.c~bug-use-%pb-in-bug-and-stack-protector-failure
+++ a/kernel/panic.c
@@ -629,7 +629,7 @@ device_initcall(register_warn_debugfs);
*/
__visible void __stack_chk_fail(void)
{
- panic("stack-protector: Kernel stack is corrupted in: %p\n",
+ panic("stack-protector: Kernel stack is corrupted in: %pB\n",
__builtin_return_address(0));
}
EXPORT_SYMBOL(__stack_chk_fail);
diff -puN lib/bug.c~bug-use-%pb-in-bug-and-stack-protector-failure lib/bug.c
--- a/lib/bug.c~bug-use-%pb-in-bug-and-stack-protector-failure
+++ a/lib/bug.c
@@ -191,7 +191,7 @@ enum bug_trap_type report_bug(unsigned l
if (file)
pr_crit("kernel BUG at %s:%u!\n", file, line);
else
- pr_crit("Kernel BUG at %p [verbose debug info unavailable]\n",
+ pr_crit("Kernel BUG at %pB [verbose debug info unavailable]\n",
(void *)bugaddr);
return BUG_TRAP_TYPE_BUG;
_
Patches currently in -mm which might be from keescook(a)chromium.org are
bug-use-%pb-in-bug-and-stack-protector-failure.patch
taint-convert-to-indexed-initialization.patch
taint-consolidate-documentation.patch
taint-add-taint-for-randstruct.patch
fork-unconditionally-clear-stack-on-fork.patch
exec-pass-stack-rlimit-into-mm-layout-functions.patch
exec-introduce-finalize_exec-before-start_thread.patch
exec-pin-stack-limit-during-exec.patch
The patch titled
Subject: vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems
has been removed from the -mm tree. Its filename was
vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Michal Hocko <mhocko(a)suse.com>
Subject: vmalloc: fix __GFP_HIGHMEM usage for vmalloc_32 on 32b systems
Kai Heng Feng has noticed that BUG_ON(PageHighMem(pg)) triggers in
drivers/media/common/saa7146/saa7146_core.c since 19809c2da28a ("mm,
vmalloc: use __GFP_HIGHMEM implicitly"). saa7146_vmalloc_build_pgtable
uses vmalloc_32 and it is reasonable to expect that the resulting page is
not in highmem. The above commit aimed to add __GFP_HIGHMEM only for
those requests which do not specify any zone modifier gfp flag.
vmalloc_32 relies on GFP_VMALLOC32 which should do the right thing.
Except it has been missed that GFP_VMALLOC32 is an alias for GFP_KERNEL on
32b architectures. Thanks to Matthew to notice this.
Fix the problem by unconditionally setting GFP_DMA32 in GFP_VMALLOC32 for
!64b arches (as a bailout). This should do the right thing and use
ZONE_NORMAL which should be always below 4G on 32b systems.
Debugged by Matthew Wilcox.
[akpm(a)linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20180212095019.GX21609@dhcp22.suse.cz
Fixes: 19809c2da28a ("mm, vmalloc: use __GFP_HIGHMEM implicitly”)
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
Reported-by: Kai Heng Feng <kai.heng.feng(a)canonical.com>
Cc: Matthew Wilcox <willy(a)infradead.org>
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/vmalloc.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff -puN mm/vmalloc.c~vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems mm/vmalloc.c
--- a/mm/vmalloc.c~vmalloc-fix-__gfp_highmem-usage-for-vmalloc_32-on-32b-systems
+++ a/mm/vmalloc.c
@@ -1943,11 +1943,15 @@ void *vmalloc_exec(unsigned long size)
}
#if defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA32)
-#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
+#define GFP_VMALLOC32 (GFP_DMA32 | GFP_KERNEL)
#elif defined(CONFIG_64BIT) && defined(CONFIG_ZONE_DMA)
-#define GFP_VMALLOC32 GFP_DMA | GFP_KERNEL
+#define GFP_VMALLOC32 (GFP_DMA | GFP_KERNEL)
#else
-#define GFP_VMALLOC32 GFP_KERNEL
+/*
+ * 64b systems should always have either DMA or DMA32 zones. For others
+ * GFP_DMA32 should do the right thing and use the normal zone.
+ */
+#define GFP_VMALLOC32 GFP_DMA32 | GFP_KERNEL
#endif
/**
_
Patches currently in -mm which might be from mhocko(a)suse.com are
hugetlb-fix-surplus-pages-accounting.patch
mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2.patch
mm-numa-rework-do_pages_move.patch
mm-migrate-remove-reason-argument-from-new_page_t.patch
mm-unclutter-thp-migration.patch
mm-introduce-map_fixed_safe.patch
fs-elf-drop-map_fixed-usage-from-elf_map.patch
elf-enforce-map_fixed-on-overlaying-elf-segments.patch
The patch titled
Subject: mm, swap, frontswap: fix THP swap if frontswap enabled
has been removed from the -mm tree. Its filename was
mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Huang Ying <huang.ying.caritas(a)gmail.com>
Subject: mm, swap, frontswap: fix THP swap if frontswap enabled
It was reported by Sergey Senozhatsky that if THP (Transparent Huge Page)
and frontswap (via zswap) are both enabled, when memory goes low so that
swap is triggered, segfault and memory corruption will occur in random
user space applications as follow,
kernel: urxvt[338]: segfault at 20 ip 00007fc08889ae0d sp 00007ffc73a7fc40 error 6 in libc-2.26.so[7fc08881a000+1ae000]
#0 0x00007fc08889ae0d _int_malloc (libc.so.6)
#1 0x00007fc08889c2f3 malloc (libc.so.6)
#2 0x0000560e6004bff7 _Z14rxvt_wcstoutf8PKwi (urxvt)
#3 0x0000560e6005e75c n/a (urxvt)
#4 0x0000560e6007d9f1 _ZN16rxvt_perl_interp6invokeEP9rxvt_term9hook_typez (urxvt)
#5 0x0000560e6003d988 _ZN9rxvt_term9cmd_parseEv (urxvt)
#6 0x0000560e60042804 _ZN9rxvt_term6pty_cbERN2ev2ioEi (urxvt)
#7 0x0000560e6005c10f _Z17ev_invoke_pendingv (urxvt)
#8 0x0000560e6005cb55 ev_run (urxvt)
#9 0x0000560e6003b9b9 main (urxvt)
#10 0x00007fc08883af4a __libc_start_main (libc.so.6)
#11 0x0000560e6003f9da _start (urxvt)
After bisection, it was found the first bad commit is bd4c82c22c367e068
("mm, THP, swap: delay splitting THP after swapped out").
The root cause is as follows:
When the pages are written to swap device during swapping out in
swap_writepage(), zswap (fontswap) is tried to compress the pages to
improve performance. But zswap (frontswap) will treat THP as a normal
page, so only the head page is saved. After swapping in, tail pages will
not be restored to their original contents, causing memory corruption in
the applications.
This is fixed by refusing to save page in the frontswap store functions if
the page is a THP. So that the THP will be swapped out to swap device.
Another choice is to split THP if frontswap is enabled. But it is found
that the frontswap enabling isn't flexible. For example, if
CONFIG_ZSWAP=y (cannot be module), frontswap will be enabled even if zswap
itself isn't enabled.
Frontswap has multiple backends, to make it easy for one backend to enable
THP support, the THP checking is put in backend frontswap store functions
instead of the general interfaces.
Link: http://lkml.kernel.org/r/20180209084947.22749-1-ying.huang@intel.com
Fixes: bd4c82c22c367e068 ("mm, THP, swap: delay splitting THP after swapped out")
Signed-off-by: "Huang, Ying" <ying.huang(a)intel.com>
Reported-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Tested-by: Sergey Senozhatsky <sergey.senozhatsky(a)gmail.com>
Suggested-by: Minchan Kim <minchan(a)kernel.org> [put THP checking in backend]
Cc: Konrad Rzeszutek Wilk <konrad.wilk(a)oracle.com>
Cc: Dan Streetman <ddstreet(a)ieee.org>
Cc: Seth Jennings <sjenning(a)redhat.com>
Cc: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Cc: Shaohua Li <shli(a)kernel.org>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Johannes Weiner <hannes(a)cmpxchg.org>
Cc: Mel Gorman <mgorman(a)techsingularity.net>
Cc: Shakeel Butt <shakeelb(a)google.com>
Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: Juergen Gross <jgross(a)suse.com>
Cc: <stable(a)vger.kernel.org> [4.14]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
drivers/xen/tmem.c | 4 ++++
mm/zswap.c | 6 ++++++
2 files changed, 10 insertions(+)
diff -puN drivers/xen/tmem.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3 drivers/xen/tmem.c
--- a/drivers/xen/tmem.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3
+++ a/drivers/xen/tmem.c
@@ -284,6 +284,10 @@ static int tmem_frontswap_store(unsigned
int pool = tmem_frontswap_poolid;
int ret;
+ /* THP isn't supported */
+ if (PageTransHuge(page))
+ return -1;
+
if (pool < 0)
return -1;
if (ind64 != ind)
diff -puN mm/zswap.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3 mm/zswap.c
--- a/mm/zswap.c~mm-swap-frontswap-fix-thp-swap-if-frontswap-enabled-v3
+++ a/mm/zswap.c
@@ -1007,6 +1007,12 @@ static int zswap_frontswap_store(unsigne
u8 *src, *dst;
struct zswap_header zhdr = { .swpentry = swp_entry(type, offset) };
+ /* THP isn't supported */
+ if (PageTransHuge(page)) {
+ ret = -EINVAL;
+ goto reject;
+ }
+
if (!zswap_enabled || !tree) {
ret = -ENODEV;
goto reject;
_
Patches currently in -mm which might be from huang.ying.caritas(a)gmail.com are
The patch titled
Subject: Kbuild: always define endianess in kconfig.h
has been removed from the -mm tree. Its filename was
kbuild-always-define-endianess-in-kconfigh.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: Arnd Bergmann <arnd(a)arndb.de>
Subject: Kbuild: always define endianess in kconfig.h
Build testing with LTO found a couple of files that get compiled
differently depending on whether asm/byteorder.h gets included early
enough or not. In particular, include/asm-generic/qrwlock_types.h is
affected by this, but there are probably others as well.
The symptom is a series of LTO link time warnings, including these:
net/netlabel/netlabel_unlabeled.h:223: error: type of 'netlbl_unlhsh_add' does not match original declaration [-Werror=lto-type-mismatch]
int netlbl_unlhsh_add(struct net *net,
net/netlabel/netlabel_unlabeled.c:377: note: 'netlbl_unlhsh_add' was previously declared here
include/net/ipv6.h:360: error: type of 'ipv6_renew_options_kern' does not match original declaration [-Werror=lto-type-mismatch]
ipv6_renew_options_kern(struct sock *sk,
net/ipv6/exthdrs.c:1162: note: 'ipv6_renew_options_kern' was previously declared here
net/core/dev.c:761: note: 'dev_get_by_name_rcu' was previously declared here
struct net_device *dev_get_by_name_rcu(struct net *net, const char *name)
net/core/dev.c:761: note: code may be misoptimized unless -fno-strict-aliasing is used
drivers/gpu/drm/i915/i915_drv.h:3377: error: type of 'i915_gem_object_set_to_wc_domain' does not match original declaration [-Werror=lto-type-mismatch]
i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write);
drivers/gpu/drm/i915/i915_gem.c:3639: note: 'i915_gem_object_set_to_wc_domain' was previously declared here
include/linux/debugfs.h:92:9: error: type of 'debugfs_attr_read' does not match original declaration [-Werror=lto-type-mismatch]
ssize_t debugfs_attr_read(struct file *file, char __user *buf,
fs/debugfs/file.c:318: note: 'debugfs_attr_read' was previously declared here
include/linux/rwlock_api_smp.h:30: error: type of '_raw_read_unlock' does not match original declaration [-Werror=lto-type-mismatch]
void __lockfunc _raw_read_unlock(rwlock_t *lock) __releases(lock);
kernel/locking/spinlock.c:246:26: note: '_raw_read_unlock' was previously declared here
include/linux/fs.h:3308:5: error: type of 'simple_attr_open' does not match original declaration [-Werror=lto-type-mismatch]
int simple_attr_open(struct inode *inode, struct file *file,
fs/libfs.c:795: note: 'simple_attr_open' was previously declared here
All of the above are caused by include/asm-generic/qrwlock_types.h failing
to include asm/byteorder.h after commit e0d02285f16e ("locking/qrwlock:
Use 'struct qrwlock' instead of 'struct __qrwlock'") in linux-4.15.
Similar bugs may or may not exist in older kernels as well, but there is
no easy way to test those with link-time optimizations, and kernels before
4.14 are harder to fix because they don't have Babu's patch series
We had similar issues with CONFIG_ symbols in the past and ended up always
including the configuration headers though linux/kconfig.h. This works
around the issue through that same file, defining either __BIG_ENDIAN or
__LITTLE_ENDIAN depending on CONFIG_CPU_BIG_ENDIAN, which is now always
set on all architectures since commit 4c97a0c8fee3 ("arch: define
CPU_BIG_ENDIAN for all fixed big endian archs").
Link: http://lkml.kernel.org/r/20180202154104.1522809-2-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Cc: Babu Moger <babu.moger(a)amd.com>
Cc: Andi Kleen <ak(a)linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: Masahiro Yamada <yamada.masahiro(a)socionext.com>
Cc: Nicolas Pitre <nico(a)linaro.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/kconfig.h | 6 ++++++
1 file changed, 6 insertions(+)
diff -puN include/linux/kconfig.h~kbuild-always-define-endianess-in-kconfigh include/linux/kconfig.h
--- a/include/linux/kconfig.h~kbuild-always-define-endianess-in-kconfigh
+++ a/include/linux/kconfig.h
@@ -4,6 +4,12 @@
#include <generated/autoconf.h>
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#define __BIG_ENDIAN 4321
+#else
+#define __LITTLE_ENDIAN 1234
+#endif
+
#define __ARG_PLACEHOLDER_1 0,
#define __take_second_arg(__ignored, val, ...) val
_
Patches currently in -mm which might be from arnd(a)arndb.de are
From: Leif Liddy <leif.linux(a)gmail.com>
This patch has been added to the stable tree. If you have any
objections, please let us know.
===============
[ Upstream commit fd865802c66bc451dc515ed89360f84376ce1a56 ]
There's been numerous reported instances where BTUSB_QCA_ROME
bluetooth controllers stop functioning upon resume from suspend. These
devices seem to be losing power during suspend. Patch will detect a status
change on resume and perform a reset.
Signed-off-by: Leif Liddy <leif.linux(a)gmail.com>
Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
---
drivers/bluetooth/btusb.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 32f5b87fe93c..b17bd3fc74cb 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3207,6 +3207,12 @@ static int btusb_probe(struct usb_interface *intf,
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.
+ */
+ set_bit(BTUSB_RESET_RESUME, &data->flags);
}
if (id->driver_info & BTUSB_REALTEK)
--
2.14.1
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 ee70bc1e7b63ac8023c9ff9475d8741e397316e7 Mon Sep 17 00:00:00 2001
From: Alexander Steffen <Alexander.Steffen(a)infineon.com>
Date: Fri, 8 Sep 2017 17:21:32 +0200
Subject: [PATCH] tpm-dev-common: Reject too short writes
tpm_transmit() does not offer an explicit interface to indicate the number
of valid bytes in the communication buffer. Instead, it relies on the
commandSize field in the TPM header that is encoded within the buffer.
Therefore, ensure that a) enough data has been written to the buffer, so
that the commandSize field is present and b) the commandSize field does not
announce more data than has been written to the buffer.
This should have been fixed with CVE-2011-1161 long ago, but apparently
a correct version of that patch never made it into the kernel.
Cc: stable(a)vger.kernel.org
Signed-off-by: Alexander Steffen <Alexander.Steffen(a)infineon.com>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
diff --git a/drivers/char/tpm/tpm-dev-common.c b/drivers/char/tpm/tpm-dev-common.c
index 610638a80383..461bf0b8a094 100644
--- a/drivers/char/tpm/tpm-dev-common.c
+++ b/drivers/char/tpm/tpm-dev-common.c
@@ -110,6 +110,12 @@ ssize_t tpm_common_write(struct file *file, const char __user *buf,
return -EFAULT;
}
+ if (in_size < 6 ||
+ in_size < be32_to_cpu(*((__be32 *) (priv->data_buffer + 2)))) {
+ mutex_unlock(&priv->buffer_mutex);
+ return -EINVAL;
+ }
+
/* atomic tpm command send and result receive. We only hold the ops
* lock during this period so that the tpm can be unregistered even if
* the char dev is held open.
We're seeing on CI that some contexts don't have the programmed OA
period timer that directs the OA unit on how often to write reports.
The issue is that we're not holding the drm lock from when we edit the
context images down to when we set the exclusive_stream variable. This
leaves a window for the deferred context allocation to call
i915_oa_init_reg_state() that will not program the expected OA timer
value, because we haven't set the exclusive_stream yet.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin(a)intel.com>
Fixes: 701f8231a2f ("drm/i915/perf: prune OA configs")
Cc: <stable(a)vger.kernel.org> # v4.14+
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102254
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103715
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103755
---
drivers/gpu/drm/i915/i915_perf.c | 41 +++++++++++++++++++---------------------
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2741b1bc7095..7016abfc8ba9 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1757,21 +1757,16 @@ static int gen8_switch_to_updated_kernel_context(struct drm_i915_private *dev_pr
*/
static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv,
const struct i915_oa_config *oa_config,
- bool interruptible)
+ bool need_lock)
{
struct i915_gem_context *ctx;
int ret;
unsigned int wait_flags = I915_WAIT_LOCKED;
- if (interruptible) {
- ret = i915_mutex_lock_interruptible(&dev_priv->drm);
- if (ret)
- return ret;
-
- wait_flags |= I915_WAIT_INTERRUPTIBLE;
- } else {
+ if (need_lock)
mutex_lock(&dev_priv->drm.struct_mutex);
- }
+
+ lockdep_assert_held(&dev_priv->drm.struct_mutex);
/* Switch away from any user context. */
ret = gen8_switch_to_updated_kernel_context(dev_priv, oa_config);
@@ -1819,7 +1814,8 @@ static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv,
}
out:
- mutex_unlock(&dev_priv->drm.struct_mutex);
+ if (need_lock)
+ mutex_unlock(&dev_priv->drm.struct_mutex);
return ret;
}
@@ -1863,7 +1859,7 @@ static int gen8_enable_metric_set(struct drm_i915_private *dev_priv,
* to make sure all slices/subslices are ON before writing to NOA
* registers.
*/
- ret = gen8_configure_all_contexts(dev_priv, oa_config, true);
+ ret = gen8_configure_all_contexts(dev_priv, oa_config, false);
if (ret)
return ret;
@@ -1878,7 +1874,7 @@ static int gen8_enable_metric_set(struct drm_i915_private *dev_priv,
static void gen8_disable_metric_set(struct drm_i915_private *dev_priv)
{
/* Reset all contexts' slices/subslices configurations. */
- gen8_configure_all_contexts(dev_priv, NULL, false);
+ gen8_configure_all_contexts(dev_priv, NULL, true);
I915_WRITE(GDT_CHICKEN_BITS, (I915_READ(GDT_CHICKEN_BITS) &
~GT_NOA_ENABLE));
@@ -1888,7 +1884,7 @@ static void gen8_disable_metric_set(struct drm_i915_private *dev_priv)
static void gen10_disable_metric_set(struct drm_i915_private *dev_priv)
{
/* Reset all contexts' slices/subslices configurations. */
- gen8_configure_all_contexts(dev_priv, NULL, false);
+ gen8_configure_all_contexts(dev_priv, NULL, true);
/* Make sure we disable noa to save power. */
I915_WRITE(RPM_CONFIG1,
@@ -2138,13 +2134,6 @@ static int i915_oa_stream_init(struct i915_perf_stream *stream,
if (ret)
goto err_oa_buf_alloc;
- ret = dev_priv->perf.oa.ops.enable_metric_set(dev_priv,
- stream->oa_config);
- if (ret)
- goto err_enable;
-
- stream->ops = &i915_oa_stream_ops;
-
/* Lock device for exclusive_stream access late because
* enable_metric_set() might lock as well on gen8+.
*/
@@ -2152,16 +2141,24 @@ static int i915_oa_stream_init(struct i915_perf_stream *stream,
if (ret)
goto err_lock;
+ ret = dev_priv->perf.oa.ops.enable_metric_set(dev_priv,
+ stream->oa_config);
+ if (ret)
+ goto err_enable;
+
+ stream->ops = &i915_oa_stream_ops;
+
dev_priv->perf.oa.exclusive_stream = stream;
mutex_unlock(&dev_priv->drm.struct_mutex);
return 0;
-err_lock:
+err_enable:
+ mutex_unlock(&dev_priv->drm.struct_mutex);
dev_priv->perf.oa.ops.disable_metric_set(dev_priv);
-err_enable:
+err_lock:
free_oa_buffer(dev_priv);
err_oa_buf_alloc:
--
2.16.1
Commit 55a9c95d70ab ("Bluetooth: btusb: Use DMI matching for QCA
reset_resume quirking"), added the Lenovo Yoga 920 to the
btusb_needs_reset_resume_table.
Testing has shown that this is a false positive and the problems where
caused by issues with the initial fix: commit fd865802c66b ("Bluetooth:
btusb: fix QCA Rome suspend/resume"), which has already been reverted.
So the QCA Rome BT in the Yoga 920 does not need a reset-resume quirk at
all and this commit removes it from the btusb_needs_reset_resume_table.
Note that after this commit the btusb_needs_reset_resume_table is now
empty. It is kept around on purpose, since this whole series of commits
started for a reason and there are actually broken platforms around,
which need to be added to it.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1514836
Fixes: 55a9c95d70ab ("Bluetooth: btusb: Use DMI matching for QCA ...")
Cc: stable(a)vger.kernel.org
Cc: Brian Norris <briannorris(a)chromium.org>
Cc: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Tested-by: Kevin Fenzi <kevin(a)scrye.com>
Suggested-by: Brian Norris <briannorris(a)chromium.org>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
---
drivers/bluetooth/btusb.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index a4b62f0a93cc..418550eb1522 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -386,13 +386,6 @@ static const struct usb_device_id blacklist_table[] = {
* the module itself. So we use a DMI list to match known broken platforms.
*/
static const struct dmi_system_id btusb_needs_reset_resume_table[] = {
- {
- /* Lenovo Yoga 920 (QCA Rome device 0cf3:e300) */
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
- DMI_MATCH(DMI_PRODUCT_VERSION, "Lenovo YOGA 920"),
- },
- },
{}
};
--
2.14.3
For some 32-bit architectures calculation of DTO and STO timeout can be incorrect
due to multiply overflow. Lets prevent this by casting multiply and result to u64.
Suggested by Jisheng Zhang.
Switch DIV_ROUND_UP macro to DIV_ROUND_UP_ULL is not reasonable
because overflow happens on multiply and DIV_ROUND_UP_ULL helps
with sum overflow.
---
Changes since v2:
-add fix for cto_ms
Evgeniy Didin (2):
mmc: dw_mmc: Fix the DTO timeout overflow calculation for 32-bit
systems
mmc: dw_mmc: Fix the CTO overflow calculation for 32-bit systems
drivers/mmc/host/dw_mmc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--
2.11.0
Commit 45ee9d5e97a4 ("KVM: arm/arm64: Check pagesize when allocating a
hugepage at Stage 2") lost the check for PMD_SIZE during the backport
to 4.9.
Fix this by correcting the condition to detect hugepages during stage
2 allocation.
Fixes: 45ee9d5e97a4 ("KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2")
Reported-by: Ioana Ciornei <ioana.ciornei(a)nxp.com>
Signed-off-by: Punit Agrawal <punit.agrawal(a)arm.com>
Cc: Marc Zyngier <marc.zyngier(a)arm.com>
Cc: Christoffer Dall <christoffer.dall(a)linaro.org>
--
Hi Greg,
This patch fixes a commit in the stable tree that was backported from
upstream. I am not sure what the tag convention is for such a commit -
so sending as a fix.
Thanks,
Punit
---
arch/arm/kvm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 2a35c1963f6d..7f868d9bb5ed 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1284,7 +1284,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
return -EFAULT;
}
- if (vma_kernel_pagesize(vma) && !logging_active) {
+ if (vma_kernel_pagesize(vma) == PMD_SIZE && !logging_active) {
hugetlb = true;
gfn = (fault_ipa & PMD_MASK) >> PAGE_SHIFT;
} else {
--
2.16.1
This is the start of the stable review cycle for the 4.9.79 release.
There are 66 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed Jan 31 12:38:12 UTC 2018.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.79-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.9.79-rc1
Daniel Borkmann <daniel(a)iogearbox.net>
bpf: reject stores into ctx via st and xadd
Alexei Starovoitov <ast(a)kernel.org>
bpf: fix 32-bit divide by zero
Eric Dumazet <edumazet(a)google.com>
bpf: fix divides by zero
Daniel Borkmann <daniel(a)iogearbox.net>
bpf: avoid false sharing of map refcount with max_entries
Daniel Borkmann <daniel(a)iogearbox.net>
bpf: arsh is not supported in 32 bit alu thus reject it
Alexei Starovoitov <ast(a)kernel.org>
bpf: introduce BPF_JIT_ALWAYS_ON config
Alexei Starovoitov <ast(a)fb.com>
bpf: fix bpf_tail_call() x64 JIT
Eric Dumazet <edumazet(a)google.com>
x86: bpf_jit: small optimization in emit_bpf_tail_call()
Thomas Gleixner <tglx(a)linutronix.de>
hrtimer: Reset hrtimer cpu base proper on CPU hotplug
Jia Zhang <zhang.jia(a)linux.alibaba.com>
x86/microcode/intel: Extend BDW late-loading further with LLC size check
Xiao Liang <xiliang(a)redhat.com>
perf/x86/amd/power: Do not load AMD power module on !AMD platforms
Eric Dumazet <edumazet(a)google.com>
flow_dissector: properly cap thoff field
Cong Wang <xiyou.wangcong(a)gmail.com>
tun: fix a memory leak for tfile->tx_array
Yuval Mintz <yuvalm(a)mellanox.com>
mlxsw: spectrum_router: Don't log an error on missing neighbor
Willem de Bruijn <willemb(a)google.com>
gso: validate gso_type in GSO handlers
Alexey Kodanev <alexey.kodanev(a)oracle.com>
ip6_gre: init dev->mtu and dev->hard_header_len correctly
Ivan Vecera <cera(a)cera.cz>
be2net: restore properly promisc mode after queues reconfiguration
Guillaume Nault <g.nault(a)alphalink.fr>
ppp: unlock all_ppp_mutex before registering device
Jim Westfall <jwestfall(a)surrealistic.net>
ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY
Jim Westfall <jwestfall(a)surrealistic.net>
net: Allow neigh contructor functions ability to modify the primary_key
Neil Horman <nhorman(a)tuxdriver.com>
vmxnet3: repair memory leak
Cong Wang <xiyou.wangcong(a)gmail.com>
tipc: fix a memory leak in tipc_nl_node_get_link()
Xin Long <lucien.xin(a)gmail.com>
sctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf
Xin Long <lucien.xin(a)gmail.com>
sctp: do not allow the v4 socket to bind a v4mapped v6 address
Francois Romieu <romieu(a)fr.zoreil.com>
r8169: fix memory corruption on retrieval of hardware statistics.
Guillaume Nault <g.nault(a)alphalink.fr>
pppoe: take ->needed_headroom of lower device into account on xmit
Dan Streetman <ddstreet(a)ieee.org>
net: tcp: close sock if net namespace is exiting
Eric Dumazet <edumazet(a)google.com>
net: qdisc_pkt_len_init() should be more robust
Felix Fietkau <nbd(a)nbd.name>
net: igmp: fix source address check for IGMPv3 reports
Yuiko Oshino <yuiko.oshino(a)microchip.com>
lan78xx: Fix failure in USB Full Speed
Eric Dumazet <edumazet(a)google.com>
ipv6: ip6_make_skb() needs to clear cork.base.dst
Mike Maloney <maloney(a)google.com>
ipv6: fix udpv6 sendmsg crash caused by too small MTU
Ben Hutchings <ben.hutchings(a)codethink.co.uk>
ipv6: Fix getsockopt() for sockets with default IPV6_AUTOFLOWLABEL
Alexey Kodanev <alexey.kodanev(a)oracle.com>
dccp: don't restart ccid2_hc_tx_rto_expire() if sk in closed state
Greg KH <gregkh(a)linuxfoundation.org>
eventpoll.h: add missing epoll event masks
Ben Hutchings <ben.hutchings(a)codethink.co.uk>
vsyscall: Fix permissions for emulate mode with KAISER/PTI
Thomas Meyer <thomas(a)m3y3r.de>
um: link vmlinux with -no-pie
Martin Brandenburg <martin(a)omnibond.com>
orangefs: fix deadlock; do not write i_size in read_iter
Aaron Ma <aaron.ma(a)canonical.com>
Input: trackpoint - force 3 buttons if 0 button is reported
Johannes Weiner <hannes(a)cmpxchg.org>
mm: fix 100% CPU kswapd busyloop on unreclaimable nodes
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Revert "module: Add retpoline tag to VERMAGIC"
Johannes Thumshirn <jthumshirn(a)suse.de>
scsi: libiscsi: fix shifting of DID_REQUEUE host byte
Jiri Slaby <jslaby(a)suse.cz>
fs/fcntl: f_setown, avoid undefined behaviour
Jeff Mahoney <jeffm(a)suse.com>
reiserfs: don't preallocate blocks for extended attributes
Jeff Mahoney <jeffm(a)suse.com>
reiserfs: fix race in prealloc discard
Kevin Cernekee <cernekee(a)chromium.org>
netfilter: xt_osf: Add missing permission checks
Kevin Cernekee <cernekee(a)chromium.org>
netfilter: nfnetlink_cthelper: Add missing permission checks
Seunghun Han <kkamagui(a)gmail.com>
ACPICA: Namespace: fix operand cache leak
Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
ACPI / scan: Prefer devices without _HID/_CID for _ADR matching
Jiri Slaby <jslaby(a)suse.cz>
ipc: msg, make msgrcv work with LONG_MIN
Vlastimil Babka <vbabka(a)suse.cz>
mm, page_alloc: fix potential false positive in __zone_watermark_ok
Doug Berger <opendmb(a)gmail.com>
cma: fix calculation of aligned offset
Michal Hocko <mhocko(a)suse.com>
hwpoison, memcg: forcibly uncharge LRU pages
Michal Hocko <mhocko(a)suse.com>
mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack
Sudeep Holla <sudeep.holla(a)arm.com>
drivers: base: cacheinfo: fix boot error message when acpi is enabled
Sudeep Holla <sudeep.holla(a)arm.com>
drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled
Janakarajan Natarajan <Janakarajan.Natarajan(a)amd.com>
Prevent timer value 0 for MWAITX
Punit Agrawal <punit.agrawal(a)arm.com>
KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2
Marc Kleine-Budde <mkl(a)pengutronix.de>
can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
Marc Kleine-Budde <mkl(a)pengutronix.de>
can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
Jonathan Dieter <jdieter(a)lesbg.com>
usbip: Fix potential format overflow in userspace tools
Jonathan Dieter <jdieter(a)lesbg.com>
usbip: Fix implicit fallthrough warning
Shuah Khan <shuah(a)kernel.org>
usbip: prevent vhci_hcd driver from leaking a socket pointer address
Martin Brandenburg <martin(a)omnibond.com>
orangefs: initialize op on loop restart in orangefs_devreq_read
Martin Brandenburg <martin(a)omnibond.com>
orangefs: use list_for_each_entry_safe in purge_waiting_ops
Andy Lutomirski <luto(a)kernel.org>
x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
-------------
Diffstat:
Makefile | 4 +-
arch/arm/kvm/mmu.c | 2 +-
arch/um/Makefile | 2 +-
arch/x86/entry/vsyscall/vsyscall_64.c | 7 ++--
arch/x86/events/amd/power.c | 2 +-
arch/x86/include/asm/processor.h | 2 +-
arch/x86/include/asm/vsyscall.h | 1 +
arch/x86/kernel/cpu/intel_cacheinfo.c | 2 +
arch/x86/kernel/cpu/microcode/intel.c | 20 ++++++++-
arch/x86/lib/delay.c | 7 ++++
arch/x86/mm/kaiser.c | 2 +-
arch/x86/net/bpf_jit_comp.c | 13 +++---
drivers/acpi/acpica/nsutils.c | 23 +++++------
drivers/acpi/glue.c | 12 +++---
drivers/base/cacheinfo.c | 15 +++++--
drivers/input/mouse/trackpoint.c | 3 ++
drivers/net/ethernet/emulex/benet/be_main.c | 9 +++++
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 5 +--
drivers/net/ethernet/realtek/r8169.c | 9 +----
drivers/net/ppp/ppp_generic.c | 5 ++-
drivers/net/ppp/pppoe.c | 11 ++---
drivers/net/tun.c | 15 ++++++-
drivers/net/usb/lan78xx.c | 1 +
drivers/net/vmxnet3/vmxnet3_drv.c | 2 +-
drivers/scsi/libiscsi.c | 2 +-
drivers/usb/usbip/usbip_common.h | 1 +
drivers/usb/usbip/vhci_sysfs.c | 25 +++++++-----
fs/fcntl.c | 4 ++
fs/orangefs/devorangefs-req.c | 3 +-
fs/orangefs/file.c | 7 +---
fs/orangefs/orangefs-kernel.h | 11 -----
fs/orangefs/waitqueue.c | 4 +-
fs/reiserfs/bitmap.c | 14 +++++--
include/linux/bpf.h | 16 ++++++--
include/linux/cacheinfo.h | 1 +
include/linux/mmzone.h | 2 +
include/linux/vermagic.h | 8 +---
include/net/arp.h | 3 ++
include/net/ipv6.h | 1 +
include/net/net_namespace.h | 10 +++++
include/uapi/linux/eventpoll.h | 13 ++++++
init/Kconfig | 7 ++++
ipc/msg.c | 5 ++-
kernel/bpf/core.c | 24 +++++++++--
kernel/bpf/verifier.c | 42 +++++++++++++++++++
kernel/time/hrtimer.c | 3 ++
lib/test_bpf.c | 11 +++--
mm/cma.c | 15 +++----
mm/internal.h | 6 +++
mm/memcontrol.c | 2 +-
mm/memory-failure.c | 7 ++++
mm/mmap.c | 6 ++-
mm/page_alloc.c | 15 +++----
mm/vmscan.c | 47 +++++++++++++++-------
mm/vmstat.c | 2 +-
net/can/af_can.c | 22 +++++-----
net/core/dev.c | 19 +++++++--
net/core/filter.c | 10 +++--
net/core/flow_dissector.c | 3 +-
net/core/neighbour.c | 4 +-
net/core/sysctl_net_core.c | 6 +++
net/dccp/ccids/ccid2.c | 3 ++
net/ipv4/arp.c | 7 +++-
net/ipv4/igmp.c | 2 +-
net/ipv4/tcp.c | 3 ++
net/ipv4/tcp_offload.c | 3 ++
net/ipv4/tcp_timer.c | 15 +++++++
net/ipv4/udp_offload.c | 3 ++
net/ipv6/ip6_gre.c | 14 +++----
net/ipv6/ip6_output.c | 9 +++--
net/ipv6/ipv6_sockglue.c | 2 +-
net/ipv6/tcpv6_offload.c | 3 ++
net/ipv6/udp_offload.c | 3 ++
net/netfilter/nfnetlink_cthelper.c | 10 +++++
net/netfilter/xt_osf.c | 7 ++++
net/sctp/offload.c | 3 ++
net/sctp/socket.c | 30 ++++++--------
net/socket.c | 9 +++++
net/tipc/node.c | 26 ++++++------
tools/usb/usbip/libsrc/usbip_common.c | 9 ++++-
tools/usb/usbip/libsrc/usbip_host_common.c | 28 ++++++++++---
tools/usb/usbip/libsrc/vhci_driver.c | 8 ++--
tools/usb/usbip/src/usbip.c | 2 +
83 files changed, 523 insertions(+), 231 deletions(-)
This is a note to let you know that I've just added the patch titled
xfs: quota: fix missed destroy of qi_tree_lock
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:
xfs-quota-fix-missed-destroy-of-qi_tree_lock.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 28 16:23:28 CET 2018
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Date: Thu, 21 Dec 2017 13:18:26 -0800
Subject: xfs: quota: fix missed destroy of qi_tree_lock
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[ Upstream commit 2196881566225f3c3428d1a5f847a992944daa5b ]
xfs_qm_destroy_quotainfo() does not destroy quotainfo->qi_tree_lock
while destroys quotainfo->qi_quotaofflock.
Signed-off-by: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_qm.c | 1 +
1 file changed, 1 insertion(+)
--- a/fs/xfs/xfs_qm.c
+++ b/fs/xfs/xfs_qm.c
@@ -736,6 +736,7 @@ xfs_qm_destroy_quotainfo(
IRELE(qi->qi_pquotaip);
qi->qi_pquotaip = NULL;
}
+ mutex_destroy(&qi->qi_tree_lock);
mutex_destroy(&qi->qi_quotaofflock);
kmem_free(qi);
mp->m_quotainfo = NULL;
Patches currently in stable-queue which might be from akaraliou.dev(a)gmail.com are
queue-4.14/xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
queue-4.14/xfs-quota-check-result-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
xfs: quota: check result of register_shrinker()
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:
xfs-quota-check-result-of-register_shrinker.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 28 16:23:28 CET 2018
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
Date: Thu, 21 Dec 2017 13:18:26 -0800
Subject: xfs: quota: check result of register_shrinker()
From: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[ Upstream commit 3a3882ff26fbdbaf5f7e13f6a0bccfbf7121041d ]
xfs_qm_init_quotainfo() does not check result of register_shrinker()
which was tagged as __must_check recently, reported by sparse.
Signed-off-by: Aliaksei Karaliou <akaraliou.dev(a)gmail.com>
[darrick: move xfs_qm_destroy_quotainos nearer xfs_qm_init_quotainos]
Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/xfs/xfs_qm.c | 45 +++++++++++++++++++++++++++++----------------
1 file changed, 29 insertions(+), 16 deletions(-)
--- a/fs/xfs/xfs_qm.c
+++ b/fs/xfs/xfs_qm.c
@@ -48,7 +48,7 @@
STATIC int xfs_qm_init_quotainos(xfs_mount_t *);
STATIC int xfs_qm_init_quotainfo(xfs_mount_t *);
-
+STATIC void xfs_qm_destroy_quotainos(xfs_quotainfo_t *qi);
STATIC void xfs_qm_dqfree_one(struct xfs_dquot *dqp);
/*
* We use the batch lookup interface to iterate over the dquots as it
@@ -695,9 +695,17 @@ xfs_qm_init_quotainfo(
qinf->qi_shrinker.scan_objects = xfs_qm_shrink_scan;
qinf->qi_shrinker.seeks = DEFAULT_SEEKS;
qinf->qi_shrinker.flags = SHRINKER_NUMA_AWARE;
- register_shrinker(&qinf->qi_shrinker);
+
+ error = register_shrinker(&qinf->qi_shrinker);
+ if (error)
+ goto out_free_inos;
+
return 0;
+out_free_inos:
+ mutex_destroy(&qinf->qi_quotaofflock);
+ mutex_destroy(&qinf->qi_tree_lock);
+ xfs_qm_destroy_quotainos(qinf);
out_free_lru:
list_lru_destroy(&qinf->qi_lru);
out_free_qinf:
@@ -706,7 +714,6 @@ out_free_qinf:
return error;
}
-
/*
* Gets called when unmounting a filesystem or when all quotas get
* turned off.
@@ -723,19 +730,7 @@ xfs_qm_destroy_quotainfo(
unregister_shrinker(&qi->qi_shrinker);
list_lru_destroy(&qi->qi_lru);
-
- if (qi->qi_uquotaip) {
- IRELE(qi->qi_uquotaip);
- qi->qi_uquotaip = NULL; /* paranoia */
- }
- if (qi->qi_gquotaip) {
- IRELE(qi->qi_gquotaip);
- qi->qi_gquotaip = NULL;
- }
- if (qi->qi_pquotaip) {
- IRELE(qi->qi_pquotaip);
- qi->qi_pquotaip = NULL;
- }
+ xfs_qm_destroy_quotainos(qi);
mutex_destroy(&qi->qi_tree_lock);
mutex_destroy(&qi->qi_quotaofflock);
kmem_free(qi);
@@ -1601,6 +1596,24 @@ error_rele:
}
STATIC void
+xfs_qm_destroy_quotainos(
+ xfs_quotainfo_t *qi)
+{
+ if (qi->qi_uquotaip) {
+ IRELE(qi->qi_uquotaip);
+ qi->qi_uquotaip = NULL; /* paranoia */
+ }
+ if (qi->qi_gquotaip) {
+ IRELE(qi->qi_gquotaip);
+ qi->qi_gquotaip = NULL;
+ }
+ if (qi->qi_pquotaip) {
+ IRELE(qi->qi_pquotaip);
+ qi->qi_pquotaip = NULL;
+ }
+}
+
+STATIC void
xfs_qm_dqfree_one(
struct xfs_dquot *dqp)
{
Patches currently in stable-queue which might be from akaraliou.dev(a)gmail.com are
queue-4.14/xfs-quota-fix-missed-destroy-of-qi_tree_lock.patch
queue-4.14/xfs-quota-check-result-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
xen-netfront: enable device after manual module load
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:
xen-netfront-enable-device-after-manual-module-load.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 28 16:23:28 CET 2018
From: Eduardo Otubo <otubo(a)redhat.com>
Date: Fri, 5 Jan 2018 09:42:16 +0100
Subject: xen-netfront: enable device after manual module load
From: Eduardo Otubo <otubo(a)redhat.com>
[ Upstream commit b707fda2df4070785d0fa8a278aa13944c5f51f8 ]
When loading the module after unloading it, the network interface would
not be enabled and thus wouldn't have a backend counterpart and unable
to be used by the guest.
The guest would face errors like:
[root@guest ~]# ethtool -i eth0
Cannot get driver information: No such device
[root@guest ~]# ifconfig eth0
eth0: error fetching interface information: Device not found
This patch initializes the state of the netfront device whenever it is
loaded manually, this state would communicate the netback to create its
device and establish the connection between them.
Signed-off-by: Eduardo Otubo <otubo(a)redhat.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/xen-netfront.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1326,6 +1326,7 @@ static struct net_device *xennet_create_
netif_carrier_off(netdev);
+ xenbus_switch_state(dev, XenbusStateInitialising);
return netdev;
exit:
Patches currently in stable-queue which might be from otubo(a)redhat.com are
queue-4.14/xen-netfront-enable-device-after-manual-module-load.patch
This is a note to let you know that I've just added the patch titled
xen/gntdev: Fix partial gntdev_mmap() cleanup
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:
xen-gntdev-fix-partial-gntdev_mmap-cleanup.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 28 16:23:28 CET 2018
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Date: Tue, 9 Jan 2018 12:10:22 +0000
Subject: xen/gntdev: Fix partial gntdev_mmap() cleanup
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
[ Upstream commit cf2acf66ad43abb39735568f55e1f85f9844e990 ]
When cleaning up after a partially successful gntdev_mmap(), unmap the
successfully mapped grant pages otherwise Xen will kill the domain if
in debug mode (Attempt to implicitly unmap a granted PTE) or Linux will
kill the process and emit "BUG: Bad page map in process" if Xen is in
release mode.
This is only needed when use_ptemod is true because gntdev_put_map()
will unmap grant pages itself when use_ptemod is false.
Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/xen/gntdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -1071,8 +1071,10 @@ unlock_out:
out_unlock_put:
mutex_unlock(&priv->lock);
out_put_map:
- if (use_ptemod)
+ if (use_ptemod) {
map->vma = NULL;
+ unmap_grant_pages(map, 0, map->count);
+ }
gntdev_put_map(priv, map);
return err;
}
Patches currently in stable-queue which might be from ross.lagerwall(a)citrix.com are
queue-4.14/xen-gntdev-fix-off-by-one-error-when-unmapping-with-holes.patch
queue-4.14/xen-gntdev-fix-partial-gntdev_mmap-cleanup.patch
This is a note to let you know that I've just added the patch titled
xen/gntdev: Fix off-by-one error when unmapping with holes
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:
xen-gntdev-fix-off-by-one-error-when-unmapping-with-holes.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 28 16:23:28 CET 2018
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Date: Tue, 9 Jan 2018 12:10:21 +0000
Subject: xen/gntdev: Fix off-by-one error when unmapping with holes
From: Ross Lagerwall <ross.lagerwall(a)citrix.com>
[ Upstream commit 951a010233625b77cde3430b4b8785a9a22968d1 ]
If the requested range has a hole, the calculation of the number of
pages to unmap is off by one. Fix it.
Signed-off-by: Ross Lagerwall <ross.lagerwall(a)citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/xen/gntdev.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -380,10 +380,8 @@ static int unmap_grant_pages(struct gran
}
range = 0;
while (range < pages) {
- if (map->unmap_ops[offset+range].handle == -1) {
- range--;
+ if (map->unmap_ops[offset+range].handle == -1)
break;
- }
range++;
}
err = __unmap_grant_pages(map, offset, range);
Patches currently in stable-queue which might be from ross.lagerwall(a)citrix.com are
queue-4.14/xen-gntdev-fix-off-by-one-error-when-unmapping-with-holes.patch
queue-4.14/xen-gntdev-fix-partial-gntdev_mmap-cleanup.patch
This is a note to let you know that I've just added the patch titled
x86/stacktrace: Make zombie stack traces reliable
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:
x86-stacktrace-make-zombie-stack-traces-reliable.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 28 16:23:28 CET 2018
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
Date: Mon, 18 Dec 2017 15:13:44 -0600
Subject: x86/stacktrace: Make zombie stack traces reliable
From: Josh Poimboeuf <jpoimboe(a)redhat.com>
[ Upstream commit 6454b3bdd138dfc640deb5e7b9a0668fca2d55dd ]
Commit:
1959a60182f4 ("x86/dumpstack: Pin the target stack when dumping it")
changed the behavior of stack traces for zombies. Before that commit,
/proc/<pid>/stack reported the last execution path of the zombie before
it died:
[<ffffffff8105b877>] do_exit+0x6f7/0xa80
[<ffffffff8105bc79>] do_group_exit+0x39/0xa0
[<ffffffff8105bcf0>] __wake_up_parent+0x0/0x30
[<ffffffff8152dd09>] system_call_fastpath+0x16/0x1b
[<00007fd128f9c4f9>] 0x7fd128f9c4f9
[<ffffffffffffffff>] 0xffffffffffffffff
After the commit, it just reports an empty stack trace.
The new behavior is actually probably more correct. If the stack
refcount has gone down to zero, then the task has already gone through
do_exit() and isn't going to run anymore. The stack could be freed at
any time and is basically gone, so reporting an empty stack makes sense.
However, save_stack_trace_tsk_reliable() treats such a missing stack
condition as an error. That can cause livepatch transition stalls if
there are any unreaped zombies. Instead, just treat it as a reliable,
empty stack.
Reported-and-tested-by: Miroslav Benes <mbenes(a)suse.cz>
Signed-off-by: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: live-patching(a)vger.kernel.org
Fixes: af085d9084b4 ("stacktrace/x86: add function for detecting reliable stack traces")
Link: http://lkml.kernel.org/r/e4b09e630e99d0c1080528f0821fc9d9dbaeea82.151363162…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/stacktrace.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/stacktrace.c
+++ b/arch/x86/kernel/stacktrace.c
@@ -160,8 +160,12 @@ int save_stack_trace_tsk_reliable(struct
{
int ret;
+ /*
+ * If the task doesn't have a stack (e.g., a zombie), the stack is
+ * "reliably" empty.
+ */
if (!try_get_task_stack(tsk))
- return -EINVAL;
+ return 0;
ret = __save_stack_trace_reliable(trace, tsk);
Patches currently in stable-queue which might be from jpoimboe(a)redhat.com are
queue-4.14/x86-asm-allow-again-using-asm.h-when-building-for-the-bpf-clang-target.patch
queue-4.14/x86-stacktrace-make-zombie-stack-traces-reliable.patch
This is a note to let you know that I've just added the patch titled
x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const"
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:
x86-platform-intel-mid-revert-make-bt_sfi_data-const.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 28 16:23:28 CET 2018
From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Date: Thu, 28 Dec 2017 14:25:23 +0200
Subject: x86/platform/intel-mid: Revert "Make 'bt_sfi_data' const"
From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
[ Upstream commit 9d0513d82f1a8fe17b41f113ac5922fa57dbaf5c ]
So one of the constification patches unearthed a type casting fragility
of the underlying code:
276c87054751 ("x86/platform/intel-mid: Make 'bt_sfi_data' const")
converted the struct to be const while it is also used as a temporary
container for important data that is used to fill 'parent' and 'name'
fields in struct platform_device_info.
The compiler doesn't notice this due to an explicit type cast that loses
the const - which fragility will be fixed separately.
This type cast turned a seemingly trivial const propagation patch into a
hard to debug data corruptor and crasher bug.
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Cc: Bhumika Goyal <bhumirks(a)gmail.com>
Cc: Darren Hart <dvhart(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: julia.lawall(a)lip6.fr
Cc: platform-driver-x86(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20171228122523.21802-1-andriy.shevchenko@linux.int…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/platform/intel-mid/device_libs/platform_bt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/platform/intel-mid/device_libs/platform_bt.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_bt.c
@@ -60,7 +60,7 @@ static int __init tng_bt_sfi_setup(struc
return 0;
}
-static const struct bt_sfi_data tng_bt_sfi_data __initdata = {
+static struct bt_sfi_data tng_bt_sfi_data __initdata = {
.setup = tng_bt_sfi_setup,
};
Patches currently in stable-queue which might be from andriy.shevchenko(a)linux.intel.com are
queue-4.14/x86-platform-intel-mid-revert-make-bt_sfi_data-const.patch
queue-4.14/genirq-guard-handle_bad_irq-log-messages.patch
This is a note to let you know that I've just added the patch titled
x86/efi: Fix kernel param add_efi_memmap 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:
x86-efi-fix-kernel-param-add_efi_memmap-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 foo@baz Wed Feb 28 16:23:28 CET 2018
From: Dave Young <dyoung(a)redhat.com>
Date: Tue, 2 Jan 2018 17:21:09 +0000
Subject: x86/efi: Fix kernel param add_efi_memmap regression
From: Dave Young <dyoung(a)redhat.com>
[ Upstream commit 835bcec5fdf3f9e880111b482177e7e70e3596da ]
'add_efi_memmap' is an early param, but do_add_efi_memmap() has no
chance to run because the code path is before parse_early_param().
I believe it worked when the param was introduced but probably later
some other changes caused the wrong order and nobody noticed it.
Move efi_memblock_x86_reserve_range() after parse_early_param()
to fix it.
Signed-off-by: Dave Young <dyoung(a)redhat.com>
Signed-off-by: Matt Fleming <matt(a)codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Cc: Bryan O'Donoghue <pure.logic(a)nexus-software.ie>
Cc: Ge Song <ge.song(a)hxt-semitech.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-efi(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20180102172110.17018-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/setup.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -928,9 +928,6 @@ void __init setup_arch(char **cmdline_p)
set_bit(EFI_BOOT, &efi.flags);
set_bit(EFI_64BIT, &efi.flags);
}
-
- if (efi_enabled(EFI_BOOT))
- efi_memblock_x86_reserve_range();
#endif
x86_init.oem.arch_setup();
@@ -984,6 +981,8 @@ void __init setup_arch(char **cmdline_p)
parse_early_param();
+ if (efi_enabled(EFI_BOOT))
+ efi_memblock_x86_reserve_range();
#ifdef CONFIG_MEMORY_HOTPLUG
/*
* Memory used by the kernel cannot be hot-removed because Linux
Patches currently in stable-queue which might be from dyoung(a)redhat.com are
queue-4.14/x86-efi-fix-kernel-param-add_efi_memmap-regression.patch
This is a note to let you know that I've just added the patch titled
x86/asm: Allow again using asm.h when building for the 'bpf' clang 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:
x86-asm-allow-again-using-asm.h-when-building-for-the-bpf-clang-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 foo@baz Wed Feb 28 16:23:28 CET 2018
From: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Date: Mon, 4 Dec 2017 13:08:47 -0300
Subject: x86/asm: Allow again using asm.h when building for the 'bpf' clang target
From: Arnaldo Carvalho de Melo <acme(a)redhat.com>
[ Upstream commit ca26cffa4e4aaeb09bb9e308f95c7835cb149248 ]
Up to f5caf621ee35 ("x86/asm: Fix inline asm call constraints for Clang")
we were able to use x86 headers to build to the 'bpf' clang target, as
done by the BPF code in tools/perf/.
With that commit, we ended up with following failure for 'perf test LLVM', this
is because "clang ... -target bpf ..." fails since 4.0 does not have bpf inline
asm support and 6.0 does not recognize the register 'esp', fix it by guarding
that part with an #ifndef __BPF__, that is defined by clang when building to
the "bpf" target.
# perf test -v LLVM
37: LLVM search and compile :
37.1: Basic BPF llvm compile :
--- start ---
test child forked, pid 25526
Kernel build dir is set to /lib/modules/4.14.0+/build
set env: KBUILD_DIR=/lib/modules/4.14.0+/build
unset env: KBUILD_OPTS
include option is set to -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include -I/home/acme/git/linux/arch/x86/include -I./arch/x86/include/generated -I/home/acme/git/linux/include -I./include -I/home/acme/git/linux/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/home/acme/git/linux/include/uapi -I./include/generated/uapi -include /home/acme/git/linux/include/linux/kconfig.h
set env: NR_CPUS=4
set env: LINUX_VERSION_CODE=0x40e00
set env: CLANG_EXEC=/usr/local/bin/clang
set env: CLANG_OPTIONS=-xc
set env: KERNEL_INC_OPTIONS= -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include -I/home/acme/git/linux/arch/x86/include -I./arch/x86/include/generated -I/home/acme/git/linux/include -I./include -I/home/acme/git/linux/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/home/acme/git/linux/include/uapi -I./include/generated/uapi -include /home/acme/git/linux/include/linux/kconfig.h
set env: WORKING_DIR=/lib/modules/4.14.0+/build
set env: CLANG_SOURCE=-
llvm compiling command template: echo '/*
* bpf-script-example.c
* Test basic LLVM building
*/
#ifndef LINUX_VERSION_CODE
# error Need LINUX_VERSION_CODE
# error Example: for 4.2 kernel, put 'clang-opt="-DLINUX_VERSION_CODE=0x40200" into llvm section of ~/.perfconfig'
#endif
#define BPF_ANY 0
#define BPF_MAP_TYPE_ARRAY 2
#define BPF_FUNC_map_lookup_elem 1
#define BPF_FUNC_map_update_elem 2
static void *(*bpf_map_lookup_elem)(void *map, void *key) =
(void *) BPF_FUNC_map_lookup_elem;
static void *(*bpf_map_update_elem)(void *map, void *key, void *value, int flags) =
(void *) BPF_FUNC_map_update_elem;
struct bpf_map_def {
unsigned int type;
unsigned int key_size;
unsigned int value_size;
unsigned int max_entries;
};
#define SEC(NAME) __attribute__((section(NAME), used))
struct bpf_map_def SEC("maps") flip_table = {
.type = BPF_MAP_TYPE_ARRAY,
.key_size = sizeof(int),
.value_size = sizeof(int),
.max_entries = 1,
};
SEC("func=SyS_epoll_wait")
int bpf_func__SyS_epoll_wait(void *ctx)
{
int ind =0;
int *flag = bpf_map_lookup_elem(&flip_table, &ind);
int new_flag;
if (!flag)
return 0;
/* flip flag and store back */
new_flag = !*flag;
bpf_map_update_elem(&flip_table, &ind, &new_flag, BPF_ANY);
return new_flag;
}
char _license[] SEC("license") = "GPL";
int _version SEC("version") = LINUX_VERSION_CODE;
' | $CLANG_EXEC -D__KERNEL__ -D__NR_CPUS__=$NR_CPUS -DLINUX_VERSION_CODE=$LINUX_VERSION_CODE $CLANG_OPTIONS $KERNEL_INC_OPTIONS -Wno-unused-value -Wno-pointer-sign -working-directory $WORKING_DIR -c "$CLANG_SOURCE" -target bpf -O2 -o -
test child finished with 0
---- end ----
LLVM search and compile subtest 0: Ok
37.2: kbuild searching :
--- start ---
test child forked, pid 25950
Kernel build dir is set to /lib/modules/4.14.0+/build
set env: KBUILD_DIR=/lib/modules/4.14.0+/build
unset env: KBUILD_OPTS
include option is set to -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include -I/home/acme/git/linux/arch/x86/include -I./arch/x86/include/generated -I/home/acme/git/linux/include -I./include -I/home/acme/git/linux/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/home/acme/git/linux/include/uapi -I./include/generated/uapi -include /home/acme/git/linux/include/linux/kconfig.h
set env: NR_CPUS=4
set env: LINUX_VERSION_CODE=0x40e00
set env: CLANG_EXEC=/usr/local/bin/clang
set env: CLANG_OPTIONS=-xc
set env: KERNEL_INC_OPTIONS= -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/7/include -I/home/acme/git/linux/arch/x86/include -I./arch/x86/include/generated -I/home/acme/git/linux/include -I./include -I/home/acme/git/linux/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/home/acme/git/linux/include/uapi -I./include/generated/uapi -include /home/acme/git/linux/include/linux/kconfig.h
set env: WORKING_DIR=/lib/modules/4.14.0+/build
set env: CLANG_SOURCE=-
llvm compiling command template: echo '/*
* bpf-script-test-kbuild.c
* Test include from kernel header
*/
#ifndef LINUX_VERSION_CODE
# error Need LINUX_VERSION_CODE
# error Example: for 4.2 kernel, put 'clang-opt="-DLINUX_VERSION_CODE=0x40200" into llvm section of ~/.perfconfig'
#endif
#define SEC(NAME) __attribute__((section(NAME), used))
#include <uapi/linux/fs.h>
#include <uapi/asm/ptrace.h>
SEC("func=vfs_llseek")
int bpf_func__vfs_llseek(void *ctx)
{
return 0;
}
char _license[] SEC("license") = "GPL";
int _version SEC("version") = LINUX_VERSION_CODE;
' | $CLANG_EXEC -D__KERNEL__ -D__NR_CPUS__=$NR_CPUS -DLINUX_VERSION_CODE=$LINUX_VERSION_CODE $CLANG_OPTIONS $KERNEL_INC_OPTIONS -Wno-unused-value -Wno-pointer-sign -working-directory $WORKING_DIR -c "$CLANG_SOURCE" -target bpf -O2 -o -
In file included from <stdin>:12:
In file included from /home/acme/git/linux/arch/x86/include/uapi/asm/ptrace.h:5:
In file included from /home/acme/git/linux/include/linux/compiler.h:242:
In file included from /home/acme/git/linux/arch/x86/include/asm/barrier.h:5:
In file included from /home/acme/git/linux/arch/x86/include/asm/alternative.h:10:
/home/acme/git/linux/arch/x86/include/asm/asm.h:145:50: error: unknown register name 'esp' in asm
register unsigned long current_stack_pointer asm(_ASM_SP);
^
/home/acme/git/linux/arch/x86/include/asm/asm.h:44:18: note: expanded from macro '_ASM_SP'
#define _ASM_SP __ASM_REG(sp)
^
/home/acme/git/linux/arch/x86/include/asm/asm.h:27:32: note: expanded from macro '__ASM_REG'
#define __ASM_REG(reg) __ASM_SEL_RAW(e##reg, r##reg)
^
/home/acme/git/linux/arch/x86/include/asm/asm.h:18:29: note: expanded from macro '__ASM_SEL_RAW'
# define __ASM_SEL_RAW(a,b) __ASM_FORM_RAW(a)
^
/home/acme/git/linux/arch/x86/include/asm/asm.h:11:32: note: expanded from macro '__ASM_FORM_RAW'
# define __ASM_FORM_RAW(x) #x
^
<scratch space>:4:1: note: expanded from here
"esp"
^
1 error generated.
ERROR: unable to compile -
Hint: Check error message shown above.
Hint: You can also pre-compile it into .o using:
clang -target bpf -O2 -c -
with proper -I and -D options.
Failed to compile test case: 'kbuild searching'
test child finished with -1
---- end ----
LLVM search and compile subtest 1: FAILED!
Cc: Adrian Hunter <adrian.hunter(a)intel.com>
Cc: Alexander Potapenko <glider(a)google.com>
Cc: Alexei Starovoitov <alexei.starovoitov(a)gmail.com>
Cc: Andrey Ryabinin <aryabinin(a)virtuozzo.com>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: Daniel Borkmann <daniel(a)iogearbox.net>
Cc: David Ahern <dsahern(a)gmail.com>
Cc: Dmitriy Vyukov <dvyukov(a)google.com>
Cc: Jiri Olsa <jolsa(a)kernel.org>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Miguel Bernal Marin <miguel.bernal.marin(a)linux.intel.com>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Wang Nan <wangnan0(a)huawei.com>
Cc: Yonghong Song <yhs(a)fb.com>
Link: https://lkml.kernel.org/r/20171128175948.GL3298@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/asm.h | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/x86/include/asm/asm.h
+++ b/arch/x86/include/asm/asm.h
@@ -136,6 +136,7 @@
#endif
#ifndef __ASSEMBLY__
+#ifndef __BPF__
/*
* This output constraint should be used for any inline asm which has a "call"
* instruction. Otherwise the asm may be inserted before the frame pointer
@@ -145,5 +146,6 @@
register unsigned long current_stack_pointer asm(_ASM_SP);
#define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer)
#endif
+#endif
#endif /* _ASM_X86_ASM_H */
Patches currently in stable-queue which might be from acme(a)redhat.com are
queue-4.14/x86-asm-allow-again-using-asm.h-when-building-for-the-bpf-clang-target.patch
This is a note to let you know that I've just added the patch titled
x86-64/Xen: eliminate W+X mappings
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:
x86-64-xen-eliminate-w-x-mappings.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 28 16:23:28 CET 2018
From: Jan Beulich <JBeulich(a)suse.com>
Date: Mon, 18 Dec 2017 09:37:45 -0700
Subject: x86-64/Xen: eliminate W+X mappings
From: Jan Beulich <JBeulich(a)suse.com>
[ Upstream commit 2cc42bac1c795f75fcc062b95c6ca7ac1b84d5d8 ]
A few thousand such pages are usually left around due to the re-use of
L1 tables having been provided by the hypervisor (Dom0) or tool stack
(DomU). Set NX in the direct map variant, which needs to be done in L2
due to the dual use of the re-used L1s.
For x86_configure_nx() to actually do what it is supposed to do, call
get_cpu_cap() first. This was broken by commit 4763ed4d45 ("x86, mm:
Clean up and simplify NX enablement") when switching away from the
direct EFER read.
Signed-off-by: Jan Beulich <jbeulich(a)suse.com>
Reviewed-by: Juergen Gross <jgross(a)suse.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/xen/enlighten_pv.c | 3 +++
arch/x86/xen/mmu_pv.c | 12 ++++++++++++
2 files changed, 15 insertions(+)
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -88,6 +88,8 @@
#include "multicalls.h"
#include "pmu.h"
+#include "../kernel/cpu/cpu.h" /* get_cpu_cap() */
+
void *xen_initial_gdt;
static int xen_cpu_up_prepare_pv(unsigned int cpu);
@@ -1257,6 +1259,7 @@ asmlinkage __visible void __init xen_sta
__userpte_alloc_gfp &= ~__GFP_HIGHMEM;
/* Work out if we support NX */
+ get_cpu_cap(&boot_cpu_data);
x86_configure_nx();
/* Get mfn list */
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -1902,6 +1902,18 @@ void __init xen_setup_kernel_pagetable(p
/* Graft it onto L4[511][510] */
copy_page(level2_kernel_pgt, l2);
+ /*
+ * Zap execute permission from the ident map. Due to the sharing of
+ * L1 entries we need to do this in the L2.
+ */
+ if (__supported_pte_mask & _PAGE_NX) {
+ for (i = 0; i < PTRS_PER_PMD; ++i) {
+ if (pmd_none(level2_ident_pgt[i]))
+ continue;
+ level2_ident_pgt[i] = pmd_set_flags(level2_ident_pgt[i], _PAGE_NX);
+ }
+ }
+
/* Copy the initial P->M table mappings if necessary. */
i = pgd_index(xen_start_info->mfn_list);
if (i && i < pgd_index(__START_KERNEL_map))
Patches currently in stable-queue which might be from JBeulich(a)suse.com are
queue-4.14/x86-64-xen-eliminate-w-x-mappings.patch
This is a note to let you know that I've just added the patch titled
wcn36xx: Fix dynamic power saving
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:
wcn36xx-fix-dynamic-power-saving.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 28 16:23:28 CET 2018
From: Loic Poulain <loic.poulain(a)linaro.org>
Date: Mon, 11 Dec 2017 09:52:22 +0100
Subject: wcn36xx: Fix dynamic power saving
From: Loic Poulain <loic.poulain(a)linaro.org>
[ Upstream commit 0856655a25476d4431005e39d606e349050066b0 ]
Since driver does not report hardware dynamic power saving cap,
this is up to the mac80211 to manage power saving timeout and
state machine, using the ieee80211 config callback to report
PS changes. This patch enables/disables PS mode according to
the new configuration.
Remove old behaviour enabling PS mode in a static way, this make
the device unusable when power save is enabled since device is
forced to PS regardless RX/TX traffic.
Acked-by: Bjorn Andersson <bjorn.andersson(a)linaro.org>
Signed-off-by: Loic Poulain <loic.poulain(a)linaro.org>
Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wireless/ath/wcn36xx/main.c | 23 ++++++++++++-----------
drivers/net/wireless/ath/wcn36xx/pmc.c | 6 ++++--
2 files changed, 16 insertions(+), 13 deletions(-)
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -384,6 +384,18 @@ static int wcn36xx_config(struct ieee802
}
}
+ if (changed & IEEE80211_CONF_CHANGE_PS) {
+ list_for_each_entry(tmp, &wcn->vif_list, list) {
+ vif = wcn36xx_priv_to_vif(tmp);
+ if (hw->conf.flags & IEEE80211_CONF_PS) {
+ if (vif->bss_conf.ps) /* ps allowed ? */
+ wcn36xx_pmc_enter_bmps_state(wcn, vif);
+ } else {
+ wcn36xx_pmc_exit_bmps_state(wcn, vif);
+ }
+ }
+ }
+
mutex_unlock(&wcn->conf_mutex);
return 0;
@@ -747,17 +759,6 @@ static void wcn36xx_bss_info_changed(str
vif_priv->dtim_period = bss_conf->dtim_period;
}
- if (changed & BSS_CHANGED_PS) {
- wcn36xx_dbg(WCN36XX_DBG_MAC,
- "mac bss PS set %d\n",
- bss_conf->ps);
- if (bss_conf->ps) {
- wcn36xx_pmc_enter_bmps_state(wcn, vif);
- } else {
- wcn36xx_pmc_exit_bmps_state(wcn, vif);
- }
- }
-
if (changed & BSS_CHANGED_BSSID) {
wcn36xx_dbg(WCN36XX_DBG_MAC, "mac bss changed_bssid %pM\n",
bss_conf->bssid);
--- a/drivers/net/wireless/ath/wcn36xx/pmc.c
+++ b/drivers/net/wireless/ath/wcn36xx/pmc.c
@@ -45,8 +45,10 @@ int wcn36xx_pmc_exit_bmps_state(struct w
struct wcn36xx_vif *vif_priv = wcn36xx_vif_to_priv(vif);
if (WCN36XX_BMPS != vif_priv->pw_state) {
- wcn36xx_err("Not in BMPS mode, no need to exit from BMPS mode!\n");
- return -EINVAL;
+ /* Unbalanced call or last BMPS enter failed */
+ wcn36xx_dbg(WCN36XX_DBG_PMC,
+ "Not in BMPS mode, no need to exit\n");
+ return -EALREADY;
}
wcn36xx_smd_exit_bmps(wcn, vif);
vif_priv->pw_state = WCN36XX_FULL_POWER;
Patches currently in stable-queue which might be from loic.poulain(a)linaro.org are
queue-4.14/wcn36xx-fix-dynamic-power-saving.patch
This is a note to let you know that I've just added the patch titled
vxlan: update skb dst pmtu on tx path
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:
vxlan-update-skb-dst-pmtu-on-tx-path.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 28 16:23:28 CET 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Mon, 18 Dec 2017 14:20:56 +0800
Subject: vxlan: update skb dst pmtu on tx path
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit a93bf0ff449064e6b7f44e58522e940f88c0d966 ]
Unlike ip tunnels, now vxlan doesn't do any pmtu update for
upper dst pmtu, even if it doesn't match the lower dst pmtu
any more.
The problem can be reproduced when reducing the vxlan lower
dev's pmtu when running netperf. In jianlin's testing, the
performance went to 1/7 of the previous.
This patch is to update the upper dst pmtu to match the lower
dst pmtu on tx path so that packets can be sent out even when
lower dev's pmtu has been changed.
It also works for metadata dst.
Note that this patch doesn't process any pmtu icmp packet.
But even in the future, the support for pmtu icmp packets
process of udp tunnels will also needs this.
The same thing will be done for geneve in another patch.
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/vxlan.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2155,6 +2155,13 @@ static void vxlan_xmit_one(struct sk_buf
}
ndst = &rt->dst;
+ if (skb_dst(skb)) {
+ int mtu = dst_mtu(ndst) - VXLAN_HEADROOM;
+
+ skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL,
+ skb, mtu);
+ }
+
tos = ip_tunnel_ecn_encap(tos, old_iph, skb);
ttl = ttl ? : ip4_dst_hoplimit(&rt->dst);
err = vxlan_build_skb(skb, ndst, sizeof(struct iphdr),
@@ -2190,6 +2197,13 @@ static void vxlan_xmit_one(struct sk_buf
goto out_unlock;
}
+ if (skb_dst(skb)) {
+ int mtu = dst_mtu(ndst) - VXLAN6_HEADROOM;
+
+ skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL,
+ skb, mtu);
+ }
+
tos = ip_tunnel_ecn_encap(tos, old_iph, skb);
ttl = ttl ? : ip6_dst_hoplimit(ndst);
skb_scrub_packet(skb, xnet);
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/ip_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.patch
queue-4.14/ip6_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.patch
queue-4.14/ip6_tunnel-allow-ip6gre-dev-mtu-to-be-set-below-1280.patch
queue-4.14/vxlan-update-skb-dst-pmtu-on-tx-path.patch
queue-4.14/ip6_tunnel-get-the-min-mtu-properly-in-ip6_tnl_xmit.patch
queue-4.14/sctp-fix-the-issue-that-a-__u16-variable-may-overflow-in-sctp_ulpq_renege.patch
This is a note to let you know that I've just added the patch titled
uapi libc compat: add fallback for unsupported libcs
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:
uapi-libc-compat-add-fallback-for-unsupported-libcs.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 28 16:23:28 CET 2018
From: Felix Janda <felix.janda(a)posteo.de>
Date: Mon, 1 Jan 2018 19:33:20 +0100
Subject: uapi libc compat: add fallback for unsupported libcs
From: Felix Janda <felix.janda(a)posteo.de>
[ Upstream commit c0bace798436bca0fdc221ff61143f1376a9c3de ]
libc-compat.h aims to prevent symbol collisions between uapi and libc
headers for each supported libc. This requires continuous coordination
between them.
The goal of this commit is to improve the situation for libcs (such as
musl) which are not yet supported and/or do not wish to be explicitly
supported, while not affecting supported libcs. More precisely, with
this commit, unsupported libcs can request the suppression of any
specific uapi definition by defining the correspondings _UAPI_DEF_*
macro as 0. This can fix symbol collisions for them, as long as the
libc headers are included before the uapi headers. Inclusion in the
other order is outside the scope of this commit.
All infrastructure in order to enable this fallback for unsupported
libcs is already in place, except that libc-compat.h unconditionally
defines all _UAPI_DEF_* macros to 1 for all unsupported libcs so that
any previous definitions are ignored. In order to fix this, this commit
merely makes these definitions conditional.
This commit together with the musl libc commit
http://git.musl-libc.org/cgit/musl/commit/?id=04983f2272382af92eb8f8838964f…
fixes for example the following compiler errors when <linux/in6.h> is
included after musl's <netinet/in.h>:
./linux/in6.h:32:8: error: redefinition of 'struct in6_addr'
./linux/in6.h:49:8: error: redefinition of 'struct sockaddr_in6'
./linux/in6.h:59:8: error: redefinition of 'struct ipv6_mreq'
The comments referencing glibc are still correct, but this file is not
only used for glibc any more.
Signed-off-by: Felix Janda <felix.janda(a)posteo.de>
Reviewed-by: Hauke Mehrtens <hauke(a)hauke-m.de>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/uapi/linux/libc-compat.h | 55 ++++++++++++++++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 1 deletion(-)
--- a/include/uapi/linux/libc-compat.h
+++ b/include/uapi/linux/libc-compat.h
@@ -168,46 +168,99 @@
/* If we did not see any headers from any supported C libraries,
* or we are being included in the kernel, then define everything
- * that we need. */
+ * that we need. Check for previous __UAPI_* definitions to give
+ * unsupported C libraries a way to opt out of any kernel definition. */
#else /* !defined(__GLIBC__) */
/* Definitions for if.h */
+#ifndef __UAPI_DEF_IF_IFCONF
#define __UAPI_DEF_IF_IFCONF 1
+#endif
+#ifndef __UAPI_DEF_IF_IFMAP
#define __UAPI_DEF_IF_IFMAP 1
+#endif
+#ifndef __UAPI_DEF_IF_IFNAMSIZ
#define __UAPI_DEF_IF_IFNAMSIZ 1
+#endif
+#ifndef __UAPI_DEF_IF_IFREQ
#define __UAPI_DEF_IF_IFREQ 1
+#endif
/* Everything up to IFF_DYNAMIC, matches net/if.h until glibc 2.23 */
+#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS
#define __UAPI_DEF_IF_NET_DEVICE_FLAGS 1
+#endif
/* For the future if glibc adds IFF_LOWER_UP, IFF_DORMANT and IFF_ECHO */
+#ifndef __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO
#define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 1
+#endif
/* Definitions for in.h */
+#ifndef __UAPI_DEF_IN_ADDR
#define __UAPI_DEF_IN_ADDR 1
+#endif
+#ifndef __UAPI_DEF_IN_IPPROTO
#define __UAPI_DEF_IN_IPPROTO 1
+#endif
+#ifndef __UAPI_DEF_IN_PKTINFO
#define __UAPI_DEF_IN_PKTINFO 1
+#endif
+#ifndef __UAPI_DEF_IP_MREQ
#define __UAPI_DEF_IP_MREQ 1
+#endif
+#ifndef __UAPI_DEF_SOCKADDR_IN
#define __UAPI_DEF_SOCKADDR_IN 1
+#endif
+#ifndef __UAPI_DEF_IN_CLASS
#define __UAPI_DEF_IN_CLASS 1
+#endif
/* Definitions for in6.h */
+#ifndef __UAPI_DEF_IN6_ADDR
#define __UAPI_DEF_IN6_ADDR 1
+#endif
+#ifndef __UAPI_DEF_IN6_ADDR_ALT
#define __UAPI_DEF_IN6_ADDR_ALT 1
+#endif
+#ifndef __UAPI_DEF_SOCKADDR_IN6
#define __UAPI_DEF_SOCKADDR_IN6 1
+#endif
+#ifndef __UAPI_DEF_IPV6_MREQ
#define __UAPI_DEF_IPV6_MREQ 1
+#endif
+#ifndef __UAPI_DEF_IPPROTO_V6
#define __UAPI_DEF_IPPROTO_V6 1
+#endif
+#ifndef __UAPI_DEF_IPV6_OPTIONS
#define __UAPI_DEF_IPV6_OPTIONS 1
+#endif
+#ifndef __UAPI_DEF_IN6_PKTINFO
#define __UAPI_DEF_IN6_PKTINFO 1
+#endif
+#ifndef __UAPI_DEF_IP6_MTUINFO
#define __UAPI_DEF_IP6_MTUINFO 1
+#endif
/* Definitions for ipx.h */
+#ifndef __UAPI_DEF_SOCKADDR_IPX
#define __UAPI_DEF_SOCKADDR_IPX 1
+#endif
+#ifndef __UAPI_DEF_IPX_ROUTE_DEFINITION
#define __UAPI_DEF_IPX_ROUTE_DEFINITION 1
+#endif
+#ifndef __UAPI_DEF_IPX_INTERFACE_DEFINITION
#define __UAPI_DEF_IPX_INTERFACE_DEFINITION 1
+#endif
+#ifndef __UAPI_DEF_IPX_CONFIG_DATA
#define __UAPI_DEF_IPX_CONFIG_DATA 1
+#endif
+#ifndef __UAPI_DEF_IPX_ROUTE_DEF
#define __UAPI_DEF_IPX_ROUTE_DEF 1
+#endif
/* Definitions for xattr.h */
+#ifndef __UAPI_DEF_XATTR
#define __UAPI_DEF_XATTR 1
+#endif
#endif /* __GLIBC__ */
Patches currently in stable-queue which might be from felix.janda(a)posteo.de are
queue-4.14/uapi-libc-compat-add-fallback-for-unsupported-libcs.patch
This is a note to let you know that I've just added the patch titled
tipc: error path leak fixes in tipc_enable_bearer()
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:
tipc-error-path-leak-fixes-in-tipc_enable_bearer.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 28 16:23:28 CET 2018
From: Tommi Rantala <tommi.t.rantala(a)nokia.com>
Date: Fri, 22 Dec 2017 09:35:16 +0200
Subject: tipc: error path leak fixes in tipc_enable_bearer()
From: Tommi Rantala <tommi.t.rantala(a)nokia.com>
[ Upstream commit 19142551b2be4a9e13838099fde1351386e5e007 ]
Fix memory leak in tipc_enable_bearer() if enable_media() fails, and
cleanup with bearer_disable() if tipc_mon_create() fails.
Acked-by: Ying Xue <ying.xue(a)windriver.com>
Acked-by: Jon Maloy <jon.maloy(a)ericsson.com>
Signed-off-by: Tommi Rantala <tommi.t.rantala(a)nokia.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/tipc/bearer.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -324,6 +324,7 @@ restart:
if (res) {
pr_warn("Bearer <%s> rejected, enable failure (%d)\n",
name, -res);
+ kfree(b);
return -EINVAL;
}
@@ -347,8 +348,10 @@ restart:
if (skb)
tipc_bearer_xmit_skb(net, bearer_id, skb, &b->bcast_addr);
- if (tipc_mon_create(net, bearer_id))
+ if (tipc_mon_create(net, bearer_id)) {
+ bearer_disable(net, b);
return -ENOMEM;
+ }
pr_info("Enabled bearer <%s>, discovery domain %s, priority %u\n",
name,
Patches currently in stable-queue which might be from tommi.t.rantala(a)nokia.com are
queue-4.14/perf-x86-intel-plug-memory-leak-in-intel_pmu_init.patch
queue-4.14/tipc-error-path-leak-fixes-in-tipc_enable_bearer.patch
queue-4.14/tipc-fix-tipc_mon_delete-oops-in-tipc_enable_bearer-error-path.patch
This is a note to let you know that I've just added the patch titled
tg3: Enable PHY reset in MTU change path for 5720
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:
tg3-enable-phy-reset-in-mtu-change-path-for-5720.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 28 16:23:28 CET 2018
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Date: Fri, 22 Dec 2017 16:05:29 +0530
Subject: tg3: Enable PHY reset in MTU change path for 5720
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
[ Upstream commit e60ee41aaf898584205a6af5c996860d0fe6a836 ]
A customer noticed RX path hang when MTU is changed on the fly while
running heavy traffic with NCSI enabled for 5717 and 5719. Since 5720
belongs to same ASIC family, we observed same issue and same fix
could solve this problem for 5720.
Signed-off-by: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/tg3.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -14239,7 +14239,8 @@ static int tg3_change_mtu(struct net_dev
*/
if (tg3_asic_rev(tp) == ASIC_REV_57766 ||
tg3_asic_rev(tp) == ASIC_REV_5717 ||
- tg3_asic_rev(tp) == ASIC_REV_5719)
+ tg3_asic_rev(tp) == ASIC_REV_5719 ||
+ tg3_asic_rev(tp) == ASIC_REV_5720)
reset_phy = true;
err = tg3_restart_hw(tp, reset_phy);
Patches currently in stable-queue which might be from siva.kallam(a)broadcom.com are
queue-4.14/tg3-enable-phy-reset-in-mtu-change-path-for-5720.patch
queue-4.14/tg3-add-workaround-to-restrict-5762-mrrs-to-2048.patch
This is a note to let you know that I've just added the patch titled
tg3: Add workaround to restrict 5762 MRRS to 2048
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:
tg3-add-workaround-to-restrict-5762-mrrs-to-2048.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 28 16:23:28 CET 2018
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Date: Fri, 22 Dec 2017 16:05:28 +0530
Subject: tg3: Add workaround to restrict 5762 MRRS to 2048
From: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
[ Upstream commit 4419bb1cedcda0272e1dc410345c5a1d1da0e367 ]
One of AMD based server with 5762 hangs with jumbo frame traffic.
This AMD platform has southbridge limitation which is restricting MRRS
to 4000. As a work around, driver to restricts the MRRS to 2048 for
this particular 5762 NX1 card.
Signed-off-by: Siva Reddy Kallam <siva.kallam(a)broadcom.com>
Signed-off-by: Michael Chan <michael.chan(a)broadcom.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/tg3.c | 10 ++++++++++
drivers/net/ethernet/broadcom/tg3.h | 4 ++++
2 files changed, 14 insertions(+)
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -10052,6 +10052,16 @@ static int tg3_reset_hw(struct tg3 *tp,
tw32(GRC_MODE, tp->grc_mode | val);
+ /* On one of the AMD platform, MRRS is restricted to 4000 because of
+ * south bridge limitation. As a workaround, Driver is setting MRRS
+ * to 2048 instead of default 4096.
+ */
+ if (tp->pdev->subsystem_vendor == PCI_VENDOR_ID_DELL &&
+ tp->pdev->subsystem_device == TG3PCI_SUBDEVICE_ID_DELL_5762) {
+ val = tr32(TG3PCI_DEV_STATUS_CTRL) & ~MAX_READ_REQ_MASK;
+ tw32(TG3PCI_DEV_STATUS_CTRL, val | MAX_READ_REQ_SIZE_2048);
+ }
+
/* Setup the timer prescalar register. Clock is always 66Mhz. */
val = tr32(GRC_MISC_CFG);
val &= ~0xff;
--- a/drivers/net/ethernet/broadcom/tg3.h
+++ b/drivers/net/ethernet/broadcom/tg3.h
@@ -96,6 +96,7 @@
#define TG3PCI_SUBDEVICE_ID_DELL_JAGUAR 0x0106
#define TG3PCI_SUBDEVICE_ID_DELL_MERLOT 0x0109
#define TG3PCI_SUBDEVICE_ID_DELL_SLIM_MERLOT 0x010a
+#define TG3PCI_SUBDEVICE_ID_DELL_5762 0x07f0
#define TG3PCI_SUBVENDOR_ID_COMPAQ PCI_VENDOR_ID_COMPAQ
#define TG3PCI_SUBDEVICE_ID_COMPAQ_BANSHEE 0x007c
#define TG3PCI_SUBDEVICE_ID_COMPAQ_BANSHEE_2 0x009a
@@ -281,6 +282,9 @@
#define TG3PCI_STD_RING_PROD_IDX 0x00000098 /* 64-bit */
#define TG3PCI_RCV_RET_RING_CON_IDX 0x000000a0 /* 64-bit */
/* 0xa8 --> 0xb8 unused */
+#define TG3PCI_DEV_STATUS_CTRL 0x000000b4
+#define MAX_READ_REQ_SIZE_2048 0x00004000
+#define MAX_READ_REQ_MASK 0x00007000
#define TG3PCI_DUAL_MAC_CTRL 0x000000b8
#define DUAL_MAC_CTRL_CH_MASK 0x00000003
#define DUAL_MAC_CTRL_ID 0x00000004
Patches currently in stable-queue which might be from siva.kallam(a)broadcom.com are
queue-4.14/tg3-enable-phy-reset-in-mtu-change-path-for-5720.patch
queue-4.14/tg3-add-workaround-to-restrict-5762-mrrs-to-2048.patch
This is a note to let you know that I've just added the patch titled
staging: ion: Fix ion_cma_heap allocations
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:
staging-ion-fix-ion_cma_heap-allocations.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 28 16:23:28 CET 2018
From: John Stultz <john.stultz(a)linaro.org>
Date: Fri, 15 Dec 2017 19:59:47 -0800
Subject: staging: ion: Fix ion_cma_heap allocations
From: John Stultz <john.stultz(a)linaro.org>
[ Upstream commit f292b9b28097d8fe870336108e91bd95a14294bf ]
In trying to add support for drm_hwcomposer to HiKey,
I've needed to utilize the ION CMA heap, and I've noticed
problems with allocations on newer kernels failing.
It seems back with 204f672255c2 ("ion: Use CMA APIs directly"),
the ion_cma_heap code was modified to use the CMA API, but
kept the arguments as buffer lengths rather then number of pages.
This results in errors as we don't have enough pages in CMA to
satisfy the exaggerated requests.
This patch converts the ion_cma_heap CMA API usage to properly
request pages.
It also fixes a minor issue in the allocation where in the error
path, the cma_release is called with the buffer->size value which
hasn't yet been set.
Cc: Laura Abbott <labbott(a)redhat.com>
Cc: Sumit Semwal <sumit.semwal(a)linaro.org>
Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org>
Cc: Archit Taneja <architt(a)codeaurora.org>
Cc: Greg KH <gregkh(a)linuxfoundation.org>
Cc: Daniel Vetter <daniel(a)ffwll.ch>
Cc: Dmitry Shmidt <dimitrysh(a)google.com>
Cc: Todd Kjos <tkjos(a)google.com>
Cc: Amit Pundir <amit.pundir(a)linaro.org>
Fixes: 204f672255c2 ("staging: android: ion: Use CMA APIs directly")
Acked-by: Laura Abbott <labbott(a)redhat.com>
Signed-off-by: John Stultz <john.stultz(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/android/ion/Kconfig | 2 +-
drivers/staging/android/ion/ion_cma_heap.c | 15 +++++++++++----
2 files changed, 12 insertions(+), 5 deletions(-)
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -37,7 +37,7 @@ config ION_CHUNK_HEAP
config ION_CMA_HEAP
bool "Ion CMA heap support"
- depends on ION && CMA
+ depends on ION && DMA_CMA
help
Choose this option to enable CMA heaps with Ion. This heap is backed
by the Contiguous Memory Allocator (CMA). If your system has these
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -39,9 +39,15 @@ static int ion_cma_allocate(struct ion_h
struct ion_cma_heap *cma_heap = to_cma_heap(heap);
struct sg_table *table;
struct page *pages;
+ unsigned long size = PAGE_ALIGN(len);
+ unsigned long nr_pages = size >> PAGE_SHIFT;
+ unsigned long align = get_order(size);
int ret;
- pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
+ if (align > CONFIG_CMA_ALIGNMENT)
+ align = CONFIG_CMA_ALIGNMENT;
+
+ pages = cma_alloc(cma_heap->cma, nr_pages, align, GFP_KERNEL);
if (!pages)
return -ENOMEM;
@@ -53,7 +59,7 @@ static int ion_cma_allocate(struct ion_h
if (ret)
goto free_mem;
- sg_set_page(table->sgl, pages, len, 0);
+ sg_set_page(table->sgl, pages, size, 0);
buffer->priv_virt = pages;
buffer->sg_table = table;
@@ -62,7 +68,7 @@ static int ion_cma_allocate(struct ion_h
free_mem:
kfree(table);
err:
- cma_release(cma_heap->cma, pages, buffer->size);
+ cma_release(cma_heap->cma, pages, nr_pages);
return -ENOMEM;
}
@@ -70,9 +76,10 @@ static void ion_cma_free(struct ion_buff
{
struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
struct page *pages = buffer->priv_virt;
+ unsigned long nr_pages = PAGE_ALIGN(buffer->size) >> PAGE_SHIFT;
/* release memory */
- cma_release(cma_heap->cma, pages, buffer->size);
+ cma_release(cma_heap->cma, pages, nr_pages);
/* release sg table */
sg_free_table(buffer->sg_table);
kfree(buffer->sg_table);
Patches currently in stable-queue which might be from john.stultz(a)linaro.org are
queue-4.14/hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
queue-4.14/staging-ion-fix-ion_cma_heap-allocations.patch
This is a note to let you know that I've just added the patch titled
spi: atmel: fixed spin_lock usage inside atmel_spi_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:
spi-atmel-fixed-spin_lock-usage-inside-atmel_spi_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 foo@baz Wed Feb 28 16:23:28 CET 2018
From: Radu Pirea <radu.pirea(a)microchip.com>
Date: Fri, 15 Dec 2017 17:40:17 +0200
Subject: spi: atmel: fixed spin_lock usage inside atmel_spi_remove
From: Radu Pirea <radu.pirea(a)microchip.com>
[ Upstream commit 66e900a3d225575c8b48b59ae1fe74bb6e5a65cc ]
The only part of atmel_spi_remove which needs to be atomic is hardware
reset.
atmel_spi_stop_dma calls dma_terminate_all and this needs interrupts
enabled.
atmel_spi_release_dma calls dma_release_channel and dma_release_channel
locks a mutex inside of spin_lock.
So the call of these functions can't be inside a spin_lock.
Reported-by: Jia-Ju Bai <baijiaju1990(a)gmail.com>
Signed-off-by: Radu Pirea <radu.pirea(a)microchip.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/spi/spi-atmel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/spi/spi-atmel.c
+++ b/drivers/spi/spi-atmel.c
@@ -1661,12 +1661,12 @@ static int atmel_spi_remove(struct platf
pm_runtime_get_sync(&pdev->dev);
/* reset the hardware and block queue progress */
- spin_lock_irq(&as->lock);
if (as->use_dma) {
atmel_spi_stop_dma(master);
atmel_spi_release_dma(master);
}
+ spin_lock_irq(&as->lock);
spi_writel(as, CR, SPI_BIT(SWRST));
spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
spi_readl(as, SR);
Patches currently in stable-queue which might be from radu.pirea(a)microchip.com are
queue-4.14/spi-atmel-fixed-spin_lock-usage-inside-atmel_spi_remove.patch
This is a note to let you know that I've just added the patch titled
SolutionEngine771x: fix Ether platform data
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:
solutionengine771x-fix-ether-platform-data.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 28 16:23:28 CET 2018
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Date: Sat, 6 Jan 2018 21:53:26 +0300
Subject: SolutionEngine771x: fix Ether platform data
From: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
[ Upstream commit 195e2addbce09e5afbc766efc1e6567c9ce840d3 ]
The 'sh_eth' driver's probe() method would fail on the SolutionEngine7710
board and crash on SolutionEngine7712 board as the platform code is
hopelessly behind the driver's platform data -- it passes the PHY address
instead of 'struct sh_eth_plat_data *'; pass the latter to the driver in
order to fix the bug...
Fixes: 71557a37adb5 ("[netdrvr] sh_eth: Add SH7619 support")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov(a)cogentembedded.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/sh/boards/mach-se/770x/setup.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/arch/sh/boards/mach-se/770x/setup.c
+++ b/arch/sh/boards/mach-se/770x/setup.c
@@ -9,6 +9,7 @@
*/
#include <linux/init.h>
#include <linux/platform_device.h>
+#include <linux/sh_eth.h>
#include <mach-se/mach/se.h>
#include <mach-se/mach/mrshpc.h>
#include <asm/machvec.h>
@@ -115,6 +116,11 @@ static struct platform_device heartbeat_
#if defined(CONFIG_CPU_SUBTYPE_SH7710) ||\
defined(CONFIG_CPU_SUBTYPE_SH7712)
/* SH771X Ethernet driver */
+static struct sh_eth_plat_data sh_eth_plat = {
+ .phy = PHY_ID,
+ .phy_interface = PHY_INTERFACE_MODE_MII,
+};
+
static struct resource sh_eth0_resources[] = {
[0] = {
.start = SH_ETH0_BASE,
@@ -132,7 +138,7 @@ static struct platform_device sh_eth0_de
.name = "sh771x-ether",
.id = 0,
.dev = {
- .platform_data = PHY_ID,
+ .platform_data = &sh_eth_plat,
},
.num_resources = ARRAY_SIZE(sh_eth0_resources),
.resource = sh_eth0_resources,
@@ -155,7 +161,7 @@ static struct platform_device sh_eth1_de
.name = "sh771x-ether",
.id = 1,
.dev = {
- .platform_data = PHY_ID,
+ .platform_data = &sh_eth_plat,
},
.num_resources = ARRAY_SIZE(sh_eth1_resources),
.resource = sh_eth1_resources,
Patches currently in stable-queue which might be from sergei.shtylyov(a)cogentembedded.com are
queue-4.14/solutionengine771x-fix-ether-platform-data.patch
This is a note to let you know that I've just added the patch titled
sctp: make use of pre-calculated len
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:
sctp-make-use-of-pre-calculated-len.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 28 16:23:28 CET 2018
From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Date: Mon, 8 Jan 2018 19:02:29 -0200
Subject: sctp: make use of pre-calculated len
From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
[ Upstream commit c76f97c99ae6d26d14c7f0e50e074382bfbc9f98 ]
Some sockopt handling functions were calculating the length of the
buffer to be written to userspace and then calculating it again when
actually writing the buffer, which could lead to some write not using
an up-to-date length.
This patch updates such places to just make use of the len variable.
Also, replace some sizeof(type) to sizeof(var).
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/socket.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -4957,7 +4957,7 @@ static int sctp_getsockopt_autoclose(str
len = sizeof(int);
if (put_user(len, optlen))
return -EFAULT;
- if (copy_to_user(optval, &sctp_sk(sk)->autoclose, sizeof(int)))
+ if (copy_to_user(optval, &sctp_sk(sk)->autoclose, len))
return -EFAULT;
return 0;
}
@@ -5588,6 +5588,9 @@ copy_getaddrs:
err = -EFAULT;
goto out;
}
+ /* XXX: We should have accounted for sizeof(struct sctp_getaddrs) too,
+ * but we can't change it anymore.
+ */
if (put_user(bytes_copied, optlen))
err = -EFAULT;
out:
@@ -6024,7 +6027,7 @@ static int sctp_getsockopt_maxseg(struct
params.assoc_id = 0;
} else if (len >= sizeof(struct sctp_assoc_value)) {
len = sizeof(struct sctp_assoc_value);
- if (copy_from_user(¶ms, optval, sizeof(params)))
+ if (copy_from_user(¶ms, optval, len))
return -EFAULT;
} else
return -EINVAL;
@@ -6194,7 +6197,9 @@ static int sctp_getsockopt_active_key(st
if (len < sizeof(struct sctp_authkeyid))
return -EINVAL;
- if (copy_from_user(&val, optval, sizeof(struct sctp_authkeyid)))
+
+ len = sizeof(struct sctp_authkeyid);
+ if (copy_from_user(&val, optval, len))
return -EFAULT;
asoc = sctp_id2assoc(sk, val.scact_assoc_id);
@@ -6206,7 +6211,6 @@ static int sctp_getsockopt_active_key(st
else
val.scact_keynumber = ep->active_key_id;
- len = sizeof(struct sctp_authkeyid);
if (put_user(len, optlen))
return -EFAULT;
if (copy_to_user(optval, &val, len))
@@ -6232,7 +6236,7 @@ static int sctp_getsockopt_peer_auth_chu
if (len < sizeof(struct sctp_authchunks))
return -EINVAL;
- if (copy_from_user(&val, optval, sizeof(struct sctp_authchunks)))
+ if (copy_from_user(&val, optval, sizeof(val)))
return -EFAULT;
to = p->gauth_chunks;
@@ -6277,7 +6281,7 @@ static int sctp_getsockopt_local_auth_ch
if (len < sizeof(struct sctp_authchunks))
return -EINVAL;
- if (copy_from_user(&val, optval, sizeof(struct sctp_authchunks)))
+ if (copy_from_user(&val, optval, sizeof(val)))
return -EFAULT;
to = p->gauth_chunks;
Patches currently in stable-queue which might be from marcelo.leitner(a)gmail.com are
queue-4.14/sctp-make-use-of-pre-calculated-len.patch
queue-4.14/sctp-add-a-ceiling-to-optlen-in-some-sockopts.patch
queue-4.14/sctp-fix-the-issue-that-a-__u16-variable-may-overflow-in-sctp_ulpq_renege.patch
This is a note to let you know that I've just added the patch titled
sget(): handle failures of register_shrinker()
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:
sget-handle-failures-of-register_shrinker.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 28 16:23:28 CET 2018
From: Al Viro <viro(a)zeniv.linux.org.uk>
Date: Mon, 18 Dec 2017 15:05:07 -0500
Subject: sget(): handle failures of register_shrinker()
From: Al Viro <viro(a)zeniv.linux.org.uk>
[ Upstream commit 9ee332d99e4d5a97548943b81c54668450ce641b ]
Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/super.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/fs/super.c
+++ b/fs/super.c
@@ -522,7 +522,11 @@ retry:
hlist_add_head(&s->s_instances, &type->fs_supers);
spin_unlock(&sb_lock);
get_filesystem(type);
- register_shrinker(&s->s_shrink);
+ err = register_shrinker(&s->s_shrink);
+ if (err) {
+ deactivate_locked_super(s);
+ s = ERR_PTR(err);
+ }
return s;
}
Patches currently in stable-queue which might be from viro(a)zeniv.linux.org.uk are
queue-4.14/afs-fix-missing-error-handling-in-afs_write_end.patch
queue-4.14/exec-avoid-gcc-8-warning-for-get_task_comm.patch
queue-4.14/sget-handle-failures-of-register_shrinker.patch
This is a note to let you know that I've just added the patch titled
sctp: fix the issue that a __u16 variable may overflow in sctp_ulpq_renege
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:
sctp-fix-the-issue-that-a-__u16-variable-may-overflow-in-sctp_ulpq_renege.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 28 16:23:28 CET 2018
From: Xin Long <lucien.xin(a)gmail.com>
Date: Mon, 18 Dec 2017 14:07:25 +0800
Subject: sctp: fix the issue that a __u16 variable may overflow in sctp_ulpq_renege
From: Xin Long <lucien.xin(a)gmail.com>
[ Upstream commit 5c468674d17056148da06218d4da5d04baf22eac ]
Now when reneging events in sctp_ulpq_renege(), the variable freed
could be increased by a __u16 value twice while freed is of __u16
type. It means freed may overflow at the second addition.
This patch is to fix it by using __u32 type for 'freed', while at
it, also to remove 'if (chunk)' check, as all renege commands are
generated in sctp_eat_data and it can't be NULL.
Reported-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: Xin Long <lucien.xin(a)gmail.com>
Acked-by: Neil Horman <nhorman(a)tuxdriver.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/ulpqueue.c | 24 ++++++++----------------
1 file changed, 8 insertions(+), 16 deletions(-)
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -1084,29 +1084,21 @@ void sctp_ulpq_partial_delivery(struct s
void sctp_ulpq_renege(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk,
gfp_t gfp)
{
- struct sctp_association *asoc;
- __u16 needed, freed;
+ struct sctp_association *asoc = ulpq->asoc;
+ __u32 freed = 0;
+ __u16 needed;
- asoc = ulpq->asoc;
-
- if (chunk) {
- needed = ntohs(chunk->chunk_hdr->length);
- needed -= sizeof(struct sctp_data_chunk);
- } else
- needed = SCTP_DEFAULT_MAXWINDOW;
-
- freed = 0;
+ needed = ntohs(chunk->chunk_hdr->length) -
+ sizeof(struct sctp_data_chunk);
if (skb_queue_empty(&asoc->base.sk->sk_receive_queue)) {
freed = sctp_ulpq_renege_order(ulpq, needed);
- if (freed < needed) {
+ if (freed < needed)
freed += sctp_ulpq_renege_frags(ulpq, needed - freed);
- }
}
/* If able to free enough room, accept this chunk. */
- if (chunk && (freed >= needed)) {
- int retval;
- retval = sctp_ulpq_tail_data(ulpq, chunk, gfp);
+ if (freed >= needed) {
+ int retval = sctp_ulpq_tail_data(ulpq, chunk, gfp);
/*
* Enter partial delivery if chunk has not been
* delivered; otherwise, drain the reassembly queue.
Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are
queue-4.14/ip_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.patch
queue-4.14/ip6_gre-remove-the-incorrect-mtu-limit-for-ipgre-tap.patch
queue-4.14/ip6_tunnel-allow-ip6gre-dev-mtu-to-be-set-below-1280.patch
queue-4.14/vxlan-update-skb-dst-pmtu-on-tx-path.patch
queue-4.14/ip6_tunnel-get-the-min-mtu-properly-in-ip6_tnl_xmit.patch
queue-4.14/sctp-fix-the-issue-that-a-__u16-variable-may-overflow-in-sctp_ulpq_renege.patch
This is a note to let you know that I've just added the patch titled
sctp: add a ceiling to optlen in some sockopts
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:
sctp-add-a-ceiling-to-optlen-in-some-sockopts.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 28 16:23:28 CET 2018
From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Date: Mon, 8 Jan 2018 19:02:28 -0200
Subject: sctp: add a ceiling to optlen in some sockopts
From: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
[ Upstream commit 5960cefab9df76600a1a7d4ff592c59e14616e88 ]
Hangbin Liu reported that some sockopt calls could cause the kernel to log
a warning on memory allocation failure if the user supplied a large optlen
value. That is because some of them called memdup_user() without a ceiling
on optlen, allowing it to try to allocate really large buffers.
This patch adds a ceiling by limiting optlen to the maximum allowed that
would still make sense for these sockopt.
Reported-by: Hangbin Liu <haliu(a)redhat.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/sctp/socket.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -3494,6 +3494,8 @@ static int sctp_setsockopt_hmac_ident(st
if (optlen < sizeof(struct sctp_hmacalgo))
return -EINVAL;
+ optlen = min_t(unsigned int, optlen, sizeof(struct sctp_hmacalgo) +
+ SCTP_AUTH_NUM_HMACS * sizeof(u16));
hmacs = memdup_user(optval, optlen);
if (IS_ERR(hmacs))
@@ -3532,6 +3534,11 @@ static int sctp_setsockopt_auth_key(stru
if (optlen <= sizeof(struct sctp_authkey))
return -EINVAL;
+ /* authkey->sca_keylength is u16, so optlen can't be bigger than
+ * this.
+ */
+ optlen = min_t(unsigned int, optlen, USHRT_MAX +
+ sizeof(struct sctp_authkey));
authkey = memdup_user(optval, optlen);
if (IS_ERR(authkey))
@@ -3889,6 +3896,9 @@ static int sctp_setsockopt_reset_streams
if (optlen < sizeof(*params))
return -EINVAL;
+ /* srs_number_streams is u16, so optlen can't be bigger than this. */
+ optlen = min_t(unsigned int, optlen, USHRT_MAX +
+ sizeof(__u16) * sizeof(*params));
params = memdup_user(optval, optlen);
if (IS_ERR(params))
Patches currently in stable-queue which might be from marcelo.leitner(a)gmail.com are
queue-4.14/sctp-make-use-of-pre-calculated-len.patch
queue-4.14/sctp-add-a-ceiling-to-optlen-in-some-sockopts.patch
queue-4.14/sctp-fix-the-issue-that-a-__u16-variable-may-overflow-in-sctp_ulpq_renege.patch
This is a note to let you know that I've just added the patch titled
scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error
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:
scsi-storvsc-fix-scsi_cmd-error-assignments-in-storvsc_handle_error.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 28 16:23:28 CET 2018
From: Cathy Avery <cavery(a)redhat.com>
Date: Tue, 19 Dec 2017 13:32:48 -0500
Subject: scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error
From: Cathy Avery <cavery(a)redhat.com>
[ Upstream commit d1b8b2391c24751e44f618fcf86fb55d9a9247fd ]
When an I/O is returned with an srb_status of SRB_STATUS_INVALID_LUN
which has zero good_bytes it must be assigned an error. Otherwise the
I/O will be continuously requeued and will cause a deadlock in the case
where disks are being hot added and removed. sd_probe_async will wait
forever for its I/O to complete while holding scsi_sd_probe_domain.
Also returning the default error of DID_TARGET_FAILURE causes multipath
to not retry the I/O resulting in applications receiving I/O errors
before a failover can occur.
Signed-off-by: Cathy Avery <cavery(a)redhat.com>
Signed-off-by: Long Li <longli(a)microsoft.com>
Reviewed-by: Stephen Hemminger <stephen(a)networkplumber.org>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/storvsc_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -952,10 +952,11 @@ static void storvsc_handle_error(struct
case TEST_UNIT_READY:
break;
default:
- set_host_byte(scmnd, DID_TARGET_FAILURE);
+ set_host_byte(scmnd, DID_ERROR);
}
break;
case SRB_STATUS_INVALID_LUN:
+ set_host_byte(scmnd, DID_NO_CONNECT);
do_work = true;
process_err_fn = storvsc_remove_lun;
break;
Patches currently in stable-queue which might be from cavery(a)redhat.com are
queue-4.14/scsi-storvsc-fix-scsi_cmd-error-assignments-in-storvsc_handle_error.patch
This is a note to let you know that I've just added the patch titled
scsi: aacraid: Fix I/O drop during reset
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:
scsi-aacraid-fix-i-o-drop-during-reset.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 28 16:23:28 CET 2018
From: Prasad B Munirathnam <prasad.munirathnam(a)microsemi.com>
Date: Tue, 12 Dec 2017 11:40:10 -0800
Subject: scsi: aacraid: Fix I/O drop during reset
From: Prasad B Munirathnam <prasad.munirathnam(a)microsemi.com>
[ Upstream commit 5771cfffdffe709ae9b403b6f80438ca40bf850e ]
"FIB_CONTEXT_FLAG_TIMEDOUT" flag is set in aac_eh_abort to indicate
command timeout. Using the same flag in reset handler causes the command
to time out and the I/Os were dropped.
Define a new flag "FIB_CONTEXT_FLAG_EH_RESET" to make sure I/O is
properly handled in eh_reset handler.
[mkp: tweaked commit message]
Signed-off-by: Prasad B Munirathnam <prasad.munirathnam(a)microsemi.com>
Reviewed-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta(a)microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/aacraid/aacraid.h | 1 +
drivers/scsi/aacraid/linit.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/scsi/aacraid/aacraid.h
+++ b/drivers/scsi/aacraid/aacraid.h
@@ -1724,6 +1724,7 @@ struct aac_dev
#define FIB_CONTEXT_FLAG_NATIVE_HBA (0x00000010)
#define FIB_CONTEXT_FLAG_NATIVE_HBA_TMF (0x00000020)
#define FIB_CONTEXT_FLAG_SCSI_CMD (0x00000040)
+#define FIB_CONTEXT_FLAG_EH_RESET (0x00000080)
/*
* Define the command values
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -1037,7 +1037,7 @@ static int aac_eh_bus_reset(struct scsi_
info = &aac->hba_map[bus][cid];
if (bus >= AAC_MAX_BUSES || cid >= AAC_MAX_TARGETS ||
info->devtype != AAC_DEVTYPE_NATIVE_RAW) {
- fib->flags |= FIB_CONTEXT_FLAG_TIMED_OUT;
+ fib->flags |= FIB_CONTEXT_FLAG_EH_RESET;
cmd->SCp.phase = AAC_OWNER_ERROR_HANDLER;
}
}
Patches currently in stable-queue which might be from prasad.munirathnam(a)microsemi.com are
queue-4.14/scsi-aacraid-fix-i-o-drop-during-reset.patch
This is a note to let you know that I've just added the patch titled
s390/dasd: fix wrongly assigned configuration data
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:
s390-dasd-fix-wrongly-assigned-configuration-data.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 28 16:23:28 CET 2018
From: Stefan Haberland <sth(a)linux.vnet.ibm.com>
Date: Wed, 6 Dec 2017 10:30:39 +0100
Subject: s390/dasd: fix wrongly assigned configuration data
From: Stefan Haberland <sth(a)linux.vnet.ibm.com>
[ Upstream commit 8a9bd4f8ebc6800bfc0596e28631ff6809a2f615 ]
We store per path and per device configuration data to identify the
path or device correctly. The per path configuration data might get
mixed up if the original request gets into error recovery and is
started with a random path mask.
This would lead to a wrong identification of a path in case of a CUIR
event for example.
Fix by copying the path mask from the original request to the error
recovery request in case it is a path verification request.
Signed-off-by: Stefan Haberland <sth(a)linux.vnet.ibm.com>
Reviewed-by: Jan Hoeppner <hoeppner(a)linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/s390/block/dasd_3990_erp.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/drivers/s390/block/dasd_3990_erp.c
+++ b/drivers/s390/block/dasd_3990_erp.c
@@ -2803,6 +2803,16 @@ dasd_3990_erp_action(struct dasd_ccw_req
erp = dasd_3990_erp_handle_match_erp(cqr, erp);
}
+
+ /*
+ * For path verification work we need to stick with the path that was
+ * originally chosen so that the per path configuration data is
+ * assigned correctly.
+ */
+ if (test_bit(DASD_CQR_VERIFY_PATH, &erp->flags) && cqr->lpm) {
+ erp->lpm = cqr->lpm;
+ }
+
if (device->features & DASD_FEATURE_ERPLOG) {
/* print current erp_chain */
dev_err(&device->cdev->dev,
Patches currently in stable-queue which might be from sth(a)linux.vnet.ibm.com are
queue-4.14/s390-dasd-fix-wrongly-assigned-configuration-data.patch
This is a note to let you know that I've just added the patch titled
RDMA/vmw_pvrdma: Call ib_umem_release on destroy QP path
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:
rdma-vmw_pvrdma-call-ib_umem_release-on-destroy-qp-path.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 28 16:23:28 CET 2018
From: Bryan Tan <bryantan(a)vmware.com>
Date: Wed, 20 Dec 2017 09:49:03 -0800
Subject: RDMA/vmw_pvrdma: Call ib_umem_release on destroy QP path
From: Bryan Tan <bryantan(a)vmware.com>
[ Upstream commit 17748056ce123ee37fb7382bc698fc721e3c4a09 ]
The QP cleanup did not previously call ib_umem_release,
resulting in a user-triggerable kernel resource leak.
Fixes: 29c8d9eba550 ("IB: Add vmw_pvrdma driver")
Reviewed-by: Adit Ranadive <aditr(a)vmware.com>
Reviewed-by: Aditya Sarwade <asarwade(a)vmware.com>
Reviewed-by: Jorgen Hansen <jhansen(a)vmware.com>
Signed-off-by: Bryan Tan <bryantan(a)vmware.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c
+++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_qp.c
@@ -406,6 +406,13 @@ static void pvrdma_free_qp(struct pvrdma
atomic_dec(&qp->refcnt);
wait_event(qp->wait, !atomic_read(&qp->refcnt));
+ if (!qp->is_kernel) {
+ if (qp->rumem)
+ ib_umem_release(qp->rumem);
+ if (qp->sumem)
+ ib_umem_release(qp->sumem);
+ }
+
pvrdma_page_dir_cleanup(dev, &qp->pdir);
kfree(qp);
Patches currently in stable-queue which might be from bryantan(a)vmware.com are
queue-4.14/rdma-vmw_pvrdma-call-ib_umem_release-on-destroy-qp-path.patch
This is a note to let you know that I've just added the patch titled
phy: cpcap-usb: Fix platform_get_irq_byname's error checking.
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:
phy-cpcap-usb-fix-platform_get_irq_byname-s-error-checking.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 28 16:23:28 CET 2018
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Fri, 17 Nov 2017 16:55:35 +0530
Subject: phy: cpcap-usb: Fix platform_get_irq_byname's error checking.
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
[ Upstream commit e796cc6a3a9186c92092e2f5929cf8f65b56cf01 ]
The platform_get_irq_byname() function returns negative if an error occurs.
zero or positive number on success. platform_get_irq_byname() error
checking for zero is not correct.
Fixes: 6d6ce40f63af ("phy: cpcap-usb: Add CPCAP PMIC USB support")
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel(a)collabora.co.uk>
Acked-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/phy/motorola/phy-cpcap-usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/phy/motorola/phy-cpcap-usb.c
+++ b/drivers/phy/motorola/phy-cpcap-usb.c
@@ -310,7 +310,7 @@ static int cpcap_usb_init_irq(struct pla
int irq, error;
irq = platform_get_irq_byname(pdev, name);
- if (!irq)
+ if (irq < 0)
return -ENODEV;
error = devm_request_threaded_irq(ddata->dev, irq, NULL,
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.14/phy-cpcap-usb-fix-platform_get_irq_byname-s-error-checking.patch
This is a note to let you know that I've just added the patch titled
perf/x86/intel: Plug memory leak in intel_pmu_init()
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:
perf-x86-intel-plug-memory-leak-in-intel_pmu_init.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 28 16:23:28 CET 2018
From: Thomas Gleixner <tglx(a)linutronix.de>
Date: Wed, 27 Dec 2017 19:45:31 +0100
Subject: perf/x86/intel: Plug memory leak in intel_pmu_init()
From: Thomas Gleixner <tglx(a)linutronix.de>
[ Upstream commit 7ad1437d6ace0e450a6c1167720608ad660b191d ]
A recent commit introduced an extra merge_attr() call in the skylake
branch, which causes a memory leak.
Store the pointer to the extra allocated memory and free it at the end of
the function.
Fixes: a5df70c354c2 ("perf/x86: Only show format attributes when supported")
Reported-by: Tommi Rantala <tommi.t.rantala(a)nokia.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Andi Kleen <ak(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/events/intel/core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -3847,6 +3847,8 @@ static struct attribute *intel_pmu_attrs
__init int intel_pmu_init(void)
{
+ struct attribute **extra_attr = NULL;
+ struct attribute **to_free = NULL;
union cpuid10_edx edx;
union cpuid10_eax eax;
union cpuid10_ebx ebx;
@@ -3854,7 +3856,6 @@ __init int intel_pmu_init(void)
unsigned int unused;
struct extra_reg *er;
int version, i;
- struct attribute **extra_attr = NULL;
char *name;
if (!cpu_has(&boot_cpu_data, X86_FEATURE_ARCH_PERFMON)) {
@@ -4294,6 +4295,7 @@ __init int intel_pmu_init(void)
extra_attr = boot_cpu_has(X86_FEATURE_RTM) ?
hsw_format_attr : nhm_format_attr;
extra_attr = merge_attr(extra_attr, skl_format_attr);
+ to_free = extra_attr;
x86_pmu.cpu_events = get_hsw_events_attrs();
intel_pmu_pebs_data_source_skl(
boot_cpu_data.x86_model == INTEL_FAM6_SKYLAKE_X);
@@ -4401,6 +4403,7 @@ __init int intel_pmu_init(void)
pr_cont("full-width counters, ");
}
+ kfree(to_free);
return 0;
}
Patches currently in stable-queue which might be from tglx(a)linutronix.de are
queue-4.14/exec-avoid-gcc-8-warning-for-get_task_comm.patch
queue-4.14/perf-x86-intel-plug-memory-leak-in-intel_pmu_init.patch
queue-4.14/x86-efi-fix-kernel-param-add_efi_memmap-regression.patch
queue-4.14/x86-platform-intel-mid-revert-make-bt_sfi_data-const.patch
queue-4.14/x86-asm-allow-again-using-asm.h-when-building-for-the-bpf-clang-target.patch
queue-4.14/x86-stacktrace-make-zombie-stack-traces-reliable.patch
queue-4.14/ia64-sched-cputime-fix-build-error-if-config_virt_cpu_accounting_native-y.patch
queue-4.14/genirq-guard-handle_bad_irq-log-messages.patch
queue-4.14/hrtimer-ensure-posix-compliance-relative-clock_realtime-hrtimers.patch
This is a note to let you know that I've just added the patch titled
parisc: Reduce thread stack to 16 kb
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:
parisc-reduce-thread-stack-to-16-kb.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 28 16:23:28 CET 2018
From: John David Anglin <dave.anglin(a)bell.net>
Date: Mon, 13 Nov 2017 19:35:33 -0500
Subject: parisc: Reduce thread stack to 16 kb
From: John David Anglin <dave.anglin(a)bell.net>
[ Upstream commit da57c5414f49ef9e4bcb9ae0bbafd1d650b31411 ]
In testing, I found that the thread stack can be 16 kB when using an irq
stack. Without it, the thread stack needs to be 32 kB. Currently, the irq
stack is 32 kB. While it probably could be 16 kB, I would prefer to leave it
as is for safety.
Signed-off-by: John David Anglin <dave.anglin(a)bell.net>
Signed-off-by: Helge Deller <deller(a)gmx.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/parisc/include/asm/thread_info.h | 5 +++++
1 file changed, 5 insertions(+)
--- a/arch/parisc/include/asm/thread_info.h
+++ b/arch/parisc/include/asm/thread_info.h
@@ -35,7 +35,12 @@ struct thread_info {
/* thread information allocation */
+#ifdef CONFIG_IRQSTACKS
+#define THREAD_SIZE_ORDER 2 /* PA-RISC requires at least 16k stack */
+#else
#define THREAD_SIZE_ORDER 3 /* PA-RISC requires at least 32k stack */
+#endif
+
/* Be sure to hunt all references to this down when you change the size of
* the kernel stack */
#define THREAD_SIZE (PAGE_SIZE << THREAD_SIZE_ORDER)
Patches currently in stable-queue which might be from dave.anglin(a)bell.net are
queue-4.14/parisc-reduce-thread-stack-to-16-kb.patch
This is a note to let you know that I've just added the patch titled
of_mdio: avoid MDIO bus removal when a PHY is missing
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:
of_mdio-avoid-mdio-bus-removal-when-a-phy-is-missing.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 28 16:23:28 CET 2018
From: Madalin Bucur <madalin.bucur(a)nxp.com>
Date: Tue, 9 Jan 2018 14:43:34 +0200
Subject: of_mdio: avoid MDIO bus removal when a PHY is missing
From: Madalin Bucur <madalin.bucur(a)nxp.com>
[ Upstream commit 95f566de0269a0c59fd6a737a147731302136429 ]
If one of the child devices is missing the of_mdiobus_register_phy()
call will return -ENODEV. When a missing device is encountered the
registration of the remaining PHYs is stopped and the MDIO bus will
fail to register. Propagate all errors except ENODEV to avoid it.
Signed-off-by: Madalin Bucur <madalin.bucur(a)nxp.com>
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/of/of_mdio.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -228,7 +228,12 @@ int of_mdiobus_register(struct mii_bus *
rc = of_mdiobus_register_phy(mdio, child, addr);
else
rc = of_mdiobus_register_device(mdio, child, addr);
- if (rc)
+
+ if (rc == -ENODEV)
+ dev_err(&mdio->dev,
+ "MDIO device at address %d is missing.\n",
+ addr);
+ else if (rc)
goto unregister;
}
@@ -252,7 +257,7 @@ int of_mdiobus_register(struct mii_bus *
if (of_mdiobus_child_is_phy(child)) {
rc = of_mdiobus_register_phy(mdio, child, addr);
- if (rc)
+ if (rc && rc != -ENODEV)
goto unregister;
}
}
Patches currently in stable-queue which might be from madalin.bucur(a)nxp.com are
queue-4.14/of_mdio-avoid-mdio-bus-removal-when-a-phy-is-missing.patch
This is a note to let you know that I've just added the patch titled
nvme-fc: remove double put reference if admin connect fails
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:
nvme-fc-remove-double-put-reference-if-admin-connect-fails.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 28 16:23:28 CET 2018
From: James Smart <jsmart2021(a)gmail.com>
Date: Wed, 29 Nov 2017 15:11:37 -0800
Subject: nvme-fc: remove double put reference if admin connect fails
From: James Smart <jsmart2021(a)gmail.com>
[ Upstream commit 4596e752db02d47038cd7c965419789ab15d1985 ]
There are two put references in the failure case of initial
create_association. The first put actually frees the controller, thus the
second put references freed memory.
Remove the unnecessary 2nd put.
Signed-off-by: James Smart <james.smart(a)broadcom.com>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nvme/host/fc.c | 1 -
1 file changed, 1 deletion(-)
--- a/drivers/nvme/host/fc.c
+++ b/drivers/nvme/host/fc.c
@@ -2876,7 +2876,6 @@ nvme_fc_init_ctrl(struct device *dev, st
/* initiate nvme ctrl ref counting teardown */
nvme_uninit_ctrl(&ctrl->ctrl);
- nvme_put_ctrl(&ctrl->ctrl);
/* Remove core ctrl ref. */
nvme_put_ctrl(&ctrl->ctrl);
Patches currently in stable-queue which might be from jsmart2021(a)gmail.com are
queue-4.14/nvme-fc-remove-double-put-reference-if-admin-connect-fails.patch
This is a note to let you know that I've just added the patch titled
nvme: check hw sectors before setting chunk sectors
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:
nvme-check-hw-sectors-before-setting-chunk-sectors.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 28 16:23:28 CET 2018
From: Keith Busch <keith.busch(a)intel.com>
Date: Thu, 14 Dec 2017 11:20:14 -0700
Subject: nvme: check hw sectors before setting chunk sectors
From: Keith Busch <keith.busch(a)intel.com>
[ Upstream commit 249159c5f15812140fa216f9997d799ac0023a1f ]
Some devices with IDs matching the "stripe" quirk don't actually have
this quirk, and don't have an MDTS value. When MDTS is not set, the
driver sets the max sectors to UINT_MAX, which is not a power of 2,
hitting a BUG_ON from blk_queue_chunk_sectors. This patch skips setting
chunk sectors for such devices.
Signed-off-by: Keith Busch <keith.busch(a)intel.com>
Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nvme/host/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -1515,7 +1515,8 @@ static void nvme_set_queue_limits(struct
blk_queue_max_hw_sectors(q, ctrl->max_hw_sectors);
blk_queue_max_segments(q, min_t(u32, max_segments, USHRT_MAX));
}
- if (ctrl->quirks & NVME_QUIRK_STRIPE_SIZE)
+ if ((ctrl->quirks & NVME_QUIRK_STRIPE_SIZE) &&
+ is_power_of_2(ctrl->max_hw_sectors))
blk_queue_chunk_sectors(q, ctrl->max_hw_sectors);
blk_queue_virt_boundary(q, ctrl->page_size - 1);
if (ctrl->vwc & NVME_CTRL_VWC_PRESENT)
Patches currently in stable-queue which might be from keith.busch(a)intel.com are
queue-4.14/nvme-check-hw-sectors-before-setting-chunk-sectors.patch
This is a note to let you know that I've just added the patch titled
nvme-fabrics: initialize default host->id in nvmf_host_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:
nvme-fabrics-initialize-default-host-id-in-nvmf_host_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 foo@baz Wed Feb 28 16:23:28 CET 2018
From: "Ewan D. Milne" <emilne(a)redhat.com>
Date: Fri, 5 Jan 2018 12:44:06 -0500
Subject: nvme-fabrics: initialize default host->id in nvmf_host_default()
From: "Ewan D. Milne" <emilne(a)redhat.com>
[ Upstream commit 6b018235b4daabae96d855219fae59c3fb8be417 ]
The field was uninitialized before use.
Signed-off-by: Ewan D. Milne <emilne(a)redhat.com>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nvme/host/fabrics.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/nvme/host/fabrics.c
+++ b/drivers/nvme/host/fabrics.c
@@ -74,6 +74,7 @@ static struct nvmf_host *nvmf_host_defau
return NULL;
kref_init(&host->ref);
+ uuid_gen(&host->id);
snprintf(host->nqn, NVMF_NQN_SIZE,
"nqn.2014-08.org.nvmexpress:uuid:%pUb", &host->id);
Patches currently in stable-queue which might be from emilne(a)redhat.com are
queue-4.14/nvme-fabrics-initialize-default-host-id-in-nvmf_host_default.patch
This is a note to let you know that I've just added the patch titled
nl80211: Check for the required netlink attribute presence
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:
nl80211-check-for-the-required-netlink-attribute-presence.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 28 16:23:28 CET 2018
From: Hao Chen <flank3rsky(a)gmail.com>
Date: Wed, 3 Jan 2018 11:00:31 +0800
Subject: nl80211: Check for the required netlink attribute presence
From: Hao Chen <flank3rsky(a)gmail.com>
[ Upstream commit 3ea15452ee85754f70f3b9fa1f23165ef2e77ba7 ]
nl80211_nan_add_func() does not check if the required attribute
NL80211_NAN_FUNC_FOLLOW_UP_DEST is present when processing
NL80211_CMD_ADD_NAN_FUNCTION request. This request can be issued
by users with CAP_NET_ADMIN privilege and may result in NULL dereference
and a system crash. Add a check for the required attribute presence.
Signed-off-by: Hao Chen <flank3rsky(a)gmail.com>
Signed-off-by: Johannes Berg <johannes.berg(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/wireless/nl80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -11301,7 +11301,8 @@ static int nl80211_nan_add_func(struct s
break;
case NL80211_NAN_FUNC_FOLLOW_UP:
if (!tb[NL80211_NAN_FUNC_FOLLOW_UP_ID] ||
- !tb[NL80211_NAN_FUNC_FOLLOW_UP_REQ_ID]) {
+ !tb[NL80211_NAN_FUNC_FOLLOW_UP_REQ_ID] ||
+ !tb[NL80211_NAN_FUNC_FOLLOW_UP_DEST]) {
err = -EINVAL;
goto out;
}
Patches currently in stable-queue which might be from flank3rsky(a)gmail.com are
queue-4.14/nl80211-check-for-the-required-netlink-attribute-presence.patch
This is a note to let you know that I've just added the patch titled
nfp: always unmask aux interrupts at init
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:
nfp-always-unmask-aux-interrupts-at-init.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 28 16:23:28 CET 2018
From: Jakub Kicinski <jakub.kicinski(a)netronome.com>
Date: Tue, 9 Jan 2018 18:14:28 -0800
Subject: nfp: always unmask aux interrupts at init
From: Jakub Kicinski <jakub.kicinski(a)netronome.com>
[ Upstream commit fc2336505fb49a8b932a0a67a9745c408b79992c ]
The link state and exception interrupts may be masked when we probe.
The firmware should in theory prevent sending (and automasking) those
interrupts if the device is disabled, but if my reading of the FW code
is correct there are firmwares out there with race conditions in this
area. The interrupt may also be masked if previous driver which used
the device was malfunctioning and we didn't load the FW (there is no
other good way to comprehensively reset the PF).
Note that FW unmasks the data interrupts by itself when vNIC is
enabled, such helpful operation is not performed for LSC/EXN interrupts.
Always unmask the auxiliary interrupts after request_irq(). On the
remove path add missing PCI write flush before free_irq().
Fixes: 4c3523623dc0 ("net: add driver for Netronome NFP4000/NFP6000 NIC VFs")
Signed-off-by: Jakub Kicinski <jakub.kicinski(a)netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe(a)netronome.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -568,6 +568,7 @@ nfp_net_aux_irq_request(struct nfp_net *
return err;
}
nn_writeb(nn, ctrl_offset, entry->entry);
+ nfp_net_irq_unmask(nn, entry->entry);
return 0;
}
@@ -582,6 +583,7 @@ static void nfp_net_aux_irq_free(struct
unsigned int vector_idx)
{
nn_writeb(nn, ctrl_offset, 0xff);
+ nn_pci_flush(nn);
free_irq(nn->irq_entries[vector_idx].vector, nn);
}
Patches currently in stable-queue which might be from jakub.kicinski(a)netronome.com are
queue-4.14/nfp-always-unmask-aux-interrupts-at-init.patch
This is a note to let you know that I've just added the patch titled
netfilter: uapi: correct UNTRACKED conntrack state bit number
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:
netfilter-uapi-correct-untracked-conntrack-state-bit-number.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 28 16:23:28 CET 2018
From: Florian Westphal <fw(a)strlen.de>
Date: Wed, 20 Dec 2017 12:08:33 +0100
Subject: netfilter: uapi: correct UNTRACKED conntrack state bit number
From: Florian Westphal <fw(a)strlen.de>
[ Upstream commit 4c82fd0abb87e20d0d68ef5237e74732352806c8 ]
nft_ct exposes this bit to userspace. This used to be
#define NF_CT_STATE_UNTRACKED_BIT (1 << (IP_CT_NUMBER + 1))
(IP_CT_NUMBER is 5, so this was 0x40)
.. but this got changed to 8 (0x100) when the untracked object got removed.
Replace this with a literal 6 to prevent further incompatible changes
in case IP_CT_NUMBER ever increases.
Fixes: cc41c84b7e7f2 ("netfilter: kill the fake untracked conntrack objects")
Reported-by: Li Shuang <shuali(a)redhat.com>
Signed-off-by: Florian Westphal <fw(a)strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/uapi/linux/netfilter/nf_conntrack_common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/uapi/linux/netfilter/nf_conntrack_common.h
+++ b/include/uapi/linux/netfilter/nf_conntrack_common.h
@@ -36,7 +36,7 @@ enum ip_conntrack_info {
#define NF_CT_STATE_INVALID_BIT (1 << 0)
#define NF_CT_STATE_BIT(ctinfo) (1 << ((ctinfo) % IP_CT_IS_REPLY + 1))
-#define NF_CT_STATE_UNTRACKED_BIT (1 << (IP_CT_UNTRACKED + 1))
+#define NF_CT_STATE_UNTRACKED_BIT (1 << 6)
/* Bitset representing status of connection. */
enum ip_conntrack_status {
Patches currently in stable-queue which might be from fw(a)strlen.de are
queue-4.14/netfilter-uapi-correct-untracked-conntrack-state-bit-number.patch
This is a note to let you know that I've just added the patch titled
netfilter: nf_tables: fix potential NULL-ptr deref in nf_tables_dump_obj_done()
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:
netfilter-nf_tables-fix-potential-null-ptr-deref-in-nf_tables_dump_obj_done.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 28 16:23:28 CET 2018
From: Hangbin Liu <liuhangbin(a)gmail.com>
Date: Mon, 25 Dec 2017 11:34:54 +0800
Subject: netfilter: nf_tables: fix potential NULL-ptr deref in nf_tables_dump_obj_done()
From: Hangbin Liu <liuhangbin(a)gmail.com>
[ Upstream commit 8bea728dce8972e534e6b99fd550f7b5cc3864e8 ]
If there is no NFTA_OBJ_TABLE and NFTA_OBJ_TYPE, the c.data will be NULL in
nf_tables_getobj(). So before free filter->table in nf_tables_dump_obj_done(),
we need to check if filter is NULL first.
Fixes: e46abbcc05aa ("netfilter: nf_tables: Allow table names of up to 255 chars")
Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com>
Acked-by: Phil Sutter <phil(a)nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/nf_tables_api.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -4596,8 +4596,10 @@ static int nf_tables_dump_obj_done(struc
{
struct nft_obj_filter *filter = cb->data;
- kfree(filter->table);
- kfree(filter);
+ if (filter) {
+ kfree(filter->table);
+ kfree(filter);
+ }
return 0;
}
Patches currently in stable-queue which might be from liuhangbin(a)gmail.com are
queue-4.14/netfilter-nf_tables-fix-potential-null-ptr-deref-in-nf_tables_dump_obj_done.patch
This is a note to let you know that I've just added the patch titled
netfilter: nf_tables: fix chain filter in nf_tables_dump_rules()
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:
netfilter-nf_tables-fix-chain-filter-in-nf_tables_dump_rules.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 28 16:23:28 CET 2018
From: Pablo Neira Ayuso <pablo(a)netfilter.org>
Date: Tue, 19 Dec 2017 12:01:21 +0100
Subject: netfilter: nf_tables: fix chain filter in nf_tables_dump_rules()
From: Pablo Neira Ayuso <pablo(a)netfilter.org>
[ Upstream commit 24c0df82ef7919e4d10cf2e4e65d368eb2e8ea21 ]
ctx->chain may be null now that we have very large object names,
so we cannot check for ctx->chain[0] here.
Fixes: b7263e071aba7 ("netfilter: nf_tables: Allow table names of up to 255 chars")
Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org>
Acked-by: Phil Sutter <phil(a)nwl.cc>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/netfilter/nf_tables_api.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -2072,7 +2072,7 @@ static int nf_tables_dump_rules(struct s
continue;
list_for_each_entry_rcu(chain, &table->chains, list) {
- if (ctx && ctx->chain[0] &&
+ if (ctx && ctx->chain &&
strcmp(ctx->chain, chain->name) != 0)
continue;
Patches currently in stable-queue which might be from pablo(a)netfilter.org are
queue-4.14/netfilter-uapi-correct-untracked-conntrack-state-bit-number.patch
queue-4.14/netfilter-nf_tables-fix-chain-filter-in-nf_tables_dump_rules.patch
queue-4.14/netfilter-nf_tables-fix-potential-null-ptr-deref-in-nf_tables_dump_obj_done.patch
This is a note to let you know that I've just added the patch titled
net: usb: qmi_wwan: add Telit ME910 PID 0x1101 support
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:
net-usb-qmi_wwan-add-telit-me910-pid-0x1101-support.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 28 16:23:28 CET 2018
From: Daniele Palmas <dnlplm(a)gmail.com>
Date: Thu, 14 Dec 2017 16:56:14 +0100
Subject: net: usb: qmi_wwan: add Telit ME910 PID 0x1101 support
From: Daniele Palmas <dnlplm(a)gmail.com>
[ Upstream commit c647c0d62c82eb3ddf78a0d8b3d58819d9f552aa ]
This patch adds support for Telit ME910 PID 0x1101.
Signed-off-by: Daniele Palmas <dnlplm(a)gmail.com>
Acked-by: Bjørn Mork <bjorn(a)mork.no>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1211,6 +1211,7 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x2357, 0x9000, 4)}, /* TP-LINK MA260 */
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1040, 2)}, /* Telit LE922A */
{QMI_FIXED_INTF(0x1bc7, 0x1100, 3)}, /* Telit ME910 */
+ {QMI_FIXED_INTF(0x1bc7, 0x1101, 3)}, /* Telit ME910 dual modem */
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)}, /* Telit LE920 */
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1201, 2)}, /* Telit LE920, LE920A4 */
{QMI_FIXED_INTF(0x1c9e, 0x9801, 3)}, /* Telewell TW-3G HSPA+ */
Patches currently in stable-queue which might be from dnlplm(a)gmail.com are
queue-4.14/net-usb-qmi_wwan-add-telit-me910-pid-0x1101-support.patch
This is a note to let you know that I've just added the patch titled
NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625
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:
net-usb-qmi_wwan-add-support-for-yuga-clm920-nc5-pid-0x9625.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 28 16:23:28 CET 2018
From: "SZ Lin (林上智)" <sz.lin(a)moxa.com>
Date: Fri, 29 Dec 2017 17:02:17 +0800
Subject: NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625
From: "SZ Lin (林上智)" <sz.lin(a)moxa.com>
[ Upstream commit bd30ffc414e55194ed6149fad69a145550cb7c18 ]
This patch adds support for PID 0x9625 of YUGA CLM920-NC5.
YUGA CLM920-NC5 needs to enable QMI_WWAN_QUIRK_DTR before QMI operation.
qmicli -d /dev/cdc-wdm0 -p --dms-get-revision
[/dev/cdc-wdm0] Device revision retrieved:
Revision: 'CLM920_NC5-V1 1 [Oct 23 2016 19:00:00]'
Signed-off-by: SZ Lin (林上智) <sz.lin(a)moxa.com>
Acked-by: Bjørn Mork <bjorn(a)mork.no>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1100,6 +1100,7 @@ static const struct usb_device_id produc
{QMI_FIXED_INTF(0x05c6, 0x9084, 4)},
{QMI_FIXED_INTF(0x05c6, 0x920d, 0)},
{QMI_FIXED_INTF(0x05c6, 0x920d, 5)},
+ {QMI_QUIRK_SET_DTR(0x05c6, 0x9625, 4)}, /* YUGA CLM920-NC5 */
{QMI_FIXED_INTF(0x0846, 0x68a2, 8)},
{QMI_FIXED_INTF(0x12d1, 0x140c, 1)}, /* Huawei E173 */
{QMI_FIXED_INTF(0x12d1, 0x14ac, 1)}, /* Huawei E1820 */
Patches currently in stable-queue which might be from sz.lin(a)moxa.com are
queue-4.14/net-usb-qmi_wwan-add-support-for-yuga-clm920-nc5-pid-0x9625.patch
This is a note to let you know that I've just added the patch titled
net: stmmac: Fix TX timestamp calculation
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:
net-stmmac-fix-tx-timestamp-calculation.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 28 16:23:28 CET 2018
From: Fredrik Hallenberg <megahallon(a)gmail.com>
Date: Mon, 18 Dec 2017 23:33:59 +0100
Subject: net: stmmac: Fix TX timestamp calculation
From: Fredrik Hallenberg <megahallon(a)gmail.com>
[ Upstream commit 200922c93f008e03ddc804c6dacdf26ca1ba86d7 ]
When using GMAC4 the value written in PTP_SSIR should be shifted however
the shifted value is also used in subsequent calculations which results
in a bad timestamp value.
Signed-off-by: Fredrik Hallenberg <megahallon(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -34,6 +34,7 @@ static u32 stmmac_config_sub_second_incr
{
u32 value = readl(ioaddr + PTP_TCR);
unsigned long data;
+ u32 reg_value;
/* For GMAC3.x, 4.x versions, convert the ptp_clock to nano second
* formula = (1/ptp_clock) * 1000000000
@@ -50,10 +51,11 @@ static u32 stmmac_config_sub_second_incr
data &= PTP_SSIR_SSINC_MASK;
+ reg_value = data;
if (gmac4)
- data = data << GMAC4_PTP_SSIR_SSINC_SHIFT;
+ reg_value <<= GMAC4_PTP_SSIR_SSINC_SHIFT;
- writel(data, ioaddr + PTP_SSIR);
+ writel(reg_value, ioaddr + PTP_SSIR);
return data;
}
Patches currently in stable-queue which might be from megahallon(a)gmail.com are
queue-4.14/net-stmmac-fix-tx-timestamp-calculation.patch
queue-4.14/net-stmmac-fix-bad-rx-timestamp-extraction.patch
This is a note to let you know that I've just added the patch titled
net: stmmac: Fix bad RX timestamp extraction
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:
net-stmmac-fix-bad-rx-timestamp-extraction.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 28 16:23:28 CET 2018
From: Fredrik Hallenberg <megahallon(a)gmail.com>
Date: Mon, 18 Dec 2017 23:34:00 +0100
Subject: net: stmmac: Fix bad RX timestamp extraction
From: Fredrik Hallenberg <megahallon(a)gmail.com>
[ Upstream commit a1762456993893795030d911106a7650481db0ef ]
As noted in dwmac4_wrback_get_rx_timestamp_status the timestamp is found
in the context descriptor following the current descriptor. However the
current code looks for the context descriptor in the current
descriptor, which will always fail.
Signed-off-by: Fredrik Hallenberg <megahallon(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/stmicro/stmmac/common.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 5 +++--
drivers/net/ethernet/stmicro/stmmac/enh_desc.c | 3 ++-
drivers/net/ethernet/stmicro/stmmac/norm_desc.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
5 files changed, 8 insertions(+), 6 deletions(-)
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -409,7 +409,7 @@ struct stmmac_desc_ops {
/* get timestamp value */
u64(*get_timestamp) (void *desc, u32 ats);
/* get rx timestamp status */
- int (*get_rx_timestamp_status) (void *desc, u32 ats);
+ int (*get_rx_timestamp_status)(void *desc, void *next_desc, u32 ats);
/* Display ring */
void (*display_ring)(void *head, unsigned int size, bool rx);
/* set MSS via context descriptor */
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -258,7 +258,8 @@ static int dwmac4_rx_check_timestamp(voi
return ret;
}
-static int dwmac4_wrback_get_rx_timestamp_status(void *desc, u32 ats)
+static int dwmac4_wrback_get_rx_timestamp_status(void *desc, void *next_desc,
+ u32 ats)
{
struct dma_desc *p = (struct dma_desc *)desc;
int ret = -EINVAL;
@@ -270,7 +271,7 @@ static int dwmac4_wrback_get_rx_timestam
/* Check if timestamp is OK from context descriptor */
do {
- ret = dwmac4_rx_check_timestamp(desc);
+ ret = dwmac4_rx_check_timestamp(next_desc);
if (ret < 0)
goto exit;
i++;
--- a/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/enh_desc.c
@@ -400,7 +400,8 @@ static u64 enh_desc_get_timestamp(void *
return ns;
}
-static int enh_desc_get_rx_timestamp_status(void *desc, u32 ats)
+static int enh_desc_get_rx_timestamp_status(void *desc, void *next_desc,
+ u32 ats)
{
if (ats) {
struct dma_extended_desc *p = (struct dma_extended_desc *)desc;
--- a/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/norm_desc.c
@@ -265,7 +265,7 @@ static u64 ndesc_get_timestamp(void *des
return ns;
}
-static int ndesc_get_rx_timestamp_status(void *desc, u32 ats)
+static int ndesc_get_rx_timestamp_status(void *desc, void *next_desc, u32 ats)
{
struct dma_desc *p = (struct dma_desc *)desc;
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -489,7 +489,7 @@ static void stmmac_get_rx_hwtstamp(struc
desc = np;
/* Check if timestamp is available */
- if (priv->hw->desc->get_rx_timestamp_status(desc, priv->adv_ts)) {
+ if (priv->hw->desc->get_rx_timestamp_status(p, np, priv->adv_ts)) {
ns = priv->hw->desc->get_timestamp(desc, priv->adv_ts);
netdev_dbg(priv->dev, "get valid RX hw timestamp %llu\n", ns);
shhwtstamp = skb_hwtstamps(skb);
Patches currently in stable-queue which might be from megahallon(a)gmail.com are
queue-4.14/net-stmmac-fix-tx-timestamp-calculation.patch
queue-4.14/net-stmmac-fix-bad-rx-timestamp-extraction.patch
This is a note to let you know that I've just added the patch titled
net: phy: xgene: disable clk on error paths
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:
net-phy-xgene-disable-clk-on-error-paths.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 28 16:23:28 CET 2018
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Date: Sat, 16 Dec 2017 00:52:39 +0300
Subject: net: phy: xgene: disable clk on error paths
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
[ Upstream commit ab14436065c8066c265540312742390d6d07ddd2 ]
There are several error paths in xgene_mdio_probe(),
where clk is left undisabled. The patch fixes them.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/phy/mdio-xgene.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
--- a/drivers/net/phy/mdio-xgene.c
+++ b/drivers/net/phy/mdio-xgene.c
@@ -194,8 +194,11 @@ static int xgene_mdio_reset(struct xgene
}
ret = xgene_enet_ecc_init(pdata);
- if (ret)
+ if (ret) {
+ if (pdata->dev->of_node)
+ clk_disable_unprepare(pdata->clk);
return ret;
+ }
xgene_gmac_reset(pdata);
return 0;
@@ -388,8 +391,10 @@ static int xgene_mdio_probe(struct platf
return ret;
mdio_bus = mdiobus_alloc();
- if (!mdio_bus)
- return -ENOMEM;
+ if (!mdio_bus) {
+ ret = -ENOMEM;
+ goto out_clk;
+ }
mdio_bus->name = "APM X-Gene MDIO bus";
@@ -418,7 +423,7 @@ static int xgene_mdio_probe(struct platf
mdio_bus->phy_mask = ~0;
ret = mdiobus_register(mdio_bus);
if (ret)
- goto out;
+ goto out_mdiobus;
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_HANDLE(dev), 1,
acpi_register_phy, NULL, mdio_bus, NULL);
@@ -426,16 +431,20 @@ static int xgene_mdio_probe(struct platf
}
if (ret)
- goto out;
+ goto out_mdiobus;
pdata->mdio_bus = mdio_bus;
xgene_mdio_status = true;
return 0;
-out:
+out_mdiobus:
mdiobus_free(mdio_bus);
+out_clk:
+ if (dev->of_node)
+ clk_disable_unprepare(pdata->clk);
+
return ret;
}
Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are
queue-4.14/net-phy-xgene-disable-clk-on-error-paths.patch
This is a note to let you know that I've just added the patch titled
net/mlx5e: Fix ETS BW check
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:
net-mlx5e-fix-ets-bw-check.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 28 16:23:28 CET 2018
From: Huy Nguyen <huyn(a)mellanox.com>
Date: Thu, 26 Oct 2017 09:56:34 -0500
Subject: net/mlx5e: Fix ETS BW check
From: Huy Nguyen <huyn(a)mellanox.com>
[ Upstream commit ff0891915cd7b24ab27eee9b360c0452853bf9f6 ]
Fix bug that allows ets bw sum to be 0% when ets tc type exists.
Fixes: 08fb1dacdd76 ('net/mlx5e: Support DCBNL IEEE ETS')
Signed-off-by: Moshe Shemesh <moshe(a)mellanox.com>
Reviewed-by: Huy Nguyen <huyn(a)mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
@@ -259,6 +259,7 @@ int mlx5e_dcbnl_ieee_setets_core(struct
static int mlx5e_dbcnl_validate_ets(struct net_device *netdev,
struct ieee_ets *ets)
{
+ bool have_ets_tc = false;
int bw_sum = 0;
int i;
@@ -273,11 +274,14 @@ static int mlx5e_dbcnl_validate_ets(stru
}
/* Validate Bandwidth Sum */
- for (i = 0; i < IEEE_8021QAZ_MAX_TCS; i++)
- if (ets->tc_tsa[i] == IEEE_8021QAZ_TSA_ETS)
+ for (i = 0; i < IEEE_8021QAZ_MAX_TCS; i++) {
+ if (ets->tc_tsa[i] == IEEE_8021QAZ_TSA_ETS) {
+ have_ets_tc = true;
bw_sum += ets->tc_tx_bw[i];
+ }
+ }
- if (bw_sum != 0 && bw_sum != 100) {
+ if (have_ets_tc && bw_sum != 100) {
netdev_err(netdev,
"Failed to validate ETS: BW sum is illegal\n");
return -EINVAL;
Patches currently in stable-queue which might be from huyn(a)mellanox.com are
queue-4.14/net-mlx5e-fix-ets-bw-check.patch
This is a note to let you know that I've just added the patch titled
net/mlx5: Stay in polling mode when command EQ destroy fails
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:
net-mlx5-stay-in-polling-mode-when-command-eq-destroy-fails.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 28 16:23:28 CET 2018
From: Moshe Shemesh <moshe(a)mellanox.com>
Date: Mon, 4 Dec 2017 15:23:51 +0200
Subject: net/mlx5: Stay in polling mode when command EQ destroy fails
From: Moshe Shemesh <moshe(a)mellanox.com>
[ Upstream commit a2fba188fd5eadd6061bef4f2f2577a43231ebf3 ]
During unload, on mlx5_stop_eqs we move command interface from events
mode to polling mode, but if command interface EQ destroy fail we move
back to events mode.
That's wrong since even if we fail to destroy command interface EQ, we
do release its irq, so no interrupts will be received.
Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Moshe Shemesh <moshe(a)mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
@@ -802,11 +802,9 @@ void mlx5_stop_eqs(struct mlx5_core_dev
mlx5_cmd_use_polling(dev);
err = mlx5_destroy_unmap_eq(dev, &table->cmd_eq);
- if (err) {
+ if (err)
mlx5_core_err(dev, "failed to destroy command eq, err(%d)\n",
err);
- mlx5_cmd_use_events(dev);
- }
}
int mlx5_core_eq_query(struct mlx5_core_dev *dev, struct mlx5_eq *eq,
Patches currently in stable-queue which might be from moshe(a)mellanox.com are
queue-4.14/net-mlx5e-fix-ets-bw-check.patch
queue-4.14/net-mlx5-stay-in-polling-mode-when-command-eq-destroy-fails.patch
queue-4.14/net-mlx5-cleanup-irqs-in-case-of-unload-failure.patch
This is a note to let you know that I've just added the patch titled
net/mlx5: Cleanup IRQs in case of unload failure
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:
net-mlx5-cleanup-irqs-in-case-of-unload-failure.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 28 16:23:28 CET 2018
From: Moshe Shemesh <moshe(a)mellanox.com>
Date: Tue, 21 Nov 2017 15:15:51 +0200
Subject: net/mlx5: Cleanup IRQs in case of unload failure
From: Moshe Shemesh <moshe(a)mellanox.com>
[ Upstream commit d6b2785cd55ee72e9608762650b3ef299f801b1b ]
When mlx5_stop_eqs fails to destroy any of the eqs it returns with an error.
In such failure flow the function will return without
releasing all EQs irqs and then pci_free_irq_vectors will fail.
Fix by only warn on destroy EQ failure and continue to release other
EQs and their irqs.
It fixes the following kernel trace:
kernel: kernel BUG at drivers/pci/msi.c:352!
...
...
kernel: Call Trace:
kernel: pci_disable_msix+0xd3/0x100
kernel: pci_free_irq_vectors+0xe/0x20
kernel: mlx5_load_one.isra.17+0x9f5/0xec0 [mlx5_core]
Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Moshe Shemesh <moshe(a)mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 20 +++++++++++++-------
include/linux/mlx5/driver.h | 2 +-
2 files changed, 14 insertions(+), 8 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
@@ -776,7 +776,7 @@ err1:
return err;
}
-int mlx5_stop_eqs(struct mlx5_core_dev *dev)
+void mlx5_stop_eqs(struct mlx5_core_dev *dev)
{
struct mlx5_eq_table *table = &dev->priv.eq_table;
int err;
@@ -785,22 +785,28 @@ int mlx5_stop_eqs(struct mlx5_core_dev *
if (MLX5_CAP_GEN(dev, pg)) {
err = mlx5_destroy_unmap_eq(dev, &table->pfault_eq);
if (err)
- return err;
+ mlx5_core_err(dev, "failed to destroy page fault eq, err(%d)\n",
+ err);
}
#endif
err = mlx5_destroy_unmap_eq(dev, &table->pages_eq);
if (err)
- return err;
+ mlx5_core_err(dev, "failed to destroy pages eq, err(%d)\n",
+ err);
- mlx5_destroy_unmap_eq(dev, &table->async_eq);
+ err = mlx5_destroy_unmap_eq(dev, &table->async_eq);
+ if (err)
+ mlx5_core_err(dev, "failed to destroy async eq, err(%d)\n",
+ err);
mlx5_cmd_use_polling(dev);
err = mlx5_destroy_unmap_eq(dev, &table->cmd_eq);
- if (err)
+ if (err) {
+ mlx5_core_err(dev, "failed to destroy command eq, err(%d)\n",
+ err);
mlx5_cmd_use_events(dev);
-
- return err;
+ }
}
int mlx5_core_eq_query(struct mlx5_core_dev *dev, struct mlx5_eq *eq,
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -1017,7 +1017,7 @@ int mlx5_create_map_eq(struct mlx5_core_
enum mlx5_eq_type type);
int mlx5_destroy_unmap_eq(struct mlx5_core_dev *dev, struct mlx5_eq *eq);
int mlx5_start_eqs(struct mlx5_core_dev *dev);
-int mlx5_stop_eqs(struct mlx5_core_dev *dev);
+void mlx5_stop_eqs(struct mlx5_core_dev *dev);
int mlx5_vector2eqn(struct mlx5_core_dev *dev, int vector, int *eqn,
unsigned int *irqn);
int mlx5_core_attach_mcg(struct mlx5_core_dev *dev, union ib_gid *mgid, u32 qpn);
Patches currently in stable-queue which might be from moshe(a)mellanox.com are
queue-4.14/net-mlx5e-fix-ets-bw-check.patch
queue-4.14/net-mlx5-stay-in-polling-mode-when-command-eq-destroy-fails.patch
queue-4.14/net-mlx5-cleanup-irqs-in-case-of-unload-failure.patch
This is a note to let you know that I've just added the patch titled
net: mediatek: setup proper state for disabled GMAC on the 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:
net-mediatek-setup-proper-state-for-disabled-gmac-on-the-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 foo@baz Wed Feb 28 16:23:28 CET 2018
From: Sean Wang <sean.wang(a)mediatek.com>
Date: Mon, 18 Dec 2017 17:00:17 +0800
Subject: net: mediatek: setup proper state for disabled GMAC on the default
From: Sean Wang <sean.wang(a)mediatek.com>
[ Upstream commit 7352e252b5bf40d59342494a70354a2d436fd0cd ]
The current solution would setup fixed and force link of 1Gbps to the both
GMAC on the default. However, The GMAC should always be put to link down
state when the GMAC is disabled on certain target boards. Otherwise,
the driver possibly receives unexpected data from the floating hardware
connection through the unused GMAC. Although the driver had been added
certain protection in RX path to get rid of such kind of unexpected data
sent to the upper stack.
Signed-off-by: Sean Wang <sean.wang(a)mediatek.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1959,11 +1959,12 @@ static int mtk_hw_init(struct mtk_eth *e
/* set GE2 TUNE */
regmap_write(eth->pctl, GPIO_BIAS_CTRL, 0x0);
- /* GE1, Force 1000M/FD, FC ON */
- mtk_w32(eth, MAC_MCR_FIXED_LINK, MTK_MAC_MCR(0));
-
- /* GE2, Force 1000M/FD, FC ON */
- mtk_w32(eth, MAC_MCR_FIXED_LINK, MTK_MAC_MCR(1));
+ /* Set linkdown as the default for each GMAC. Its own MCR would be set
+ * up with the more appropriate value when mtk_phy_link_adjust call is
+ * being invoked.
+ */
+ for (i = 0; i < MTK_MAC_COUNT; i++)
+ mtk_w32(eth, 0, MTK_MAC_MCR(i));
/* Indicates CDM to parse the MTK special tag from CPU
* which also is working out for untag packets.
Patches currently in stable-queue which might be from sean.wang(a)mediatek.com are
queue-4.14/net-mediatek-setup-proper-state-for-disabled-gmac-on-the-default.patch
This is a note to let you know that I've just added the patch titled
net: gianfar_ptp: move set_fipers() to spinlock protecting area
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:
net-gianfar_ptp-move-set_fipers-to-spinlock-protecting-area.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 28 16:23:28 CET 2018
From: Yangbo Lu <yangbo.lu(a)nxp.com>
Date: Tue, 9 Jan 2018 11:02:33 +0800
Subject: net: gianfar_ptp: move set_fipers() to spinlock protecting area
From: Yangbo Lu <yangbo.lu(a)nxp.com>
[ Upstream commit 11d827a993a969c3c6ec56758ff63a44ba19b466 ]
set_fipers() calling should be protected by spinlock in
case that any interrupt breaks related registers setting
and the function we expect. This patch is to move set_fipers()
to spinlock protecting area in ptp_gianfar_adjtime().
Signed-off-by: Yangbo Lu <yangbo.lu(a)nxp.com>
Acked-by: Richard Cochran <richardcochran(a)gmail.com>
Reviewed-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/freescale/gianfar_ptp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
@@ -319,11 +319,10 @@ static int ptp_gianfar_adjtime(struct pt
now = tmr_cnt_read(etsects);
now += delta;
tmr_cnt_write(etsects, now);
+ set_fipers(etsects);
spin_unlock_irqrestore(&etsects->lock, flags);
- set_fipers(etsects);
-
return 0;
}
Patches currently in stable-queue which might be from yangbo.lu(a)nxp.com are
queue-4.14/net-gianfar_ptp-move-set_fipers-to-spinlock-protecting-area.patch
This is a note to let you know that I've just added the patch titled
net: ena: unmask MSI-X only after device initialization is completed
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:
net-ena-unmask-msi-x-only-after-device-initialization-is-completed.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 28 16:23:28 CET 2018
From: Netanel Belgazal <netanel(a)amazon.com>
Date: Wed, 3 Jan 2018 06:17:29 +0000
Subject: net: ena: unmask MSI-X only after device initialization is completed
From: Netanel Belgazal <netanel(a)amazon.com>
[ Upstream commit 7853b49ce8e0ef6364d24512b287463841d71bd3 ]
Under certain conditions MSI-X interrupt might arrive right after it
was unmasked in ena_up(). There is a chance it would be processed by
the driver before device ENA_FLAG_DEV_UP flag is set. In such a case
the interrupt is ignored.
ENA device operates in auto-masked mode, therefore ignoring
interrupt leaves it masked for good.
Moving unmask of interrupt to be the last step in ena_up().
Signed-off-by: Netanel Belgazal <netanel(a)amazon.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/amazon/ena/ena_netdev.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
--- a/drivers/net/ethernet/amazon/ena/ena_netdev.c
+++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c
@@ -1565,7 +1565,7 @@ static int ena_rss_configure(struct ena_
static int ena_up_complete(struct ena_adapter *adapter)
{
- int rc, i;
+ int rc;
rc = ena_rss_configure(adapter);
if (rc)
@@ -1584,17 +1584,6 @@ static int ena_up_complete(struct ena_ad
ena_napi_enable_all(adapter);
- /* Enable completion queues interrupt */
- for (i = 0; i < adapter->num_queues; i++)
- ena_unmask_interrupt(&adapter->tx_ring[i],
- &adapter->rx_ring[i]);
-
- /* schedule napi in case we had pending packets
- * from the last time we disable napi
- */
- for (i = 0; i < adapter->num_queues; i++)
- napi_schedule(&adapter->ena_napi[i].napi);
-
return 0;
}
@@ -1731,7 +1720,7 @@ create_err:
static int ena_up(struct ena_adapter *adapter)
{
- int rc;
+ int rc, i;
netdev_dbg(adapter->netdev, "%s\n", __func__);
@@ -1774,6 +1763,17 @@ static int ena_up(struct ena_adapter *ad
set_bit(ENA_FLAG_DEV_UP, &adapter->flags);
+ /* Enable completion queues interrupt */
+ for (i = 0; i < adapter->num_queues; i++)
+ ena_unmask_interrupt(&adapter->tx_ring[i],
+ &adapter->rx_ring[i]);
+
+ /* schedule napi in case we had pending packets
+ * from the last time we disable napi
+ */
+ for (i = 0; i < adapter->num_queues; i++)
+ napi_schedule(&adapter->ena_napi[i].napi);
+
return rc;
err_up:
Patches currently in stable-queue which might be from netanel(a)amazon.com are
queue-4.14/net-ena-unmask-msi-x-only-after-device-initialization-is-completed.patch
This is a note to let you know that I've just added the patch titled
net: arc_emac: fix arc_emac_rx() error paths
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:
net-arc_emac-fix-arc_emac_rx-error-paths.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 28 16:23:28 CET 2018
From: Alexander Kochetkov <al.kochet(a)gmail.com>
Date: Fri, 15 Dec 2017 20:20:06 +0300
Subject: net: arc_emac: fix arc_emac_rx() error paths
From: Alexander Kochetkov <al.kochet(a)gmail.com>
[ Upstream commit e688822d035b494071ecbadcccbd6f3325fb0f59 ]
arc_emac_rx() has some issues found by code review.
In case netdev_alloc_skb_ip_align() or dma_map_single() failure
rx fifo entry will not be returned to EMAC.
In case dma_map_single() failure previously allocated skb became
lost to driver. At the same time address of newly allocated skb
will not be provided to EMAC.
Signed-off-by: Alexander Kochetkov <al.kochet(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/arc/emac_main.c | 53 ++++++++++++++++++++---------------
1 file changed, 31 insertions(+), 22 deletions(-)
--- a/drivers/net/ethernet/arc/emac_main.c
+++ b/drivers/net/ethernet/arc/emac_main.c
@@ -210,39 +210,48 @@ static int arc_emac_rx(struct net_device
continue;
}
- pktlen = info & LEN_MASK;
- stats->rx_packets++;
- stats->rx_bytes += pktlen;
- skb = rx_buff->skb;
- skb_put(skb, pktlen);
- skb->dev = ndev;
- skb->protocol = eth_type_trans(skb, ndev);
-
- dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr),
- dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE);
-
- /* Prepare the BD for next cycle */
- rx_buff->skb = netdev_alloc_skb_ip_align(ndev,
- EMAC_BUFFER_SIZE);
- if (unlikely(!rx_buff->skb)) {
+ /* Prepare the BD for next cycle. netif_receive_skb()
+ * only if new skb was allocated and mapped to avoid holes
+ * in the RX fifo.
+ */
+ skb = netdev_alloc_skb_ip_align(ndev, EMAC_BUFFER_SIZE);
+ if (unlikely(!skb)) {
+ if (net_ratelimit())
+ netdev_err(ndev, "cannot allocate skb\n");
+ /* Return ownership to EMAC */
+ rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE);
stats->rx_errors++;
- /* Because receive_skb is below, increment rx_dropped */
stats->rx_dropped++;
continue;
}
- /* receive_skb only if new skb was allocated to avoid holes */
- netif_receive_skb(skb);
-
- addr = dma_map_single(&ndev->dev, (void *)rx_buff->skb->data,
+ addr = dma_map_single(&ndev->dev, (void *)skb->data,
EMAC_BUFFER_SIZE, DMA_FROM_DEVICE);
if (dma_mapping_error(&ndev->dev, addr)) {
if (net_ratelimit())
- netdev_err(ndev, "cannot dma map\n");
- dev_kfree_skb(rx_buff->skb);
+ netdev_err(ndev, "cannot map dma buffer\n");
+ dev_kfree_skb(skb);
+ /* Return ownership to EMAC */
+ rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE);
stats->rx_errors++;
+ stats->rx_dropped++;
continue;
}
+
+ /* unmap previosly mapped skb */
+ dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr),
+ dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE);
+
+ pktlen = info & LEN_MASK;
+ stats->rx_packets++;
+ stats->rx_bytes += pktlen;
+ skb_put(rx_buff->skb, pktlen);
+ rx_buff->skb->dev = ndev;
+ rx_buff->skb->protocol = eth_type_trans(rx_buff->skb, ndev);
+
+ netif_receive_skb(rx_buff->skb);
+
+ rx_buff->skb = skb;
dma_unmap_addr_set(rx_buff, addr, addr);
dma_unmap_len_set(rx_buff, len, EMAC_BUFFER_SIZE);
Patches currently in stable-queue which might be from al.kochet(a)gmail.com are
queue-4.14/net-arc_emac-fix-arc_emac_rx-error-paths.patch
This is a note to let you know that I've just added the patch titled
net: aquantia: Fix hardware DMA stream overload on large MRRS
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:
net-aquantia-fix-hardware-dma-stream-overload-on-large-mrrs.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 28 16:23:28 CET 2018
From: Igor Russkikh <igor.russkikh(a)aquantia.com>
Date: Thu, 14 Dec 2017 12:34:41 +0300
Subject: net: aquantia: Fix hardware DMA stream overload on large MRRS
From: Igor Russkikh <igor.russkikh(a)aquantia.com>
[ Upstream commit 1e366161510f266516107a69db91f1f2edaea11c ]
Systems with large MRRS on device (2K, 4K) with high data rates and/or
large MTU, atlantic observes DMA packet buffer overflow. On some systems
that causes PCIe transaction errors, hardware NMIs or datapath freeze.
This patch
1) Limits MRRS from device side to 2K (thats maximum our hardware supports)
2) Limit maximum size of outstanding TX DMA data read requests. This makes
hardware buffers running fine.
Signed-off-by: Pavel Belous <pavel.belous(a)aquantia.com>
Signed-off-by: Igor Russkikh <igor.russkikh(a)aquantia.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 12 ++++++++++
drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h | 6 +++++
2 files changed, 18 insertions(+)
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c
@@ -16,6 +16,7 @@
#include "hw_atl_utils.h"
#include "hw_atl_llh.h"
#include "hw_atl_b0_internal.h"
+#include "hw_atl_llh_internal.h"
static int hw_atl_b0_get_hw_caps(struct aq_hw_s *self,
struct aq_hw_caps_s *aq_hw_caps,
@@ -368,6 +369,7 @@ static int hw_atl_b0_hw_init(struct aq_h
};
int err = 0;
+ u32 val;
self->aq_nic_cfg = aq_nic_cfg;
@@ -385,6 +387,16 @@ static int hw_atl_b0_hw_init(struct aq_h
hw_atl_b0_hw_rss_set(self, &aq_nic_cfg->aq_rss);
hw_atl_b0_hw_rss_hash_set(self, &aq_nic_cfg->aq_rss);
+ /* Force limit MRRS on RDM/TDM to 2K */
+ val = aq_hw_read_reg(self, pci_reg_control6_adr);
+ aq_hw_write_reg(self, pci_reg_control6_adr, (val & ~0x707) | 0x404);
+
+ /* TX DMA total request limit. B0 hardware is not capable to
+ * handle more than (8K-MRRS) incoming DMA data.
+ * Value 24 in 256byte units
+ */
+ aq_hw_write_reg(self, tx_dma_total_req_limit_adr, 24);
+
err = aq_hw_err_from_flags(self);
if (err < 0)
goto err_exit;
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_llh_internal.h
@@ -2343,6 +2343,9 @@
#define tx_dma_desc_base_addrmsw_adr(descriptor) \
(0x00007c04u + (descriptor) * 0x40)
+/* tx dma total request limit */
+#define tx_dma_total_req_limit_adr 0x00007b20u
+
/* tx interrupt moderation control register definitions
* Preprocessor definitions for TX Interrupt Moderation Control Register
* Base Address: 0x00008980
@@ -2369,6 +2372,9 @@
/* default value of bitfield reg_res_dsbl */
#define pci_reg_res_dsbl_default 0x1
+/* PCI core control register */
+#define pci_reg_control6_adr 0x1014u
+
/* global microprocessor scratch pad definitions */
#define glb_cpu_scratch_scp_adr(scratch_scp) (0x00000300u + (scratch_scp) * 0x4)
Patches currently in stable-queue which might be from igor.russkikh(a)aquantia.com are
queue-4.14/net-aquantia-fix-actual-speed-capabilities-reporting.patch
queue-4.14/net-aquantia-fix-hardware-dma-stream-overload-on-large-mrrs.patch