3.16 was EOL in 2020.
4.4 was EOL in 2022.
5.10 is new in 2020.
5.15 is new in 2021.
We'll see if 6.1 becomes LTS in 2022.
Link: https://lore.kernel.org/stable/514c425e2b4dca71a11b0c669746d3122f7039a5.cam…
Link: https://lore.kernel.org/stable/1643877137240249@kroah.com/
Signed-off-by: Nick Desaulniers <ndesaulniers(a)google.com>
---
Documentation/process/2.Process.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/2.Process.rst b/Documentation/process/2.Process.rst
index e05fb1b8f8b6..9ae64376a8d4 100644
--- a/Documentation/process/2.Process.rst
+++ b/Documentation/process/2.Process.rst
@@ -130,12 +130,12 @@ for a longer period. As of this writing, the current long term kernels
and their maintainers are:
====== ================================ =======================
- 3.16 Ben Hutchings (very long-term kernel)
- 4.4 Greg Kroah-Hartman & Sasha Levin (very long-term kernel)
4.9 Greg Kroah-Hartman & Sasha Levin
4.14 Greg Kroah-Hartman & Sasha Levin
4.19 Greg Kroah-Hartman & Sasha Levin
5.4 Greg Kroah-Hartman & Sasha Levin
+ 5.10 Greg Kroah-Hartman & Sasha Levin
+ 5.15 Greg Kroah-Hartman & Sasha Levin
====== ================================ =======================
The selection of a kernel for long-term support is purely a matter of a
--
2.38.0.413.g74048e4d9e-goog
سلام big_home_movies_sex
ijq.page.link/qCQA#
Soild عزیز به وب سایت ما خوش آمدید،
از اینکه در وب سایت مرکز اورال دیزاین ایران ثبت نام نموده اید متشکریم.
شما هم اکنون می توانید در سایت https://www.oraldesign-iran.com/ با استفاده از نام کاربری و رمز عبور زیر وارد شوید:
نام کاربری: big_home_movies_sex ijq.page.link/qCQA#Soild
رمز عبور: best_way_for_oral_sex
olr.page.link/KH9p#
Bup
Hello stable,
please backport the following commits to 5.15-stable:
commit 973b9e37330656dec719ede508e4dc40e5c2d80c upstream.
Please note that the extra backport below can be avoided with a
trivial change in the above patch. Let me know if that's preferable.
Cc: <stable(a)vger.kernel.org> # 5.15.y: e921da6: arm64/mm: Consolidate
TCR_EL1 fields
Signed-off-by: Evgenii Stepanov <eugenis(a)google.com>
This patch fixes a double sock_release() call when the listen() is
called for the dlm lowcomms listen socket. The caller of
dlm_listen_for_all should never care about releasing the socket if
dlm_listen_for_all() fails, it's done now only once if listen() fails.
Cc: stable(a)vger.kernel.org
Fixes: 2dc6b1158c28 ("fs: dlm: introduce generic listen")
Signed-off-by: Alexander Aring <aahringo(a)redhat.com>
---
fs/dlm/lowcomms.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/dlm/lowcomms.c b/fs/dlm/lowcomms.c
index 59f64c596233..2cb9f3b49e05 100644
--- a/fs/dlm/lowcomms.c
+++ b/fs/dlm/lowcomms.c
@@ -1820,7 +1820,7 @@ static int dlm_listen_for_all(void)
result = sock->ops->listen(sock, 5);
if (result < 0) {
dlm_close_sock(&listen_con.sock);
- goto out;
+ return result;
}
return 0;
@@ -2023,7 +2023,6 @@ int dlm_lowcomms_start(void)
dlm_proto_ops = NULL;
fail_proto_ops:
dlm_allow_conn = 0;
- dlm_close_sock(&listen_con.sock);
work_stop();
fail_local:
deinit_local();
--
2.31.1
From qjv001@qjv001-XeonWs Tue Oct 18 15:37:29 2022
From: qjv001 <qjv001@qjv001-XeonWs>
To: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com>
Subject: Re: [PATCH v3 2/6] usb: dwc3: gadget: cancel requests instead of
release after missed isoc
References: <20221017205446.523796-1-w36195(a)motorola.com>
<20221017205446.523796-3-w36195(a)motorola.com>
<20221017213031.tqb575hdzli7jlbh(a)synopsys.com>
<Y04K/HoUigF5FYBA@p1g3>
<20221018184535.3g3sm35picdeuajs(a)synopsys.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20221018184535.3g3sm35picdeuajs(a)synopsys.com>
X-Mutt-References: <20221018184535.3g3sm35picdeuajs(a)synopsys.com>
X-Mutt-Fcc: ~/sent
Status: RO
Date: Tue, 18 Oct 2022 15:37:29 -0500
Content-Length: 5434
Lines: 124
Hi Thinh,
On Tue, Oct 18, 2022 at 06:45:40PM +0000, Thinh Nguyen wrote:
> Hi Dan,
>
> On Mon, Oct 17, 2022, Dan Vacura wrote:
> > Hi Thinh,
> >
> > On Mon, Oct 17, 2022 at 09:30:38PM +0000, Thinh Nguyen wrote:
> > > On Mon, Oct 17, 2022, Dan Vacura wrote:
> > > > From: Jeff Vanhoof <qjv001(a)motorola.com>
> > > >
> > > > arm-smmu related crashes seen after a Missed ISOC interrupt when
> > > > no_interrupt=1 is used. This can happen if the hardware is still using
> > > > the data associated with a TRB after the usb_request's ->complete call
> > > > has been made. Instead of immediately releasing a request when a Missed
> > > > ISOC interrupt has occurred, this change will add logic to cancel the
> > > > request instead where it will eventually be released when the
> > > > END_TRANSFER command has completed. This logic is similar to some of the
> > > > cleanup done in dwc3_gadget_ep_dequeue.
> > >
> > > This doesn't sound right. How did you determine that the hardware is
> > > still using the data associated with the TRB? Did you check the TRB's
> > > HWO bit?
> >
> > The problem we're seeing was mentioned in the summary of this patch
> > series, issue #1. Basically, with the following patch
> > https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-usb/…
> > integrated a smmu panic is occurring on our Android device with the 5.15
> > kernel which is:
> >
> > <3>[ 718.314900][ T803] arm-smmu 15000000.apps-smmu: Unhandled arm-smmu context fault from a600000.dwc3!
> >
> > The uvc gadget driver appears to be the first (and only) gadget that
> > uses the no_interrupt=1 logic, so this seems to be a new condition for
> > the dwc3 driver. In our configuration, we have up to 64 requests and the
> > no_interrupt=1 for up to 15 requests. The list size of dep->started_list
> > would get up to that amount when looping through to cleanup the
> > completed requests. From testing and debugging the smmu panic occurs
> > when a -EXDEV status shows up and right after
> > dwc3_gadget_ep_cleanup_completed_request() was visited. The conclusion
> > we had was the requests were getting returned to the gadget too early.
>
> As I mentioned, if the status is updated to missed isoc, that means that
> the controller returned ownership of the TRB to the driver. At least for
> the particular request with -EXDEV, its TRBs are completed. I'm not
> clear on your conclusion.
>
> Do we know where did the crash occur? Is it from dwc3 driver or from uvc
> driver, and at what line? It'd great if we can see the driver log.
>
To interject, what should happen in dwc3_gadget_ep_reclaim_completed_trb if the
IOC bit is not set (but the IMI bit is) and -EXDEV status is passed into it?
If the function returns 0, another attempt to reclaim may occur. If this
happens and the next request did have the HWO bit set, the function would
return 1 but dwc3_gadget_ep_cleanup_completed_request would still call
dwc3_gadget_giveback.
As a test (without this patch), I added a check to see if HWO bit was set in
dwc3_gadget_ep_cleanup_completed_requests(). If the usecase was ISOC and the
HWO bit was set I avoided calling dwc3_gadget_ep_cleanup_completed_request().
This seemed to also avoid the iommu related crash being seen.
Is there an issue in this area that needs to be corrected instead? Not having
interrupts set for each request may be causing some new issues to be uncovered.
As far as the crash seen without this patch, no good stacktrace is given. Line
provided for crash varied a bit, but tended to appear towards the end of
dwc3_stop_active_transfer() or dwc3_gadget_endpoint_trbs_complete().
Since dwc3_gadget_endpoint_trbs_complete() can be called from multiple
locations, I duplicated the function to help identify which path it was likely
being called from. At the time of the crashes seen,
dwc3_gadget_endpoint_transfer_in_progress() appeared to be the caller.
dwc3_gadget_endpoint_transfer_in_progress()
->dwc3_gadget_endpoint_trbs_complete() (crashed towards end of here)
->dwc3_stop_active_transfer() (sometimes crashed towards end of here)
I hope this clarifies things a bit.
> >
> > >
> > > The dwc3 driver would only give back the requests if the TRBs of the
> > > associated requests are completed or when the device is disconnected.
> > > If the TRB indicated missed isoc, that means that the TRB is completed
> > > and its status was updated.
> >
> > Interesting, the device is not disconnected as we don't get the
> > -ESHUTDOWN status back and with this patch in place things continue
> > after a -EXDEV status is received.
> >
>
> Actually, minor correction here: a recent change
> b44c0e7fef51 ("usb: dwc3: gadget: conditionally remove requests")
> changed -ESHUTDOWN request status to -ECONNRESET when disable endpoint.
> This doesn't look right.
>
> While disabling endpoint may also apply for other cases such as
> switching alternate interface in addition to disconnect, -ESHUTDOWN
> seems more fitting there.
>
btw, we don't have "usb: dwc3: gadget: conditionally remove requests" in our baseline
> Hi Michael,
>
> Can you help clarify for the change above? This changed the usage of
> requests. Now requests returned by disconnection won't be returned as
> -ESHUTDOWN.
>
> > >
> > > There's a special case which dwc3 may give back requests early is the
> > > case of the device disconnecting. The requests should be returned with
> > > -ESHUTDOWN, and the gadget driver shouldn't be re-using the requests on
> > > de-initialization anyway.
> > >
> > > We should not issue End Transfer command just because of missed isoc. We
> > > may want issue End Transfer if the gadget driver is too slow and unable
> > > to feed requests in time (causing underrun and missed isoc) to resync
> > > with the host, but we already handle that.
> >
> > Hmm, isn't that what happens when we get into this
> > condition in dwc3_gadget_endpoint_trbs_complete():
> >
> > if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
> > list_empty(&dep->started_list) &&
> > (list_empty(&dep->pending_list) || status == -EXDEV))
> > dwc3_stop_active_transfer(dep, true, true);
> >
>
> Yes, it's being handled there.
>
> > >
> > > I'm still not clear what's the problem you're seeing. Do you have the
> > > crash log? Tracepoints?
> > >
> >
> > Appreciate the support!
> >
>
> Thanks,
> Thinh
Thanks,
Jeff
The ACPI CEDT.CFMWS indicates a range of possible address where new CXL
regions can appear. Each range is associated with a QTG id (QoS
Throttling Group id). For each range + QTG pair that is not covered by a proximity
domain in the SRAT, Linux creates a new NUMA node. However, the commit
that added the new ranges missed updating the node_possible mask which
causes memory_group_register() to fail. Add the new nodes to the
nodes_possible mask.
Cc: <stable(a)vger.kernel.org>
Fixes: fd49f99c1809 ("ACPI: NUMA: Add a node and memblk for each CFMWS not in SRAT")
Cc: Alison Schofield <alison.schofield(a)intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>
Reported-by: Vishal Verma <vishal.l.verma(a)intel.com>
Tested-by: Vishal Verma <vishal.l.verma(a)intel.com>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
---
Rafael, I can take this through the CXL tree with some other pending
fixes.
drivers/acpi/numa/srat.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c
index 3b818ab186be..1f4fc5f8a819 100644
--- a/drivers/acpi/numa/srat.c
+++ b/drivers/acpi/numa/srat.c
@@ -327,6 +327,7 @@ static int __init acpi_parse_cfmws(union acpi_subtable_headers *header,
pr_warn("ACPI NUMA: Failed to add memblk for CFMWS node %d [mem %#llx-%#llx]\n",
node, start, end);
}
+ node_set(node, numa_nodes_parsed);
/* Set the next available fake_pxm value */
(*fake_pxm)++;
Static analysis tools indicate that indirect target
minstrel_ht_get_expected_throughput() could be used as a disclosure
gadget for Intra-mode Branch Target Injection (IMBTI) or Branch History
Injection (BHI).
ASM generated by compilers indicate a construct of a typical disclosure
gadget, where function arguments can be used to speculatively access and
transmit the contents of an arbitrary memory location.
Mitigate it by adding a speculation barrier.
Reported-by: Scott D. Constable <scott.d.constable(a)intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
---
net/mac80211/rc80211_minstrel_ht.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 788a82f9c74d..af66e5c8dcfa 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -11,6 +11,7 @@
#include <linux/moduleparam.h>
#include <linux/ieee80211.h>
#include <linux/minmax.h>
+#include <linux/nospec.h>
#include <net/mac80211.h>
#include "rate.h"
#include "sta_info.h"
@@ -1998,6 +1999,14 @@ static u32 minstrel_ht_get_expected_throughput(void *priv_sta)
struct minstrel_ht_sta *mi = priv_sta;
int i, j, prob, tp_avg;
+ /*
+ * Protect against IMBTI/BHI.
+ *
+ * Transiently executing this function with an adversary controlled
+ * argument may disclose secrets. Speculation barrier prevents that.
+ */
+ barrier_nospec();
+
i = MI_RATE_GROUP(mi->max_tp_rate[0]);
j = MI_RATE_IDX(mi->max_tp_rate[0]);
prob = mi->groups[i].rates[j].prob_avg;
--
2.37.3
barrier_nospec() is a speculation barrier with arch dependent
implementation. To be able to use barrier_nospec() in non-architecture
code add a generic version that does nothing. Architectures that don't
have a use case for speculation barrier shouldn't need to define an arch
specific version.
Architectures needing speculation barrier can override the generic
version in their asm/barrier.h.
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
---
include/linux/nospec.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/nospec.h b/include/linux/nospec.h
index c1e79f72cd89..60e040a5df27 100644
--- a/include/linux/nospec.h
+++ b/include/linux/nospec.h
@@ -60,6 +60,10 @@ static inline unsigned long array_index_mask_nospec(unsigned long index,
(typeof(_i)) (_i & _mask); \
})
+#ifndef barrier_nospec
+#define barrier_nospec() do { } while (0)
+#endif
+
/* Speculation control prctl */
int arch_prctl_spec_ctrl_get(struct task_struct *task, unsigned long which);
int arch_prctl_spec_ctrl_set(struct task_struct *task, unsigned long which,
--
2.37.3