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