| Age | Commit message (Collapse) | Author |
|---|
|
commit 5027d54a9c30bc7ec808360378e2b4753f053f25 upstream.
accept_ra_min_rtr_lft only considered the lifetime of the default route
and discarded entire RAs accordingly.
This change renames accept_ra_min_rtr_lft to accept_ra_min_lft, and
applies the value to individual RA sections; in particular, router
lifetime, PIO preferred lifetime, and RIO lifetime. If any of those
lifetimes are lower than the configured value, the specific RA section
is ignored.
In order for the sysctl to be useful to Android, it should really apply
to all lifetimes in the RA, since that is what determines the minimum
frequency at which RAs must be processed by the kernel. Android uses
hardware offloads to drop RAs for a fraction of the minimum of all
lifetimes present in the RA (some networks have very frequent RAs (5s)
with high lifetimes (2h)). Despite this, we have encountered networks
that set the router lifetime to 30s which results in very frequent CPU
wakeups. Instead of disabling IPv6 (and dropping IPv6 ethertype in the
WiFi firmware) entirely on such networks, it seems better to ignore the
misconfigured routers while still processing RAs from other IPv6 routers
on the same network (i.e. to support IoT applications).
The previous implementation dropped the entire RA based on router
lifetime. This turned out to be hard to expand to the other lifetimes
present in the RA in a consistent manner; dropping the entire RA based
on RIO/PIO lifetimes would essentially require parsing the whole thing
twice.
Fixes: 1671bcfd76fd ("net: add sysctl accept_ra_min_rtr_lft")
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Patrick Rohr <prohr@google.com>
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20230726230701.919212-1-prohr@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1671bcfd76fdc0b9e65153cf759153083755fe4c upstream.
This change adds a new sysctl accept_ra_min_rtr_lft to specify the
minimum acceptable router lifetime in an RA. If the received RA router
lifetime is less than the configured value (and not 0), the RA is
ignored.
This is useful for mobile devices, whose battery life can be impacted
by networks that configure RAs with a short lifetime. On such networks,
the device should never gain IPv6 provisioning and should attempt to
drop RAs via hardware offload, if available.
Signed-off-by: Patrick Rohr <prohr@google.com>
Cc: Maciej Żenczykowski <maze@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit fcd7c26901c83681532c6daac599e53d4df11738 ]
The two existing trusted key sources don't make use of the kernel RNG,
but instead let the hardware doing the sealing/unsealing also
generate the random key material. However, both users and future
backends may want to place less trust into the quality of the trust
source's random number generator and instead reuse the kernel entropy
pool, which can be seeded from multiple entropy sources.
Make this possible by adding a new trusted.rng parameter,
that will force use of the kernel RNG. In its absence, it's up
to the trust source to decide, which random numbers to use,
maintaining the existing behavior.
Suggested-by: Jarkko Sakkinen <jarkko@kernel.org>
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Acked-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: David Gstir <david@sigma-star.at>
Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Tested-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E)
Tested-by: John Ernberg <john.ernberg@actia.se> # iMX8QXP
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Stable-dep-of: 01bbafc63b65 ("KEYS: trusted: Remove redundant static calls usage")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
# Conflicts:
# net/hsr/hsr_forward.c
|
|
This is the 5.15.133 stable release
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUOq3oACgkQONu9yGCS
# aT6+5A//YHQ1kMXB9u4AvvKP5RaOpQxKmarumYWw1gKsLJ5uzGlw5zryPzq353Pu
# aoCBIbYospy7p5zLu+UCMZBH/hWWoKbsvsR2FUBLW9q3L/BvREwZY0HTeGEWSDB1
# Z6TIu6ESSFJ1QWSRJDikchaCqcpFWJNcuWRJXnpXJV9NzGF1ERcjwIUtD4a05C2Z
# xLJpu7HpBE2dVgQn+yepXNaHtRIsIuVv83xNjj4IMhhU+L9CnR9kJlJ4tICvlphi
# 7ub+lPVBEBU8g9+3tbYSwbw0OLRZ5VG1VKUhrmP1LA2joQY3lTiB1ojdGtVEmYBQ
# FHAvJME6D5DSap3LrK/4kUbytp2CjB0yHHi5B8nYnOfm7NXfL9WMOUnYVtirA/Qz
# yW7/SN52zrHzXp4WVruJrc67XO347WEEZ9uhHWL6MVYouwkARa0DZjahqtxwY5Ds
# Qh7uwUmyE6GZ8vbcCgsrCNl8+gQaeF6w2nDmqLGigpalSwWxkBrtZnfB85WqfUfJ
# pGpJdDIqQUYB1ahTmSW8eHvm9Dm1wUmheRuDBsURxxYq97Gmy8fOa8PVwbVCjS5q
# EHhzbX6aC9m4kPg7mUhWRNxjGpmyntvXwZ6oF3J+MIl0vsjjo7uXxRIrH1q+hn4f
# TKPCC8EYM9IMAn8PpBIKDd/xhoBF/hgHbzhsuKNb5mEZlIO0GI0=
# =RCtk
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 23 Sep 2023 05:10:18 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
# Conflicts:
# fs/jbd2/transaction.c
|
|
This is the 5.15.132 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUJdpAACgkQONu9yGCS
# aT7LKA//TbjfOj1RRRPE916bAbXiUwXoDDOFaAnUj8+QRLAxDB6g8U2uAMRdPwrE
# ChCFkRfma3u1hUloRp4w+IVxDNpyeTYDkK7VK5P0GSX+CUJj8ZtVCGMIYcyzdK18
# UHff2rCQVhkfzfXPxUVYws2JEtFqxeO1VsNJEVFLhMJ1NHePLyrMFyAQNLrLlk8K
# mxHjjpNdImSdgh8agAgioUaq+RvrWt2X0CTL8NC3HAU4PwMuDjTiB2YFD3PcQloS
# Pszqw1oenTQG9PwuwtnWJyn2U0RkD+IkEXj99ED/ocs73aHOmQ31jjcDXcz3gNJ5
# dZVktqD7y1tAQlivvsiwgumeJWxBQ9u5bEf1i8bAYfjelT6TyNuhk+JDWGRBYetd
# fOddhoNHw7KFvB8RKNSW/R+gt6RaeQZB8JN+9qF6vlit/uSP3wC0klKV56gKhXY9
# DMQ9j/FCLHrxOo5vgvMu5LTXJOyn/hgdQ9kYVT7Yz4Y2JDuFR6pE4xzuVsxIhnyX
# TIzp8ywsAKDl2d2OZCzp5S9YXxkVDBj0xJIxFSjyq9JPW9iVh18AEsIgkvwBjh/P
# 5okd3AIw+zU45dHDDsnePslFxl90La5cACuwEJzGsGuDYomdiUeqSCkB/5zcAWTn
# nra2BuxEI/DVHOifygJ4rZA9IBxIUoPrAbIPHR1Knjll+lfSVGY=
# =blAW
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 19 Sep 2023 06:23:12 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 5.15.130 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTy4X8ACgkQONu9yGCS
# aT79nQ/9FeYdbMntN6RtqQWEcKNVndxcSJaUeR279LGztnCeY0BnFEBsf6M4hs7y
# Zk5X1YORKDL6CcNnD5HWc++5fR0mI9B992BovswlU40kW1zvRXOujaeVRLllJWSi
# gKWF6gWUEM7hHe0GWp/buOuKfWsC0KXJQQ5AlEFtQaeVdsC8dq6CWvDTOlvPmXCf
# 7a3KKLg0VDAd7c8NQ/UHtdVfGYrJ57sbM2aCfM4jYJOXql0+FGn38hCx5R8/jlaQ
# ikfiKYHPZKK5fGUGjQKemi3+xfFiCfvm1A9YuwOhuqLzejFqcuxWFuSB8WDO0+gr
# T0gJz8taYRVrNeLsyR6+MOcVAYFyNP2v9dbzA0Yd3LV/Su9S5L3pckrbe6Nd3875
# vCt6l0JC416zud+UXno9KHzKY/hpflwZhnAf+vhDW5l4pcGkSzD9qP4CiuXtNrGY
# dj0FxcWWWtAmVIlthe4sym/yvZrj3qgrYcunmRZrf5dMw8AyIVajQf8NFEDwph7L
# VrvkF4PhbqVVUQpqz/19lrfFn3ZgJuE7L84H2c4YdKzlUVfNqXUkUEynYjsej+0Y
# zj4x02GI957d2bfnH0BhrtaqSXiuuegiU0NKc+Qemn98S9QCwrHPpP6K6PmXNk/W
# jJTPSCbZjjZWFvwqyq8v7IxPtxzMS1G5CxSyu6VT7OzEp207NKw=
# =ykoO
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 02 Sep 2023 03:17:19 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit 0242737dc4eb9f6e9a5ea594b3f93efa0b12f28d ]
Some HiSilicon SMMU PMCG suffers the erratum 162001900 that the PMU
disable control sometimes fail to disable the counters. This will lead
to error or inaccurate data since before we enable the counters the
counter's still counting for the event used in last perf session.
This patch tries to fix this by hardening the global disable process.
Before disable the PMU, writing an invalid event type (0xffff) to
focibly stop the counters. Correspondingly restore each events on
pmu::pmu_enable().
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Link: https://lore.kernel.org/r/20230814124012.58013-1-yangyicong@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 172044e30b00977784269e8ab72132a48293c654 upstream.
select:false makes the schema basically ignored and not effective, which
is clearly not what we want for a device binding.
Fixes: 352546805a44 ("dt-bindings: clock: Add bindings for versal clock driver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230728165923.108589-1-krzysztof.kozlowski@linaro.org
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f669b8a683e4ee26fa5cafe19d71cec1786b556a upstream.
Because scsi_finish_command() subtracts the residual from the buffer
length, residual overflows must not be reported. Reflect this in the SCSI
documentation. See also commit 9237f04e12cc ("scsi: core: Fix
scsi_get/set_resid() interface")
Cc: Damien Le Moal <dlemoal@kernel.org>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Douglas Gilbert <dgilbert@interlog.com>
Cc: stable@vger.kernel.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20230721160154.874010-2-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5f641174a12b8a876a4101201a21ef4675ecc014 upstream.
The `nocrt` module parameter has no code associated with it and does
nothing. As `crt=-1` has same functionality as what nocrt should be
doing drop `nocrt` and associated documentation.
This should fix a quirk for Gigabyte GA-7ZX that used `nocrt` and
thus didn't function properly.
Fixes: 8c99fdce3078 ("ACPI: thermal: set "thermal.nocrt" via DMI on Gigabyte GA-7ZX")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
This is the 5.15.128 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTp7tMACgkQONu9yGCS
# aT7/QA/9H1u9jFZ20L4z83pDbODjwbr3YYnJOEOraoPxIaMy+VTkGkgOWnSa+vii
# u4hqborqfJQxtd3ZzLy1/yS9YvSZmTCnhn4ET4RiO4S8CsQmqdIF9oU8W+NAAQNu
# 94gXBLX+e+dIYm29/ra7RjZx9T21gir7BwDiyS01DHMjGi9mJBe/5tUjpc8JB+kZ
# eez/x+th7naL5BN5rBnHqYA5bsF3NYSaOaJG80yUyG8if8PAT2F9kpaePr1Pwh4L
# FWIhGC/qCUq/Im0vhMluQSRKHggE74rKYVfZk9bVzbhKd9Y52uE68/FxRQQcK9ZX
# p0pvhJykiy97Ufxl0d9qGeOUVHw0fReZyY97T3mHHfQoa5FQnSEtXkDQz4JDoens
# MN0FL2i4oVvh57TyVN/VNjXVf33h1OXo7GeCPHWaeGRCn13BL+QuXJd/GSEc1i2P
# 3yvaELPJ/KKWxa5iU+jH4/OHZh46tBgw3lMpVCVjyOTTSzkYhpsm/4/XxcFYFZpr
# XpZum+KK2znylypPEPJ2RSSdDMN52Rap/c01epljhJFDRltrBbGWrXR1VOWUwJal
# MyxKaKqCm5jJKZ/KYPuk2+zh8NFXf3/hHpR+ID7fcufOE/34sirC23ETaQ73rCic
# ObR0TC6jHevrvAoH3AzO1MDMWSi5OuVNvNM4c9sD4ceuOHACmpg=
# =x7o6
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 26 Aug 2023 08:23:47 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 42be649dd1f2eee6b1fb185f1a231b9494cf095f upstream.
For a more consistent namespace.
[ bp: Fixup names in the doc too. ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/r/20230814121148.976236447@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
This is the 5.15.126 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTWRIsACgkQONu9yGCS
# aT4H8w//dG/Wgxtk8Z80PCsPceeGpYyejMqSdy4lAkfdj4nqSHeVLfkJSpDR4Y59
# bk+zFKuAjP1Oe3UxmCdXFawe36EnLRCgH29pkL9Kyub8p+WbcwG7YYwCBxhiYq9V
# Y9laUTlPHOkpjSkHElI9tDfZ8VmPtW7+fC92LzwxlX6TXdpqjNumG+vU58iyJ31B
# SZBGmnJcB9tjHPE85n81PN4kOIURvMp4KxUsCE0dGGFlo3i0T8X6jkimvCZLJMLI
# r9EFNeC5uPtCgIpqSCQ5LzCaI9/o2WhYzY0HEXA73MZTbNFJt2vNUv7f8nky28oy
# piweMTkmBedMUPuA8o2XnPKP3LUved+sxvBulUWI6i6YOTr/tVBBuX9+cWd59lxX
# R3mW2vOkN267PcfD7UBo0k6i3TTvXi/boRO5IplIrgHkgtd/zt2rkeugGNxKC4n9
# 5seP+XqHIqxGiP0ptAqlR2E+h6g5Eyt6mmj1Qe6wp97vo4pfBxDe8FRWrFWAZP6n
# /UtK5mJ1yrGF8+m9J58905qIvtQ5ty7dVIqMHYThcM/7SPyqlMRXU7QnhmeqaV9n
# 1P7fqOZkUOu5bB1ma/gsOj8HQiJMiohnHUJfVyGocJOcGoUSxqUCRy/iwIwrcrlY
# 7sxznDE9xd4eTa/MHeU36wf4m+LntnEklmjyLHlUBgXfF2aROdo=
# =wwTt
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 11 Aug 2023 10:24:11 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 0bfbfc526c70606bf0fad302e4821087cbecfaf4 upstream
Both MMU-600 and MMU-700 have similar errata around TLB invalidation
while both stages of translation are active, which will need some
consideration once nesting support is implemented. For now, though,
it's very easy to make our implicit lack of nesting support explicit
for those cases, so they're less likely to be missed in future.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Link: https://lore.kernel.org/r/696da78d32bb4491f898f11b0bb4d850a8aa7c6a.1683731256.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 309a15cb16bb075da1c99d46fb457db6a1a2669e upstream
To work around MMU-700 erratum 2812531 we need to ensure that certain
sequences of commands cannot be issued without an intervening sync. In
practice this falls out of our current command-batching machinery
anyway - each batch only contains a single type of invalidation command,
and ends with a sync. The only exception is when a batch is sufficiently
large to need issuing across multiple command queue slots, wherein the
earlier slots will not contain a sync and thus may in theory interleave
with another batch being issued in parallel to create an affected
sequence across the slot boundary.
Since MMU-700 supports range invalidate commands and thus we will prefer
to use them (which also happens to avoid conditions for other errata),
I'm not entirely sure it's even possible for a single high-level
invalidate call to generate a batch of more than 63 commands, but for
the sake of robustness and documentation, wire up an option to enforce
that a sync is always inserted for every slot issued.
The other aspect is that the relative order of DVM commands cannot be
controlled, so DVM cannot be used. Again that is already the status quo,
but since we have at least defined ARM_SMMU_FEAT_BTM, we can explicitly
disable it for documentation purposes even if it's not wired up anywhere
yet.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Link: https://lore.kernel.org/r/330221cdfd0003cd51b6c04e7ff3566741ad8374.1683731256.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f322e8af35c7f23a8c08b595c38d6c855b2d836f upstream
MMU-600 versions prior to r1p0 fail to correctly generate a WFE wakeup
event when the command queue transitions fom full to non-full. We can
easily work around this by simply hiding the SEV capability such that we
fall back to polling for space in the queue - since MMU-600 implements
MSIs we wouldn't expect to need SEV for sync completion either, so this
should have little to no impact.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Tested-by: Nicolin Chen <nicolinc@nvidia.com>
Link: https://lore.kernel.org/r/08adbe3d01024d8382a478325f73b56851f76e49.1683731256.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8d81b2a38ddfc4b03662d2359765648c8b4cc73c upstream
Arm Neoverse-N2 and Cortex-A710 cores are affected by an erratum where
the trbe, under some circumstances, might write upto 64bytes to an
address after the Limit as programmed by the TRBLIMITR_EL1.LIMIT.
This might -
- Corrupt a page in the ring buffer, which may corrupt trace from a
previous session, consumed by userspace.
- Hit the guard page at the end of the vmalloc area and raise a fault.
To keep the handling simpler, we always leave the last page from the
range, which TRBE is allowed to write. This can be achieved by ensuring
that we always have more than a PAGE worth space in the range, while
calculating the LIMIT for TRBE. And then the LIMIT pointer can be
adjusted to leave the PAGE (TRBLIMITR.LIMIT -= PAGE_SIZE), out of the
TRBE range while enabling it. This makes sure that the TRBE will only
write to an area within its allowed limit (i.e, [head-head+size]) and
we do not have to handle address faults within the driver.
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20211019163153.3692640-5-suzuki.poulose@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fa82d0b4b833790ac4572377fb777dcea24a9d69 upstream
Arm Neoverse-N2 (#2067961) and Cortex-A710 (#2054223) suffers
from errata, where a TSB (trace synchronization barrier)
fails to flush the trace data completely, when executed from
a trace prohibited region. In Linux we always execute it
after we have moved the PE to trace prohibited region. So,
we can apply the workaround every time a TSB is executed.
The work around is to issue two TSB consecutively.
NOTE: This errata is defined as LOCAL_CPU_ERRATUM, implying
that a late CPU could be blocked from booting if it is the
first CPU that requires the workaround. This is because we
do not allow setting a cpu_hwcaps after the SMP boot. The
other alternative is to use "this_cpu_has_cap()" instead
of the faster system wide check, which may be a bit of an
overhead, given we may have to do this in nvhe KVM host
before a guest entry.
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20211019163153.3692640-4-suzuki.poulose@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
This is the 5.15.125 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTSgosACgkQONu9yGCS
# aT44WA/9EQUHO98jWu+kvgqkTuFPoO6FaDXw4iaQkb9YSQKKQnEhRuyJ28Cyf7up
# cvlvUlTPa62DLQ7Gmy9BLXneuUjE2iwI2Tr/W3VJgSYS3sKvh4f3/tteJdrnqLDA
# NHaUvGV/EJs1PxiVeim5aC07SNOV3Wk1wrlU2iH9W7m4QEKMjNGGgXNkmmoG3rMC
# RMDAaX4x43rgBXKkmZQgRnFvUlYzw3h038Hm3a2mXA7DFjiSDHE3OnWDWZTuLyR8
# lYsLuEC2u7RO+jUgXgXDSdyeqimhaiooRSPXgZ7LvHqcdd6eBggB4ZDxFtdoDK49
# ItwZaHuYFAImEAK6tY1rbBG1Bcj4E3nvpIwcqUDJOpoLX4z7cU3D1SHIoQqflgzw
# GtJ5Q+OI1rs8vPTniIKpeFIe7Zi8R10S5fXKw4kGwDOvJaqTDr8FW2HoIJu0+hlf
# Fw3Z/DvoQQzJ8akBJJicWHx5eGlk0n85+3XiOu3AFtWz7REpp2kAgX4nExZEprrL
# F+DllJVzBF4G7nxzs8Mj2le6HqYfFEgIkhCscJGw8Z903mEcRtjX3AZFrzYZfqQu
# ODW6dDYJC94GaxiMQNSLyTL3nLfEKvy67AvN/zbkk+3DMfI4pxZfrsmrNXS/YBU2
# huOCsxPVNYmmGrimirbYACMhN65D0SIBgvqsc8tkdH4oBCT8xRQ=
# =3VnP
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 08 Aug 2023 01:59:39 PM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
Upstream commit: fb3bd914b3ec28f5fb697ac55c4846ac2d542855
Add a mitigation for the speculative return address stack overflow
vulnerability found on AMD processors.
The mitigation works by ensuring all RET instructions speculate to
a controlled location, similar to how speculation is controlled in the
retpoline sequence. To accomplish this, the __x86_return_thunk forces
the CPU to mispredict every function return using a 'safe return'
sequence.
To ensure the safety of this mitigation, the kernel must ensure that the
safe return sequence is itself free from attacker interference. In Zen3
and Zen4, this is accomplished by creating a BTB alias between the
untraining function srso_untrain_ret_alias() and the safe return
function srso_safe_ret_alias() which results in evicting a potentially
poisoned BTB entry and using that safe one for all function returns.
In older Zen1 and Zen2, this is accomplished using a reinterpretation
technique similar to Retbleed one: srso_untrain_ret() and
srso_safe_ret().
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1b0fc0345f2852ffe54fb9ae0e12e2ee69ad6a20 upstream
These options clearly turn *off* XSAVE YMM support. Correct the
typo.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Fixes: 553a5c03e90a ("x86/speculation: Add force option to GDS mitigation")
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 553a5c03e90a6087e88f8ff878335ef0621536fb upstream
The Gather Data Sampling (GDS) vulnerability allows malicious software
to infer stale data previously stored in vector registers. This may
include sensitive data such as cryptographic keys. GDS is mitigated in
microcode, and systems with up-to-date microcode are protected by
default. However, any affected system that is running with older
microcode will still be vulnerable to GDS attacks.
Since the gather instructions used by the attacker are part of the
AVX2 and AVX512 extensions, disabling these extensions prevents gather
instructions from being executed, thereby mitigating the system from
GDS. Disabling AVX2 is sufficient, but we don't have the granularity
to do this. The XCR0[2] disables AVX, with no option to just disable
AVX2.
Add a kernel parameter gather_data_sampling=force that will enable the
microcode mitigation if available, otherwise it will disable AVX on
affected systems.
This option will be ignored if cmdline mitigations=off.
This is a *big* hammer. It is known to break buggy userspace that
uses incomplete, buggy AVX enumeration. Unfortunately, such userspace
does exist in the wild:
https://www.mail-archive.com/bug-coreutils@gnu.org/msg33046.html
[ dhansen: add some more ominous warnings about disabling AVX ]
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8974eb588283b7d44a7c91fa09fcbaf380339f3a upstream
Gather Data Sampling (GDS) is a hardware vulnerability which allows
unprivileged speculative access to data which was previously stored in
vector registers.
Intel processors that support AVX2 and AVX512 have gather instructions
that fetch non-contiguous data elements from memory. On vulnerable
hardware, when a gather instruction is transiently executed and
encounters a fault, stale data from architectural or internal vector
registers may get transiently stored to the destination vector
register allowing an attacker to infer the stale data using typical
side channel techniques like cache timing attacks.
This mitigation is different from many earlier ones for two reasons.
First, it is enabled by default and a bit must be set to *DISABLE* it.
This is the opposite of normal mitigation polarity. This means GDS can
be mitigated simply by updating microcode and leaving the new control
bit alone.
Second, GDS has a "lock" bit. This lock bit is there because the
mitigation affects the hardware security features KeyLocker and SGX.
It needs to be enabled and *STAY* enabled for these features to be
mitigated against GDS.
The mitigation is enabled in the microcode by default. Disable it by
setting gather_data_sampling=off or by disabling all mitigations with
mitigations=off. The mitigation status can be checked by reading:
/sys/devices/system/cpu/vulnerabilities/gather_data_sampling
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
This is the 5.15.124 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTLY98ACgkQONu9yGCS
# aT5o6RAAr85HEJKt1Edvq8QyZ1qF0E5E+uPsBTWaf+AcHpP1BB59/8G1poiQHmqB
# aUTzZVEOzHBjFHwNHOSzV7dfHyngAtamOBkS+khLCz2x6o5Csqoeutwlhl4sQ3Ya
# 4ng+uu8FyjQrwzJk5ixEE0VnsWGfGTslUXE2mo+7B5yjwUhIG5QxTkVPfldzfTi4
# vlHzcELJPW6xr+L+/TuBauESSNzyHloHVBbvPBYQqCjGXoymPKZXjSsOQp4ck3tZ
# Hp/9pfxA73+3AgaMNO7qFCwMQrpsvU/qb0n7mNQHlcMXyJiOOTKerhsBrePBc2TQ
# 67UYyLMy1D3pIKjkk/t2Kx5CM3yA1M7YY8mOlxuHH9EQYvgzdgN8xQlBDu7faOiT
# OGfvJLtJqAP0hepMj48rLUp7+NHfHYJyK0UGLVXInsbq5Ovm68pvMHULzizc2bx/
# H6qedzwOF40hmcgPGs97nxehn1eq63dkztY8wZ+4PKGMRh8y2cQyXOmWbn5liqkh
# Zt4gAv4MfGOcchEaUZoPDvAnlzd5KdWz7oaR6urlGZ6ZxyJplnhBwKCM9PTsNgaq
# uHSvdVrBLoB6H210O3RnRiOhFw4gLIBsK8P+b0z033eXdod+qpWb9cf4T5kLH1T6
# jiWF7CLYyANx3FFJNZJRo87TtJgmp2RUXnUHGaCyECgbNRncr7Y=
# =jkw9
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 03 Aug 2023 04:22:55 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 3c1897ae4b6bc7cc586eda2feaa2cd68325ec29c upstream.
The kernel security team does NOT assign CVEs, so document that properly
and provide the "if you want one, ask MITRE for it" response that we
give on a weekly basis in the document, so we don't have to constantly
say it to everyone who asks.
Link: https://lore.kernel.org/r/2023063022-retouch-kerosene-7e4a@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
linux-distros group
commit 4fee0915e649bd0cea56dece6d96f8f4643df33c upstream.
Because the linux-distros group forces reporters to release information
about reported bugs, and they impose arbitrary deadlines in having those
bugs fixed despite not actually being kernel developers, the kernel
security team recommends not interacting with them at all as this just
causes confusion and the early-release of reported security problems.
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/2023063020-throat-pantyhose-f110@gregkh
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit b26a124cbfa80f42bfc4e63e1d5643ca98159d66 ]
Add 'symstr' type for storing the kernel symbol as a string data
instead of the symbol address. This allows us to filter the
events by wildcard symbol name.
e.g.
# echo 'e:wqfunc workqueue.workqueue_execute_start symname=$function:symstr' >> dynamic_events
# cat events/eprobes/wqfunc/format
name: wqfunc
ID: 2110
format:
field:unsigned short common_type; offset:0; size:2; signed:0;
field:unsigned char common_flags; offset:2; size:1; signed:0;
field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
field:int common_pid; offset:4; size:4; signed:1;
field:__data_loc char[] symname; offset:8; size:4; signed:1;
print fmt: " symname=\"%s\"", __get_str(symname)
Note that there is already 'symbol' type which just change the
print format (so it still stores the symbol address in the tracing
ring buffer.) On the other hand, 'symstr' type stores the actual
"symbol+offset/size" data as a string.
Link: https://lore.kernel.org/all/166679930847.1528100.4124308529180235965.stgit@devnote3/
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Stable-dep-of: 66bcf65d6cf0 ("tracing/probes: Fix to avoid double count of the string length on the array")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
|
|
This is the 5.15.121 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmS9E3sACgkQONu9yGCS
# aT573w//WOG9AJV335EzZh9gjjxGg6nbJZZzLAbvC7XgY+ECVPfajaDAMMP7nGM5
# s2CQsbVFp22Rm73r8DVZmGJqAZzATSO1b09yUQZKcN/wWYqQYVzqqSp+vJfTY2zQ
# TcNsd2+8AFAZm2e5GBS3HFCBc+I3VqOVyuDBNvf5T+EGZNoJ8mNhVBkpnWudAPwc
# ALapsdAov0iv7Rv2pMcroSIKGk/VhERsbzEUV4xRvPH2UqmVVMASrZwWM4DKs1+t
# GuePKKloR60Tm+e6ZvVCjdXJlLcgRd4+o9RY9TCdKonsa9xuv0l3p5FwpjhdGIVc
# tw6LtiafMhQ2WWybvusMnSaNGhLJuPg2FM95PfUtarg0COflljrssz0mW+zGJpwP
# P1f5iKUFZmGQ3Is9ddrO4JoQQokgxDQ/ojhmoRv3tjnG+gMPadQi8wBuasipVt3u
# ho2Y7+U6wKfFOPIcUFS4qPMrjCvw28OdAIG6aF5vdd3SIiKejFuO/rMBCx9tHuLJ
# x6wPua6Xtmt0WSFlt8J8mcvnQOSj8gK4EIDfJlcXvNsmA0oHvOv+uEHSuxfxZaIq
# c23EPGjG+YXmPBJPmdV8WFzVaQc3xYgsg3gMVj99Zx0yTmT2viZmsJkWI/Uz/IKc
# G1HEJbuNniuyL4l4nZnNDr44UbA/i38IRy8+Ol8ATToGvDLSUvs=
# =XbDI
# -----END PGP SIGNATURE-----
# gpg: Signature made Sun 23 Jul 2023 07:48:11 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 035641b01e72af4f6c6cf22a4bdb5d7dfc4e8e8e upstream.
Just calling wait_for_device_probe() is not enough to ensure that
asynchronously probed block devices are available (E.G. mmc, usb), so
add a "dm-mod.waitfor=<device1>[,..,<deviceN>]" parameter to get
dm-init to explicitly wait for specific block devices before
initializing the tables with logic similar to the rootwait logic that
was introduced with commit cc1ed7542c8c ("init: wait for
asynchronously scanned block devices").
E.G. with dm-verity on mmc using:
dm-mod.waitfor="PARTLABEL=hash-a,PARTLABEL=root-a"
[ 0.671671] device-mapper: init: waiting for all devices to be available before creating mapped devices
[ 0.671679] device-mapper: init: waiting for device PARTLABEL=hash-a ...
[ 0.710695] mmc0: new HS200 MMC card at address 0001
[ 0.711158] mmcblk0: mmc0:0001 004GA0 3.69 GiB
[ 0.715954] mmcblk0boot0: mmc0:0001 004GA0 partition 1 2.00 MiB
[ 0.722085] mmcblk0boot1: mmc0:0001 004GA0 partition 2 2.00 MiB
[ 0.728093] mmcblk0rpmb: mmc0:0001 004GA0 partition 3 512 KiB, chardev (249:0)
[ 0.738274] mmcblk0: p1 p2 p3 p4 p5 p6 p7
[ 0.751282] device-mapper: init: waiting for device PARTLABEL=root-a ...
[ 0.751306] device-mapper: init: all devices available
[ 0.751683] device-mapper: verity: sha256 using implementation "sha256-generic"
[ 0.759344] device-mapper: ioctl: dm-0 (vroot) is ready
[ 0.766540] VFS: Mounted root (squashfs filesystem) readonly on device 254:0.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Cc: Mark-PK Tsai <mark-pk.tsai@mediatek.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b9d216fcef4298de76519e2baeed69ba482467bd upstream
Arm Neoverse-N2 and the Cortex-A710 cores are affected
by a CPU erratum where the TRBE will overwrite the trace buffer
in FILL mode. The TRBE doesn't stop (as expected in FILL mode)
when it reaches the limit and wraps to the base to continue
writing upto 3 cache lines. This will overwrite any trace that
was written previously.
Add the Neoverse-N2 erratum(#2139208) and Cortex-A710 erratum
(#2119858) to the detection logic.
This will be used by the TRBE driver in later patches to work
around the issue. The detection has been kept with the core
arm64 errata framework list to make sure :
- We don't duplicate the framework in TRBE driver
- The errata detection is advertised like the rest
of the CPU errata.
Note that the Kconfig entries are not fully active until the
TRBE driver implements the work around.
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
cc: Leo Yan <leo.yan@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20211019163153.3692640-3-suzuki.poulose@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 28eceeda130f5058074dd007d9c59d2e8bc5af2e upstream.
When a directory is moved to a different directory, some filesystems
(udf, ext4, ocfs2, f2fs, and likely gfs2, reiserfs, and others) need to
update their pointer to the parent and this must not race with other
operations on the directory. Lock the directories when they are moved.
Although not all filesystems need this locking, we perform it in
vfs_rename() because getting the lock ordering right is really difficult
and we don't want to expose these locking details to filesystems.
CC: stable@vger.kernel.org
Signed-off-by: Jan Kara <jack@suse.cz>
Message-Id: <20230601105830.13168-5-jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e910c8e3aa02dc456e2f4c32cb479523c326b534 upstream.
Commit df8fc4e934c1 ("kbuild: Enable -fstrict-flex-arrays=3") introduced a warning
for the autofs_dev_ioctl structure:
In function 'check_name',
inlined from 'validate_dev_ioctl' at fs/autofs/dev-ioctl.c:131:9,
inlined from '_autofs_dev_ioctl' at fs/autofs/dev-ioctl.c:624:8:
fs/autofs/dev-ioctl.c:33:14: error: 'strchr' reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
33 | if (!strchr(name, '/'))
| ^~~~~~~~~~~~~~~~~
In file included from include/linux/auto_dev-ioctl.h:10,
from fs/autofs/autofs_i.h:10,
from fs/autofs/dev-ioctl.c:14:
include/uapi/linux/auto_dev-ioctl.h: In function '_autofs_dev_ioctl':
include/uapi/linux/auto_dev-ioctl.h:112:14: note: source object 'path' of size 0
112 | char path[0];
| ^~~~
This is easily fixed by changing the gnu 0-length array into a c99
flexible array. Since this is a uapi structure, we have to be careful
about possible regressions but this one should be fine as they are
equivalent here. While it would break building with ancient gcc versions
that predate c99, it helps building with --std=c99 and -Wpedantic builds
in user space, as well as non-gnu compilers. This means we probably
also want it fixed in stable kernels.
Cc: stable@vger.kernel.org
Cc: Kees Cook <keescook@chromium.org>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20230523081944.581710-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit f7306acec9aae9893d15e745c8791124d42ab10a ]
Initial creation of an AF_XDP socket requires CAP_NET_RAW capability. A
privileged process might create the socket and pass it to a non-privileged
process for later use. However, that process will be able to bind the socket
to any network interface. Even though it will not be able to receive any
traffic without modification of the BPF map, the situation is not ideal.
Sockets already have a mechanism that can be used to restrict what interface
they can be attached to. That is SO_BINDTODEVICE.
To change the SO_BINDTODEVICE binding the process will need CAP_NET_RAW.
Make xsk_bind() honor the SO_BINDTODEVICE in order to allow safer workflow
when non-privileged process is using AF_XDP.
The intended workflow is following:
1. First process creates a bare socket with socket(AF_XDP, ...).
2. First process loads the XSK program to the interface.
3. First process adds the socket fd to a BPF map.
4. First process ties socket fd to a particular interface using
SO_BINDTODEVICE.
5. First process sends socket fd to a second process.
6. Second process allocates UMEM.
7. Second process binds socket to the interface with bind(...).
8. Second process sends/receives the traffic.
All the steps above are possible today if the first process is privileged
and the second one has sufficient RLIMIT_MEMLOCK and no capabilities.
However, the second process will be able to bind the socket to any interface
it wants on step 7 and send traffic from it. With the proposed change, the
second process will be able to bind the socket only to a specific interface
chosen by the first process at step 4.
Fixes: 965a99098443 ("xsk: add support for bind for Rx")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Magnus Karlsson <magnus.karlsson@intel.com>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Link: https://lore.kernel.org/bpf/20230703175329.3259672-1-i.maximets@ovn.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
|
|
This is the 5.15.118 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSTAmsACgkQONu9yGCS
# aT6MyA/9FRXd3ydG7b2o+n75Zolt/qzyz8p7YRljp7zF2py6/9NxKKKf0RtMifn0
# KDneJN9HSmkFDrFsZEX1PONHS4346lQpX33yE/6l19zsm/5PygqF7opTF2Amabkc
# 1FiQRb5EemctR902VNalYlSEHVMph0b+8pwMZzz9WjIkkQkOC2Bu+DIovmwk+wwQ
# IwBwq0Qouhp/MZAji+vcvRcvT1cKe8yWo5XEbPDCexJ8CkR3KHmXrWGzmLWKL/LB
# RDOUl71IoEEtepd8lMRMQN6WsYpun+yHE0DummXhNh/Xt8s0VRP73K15SIyIDaim
# TGZ2syUwq6/VWZRh3z5ERek4euaCp7JqYIv/+dnWoKxQvaXDLd4udSGin4AbMjd/
# vwxMsARWXM3i89tKByCryajUmYk6CUdxtf0VF4pJifq3+jbhTMb439tfzv5ja0kl
# umlappmgfc5+1keuHvONZsxMsbb0lhICbvBwXQEvRg0whNS6jMmWoFTc8mzQ1M/m
# qVDjKVWWDdmhTAnhn0MK9Z5HQ1Dnw0uwyObQM7ZHh5PK6PTf4vlY6RVU1NrhqOjK
# xHlEgYJ+GDXvooP8TLGv60K1T8p1YPi80mhYW0Gm8MytnRRlrDVTORgvyOUvlbu/
# BxxvDuOr/LiSn/cgQBC03WKxGbF4LjQsbesnt6xqIbG9aWybax4=
# =H93I
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 21 Jun 2023 10:00:11 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 1202cdd665315c525b5237e96e0bedc76d7e754f upstream.
DECnet is an obsolete network protocol that receives more attention
from kernel janitors than users. It belongs in computer protocol
history museum not in Linux kernel.
It has been "Orphaned" in kernel since 2010. The iproute2 support
for DECnet was dropped in 5.0 release. The documentation link on
Sourceforge says it is abandoned there as well.
Leave the UAPI alone to keep userspace programs compiling.
This means that there is still an empty neighbour table
for AF_DECNET.
The table of /proc/sys/net entries was updated to match
current directories and reformatted to be alphabetical.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: David Ahern <dsahern@kernel.org>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 067c098766c6af667a9002d4e33cf1f3c998abbe ]
Fix various kfree() issues related to of_overlay_apply().
- Double kfree() of fdt and tree when init_overlay_changeset()
returns an error.
- free_overlay_changeset() free the root of the unflattened
overlay (variable tree) instead of the memory that contains
the unflattened overlay.
- For the case of a failure during applying an overlay, move kfree()
of new_fdt and overlay_mem into free_overlay_changeset(), which
is called by the function that allocated them.
- For the case of removing an overlay, the kfree() of new_fdt and
overlay_mem remains in free_overlay_changeset().
- Check return value of of_fdt_unflatten_tree() for error instead
of checking the returned value of overlay_root.
- When storing pointers to allocated objects in ovcs, do so as
near to the allocation as possible instead of in deeply layered
function.
More clearly document policy related to lifetime of pointers into
overlay memory.
Double kfree()
Reported-by: Slawomir Stepien <slawomir.stepien@nokia.com>
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220420222505.928492-3-frowand.list@gmail.com
Stable-dep-of: 39affd1fdf65 ("of: overlay: Fix missing of_node_put() in error case of init_overlay_changeset()")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
|
|
This is the 5.15.116 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSC464ACgkQONu9yGCS
# aT61dQ//bgt3MdF3nEo07Stb94D+bLOwau0kcEfnoz7goLHeQI5mmqmNlCdtmQDq
# gvY/Ut6LItUXbOctCMJGAvHWt+MOzy2lACCd5qI7NyfaSkJgNNBb4xVaG/XjfeB2
# acQ3RXBGa7xOMW677jREc76Yed4pxW6/YC6/C9/jdxoWaW6dRCV4Hju3iUf/oKBo
# iz7LWd0qeOaLIZfC9OS2v+GIZWT2z2bidmJhsjGd1cPm+ip3+YftGiwuzphv/NeY
# hzfVU7Teg874JWocsHixPjyIXZA1I4/VRKkEr4xtI7ooaTulbo1ImrhDm6imdxYp
# 5KJPr39Xm5Y6piUNn72PZ1Wc906XrBIIfP2sgjaMPnqrHOi5B0imnHg1QlRN0+Qk
# Ni9EpQb9GcKlDj5OhXPZ88xntKPtU7+q7TgoUto5DH7cSxelk2BGyrHqEXLQT2YZ
# HP5NvspUjPeAPO9W1CFeTCXrUySAjJayjrd0V7+/N6ii205+aWVsU5HkJ/OFrd6L
# 22wZKk76Fni9FDx8j6wSU0NbZMIrP3/yIth2q7LzR2JPS7IvDsohBz/VLI9wUUkU
# MEKNhQSnldRvhG7hZ6XFG6n/LsnbXWXR2LNI9Vapud4QUYFmTf5cBtjSmSET7Vpd
# Sq9NxL10cVNR4qHmTkMzeNdEAVm1XgKKoot0rvMj7qQNEIoiscc=
# =WxoZ
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 09 Jun 2023 04:32:46 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
commit 7b32040f6d7f885ffc09a6df7c17992d56d2eab8 upstream.
The "snps,hsphy_interface" is string, not u8. Fix the type.
Fixes: 389d77658801 ("dt-bindings: usb: Convert DWC USB3 bindings to DT schema")
Cc: stable <stable@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20230515172456.179049-1-marex@denx.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 55720d242052e860b9fde445e302e0425722e7f1 upstream.
The conversion to json-schema accidentally dropped the "ad" part prefix
from the compatible value.
Fixes: 8c41245872e2 ("dt-bindings:iio:adc:renesas,rcar-gyroadc: txt to yaml conversion.")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/6b328a3f52657c20759f3a5bb2fe033d47644ba8.1683635404.git.geert+renesas@glider.be
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit efb2bfd7b3d210c479b9361c176d7426e5eb8663 ]
A bunch of TI's codecs have binding schemas which force #sound-dai-cells
to one despite those codecs only having a single DAI. Allow for bindings
with zero DAI cells and deprecate the former non-zero value.
Signed-off-by: Martin Povišer <povik+lin@cutebit.org
Link: https://lore.kernel.org/r/20230509153412.62847-1-povik+lin@cutebit.org
Signed-off-by: Mark Brown <broonie@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
|
|
This is the 5.15.115 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmR9jSoACgkQONu9yGCS
# aT5bYw//fGkzqiQ2xg3sAHwMsLVydYJSxARX4ab6DFU1kwzlVoBpxsYAafR3fpSF
# qrZx4YW+6vpCjCBmgqX0r+Dz9nGKCKjZPVxoNrnpBdRTbUt/PFG2gzttzL0WuoIE
# OdrWKaFCRqS83B2ECA7gvhdPc4G7E6oJbTMHncv9fvW9kvwuX60fHZp6fsmdmX2I
# HD7KMSflfTaiS8qNI81dvsNWVMlEJfhFoYf2r1g64Ff5kLUAvr/57To29cwgs/43
# Y35X3G2Ov22G93wYFnE4JYlMXOWQKvx3IpbGQ5EOgLYLl+r3Xist03Q3ms1z5vwo
# p14/foXnGYj75iRPbkSuVcmE71k7yB9AHCJHjDBf7Sc/VtSq/4CfxQjjHCGz6lc4
# a+KV8Enk5l8sJj+Kuo2jZCo2Y68XL9C1T07jTDWQtY0j1dPrhXQPpfdtBcjI5S9f
# k0KtCMR/16OZ5WzL0Cg13mKeKDMQc3hEXFlvnaJh0n425aaJAj4CYr/3vnYD0bRf
# 8tY1RvG2UuWa4xwH5ddFUnCZoc/eoOEw0ngYso6Xr/iJSK3gGr9xAaROfGI2FB87
# Vqhw9lDyJ84w9LxmDw+WXz/jPz60f0WuH2mc3NrNbN6A7/bMwBkS1Vrc3ZPMXFLS
# rK1g/u4S3O64gbfmszj9PTzX/WkIADJyedrB72Wu9fxBuyxoWx8=
# =VKCt
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 05 Jun 2023 03:22:18 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
Patrick Rohr
Ahmad Fatoum
Bruce Ashfield
Yicong Yang
Krzysztof Kozlowski
Bart Van Assche
Mario Limonciello
Peter Zijlstra
Robin Murphy
Suzuki K Poulose
Borislav Petkov (AMD)
Dave Hansen
Daniel Sneddon
Greg Kroah-Hartman
Masami Hiramatsu (Google)
Peter Korsgaard
Jan Kara
Arnd Bergmann
Ilya Maximets
Stephen Hemminger
Frank Rowand
Marek Vasut
Geert Uytterhoeven
Martin Povišer