From: Greg Kroah-Hartman Date: Sat, 13 Mar 2021 13:44:46 +0000 (+0100) Subject: 5.4-stable patches X-Git-Tag: v4.4.262~59 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=b728d2eb56eae4164a908eec27ee78d91cc0cf9e;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: alsa-hda-avoid-spurious-unsol-event-handling-during-s3-s4.patch alsa-hda-ca0132-add-sound-blasterx-ae-5-plus-support.patch alsa-hda-drop-the-batch-workaround-for-amd-controllers.patch alsa-hda-flush-pending-unsolicited-events-before-suspend.patch alsa-hda-hdmi-cancel-pending-works-before-suspend.patch alsa-usb-add-plantronics-c320-m-usb-ctrl-msg-delay-quirk.patch alsa-usb-audio-apply-the-control-quirk-to-plantronics-headsets.patch alsa-usb-audio-fix-cannot-get-freq-eq-errors-on-dell-ae515-sound-bar.patch arm64-kasan-fix-page_alloc-tagging-with-debug_virtual.patch mmc-core-fix-partition-switch-time-for-emmc.patch mmc-cqhci-fix-random-crash-when-remove-mmc-module-card.patch revert-95ebabde382c-capabilities-don-t-allow-writing-ambiguous-v3-file-capabilities.patch s390-dasd-fix-hanging-dasd-driver-unbind.patch s390-dasd-fix-hanging-io-request-during-dasd-driver-unbind.patch software-node-fix-node-registration.patch --- diff --git a/queue-5.4/alsa-hda-avoid-spurious-unsol-event-handling-during-s3-s4.patch b/queue-5.4/alsa-hda-avoid-spurious-unsol-event-handling-during-s3-s4.patch new file mode 100644 index 00000000000..dbc5c3870df --- /dev/null +++ b/queue-5.4/alsa-hda-avoid-spurious-unsol-event-handling-during-s3-s4.patch @@ -0,0 +1,44 @@ +From 5ff9dde42e8c72ed8102eb8cb62e03f9dc2103ab Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Wed, 10 Mar 2021 12:28:08 +0100 +Subject: ALSA: hda: Avoid spurious unsol event handling during S3/S4 + +From: Takashi Iwai + +commit 5ff9dde42e8c72ed8102eb8cb62e03f9dc2103ab upstream. + +When HD-audio bus receives unsolicited events during its system +suspend/resume (S3 and S4) phase, the controller driver may still try +to process events although the codec chips are already (or yet) +powered down. This might screw up the codec communication, resulting +in CORB/RIRB errors. Such events should be rather skipped, as the +codec chip status such as the jack status will be fully refreshed at +the system resume time. + +Since we're tracking the system suspend/resume state in codec +power.power_state field, let's add the check in the common unsol event +handler entry point to filter out such events. + +BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1182377 +Tested-by: Abhishek Sahu +Cc: # 183ab39eb0ea: ALSA: hda: Initialize power_state +Link: https://lore.kernel.org/r/20210310112809.9215-3-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/hda_bind.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/sound/pci/hda/hda_bind.c ++++ b/sound/pci/hda/hda_bind.c +@@ -47,6 +47,10 @@ static void hda_codec_unsol_event(struct + if (codec->bus->shutdown) + return; + ++ /* ignore unsol events during system suspend/resume */ ++ if (codec->core.dev.power.power_state.event != PM_EVENT_ON) ++ return; ++ + if (codec->patch_ops.unsol_event) + codec->patch_ops.unsol_event(codec, ev); + } diff --git a/queue-5.4/alsa-hda-ca0132-add-sound-blasterx-ae-5-plus-support.patch b/queue-5.4/alsa-hda-ca0132-add-sound-blasterx-ae-5-plus-support.patch new file mode 100644 index 00000000000..98cfd3aed4c --- /dev/null +++ b/queue-5.4/alsa-hda-ca0132-add-sound-blasterx-ae-5-plus-support.patch @@ -0,0 +1,31 @@ +From f15c5c11abfbf8909eb30598315ecbec2311cfdc Mon Sep 17 00:00:00 2001 +From: Simeon Simeonoff +Date: Mon, 8 Mar 2021 20:48:35 +0200 +Subject: ALSA: hda/ca0132: Add Sound BlasterX AE-5 Plus support + +From: Simeon Simeonoff + +commit f15c5c11abfbf8909eb30598315ecbec2311cfdc upstream. + +The new AE-5 Plus model has a different Subsystem ID compared to the +non-plus model. Adding the new id to the list of quirks. + +Signed-off-by: Simeon Simeonoff +Cc: +Link: https://lore.kernel.org/r/998cafbe10b648f724ee33570553f2d780a38963.camel@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_ca0132.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_ca0132.c ++++ b/sound/pci/hda/patch_ca0132.c +@@ -1185,6 +1185,7 @@ static const struct snd_pci_quirk ca0132 + SND_PCI_QUIRK(0x1102, 0x0013, "Recon3D", QUIRK_R3D), + SND_PCI_QUIRK(0x1102, 0x0018, "Recon3D", QUIRK_R3D), + SND_PCI_QUIRK(0x1102, 0x0051, "Sound Blaster AE-5", QUIRK_AE5), ++ SND_PCI_QUIRK(0x1102, 0x0191, "Sound Blaster AE-5 Plus", QUIRK_AE5), + SND_PCI_QUIRK(0x1102, 0x0081, "Sound Blaster AE-7", QUIRK_AE7), + {} + }; diff --git a/queue-5.4/alsa-hda-drop-the-batch-workaround-for-amd-controllers.patch b/queue-5.4/alsa-hda-drop-the-batch-workaround-for-amd-controllers.patch new file mode 100644 index 00000000000..5fc90051e87 --- /dev/null +++ b/queue-5.4/alsa-hda-drop-the-batch-workaround-for-amd-controllers.patch @@ -0,0 +1,46 @@ +From 28e96c1693ec1cdc963807611f8b5ad400431e82 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 8 Mar 2021 17:07:26 +0100 +Subject: ALSA: hda: Drop the BATCH workaround for AMD controllers + +From: Takashi Iwai + +commit 28e96c1693ec1cdc963807611f8b5ad400431e82 upstream. + +The commit c02f77d32d2c ("ALSA: hda - Workaround for crackled sound on +AMD controller (1022:1457)") introduced a few workarounds for the +recent AMD HD-audio controller, and one of them is the forced BATCH +PCM mode so that PulseAudio avoids the timer-based scheduling. This +was thought to cover for some badly working applications, but this +actually worsens for more others. In total, this wasn't a good idea +to enforce it. + +This is a partial revert of the commit above for dropping the PCM +BATCH enforcement part to recover from the regression again. + +Fixes: c02f77d32d2c ("ALSA: hda - Workaround for crackled sound on AMD controller (1022:1457)") +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303 +Cc: +Link: https://lore.kernel.org/r/20210308160726.22930-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/hda_controller.c | 7 ------- + 1 file changed, 7 deletions(-) + +--- a/sound/pci/hda/hda_controller.c ++++ b/sound/pci/hda/hda_controller.c +@@ -613,13 +613,6 @@ static int azx_pcm_open(struct snd_pcm_s + 20, + 178000000); + +- /* by some reason, the playback stream stalls on PulseAudio with +- * tsched=1 when a capture stream triggers. Until we figure out the +- * real cause, disable tsched mode by telling the PCM info flag. +- */ +- if (chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND) +- runtime->hw.info |= SNDRV_PCM_INFO_BATCH; +- + if (chip->align_buffer_size) + /* constrain buffer sizes to be multiple of 128 + bytes. This is more efficient in terms of memory diff --git a/queue-5.4/alsa-hda-flush-pending-unsolicited-events-before-suspend.patch b/queue-5.4/alsa-hda-flush-pending-unsolicited-events-before-suspend.patch new file mode 100644 index 00000000000..19ffc3bb5c8 --- /dev/null +++ b/queue-5.4/alsa-hda-flush-pending-unsolicited-events-before-suspend.patch @@ -0,0 +1,40 @@ +From 13661fc48461282e43fe8f76bf5bf449b3d40687 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Wed, 10 Mar 2021 12:28:07 +0100 +Subject: ALSA: hda: Flush pending unsolicited events before suspend + +From: Takashi Iwai + +commit 13661fc48461282e43fe8f76bf5bf449b3d40687 upstream. + +The HD-audio controller driver processes the unsolicited events via +its work asynchronously, and this might be pending when the system +goes to suspend. When a lengthy event handling like ELD byte reads is +running, this might trigger unexpected accesses among suspend/resume +procedure, typically seen with Nvidia driver that still requires the +handling via unsolicited event verbs for ELD updates. + +This patch adds the flush of unsol_work to assure that pending events +are processed before going into suspend. + +Buglink: https://bugzilla.suse.com/show_bug.cgi?id=1182377 +Reported-and-tested-by: Abhishek Sahu +Cc: +Link: https://lore.kernel.org/r/20210310112809.9215-2-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/hda_intel.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/sound/pci/hda/hda_intel.c ++++ b/sound/pci/hda/hda_intel.c +@@ -1025,6 +1025,8 @@ static int azx_prepare(struct device *de + chip = card->private_data; + chip->pm_prepared = 1; + ++ flush_work(&azx_bus(chip)->unsol_work); ++ + /* HDA controller always requires different WAKEEN for runtime suspend + * and system suspend, so don't use direct-complete here. + */ diff --git a/queue-5.4/alsa-hda-hdmi-cancel-pending-works-before-suspend.patch b/queue-5.4/alsa-hda-hdmi-cancel-pending-works-before-suspend.patch new file mode 100644 index 00000000000..f266ec18087 --- /dev/null +++ b/queue-5.4/alsa-hda-hdmi-cancel-pending-works-before-suspend.patch @@ -0,0 +1,57 @@ +From eea46a0879bcca23e15071f9968c0f6e6596e470 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Wed, 10 Mar 2021 12:28:09 +0100 +Subject: ALSA: hda/hdmi: Cancel pending works before suspend + +From: Takashi Iwai + +commit eea46a0879bcca23e15071f9968c0f6e6596e470 upstream. + +The per_pin->work might be still floating at the suspend, and this may +hit the access to the hardware at an unexpected timing. Cancel the +work properly at the suspend callback for avoiding the buggy access. + +Note that the bug doesn't trigger easily in the recent kernels since +the work is queued only when the repoll count is set, and usually it's +only at the resume callback, but it's still possible to hit in +theory. + +BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1182377 +Reported-and-tested-by: Abhishek Sahu +Cc: +Link: https://lore.kernel.org/r/20210310112809.9215-4-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_hdmi.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +--- a/sound/pci/hda/patch_hdmi.c ++++ b/sound/pci/hda/patch_hdmi.c +@@ -2382,6 +2382,18 @@ static void generic_hdmi_free(struct hda + } + + #ifdef CONFIG_PM ++static int generic_hdmi_suspend(struct hda_codec *codec) ++{ ++ struct hdmi_spec *spec = codec->spec; ++ int pin_idx; ++ ++ for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) { ++ struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx); ++ cancel_delayed_work_sync(&per_pin->work); ++ } ++ return 0; ++} ++ + static int generic_hdmi_resume(struct hda_codec *codec) + { + struct hdmi_spec *spec = codec->spec; +@@ -2405,6 +2417,7 @@ static const struct hda_codec_ops generi + .build_controls = generic_hdmi_build_controls, + .unsol_event = hdmi_unsol_event, + #ifdef CONFIG_PM ++ .suspend = generic_hdmi_suspend, + .resume = generic_hdmi_resume, + #endif + }; diff --git a/queue-5.4/alsa-usb-add-plantronics-c320-m-usb-ctrl-msg-delay-quirk.patch b/queue-5.4/alsa-usb-add-plantronics-c320-m-usb-ctrl-msg-delay-quirk.patch new file mode 100644 index 00000000000..207b9f9f6b2 --- /dev/null +++ b/queue-5.4/alsa-usb-add-plantronics-c320-m-usb-ctrl-msg-delay-quirk.patch @@ -0,0 +1,42 @@ +From fc7c5c208eb7bc2df3a9f4234f14eca250001cb6 Mon Sep 17 00:00:00 2001 +From: John Ernberg +Date: Wed, 3 Mar 2021 18:14:39 +0000 +Subject: ALSA: usb: Add Plantronics C320-M USB ctrl msg delay quirk + +From: John Ernberg + +commit fc7c5c208eb7bc2df3a9f4234f14eca250001cb6 upstream. + +The microphone in the Plantronics C320-M headset will randomly +fail to initialize properly, at least when using Microsoft Teams. +Introducing a 20ms delay on the control messages appears to +resolve the issue. + +Link: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1065 +Tested-by: Andreas Kempe +Signed-off-by: John Ernberg +Cc: +Link: https://lore.kernel.org/r/20210303181405.39835-1-john.ernberg@actia.se +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/quirks.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/sound/usb/quirks.c ++++ b/sound/usb/quirks.c +@@ -1604,6 +1604,14 @@ void snd_usb_ctl_msg_quirk(struct usb_de + && (requesttype & USB_TYPE_MASK) == USB_TYPE_CLASS) + msleep(20); + ++ /* ++ * Plantronics C320-M needs a delay to avoid random ++ * microhpone failures. ++ */ ++ if (chip->usb_id == USB_ID(0x047f, 0xc025) && ++ (requesttype & USB_TYPE_MASK) == USB_TYPE_CLASS) ++ msleep(20); ++ + /* Zoom R16/24, many Logitech(at least H650e/H570e/BCC950), + * Jabra 550a, Kingston HyperX needs a tiny delay here, + * otherwise requests like get/set frequency return diff --git a/queue-5.4/alsa-usb-audio-apply-the-control-quirk-to-plantronics-headsets.patch b/queue-5.4/alsa-usb-audio-apply-the-control-quirk-to-plantronics-headsets.patch new file mode 100644 index 00000000000..9c08b07647f --- /dev/null +++ b/queue-5.4/alsa-usb-audio-apply-the-control-quirk-to-plantronics-headsets.patch @@ -0,0 +1,43 @@ +From 06abcb18b3a021ba1a3f2020cbefb3ed04e59e72 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Thu, 4 Mar 2021 09:50:09 +0100 +Subject: ALSA: usb-audio: Apply the control quirk to Plantronics headsets + +From: Takashi Iwai + +commit 06abcb18b3a021ba1a3f2020cbefb3ed04e59e72 upstream. + +Other Plantronics headset models seem requiring the same workaround as +C320-M to add the 20ms delay for the control messages, too. Apply the +workaround generically for devices with the vendor ID 0x047f. + +Note that the problem didn't surface before 5.11 just with luck. +Since 5.11 got a big code rewrite about the stream handling, the +parameter setup procedure has changed, and this seemed triggering the +problem more often. + +BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1182552 +Cc: +Link: https://lore.kernel.org/r/20210304085009.4770-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/quirks.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/sound/usb/quirks.c ++++ b/sound/usb/quirks.c +@@ -1606,10 +1606,10 @@ void snd_usb_ctl_msg_quirk(struct usb_de + msleep(20); + + /* +- * Plantronics C320-M needs a delay to avoid random +- * microhpone failures. ++ * Plantronics headsets (C320, C320-M, etc) need a delay to avoid ++ * random microhpone failures. + */ +- if (chip->usb_id == USB_ID(0x047f, 0xc025) && ++ if (USB_ID_VENDOR(chip->usb_id) == 0x047f && + (requesttype & USB_TYPE_MASK) == USB_TYPE_CLASS) + msleep(20); + diff --git a/queue-5.4/alsa-usb-audio-fix-cannot-get-freq-eq-errors-on-dell-ae515-sound-bar.patch b/queue-5.4/alsa-usb-audio-fix-cannot-get-freq-eq-errors-on-dell-ae515-sound-bar.patch new file mode 100644 index 00000000000..cf95077727d --- /dev/null +++ b/queue-5.4/alsa-usb-audio-fix-cannot-get-freq-eq-errors-on-dell-ae515-sound-bar.patch @@ -0,0 +1,32 @@ +From fec60c3bc5d1713db2727cdffc638d48f9c07dc3 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Thu, 4 Mar 2021 09:30:21 +0100 +Subject: ALSA: usb-audio: Fix "cannot get freq eq" errors on Dell AE515 sound bar + +From: Takashi Iwai + +commit fec60c3bc5d1713db2727cdffc638d48f9c07dc3 upstream. + +Dell AE515 sound bar (413c:a506) spews the error messages when the +driver tries to read the current sample frequency, hence it needs to +be on the list in snd_usb_get_sample_rate_quirk(). + +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211551 +Cc: +Link: https://lore.kernel.org/r/20210304083021.2152-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/quirks.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/usb/quirks.c ++++ b/sound/usb/quirks.c +@@ -1452,6 +1452,7 @@ bool snd_usb_get_sample_rate_quirk(struc + case USB_ID(0x1901, 0x0191): /* GE B850V3 CP2114 audio interface */ + case USB_ID(0x21B4, 0x0081): /* AudioQuest DragonFly */ + case USB_ID(0x2912, 0x30c8): /* Audioengine D1 */ ++ case USB_ID(0x413c, 0xa506): /* Dell AE515 sound bar */ + return true; + } + diff --git a/queue-5.4/arm64-kasan-fix-page_alloc-tagging-with-debug_virtual.patch b/queue-5.4/arm64-kasan-fix-page_alloc-tagging-with-debug_virtual.patch new file mode 100644 index 00000000000..0fed3ce9d95 --- /dev/null +++ b/queue-5.4/arm64-kasan-fix-page_alloc-tagging-with-debug_virtual.patch @@ -0,0 +1,41 @@ +From 86c83365ab76e4b43cedd3ce07a07d32a4dc79ba Mon Sep 17 00:00:00 2001 +From: Andrey Konovalov +Date: Mon, 8 Mar 2021 17:10:23 +0100 +Subject: arm64: kasan: fix page_alloc tagging with DEBUG_VIRTUAL + +From: Andrey Konovalov + +commit 86c83365ab76e4b43cedd3ce07a07d32a4dc79ba upstream. + +When CONFIG_DEBUG_VIRTUAL is enabled, the default page_to_virt() macro +implementation from include/linux/mm.h is used. That definition doesn't +account for KASAN tags, which leads to no tags on page_alloc allocations. + +Provide an arm64-specific definition for page_to_virt() when +CONFIG_DEBUG_VIRTUAL is enabled that takes care of KASAN tags. + +Fixes: 2813b9c02962 ("kasan, mm, arm64: tag non slab memory allocated via pagealloc") +Cc: +Signed-off-by: Andrey Konovalov +Reviewed-by: Catalin Marinas +Link: https://lore.kernel.org/r/4b55b35202706223d3118230701c6a59749d9b72.1615219501.git.andreyknvl@google.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/include/asm/memory.h | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/arch/arm64/include/asm/memory.h ++++ b/arch/arm64/include/asm/memory.h +@@ -315,6 +315,11 @@ static inline void *phys_to_virt(phys_ad + #define ARCH_PFN_OFFSET ((unsigned long)PHYS_PFN_OFFSET) + + #if !defined(CONFIG_SPARSEMEM_VMEMMAP) || defined(CONFIG_DEBUG_VIRTUAL) ++#define page_to_virt(x) ({ \ ++ __typeof__(x) __page = x; \ ++ void *__addr = __va(page_to_phys(__page)); \ ++ (void *)__tag_set((const void *)__addr, page_kasan_tag(__page));\ ++}) + #define virt_to_page(x) pfn_to_page(virt_to_pfn(x)) + #else + #define page_to_virt(x) ({ \ diff --git a/queue-5.4/mmc-core-fix-partition-switch-time-for-emmc.patch b/queue-5.4/mmc-core-fix-partition-switch-time-for-emmc.patch new file mode 100644 index 00000000000..10c04a1279f --- /dev/null +++ b/queue-5.4/mmc-core-fix-partition-switch-time-for-emmc.patch @@ -0,0 +1,57 @@ +From 66fbacccbab91e6e55d9c8f1fc0910a8eb6c81f7 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Wed, 3 Mar 2021 11:26:14 +0200 +Subject: mmc: core: Fix partition switch time for eMMC + +From: Adrian Hunter + +commit 66fbacccbab91e6e55d9c8f1fc0910a8eb6c81f7 upstream. + +Avoid the following warning by always defining partition switch time: + + [ 3.209874] mmc1: unspecified timeout for CMD6 - use generic + [ 3.222780] ------------[ cut here ]------------ + [ 3.233363] WARNING: CPU: 1 PID: 111 at drivers/mmc/core/mmc_ops.c:575 __mmc_switch+0x200/0x204 + +Reported-by: Paul Fertser +Fixes: 1c447116d017 ("mmc: mmc: Fix partition switch timeout for some eMMCs") +Signed-off-by: Adrian Hunter +Link: https://lore.kernel.org/r/168bbfd6-0c5b-5ace-ab41-402e7937c46e@intel.com +Cc: stable@vger.kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/mmc.c | 15 +++++++++++---- + 1 file changed, 11 insertions(+), 4 deletions(-) + +--- a/drivers/mmc/core/mmc.c ++++ b/drivers/mmc/core/mmc.c +@@ -423,10 +423,6 @@ static int mmc_decode_ext_csd(struct mmc + + /* EXT_CSD value is in units of 10ms, but we store in ms */ + card->ext_csd.part_time = 10 * ext_csd[EXT_CSD_PART_SWITCH_TIME]; +- /* Some eMMC set the value too low so set a minimum */ +- if (card->ext_csd.part_time && +- card->ext_csd.part_time < MMC_MIN_PART_SWITCH_TIME) +- card->ext_csd.part_time = MMC_MIN_PART_SWITCH_TIME; + + /* Sleep / awake timeout in 100ns units */ + if (sa_shift > 0 && sa_shift <= 0x17) +@@ -616,6 +612,17 @@ static int mmc_decode_ext_csd(struct mmc + card->ext_csd.data_sector_size = 512; + } + ++ /* ++ * GENERIC_CMD6_TIME is to be used "unless a specific timeout is defined ++ * when accessing a specific field", so use it here if there is no ++ * PARTITION_SWITCH_TIME. ++ */ ++ if (!card->ext_csd.part_time) ++ card->ext_csd.part_time = card->ext_csd.generic_cmd6_time; ++ /* Some eMMC set the value too low so set a minimum */ ++ if (card->ext_csd.part_time < MMC_MIN_PART_SWITCH_TIME) ++ card->ext_csd.part_time = MMC_MIN_PART_SWITCH_TIME; ++ + /* eMMC v5 or later */ + if (card->ext_csd.rev >= 7) { + memcpy(card->ext_csd.fwrev, &ext_csd[EXT_CSD_FIRMWARE_VERSION], diff --git a/queue-5.4/mmc-cqhci-fix-random-crash-when-remove-mmc-module-card.patch b/queue-5.4/mmc-cqhci-fix-random-crash-when-remove-mmc-module-card.patch new file mode 100644 index 00000000000..3984b3e354a --- /dev/null +++ b/queue-5.4/mmc-cqhci-fix-random-crash-when-remove-mmc-module-card.patch @@ -0,0 +1,94 @@ +From f06391c45e83f9a731045deb23df7cc3814fd795 Mon Sep 17 00:00:00 2001 +From: Frank Li +Date: Wed, 3 Mar 2021 11:42:48 -0600 +Subject: mmc: cqhci: Fix random crash when remove mmc module/card + +From: Frank Li + +commit f06391c45e83f9a731045deb23df7cc3814fd795 upstream. + +[ 6684.493350] Unable to handle kernel paging request at virtual address ffff800011c5b0f0 +[ 6684.498531] mmc0: card 0001 removed +[ 6684.501556] Mem abort info: +[ 6684.509681] ESR = 0x96000047 +[ 6684.512786] EC = 0x25: DABT (current EL), IL = 32 bits +[ 6684.518394] SET = 0, FnV = 0 +[ 6684.521707] EA = 0, S1PTW = 0 +[ 6684.524998] Data abort info: +[ 6684.528236] ISV = 0, ISS = 0x00000047 +[ 6684.532986] CM = 0, WnR = 1 +[ 6684.536129] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000081b22000 +[ 6684.543923] [ffff800011c5b0f0] pgd=00000000bffff003, p4d=00000000bffff003, pud=00000000bfffe003, pmd=00000000900e1003, pte=0000000000000000 +[ 6684.557915] Internal error: Oops: 96000047 [#1] PREEMPT SMP +[ 6684.564240] Modules linked in: sdhci_esdhc_imx(-) sdhci_pltfm sdhci cqhci mmc_block mmc_core fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine rng_core authenc libdes crct10dif_ce flexcan can_dev caam error [last unloaded: mmc_core] +[ 6684.587281] CPU: 0 PID: 79138 Comm: kworker/0:3H Not tainted 5.10.9-01410-g3ba33182767b-dirty #10 +[ 6684.596160] Hardware name: Freescale i.MX8DXL EVK (DT) +[ 6684.601320] Workqueue: kblockd blk_mq_run_work_fn + +[ 6684.606094] pstate: 40000005 (nZcv daif -PAN -UAO -TCO BTYPE=--) +[ 6684.612286] pc : cqhci_request+0x148/0x4e8 [cqhci] +^GMessage from syslogd@ at Thu Jan 1 01:51:24 1970 ...[ 6684.617085] lr : cqhci_request+0x314/0x4e8 [cqhci] +[ 6684.626734] sp : ffff80001243b9f0 +[ 6684.630049] x29: ffff80001243b9f0 x28: ffff00002c3dd000 +[ 6684.635367] x27: 0000000000000001 x26: 0000000000000001 +[ 6684.640690] x25: ffff00002c451000 x24: 000000000000000f +[ 6684.646007] x23: ffff000017e71c80 x22: ffff00002c451000 +[ 6684.651326] x21: ffff00002c0f3550 x20: ffff00002c0f3550 +[ 6684.656651] x19: ffff000017d46880 x18: ffff00002cea1500 +[ 6684.661977] x17: 0000000000000000 x16: 0000000000000000 +[ 6684.667294] x15: 000001ee628e3ed1 x14: 0000000000000278 +[ 6684.672610] x13: 0000000000000001 x12: 0000000000000001 +[ 6684.677927] x11: 0000000000000000 x10: 0000000000000000 +[ 6684.683243] x9 : 000000000000002b x8 : 0000000000001000 +[ 6684.688560] x7 : 0000000000000010 x6 : ffff00002c0f3678 +[ 6684.693886] x5 : 000000000000000f x4 : ffff800011c5b000 +[ 6684.699211] x3 : 000000000002d988 x2 : 0000000000000008 +[ 6684.704537] x1 : 00000000000000f0 x0 : 0002d9880008102f +[ 6684.709854] Call trace: +[ 6684.712313] cqhci_request+0x148/0x4e8 [cqhci] +[ 6684.716803] mmc_cqe_start_req+0x58/0x68 [mmc_core] +[ 6684.721698] mmc_blk_mq_issue_rq+0x460/0x810 [mmc_block] +[ 6684.727018] mmc_mq_queue_rq+0x118/0x2b0 [mmc_block] + +The problem occurs when cqhci_request() get called after cqhci_disable() as +it leads to access of allocated memory that has already been freed. Let's +fix the problem by calling cqhci_disable() a bit later in the remove path. + +Signed-off-by: Frank Li +Diagnosed-by: Adrian Hunter +Acked-by: Adrian Hunter +Link: https://lore.kernel.org/r/20210303174248.542175-1-Frank.Li@nxp.com +Fixes: f690f4409ddd ("mmc: mmc: Enable CQE's") +Cc: stable@vger.kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/bus.c | 11 +++++------ + 1 file changed, 5 insertions(+), 6 deletions(-) + +--- a/drivers/mmc/core/bus.c ++++ b/drivers/mmc/core/bus.c +@@ -373,11 +373,6 @@ void mmc_remove_card(struct mmc_card *ca + mmc_remove_card_debugfs(card); + #endif + +- if (host->cqe_enabled) { +- host->cqe_ops->cqe_disable(host); +- host->cqe_enabled = false; +- } +- + if (mmc_card_present(card)) { + if (mmc_host_is_spi(card->host)) { + pr_info("%s: SPI card removed\n", +@@ -390,6 +385,10 @@ void mmc_remove_card(struct mmc_card *ca + of_node_put(card->dev.of_node); + } + ++ if (host->cqe_enabled) { ++ host->cqe_ops->cqe_disable(host); ++ host->cqe_enabled = false; ++ } ++ + put_device(&card->dev); + } +- diff --git a/queue-5.4/net-bonding-fix-error-return-code-of-bond_neigh_init.patch b/queue-5.4/net-bonding-fix-error-return-code-of-bond_neigh_init.patch deleted file mode 100644 index 7e4503554b1..00000000000 --- a/queue-5.4/net-bonding-fix-error-return-code-of-bond_neigh_init.patch +++ /dev/null @@ -1,42 +0,0 @@ -From 2055a99da8a253a357bdfd359b3338ef3375a26c Mon Sep 17 00:00:00 2001 -From: Jia-Ju Bai -Date: Sun, 7 Mar 2021 19:11:02 -0800 -Subject: net: bonding: fix error return code of bond_neigh_init() - -From: Jia-Ju Bai - -commit 2055a99da8a253a357bdfd359b3338ef3375a26c upstream. - -When slave is NULL or slave_ops->ndo_neigh_setup is NULL, no error -return code of bond_neigh_init() is assigned. -To fix this bug, ret is assigned with -EINVAL in these cases. - -Fixes: 9e99bfefdbce ("bonding: fix bond_neigh_init()") -Reported-by: TOTE Robot -Signed-off-by: Jia-Ju Bai -Signed-off-by: David S. Miller -Signed-off-by: Greg Kroah-Hartman ---- - drivers/net/bonding/bond_main.c | 8 ++++++-- - 1 file changed, 6 insertions(+), 2 deletions(-) - ---- a/drivers/net/bonding/bond_main.c -+++ b/drivers/net/bonding/bond_main.c -@@ -3703,11 +3703,15 @@ static int bond_neigh_init(struct neighb - - rcu_read_lock(); - slave = bond_first_slave_rcu(bond); -- if (!slave) -+ if (!slave) { -+ ret = -EINVAL; - goto out; -+ } - slave_ops = slave->dev->netdev_ops; -- if (!slave_ops->ndo_neigh_setup) -+ if (!slave_ops->ndo_neigh_setup) { -+ ret = -EINVAL; - goto out; -+ } - - /* TODO: find another way [1] to implement this. - * Passing a zeroed structure is fragile, diff --git a/queue-5.4/net-enetc-keep-rx-ring-consumer-index-in-sync-with-hardware.patch b/queue-5.4/net-enetc-keep-rx-ring-consumer-index-in-sync-with-hardware.patch deleted file mode 100644 index f76a7f26c4f..00000000000 --- a/queue-5.4/net-enetc-keep-rx-ring-consumer-index-in-sync-with-hardware.patch +++ /dev/null @@ -1,242 +0,0 @@ -From 3a5d12c9be6f30080600c8bacaf310194e37d029 Mon Sep 17 00:00:00 2001 -From: Vladimir Oltean -Date: Mon, 1 Mar 2021 13:18:18 +0200 -Subject: net: enetc: keep RX ring consumer index in sync with hardware - -From: Vladimir Oltean - -commit 3a5d12c9be6f30080600c8bacaf310194e37d029 upstream. - -The RX rings have a producer index owned by hardware, where newly -received frame buffers are placed, and a consumer index owned by -software, where newly allocated buffers are placed, in expectation of -hardware being able to place frame data in them. - -Hardware increments the producer index when a frame is received, however -it is not allowed to increment the producer index to match the consumer -index (RBCIR) since the ring can hold at most RBLENR[LENGTH]-1 received -BDs. Whenever the producer index matches the value of the consumer -index, the ring has no unprocessed received frames and all BDs in the -ring have been initialized/prepared by software, i.e. hardware owns all -BDs in the ring. - -The code uses the next_to_clean variable to keep track of the producer -index, and the next_to_use variable to keep track of the consumer index. - -The RX rings are seeded from enetc_refill_rx_ring, which is called from -two places: - -1. initially the ring is seeded until full with enetc_bd_unused(rx_ring), - i.e. with 511 buffers. This will make next_to_clean=0 and next_to_use=511: - -.ndo_open --> enetc_open - -> enetc_setup_bdrs - -> enetc_setup_rxbdr - -> enetc_refill_rx_ring - -2. then during the data path processing, it is refilled with 16 buffers - at a time: - -enetc_msix --> napi_schedule - -> enetc_poll - -> enetc_clean_rx_ring - -> enetc_refill_rx_ring - -There is just one problem: the initial seeding done during .ndo_open -updates just the producer index (ENETC_RBPIR) with 0, and the software -next_to_clean and next_to_use variables. Notably, it will not update the -consumer index to make the hardware aware of the newly added buffers. - -Wait, what? So how does it work? - -Well, the reset values of the producer index and of the consumer index -of a ring are both zero. As per the description in the second paragraph, -it means that the ring is full of buffers waiting for hardware to put -frames in them, which by coincidence is almost true, because we have in -fact seeded 511 buffers into the ring. - -But will the hardware attempt to access the 512th entry of the ring, -which has an invalid BD in it? Well, no, because in order to do that, it -would have to first populate the first 511 entries, and the NAPI -enetc_poll will kick in by then. Eventually, after 16 processed slots -have become available in the RX ring, enetc_clean_rx_ring will call -enetc_refill_rx_ring and then will [ finally ] update the consumer index -with the new software next_to_use variable. From now on, the -next_to_clean and next_to_use variables are in sync with the producer -and consumer ring indices. - -So the day is saved, right? Well, not quite. Freeing the memory -allocated for the rings is done in: - -enetc_close --> enetc_clear_bdrs - -> enetc_clear_rxbdr - -> this just disables the ring --> enetc_free_rxtx_rings - -> enetc_free_rx_ring - -> sets next_to_clean and next_to_use to 0 - -but again, nothing is committed to the hardware producer and consumer -indices (yay!). The assumption is that the ring is disabled, so the -indices don't matter anyway, and it's the responsibility of the "open" -code path to set those up. - -.. Except that the "open" code path does not set those up properly. - -While initially, things almost work, during subsequent enetc_close -> -enetc_open sequences, we have problems. To be precise, the enetc_open -that is subsequent to enetc_close will again refill the ring with 511 -entries, but it will leave the consumer index untouched. Untouched -means, of course, equal to the value it had before disabling the ring -and draining the old buffers in enetc_close. - -But as mentioned, enetc_setup_rxbdr will at least update the producer -index though, through this line of code: - - enetc_rxbdr_wr(hw, idx, ENETC_RBPIR, 0); - -so at this stage we'll have: - -next_to_clean=0 (in hardware 0) -next_to_use=511 (in hardware we'll have the refill index prior to enetc_close) - -Again, the next_to_clean and producer index are in sync and set to -correct values, so the driver manages to limp on. Eventually, 16 ring -entries will be consumed by enetc_poll, and the savior -enetc_clean_rx_ring will come and call enetc_refill_rx_ring, and then -update the hardware consumer ring based upon the new next_to_use. - -So.. it works? -Well, by coincidence, it almost does, but there's a circumstance where -enetc_clean_rx_ring won't be there to save us. If the previous value of -the consumer index was 15, there's a problem, because the NAPI poll -sequence will only issue a refill when 16 or more buffers have been -consumed. - -It's easiest to illustrate this with an example: - -ip link set eno0 up -ip addr add 192.168.100.1/24 dev eno0 -ping 192.168.100.1 -c 20 # ping this port from another board -ip link set eno0 down -ip link set eno0 up -ping 192.168.100.1 -c 20 # ping it again from the same other board - -One by one: - -1. ip link set eno0 up --> calls enetc_setup_rxbdr: - -> calls enetc_refill_rx_ring(511 buffers) - -> next_to_clean=0 (in hw 0) - -> next_to_use=511 (in hw 0) - -2. ping 192.168.100.1 -c 20 # ping this port from another board -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=1 next_to_clean 0 (in hw 1) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=2 next_to_clean 1 (in hw 2) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=3 next_to_clean 2 (in hw 3) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=4 next_to_clean 3 (in hw 4) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=5 next_to_clean 4 (in hw 5) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=6 next_to_clean 5 (in hw 6) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=7 next_to_clean 6 (in hw 7) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=8 next_to_clean 7 (in hw 8) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=9 next_to_clean 8 (in hw 9) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=10 next_to_clean 9 (in hw 10) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=11 next_to_clean 10 (in hw 11) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=12 next_to_clean 11 (in hw 12) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=13 next_to_clean 12 (in hw 13) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=14 next_to_clean 13 (in hw 14) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=15 next_to_clean 14 (in hw 15) next_to_use 511 (in hw 0) -enetc_clean_rx_ring: enetc_refill_rx_ring(16) increments next_to_use by 16 (mod 512) and writes it to hw -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=0 next_to_clean 15 (in hw 16) next_to_use 15 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=1 next_to_clean 16 (in hw 17) next_to_use 15 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=2 next_to_clean 17 (in hw 18) next_to_use 15 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=3 next_to_clean 18 (in hw 19) next_to_use 15 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=4 next_to_clean 19 (in hw 20) next_to_use 15 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=5 next_to_clean 20 (in hw 21) next_to_use 15 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=6 next_to_clean 21 (in hw 22) next_to_use 15 (in hw 15) - -20 packets transmitted, 20 packets received, 0% packet loss - -3. ip link set eno0 down -enetc_free_rx_ring: next_to_clean 0 (in hw 22), next_to_use 0 (in hw 15) - -4. ip link set eno0 up --> calls enetc_setup_rxbdr: - -> calls enetc_refill_rx_ring(511 buffers) - -> next_to_clean=0 (in hw 0) - -> next_to_use=511 (in hw 15) - -5. ping 192.168.100.1 -c 20 # ping it again from the same other board -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=1 next_to_clean 0 (in hw 1) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=2 next_to_clean 1 (in hw 2) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=3 next_to_clean 2 (in hw 3) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=4 next_to_clean 3 (in hw 4) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=5 next_to_clean 4 (in hw 5) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=6 next_to_clean 5 (in hw 6) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=7 next_to_clean 6 (in hw 7) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=8 next_to_clean 7 (in hw 8) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=9 next_to_clean 8 (in hw 9) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=10 next_to_clean 9 (in hw 10) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=11 next_to_clean 10 (in hw 11) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=12 next_to_clean 11 (in hw 12) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=13 next_to_clean 12 (in hw 13) next_to_use 511 (in hw 15) -enetc_clean_rx_ring: rx_frm_cnt=1 cleaned_cnt=14 next_to_clean 13 (in hw 14) next_to_use 511 (in hw 15) - -20 packets transmitted, 12 packets received, 40% packet loss - -And there it dies. No enetc_refill_rx_ring (because cleaned_cnt must be equal -to 15 for that to happen), no nothing. The hardware enters the condition where -the producer (14) + 1 is equal to the consumer (15) index, which makes it -believe it has no more free buffers to put packets in, so it starts discarding -them: - -ip netns exec ns0 ethtool -S eno0 | grep -v ': 0' -NIC statistics: - Rx ring 0 discarded frames: 8 - -Summarized, if the interface receives between 16 and 32 (mod 512) frames -and then there is a link flap, then the port will eventually die with no -way to recover. If it receives less than 16 (mod 512) frames, then the -initial NAPI poll [ before the link flap ] will not update the consumer -index in hardware (it will remain zero) which will be ok when the buffers -are later reinitialized. If more than 32 (mod 512) frames are received, -the initial NAPI poll has the chance to refill the ring twice, updating -the consumer index to at least 32. So after the link flap, the consumer -index is still wrong, but the post-flap NAPI poll gets a chance to -refill the ring once (because it passes through cleaned_cnt=15) and -makes the consumer index be again back in sync with next_to_use. - -The solution to this problem is actually simple, we just need to write -next_to_use into the hardware consumer index at enetc_open time, which -always brings it back in sync after an initial buffer seeding process. - -The simpler thing would be to put the write to the consumer index into -enetc_refill_rx_ring directly, but there are issues with the MDIO -locking: in the NAPI poll code we have the enetc_lock_mdio() taken from -top-level and we use the unlocked enetc_wr_reg_hot, whereas in -enetc_open, the enetc_lock_mdio() is not taken at the top level, but -instead by each individual enetc_wr_reg, so we are forced to put an -additional enetc_wr_reg in enetc_setup_rxbdr. Better organization of -the code is left as a refactoring exercise. - -Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers") -Signed-off-by: Vladimir Oltean -Signed-off-by: David S. Miller -Signed-off-by: Greg Kroah-Hartman ---- - drivers/net/ethernet/freescale/enetc/enetc.c | 2 ++ - 1 file changed, 2 insertions(+) - ---- a/drivers/net/ethernet/freescale/enetc/enetc.c -+++ b/drivers/net/ethernet/freescale/enetc/enetc.c -@@ -1162,6 +1162,8 @@ static void enetc_setup_rxbdr(struct ene - rx_ring->idr = hw->reg + ENETC_SIRXIDR; - - enetc_refill_rx_ring(rx_ring, enetc_bd_unused(rx_ring)); -+ /* update ENETC's consumer index */ -+ enetc_rxbdr_wr(hw, idx, ENETC_RBCIR, rx_ring->next_to_use); - - /* enable ring */ - enetc_rxbdr_wr(hw, idx, ENETC_RBMR, rbmr); diff --git a/queue-5.4/revert-95ebabde382c-capabilities-don-t-allow-writing-ambiguous-v3-file-capabilities.patch b/queue-5.4/revert-95ebabde382c-capabilities-don-t-allow-writing-ambiguous-v3-file-capabilities.patch new file mode 100644 index 00000000000..dd716c115c9 --- /dev/null +++ b/queue-5.4/revert-95ebabde382c-capabilities-don-t-allow-writing-ambiguous-v3-file-capabilities.patch @@ -0,0 +1,54 @@ +From 3b0c2d3eaa83da259d7726192cf55a137769012f Mon Sep 17 00:00:00 2001 +From: "Eric W. Biederman" +Date: Fri, 12 Mar 2021 15:07:09 -0600 +Subject: Revert 95ebabde382c ("capabilities: Don't allow writing ambiguous v3 file capabilities") + +From: Eric W. Biederman + +commit 3b0c2d3eaa83da259d7726192cf55a137769012f upstream. + +It turns out that there are in fact userspace implementations that +care and this recent change caused a regression. + +https://github.com/containers/buildah/issues/3071 + +As the motivation for the original change was future development, +and the impact is existing real world code just revert this change +and allow the ambiguity in v3 file caps. + +Cc: stable@vger.kernel.org +Fixes: 95ebabde382c ("capabilities: Don't allow writing ambiguous v3 file capabilities") +Signed-off-by: Eric W. Biederman +Signed-off-by: Greg Kroah-Hartman +--- + security/commoncap.c | 12 +----------- + 1 file changed, 1 insertion(+), 11 deletions(-) + +--- a/security/commoncap.c ++++ b/security/commoncap.c +@@ -500,8 +500,7 @@ int cap_convert_nscap(struct dentry *den + __u32 magic, nsmagic; + struct inode *inode = d_backing_inode(dentry); + struct user_namespace *task_ns = current_user_ns(), +- *fs_ns = inode->i_sb->s_user_ns, +- *ancestor; ++ *fs_ns = inode->i_sb->s_user_ns; + kuid_t rootid; + size_t newsize; + +@@ -524,15 +523,6 @@ int cap_convert_nscap(struct dentry *den + if (nsrootid == -1) + return -EINVAL; + +- /* +- * Do not allow allow adding a v3 filesystem capability xattr +- * if the rootid field is ambiguous. +- */ +- for (ancestor = task_ns->parent; ancestor; ancestor = ancestor->parent) { +- if (from_kuid(ancestor, rootid) == 0) +- return -EINVAL; +- } +- + newsize = sizeof(struct vfs_ns_cap_data); + nscap = kmalloc(newsize, GFP_ATOMIC); + if (!nscap) diff --git a/queue-5.4/s390-dasd-fix-hanging-dasd-driver-unbind.patch b/queue-5.4/s390-dasd-fix-hanging-dasd-driver-unbind.patch new file mode 100644 index 00000000000..e440560b406 --- /dev/null +++ b/queue-5.4/s390-dasd-fix-hanging-dasd-driver-unbind.patch @@ -0,0 +1,49 @@ +From 7d365bd0bff3c0310c39ebaffc9a8458e036d666 Mon Sep 17 00:00:00 2001 +From: Stefan Haberland +Date: Fri, 5 Mar 2021 13:54:38 +0100 +Subject: s390/dasd: fix hanging DASD driver unbind + +From: Stefan Haberland + +commit 7d365bd0bff3c0310c39ebaffc9a8458e036d666 upstream. + +In case of an unbind of the DASD device driver the function +dasd_generic_remove() is called which shuts down the device. +Among others this functions removes the int_handler from the cdev. +During shutdown the device cancels all outstanding IO requests and waits +for completion of the clear request. +Unfortunately the clear interrupt will never be received when there is no +interrupt handler connected. + +Fix by moving the int_handler removal after the call to the state machine +where no request or interrupt is outstanding. + +Cc: stable@vger.kernel.org +Signed-off-by: Stefan Haberland +Tested-by: Bjoern Walk +Reviewed-by: Jan Hoeppner +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/s390/block/dasd.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/s390/block/dasd.c ++++ b/drivers/s390/block/dasd.c +@@ -3522,8 +3522,6 @@ void dasd_generic_remove(struct ccw_devi + struct dasd_device *device; + struct dasd_block *block; + +- cdev->handler = NULL; +- + device = dasd_device_from_cdev(cdev); + if (IS_ERR(device)) { + dasd_remove_sysfs_files(cdev); +@@ -3542,6 +3540,7 @@ void dasd_generic_remove(struct ccw_devi + * no quite down yet. + */ + dasd_set_target_state(device, DASD_STATE_NEW); ++ cdev->handler = NULL; + /* dasd_delete_device destroys the device reference. */ + block = device->block; + dasd_delete_device(device); diff --git a/queue-5.4/s390-dasd-fix-hanging-io-request-during-dasd-driver-unbind.patch b/queue-5.4/s390-dasd-fix-hanging-io-request-during-dasd-driver-unbind.patch new file mode 100644 index 00000000000..0af6c1848d8 --- /dev/null +++ b/queue-5.4/s390-dasd-fix-hanging-io-request-during-dasd-driver-unbind.patch @@ -0,0 +1,40 @@ +From 66f669a272898feb1c69b770e1504aa2ec7723d1 Mon Sep 17 00:00:00 2001 +From: Stefan Haberland +Date: Fri, 5 Mar 2021 13:54:39 +0100 +Subject: s390/dasd: fix hanging IO request during DASD driver unbind + +From: Stefan Haberland + +commit 66f669a272898feb1c69b770e1504aa2ec7723d1 upstream. + +Prevent that an IO request is build during device shutdown initiated by +a driver unbind. This request will never be able to be processed or +canceled and will hang forever. This will lead also to a hanging unbind. + +Fix by checking not only if the device is in READY state but also check +that there is no device offline initiated before building a new IO request. + +Fixes: e443343e509a ("s390/dasd: blk-mq conversion") + +Cc: # v4.14+ +Signed-off-by: Stefan Haberland +Tested-by: Bjoern Walk +Reviewed-by: Jan Hoeppner +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/s390/block/dasd.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/s390/block/dasd.c ++++ b/drivers/s390/block/dasd.c +@@ -3087,7 +3087,8 @@ static blk_status_t do_dasd_request(stru + + basedev = block->base; + spin_lock_irq(&dq->lock); +- if (basedev->state < DASD_STATE_READY) { ++ if (basedev->state < DASD_STATE_READY || ++ test_bit(DASD_FLAG_OFFLINE, &basedev->flags)) { + DBF_DEV_EVENT(DBF_ERR, basedev, + "device not ready for request %p", req); + rc = BLK_STS_IOERR; diff --git a/queue-5.4/series b/queue-5.4/series index 050b2952f6d..c45d594f83f 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -24,7 +24,6 @@ mount-fix-mounting-of-detached-mounts-onto-targets-that-reside-on-shared-mounts. cifs-return-proper-error-code-in-statfs-2.patch revert-mm-slub-consider-rest-of-partial-list-if-acquire_slab-fails.patch net-enetc-don-t-overwrite-the-rss-indirection-table-when-initializing.patch -net-enetc-keep-rx-ring-consumer-index-in-sync-with-hardware.patch net-mlx4_en-update-moderation-when-config-reset.patch net-stmmac-fix-incorrect-dma-channel-intr-enable-setting-of-eqos-v4.10.patch nexthop-do-not-flush-blackhole-nexthops-when-loopback-goes-down.patch @@ -35,7 +34,6 @@ cipso-calipso-resolve-a-number-of-problems-with-the-doi-refcounts.patch net-lapbether-remove-netif_start_queue-netif_stop_queue.patch net-davicom-fix-regulator-not-turned-off-on-failed-probe.patch net-davicom-fix-regulator-not-turned-off-on-driver-removal.patch -net-bonding-fix-error-return-code-of-bond_neigh_init.patch net-qrtr-fix-error-return-code-of-qrtr_sendmsg.patch ixgbe-fail-to-create-xfrm-offload-of-ipsec-tunnel-mode-sa.patch net-stmmac-stop-each-tx-channel-independently.patch @@ -103,3 +101,18 @@ crypto-arm-sha256-neon-avoid-adrl-pseudo-instruction.patch crypto-arm-sha512-neon-avoid-adrl-pseudo-instruction.patch arm-9025-1-kconfig-cpu_big_endian-depends-on-ld_is_l.patch arm-9029-1-make-iwmmxt.s-support-clang-s-integrated-.patch +alsa-usb-add-plantronics-c320-m-usb-ctrl-msg-delay-quirk.patch +alsa-hda-hdmi-cancel-pending-works-before-suspend.patch +alsa-hda-ca0132-add-sound-blasterx-ae-5-plus-support.patch +alsa-hda-drop-the-batch-workaround-for-amd-controllers.patch +alsa-hda-flush-pending-unsolicited-events-before-suspend.patch +alsa-hda-avoid-spurious-unsol-event-handling-during-s3-s4.patch +alsa-usb-audio-fix-cannot-get-freq-eq-errors-on-dell-ae515-sound-bar.patch +alsa-usb-audio-apply-the-control-quirk-to-plantronics-headsets.patch +revert-95ebabde382c-capabilities-don-t-allow-writing-ambiguous-v3-file-capabilities.patch +arm64-kasan-fix-page_alloc-tagging-with-debug_virtual.patch +s390-dasd-fix-hanging-dasd-driver-unbind.patch +s390-dasd-fix-hanging-io-request-during-dasd-driver-unbind.patch +software-node-fix-node-registration.patch +mmc-core-fix-partition-switch-time-for-emmc.patch +mmc-cqhci-fix-random-crash-when-remove-mmc-module-card.patch diff --git a/queue-5.4/software-node-fix-node-registration.patch b/queue-5.4/software-node-fix-node-registration.patch new file mode 100644 index 00000000000..f57cfa1e2d4 --- /dev/null +++ b/queue-5.4/software-node-fix-node-registration.patch @@ -0,0 +1,34 @@ +From 8891123f9cbb9c1ee531e5a87fa116f0af685c48 Mon Sep 17 00:00:00 2001 +From: Heikki Krogerus +Date: Mon, 1 Mar 2021 17:30:11 +0300 +Subject: software node: Fix node registration + +From: Heikki Krogerus + +commit 8891123f9cbb9c1ee531e5a87fa116f0af685c48 upstream. + +Software node can not be registered before its parent. + +Fixes: 80488a6b1d3c ("software node: Add support for static node descriptors") +Cc: 5.10+ # 5.10+ +Signed-off-by: Heikki Krogerus +Reviewed-by: Andy Shevchenko +Tested-by: Andy Shevchenko +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/swnode.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/base/swnode.c ++++ b/drivers/base/swnode.c +@@ -812,6 +812,9 @@ int software_node_register(const struct + if (software_node_to_swnode(node)) + return -EEXIST; + ++ if (node->parent && !parent) ++ return -EINVAL; ++ + return PTR_ERR_OR_ZERO(swnode_register(node, parent, 0)); + } + EXPORT_SYMBOL_GPL(software_node_register);