From: Greg Kroah-Hartman Date: Sat, 3 Apr 2021 08:34:45 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v4.4.265~55 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=229bbfbf3bed3e8c26d8b22159b4e5b5083ca780;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: alsa-hda-add-missing-sanity-checks-in-pm-prepare-complete-callbacks.patch alsa-hda-re-add-dropped-snd_poewr_change_state-calls.patch alsa-hda-realtek-call-alc_update_headset_mode-in-hp_automute_hook.patch alsa-hda-realtek-fix-a-determine_headset_type-issue-for-a-dell-aio.patch alsa-usb-audio-apply-sample-rate-quirk-to-logitech-connect.patch bpf-remove-mtu-check-in-__bpf_skb_max_len.patch pm-runtime-fix-ordering-in-pm_runtime_get_suppliers.patch pm-runtime-fix-race-getting-putting-suppliers-at-probe.patch tracing-fix-stack-trace-event-size.patch xtensa-move-coprocessor_flush-to-the-.text-section.patch --- diff --git a/queue-5.4/alsa-hda-add-missing-sanity-checks-in-pm-prepare-complete-callbacks.patch b/queue-5.4/alsa-hda-add-missing-sanity-checks-in-pm-prepare-complete-callbacks.patch new file mode 100644 index 00000000000..2b00c6bcb8f --- /dev/null +++ b/queue-5.4/alsa-hda-add-missing-sanity-checks-in-pm-prepare-complete-callbacks.patch @@ -0,0 +1,47 @@ +From 66affb7bb0dc0905155a1b2475261aa704d1ddb5 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 29 Mar 2021 13:30:59 +0200 +Subject: ALSA: hda: Add missing sanity checks in PM prepare/complete callbacks + +From: Takashi Iwai + +commit 66affb7bb0dc0905155a1b2475261aa704d1ddb5 upstream. + +The recently added PM prepare and complete callbacks don't have the +sanity check whether the card instance has been properly initialized, +which may potentially lead to Oops. + +This patch adds the azx_is_pm_ready() call in each place +appropriately like other PM callbacks. + +Fixes: f5dac54d9d93 ("ALSA: hda: Separate runtime and system suspend") +Cc: +Link: https://lore.kernel.org/r/20210329113059.25035-2-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/hda_intel.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/sound/pci/hda/hda_intel.c ++++ b/sound/pci/hda/hda_intel.c +@@ -1022,6 +1022,9 @@ static int azx_prepare(struct device *de + struct snd_card *card = dev_get_drvdata(dev); + struct azx *chip; + ++ if (!azx_is_pm_ready(card)) ++ return 0; ++ + chip = card->private_data; + chip->pm_prepared = 1; + snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); +@@ -1039,6 +1042,9 @@ static void azx_complete(struct device * + struct snd_card *card = dev_get_drvdata(dev); + struct azx *chip; + ++ if (!azx_is_pm_ready(card)) ++ return; ++ + chip = card->private_data; + snd_power_change_state(card, SNDRV_CTL_POWER_D0); + chip->pm_prepared = 0; diff --git a/queue-5.4/alsa-hda-re-add-dropped-snd_poewr_change_state-calls.patch b/queue-5.4/alsa-hda-re-add-dropped-snd_poewr_change_state-calls.patch new file mode 100644 index 00000000000..c71ffa3aa61 --- /dev/null +++ b/queue-5.4/alsa-hda-re-add-dropped-snd_poewr_change_state-calls.patch @@ -0,0 +1,44 @@ +From c8f79808cd8eb5bc8d14de129bd6d586d3fce0aa Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 29 Mar 2021 13:30:58 +0200 +Subject: ALSA: hda: Re-add dropped snd_poewr_change_state() calls + +From: Takashi Iwai + +commit c8f79808cd8eb5bc8d14de129bd6d586d3fce0aa upstream. + +The card power state change via snd_power_change_state() at the system +suspend/resume seems dropped mistakenly during the PM code rewrite. +The card power state doesn't play much role nowadays but it's still +referred in a few places such as the HDMI codec driver. + +This patch restores them, but in a more appropriate place now in the +prepare and complete callbacks. + +Fixes: f5dac54d9d93 ("ALSA: hda: Separate runtime and system suspend") +Cc: +Link: https://lore.kernel.org/r/20210329113059.25035-1-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 +@@ -1024,6 +1024,7 @@ static int azx_prepare(struct device *de + + chip = card->private_data; + chip->pm_prepared = 1; ++ snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); + + flush_work(&azx_bus(chip)->unsol_work); + +@@ -1039,6 +1040,7 @@ static void azx_complete(struct device * + struct azx *chip; + + chip = card->private_data; ++ snd_power_change_state(card, SNDRV_CTL_POWER_D0); + chip->pm_prepared = 0; + } + diff --git a/queue-5.4/alsa-hda-realtek-call-alc_update_headset_mode-in-hp_automute_hook.patch b/queue-5.4/alsa-hda-realtek-call-alc_update_headset_mode-in-hp_automute_hook.patch new file mode 100644 index 00000000000..13d7d127933 --- /dev/null +++ b/queue-5.4/alsa-hda-realtek-call-alc_update_headset_mode-in-hp_automute_hook.patch @@ -0,0 +1,46 @@ +From e54f30befa7990b897189b44a56c1138c6bfdbb5 Mon Sep 17 00:00:00 2001 +From: Hui Wang +Date: Sat, 20 Mar 2021 17:15:42 +0800 +Subject: ALSA: hda/realtek: call alc_update_headset_mode() in hp_automute_hook + +From: Hui Wang + +commit e54f30befa7990b897189b44a56c1138c6bfdbb5 upstream. + +We found the alc_update_headset_mode() is not called on some machines +when unplugging the headset, as a result, the mode of the +ALC_HEADSET_MODE_UNPLUGGED can't be set, then the current_headset_type +is not cleared, if users plug a differnt type of headset next time, +the determine_headset_type() will not be called and the audio jack is +set to the headset type of previous time. + +On the Dell machines which connect the dmic to the PCH, if we open +the gnome-sound-setting and unplug the headset, this issue will +happen. Those machines disable the auto-mute by ucm and has no +internal mic in the input source, so the update_headset_mode() will +not be called by cap_sync_hook or automute_hook when unplugging, and +because the gnome-sound-setting is opened, the codec will not enter +the runtime_suspend state, so the update_headset_mode() will not be +called by alc_resume when unplugging. In this case the +hp_automute_hook is called when unplugging, so add +update_headset_mode() calling to this function. + +Cc: +Signed-off-by: Hui Wang +Link: https://lore.kernel.org/r/20210320091542.6748-2-hui.wang@canonical.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_realtek.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -5376,6 +5376,7 @@ static void alc_update_headset_jack_cb(s + struct hda_jack_callback *jack) + { + snd_hda_gen_hp_automute(codec, jack); ++ alc_update_headset_mode(codec); + } + + static void alc_probe_headset_mode(struct hda_codec *codec) diff --git a/queue-5.4/alsa-hda-realtek-fix-a-determine_headset_type-issue-for-a-dell-aio.patch b/queue-5.4/alsa-hda-realtek-fix-a-determine_headset_type-issue-for-a-dell-aio.patch new file mode 100644 index 00000000000..559e3f6b76a --- /dev/null +++ b/queue-5.4/alsa-hda-realtek-fix-a-determine_headset_type-issue-for-a-dell-aio.patch @@ -0,0 +1,47 @@ +From febf22565549ea7111e7d45e8f2d64373cc66b11 Mon Sep 17 00:00:00 2001 +From: Hui Wang +Date: Sat, 20 Mar 2021 17:15:41 +0800 +Subject: ALSA: hda/realtek: fix a determine_headset_type issue for a Dell AIO + +From: Hui Wang + +commit febf22565549ea7111e7d45e8f2d64373cc66b11 upstream. + +We found a recording issue on a Dell AIO, users plug a headset-mic and +select headset-mic from UI, but can't record any sound from +headset-mic. The root cause is the determine_headset_type() returns a +wrong type, e.g. users plug a ctia type headset, but that function +returns omtp type. + +On this machine, the internal mic is not connected to the codec, the +"Input Source" is headset mic by default. And when users plug a +headset, the determine_headset_type() will be called immediately, the +codec on this AIO is alc274, the delay time for this codec in the +determine_headset_type() is only 80ms, the delay is too short to +correctly determine the headset type, the fail rate is nearly 99% when +users plug the headset with the normal speed. + +Other codecs set several hundred ms delay time, so here I change the +delay time to 850ms for alc2x4 series, after this change, the fail +rate is zero unless users plug the headset slowly on purpose. + +Cc: +Signed-off-by: Hui Wang +Link: https://lore.kernel.org/r/20210320091542.6748-1-hui.wang@canonical.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_realtek.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -5192,7 +5192,7 @@ static void alc_determine_headset_type(s + case 0x10ec0274: + case 0x10ec0294: + alc_process_coef_fw(codec, coef0274); +- msleep(80); ++ msleep(850); + val = alc_read_coef_idx(codec, 0x46); + is_ctia = (val & 0x00f0) == 0x00f0; + break; diff --git a/queue-5.4/alsa-usb-audio-apply-sample-rate-quirk-to-logitech-connect.patch b/queue-5.4/alsa-usb-audio-apply-sample-rate-quirk-to-logitech-connect.patch new file mode 100644 index 00000000000..d3659b8cb1d --- /dev/null +++ b/queue-5.4/alsa-usb-audio-apply-sample-rate-quirk-to-logitech-connect.patch @@ -0,0 +1,35 @@ +From 625bd5a616ceda4840cd28f82e957c8ced394b6a Mon Sep 17 00:00:00 2001 +From: Ikjoon Jang +Date: Wed, 24 Mar 2021 18:51:52 +0800 +Subject: ALSA: usb-audio: Apply sample rate quirk to Logitech Connect + +From: Ikjoon Jang + +commit 625bd5a616ceda4840cd28f82e957c8ced394b6a upstream. + +Logitech ConferenceCam Connect is a compound USB device with UVC and +UAC. Not 100% reproducible but sometimes it keeps responding STALL to +every control transfer once it receives get_freq request. + +This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list. + +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419 +Signed-off-by: Ikjoon Jang +Cc: +Link: https://lore.kernel.org/r/20210324105153.2322881-1-ikjn@chromium.org +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 +@@ -1453,6 +1453,7 @@ bool snd_usb_get_sample_rate_quirk(struc + case USB_ID(0x21B4, 0x0081): /* AudioQuest DragonFly */ + case USB_ID(0x2912, 0x30c8): /* Audioengine D1 */ + case USB_ID(0x413c, 0xa506): /* Dell AE515 sound bar */ ++ case USB_ID(0x046d, 0x084c): /* Logitech ConferenceCam Connect */ + return true; + } + diff --git a/queue-5.4/bpf-remove-mtu-check-in-__bpf_skb_max_len.patch b/queue-5.4/bpf-remove-mtu-check-in-__bpf_skb_max_len.patch new file mode 100644 index 00000000000..eaf86438828 --- /dev/null +++ b/queue-5.4/bpf-remove-mtu-check-in-__bpf_skb_max_len.patch @@ -0,0 +1,82 @@ +From 6306c1189e77a513bf02720450bb43bd4ba5d8ae Mon Sep 17 00:00:00 2001 +From: Jesper Dangaard Brouer +Date: Tue, 9 Feb 2021 14:38:09 +0100 +Subject: bpf: Remove MTU check in __bpf_skb_max_len + +From: Jesper Dangaard Brouer + +commit 6306c1189e77a513bf02720450bb43bd4ba5d8ae upstream. + +Multiple BPF-helpers that can manipulate/increase the size of the SKB uses +__bpf_skb_max_len() as the max-length. This function limit size against +the current net_device MTU (skb->dev->mtu). + +When a BPF-prog grow the packet size, then it should not be limited to the +MTU. The MTU is a transmit limitation, and software receiving this packet +should be allowed to increase the size. Further more, current MTU check in +__bpf_skb_max_len uses the MTU from ingress/current net_device, which in +case of redirects uses the wrong net_device. + +This patch keeps a sanity max limit of SKB_MAX_ALLOC (16KiB). The real limit +is elsewhere in the system. Jesper's testing[1] showed it was not possible +to exceed 8KiB when expanding the SKB size via BPF-helper. The limiting +factor is the define KMALLOC_MAX_CACHE_SIZE which is 8192 for +SLUB-allocator (CONFIG_SLUB) in-case PAGE_SIZE is 4096. This define is +in-effect due to this being called from softirq context see code +__gfp_pfmemalloc_flags() and __do_kmalloc_node(). Jakub's testing showed +that frames above 16KiB can cause NICs to reset (but not crash). Keep this +sanity limit at this level as memory layer can differ based on kernel +config. + +[1] https://github.com/xdp-project/bpf-examples/tree/master/MTU-tests + +Signed-off-by: Jesper Dangaard Brouer +Signed-off-by: Daniel Borkmann +Acked-by: John Fastabend +Link: https://lore.kernel.org/bpf/161287788936.790810.2937823995775097177.stgit@firesoul +Signed-off-by: Greg Kroah-Hartman +--- + net/core/filter.c | 12 ++++-------- + 1 file changed, 4 insertions(+), 8 deletions(-) + +--- a/net/core/filter.c ++++ b/net/core/filter.c +@@ -3146,18 +3146,14 @@ static int bpf_skb_net_shrink(struct sk_ + return 0; + } + +-static u32 __bpf_skb_max_len(const struct sk_buff *skb) +-{ +- return skb->dev ? skb->dev->mtu + skb->dev->hard_header_len : +- SKB_MAX_ALLOC; +-} ++#define BPF_SKB_MAX_LEN SKB_MAX_ALLOC + + BPF_CALL_4(bpf_skb_adjust_room, struct sk_buff *, skb, s32, len_diff, + u32, mode, u64, flags) + { + u32 len_cur, len_diff_abs = abs(len_diff); + u32 len_min = bpf_skb_net_base_len(skb); +- u32 len_max = __bpf_skb_max_len(skb); ++ u32 len_max = BPF_SKB_MAX_LEN; + __be16 proto = skb->protocol; + bool shrink = len_diff < 0; + u32 off; +@@ -3237,7 +3233,7 @@ static int bpf_skb_trim_rcsum(struct sk_ + static inline int __bpf_skb_change_tail(struct sk_buff *skb, u32 new_len, + u64 flags) + { +- u32 max_len = __bpf_skb_max_len(skb); ++ u32 max_len = BPF_SKB_MAX_LEN; + u32 min_len = __bpf_skb_min_len(skb); + int ret; + +@@ -3313,7 +3309,7 @@ static const struct bpf_func_proto sk_sk + static inline int __bpf_skb_change_head(struct sk_buff *skb, u32 head_room, + u64 flags) + { +- u32 max_len = __bpf_skb_max_len(skb); ++ u32 max_len = BPF_SKB_MAX_LEN; + u32 new_len = skb->len + head_room; + int ret; + diff --git a/queue-5.4/pm-runtime-fix-ordering-in-pm_runtime_get_suppliers.patch b/queue-5.4/pm-runtime-fix-ordering-in-pm_runtime_get_suppliers.patch new file mode 100644 index 00000000000..1a0dfb2c24b --- /dev/null +++ b/queue-5.4/pm-runtime-fix-ordering-in-pm_runtime_get_suppliers.patch @@ -0,0 +1,34 @@ +From c0c33442f7203704aef345647e14c2fb86071001 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Fri, 26 Mar 2021 12:56:18 +0200 +Subject: PM: runtime: Fix ordering in pm_runtime_get_suppliers() + +From: Adrian Hunter + +commit c0c33442f7203704aef345647e14c2fb86071001 upstream. + +rpm_active indicates how many times the supplier usage_count has been +incremented. Consequently it must be updated after pm_runtime_get_sync() of +the supplier, not before. + +Fixes: 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance") +Signed-off-by: Adrian Hunter +Cc: 5.1+ # 5.1+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/power/runtime.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/base/power/runtime.c ++++ b/drivers/base/power/runtime.c +@@ -1663,8 +1663,8 @@ void pm_runtime_get_suppliers(struct dev + device_links_read_lock_held()) + if (link->flags & DL_FLAG_PM_RUNTIME) { + link->supplier_preactivated = true; +- refcount_inc(&link->rpm_active); + pm_runtime_get_sync(link->supplier); ++ refcount_inc(&link->rpm_active); + } + + device_links_read_unlock(idx); diff --git a/queue-5.4/pm-runtime-fix-race-getting-putting-suppliers-at-probe.patch b/queue-5.4/pm-runtime-fix-race-getting-putting-suppliers-at-probe.patch new file mode 100644 index 00000000000..bf389dabb38 --- /dev/null +++ b/queue-5.4/pm-runtime-fix-race-getting-putting-suppliers-at-probe.patch @@ -0,0 +1,93 @@ +From 9dfacc54a8661bc8be6e08cffee59596ec59f263 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Fri, 26 Mar 2021 12:56:19 +0200 +Subject: PM: runtime: Fix race getting/putting suppliers at probe + +From: Adrian Hunter + +commit 9dfacc54a8661bc8be6e08cffee59596ec59f263 upstream. + +pm_runtime_put_suppliers() must not decrement rpm_active unless the +consumer is suspended. That is because, otherwise, it could suspend +suppliers for an active consumer. + +That can happen as follows: + + static int driver_probe_device(struct device_driver *drv, struct device *dev) + { + int ret = 0; + + if (!device_is_registered(dev)) + return -ENODEV; + + dev->can_match = true; + pr_debug("bus: '%s': %s: matched device %s with driver %s\n", + drv->bus->name, __func__, dev_name(dev), drv->name); + + pm_runtime_get_suppliers(dev); + if (dev->parent) + pm_runtime_get_sync(dev->parent); + + At this point, dev can runtime suspend so rpm_put_suppliers() can run, + rpm_active becomes 1 (the lowest value). + + pm_runtime_barrier(dev); + if (initcall_debug) + ret = really_probe_debug(dev, drv); + else + ret = really_probe(dev, drv); + + Probe callback can have runtime resumed dev, and then runtime put + so dev is awaiting autosuspend, but rpm_active is 2. + + pm_request_idle(dev); + + if (dev->parent) + pm_runtime_put(dev->parent); + + pm_runtime_put_suppliers(dev); + + Now pm_runtime_put_suppliers() will put the supplier + i.e. rpm_active 2 -> 1, but consumer can still be active. + + return ret; + } + +Fix by checking the runtime status. For any status other than +RPM_SUSPENDED, rpm_active can be considered to be "owned" by +rpm_[get/put]_suppliers() and pm_runtime_put_suppliers() need do nothing. + +Reported-by: Asutosh Das +Fixes: 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance") +Signed-off-by: Adrian Hunter +Cc: 5.1+ # 5.1+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/power/runtime.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/base/power/runtime.c ++++ b/drivers/base/power/runtime.c +@@ -1677,6 +1677,8 @@ void pm_runtime_get_suppliers(struct dev + void pm_runtime_put_suppliers(struct device *dev) + { + struct device_link *link; ++ unsigned long flags; ++ bool put; + int idx; + + idx = device_links_read_lock(); +@@ -1685,7 +1687,11 @@ void pm_runtime_put_suppliers(struct dev + device_links_read_lock_held()) + if (link->supplier_preactivated) { + link->supplier_preactivated = false; +- if (refcount_dec_not_one(&link->rpm_active)) ++ spin_lock_irqsave(&dev->power.lock, flags); ++ put = pm_runtime_status_suspended(dev) && ++ refcount_dec_not_one(&link->rpm_active); ++ spin_unlock_irqrestore(&dev->power.lock, flags); ++ if (put) + pm_runtime_put(link->supplier); + } + diff --git a/queue-5.4/series b/queue-5.4/series index 4f39b47a970..d60f2eb9d51 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -37,3 +37,13 @@ ath10k-hold-rcu-lock-when-calling-ieee80211_find_sta.patch net-ethernet-aquantia-handle-error-cleanup-of-start-.patch appletalk-fix-skb-allocation-size-in-loopback-case.patch net-wan-lmc-unregister-device-when-no-matching-devic.patch +bpf-remove-mtu-check-in-__bpf_skb_max_len.patch +alsa-usb-audio-apply-sample-rate-quirk-to-logitech-connect.patch +alsa-hda-re-add-dropped-snd_poewr_change_state-calls.patch +alsa-hda-add-missing-sanity-checks-in-pm-prepare-complete-callbacks.patch +alsa-hda-realtek-fix-a-determine_headset_type-issue-for-a-dell-aio.patch +alsa-hda-realtek-call-alc_update_headset_mode-in-hp_automute_hook.patch +xtensa-move-coprocessor_flush-to-the-.text-section.patch +pm-runtime-fix-race-getting-putting-suppliers-at-probe.patch +pm-runtime-fix-ordering-in-pm_runtime_get_suppliers.patch +tracing-fix-stack-trace-event-size.patch diff --git a/queue-5.4/tracing-fix-stack-trace-event-size.patch b/queue-5.4/tracing-fix-stack-trace-event-size.patch new file mode 100644 index 00000000000..d6921c12add --- /dev/null +++ b/queue-5.4/tracing-fix-stack-trace-event-size.patch @@ -0,0 +1,74 @@ +From 9deb193af69d3fd6dd8e47f292b67c805a787010 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (VMware)" +Date: Thu, 1 Apr 2021 13:54:40 -0400 +Subject: tracing: Fix stack trace event size + +From: Steven Rostedt (VMware) + +commit 9deb193af69d3fd6dd8e47f292b67c805a787010 upstream. + +Commit cbc3b92ce037 fixed an issue to modify the macros of the stack trace +event so that user space could parse it properly. Originally the stack +trace format to user space showed that the called stack was a dynamic +array. But it is not actually a dynamic array, in the way that other +dynamic event arrays worked, and this broke user space parsing for it. The +update was to make the array look to have 8 entries in it. Helper +functions were added to make it parse it correctly, as the stack was +dynamic, but was determined by the size of the event stored. + +Although this fixed user space on how it read the event, it changed the +internal structure used for the stack trace event. It changed the array +size from [0] to [8] (added 8 entries). This increased the size of the +stack trace event by 8 words. The size reserved on the ring buffer was the +size of the stack trace event plus the number of stack entries found in +the stack trace. That commit caused the amount to be 8 more than what was +needed because it did not expect the caller field to have any size. This +produced 8 entries of garbage (and reading random data) from the stack +trace event: + + -0 [002] d... 1976396.837549: + => trace_event_raw_event_sched_switch + => __traceiter_sched_switch + => __schedule + => schedule_idle + => do_idle + => cpu_startup_entry + => secondary_startup_64_no_verify + => 0xc8c5e150ffff93de + => 0xffff93de + => 0 + => 0 + => 0xc8c5e17800000000 + => 0x1f30affff93de + => 0x00000004 + => 0x200000000 + +Instead, subtract the size of the caller field from the size of the event +to make sure that only the amount needed to store the stack trace is +reserved. + +Link: https://lore.kernel.org/lkml/your-ad-here.call-01617191565-ext-9692@work.hours/ + +Cc: stable@vger.kernel.org +Fixes: cbc3b92ce037 ("tracing: Set kernel_stack's caller size properly") +Reported-by: Vasily Gorbik +Tested-by: Vasily Gorbik +Acked-by: Vasily Gorbik +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -2857,7 +2857,8 @@ static void __ftrace_trace_stack(struct + + size = nr_entries * sizeof(unsigned long); + event = __trace_buffer_lock_reserve(buffer, TRACE_STACK, +- sizeof(*entry) + size, flags, pc); ++ (sizeof(*entry) - sizeof(entry->caller)) + size, ++ flags, pc); + if (!event) + goto out; + entry = ring_buffer_event_data(event); diff --git a/queue-5.4/xtensa-move-coprocessor_flush-to-the-.text-section.patch b/queue-5.4/xtensa-move-coprocessor_flush-to-the-.text-section.patch new file mode 100644 index 00000000000..7346343aa92 --- /dev/null +++ b/queue-5.4/xtensa-move-coprocessor_flush-to-the-.text-section.patch @@ -0,0 +1,106 @@ +From ab5eb336411f18fd449a1fb37d36a55ec422603f Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Thu, 25 Feb 2021 11:42:46 -0800 +Subject: xtensa: move coprocessor_flush to the .text section + +From: Max Filippov + +commit ab5eb336411f18fd449a1fb37d36a55ec422603f upstream. + +coprocessor_flush is not a part of fast exception handlers, but it uses +parts of fast coprocessor handling code that's why it's in the same +source file. It uses call0 opcode to invoke those parts so there are no +limitations on their relative location, but the rest of the code calls +coprocessor_flush with call8 and that doesn't work when vectors are +placed in a different gigabyte-aligned area than the rest of the kernel. + +Move coprocessor_flush from the .exception.text section to the .text so +that it's reachable from the rest of the kernel with call8. + +Cc: stable@vger.kernel.org +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman +--- + arch/xtensa/kernel/coprocessor.S | 64 ++++++++++++++++++++------------------- + 1 file changed, 33 insertions(+), 31 deletions(-) + +--- a/arch/xtensa/kernel/coprocessor.S ++++ b/arch/xtensa/kernel/coprocessor.S +@@ -109,37 +109,6 @@ + .previous + + /* +- * coprocessor_flush(struct thread_info*, index) +- * a2 a3 +- * +- * Save coprocessor registers for coprocessor 'index'. +- * The register values are saved to or loaded from the coprocessor area +- * inside the task_info structure. +- * +- * Note that this function doesn't update the coprocessor_owner information! +- * +- */ +- +-ENTRY(coprocessor_flush) +- +- /* reserve 4 bytes on stack to save a0 */ +- abi_entry(4) +- +- s32i a0, a1, 0 +- movi a0, .Lsave_cp_regs_jump_table +- addx8 a3, a3, a0 +- l32i a4, a3, 4 +- l32i a3, a3, 0 +- add a2, a2, a4 +- beqz a3, 1f +- callx0 a3 +-1: l32i a0, a1, 0 +- +- abi_ret(4) +- +-ENDPROC(coprocessor_flush) +- +-/* + * Entry condition: + * + * a0: trashed, original value saved on stack (PT_AREG0) +@@ -261,6 +230,39 @@ ENTRY(fast_coprocessor) + + ENDPROC(fast_coprocessor) + ++ .text ++ ++/* ++ * coprocessor_flush(struct thread_info*, index) ++ * a2 a3 ++ * ++ * Save coprocessor registers for coprocessor 'index'. ++ * The register values are saved to or loaded from the coprocessor area ++ * inside the task_info structure. ++ * ++ * Note that this function doesn't update the coprocessor_owner information! ++ * ++ */ ++ ++ENTRY(coprocessor_flush) ++ ++ /* reserve 4 bytes on stack to save a0 */ ++ abi_entry(4) ++ ++ s32i a0, a1, 0 ++ movi a0, .Lsave_cp_regs_jump_table ++ addx8 a3, a3, a0 ++ l32i a4, a3, 4 ++ l32i a3, a3, 0 ++ add a2, a2, a4 ++ beqz a3, 1f ++ callx0 a3 ++1: l32i a0, a1, 0 ++ ++ abi_ret(4) ++ ++ENDPROC(coprocessor_flush) ++ + .data + + ENTRY(coprocessor_owner)