--- /dev/null
+From 6722e46513e0af8e2fff4698f7cb78bc50a9f13f Mon Sep 17 00:00:00 2001
+From: Jonas Gorski <jonas.gorski@gmail.com>
+Date: Sat, 24 Jun 2023 14:21:39 +0200
+Subject: bus: ixp4xx: fix IXP4XX_EXP_T1_MASK
+
+From: Jonas Gorski <jonas.gorski@gmail.com>
+
+commit 6722e46513e0af8e2fff4698f7cb78bc50a9f13f upstream.
+
+The IXP4XX_EXP_T1_MASK was shifted one bit to the right, overlapping
+IXP4XX_EXP_T2_MASK and leaving bit 29 unused. The offset being wrong is
+also confirmed at least by the datasheet of IXP45X/46X [1].
+
+Fix this by aligning it to IXP4XX_EXP_T1_SHIFT.
+
+[1] https://www.intel.com/content/dam/www/public/us/en/documents/manuals/ixp45x-ixp46x-developers-manual.pdf
+
+Cc: stable@vger.kernel.org
+Fixes: 1c953bda90ca ("bus: ixp4xx: Add a driver for IXP4xx expansion bus")
+Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
+Link: https://lore.kernel.org/r/20230624112958.27727-1-jonas.gorski@gmail.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/20230624122139.3229642-1-linus.walleij@linaro.org
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/bus/intel-ixp4xx-eb.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/bus/intel-ixp4xx-eb.c b/drivers/bus/intel-ixp4xx-eb.c
+index f5ba6bee6fd8..320cf307db05 100644
+--- a/drivers/bus/intel-ixp4xx-eb.c
++++ b/drivers/bus/intel-ixp4xx-eb.c
+@@ -33,7 +33,7 @@
+ #define IXP4XX_EXP_TIMING_STRIDE 0x04
+ #define IXP4XX_EXP_CS_EN BIT(31)
+ #define IXP456_EXP_PAR_EN BIT(30) /* Only on IXP45x and IXP46x */
+-#define IXP4XX_EXP_T1_MASK GENMASK(28, 27)
++#define IXP4XX_EXP_T1_MASK GENMASK(29, 28)
+ #define IXP4XX_EXP_T1_SHIFT 28
+ #define IXP4XX_EXP_T2_MASK GENMASK(27, 26)
+ #define IXP4XX_EXP_T2_SHIFT 26
+--
+2.41.0
+
--- /dev/null
+From 257e6172ab36ebbe295a6c9ee9a9dd0fe54c1dc2 Mon Sep 17 00:00:00 2001
+From: Xiubo Li <xiubli@redhat.com>
+Date: Wed, 28 Jun 2023 07:57:09 +0800
+Subject: ceph: don't let check_caps skip sending responses for revoke msgs
+
+From: Xiubo Li <xiubli@redhat.com>
+
+commit 257e6172ab36ebbe295a6c9ee9a9dd0fe54c1dc2 upstream.
+
+If a client sends out a cap update dropping caps with the prior 'seq'
+just before an incoming cap revoke request, then the client may drop
+the revoke because it believes it's already released the requested
+capabilities.
+
+This causes the MDS to wait indefinitely for the client to respond
+to the revoke. It's therefore always a good idea to ack the cap
+revoke request with the bumped up 'seq'.
+
+Cc: stable@vger.kernel.org
+Link: https://tracker.ceph.com/issues/61782
+Signed-off-by: Xiubo Li <xiubli@redhat.com>
+Reviewed-by: Milind Changire <mchangir@redhat.com>
+Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/caps.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/fs/ceph/caps.c
++++ b/fs/ceph/caps.c
+@@ -3517,6 +3517,15 @@ static void handle_cap_grant(struct inod
+ }
+ BUG_ON(cap->issued & ~cap->implemented);
+
++ /* don't let check_caps skip sending a response to MDS for revoke msgs */
++ if (le32_to_cpu(grant->op) == CEPH_CAP_OP_REVOKE) {
++ cap->mds_wanted = 0;
++ if (cap == ci->i_auth_cap)
++ check_caps = 1; /* check auth cap only */
++ else
++ check_caps = 2; /* check all caps */
++ }
++
+ if (extra_info->inline_version > 0 &&
+ extra_info->inline_version >= ci->i_inline_version) {
+ ci->i_inline_version = extra_info->inline_version;
--- /dev/null
+From 26efd79c4624294e553aeaa3439c646729bad084 Mon Sep 17 00:00:00 2001
+From: Zheng Yejian <zhengyejian1@huawei.com>
+Date: Wed, 12 Jul 2023 14:04:52 +0800
+Subject: ftrace: Fix possible warning on checking all pages used in ftrace_process_locs()
+
+From: Zheng Yejian <zhengyejian1@huawei.com>
+
+commit 26efd79c4624294e553aeaa3439c646729bad084 upstream.
+
+As comments in ftrace_process_locs(), there may be NULL pointers in
+mcount_loc section:
+ > Some architecture linkers will pad between
+ > the different mcount_loc sections of different
+ > object files to satisfy alignments.
+ > Skip any NULL pointers.
+
+After commit 20e5227e9f55 ("ftrace: allow NULL pointers in mcount_loc"),
+NULL pointers will be accounted when allocating ftrace pages but skipped
+before adding into ftrace pages, this may result in some pages not being
+used. Then after commit 706c81f87f84 ("ftrace: Remove extra helper
+functions"), warning may occur at:
+ WARN_ON(pg->next);
+
+To fix it, only warn for case that no pointers skipped but pages not used
+up, then free those unused pages after releasing ftrace_lock.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20230712060452.3175675-1-zhengyejian1@huawei.com
+
+Cc: stable@vger.kernel.org
+Fixes: 706c81f87f84 ("ftrace: Remove extra helper functions")
+Suggested-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ftrace.c | 45 +++++++++++++++++++++++++++++++--------------
+ 1 file changed, 31 insertions(+), 14 deletions(-)
+
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -3192,6 +3192,22 @@ static int ftrace_allocate_records(struc
+ return cnt;
+ }
+
++static void ftrace_free_pages(struct ftrace_page *pages)
++{
++ struct ftrace_page *pg = pages;
++
++ while (pg) {
++ if (pg->records) {
++ free_pages((unsigned long)pg->records, pg->order);
++ ftrace_number_of_pages -= 1 << pg->order;
++ }
++ pages = pg->next;
++ kfree(pg);
++ pg = pages;
++ ftrace_number_of_groups--;
++ }
++}
++
+ static struct ftrace_page *
+ ftrace_allocate_pages(unsigned long num_to_init)
+ {
+@@ -3230,17 +3246,7 @@ ftrace_allocate_pages(unsigned long num_
+ return start_pg;
+
+ free_pages:
+- pg = start_pg;
+- while (pg) {
+- if (pg->records) {
+- free_pages((unsigned long)pg->records, pg->order);
+- ftrace_number_of_pages -= 1 << pg->order;
+- }
+- start_pg = pg->next;
+- kfree(pg);
+- pg = start_pg;
+- ftrace_number_of_groups--;
+- }
++ ftrace_free_pages(start_pg);
+ pr_info("ftrace: FAILED to allocate memory for functions\n");
+ return NULL;
+ }
+@@ -6184,9 +6190,11 @@ static int ftrace_process_locs(struct mo
+ unsigned long *start,
+ unsigned long *end)
+ {
++ struct ftrace_page *pg_unuse = NULL;
+ struct ftrace_page *start_pg;
+ struct ftrace_page *pg;
+ struct dyn_ftrace *rec;
++ unsigned long skipped = 0;
+ unsigned long count;
+ unsigned long *p;
+ unsigned long addr;
+@@ -6240,8 +6248,10 @@ static int ftrace_process_locs(struct mo
+ * object files to satisfy alignments.
+ * Skip any NULL pointers.
+ */
+- if (!addr)
++ if (!addr) {
++ skipped++;
+ continue;
++ }
+
+ end_offset = (pg->index+1) * sizeof(pg->records[0]);
+ if (end_offset > PAGE_SIZE << pg->order) {
+@@ -6255,8 +6265,10 @@ static int ftrace_process_locs(struct mo
+ rec->ip = addr;
+ }
+
+- /* We should have used all pages */
+- WARN_ON(pg->next);
++ if (pg->next) {
++ pg_unuse = pg->next;
++ pg->next = NULL;
++ }
+
+ /* Assign the last page to ftrace_pages */
+ ftrace_pages = pg;
+@@ -6278,6 +6290,11 @@ static int ftrace_process_locs(struct mo
+ out:
+ mutex_unlock(&ftrace_lock);
+
++ /* We should have used all pages unless we skipped some */
++ if (pg_unuse) {
++ WARN_ON(!skipped);
++ ftrace_free_pages(pg_unuse);
++ }
+ return ret;
+ }
+
--- /dev/null
+From a282a2f10539dce2aa619e71e1817570d557fc97 Mon Sep 17 00:00:00 2001
+From: Ilya Dryomov <idryomov@gmail.com>
+Date: Mon, 10 Jul 2023 20:39:29 +0200
+Subject: libceph: harden msgr2.1 frame segment length checks
+
+From: Ilya Dryomov <idryomov@gmail.com>
+
+commit a282a2f10539dce2aa619e71e1817570d557fc97 upstream.
+
+ceph_frame_desc::fd_lens is an int array. decode_preamble() thus
+effectively casts u32 -> int but the checks for segment lengths are
+written as if on unsigned values. While reading in HELLO or one of the
+AUTH frames (before authentication is completed), arithmetic in
+head_onwire_len() can get duped by negative ctrl_len and produce
+head_len which is less than CEPH_PREAMBLE_LEN but still positive.
+This would lead to a buffer overrun in prepare_read_control() as the
+preamble gets copied to the newly allocated buffer of size head_len.
+
+Cc: stable@vger.kernel.org
+Fixes: cd1a677cad99 ("libceph, ceph: implement msgr2.1 protocol (crc and secure modes)")
+Reported-by: Thelford Williams <thelford@google.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Reviewed-by: Xiubo Li <xiubli@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ceph/messenger_v2.c | 41 ++++++++++++++++++++++++++---------------
+ 1 file changed, 26 insertions(+), 15 deletions(-)
+
+--- a/net/ceph/messenger_v2.c
++++ b/net/ceph/messenger_v2.c
+@@ -391,6 +391,8 @@ static int head_onwire_len(int ctrl_len,
+ int head_len;
+ int rem_len;
+
++ BUG_ON(ctrl_len < 0 || ctrl_len > CEPH_MSG_MAX_CONTROL_LEN);
++
+ if (secure) {
+ head_len = CEPH_PREAMBLE_SECURE_LEN;
+ if (ctrl_len > CEPH_PREAMBLE_INLINE_LEN) {
+@@ -409,6 +411,10 @@ static int head_onwire_len(int ctrl_len,
+ static int __tail_onwire_len(int front_len, int middle_len, int data_len,
+ bool secure)
+ {
++ BUG_ON(front_len < 0 || front_len > CEPH_MSG_MAX_FRONT_LEN ||
++ middle_len < 0 || middle_len > CEPH_MSG_MAX_MIDDLE_LEN ||
++ data_len < 0 || data_len > CEPH_MSG_MAX_DATA_LEN);
++
+ if (!front_len && !middle_len && !data_len)
+ return 0;
+
+@@ -521,29 +527,34 @@ static int decode_preamble(void *p, stru
+ desc->fd_aligns[i] = ceph_decode_16(&p);
+ }
+
+- /*
+- * This would fire for FRAME_TAG_WAIT (it has one empty
+- * segment), but we should never get it as client.
+- */
+- if (!desc->fd_lens[desc->fd_seg_cnt - 1]) {
+- pr_err("last segment empty\n");
++ if (desc->fd_lens[0] < 0 ||
++ desc->fd_lens[0] > CEPH_MSG_MAX_CONTROL_LEN) {
++ pr_err("bad control segment length %d\n", desc->fd_lens[0]);
+ return -EINVAL;
+ }
+-
+- if (desc->fd_lens[0] > CEPH_MSG_MAX_CONTROL_LEN) {
+- pr_err("control segment too big %d\n", desc->fd_lens[0]);
++ if (desc->fd_lens[1] < 0 ||
++ desc->fd_lens[1] > CEPH_MSG_MAX_FRONT_LEN) {
++ pr_err("bad front segment length %d\n", desc->fd_lens[1]);
+ return -EINVAL;
+ }
+- if (desc->fd_lens[1] > CEPH_MSG_MAX_FRONT_LEN) {
+- pr_err("front segment too big %d\n", desc->fd_lens[1]);
++ if (desc->fd_lens[2] < 0 ||
++ desc->fd_lens[2] > CEPH_MSG_MAX_MIDDLE_LEN) {
++ pr_err("bad middle segment length %d\n", desc->fd_lens[2]);
+ return -EINVAL;
+ }
+- if (desc->fd_lens[2] > CEPH_MSG_MAX_MIDDLE_LEN) {
+- pr_err("middle segment too big %d\n", desc->fd_lens[2]);
++ if (desc->fd_lens[3] < 0 ||
++ desc->fd_lens[3] > CEPH_MSG_MAX_DATA_LEN) {
++ pr_err("bad data segment length %d\n", desc->fd_lens[3]);
+ return -EINVAL;
+ }
+- if (desc->fd_lens[3] > CEPH_MSG_MAX_DATA_LEN) {
+- pr_err("data segment too big %d\n", desc->fd_lens[3]);
++
++ /*
++ * This would fire for FRAME_TAG_WAIT (it has one empty
++ * segment), but we should never get it as client.
++ */
++ if (!desc->fd_lens[desc->fd_seg_cnt - 1]) {
++ pr_err("last segment empty, segment count %d\n",
++ desc->fd_seg_cnt);
+ return -EINVAL;
+ }
+
--- /dev/null
+From c57fa0037024c92c2ca34243e79e857da5d2c0a9 Mon Sep 17 00:00:00 2001
+From: George Stark <gnstark@sberdevices.ru>
+Date: Tue, 6 Jun 2023 19:53:57 +0300
+Subject: meson saradc: fix clock divider mask length
+
+From: George Stark <gnstark@sberdevices.ru>
+
+commit c57fa0037024c92c2ca34243e79e857da5d2c0a9 upstream.
+
+According to the datasheets of supported meson SoCs length of ADC_CLK_DIV
+field is 6-bit. Although all supported SoCs have the register
+with that field documented later SoCs use external clock rather than
+ADC internal clock so this patch affects only meson8 family (S8* SoCs).
+
+Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs")
+Signed-off-by: George Stark <GNStark@sberdevices.ru>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Link: https://lore.kernel.org/r/20230606165357.42417-1-gnstark@sberdevices.ru
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iio/adc/meson_saradc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/iio/adc/meson_saradc.c
++++ b/drivers/iio/adc/meson_saradc.c
+@@ -71,7 +71,7 @@
+ #define MESON_SAR_ADC_REG3_PANEL_DETECT_COUNT_MASK GENMASK(20, 18)
+ #define MESON_SAR_ADC_REG3_PANEL_DETECT_FILTER_TB_MASK GENMASK(17, 16)
+ #define MESON_SAR_ADC_REG3_ADC_CLK_DIV_SHIFT 10
+- #define MESON_SAR_ADC_REG3_ADC_CLK_DIV_WIDTH 5
++ #define MESON_SAR_ADC_REG3_ADC_CLK_DIV_WIDTH 6
+ #define MESON_SAR_ADC_REG3_BLOCK_DLY_SEL_MASK GENMASK(9, 8)
+ #define MESON_SAR_ADC_REG3_BLOCK_DLY_MASK GENMASK(7, 0)
+
--- /dev/null
+From 1e9cb763e9bacf0c932aa948f50dcfca6f519a26 Mon Sep 17 00:00:00 2001
+From: Krister Johansen <kjlx@templeofstupid.com>
+Date: Mon, 10 Jul 2023 18:36:21 -0700
+Subject: net: ena: fix shift-out-of-bounds in exponential backoff
+
+From: Krister Johansen <kjlx@templeofstupid.com>
+
+commit 1e9cb763e9bacf0c932aa948f50dcfca6f519a26 upstream.
+
+The ENA adapters on our instances occasionally reset. Once recently
+logged a UBSAN failure to console in the process:
+
+ UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13
+ shift exponent 32 is too large for 32-bit type 'unsigned int'
+ CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117
+ Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017
+ Workqueue: ena ena_fw_reset_device [ena]
+ Call Trace:
+ <TASK>
+ dump_stack_lvl+0x4a/0x63
+ dump_stack+0x10/0x16
+ ubsan_epilogue+0x9/0x36
+ __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e
+ ? __const_udelay+0x43/0x50
+ ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena]
+ wait_for_reset_state+0x54/0xa0 [ena]
+ ena_com_dev_reset+0xc8/0x110 [ena]
+ ena_down+0x3fe/0x480 [ena]
+ ena_destroy_device+0xeb/0xf0 [ena]
+ ena_fw_reset_device+0x30/0x50 [ena]
+ process_one_work+0x22b/0x3d0
+ worker_thread+0x4d/0x3f0
+ ? process_one_work+0x3d0/0x3d0
+ kthread+0x12a/0x150
+ ? set_kthread_struct+0x50/0x50
+ ret_from_fork+0x22/0x30
+ </TASK>
+
+Apparently, the reset delays are getting so large they can trigger a
+UBSAN panic.
+
+Looking at the code, the current timeout is capped at 5000us. Using a
+base value of 100us, the current code will overflow after (1<<29). Even
+at values before 32, this function wraps around, perhaps
+unintentionally.
+
+Cap the value of the exponent used for this backoff at (1<<16) which is
+larger than currently necessary, but large enough to support bigger
+values in the future.
+
+Cc: stable@vger.kernel.org
+Fixes: 4bb7f4cf60e3 ("net: ena: reduce driver load time")
+Signed-off-by: Krister Johansen <kjlx@templeofstupid.com>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Reviewed-by: Shay Agroskin <shayagr@amazon.com>
+Link: https://lore.kernel.org/r/20230711013621.GE1926@templeofstupid.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/amazon/ena/ena_com.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/net/ethernet/amazon/ena/ena_com.c
++++ b/drivers/net/ethernet/amazon/ena/ena_com.c
+@@ -35,6 +35,8 @@
+
+ #define ENA_REGS_ADMIN_INTR_MASK 1
+
++#define ENA_MAX_BACKOFF_DELAY_EXP 16U
++
+ #define ENA_MIN_ADMIN_POLL_US 100
+
+ #define ENA_MAX_ADMIN_POLL_US 5000
+@@ -536,6 +538,7 @@ static int ena_com_comp_status_to_errno(
+
+ static void ena_delay_exponential_backoff_us(u32 exp, u32 delay_us)
+ {
++ exp = min_t(u32, exp, ENA_MAX_BACKOFF_DELAY_EXP);
+ delay_us = max_t(u32, ENA_MIN_ADMIN_POLL_US, delay_us);
+ delay_us = min_t(u32, delay_us * (1U << exp), ENA_MAX_ADMIN_POLL_US);
+ usleep_range(delay_us, 2 * delay_us);
--- /dev/null
+From b2a2ab039bd58f51355e33d7d3fc64605d7f870d Mon Sep 17 00:00:00 2001
+From: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
+Date: Tue, 30 May 2023 17:54:46 +0200
+Subject: opp: Fix use-after-free in lazy_opp_tables after probe deferral
+
+From: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
+
+commit b2a2ab039bd58f51355e33d7d3fc64605d7f870d upstream.
+
+When dev_pm_opp_of_find_icc_paths() in _allocate_opp_table() returns
+-EPROBE_DEFER, the opp_table is freed again, to wait until all the
+interconnect paths are available.
+
+However, if the OPP table is using required-opps then it may already
+have been added to the global lazy_opp_tables list. The error path
+does not remove the opp_table from the list again.
+
+This can cause crashes later when the provider of the required-opps
+is added, since we will iterate over OPP tables that have already been
+freed. E.g.:
+
+ Unable to handle kernel NULL pointer dereference when read
+ CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.4.0-rc3
+ PC is at _of_add_opp_table_v2 (include/linux/of.h:949
+ drivers/opp/of.c:98 drivers/opp/of.c:344 drivers/opp/of.c:404
+ drivers/opp/of.c:1032) -> lazy_link_required_opp_table()
+
+Fix this by calling _of_clear_opp_table() to remove the opp_table from
+the list and clear other allocated resources. While at it, also add the
+missing mutex_destroy() calls in the error path.
+
+Cc: stable@vger.kernel.org
+Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
+Fixes: 7eba0c7641b0 ("opp: Allow lazy-linking of required-opps")
+Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
+Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/opp/core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/opp/core.c
++++ b/drivers/opp/core.c
+@@ -1249,7 +1249,10 @@ static struct opp_table *_allocate_opp_t
+ return opp_table;
+
+ remove_opp_dev:
++ _of_clear_opp_table(opp_table);
+ _remove_opp_dev(opp_dev, opp_table);
++ mutex_destroy(&opp_table->genpd_virt_dev_lock);
++ mutex_destroy(&opp_table->lock);
+ err:
+ kfree(opp_table);
+ return ERR_PTR(ret);
--- /dev/null
+From a82d62f708545d22859584e0e0620da8e3759bbc Mon Sep 17 00:00:00 2001
+From: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
+Date: Mon, 19 Jun 2023 15:57:44 +0000
+Subject: Revert "8250: add support for ASIX devices with a FIFO bug"
+
+From: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
+
+commit a82d62f708545d22859584e0e0620da8e3759bbc upstream.
+
+This reverts commit eb26dfe8aa7eeb5a5aa0b7574550125f8aa4c3b3.
+
+Commit eb26dfe8aa7e ("8250: add support for ASIX devices with a FIFO
+bug") merged on Jul 13, 2012 adds a quirk for PCI_VENDOR_ID_ASIX
+(0x9710). But that ID is the same as PCI_VENDOR_ID_NETMOS defined in
+1f8b061050c7 ("[PATCH] Netmos parallel/serial/combo support") merged
+on Mar 28, 2005. In pci_serial_quirks array, the NetMos entry always
+takes precedence over the ASIX entry even since it was initially
+merged, code in that commit is always unreachable.
+
+In my tests, adding the FIFO workaround to pci_netmos_init() makes no
+difference, and the vendor driver also does not have such workaround.
+Given that the code was never used for over a decade, it's safe to
+revert it.
+
+Also, the real PCI_VENDOR_ID_ASIX should be 0x125b, which is used on
+their newer AX99100 PCIe serial controllers released on 2016. The FIFO
+workaround should not be intended for these newer controllers, and it
+was never implemented in vendor driver.
+
+Fixes: eb26dfe8aa7e ("8250: add support for ASIX devices with a FIFO bug")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Link: https://lore.kernel.org/r/20230619155743.827859-1-jiaqing.zhao@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250.h | 1 -
+ drivers/tty/serial/8250/8250_pci.c | 19 -------------------
+ drivers/tty/serial/8250/8250_port.c | 11 +++--------
+ include/linux/serial_8250.h | 1 -
+ 4 files changed, 3 insertions(+), 29 deletions(-)
+
+--- a/drivers/tty/serial/8250/8250.h
++++ b/drivers/tty/serial/8250/8250.h
+@@ -90,7 +90,6 @@ struct serial8250_config {
+ #define UART_BUG_TXEN BIT(1) /* UART has buggy TX IIR status */
+ #define UART_BUG_NOMSR BIT(2) /* UART has buggy MSR status bits (Au1x00) */
+ #define UART_BUG_THRE BIT(3) /* UART has buggy THRE reassertion */
+-#define UART_BUG_PARITY BIT(4) /* UART mishandles parity if FIFO enabled */
+ #define UART_BUG_TXRACE BIT(5) /* UART Tx fails to set remote DR */
+
+
+--- a/drivers/tty/serial/8250/8250_pci.c
++++ b/drivers/tty/serial/8250/8250_pci.c
+@@ -1252,14 +1252,6 @@ static int pci_oxsemi_tornado_setup(stru
+ return pci_default_setup(priv, board, up, idx);
+ }
+
+-static int pci_asix_setup(struct serial_private *priv,
+- const struct pciserial_board *board,
+- struct uart_8250_port *port, int idx)
+-{
+- port->bugs |= UART_BUG_PARITY;
+- return pci_default_setup(priv, board, port, idx);
+-}
+-
+ /* Quatech devices have their own extra interface features */
+
+ struct quatech_feature {
+@@ -2082,7 +2074,6 @@ pci_moxa_setup(struct serial_private *pr
+ #define PCI_DEVICE_ID_WCH_CH355_4S 0x7173
+ #define PCI_VENDOR_ID_AGESTAR 0x5372
+ #define PCI_DEVICE_ID_AGESTAR_9375 0x6872
+-#define PCI_VENDOR_ID_ASIX 0x9710
+ #define PCI_DEVICE_ID_BROADCOM_TRUMANAGE 0x160a
+ #define PCI_DEVICE_ID_AMCC_ADDIDATA_APCI7800 0x818e
+
+@@ -2893,16 +2884,6 @@ static struct pci_serial_quirk pci_seria
+ .setup = pci_wch_ch38x_setup,
+ },
+ /*
+- * ASIX devices with FIFO bug
+- */
+- {
+- .vendor = PCI_VENDOR_ID_ASIX,
+- .device = PCI_ANY_ID,
+- .subvendor = PCI_ANY_ID,
+- .subdevice = PCI_ANY_ID,
+- .setup = pci_asix_setup,
+- },
+- /*
+ * Broadcom TruManage (NetXtreme)
+ */
+ {
+--- a/drivers/tty/serial/8250/8250_port.c
++++ b/drivers/tty/serial/8250/8250_port.c
+@@ -2620,11 +2620,8 @@ static unsigned char serial8250_compute_
+
+ if (c_cflag & CSTOPB)
+ cval |= UART_LCR_STOP;
+- if (c_cflag & PARENB) {
++ if (c_cflag & PARENB)
+ cval |= UART_LCR_PARITY;
+- if (up->bugs & UART_BUG_PARITY)
+- up->fifo_bug = true;
+- }
+ if (!(c_cflag & PARODD))
+ cval |= UART_LCR_EPAR;
+ #ifdef CMSPAR
+@@ -2787,8 +2784,7 @@ serial8250_do_set_termios(struct uart_po
+ up->lcr = cval; /* Save computed LCR */
+
+ if (up->capabilities & UART_CAP_FIFO && port->fifosize > 1) {
+- /* NOTE: If fifo_bug is not set, a user can set RX_trigger. */
+- if ((baud < 2400 && !up->dma) || up->fifo_bug) {
++ if (baud < 2400 && !up->dma) {
+ up->fcr &= ~UART_FCR_TRIGGER_MASK;
+ up->fcr |= UART_FCR_TRIGGER_1;
+ }
+@@ -3124,8 +3120,7 @@ static int do_set_rxtrig(struct tty_port
+ struct uart_8250_port *up = up_to_u8250p(uport);
+ int rxtrig;
+
+- if (!(up->capabilities & UART_CAP_FIFO) || uport->fifosize <= 1 ||
+- up->fifo_bug)
++ if (!(up->capabilities & UART_CAP_FIFO) || uport->fifosize <= 1)
+ return -EINVAL;
+
+ rxtrig = bytes_to_fcr_rxtrig(up, bytes);
+--- a/include/linux/serial_8250.h
++++ b/include/linux/serial_8250.h
+@@ -98,7 +98,6 @@ struct uart_8250_port {
+ struct list_head list; /* ports on this IRQ */
+ u32 capabilities; /* port capabilities */
+ unsigned short bugs; /* port bugs */
+- bool fifo_bug; /* min RX trigger if enabled */
+ unsigned int tx_loadsz; /* transmit fifo load size */
+ unsigned char acr;
+ unsigned char fcr;
--- /dev/null
+From 7e42907f3a7b4ce3a2d1757f6d78336984daf8f5 Mon Sep 17 00:00:00 2001
+From: Zheng Yejian <zhengyejian1@huawei.com>
+Date: Sun, 9 Jul 2023 06:51:44 +0800
+Subject: ring-buffer: Fix deadloop issue on reading trace_pipe
+
+From: Zheng Yejian <zhengyejian1@huawei.com>
+
+commit 7e42907f3a7b4ce3a2d1757f6d78336984daf8f5 upstream.
+
+Soft lockup occurs when reading file 'trace_pipe':
+
+ watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488]
+ [...]
+ RIP: 0010:ring_buffer_empty_cpu+0xed/0x170
+ RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246
+ RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb
+ RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218
+ RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f
+ R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901
+ R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000
+ [...]
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0
+ DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+ DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+ Call Trace:
+ __find_next_entry+0x1a8/0x4b0
+ ? peek_next_entry+0x250/0x250
+ ? down_write+0xa5/0x120
+ ? down_write_killable+0x130/0x130
+ trace_find_next_entry_inc+0x3b/0x1d0
+ tracing_read_pipe+0x423/0xae0
+ ? tracing_splice_read_pipe+0xcb0/0xcb0
+ vfs_read+0x16b/0x490
+ ksys_read+0x105/0x210
+ ? __ia32_sys_pwrite64+0x200/0x200
+ ? switch_fpu_return+0x108/0x220
+ do_syscall_64+0x33/0x40
+ entry_SYSCALL_64_after_hwframe+0x61/0xc6
+
+Through the vmcore, I found it's because in tracing_read_pipe(),
+ring_buffer_empty_cpu() found some buffer is not empty but then it
+cannot read anything due to "rb_num_of_entries() == 0" always true,
+Then it infinitely loop the procedure due to user buffer not been
+filled, see following code path:
+
+ tracing_read_pipe() {
+ ... ...
+ waitagain:
+ tracing_wait_pipe() // 1. find non-empty buffer here
+ trace_find_next_entry_inc() // 2. loop here try to find an entry
+ __find_next_entry()
+ ring_buffer_empty_cpu(); // 3. find non-empty buffer
+ peek_next_entry() // 4. but peek always return NULL
+ ring_buffer_peek()
+ rb_buffer_peek()
+ rb_get_reader_page()
+ // 5. because rb_num_of_entries() == 0 always true here
+ // then return NULL
+ // 6. user buffer not been filled so goto 'waitgain'
+ // and eventually leads to an deadloop in kernel!!!
+ }
+
+By some analyzing, I found that when resetting ringbuffer, the 'entries'
+of its pages are not all cleared (see rb_reset_cpu()). Then when reducing
+the ringbuffer, and if some reduced pages exist dirty 'entries' data, they
+will be added into 'cpu_buffer->overrun' (see rb_remove_pages()), which
+cause wrong 'overrun' count and eventually cause the deadloop issue.
+
+To fix it, we need to clear every pages in rb_reset_cpu().
+
+Link: https://lore.kernel.org/linux-trace-kernel/20230708225144.3785600-1-zhengyejian1@huawei.com
+
+Cc: stable@vger.kernel.org
+Fixes: a5fb833172eca ("ring-buffer: Fix uninitialized read_stamp")
+Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ring_buffer.c | 24 +++++++++++++++---------
+ 1 file changed, 15 insertions(+), 9 deletions(-)
+
+--- a/kernel/trace/ring_buffer.c
++++ b/kernel/trace/ring_buffer.c
+@@ -5196,28 +5196,34 @@ unsigned long ring_buffer_size(struct tr
+ }
+ EXPORT_SYMBOL_GPL(ring_buffer_size);
+
++static void rb_clear_buffer_page(struct buffer_page *page)
++{
++ local_set(&page->write, 0);
++ local_set(&page->entries, 0);
++ rb_init_page(page->page);
++ page->read = 0;
++}
++
+ static void
+ rb_reset_cpu(struct ring_buffer_per_cpu *cpu_buffer)
+ {
++ struct buffer_page *page;
++
+ rb_head_page_deactivate(cpu_buffer);
+
+ cpu_buffer->head_page
+ = list_entry(cpu_buffer->pages, struct buffer_page, list);
+- local_set(&cpu_buffer->head_page->write, 0);
+- local_set(&cpu_buffer->head_page->entries, 0);
+- local_set(&cpu_buffer->head_page->page->commit, 0);
+-
+- cpu_buffer->head_page->read = 0;
++ rb_clear_buffer_page(cpu_buffer->head_page);
++ list_for_each_entry(page, cpu_buffer->pages, list) {
++ rb_clear_buffer_page(page);
++ }
+
+ cpu_buffer->tail_page = cpu_buffer->head_page;
+ cpu_buffer->commit_page = cpu_buffer->head_page;
+
+ INIT_LIST_HEAD(&cpu_buffer->reader_page->list);
+ INIT_LIST_HEAD(&cpu_buffer->new_pages);
+- local_set(&cpu_buffer->reader_page->write, 0);
+- local_set(&cpu_buffer->reader_page->entries, 0);
+- local_set(&cpu_buffer->reader_page->page->commit, 0);
+- cpu_buffer->reader_page->read = 0;
++ rb_clear_buffer_page(cpu_buffer->reader_page);
+
+ local_set(&cpu_buffer->entries_bytes, 0);
+ local_set(&cpu_buffer->overrun, 0);
--- /dev/null
+From 938f0c35d7d93a822ab9c9728e3205e8e57409d0 Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <hca@linux.ibm.com>
+Date: Thu, 22 Jun 2023 14:55:08 +0200
+Subject: s390/decompressor: fix misaligned symbol build error
+
+From: Heiko Carstens <hca@linux.ibm.com>
+
+commit 938f0c35d7d93a822ab9c9728e3205e8e57409d0 upstream.
+
+Nathan Chancellor reported a kernel build error on Fedora 39:
+
+$ clang --version | head -1
+clang version 16.0.5 (Fedora 16.0.5-1.fc39)
+
+$ s390x-linux-gnu-ld --version | head -1
+GNU ld version 2.40-1.fc39
+
+$ make -skj"$(nproc)" ARCH=s390 CC=clang CROSS_COMPILE=s390x-linux-gnu- olddefconfig all
+s390x-linux-gnu-ld: arch/s390/boot/startup.o(.text+0x5b4): misaligned symbol `_decompressor_end' (0x35b0f) for relocation R_390_PC32DBL
+make[3]: *** [.../arch/s390/boot/Makefile:78: arch/s390/boot/vmlinux] Error 1
+
+It turned out that the problem with misaligned symbols on s390 was fixed
+with commit 80ddf5ce1c92 ("s390: always build relocatable kernel") for the
+kernel image, but did not take into account that the decompressor uses its
+own set of CFLAGS, which come without -fPIE.
+
+Add the -fPIE flag also to the decompresser CFLAGS to fix this.
+
+Reported-by: Nathan Chancellor <nathan@kernel.org>
+Tested-by: Nathan Chancellor <nathan@kernel.org>
+Reported-by: CKI <cki-project@redhat.com>
+Suggested-by: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
+Link: https://github.com/ClangBuiltLinux/linux/issues/1747
+Link: https://lore.kernel.org/32935.123062114500601371@us-mta-9.us.mimecast.lan/
+Link: https://lore.kernel.org/r/20230622125508.1068457-1-hca@linux.ibm.com
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/s390/Makefile
++++ b/arch/s390/Makefile
+@@ -29,6 +29,7 @@ KBUILD_CFLAGS_DECOMPRESSOR += -fno-delet
+ KBUILD_CFLAGS_DECOMPRESSOR += -fno-asynchronous-unwind-tables
+ KBUILD_CFLAGS_DECOMPRESSOR += -ffreestanding
+ KBUILD_CFLAGS_DECOMPRESSOR += -fno-stack-protector
++KBUILD_CFLAGS_DECOMPRESSOR += -fPIE
+ KBUILD_CFLAGS_DECOMPRESSOR += $(call cc-disable-warning, address-of-packed-member)
+ KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO),-g)
+ KBUILD_CFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO_DWARF4), $(call cc-option, -gdwarf-4,))
--- /dev/null
+From 8564c315876ab86fcaf8e7f558d6a84cb2ce5590 Mon Sep 17 00:00:00 2001
+From: Florent Revest <revest@chromium.org>
+Date: Thu, 27 Apr 2023 16:06:59 +0200
+Subject: samples: ftrace: Save required argument registers in sample trampolines
+
+From: Florent Revest <revest@chromium.org>
+
+commit 8564c315876ab86fcaf8e7f558d6a84cb2ce5590 upstream.
+
+The ftrace-direct-too sample traces the handle_mm_fault function whose
+signature changed since the introduction of the sample. Since:
+commit bce617edecad ("mm: do page fault accounting in handle_mm_fault")
+handle_mm_fault now has 4 arguments. Therefore, the sample trampoline
+should save 4 argument registers.
+
+s390 saves all argument registers already so it does not need a change
+but x86_64 needs an extra push and pop.
+
+This also evolves the signature of the tracing function to make it
+mirror the signature of the traced function.
+
+Link: https://lkml.kernel.org/r/20230427140700.625241-2-revest@chromium.org
+
+Cc: stable@vger.kernel.org
+Fixes: bce617edecad ("mm: do page fault accounting in handle_mm_fault")
+Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Reviewed-by: Mark Rutland <mark.rutland@arm.com>
+Acked-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Florent Revest <revest@chromium.org>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ samples/ftrace/ftrace-direct-too.c | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+--- a/samples/ftrace/ftrace-direct-too.c
++++ b/samples/ftrace/ftrace-direct-too.c
+@@ -4,14 +4,14 @@
+ #include <linux/mm.h> /* for handle_mm_fault() */
+ #include <linux/ftrace.h>
+
+-extern void my_direct_func(struct vm_area_struct *vma,
+- unsigned long address, unsigned int flags);
++extern void my_direct_func(struct vm_area_struct *vma, unsigned long address,
++ unsigned int flags, struct pt_regs *regs);
+
+-void my_direct_func(struct vm_area_struct *vma,
+- unsigned long address, unsigned int flags)
++void my_direct_func(struct vm_area_struct *vma, unsigned long address,
++ unsigned int flags, struct pt_regs *regs)
+ {
+- trace_printk("handle mm fault vma=%p address=%lx flags=%x\n",
+- vma, address, flags);
++ trace_printk("handle mm fault vma=%p address=%lx flags=%x regs=%p\n",
++ vma, address, flags, regs);
+ }
+
+ extern void my_tramp(void *);
+@@ -26,7 +26,9 @@ asm (
+ " pushq %rdi\n"
+ " pushq %rsi\n"
+ " pushq %rdx\n"
++" pushq %rcx\n"
+ " call my_direct_func\n"
++" popq %rcx\n"
+ " popq %rdx\n"
+ " popq %rsi\n"
+ " popq %rdi\n"
tty-serial-samsung_tty-fix-a-memory-leak-in-s3c24xx_serial_getclk-when-iterating-clk.patch
tty-serial-imx-fix-rs485-rx-after-tx.patch
firmware-stratix10-svc-fix-a-potential-resource-leak-in-svc_create_memory_pool.patch
+libceph-harden-msgr2.1-frame-segment-length-checks.patch
+ceph-don-t-let-check_caps-skip-sending-responses-for-revoke-msgs.patch
+xhci-fix-resume-issue-of-some-zhaoxin-hosts.patch
+xhci-fix-trb-prefetch-issue-of-zhaoxin-hosts.patch
+xhci-show-zhaoxin-xhci-root-hub-speed-correctly.patch
+meson-saradc-fix-clock-divider-mask-length.patch
+opp-fix-use-after-free-in-lazy_opp_tables-after-probe-deferral.patch
+soundwire-qcom-fix-storing-port-config-out-of-bounds.patch
+revert-8250-add-support-for-asix-devices-with-a-fifo-bug.patch
+bus-ixp4xx-fix-ixp4xx_exp_t1_mask.patch
+s390-decompressor-fix-misaligned-symbol-build-error.patch
+tracing-histograms-add-histograms-to-hist_vars-if-they-have-referenced-variables.patch
+tracing-fix-memory-leak-of-iter-temp-when-reading-trace_pipe.patch
+samples-ftrace-save-required-argument-registers-in-sample-trampolines.patch
+net-ena-fix-shift-out-of-bounds-in-exponential-backoff.patch
+ring-buffer-fix-deadloop-issue-on-reading-trace_pipe.patch
+ftrace-fix-possible-warning-on-checking-all-pages-used-in-ftrace_process_locs.patch
+xtensa-iss-fix-call-to-split_if_spec.patch
--- /dev/null
+From 490937d479abe5f6584e69b96df066bc87be92e9 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Thu, 1 Jun 2023 12:25:25 +0200
+Subject: soundwire: qcom: fix storing port config out-of-bounds
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 490937d479abe5f6584e69b96df066bc87be92e9 upstream.
+
+The 'qcom_swrm_ctrl->pconfig' has size of QCOM_SDW_MAX_PORTS (14),
+however we index it starting from 1, not 0, to match real port numbers.
+This can lead to writing port config past 'pconfig' bounds and
+overwriting next member of 'qcom_swrm_ctrl' struct. Reported also by
+smatch:
+
+ drivers/soundwire/qcom.c:1269 qcom_swrm_get_port_config() error: buffer overflow 'ctrl->pconfig' 14 <= 14
+
+Fixes: 9916c02ccd74 ("soundwire: qcom: cleanup internal port config indexing")
+Cc: <stable@vger.kernel.org>
+Reported-by: kernel test robot <lkp@intel.com>
+Reported-by: Dan Carpenter <error27@gmail.com>
+Link: https://lore.kernel.org/r/202305201301.sCJ8UDKV-lkp@intel.com/
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
+Link: https://lore.kernel.org/r/20230601102525.609627-1-krzysztof.kozlowski@linaro.org
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/soundwire/qcom.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/soundwire/qcom.c
++++ b/drivers/soundwire/qcom.c
+@@ -146,7 +146,8 @@ struct qcom_swrm_ctrl {
+ u32 intr_mask;
+ u8 rcmd_id;
+ u8 wcmd_id;
+- struct qcom_swrm_port_config pconfig[QCOM_SDW_MAX_PORTS];
++ /* Port numbers are 1 - 14 */
++ struct qcom_swrm_port_config pconfig[QCOM_SDW_MAX_PORTS + 1];
+ struct sdw_stream_runtime *sruntime[SWRM_MAX_DAIS];
+ enum sdw_slave_status status[SDW_MAX_DEVICES + 1];
+ int (*reg_read)(struct qcom_swrm_ctrl *ctrl, int reg, u32 *val);
--- /dev/null
+From d5a821896360cc8b93a15bd888fabc858c038dc0 Mon Sep 17 00:00:00 2001
+From: Zheng Yejian <zhengyejian1@huawei.com>
+Date: Thu, 13 Jul 2023 22:14:35 +0800
+Subject: tracing: Fix memory leak of iter->temp when reading trace_pipe
+
+From: Zheng Yejian <zhengyejian1@huawei.com>
+
+commit d5a821896360cc8b93a15bd888fabc858c038dc0 upstream.
+
+kmemleak reports:
+ unreferenced object 0xffff88814d14e200 (size 256):
+ comm "cat", pid 336, jiffies 4294871818 (age 779.490s)
+ hex dump (first 32 bytes):
+ 04 00 01 03 00 00 00 00 08 00 00 00 00 00 00 00 ................
+ 0c d8 c8 9b ff ff ff ff 04 5a ca 9b ff ff ff ff .........Z......
+ backtrace:
+ [<ffffffff9bdff18f>] __kmalloc+0x4f/0x140
+ [<ffffffff9bc9238b>] trace_find_next_entry+0xbb/0x1d0
+ [<ffffffff9bc9caef>] trace_print_lat_context+0xaf/0x4e0
+ [<ffffffff9bc94490>] print_trace_line+0x3e0/0x950
+ [<ffffffff9bc95499>] tracing_read_pipe+0x2d9/0x5a0
+ [<ffffffff9bf03a43>] vfs_read+0x143/0x520
+ [<ffffffff9bf04c2d>] ksys_read+0xbd/0x160
+ [<ffffffff9d0f0edf>] do_syscall_64+0x3f/0x90
+ [<ffffffff9d2000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
+
+when reading file 'trace_pipe', 'iter->temp' is allocated or relocated
+in trace_find_next_entry() but not freed before 'trace_pipe' is closed.
+
+To fix it, free 'iter->temp' in tracing_release_pipe().
+
+Link: https://lore.kernel.org/linux-trace-kernel/20230713141435.1133021-1-zhengyejian1@huawei.com
+
+Cc: stable@vger.kernel.org
+Fixes: ff895103a84ab ("tracing: Save off entry when peeking at next entry")
+Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -6650,6 +6650,7 @@ static int tracing_release_pipe(struct i
+
+ free_cpumask_var(iter->started);
+ kfree(iter->fmt);
++ kfree(iter->temp);
+ mutex_destroy(&iter->mutex);
+ kfree(iter);
+
--- /dev/null
+From 6018b585e8c6fa7d85d4b38d9ce49a5b67be7078 Mon Sep 17 00:00:00 2001
+From: Mohamed Khalfella <mkhalfella@purestorage.com>
+Date: Wed, 12 Jul 2023 22:30:21 +0000
+Subject: tracing/histograms: Add histograms to hist_vars if they have referenced variables
+
+From: Mohamed Khalfella <mkhalfella@purestorage.com>
+
+commit 6018b585e8c6fa7d85d4b38d9ce49a5b67be7078 upstream.
+
+Hist triggers can have referenced variables without having direct
+variables fields. This can be the case if referenced variables are added
+for trigger actions. In this case the newly added references will not
+have field variables. Not taking such referenced variables into
+consideration can result in a bug where it would be possible to remove
+hist trigger with variables being refenced. This will result in a bug
+that is easily reproducable like so
+
+$ cd /sys/kernel/tracing
+$ echo 'synthetic_sys_enter char[] comm; long id' >> synthetic_events
+$ echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger
+$ echo 'hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)' >> events/raw_syscalls/sys_enter/trigger
+$ echo '!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger
+
+[ 100.263533] ==================================================================
+[ 100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180
+[ 100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439
+[ 100.266320]
+[ 100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4
+[ 100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014
+[ 100.268561] Call Trace:
+[ 100.268902] <TASK>
+[ 100.269189] dump_stack_lvl+0x4c/0x70
+[ 100.269680] print_report+0xc5/0x600
+[ 100.270165] ? resolve_var_refs+0xc7/0x180
+[ 100.270697] ? kasan_complete_mode_report_info+0x80/0x1f0
+[ 100.271389] ? resolve_var_refs+0xc7/0x180
+[ 100.271913] kasan_report+0xbd/0x100
+[ 100.272380] ? resolve_var_refs+0xc7/0x180
+[ 100.272920] __asan_load8+0x71/0xa0
+[ 100.273377] resolve_var_refs+0xc7/0x180
+[ 100.273888] event_hist_trigger+0x749/0x860
+[ 100.274505] ? kasan_save_stack+0x2a/0x50
+[ 100.275024] ? kasan_set_track+0x29/0x40
+[ 100.275536] ? __pfx_event_hist_trigger+0x10/0x10
+[ 100.276138] ? ksys_write+0xd1/0x170
+[ 100.276607] ? do_syscall_64+0x3c/0x90
+[ 100.277099] ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8
+[ 100.277771] ? destroy_hist_data+0x446/0x470
+[ 100.278324] ? event_hist_trigger_parse+0xa6c/0x3860
+[ 100.278962] ? __pfx_event_hist_trigger_parse+0x10/0x10
+[ 100.279627] ? __kasan_check_write+0x18/0x20
+[ 100.280177] ? mutex_unlock+0x85/0xd0
+[ 100.280660] ? __pfx_mutex_unlock+0x10/0x10
+[ 100.281200] ? kfree+0x7b/0x120
+[ 100.281619] ? ____kasan_slab_free+0x15d/0x1d0
+[ 100.282197] ? event_trigger_write+0xac/0x100
+[ 100.282764] ? __kasan_slab_free+0x16/0x20
+[ 100.283293] ? __kmem_cache_free+0x153/0x2f0
+[ 100.283844] ? sched_mm_cid_remote_clear+0xb1/0x250
+[ 100.284550] ? __pfx_sched_mm_cid_remote_clear+0x10/0x10
+[ 100.285221] ? event_trigger_write+0xbc/0x100
+[ 100.285781] ? __kasan_check_read+0x15/0x20
+[ 100.286321] ? __bitmap_weight+0x66/0xa0
+[ 100.286833] ? _find_next_bit+0x46/0xe0
+[ 100.287334] ? task_mm_cid_work+0x37f/0x450
+[ 100.287872] event_triggers_call+0x84/0x150
+[ 100.288408] trace_event_buffer_commit+0x339/0x430
+[ 100.289073] ? ring_buffer_event_data+0x3f/0x60
+[ 100.292189] trace_event_raw_event_sys_enter+0x8b/0xe0
+[ 100.295434] syscall_trace_enter.constprop.0+0x18f/0x1b0
+[ 100.298653] syscall_enter_from_user_mode+0x32/0x40
+[ 100.301808] do_syscall_64+0x1a/0x90
+[ 100.304748] entry_SYSCALL_64_after_hwframe+0x6e/0xd8
+[ 100.307775] RIP: 0033:0x7f686c75c1cb
+[ 100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48
+[ 100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021
+[ 100.321200] RAX: ffffffffffffffda RBX: 000055f566469ea0 RCX: 00007f686c75c1cb
+[ 100.324631] RDX: 0000000000000001 RSI: 0000000000000001 RDI: 000000000000000a
+[ 100.328104] RBP: 00007ffc60137ac0 R08: 00007f686c818460 R09: 000000000000000a
+[ 100.331509] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009
+[ 100.334992] R13: 0000000000000007 R14: 000000000000000a R15: 0000000000000007
+[ 100.338381] </TASK>
+
+We hit the bug because when second hist trigger has was created
+has_hist_vars() returned false because hist trigger did not have
+variables. As a result of that save_hist_vars() was not called to add
+the trigger to trace_array->hist_vars. Later on when we attempted to
+remove the first histogram find_any_var_ref() failed to detect it is
+being used because it did not find the second trigger in hist_vars list.
+
+With this change we wait until trigger actions are created so we can take
+into consideration if hist trigger has variable references. Also, now we
+check the return value of save_hist_vars() and fail trigger creation if
+save_hist_vars() fails.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20230712223021.636335-1-mkhalfella@purestorage.com
+
+Cc: stable@vger.kernel.org
+Fixes: 067fe038e70f6 ("tracing: Add variable reference handling to hist triggers")
+Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_events_hist.c | 8 +++++---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+--- a/kernel/trace/trace_events_hist.c
++++ b/kernel/trace/trace_events_hist.c
+@@ -5944,13 +5944,15 @@ static int event_hist_trigger_func(struc
+ if (get_named_trigger_data(trigger_data))
+ goto enable;
+
+- if (has_hist_vars(hist_data))
+- save_hist_vars(hist_data);
+-
+ ret = create_actions(hist_data);
+ if (ret)
+ goto out_unreg;
+
++ if (has_hist_vars(hist_data) || hist_data->n_var_refs) {
++ if (save_hist_vars(hist_data))
++ goto out_unreg;
++ }
++
+ ret = tracing_map_init(hist_data->map);
+ if (ret)
+ goto out_unreg;
--- /dev/null
+From f927728186f0de1167262d6a632f9f7e96433d1a Mon Sep 17 00:00:00 2001
+From: Weitao Wang <WeitaoWang-oc@zhaoxin.com>
+Date: Fri, 2 Jun 2023 17:40:06 +0300
+Subject: xhci: Fix resume issue of some ZHAOXIN hosts
+
+From: Weitao Wang <WeitaoWang-oc@zhaoxin.com>
+
+commit f927728186f0de1167262d6a632f9f7e96433d1a upstream.
+
+On ZHAOXIN ZX-100 project, xHCI can't work normally after resume
+from system Sx state. To fix this issue, when resume from system
+Sx state, reinitialize xHCI instead of restore.
+So, Add XHCI_RESET_ON_RESUME quirk for ZX-100 to fix issue of
+resuming from system Sx state.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Weitao Wang <WeitaoWang-oc@zhaoxin.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Message-ID: <20230602144009.1225632-9-mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-pci.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -336,6 +336,11 @@ static void xhci_pci_quirks(struct devic
+ pdev->device == PCI_DEVICE_ID_AMD_PROMONTORYA_4))
+ xhci->quirks |= XHCI_NO_SOFT_RETRY;
+
++ if (pdev->vendor == PCI_VENDOR_ID_ZHAOXIN) {
++ if (pdev->device == 0x9202)
++ xhci->quirks |= XHCI_RESET_ON_RESUME;
++ }
++
+ /* xHC spec requires PCI devices to support D3hot and D3cold */
+ if (xhci->hci_version >= 0x120)
+ xhci->quirks |= XHCI_DEFAULT_PM_RUNTIME_ALLOW;
--- /dev/null
+From 2a865a652299f5666f3b785cbe758c5f57453036 Mon Sep 17 00:00:00 2001
+From: Weitao Wang <WeitaoWang-oc@zhaoxin.com>
+Date: Fri, 2 Jun 2023 17:40:07 +0300
+Subject: xhci: Fix TRB prefetch issue of ZHAOXIN hosts
+
+From: Weitao Wang <WeitaoWang-oc@zhaoxin.com>
+
+commit 2a865a652299f5666f3b785cbe758c5f57453036 upstream.
+
+On some ZHAOXIN hosts, xHCI will prefetch TRB for performance
+improvement. However this TRB prefetch mechanism may cross page boundary,
+which may access memory not allocated by xHCI driver. In order to fix
+this issue, two pages was allocated for a segment and only the first
+page will be used. And add a quirk XHCI_ZHAOXIN_TRB_FETCH for this issue.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Weitao Wang <WeitaoWang-oc@zhaoxin.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Message-ID: <20230602144009.1225632-10-mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-mem.c | 8 ++++++--
+ drivers/usb/host/xhci-pci.c | 7 ++++++-
+ drivers/usb/host/xhci.h | 1 +
+ 3 files changed, 13 insertions(+), 3 deletions(-)
+
+--- a/drivers/usb/host/xhci-mem.c
++++ b/drivers/usb/host/xhci-mem.c
+@@ -2454,8 +2454,12 @@ int xhci_mem_init(struct xhci_hcd *xhci,
+ * and our use of dma addresses in the trb_address_map radix tree needs
+ * TRB_SEGMENT_SIZE alignment, so we pick the greater alignment need.
+ */
+- xhci->segment_pool = dma_pool_create("xHCI ring segments", dev,
+- TRB_SEGMENT_SIZE, TRB_SEGMENT_SIZE, xhci->page_size);
++ if (xhci->quirks & XHCI_ZHAOXIN_TRB_FETCH)
++ xhci->segment_pool = dma_pool_create("xHCI ring segments", dev,
++ TRB_SEGMENT_SIZE * 2, TRB_SEGMENT_SIZE * 2, xhci->page_size * 2);
++ else
++ xhci->segment_pool = dma_pool_create("xHCI ring segments", dev,
++ TRB_SEGMENT_SIZE, TRB_SEGMENT_SIZE, xhci->page_size);
+
+ /* See Table 46 and Note on Figure 55 */
+ xhci->device_pool = dma_pool_create("xHCI input/output contexts", dev,
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -337,8 +337,13 @@ static void xhci_pci_quirks(struct devic
+ xhci->quirks |= XHCI_NO_SOFT_RETRY;
+
+ if (pdev->vendor == PCI_VENDOR_ID_ZHAOXIN) {
+- if (pdev->device == 0x9202)
++ if (pdev->device == 0x9202) {
+ xhci->quirks |= XHCI_RESET_ON_RESUME;
++ xhci->quirks |= XHCI_ZHAOXIN_TRB_FETCH;
++ }
++
++ if (pdev->device == 0x9203)
++ xhci->quirks |= XHCI_ZHAOXIN_TRB_FETCH;
+ }
+
+ /* xHC spec requires PCI devices to support D3hot and D3cold */
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -1906,6 +1906,7 @@ struct xhci_hcd {
+ #define XHCI_EP_CTX_BROKEN_DCS BIT_ULL(42)
+ #define XHCI_SUSPEND_RESUME_CLKS BIT_ULL(43)
+ #define XHCI_RESET_TO_DEFAULT BIT_ULL(44)
++#define XHCI_ZHAOXIN_TRB_FETCH BIT_ULL(45)
+
+ unsigned int num_active_eps;
+ unsigned int limit_active_eps;
--- /dev/null
+From d9b0328d0b8b8298dfdc97cd8e0e2371d4bcc97b Mon Sep 17 00:00:00 2001
+From: Weitao Wang <WeitaoWang-oc@zhaoxin.com>
+Date: Fri, 2 Jun 2023 17:40:08 +0300
+Subject: xhci: Show ZHAOXIN xHCI root hub speed correctly
+
+From: Weitao Wang <WeitaoWang-oc@zhaoxin.com>
+
+commit d9b0328d0b8b8298dfdc97cd8e0e2371d4bcc97b upstream.
+
+Some ZHAOXIN xHCI controllers follow usb3.1 spec, but only support
+gen1 speed 5Gbps. While in Linux kernel, if xHCI suspport usb3.1,
+root hub speed will show on 10Gbps.
+To fix this issue of ZHAOXIN xHCI platforms, read usb speed ID
+supported by xHCI to determine root hub speed. And add a quirk
+XHCI_ZHAOXIN_HOST for this issue.
+
+[fix warning about uninitialized symbol -Mathias]
+
+Suggested-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Weitao Wang <WeitaoWang-oc@zhaoxin.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Message-ID: <20230602144009.1225632-11-mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/host/xhci-mem.c | 31 ++++++++++++++++++++++++-------
+ drivers/usb/host/xhci-pci.c | 2 ++
+ drivers/usb/host/xhci.h | 1 +
+ 3 files changed, 27 insertions(+), 7 deletions(-)
+
+--- a/drivers/usb/host/xhci-mem.c
++++ b/drivers/usb/host/xhci-mem.c
+@@ -2128,7 +2128,7 @@ static void xhci_add_in_port(struct xhci
+ {
+ u32 temp, port_offset, port_count;
+ int i;
+- u8 major_revision, minor_revision;
++ u8 major_revision, minor_revision, tmp_minor_revision;
+ struct xhci_hub *rhub;
+ struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
+ struct xhci_port_cap *port_cap;
+@@ -2148,6 +2148,15 @@ static void xhci_add_in_port(struct xhci
+ */
+ if (minor_revision > 0x00 && minor_revision < 0x10)
+ minor_revision <<= 4;
++ /*
++ * Some zhaoxin's xHCI controller that follow usb3.1 spec
++ * but only support Gen1.
++ */
++ if (xhci->quirks & XHCI_ZHAOXIN_HOST) {
++ tmp_minor_revision = minor_revision;
++ minor_revision = 0;
++ }
++
+ } else if (major_revision <= 0x02) {
+ rhub = &xhci->usb2_rhub;
+ } else {
+@@ -2157,10 +2166,6 @@ static void xhci_add_in_port(struct xhci
+ /* Ignoring port protocol we can't understand. FIXME */
+ return;
+ }
+- rhub->maj_rev = XHCI_EXT_PORT_MAJOR(temp);
+-
+- if (rhub->min_rev < minor_revision)
+- rhub->min_rev = minor_revision;
+
+ /* Port offset and count in the third dword, see section 7.2 */
+ temp = readl(addr + 2);
+@@ -2179,8 +2184,6 @@ static void xhci_add_in_port(struct xhci
+ if (xhci->num_port_caps > max_caps)
+ return;
+
+- port_cap->maj_rev = major_revision;
+- port_cap->min_rev = minor_revision;
+ port_cap->psi_count = XHCI_EXT_PORT_PSIC(temp);
+
+ if (port_cap->psi_count) {
+@@ -2201,6 +2204,11 @@ static void xhci_add_in_port(struct xhci
+ XHCI_EXT_PORT_PSIV(port_cap->psi[i - 1])))
+ port_cap->psi_uid_count++;
+
++ if (xhci->quirks & XHCI_ZHAOXIN_HOST &&
++ major_revision == 0x03 &&
++ XHCI_EXT_PORT_PSIV(port_cap->psi[i]) >= 5)
++ minor_revision = tmp_minor_revision;
++
+ xhci_dbg(xhci, "PSIV:%d PSIE:%d PLT:%d PFD:%d LP:%d PSIM:%d\n",
+ XHCI_EXT_PORT_PSIV(port_cap->psi[i]),
+ XHCI_EXT_PORT_PSIE(port_cap->psi[i]),
+@@ -2210,6 +2218,15 @@ static void xhci_add_in_port(struct xhci
+ XHCI_EXT_PORT_PSIM(port_cap->psi[i]));
+ }
+ }
++
++ rhub->maj_rev = major_revision;
++
++ if (rhub->min_rev < minor_revision)
++ rhub->min_rev = minor_revision;
++
++ port_cap->maj_rev = major_revision;
++ port_cap->min_rev = minor_revision;
++
+ /* cache usb2 port capabilities */
+ if (major_revision < 0x03 && xhci->num_ext_caps < max_caps)
+ xhci->ext_caps[xhci->num_ext_caps++] = temp;
+--- a/drivers/usb/host/xhci-pci.c
++++ b/drivers/usb/host/xhci-pci.c
+@@ -337,6 +337,8 @@ static void xhci_pci_quirks(struct devic
+ xhci->quirks |= XHCI_NO_SOFT_RETRY;
+
+ if (pdev->vendor == PCI_VENDOR_ID_ZHAOXIN) {
++ xhci->quirks |= XHCI_ZHAOXIN_HOST;
++
+ if (pdev->device == 0x9202) {
+ xhci->quirks |= XHCI_RESET_ON_RESUME;
+ xhci->quirks |= XHCI_ZHAOXIN_TRB_FETCH;
+--- a/drivers/usb/host/xhci.h
++++ b/drivers/usb/host/xhci.h
+@@ -1907,6 +1907,7 @@ struct xhci_hcd {
+ #define XHCI_SUSPEND_RESUME_CLKS BIT_ULL(43)
+ #define XHCI_RESET_TO_DEFAULT BIT_ULL(44)
+ #define XHCI_ZHAOXIN_TRB_FETCH BIT_ULL(45)
++#define XHCI_ZHAOXIN_HOST BIT_ULL(46)
+
+ unsigned int num_active_eps;
+ unsigned int limit_active_eps;
--- /dev/null
+From bc8d5916541fa19ca5bc598eb51a5f78eb891a36 Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+Date: Mon, 3 Jul 2023 11:01:42 -0700
+Subject: xtensa: ISS: fix call to split_if_spec
+
+From: Max Filippov <jcmvbkbc@gmail.com>
+
+commit bc8d5916541fa19ca5bc598eb51a5f78eb891a36 upstream.
+
+split_if_spec expects a NULL-pointer as an end marker for the argument
+list, but tuntap_probe never supplied that terminating NULL. As a result
+incorrectly formatted interface specification string may cause a crash
+because of the random memory access. Fix that by adding NULL terminator
+to the split_if_spec argument list.
+
+Cc: stable@vger.kernel.org
+Fixes: 7282bee78798 ("[PATCH] xtensa: Architecture support for Tensilica Xtensa Part 8")
+Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/xtensa/platforms/iss/network.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/xtensa/platforms/iss/network.c
++++ b/arch/xtensa/platforms/iss/network.c
+@@ -231,7 +231,7 @@ static int tuntap_probe(struct iss_net_p
+
+ init += sizeof(TRANSPORT_TUNTAP_NAME) - 1;
+ if (*init == ',') {
+- rem = split_if_spec(init + 1, &mac_str, &dev_name);
++ rem = split_if_spec(init + 1, &mac_str, &dev_name, NULL);
+ if (rem != NULL) {
+ pr_err("%s: extra garbage on specification : '%s'\n",
+ dev->name, rem);
projects / thirdparty / kernel / stable-queue.git / commitdiff
