From: Sasha Levin Date: Fri, 1 May 2020 04:38:55 +0000 (-0400) Subject: Fixes for 4.19 X-Git-Tag: v5.4.37~19 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=73716fdc0c0ff0c33561a35bbbadb550ac923177;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.19 Signed-off-by: Sasha Levin --- diff --git a/queue-4.19/alsa-hda-call-runtime_allow-for-all-hda-controllers.patch b/queue-4.19/alsa-hda-call-runtime_allow-for-all-hda-controllers.patch new file mode 100644 index 00000000000..b3d93eb8b1a --- /dev/null +++ b/queue-4.19/alsa-hda-call-runtime_allow-for-all-hda-controllers.patch @@ -0,0 +1,47 @@ +From 34f9fd6209f4eff3e1483749c884818179aa6dde Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 14 Apr 2020 22:27:25 +0800 +Subject: ALSA: hda: call runtime_allow() for all hda controllers + +From: Hui Wang + +[ Upstream commit 9a6418487b566503c772cb6e7d3d44e652b019b0 ] + +Before the pci_driver->probe() is called, the pci subsystem calls +runtime_forbid() and runtime_get_sync() on this pci dev, so only call +runtime_put_autosuspend() is not enough to enable the runtime_pm on +this device. + +For controllers with vgaswitcheroo feature, the pci/quirks.c will call +runtime_allow() for this dev, then the controllers could enter +rt_idle/suspend/resume, but for non-vgaswitcheroo controllers like +Intel hda controllers, the runtime_pm is not enabled because the +runtime_allow() is not called. + +Since it is no harm calling runtime_allow() twice, here let hda +driver call runtime_allow() for all controllers. Then the runtime_pm +is enabled on all controllers after the put_autosuspend() is called. + +Signed-off-by: Hui Wang +Link: https://lore.kernel.org/r/20200414142725.6020-1-hui.wang@canonical.com +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/pci/hda/hda_intel.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c +index ff448abb5449f..0d7981eda2c4f 100644 +--- a/sound/pci/hda/hda_intel.c ++++ b/sound/pci/hda/hda_intel.c +@@ -2477,6 +2477,7 @@ static int azx_probe_continue(struct azx *chip) + + if (azx_has_pm_runtime(chip)) { + pm_runtime_use_autosuspend(&pci->dev); ++ pm_runtime_allow(&pci->dev); + pm_runtime_put_autosuspend(&pci->dev); + } + +-- +2.20.1 + diff --git a/queue-4.19/alsa-hda-explicitly-permit-using-autosuspend-if-runt.patch b/queue-4.19/alsa-hda-explicitly-permit-using-autosuspend-if-runt.patch new file mode 100644 index 00000000000..f4ee8ed1758 --- /dev/null +++ b/queue-4.19/alsa-hda-explicitly-permit-using-autosuspend-if-runt.patch @@ -0,0 +1,41 @@ +From 638a03774f0d91a6a4c3ffed6905a09513af43e9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 13 Apr 2020 10:20:34 +0200 +Subject: ALSA: hda: Explicitly permit using autosuspend if runtime PM is + supported + +From: Roy Spliet + +[ Upstream commit 3ba21113bd33d49f3c300a23fc08cf114c434995 ] + +This fixes runtime PM not working after a suspend-to-RAM cycle at least for +the codec-less HDA device found on NVIDIA GPUs. + +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 +Signed-off-by: Roy Spliet +Link: https://lore.kernel.org/r/20200413082034.25166-7-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/pci/hda/hda_intel.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c +index 72c268e887e55..ff448abb5449f 100644 +--- a/sound/pci/hda/hda_intel.c ++++ b/sound/pci/hda/hda_intel.c +@@ -2475,8 +2475,10 @@ static int azx_probe_continue(struct azx *chip) + + set_default_power_save(chip); + +- if (azx_has_pm_runtime(chip)) ++ if (azx_has_pm_runtime(chip)) { ++ pm_runtime_use_autosuspend(&pci->dev); + pm_runtime_put_autosuspend(&pci->dev); ++ } + + out_free: + if ((chip->driver_caps & AZX_DCAPS_I915_POWERWELL) +-- +2.20.1 + diff --git a/queue-4.19/alsa-hda-keep-the-controller-initialization-even-if-.patch b/queue-4.19/alsa-hda-keep-the-controller-initialization-even-if-.patch new file mode 100644 index 00000000000..dee277de06e --- /dev/null +++ b/queue-4.19/alsa-hda-keep-the-controller-initialization-even-if-.patch @@ -0,0 +1,71 @@ +From fa780ca5102a73df3dfdc7e4e67b9c6f67c2753f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 13 Apr 2020 10:20:32 +0200 +Subject: ALSA: hda: Keep the controller initialization even if no codecs found + +From: Takashi Iwai + +[ Upstream commit 9479e75fca370a5220784f7596bf598c4dad0b9b ] + +Currently, when the HD-audio controller driver doesn't detect any +codecs, it tries to abort the probe. But this abort happens at the +delayed probe, i.e. the primary probe call already returned success, +hence the driver is never unbound until user does so explicitly. +As a result, it may leave the HD-audio device in the running state +without the runtime PM. More badly, if the device is a HD-audio bus +that is tied with a GPU, GPU cannot reach to the full power down and +consumes unnecessarily much power. + +This patch changes the logic after no-codec situation; it continues +probing without the further codec initialization but keep the +controller driver running normally. + +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207043 +Tested-by: Roy Spliet +Link: https://lore.kernel.org/r/20200413082034.25166-5-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/pci/hda/hda_intel.c | 12 +++++++----- + 1 file changed, 7 insertions(+), 5 deletions(-) + +diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c +index 0502042c16163..72c268e887e55 100644 +--- a/sound/pci/hda/hda_intel.c ++++ b/sound/pci/hda/hda_intel.c +@@ -2054,7 +2054,7 @@ static int azx_first_init(struct azx *chip) + /* codec detection */ + if (!azx_bus(chip)->codec_mask) { + dev_err(card->dev, "no codecs found!\n"); +- return -ENODEV; ++ /* keep running the rest for the runtime PM */ + } + + if (azx_acquire_irq(chip, 0) < 0) +@@ -2440,9 +2440,11 @@ static int azx_probe_continue(struct azx *chip) + #endif + + /* create codec instances */ +- err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]); +- if (err < 0) +- goto out_free; ++ if (bus->codec_mask) { ++ err = azx_probe_codecs(chip, azx_max_codecs[chip->driver_type]); ++ if (err < 0) ++ goto out_free; ++ } + + #ifdef CONFIG_SND_HDA_PATCH_LOADER + if (chip->fw) { +@@ -2456,7 +2458,7 @@ static int azx_probe_continue(struct azx *chip) + #endif + } + #endif +- if ((probe_only[dev] & 1) == 0) { ++ if (bus->codec_mask && !(probe_only[dev] & 1)) { + err = azx_codec_configure(chip); + if (err < 0) + goto out_free; +-- +2.20.1 + diff --git a/queue-4.19/arm64-delete-the-space-separator-in-__emit_inst.patch b/queue-4.19/arm64-delete-the-space-separator-in-__emit_inst.patch new file mode 100644 index 00000000000..81f6bf0f635 --- /dev/null +++ b/queue-4.19/arm64-delete-the-space-separator-in-__emit_inst.patch @@ -0,0 +1,69 @@ +From 0ac02f23ee7178d91c32e1bb92eb67fc576f25f0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 14 Apr 2020 09:32:55 -0700 +Subject: arm64: Delete the space separator in __emit_inst + +From: Fangrui Song + +[ Upstream commit c9a4ef66450145a356a626c833d3d7b1668b3ded ] + +In assembly, many instances of __emit_inst(x) expand to a directive. In +a few places __emit_inst(x) is used as an assembler macro argument. For +example, in arch/arm64/kvm/hyp/entry.S + + ALTERNATIVE(nop, SET_PSTATE_PAN(1), ARM64_HAS_PAN, CONFIG_ARM64_PAN) + +expands to the following by the C preprocessor: + + alternative_insn nop, .inst (0xd500401f | ((0) << 16 | (4) << 5) | ((!!1) << 8)), 4, 1 + +Both comma and space are separators, with an exception that content +inside a pair of parentheses/quotes is not split, so the clang +integrated assembler splits the arguments to: + + nop, .inst, (0xd500401f | ((0) << 16 | (4) << 5) | ((!!1) << 8)), 4, 1 + +GNU as preprocesses the input with do_scrub_chars(). Its arm64 backend +(along with many other non-x86 backends) sees: + + alternative_insn nop,.inst(0xd500401f|((0)<<16|(4)<<5)|((!!1)<<8)),4,1 + # .inst(...) is parsed as one argument + +while its x86 backend sees: + + alternative_insn nop,.inst (0xd500401f|((0)<<16|(4)<<5)|((!!1)<<8)),4,1 + # The extra space before '(' makes the whole .inst (...) parsed as two arguments + +The non-x86 backend's behavior is considered unintentional +(https://sourceware.org/bugzilla/show_bug.cgi?id=25750). +So drop the space separator inside `.inst (...)` to make the clang +integrated assembler work. + +Suggested-by: Ilie Halip +Signed-off-by: Fangrui Song +Reviewed-by: Mark Rutland +Link: https://github.com/ClangBuiltLinux/linux/issues/939 +Signed-off-by: Catalin Marinas +Signed-off-by: Sasha Levin +--- + arch/arm64/include/asm/sysreg.h | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h +index 3091ae5975a3a..ed99d941c4623 100644 +--- a/arch/arm64/include/asm/sysreg.h ++++ b/arch/arm64/include/asm/sysreg.h +@@ -60,7 +60,9 @@ + #ifndef CONFIG_BROKEN_GAS_INST + + #ifdef __ASSEMBLY__ +-#define __emit_inst(x) .inst (x) ++// The space separator is omitted so that __emit_inst(x) can be parsed as ++// either an assembler directive or an assembler macro argument. ++#define __emit_inst(x) .inst(x) + #else + #define __emit_inst(x) ".inst " __stringify((x)) "\n\t" + #endif +-- +2.20.1 + diff --git a/queue-4.19/bpf-x86-fix-encoding-for-lower-8-bit-registers-in-bp.patch b/queue-4.19/bpf-x86-fix-encoding-for-lower-8-bit-registers-in-bp.patch new file mode 100644 index 00000000000..1b7916d90df --- /dev/null +++ b/queue-4.19/bpf-x86-fix-encoding-for-lower-8-bit-registers-in-bp.patch @@ -0,0 +1,79 @@ +From 9acb5cbb1c1b54143b1833588fed781775c584f3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 18 Apr 2020 16:26:53 -0700 +Subject: bpf, x86: Fix encoding for lower 8-bit registers in BPF_STX BPF_B + +From: Luke Nelson + +[ Upstream commit aee194b14dd2b2bde6252b3acf57d36dccfc743a ] + +This patch fixes an encoding bug in emit_stx for BPF_B when the source +register is BPF_REG_FP. + +The current implementation for BPF_STX BPF_B in emit_stx saves one REX +byte when the operands can be encoded using Mod-R/M alone. The lower 8 +bits of registers %rax, %rbx, %rcx, and %rdx can be accessed without using +a REX prefix via %al, %bl, %cl, and %dl, respectively. Other registers, +(e.g., %rsi, %rdi, %rbp, %rsp) require a REX prefix to use their 8-bit +equivalents (%sil, %dil, %bpl, %spl). + +The current code checks if the source for BPF_STX BPF_B is BPF_REG_1 +or BPF_REG_2 (which map to %rdi and %rsi), in which case it emits the +required REX prefix. However, it misses the case when the source is +BPF_REG_FP (mapped to %rbp). + +The result is that BPF_STX BPF_B with BPF_REG_FP as the source operand +will read from register %ch instead of the correct %bpl. This patch fixes +the problem by fixing and refactoring the check on which registers need +the extra REX byte. Since no BPF registers map to %rsp, there is no need +to handle %spl. + +Fixes: 622582786c9e0 ("net: filter: x86: internal BPF JIT") +Signed-off-by: Xi Wang +Signed-off-by: Luke Nelson +Signed-off-by: Alexei Starovoitov +Link: https://lore.kernel.org/bpf/20200418232655.23870-1-luke.r.nels@gmail.com +Signed-off-by: Sasha Levin +--- + arch/x86/net/bpf_jit_comp.c | 18 +++++++++++++++--- + 1 file changed, 15 insertions(+), 3 deletions(-) + +diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c +index a32fc3d994076..46ab928312517 100644 +--- a/arch/x86/net/bpf_jit_comp.c ++++ b/arch/x86/net/bpf_jit_comp.c +@@ -142,6 +142,19 @@ static bool is_ereg(u32 reg) + BIT(BPF_REG_AX)); + } + ++/* ++ * is_ereg_8l() == true if BPF register 'reg' is mapped to access x86-64 ++ * lower 8-bit registers dil,sil,bpl,spl,r8b..r15b, which need extra byte ++ * of encoding. al,cl,dl,bl have simpler encoding. ++ */ ++static bool is_ereg_8l(u32 reg) ++{ ++ return is_ereg(reg) || ++ (1 << reg) & (BIT(BPF_REG_1) | ++ BIT(BPF_REG_2) | ++ BIT(BPF_REG_FP)); ++} ++ + static bool is_axreg(u32 reg) + { + return reg == BPF_REG_0; +@@ -751,9 +764,8 @@ st: if (is_imm8(insn->off)) + /* STX: *(u8*)(dst_reg + off) = src_reg */ + case BPF_STX | BPF_MEM | BPF_B: + /* Emit 'mov byte ptr [rax + off], al' */ +- if (is_ereg(dst_reg) || is_ereg(src_reg) || +- /* We have to add extra byte for x86 SIL, DIL regs */ +- src_reg == BPF_REG_1 || src_reg == BPF_REG_2) ++ if (is_ereg(dst_reg) || is_ereg_8l(src_reg)) ++ /* Add extra byte for eregs or SIL,DIL,BPL in src_reg */ + EMIT2(add_2mod(0x40, dst_reg, src_reg), 0x88); + else + EMIT1(0x88); +-- +2.20.1 + diff --git a/queue-4.19/ext4-convert-bug_on-s-to-warn_on-s-in-mballoc.c.patch b/queue-4.19/ext4-convert-bug_on-s-to-warn_on-s-in-mballoc.c.patch new file mode 100644 index 00000000000..a68ab4bee1a --- /dev/null +++ b/queue-4.19/ext4-convert-bug_on-s-to-warn_on-s-in-mballoc.c.patch @@ -0,0 +1,52 @@ +From 740d901f0d11a3fabd57f895119a296ac5fc3af9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 13 Apr 2020 23:33:05 -0400 +Subject: ext4: convert BUG_ON's to WARN_ON's in mballoc.c + +From: Theodore Ts'o + +[ Upstream commit 907ea529fc4c3296701d2bfc8b831dd2a8121a34 ] + +If the in-core buddy bitmap gets corrupted (or out of sync with the +block bitmap), issue a WARN_ON and try to recover. In most cases this +involves skipping trying to allocate out of a particular block group. +We can end up declaring the file system corrupted, which is fair, +since the file system probably should be checked before we proceed any +further. + +Link: https://lore.kernel.org/r/20200414035649.293164-1-tytso@mit.edu +Google-Bug-Id: 34811296 +Google-Bug-Id: 34639169 +Signed-off-by: Theodore Ts'o +Signed-off-by: Sasha Levin +--- + fs/ext4/mballoc.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c +index 71121fcf9e8cc..8dd54a8a03610 100644 +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -1936,7 +1936,8 @@ void ext4_mb_complex_scan_group(struct ext4_allocation_context *ac, + int free; + + free = e4b->bd_info->bb_free; +- BUG_ON(free <= 0); ++ if (WARN_ON(free <= 0)) ++ return; + + i = e4b->bd_info->bb_first_free; + +@@ -1959,7 +1960,8 @@ void ext4_mb_complex_scan_group(struct ext4_allocation_context *ac, + } + + mb_find_extent(e4b, i, ac->ac_g_ex.fe_len, &ex); +- BUG_ON(ex.fe_len <= 0); ++ if (WARN_ON(ex.fe_len <= 0)) ++ break; + if (free < ex.fe_len) { + ext4_grp_locked_error(sb, e4b->bd_group, 0, 0, + "%d free clusters as per " +-- +2.20.1 + diff --git a/queue-4.19/ext4-increase-wait-time-needed-before-reuse-of-delet.patch b/queue-4.19/ext4-increase-wait-time-needed-before-reuse-of-delet.patch new file mode 100644 index 00000000000..06cdb13effc --- /dev/null +++ b/queue-4.19/ext4-increase-wait-time-needed-before-reuse-of-delet.patch @@ -0,0 +1,40 @@ +From 88d150ad5d6eaf2e30a39c6d9d7036251e369681 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 13 Apr 2020 22:30:52 -0400 +Subject: ext4: increase wait time needed before reuse of deleted inode numbers + +From: Theodore Ts'o + +[ Upstream commit a17a9d935dc4a50acefaf319d58030f1da7f115a ] + +Current wait times have proven to be too short to protect against inode +reuses that lead to metadata inconsistencies. + +Now that we will retry the inode allocation if we can't find any +recently deleted inodes, it's a lot safer to increase the recently +deleted time from 5 seconds to a minute. + +Link: https://lore.kernel.org/r/20200414023925.273867-1-tytso@mit.edu +Google-Bug-Id: 36602237 +Signed-off-by: Theodore Ts'o +Signed-off-by: Sasha Levin +--- + fs/ext4/ialloc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c +index dafa7e4aaecb9..8876eaad10f68 100644 +--- a/fs/ext4/ialloc.c ++++ b/fs/ext4/ialloc.c +@@ -665,7 +665,7 @@ static int find_group_other(struct super_block *sb, struct inode *parent, + * block has been written back to disk. (Yes, these values are + * somewhat arbitrary...) + */ +-#define RECENTCY_MIN 5 ++#define RECENTCY_MIN 60 + #define RECENTCY_DIRTY 300 + + static int recently_deleted(struct super_block *sb, ext4_group_t group, int ino) +-- +2.20.1 + diff --git a/queue-4.19/ext4-use-matching-invalidatepage-in-ext4_writepage.patch b/queue-4.19/ext4-use-matching-invalidatepage-in-ext4_writepage.patch new file mode 100644 index 00000000000..581846a5a11 --- /dev/null +++ b/queue-4.19/ext4-use-matching-invalidatepage-in-ext4_writepage.patch @@ -0,0 +1,40 @@ +From bc598ae89426eb501db117517803e2aa09e233e8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 26 Feb 2020 12:10:02 +0800 +Subject: ext4: use matching invalidatepage in ext4_writepage + +From: yangerkun + +[ Upstream commit c2a559bc0e7ed5a715ad6b947025b33cb7c05ea7 ] + +Run generic/388 with journal data mode sometimes may trigger the warning +in ext4_invalidatepage. Actually, we should use the matching invalidatepage +in ext4_writepage. + +Signed-off-by: yangerkun +Signed-off-by: Theodore Ts'o +Reviewed-by: Ritesh Harjani +Reviewed-by: Jan Kara +Link: https://lore.kernel.org/r/20200226041002.13914-1-yangerkun@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Sasha Levin +--- + fs/ext4/inode.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c +index 000fa0e392787..3b1a7597af15e 100644 +--- a/fs/ext4/inode.c ++++ b/fs/ext4/inode.c +@@ -2128,7 +2128,7 @@ static int ext4_writepage(struct page *page, + bool keep_towrite = false; + + if (unlikely(ext4_forced_shutdown(EXT4_SB(inode->i_sb)))) { +- ext4_invalidatepage(page, 0, PAGE_SIZE); ++ inode->i_mapping->a_ops->invalidatepage(page, 0, PAGE_SIZE); + unlock_page(page); + return -EIO; + } +-- +2.20.1 + diff --git a/queue-4.19/hwmon-jc42-fix-name-to-have-no-illegal-characters.patch b/queue-4.19/hwmon-jc42-fix-name-to-have-no-illegal-characters.patch new file mode 100644 index 00000000000..482e924f6ef --- /dev/null +++ b/queue-4.19/hwmon-jc42-fix-name-to-have-no-illegal-characters.patch @@ -0,0 +1,43 @@ +From 5303f6f431e7829a9faa57b368e842411e873867 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 17 Apr 2020 11:28:53 +0200 +Subject: hwmon: (jc42) Fix name to have no illegal characters + +From: Sascha Hauer + +[ Upstream commit c843b382e61b5f28a3d917712c69a344f632387c ] + +The jc42 driver passes I2C client's name as hwmon device name. In case +of device tree probed devices this ends up being part of the compatible +string, "jc-42.4-temp". This name contains hyphens and the hwmon core +doesn't like this: + +jc42 2-0018: hwmon: 'jc-42.4-temp' is not a valid name attribute, please fix + +This changes the name to "jc42" which doesn't have any illegal +characters. + +Signed-off-by: Sascha Hauer +Link: https://lore.kernel.org/r/20200417092853.31206-1-s.hauer@pengutronix.de +Signed-off-by: Guenter Roeck +Signed-off-by: Sasha Levin +--- + drivers/hwmon/jc42.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/hwmon/jc42.c b/drivers/hwmon/jc42.c +index e5234f953a6d1..b6e5aaa54963d 100644 +--- a/drivers/hwmon/jc42.c ++++ b/drivers/hwmon/jc42.c +@@ -527,7 +527,7 @@ static int jc42_probe(struct i2c_client *client, const struct i2c_device_id *id) + } + data->config = config; + +- hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, ++ hwmon_dev = devm_hwmon_device_register_with_info(dev, "jc42", + data, &jc42_chip_info, + NULL); + return PTR_ERR_OR_ZERO(hwmon_dev); +-- +2.20.1 + diff --git a/queue-4.19/net-fec-set-gpr-bit-on-suspend-by-dt-configuration.patch b/queue-4.19/net-fec-set-gpr-bit-on-suspend-by-dt-configuration.patch new file mode 100644 index 00000000000..6867ba1594c --- /dev/null +++ b/queue-4.19/net-fec-set-gpr-bit-on-suspend-by-dt-configuration.patch @@ -0,0 +1,315 @@ +From 085edd8420d057d02ce26191e2bbdddcc9b32c97 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 2 Apr 2020 15:51:27 +0200 +Subject: net: fec: set GPR bit on suspend by DT configuration. + +From: Martin Fuzzey + +[ Upstream commit da722186f6549d752ea5b5fbc18111833c81a133 ] + +On some SoCs, such as the i.MX6, it is necessary to set a bit +in the SoC level GPR register before suspending for wake on lan +to work. + +The fec platform callback sleep_mode_enable was intended to allow this +but the platform implementation was NAK'd back in 2015 [1] + +This means that, currently, wake on lan is broken on mainline for +the i.MX6 at least. + +So implement the required bit setting in the fec driver by itself +by adding a new optional DT property indicating the GPR register +and adding the offset and bit information to the driver. + +[1] https://www.spinics.net/lists/netdev/msg310922.html + +Signed-off-by: Martin Fuzzey +Signed-off-by: Fugang Duan +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/freescale/fec.h | 7 + + drivers/net/ethernet/freescale/fec_main.c | 149 +++++++++++++++++----- + 2 files changed, 127 insertions(+), 29 deletions(-) + +diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h +index bf80855dd0dd4..d06a89e99872d 100644 +--- a/drivers/net/ethernet/freescale/fec.h ++++ b/drivers/net/ethernet/freescale/fec.h +@@ -488,6 +488,12 @@ struct fec_enet_priv_rx_q { + struct sk_buff *rx_skbuff[RX_RING_SIZE]; + }; + ++struct fec_stop_mode_gpr { ++ struct regmap *gpr; ++ u8 reg; ++ u8 bit; ++}; ++ + /* The FEC buffer descriptors track the ring buffers. The rx_bd_base and + * tx_bd_base always point to the base of the buffer descriptors. The + * cur_rx and cur_tx point to the currently available buffer. +@@ -563,6 +569,7 @@ struct fec_enet_private { + int hwts_tx_en; + struct delayed_work time_keep; + struct regulator *reg_phy; ++ struct fec_stop_mode_gpr stop_gpr; + + unsigned int tx_align; + unsigned int rx_align; +diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c +index 9142992ccd5a7..48c58f93b124b 100644 +--- a/drivers/net/ethernet/freescale/fec_main.c ++++ b/drivers/net/ethernet/freescale/fec_main.c +@@ -62,6 +62,8 @@ + #include + #include + #include ++#include ++#include + #include + + #include +@@ -84,6 +86,56 @@ static void fec_enet_itr_coal_init(struct net_device *ndev); + #define FEC_ENET_OPD_V 0xFFF0 + #define FEC_MDIO_PM_TIMEOUT 100 /* ms */ + ++struct fec_devinfo { ++ u32 quirks; ++ u8 stop_gpr_reg; ++ u8 stop_gpr_bit; ++}; ++ ++static const struct fec_devinfo fec_imx25_info = { ++ .quirks = FEC_QUIRK_USE_GASKET | FEC_QUIRK_MIB_CLEAR | ++ FEC_QUIRK_HAS_FRREG, ++}; ++ ++static const struct fec_devinfo fec_imx27_info = { ++ .quirks = FEC_QUIRK_MIB_CLEAR | FEC_QUIRK_HAS_FRREG, ++}; ++ ++static const struct fec_devinfo fec_imx28_info = { ++ .quirks = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME | ++ FEC_QUIRK_SINGLE_MDIO | FEC_QUIRK_HAS_RACC | ++ FEC_QUIRK_HAS_FRREG, ++}; ++ ++static const struct fec_devinfo fec_imx6q_info = { ++ .quirks = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT | ++ FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM | ++ FEC_QUIRK_HAS_VLAN | FEC_QUIRK_ERR006358 | ++ FEC_QUIRK_HAS_RACC, ++ .stop_gpr_reg = 0x34, ++ .stop_gpr_bit = 27, ++}; ++ ++static const struct fec_devinfo fec_mvf600_info = { ++ .quirks = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_RACC, ++}; ++ ++static const struct fec_devinfo fec_imx6x_info = { ++ .quirks = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT | ++ FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM | ++ FEC_QUIRK_HAS_VLAN | FEC_QUIRK_HAS_AVB | ++ FEC_QUIRK_ERR007885 | FEC_QUIRK_BUG_CAPTURE | ++ FEC_QUIRK_HAS_RACC | FEC_QUIRK_HAS_COALESCE, ++}; ++ ++static const struct fec_devinfo fec_imx6ul_info = { ++ .quirks = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT | ++ FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM | ++ FEC_QUIRK_HAS_VLAN | FEC_QUIRK_ERR007885 | ++ FEC_QUIRK_BUG_CAPTURE | FEC_QUIRK_HAS_RACC | ++ FEC_QUIRK_HAS_COALESCE, ++}; ++ + static struct platform_device_id fec_devtype[] = { + { + /* keep it for coldfire */ +@@ -91,39 +143,25 @@ static struct platform_device_id fec_devtype[] = { + .driver_data = 0, + }, { + .name = "imx25-fec", +- .driver_data = FEC_QUIRK_USE_GASKET | FEC_QUIRK_MIB_CLEAR | +- FEC_QUIRK_HAS_FRREG, ++ .driver_data = (kernel_ulong_t)&fec_imx25_info, + }, { + .name = "imx27-fec", +- .driver_data = FEC_QUIRK_MIB_CLEAR | FEC_QUIRK_HAS_FRREG, ++ .driver_data = (kernel_ulong_t)&fec_imx27_info, + }, { + .name = "imx28-fec", +- .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_SWAP_FRAME | +- FEC_QUIRK_SINGLE_MDIO | FEC_QUIRK_HAS_RACC | +- FEC_QUIRK_HAS_FRREG, ++ .driver_data = (kernel_ulong_t)&fec_imx28_info, + }, { + .name = "imx6q-fec", +- .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT | +- FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM | +- FEC_QUIRK_HAS_VLAN | FEC_QUIRK_ERR006358 | +- FEC_QUIRK_HAS_RACC, ++ .driver_data = (kernel_ulong_t)&fec_imx6q_info, + }, { + .name = "mvf600-fec", +- .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_RACC, ++ .driver_data = (kernel_ulong_t)&fec_mvf600_info, + }, { + .name = "imx6sx-fec", +- .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT | +- FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM | +- FEC_QUIRK_HAS_VLAN | FEC_QUIRK_HAS_AVB | +- FEC_QUIRK_ERR007885 | FEC_QUIRK_BUG_CAPTURE | +- FEC_QUIRK_HAS_RACC | FEC_QUIRK_HAS_COALESCE, ++ .driver_data = (kernel_ulong_t)&fec_imx6x_info, + }, { + .name = "imx6ul-fec", +- .driver_data = FEC_QUIRK_ENET_MAC | FEC_QUIRK_HAS_GBIT | +- FEC_QUIRK_HAS_BUFDESC_EX | FEC_QUIRK_HAS_CSUM | +- FEC_QUIRK_HAS_VLAN | FEC_QUIRK_ERR007885 | +- FEC_QUIRK_BUG_CAPTURE | FEC_QUIRK_HAS_RACC | +- FEC_QUIRK_HAS_COALESCE, ++ .driver_data = (kernel_ulong_t)&fec_imx6ul_info, + }, { + /* sentinel */ + } +@@ -1089,11 +1127,28 @@ fec_restart(struct net_device *ndev) + + } + ++static void fec_enet_stop_mode(struct fec_enet_private *fep, bool enabled) ++{ ++ struct fec_platform_data *pdata = fep->pdev->dev.platform_data; ++ struct fec_stop_mode_gpr *stop_gpr = &fep->stop_gpr; ++ ++ if (stop_gpr->gpr) { ++ if (enabled) ++ regmap_update_bits(stop_gpr->gpr, stop_gpr->reg, ++ BIT(stop_gpr->bit), ++ BIT(stop_gpr->bit)); ++ else ++ regmap_update_bits(stop_gpr->gpr, stop_gpr->reg, ++ BIT(stop_gpr->bit), 0); ++ } else if (pdata && pdata->sleep_mode_enable) { ++ pdata->sleep_mode_enable(enabled); ++ } ++} ++ + static void + fec_stop(struct net_device *ndev) + { + struct fec_enet_private *fep = netdev_priv(ndev); +- struct fec_platform_data *pdata = fep->pdev->dev.platform_data; + u32 rmii_mode = readl(fep->hwp + FEC_R_CNTRL) & (1 << 8); + u32 val; + +@@ -1122,9 +1177,7 @@ fec_stop(struct net_device *ndev) + val = readl(fep->hwp + FEC_ECNTRL); + val |= (FEC_ECR_MAGICEN | FEC_ECR_SLEEP); + writel(val, fep->hwp + FEC_ECNTRL); +- +- if (pdata && pdata->sleep_mode_enable) +- pdata->sleep_mode_enable(true); ++ fec_enet_stop_mode(fep, true); + } + writel(fep->phy_speed, fep->hwp + FEC_MII_SPEED); + +@@ -3347,6 +3400,37 @@ static int fec_enet_get_irq_cnt(struct platform_device *pdev) + return irq_cnt; + } + ++static int fec_enet_init_stop_mode(struct fec_enet_private *fep, ++ struct fec_devinfo *dev_info, ++ struct device_node *np) ++{ ++ struct device_node *gpr_np; ++ int ret = 0; ++ ++ if (!dev_info) ++ return 0; ++ ++ gpr_np = of_parse_phandle(np, "gpr", 0); ++ if (!gpr_np) ++ return 0; ++ ++ fep->stop_gpr.gpr = syscon_node_to_regmap(gpr_np); ++ if (IS_ERR(fep->stop_gpr.gpr)) { ++ dev_err(&fep->pdev->dev, "could not find gpr regmap\n"); ++ ret = PTR_ERR(fep->stop_gpr.gpr); ++ fep->stop_gpr.gpr = NULL; ++ goto out; ++ } ++ ++ fep->stop_gpr.reg = dev_info->stop_gpr_reg; ++ fep->stop_gpr.bit = dev_info->stop_gpr_bit; ++ ++out: ++ of_node_put(gpr_np); ++ ++ return ret; ++} ++ + static int + fec_probe(struct platform_device *pdev) + { +@@ -3362,6 +3446,7 @@ fec_probe(struct platform_device *pdev) + int num_rx_qs; + char irq_name[8]; + int irq_cnt; ++ struct fec_devinfo *dev_info; + + fec_enet_get_queue_num(pdev, &num_tx_qs, &num_rx_qs); + +@@ -3379,7 +3464,9 @@ fec_probe(struct platform_device *pdev) + of_id = of_match_device(fec_dt_ids, &pdev->dev); + if (of_id) + pdev->id_entry = of_id->data; +- fep->quirks = pdev->id_entry->driver_data; ++ dev_info = (struct fec_devinfo *)pdev->id_entry->driver_data; ++ if (dev_info) ++ fep->quirks = dev_info->quirks; + + fep->netdev = ndev; + fep->num_rx_queues = num_rx_qs; +@@ -3414,6 +3501,10 @@ fec_probe(struct platform_device *pdev) + if (of_get_property(np, "fsl,magic-packet", NULL)) + fep->wol_flag |= FEC_WOL_HAS_MAGIC_PACKET; + ++ ret = fec_enet_init_stop_mode(fep, dev_info, np); ++ if (ret) ++ goto failed_stop_mode; ++ + phy_node = of_parse_phandle(np, "phy-handle", 0); + if (!phy_node && of_phy_is_fixed_link(np)) { + ret = of_phy_register_fixed_link(np); +@@ -3583,6 +3674,7 @@ failed_clk: + if (of_phy_is_fixed_link(np)) + of_phy_deregister_fixed_link(np); + of_node_put(phy_node); ++failed_stop_mode: + failed_phy: + dev_id--; + failed_ioremap: +@@ -3660,7 +3752,6 @@ static int __maybe_unused fec_resume(struct device *dev) + { + struct net_device *ndev = dev_get_drvdata(dev); + struct fec_enet_private *fep = netdev_priv(ndev); +- struct fec_platform_data *pdata = fep->pdev->dev.platform_data; + int ret; + int val; + +@@ -3678,8 +3769,8 @@ static int __maybe_unused fec_resume(struct device *dev) + goto failed_clk; + } + if (fep->wol_flag & FEC_WOL_FLAG_ENABLE) { +- if (pdata && pdata->sleep_mode_enable) +- pdata->sleep_mode_enable(false); ++ fec_enet_stop_mode(fep, false); ++ + val = readl(fep->hwp + FEC_ECNTRL); + val &= ~(FEC_ECR_MAGICEN | FEC_ECR_SLEEP); + writel(val, fep->hwp + FEC_ECNTRL); +-- +2.20.1 + diff --git a/queue-4.19/objtool-fix-config_ubsan_trap-unreachable-warnings.patch b/queue-4.19/objtool-fix-config_ubsan_trap-unreachable-warnings.patch new file mode 100644 index 00000000000..89b36e1e1f7 --- /dev/null +++ b/queue-4.19/objtool-fix-config_ubsan_trap-unreachable-warnings.patch @@ -0,0 +1,69 @@ +From 0fb522f829bd9293106d77d1cc10f526883c8ebd Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 1 Apr 2020 13:23:25 -0500 +Subject: objtool: Fix CONFIG_UBSAN_TRAP unreachable warnings + +From: Josh Poimboeuf + +[ Upstream commit bd841d6154f5f41f8a32d3c1b0bc229e326e640a ] + +CONFIG_UBSAN_TRAP causes GCC to emit a UD2 whenever it encounters an +unreachable code path. This includes __builtin_unreachable(). Because +the BUG() macro uses __builtin_unreachable() after it emits its own UD2, +this results in a double UD2. In this case objtool rightfully detects +that the second UD2 is unreachable: + + init/main.o: warning: objtool: repair_env_string()+0x1c8: unreachable instruction + +We weren't able to figure out a way to get rid of the double UD2s, so +just silence the warning. + +Reported-by: Randy Dunlap +Signed-off-by: Josh Poimboeuf +Signed-off-by: Borislav Petkov +Reviewed-by: Kees Cook +Reviewed-by: Miroslav Benes +Acked-by: Peter Zijlstra (Intel) +Link: https://lkml.kernel.org/r/6653ad73c6b59c049211bd7c11ed3809c20ee9f5.1585761021.git.jpoimboe@redhat.com +Signed-off-by: Sasha Levin +--- + tools/objtool/check.c | 17 +++++++++++++++-- + 1 file changed, 15 insertions(+), 2 deletions(-) + +diff --git a/tools/objtool/check.c b/tools/objtool/check.c +index 9479c74af9baf..4613d796492ab 100644 +--- a/tools/objtool/check.c ++++ b/tools/objtool/check.c +@@ -2086,14 +2086,27 @@ static bool ignore_unreachable_insn(struct instruction *insn) + !strcmp(insn->sec->name, ".altinstr_aux")) + return true; + ++ if (!insn->func) ++ return false; ++ ++ /* ++ * CONFIG_UBSAN_TRAP inserts a UD2 when it sees ++ * __builtin_unreachable(). The BUG() macro has an unreachable() after ++ * the UD2, which causes GCC's undefined trap logic to emit another UD2 ++ * (or occasionally a JMP to UD2). ++ */ ++ if (list_prev_entry(insn, list)->dead_end && ++ (insn->type == INSN_BUG || ++ (insn->type == INSN_JUMP_UNCONDITIONAL && ++ insn->jump_dest && insn->jump_dest->type == INSN_BUG))) ++ return true; ++ + /* + * Check if this (or a subsequent) instruction is related to + * CONFIG_UBSAN or CONFIG_KASAN. + * + * End the search at 5 instructions to avoid going into the weeds. + */ +- if (!insn->func) +- return false; + for (i = 0; i < 5; i++) { + + if (is_kasan_insn(insn) || is_ubsan_insn(insn)) +-- +2.20.1 + diff --git a/queue-4.19/objtool-support-clang-non-section-symbols-in-orc-dum.patch b/queue-4.19/objtool-support-clang-non-section-symbols-in-orc-dum.patch new file mode 100644 index 00000000000..e699a0cb5fc --- /dev/null +++ b/queue-4.19/objtool-support-clang-non-section-symbols-in-orc-dum.patch @@ -0,0 +1,111 @@ +From b6fa7c0d37efea6d69497bc4447a69465e7ea437 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 1 Apr 2020 13:23:26 -0500 +Subject: objtool: Support Clang non-section symbols in ORC dump + +From: Josh Poimboeuf + +[ Upstream commit 8782e7cab51b6bf01a5a86471dd82228af1ac185 ] + +Historically, the relocation symbols for ORC entries have only been +section symbols: + + .text+0: sp:sp+8 bp:(und) type:call end:0 + +However, the Clang assembler is aggressive about stripping section +symbols. In that case we will need to use function symbols: + + freezing_slow_path+0: sp:sp+8 bp:(und) type:call end:0 + +In preparation for the generation of such entries in "objtool orc +generate", add support for reading them in "objtool orc dump". + +Signed-off-by: Josh Poimboeuf +Signed-off-by: Borislav Petkov +Reviewed-by: Miroslav Benes +Acked-by: Peter Zijlstra (Intel) +Link: https://lkml.kernel.org/r/b811b5eb1a42602c3b523576dc5efab9ad1c174d.1585761021.git.jpoimboe@redhat.com +Signed-off-by: Sasha Levin +--- + tools/objtool/orc_dump.c | 44 ++++++++++++++++++++++++---------------- + 1 file changed, 27 insertions(+), 17 deletions(-) + +diff --git a/tools/objtool/orc_dump.c b/tools/objtool/orc_dump.c +index faa444270ee3a..1a3e774941f8e 100644 +--- a/tools/objtool/orc_dump.c ++++ b/tools/objtool/orc_dump.c +@@ -78,7 +78,7 @@ int orc_dump(const char *_objname) + char *name; + size_t nr_sections; + Elf64_Addr orc_ip_addr = 0; +- size_t shstrtab_idx; ++ size_t shstrtab_idx, strtab_idx = 0; + Elf *elf; + Elf_Scn *scn; + GElf_Shdr sh; +@@ -139,6 +139,8 @@ int orc_dump(const char *_objname) + + if (!strcmp(name, ".symtab")) { + symtab = data; ++ } else if (!strcmp(name, ".strtab")) { ++ strtab_idx = i; + } else if (!strcmp(name, ".orc_unwind")) { + orc = data->d_buf; + orc_size = sh.sh_size; +@@ -150,7 +152,7 @@ int orc_dump(const char *_objname) + } + } + +- if (!symtab || !orc || !orc_ip) ++ if (!symtab || !strtab_idx || !orc || !orc_ip) + return 0; + + if (orc_size % sizeof(*orc) != 0) { +@@ -171,21 +173,29 @@ int orc_dump(const char *_objname) + return -1; + } + +- scn = elf_getscn(elf, sym.st_shndx); +- if (!scn) { +- WARN_ELF("elf_getscn"); +- return -1; +- } +- +- if (!gelf_getshdr(scn, &sh)) { +- WARN_ELF("gelf_getshdr"); +- return -1; +- } +- +- name = elf_strptr(elf, shstrtab_idx, sh.sh_name); +- if (!name || !*name) { +- WARN_ELF("elf_strptr"); +- return -1; ++ if (GELF_ST_TYPE(sym.st_info) == STT_SECTION) { ++ scn = elf_getscn(elf, sym.st_shndx); ++ if (!scn) { ++ WARN_ELF("elf_getscn"); ++ return -1; ++ } ++ ++ if (!gelf_getshdr(scn, &sh)) { ++ WARN_ELF("gelf_getshdr"); ++ return -1; ++ } ++ ++ name = elf_strptr(elf, shstrtab_idx, sh.sh_name); ++ if (!name) { ++ WARN_ELF("elf_strptr"); ++ return -1; ++ } ++ } else { ++ name = elf_strptr(elf, strtab_idx, sym.st_name); ++ if (!name) { ++ WARN_ELF("elf_strptr"); ++ return -1; ++ } + } + + printf("%s+%llx:", name, (unsigned long long)rela.r_addend); +-- +2.20.1 + diff --git a/queue-4.19/scsi-target-fix-pr-in-read-full-status-for-fc.patch b/queue-4.19/scsi-target-fix-pr-in-read-full-status-for-fc.patch new file mode 100644 index 00000000000..e5202f951e2 --- /dev/null +++ b/queue-4.19/scsi-target-fix-pr-in-read-full-status-for-fc.patch @@ -0,0 +1,41 @@ +From 037eed050d88ee1b692f291f12ae602587bc0d87 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 8 Apr 2020 15:26:10 +0200 +Subject: scsi: target: fix PR IN / READ FULL STATUS for FC + +From: Bodo Stroesser + +[ Upstream commit 8fed04eb79a74cbf471dfaa755900a51b37273ab ] + +Creation of the response to READ FULL STATUS fails for FC based +reservations. Reason is the too high loop limit (< 24) in +fc_get_pr_transport_id(). The string representation of FC WWPN is 23 chars +long only ("11:22:33:44:55:66:77:88"). So when i is 23, the loop body is +executed a last time for the ending '\0' of the string and thus hex2bin() +reports an error. + +Link: https://lore.kernel.org/r/20200408132610.14623-3-bstroesser@ts.fujitsu.com +Signed-off-by: Bodo Stroesser +Reviewed-by: Mike Christie +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/target/target_core_fabric_lib.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/target/target_core_fabric_lib.c b/drivers/target/target_core_fabric_lib.c +index 10fae26b44add..939c6212d2ac5 100644 +--- a/drivers/target/target_core_fabric_lib.c ++++ b/drivers/target/target_core_fabric_lib.c +@@ -76,7 +76,7 @@ static int fc_get_pr_transport_id( + * encoded TransportID. + */ + ptr = &se_nacl->initiatorname[0]; +- for (i = 0; i < 24; ) { ++ for (i = 0; i < 23; ) { + if (!strncmp(&ptr[i], ":", 1)) { + i++; + continue; +-- +2.20.1 + diff --git a/queue-4.19/scsi-target-tcmu-reset_ring-should-reset-tcmu_dev_bi.patch b/queue-4.19/scsi-target-tcmu-reset_ring-should-reset-tcmu_dev_bi.patch new file mode 100644 index 00000000000..7af41784376 --- /dev/null +++ b/queue-4.19/scsi-target-tcmu-reset_ring-should-reset-tcmu_dev_bi.patch @@ -0,0 +1,43 @@ +From 78a9ce89bfa8ef6c1563ae8d33f59024f0c93a99 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 9 Apr 2020 12:10:26 +0200 +Subject: scsi: target: tcmu: reset_ring should reset TCMU_DEV_BIT_BROKEN + +From: Bodo Stroesser + +[ Upstream commit 066f79a5fd6d1b9a5cc57b5cd445b3e4bb68a5b2 ] + +In case command ring buffer becomes inconsistent, tcmu sets device flag +TCMU_DEV_BIT_BROKEN. If the bit is set, tcmu rejects new commands from LIO +core with TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE, and no longer processes +completions from the ring. The reset_ring attribute can be used to +completely clean up the command ring, so after reset_ring the ring no +longer is inconsistent. + +Therefore reset_ring also should reset bit TCMU_DEV_BIT_BROKEN to allow +normal processing. + +Link: https://lore.kernel.org/r/20200409101026.17872-1-bstroesser@ts.fujitsu.com +Acked-by: Mike Christie +Signed-off-by: Bodo Stroesser +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/target/target_core_user.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/target/target_core_user.c b/drivers/target/target_core_user.c +index 7ee0a75ce4526..eff1e36ca03c2 100644 +--- a/drivers/target/target_core_user.c ++++ b/drivers/target/target_core_user.c +@@ -2067,6 +2067,7 @@ static void tcmu_reset_ring(struct tcmu_dev *udev, u8 err_level) + mb->cmd_tail = 0; + mb->cmd_head = 0; + tcmu_flush_dcache_range(mb, sizeof(*mb)); ++ clear_bit(TCMU_DEV_BIT_BROKEN, &udev->flags); + + del_timer(&udev->cmd_timer); + +-- +2.20.1 + diff --git a/queue-4.19/series b/queue-4.19/series index cbb6d831579..d272ec17c2d 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -24,3 +24,21 @@ perf-core-fix-parent-pid-tid-in-task-exit-events.patch bpf-x86_32-fix-incorrect-encoding-in-bpf_ldx-zero-extension.patch mm-shmem-disable-interrupt-when-acquiring-info-lock-in-userfaultfd_copy-path.patch xfs-clear-pf_memalloc-before-exiting-xfsaild-thread.patch +bpf-x86-fix-encoding-for-lower-8-bit-registers-in-bp.patch +signal-avoid-corrupting-si_pid-and-si_uid-in-do_noti.patch +net-fec-set-gpr-bit-on-suspend-by-dt-configuration.patch +x86-hyperv-report-value-of-misc_features.patch +xfs-fix-partially-uninitialized-structure-in-xfs_ref.patch +alsa-hda-keep-the-controller-initialization-even-if-.patch +alsa-hda-explicitly-permit-using-autosuspend-if-runt.patch +scsi-target-fix-pr-in-read-full-status-for-fc.patch +scsi-target-tcmu-reset_ring-should-reset-tcmu_dev_bi.patch +objtool-fix-config_ubsan_trap-unreachable-warnings.patch +objtool-support-clang-non-section-symbols-in-orc-dum.patch +xen-xenbus-ensure-xenbus_map_ring_valloc-returns-pro.patch +alsa-hda-call-runtime_allow-for-all-hda-controllers.patch +arm64-delete-the-space-separator-in-__emit_inst.patch +ext4-use-matching-invalidatepage-in-ext4_writepage.patch +ext4-increase-wait-time-needed-before-reuse-of-delet.patch +ext4-convert-bug_on-s-to-warn_on-s-in-mballoc.c.patch +hwmon-jc42-fix-name-to-have-no-illegal-characters.patch diff --git a/queue-4.19/signal-avoid-corrupting-si_pid-and-si_uid-in-do_noti.patch b/queue-4.19/signal-avoid-corrupting-si_pid-and-si_uid-in-do_noti.patch new file mode 100644 index 00000000000..d072c2f329b --- /dev/null +++ b/queue-4.19/signal-avoid-corrupting-si_pid-and-si_uid-in-do_noti.patch @@ -0,0 +1,184 @@ +From e76546cdf96e6e072b9d23dae3316511f5396c89 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 20 Apr 2020 11:41:50 -0500 +Subject: signal: Avoid corrupting si_pid and si_uid in do_notify_parent + +From: Eric W. Biederman + +[ Upstream commit 61e713bdca3678e84815f2427f7a063fc353a1fc ] + +Christof Meerwald writes: +> Hi, +> +> this is probably related to commit +> 7a0cf094944e2540758b7f957eb6846d5126f535 (signal: Correct namespace +> fixups of si_pid and si_uid). +> +> With a 5.6.5 kernel I am seeing SIGCHLD signals that don't include a +> properly set si_pid field - this seems to happen for multi-threaded +> child processes. +> +> A simple test program (based on the sample from the signalfd man page): +> +> #include +> #include +> #include +> #include +> #include +> #include +> +> #define handle_error(msg) \ +> do { perror(msg); exit(EXIT_FAILURE); } while (0) +> +> int main(int argc, char *argv[]) +> { +> sigset_t mask; +> int sfd; +> struct signalfd_siginfo fdsi; +> ssize_t s; +> +> sigemptyset(&mask); +> sigaddset(&mask, SIGCHLD); +> +> if (sigprocmask(SIG_BLOCK, &mask, NULL) == -1) +> handle_error("sigprocmask"); +> +> pid_t chldpid; +> char *chldargv[] = { "./sfdclient", NULL }; +> posix_spawn(&chldpid, "./sfdclient", NULL, NULL, chldargv, NULL); +> +> sfd = signalfd(-1, &mask, 0); +> if (sfd == -1) +> handle_error("signalfd"); +> +> for (;;) { +> s = read(sfd, &fdsi, sizeof(struct signalfd_siginfo)); +> if (s != sizeof(struct signalfd_siginfo)) +> handle_error("read"); +> +> if (fdsi.ssi_signo == SIGCHLD) { +> printf("Got SIGCHLD %d %d %d %d\n", +> fdsi.ssi_status, fdsi.ssi_code, +> fdsi.ssi_uid, fdsi.ssi_pid); +> return 0; +> } else { +> printf("Read unexpected signal\n"); +> } +> } +> } +> +> +> and a multi-threaded client to test with: +> +> #include +> #include +> +> void *f(void *arg) +> { +> sleep(100); +> } +> +> int main() +> { +> pthread_t t[8]; +> +> for (int i = 0; i != 8; ++i) +> { +> pthread_create(&t[i], NULL, f, NULL); +> } +> } +> +> I tried to do a bit of debugging and what seems to be happening is +> that +> +> /* From an ancestor pid namespace? */ +> if (!task_pid_nr_ns(current, task_active_pid_ns(t))) { +> +> fails inside task_pid_nr_ns because the check for "pid_alive" fails. +> +> This code seems to be called from do_notify_parent and there we +> actually have "tsk != current" (I am assuming both are threads of the +> current process?) + +I instrumented the code with a warning and received the following backtrace: +> WARNING: CPU: 0 PID: 777 at kernel/pid.c:501 __task_pid_nr_ns.cold.6+0xc/0x15 +> Modules linked in: +> CPU: 0 PID: 777 Comm: sfdclient Not tainted 5.7.0-rc1userns+ #2924 +> Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 +> RIP: 0010:__task_pid_nr_ns.cold.6+0xc/0x15 +> Code: ff 66 90 48 83 ec 08 89 7c 24 04 48 8d 7e 08 48 8d 74 24 04 e8 9a b6 44 00 48 83 c4 08 c3 48 c7 c7 59 9f ac 82 e8 c2 c4 04 00 <0f> 0b e9 3fd +> RSP: 0018:ffffc9000042fbf8 EFLAGS: 00010046 +> RAX: 000000000000000c RBX: 0000000000000000 RCX: ffffc9000042faf4 +> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff81193d29 +> RBP: ffffc9000042fc18 R08: 0000000000000000 R09: 0000000000000001 +> R10: 000000100f938416 R11: 0000000000000309 R12: ffff8880b941c140 +> R13: 0000000000000000 R14: 0000000000000000 R15: ffff8880b941c140 +> FS: 0000000000000000(0000) GS:ffff8880bca00000(0000) knlGS:0000000000000000 +> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +> CR2: 00007f2e8c0a32e0 CR3: 0000000002e10000 CR4: 00000000000006f0 +> Call Trace: +> send_signal+0x1c8/0x310 +> do_notify_parent+0x50f/0x550 +> release_task.part.21+0x4fd/0x620 +> do_exit+0x6f6/0xaf0 +> do_group_exit+0x42/0xb0 +> get_signal+0x13b/0xbb0 +> do_signal+0x2b/0x670 +> ? __audit_syscall_exit+0x24d/0x2b0 +> ? rcu_read_lock_sched_held+0x4d/0x60 +> ? kfree+0x24c/0x2b0 +> do_syscall_64+0x176/0x640 +> ? trace_hardirqs_off_thunk+0x1a/0x1c +> entry_SYSCALL_64_after_hwframe+0x49/0xb3 + +The immediate problem is as Christof noticed that "pid_alive(current) == false". +This happens because do_notify_parent is called from the last thread to exit +in a process after that thread has been reaped. + +The bigger issue is that do_notify_parent can be called from any +process that manages to wait on a thread of a multi-threaded process +from wait_task_zombie. So any logic based upon current for +do_notify_parent is just nonsense, as current can be pretty much +anything. + +So change do_notify_parent to call __send_signal directly. + +Inspecting the code it appears this problem has existed since the pid +namespace support started handling this case in 2.6.30. This fix only +backports to 7a0cf094944e ("signal: Correct namespace fixups of si_pid and si_uid") +where the problem logic was moved out of __send_signal and into send_signal. + +Cc: stable@vger.kernel.org +Fixes: 6588c1e3ff01 ("signals: SI_USER: Masquerade si_pid when crossing pid ns boundary") +Ref: 921cf9f63089 ("signals: protect cinit from unblocked SIG_DFL signals") +Link: https://lore.kernel.org/lkml/20200419201336.GI22017@edge.cmeerw.net/ +Reported-by: Christof Meerwald +Acked-by: Oleg Nesterov +Acked-by: Christian Brauner +Signed-off-by: "Eric W. Biederman" +Signed-off-by: Sasha Levin +--- + kernel/signal.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/kernel/signal.c b/kernel/signal.c +index 6a56921181393..bb66bc46a26db 100644 +--- a/kernel/signal.c ++++ b/kernel/signal.c +@@ -1899,8 +1899,12 @@ bool do_notify_parent(struct task_struct *tsk, int sig) + if (psig->action[SIGCHLD-1].sa.sa_handler == SIG_IGN) + sig = 0; + } ++ /* ++ * Send with __send_signal as si_pid and si_uid are in the ++ * parent's namespaces. ++ */ + if (valid_signal(sig) && sig) +- __group_send_sig_info(sig, &info, tsk->parent); ++ __send_signal(sig, &info, tsk->parent, PIDTYPE_TGID, false); + __wake_up_parent(tsk, tsk->parent); + spin_unlock_irqrestore(&psig->siglock, flags); + +-- +2.20.1 + diff --git a/queue-4.19/x86-hyperv-report-value-of-misc_features.patch b/queue-4.19/x86-hyperv-report-value-of-misc_features.patch new file mode 100644 index 00000000000..acb3b31c043 --- /dev/null +++ b/queue-4.19/x86-hyperv-report-value-of-misc_features.patch @@ -0,0 +1,38 @@ +From ae57122cb78f1238095b4badcb200f9b40d96e30 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 7 Apr 2020 19:27:39 +0200 +Subject: x86: hyperv: report value of misc_features + +From: Olaf Hering + +[ Upstream commit 97d9f1c43bedd400301d6f1eff54d46e8c636e47 ] + +A few kernel features depend on ms_hyperv.misc_features, but unlike its +siblings ->features and ->hints, the value was never reported during boot. + +Signed-off-by: Olaf Hering +Link: https://lore.kernel.org/r/20200407172739.31371-1-olaf@aepfle.de +Signed-off-by: Wei Liu +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/cpu/mshyperv.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c +index fc93ae3255153..f8b0fa2dbe374 100644 +--- a/arch/x86/kernel/cpu/mshyperv.c ++++ b/arch/x86/kernel/cpu/mshyperv.c +@@ -214,8 +214,8 @@ static void __init ms_hyperv_init_platform(void) + ms_hyperv.misc_features = cpuid_edx(HYPERV_CPUID_FEATURES); + ms_hyperv.hints = cpuid_eax(HYPERV_CPUID_ENLIGHTMENT_INFO); + +- pr_info("Hyper-V: features 0x%x, hints 0x%x\n", +- ms_hyperv.features, ms_hyperv.hints); ++ pr_info("Hyper-V: features 0x%x, hints 0x%x, misc 0x%x\n", ++ ms_hyperv.features, ms_hyperv.hints, ms_hyperv.misc_features); + + ms_hyperv.max_vp_index = cpuid_eax(HYPERV_CPUID_IMPLEMENT_LIMITS); + ms_hyperv.max_lp_index = cpuid_ebx(HYPERV_CPUID_IMPLEMENT_LIMITS); +-- +2.20.1 + diff --git a/queue-4.19/xen-xenbus-ensure-xenbus_map_ring_valloc-returns-pro.patch b/queue-4.19/xen-xenbus-ensure-xenbus_map_ring_valloc-returns-pro.patch new file mode 100644 index 00000000000..7ef49a627b0 --- /dev/null +++ b/queue-4.19/xen-xenbus-ensure-xenbus_map_ring_valloc-returns-pro.patch @@ -0,0 +1,56 @@ +From 006e2449f5eb159600a6dbe04761d618ea5e6b2c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Mar 2020 09:03:58 +0100 +Subject: xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant + status + +From: Juergen Gross + +[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ] + +xenbus_map_ring_valloc() maps a ring page and returns the status of the +used grant (0 meaning success). + +There are Xen hypervisors which might return the value 1 for the status +of a failed grant mapping due to a bug. Some callers of +xenbus_map_ring_valloc() test for errors by testing the returned status +to be less than zero, resulting in no error detected and crashing later +due to a not available ring page. + +Set the return value of xenbus_map_ring_valloc() to GNTST_general_error +in case the grant status reported by Xen is greater than zero. + +This is part of XSA-316. + +Signed-off-by: Juergen Gross +Reviewed-by: Wei Liu +Link: https://lore.kernel.org/r/20200326080358.1018-1-jgross@suse.com +Signed-off-by: Juergen Gross +Signed-off-by: Sasha Levin +--- + drivers/xen/xenbus/xenbus_client.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c +index a1c17000129ba..e94a61eaeceb0 100644 +--- a/drivers/xen/xenbus/xenbus_client.c ++++ b/drivers/xen/xenbus/xenbus_client.c +@@ -450,7 +450,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn); + int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs, + unsigned int nr_grefs, void **vaddr) + { +- return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr); ++ int err; ++ ++ err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr); ++ /* Some hypervisors are buggy and can return 1. */ ++ if (err > 0) ++ err = GNTST_general_error; ++ ++ return err; + } + EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc); + +-- +2.20.1 + diff --git a/queue-4.19/xfs-fix-partially-uninitialized-structure-in-xfs_ref.patch b/queue-4.19/xfs-fix-partially-uninitialized-structure-in-xfs_ref.patch new file mode 100644 index 00000000000..683d14d2399 --- /dev/null +++ b/queue-4.19/xfs-fix-partially-uninitialized-structure-in-xfs_ref.patch @@ -0,0 +1,39 @@ +From de4d2c41ffc684a6f72b12bd7d674ce0df99ee12 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 12 Apr 2020 13:11:11 -0700 +Subject: xfs: fix partially uninitialized structure in + xfs_reflink_remap_extent + +From: Darrick J. Wong + +[ Upstream commit c142932c29e533ee892f87b44d8abc5719edceec ] + +In the reflink extent remap function, it turns out that uirec (the block +mapping corresponding only to the part of the passed-in mapping that got +unmapped) was not fully initialized. Specifically, br_state was not +being copied from the passed-in struct to the uirec. This could lead to +unpredictable results such as the reflinked mapping being marked +unwritten in the destination file. + +Signed-off-by: Darrick J. Wong +Reviewed-by: Brian Foster +Signed-off-by: Sasha Levin +--- + fs/xfs/xfs_reflink.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c +index f3c393f309e19..6622652a85a80 100644 +--- a/fs/xfs/xfs_reflink.c ++++ b/fs/xfs/xfs_reflink.c +@@ -1058,6 +1058,7 @@ xfs_reflink_remap_extent( + uirec.br_startblock = irec->br_startblock + rlen; + uirec.br_startoff = irec->br_startoff + rlen; + uirec.br_blockcount = unmap_len - rlen; ++ uirec.br_state = irec->br_state; + unmap_len = rlen; + + /* If this isn't a real mapping, we're done. */ +-- +2.20.1 +