Make CIG auto-allocation to select the first CIG_ID that is still
configurable. Also use correct CIG_ID range (see Core v5.3 Vol 4 Part E
Sec 7.8.97 p.2553).
Previously, it would always select CIG_ID 0 regardless of anything,
because cis_list with data.cis == 0xff (BT_ISO_QOS_CIS_UNSET) would not
count any CIS. Since we are not adding CIS here, use find_cis instead.
Fixes: 26afbd826e ("Bluetooth: Add initial implementation of CIS connections")
Signed-off-by: Pauli Virtanen <pav@iki.fi>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
When looking for CIS blocking CIG removal, consider only the CIS with
the right CIG ID. Don't try to remove CIG with unset CIG ID.
Fixes: 26afbd826e ("Bluetooth: Add initial implementation of CIS connections")
Signed-off-by: Pauli Virtanen <pav@iki.fi>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The existing documentation refers to memory.high as the "main mechanism
to control memory usage." This seems incorrect to me - memory.high can
result in reclaim pressure which simply leads to stalls unless some
external component observes and actions on it (e.g. systemd-oomd can be
used for this purpose). While this is feasible, users are unaware of
this interaction and are led to believe that memory.high alone is an
effective mechanism for limiting memory.
The documentation should recommend the use of memory.max as the
effective way to enforce memory limits - it triggers reclaim and results
in OOM kills by itself.
Signed-off-by: Dan Schatzberg <schatzberg.dan@gmail.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Tejun Heo <tj@kernel.org>
Andrii Nakryiko writes:
And we currently don't have an attach type for NETLINK BPF link.
Thankfully it's not too late to add it. I see that link_create() in
kernel/bpf/syscall.c just bypasses attach_type check. We shouldn't
have done that. Instead we need to add BPF_NETLINK attach type to enum
bpf_attach_type. And wire all that properly throughout the kernel and
libbpf itself.
This adds BPF_NETFILTER and uses it. This breaks uabi but this
wasn't in any non-rc release yet, so it should be fine.
v2: check link_attack prog type in link_create too
Fixes: 84601d6ee6 ("bpf: add bpf_link support for BPF_NETFILTER programs")
Suggested-by: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/CAEf4BzZ69YgrQW7DHCJUT_X+GqMq_ZQQPBwopaJJVGFD5=d5Vg@mail.gmail.com/
Link: https://lore.kernel.org/bpf/20230605131445.32016-1-fw@strlen.de
It seems we forgot the normal case to terminate the retry loop,
making us asking 3 times each command, which is probably a little bit
too much.
And remove the ugly "goto exit" that can be replaced by a simpler "break"
Fixes: 586e8fede7 ("HID: logitech-hidpp: Retry commands when device is busy")
Suggested-by: Mark Lord <mlord@pobox.com>
Tested-by: Mark Lord <mlord@pobox.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Several device tree files get the polarity of the pendown-gpios
wrong: this signal is active low. Fix up all incorrect flags, so
that operating systems can rely on the flag being correctly set.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20230510105156.1134320-1-linus.walleij@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
It contains:
- fix imbalanced reference counter for ethernet devices; without it
system hangs after consecutive suspend/resume cycles;
- fix debounce delay property for shutdown controller; the initial DT
property is not what the driver expects.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTsZ8eserC1pmhwqDmejrg/N2X7/QUCZHXQCQAKCRCejrg/N2X7
/USYAP0ZZsxsFtaxYEj+ZpkOOM5QjUKmxRBF5EKpvT6Y18x1yAD/em5J/Qwe7k+T
QxnajMvdb91RwupjZp9kGSJjU9BJfAg=
=kXQQ
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmR+AYsACgkQYKtH/8kJ
Uid8ug/+M395NCIOKaOuWeRcJKW5yk6wWCxQiL57zB+2aKEQR8p55bBsRQNuMD0i
lOFirJk5oAOh5Vv6Pe3Xu1b8WpKCf/td6UuWj0CM2T6WFrZbLYqJIg7wwqS+p7Oj
4FjkTmIReKSDLcnhruLL8sbeuFwXwIj33xQLBOoRPVcFcxo74+MKIfHW9pxnDyoK
wwXNORvhQjNpvwwb6gsr4pgcOEbGGOte7VjQ5EEI8Ov92RRxnwRr/T6qoUbn2Fv8
Nu05FtZ3du66cGEW/Ma6UkttSwCAax6DoOycPoSAbQcxFkiUFMI+zfDlVnhyyYvt
bmeEgbZqEXp5Db2Ic89gGaWnqAeS6mXwY9WG4kmQoRxRanDfd9eT2n3/KO6EyF5P
gevbL5XnqRHH7B2VkSJOVQUoLvrv931Vg8qIY6gsuWIYTsrA1u+VZ5/LygFLUR2I
dlf35dSgF18naFXk1DMu4bdXJ2HtmbjnrUgGIbXPYG/zxBajMdrC6O5OVWO9lWmK
/EmPU12JhjpPQNrPiJulADx18QinEuAmmbAEtuJoK2of6+MQlWTwmDOx4kmorYeT
hzW0jj6q/wE3VmNgO7kZ3SitIa7zYLb5QUAKJaj72rtRFjKevSOi3RtpK8+5Cs/O
Tbv4UpkQ5elxT6eh3GN+M0oEIn6ERgvcJ6zUmV6zLVESVykrvas=
=s5VF
-----END PGP SIGNATURE-----
Merge tag 'at91-fixes-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/fixes
AT91 fixes for 6.4
It contains:
- fix imbalanced reference counter for ethernet devices; without it
system hangs after consecutive suspend/resume cycles;
- fix debounce delay property for shutdown controller; the initial DT
property is not what the driver expects.
* tag 'at91-fixes-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
ARM: dts: at91: sama7g5ek: fix debounce delay property for shdwc
ARM: at91: pm: fix imbalanced reference counter for ethernet devices
Link: https://lore.kernel.org/r/20230530105930.11621-1-claudiu.beznea@microchip.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Register scheme for SM8550 LLCC is corrected to avoid using the wrong
register offsets. SDRAM frequency for misidentified SC7180-lite boards
is handled. The datatype for Soundwire interval on SM8550 is corrected.
The resource controller on SC8280XP is added to the CPU cluster
power-domain to get notified to send cached sleep and wake votes before
going entering the lower power states.
SA8155P power-domains that differ from what's inherited from the SM8150
DeviceTree are adjusted to make the platform boot again.
Remoteproc firmware paths are corrected for Sony Xperia 10 IV.
Cache properties are adjusted across a range of platforms, to meet
changes in the binding.
Panel compatibles are corrected for Xiaomi Mi Pad 5 Pro, to match
binding. Invalid dai-cells are dropped from SC7280 devices, to match
binding.
The incorrect removal of "input-enable" from the LPASS pinctrl node of
SC8280XP was reverted, to get dmic pins in the correct state again.
The incorrect input-enable property is dropped from a msm8974, mdm9615
and apq8026 to resolve a range of DT validation warnings, incorrectly
picked up through the ARM64 tree.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmR4qgcVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3Fwl0QAMJQ1TIS+mo2ywDn9F1jWPSt49gg
6d0oaWgZV9QDOVISEPUecLV1ZlnequdWWrGL1bTungJVnqOdbFVhNU6pLtBoJ68X
TMlPR9FHbLyaogxxo4x3mPBl9N+O001cXT/U9k8O72mouD4986K++JBAbfTjkk3B
4aKW/W4JyQUtJZsrDI5m7VItwcf9EqBO1Ocp2bdgSoVInAOmXdLKiff+hNatDZdH
HEAav5g6bqDr2DPJBKABSH3rN/yEsElh4Zyofpbb0byW7oMTzreZPSwVqwpPWuTJ
Ke2R8C/ASZp+/xZJQvZw3W5VDQXrqSDMUvp5sJnBRYLnT17OQlrYwM5KjiZ/vUax
9Mk26mg7E51sHwjDjBzbS1rEVIPVnMxmWcokBzLjl5eQMkoaRAgPzDFEyTkkXMUG
W2V+vEGtK4INEow5pyKWNpOg/62B9CnBt5E+xlm1Dpi4s/EgmqYxqFKV+nWsuJwl
7P4X0RUhTY4+PEOjgqDuNvlxX5wIqg12DvdDpsIZaak0p6kTLvyazcFENio01gXF
tcbfcePNbv6zp/ll4xgP1Hm3mjB/wlSzVufVSi0VqVOLMzkFS8LMeTM3EINvhbwD
POKjOQi8Gq8Or9vWR5fEyC0nNW5jA60WMGfFtRtiul8FrCw6V1k+bweMIA5UTy2t
+Rc45Ff/YTRqY1qx
=62ow
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmR+ATkACgkQYKtH/8kJ
Uie1ww/+LgWQXR9AsifntyJZJEDgxEIIc7LqvNu7FxLmi/RdJ7pfKZvRsfSCQsDp
YAYIqtUbgb5ih1Ifz3XTzlSqCFqrTnKM9M6aJaKctQulC4UbaYAEQHFk54wlB6u8
isv0bXZYOn45AWOpd5zvuNcYZ8g+HOcmdWpQ+KE10yV4uqMBOMD75AIqH6ZbnRX/
j1r5Wlf3YZYa7kCqtYDPW/zGIlE7EnNrAnkehqcEN2KVtaaavWT//2Ess63FGnk5
rHLDqRzb3ivDdlsUCA2hvytXkHY/MBDJmGlJZStdpy1hzGGtfs77FkNt00diKe8q
p91mw3IhUufFthJN9gwr5j3KuEO0thAmXKGI07pOAVRakIL/C0jIkaaSe4JuNdkZ
gxl6MBY6bnMPUzpTcR/cZDvRPXr4dnV2OEUJEz0EH5Zz6SIV1bBLQp+WEgU6+Wzx
xho6/cymh3GSsoPoBb8wMqJ0yOrJgYiw8NBcXoKSgKDrEXRpQ7CSMtBO+ALkmqnT
hheC2TKuIZqMmainAS6Gz11XJZkWQsq7Nz20L3k6NHAYsddK7EMfn8CBfyORbs5G
qy14bpPpPW33ijAzfQxV4zLQP3xoZT1f1ThZTEC8NpJ80WpasylgkZu2FJfiH5XU
WnljQsUUKZovnGjreuX8NsUTQZ3mrGTtg9S33XdyNYYdEye+afI=
=TSqN
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-fixes-for-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm ARM64 DeviceTree fixes for 6.4
Register scheme for SM8550 LLCC is corrected to avoid using the wrong
register offsets. SDRAM frequency for misidentified SC7180-lite boards
is handled. The datatype for Soundwire interval on SM8550 is corrected.
The resource controller on SC8280XP is added to the CPU cluster
power-domain to get notified to send cached sleep and wake votes before
going entering the lower power states.
SA8155P power-domains that differ from what's inherited from the SM8150
DeviceTree are adjusted to make the platform boot again.
Remoteproc firmware paths are corrected for Sony Xperia 10 IV.
Cache properties are adjusted across a range of platforms, to meet
changes in the binding.
Panel compatibles are corrected for Xiaomi Mi Pad 5 Pro, to match
binding. Invalid dai-cells are dropped from SC7280 devices, to match
binding.
The incorrect removal of "input-enable" from the LPASS pinctrl node of
SC8280XP was reverted, to get dmic pins in the correct state again.
The incorrect input-enable property is dropped from a msm8974, mdm9615
and apq8026 to resolve a range of DT validation warnings, incorrectly
picked up through the ARM64 tree.
* tag 'qcom-arm64-fixes-for-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: sm8550: Use the correct LLCC register scheme
arm64: dts: qcom: sc7180-lite: Fix SDRAM freq for misidentified sc7180-lite boards
arm64: dts: qcom: sm8550: use uint16 for Soundwire interval
arm64: dts: qcom: Split out SA8155P and use correct RPMh power domains
arm64: dts: qcom: sm6375-pdx225: Fix remoteproc firmware paths
arm64: dts: qcom: add missing cache properties
arm64: dts: qcom: use decimal for cache level
arm64: dts: qcom: fix indentation
ARM: dts: qcom: msm8974: remove superfluous "input-enable"
ARM: dts: qcom: mdm9615: remove superfluous "input-enable"
ARM: dts: qcom: apq8026: remove superfluous "input-enable"
arm64: dts: qcom: sm8250-xiaomi-elish-csot: fix panel compatible
arm64: dts: qcom: sm8250-xiaomi-elish-boe: fix panel compatible
arm64: dts: qcom: sc7280-qcard: drop incorrect dai-cells from WCD938x SDW
arm64: dts: qcom: sc7280-idp: drop incorrect dai-cells from WCD938x SDW
arm64: dts: qcom: sc8280xp: Flush RSC sleep & wake votes
arm64: dts: qcom: sc8280xp: Revert "arm64: dts: qcom: sc8280xp: remove superfluous "input-enable""
Link: https://lore.kernel.org/r/20230601142659.2246348-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Error paths is corrected across icc-bwmon, rpmh-rsc, ramp_controller and
rmtfs. The ice module is renamed qcom_ice, to avoid clashing with
existing "ice" driver.
SA8155P-specific RPMh power-domains are introduced to avoid the code
trying to access resources that exists on SM8150, but not on SA8155P.
Lastly, changes to the EDAC driver to fix an issue where the driver
performs mmio based on the wrong register map.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmR4pqAVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3F7vIP/008Kr7YqlJb5dyms/eMfwy+GFFI
LhLlpEB5bjGkEN9RD0J+8Nx4FnJeWZgugitIPqvbUtwlH80xhqtoezBk4LNu7+o1
Ulq1A8wU7jXAQ7KptKemkoGMmaxLffLhU8MG0r7Rd8t/MtPrPdRwn8KiFPRvbeX4
JRegPpYn4fb+Yx4IqKesbTjSiPf46N8j+hjlwtiCm/6CHfr9DJpoLfQoWiHXHMW6
b4I9Ui6sZp+SK8sXMGTFQmzngVXND9/4NPUlCxOeFxluV/wsfLAunwdLzqp28YOj
GnlWOcyOKGwDv/h0YxUex4Gipxq+mFiDYGxhJl2TZonZHEUKyFAPdgQ/v98kH0Eq
i/m5DSmXaTJh/R2tqHA+wWdWGjWMlcgTyNWfShqiHdlrLe4RTsQ7WIc47QYVggMz
7B9f2NKubQFvbAY5rBQ8VyNb/3qMwYQpl7bMLv9V48F+80xHrnb9Sh7WpkERbIXL
4bR6Vs1144XcCnFdwiaqCL62rMXxmIuQVQJhOmMHtSwvokIF8UMAbIYhVxEyIW6p
z3elXQjIh+aNafViHdcuOVzjo/9Pbl6Bv99wO+CS3LM5hosFAZa/XCGmBx6ZK04e
sEOg97cM1QXwzOEzyn7R5CbYpIC0N8Gasvgo6qVqq8iNrgf2JaDoQtlc76PegqBI
z43DNpZC4k7L+0uk
=icu7
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmR+AMAACgkQYKtH/8kJ
UidzSA//bsg1vu0o8HgbJaTj175jSVh/FqJhIVjK5FrCVJCAS8brAmaPg35qN9Fs
8HyZVjEfx0P2Xg7FITIYIKajW8FtMTM0bVeb0P6LMa7DmYT5emm6CS5iOjFNBsZN
zau26lEKzTefmXUqbxQb9urzlpsil7RfhzJ+LYCfpODWt9/cPDCoTVV1vFj6M7Mr
Rp0ZvhZHeH/tBRFjXcQZYpsdxJFYTkgAf4weOqr2mqgK/HyXhm4bZQMKyRQgEozD
LODl1UfhQ7bOnA3PhLsJ2+BlOeUCOizx7PRuPpSnmKo5qzyUs6M4m6BCXDLBQ4N5
ynDrLSdxgcRWvLiFkri2zdW545MmryKGGP9l4Vus52kAEmhFaHg3hQC97l73NMV4
XZSVPHd64I18FpW4hHH2vRtVvU4Yeu+FRduQs7ghHg5wUKGlSMZLZdrTrxjvmKYq
8R8E/gcCeqOywQgOfisvSc30iDPwxohs2iaHD2J8W9NduafVmDlQjvH6dx1nK1YW
CwIfPO/87eOoGkZlrkL8nacqMiQC5YTg9vUpkOxVmyrFTz/hqZI8V04OXc2kBvZk
Af6nAFjVIaX/hKukSKJLpu9sg8WU6Nc/4UeHCUHKsUdCxtC+p3FabG8DMw6wSbFz
3p8q1LEUW7TXazrqGhFV43q+zz/z585NwYNr+FW/7RwdgCu+3rE=
=qhFg
-----END PGP SIGNATURE-----
Merge tag 'qcom-driver-fixes-for-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm driver fixes for 6.4
Error paths is corrected across icc-bwmon, rpmh-rsc, ramp_controller and
rmtfs. The ice module is renamed qcom_ice, to avoid clashing with
existing "ice" driver.
SA8155P-specific RPMh power-domains are introduced to avoid the code
trying to access resources that exists on SM8150, but not on SA8155P.
Lastly, changes to the EDAC driver to fix an issue where the driver
performs mmio based on the wrong register map.
* tag 'qcom-driver-fixes-for-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
EDAC/qcom: Get rid of hardcoded register offsets
EDAC/qcom: Remove superfluous return variable assignment in qcom_llcc_core_setup()
dt-bindings: cache: qcom,llcc: Fix SM8550 description
soc: qcom: rpmhpd: Add SA8155P power domains
dt-bindings: power: qcom,rpmpd: Add SA8155P
soc: qcom: Rename ice to qcom_ice to avoid module name conflict
soc: qcom: rmtfs: Fix error code in probe()
soc: qcom: ramp_controller: Fix an error handling path in qcom_ramp_controller_probe()
soc: qcom: rpmh-rsc: drop redundant unsigned >=0 comparision
soc: qcom: icc-bwmon: fix incorrect error code passed to dev_err_probe()
Link: https://lore.kernel.org/r/20230601141058.2246039-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
A range of 32-bit Qualcomm platforms are missing cache-unified, which is
now required by the binding, this is now corrected.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmR4pNAVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3Fqk4QALnQZum00qSONsODppP+bE1zyyp2
JIL9P0CdUGb1asvIdUE9NDtdss0GXZe4AyDo8h8G00jC0e6kzf4WaIdYBm33Zd55
lX80o2o5NljG0xO6Nme2SoCreWFJvflm2upw2Tx7OR2txMYUcMgsvOCGOGudmJHB
dzWhTXaX9O/YSp0DZqqz+xuJ7e9qzFCbZzzO7uO+qQaDMm6cuAhkacCOoa37Xi9n
tg4nQqdCWcxYOjsKzGouLGs6svtjazofAMNNJLXhJ1l4xomGS+QfpFVMAvQZfu5M
2khtAtfq+s8lywWRyCnZswrdlUvffeZA7naRZsX88YQ2NlUukR92kUtgEN0IYrqn
kafgUfwa7T4wnM6MLKugtKF+l8fgxU9aWGa7gLwYBN9VZEa4BuNuym9hMrE5UoGX
XHCoKVgYqe6QbQ8/q1T1WhXDG8fjFC59hEDHQZi22IMCsY8zjPqukh3nyEjaWyrG
Xyt3RNetaULFUpJ6oat7mVBe8TiFtIt+NdP2Z/yDtG8kSYSqxXtYnncEEjROgx8c
gp+0be+RI2wHGU1FAk5huU2H0n4KeM7IUKSdtL3JxOoNdoLSyTjh8CrqdhEzVQ1g
4EIuMgxZ0W1kRiwRtrO8JvzpXaUcn9IjMPXHvgmrTMyzYpN/RB//dxCaQHohM6zy
U4SzSm3egcp+pQzE
=Qnr3
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmR+AJ8ACgkQYKtH/8kJ
UifUrxAApX6UgjIaq7C5SLXNc5RHCgAfreaxmHUrRBgszgL+XsIqqK79rGl+RA9f
qjo8rUSISjAiYragW/Sn7fP8ov2V0mhzBrSAXzBEP2vFwK2JhtCFl+TSxfCm+Wau
f3iw2Qf5RNSbj6iOXuUjs1welMewuCw9M14/Gucx4rJ1tiCcAMRxNKUZs/1YVhEK
cGNpYuub6vYnmm55aj5zUiW8oxwRbE/LcOCLJRAaggss+4vG1vKIcH8oIYzl5ed8
EugwVAq/xkS8QbVGd5SX2TyQIdsNQCfgnNkkVPTBqCmiLYuK7OviwxO+a7boKJsV
cCSiBGDscfeRis4+AYY9DRa9L/1otxGBfXUjz0yjktiDnZIBCc1Ul/pYtxSvJ9e1
b0H/4g7YSr7xXVt8jF5LSPt7OzAEDqCt6H+0zM4KTEbigybaALkfcwalA3OJ+YVl
eCtQU+BXGoo0o4Lj+O3auQRa52VtkTGrXiUhPIX6D6M/GBKGUbor7OlCsvOjc1gH
Sa6F/yfCkc9GXtRuy9VNyK7ETLAWaM0vcB0jJiGk4K1UmtQQlWWw4dHhoBLNsNF2
pJebjwWolMS6cgDPmXgGeCfomT0n9upRV9x4HdvL/w2mcwM1I4d+pH8TwAF9kQ8U
zspYHv6TZ5V6/92wLP5Y3kHtYehNUhYMiqQ7znQBdGa0lDA+wuw=
=OeZW
-----END PGP SIGNATURE-----
Merge tag 'qcom-dts-fixes-for-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes
Qualcomm ARM32 fix for 6.4
A range of 32-bit Qualcomm platforms are missing cache-unified, which is
now required by the binding, this is now corrected.
* tag 'qcom-dts-fixes-for-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
ARM: dts: qcom: add missing cache properties
Link: https://lore.kernel.org/r/20230601140347.2245680-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Here is a small fix to make an unconditional copy of the buffer passed
to crypto operations, to take into account the case of the stack not in
the linear mapping area.
It has been tested and verified to fix the bug.
Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEET37nTLf1dvVbFDawFAq+TsLIwHwFAmR5+m0ACgkQFAq+TsLI
wHxEfQv+MJgxUJQT4PLVWjhI2Qi/ARmCaLf7MvJwJz7tjiw+Ph/L1rFDozMpWJD/
aKL0Mo4vEY1m6ibLk694ordpdESBvsY/O2YPmZ1NeGepN0m13R9gRHJ6K/PHAgDP
ZkNf98QWY+oE5OcTrfeWmRQTR54Us46Gajmh9jAnzA5kODeDDyIImIPn3ihfcY9L
m/PdgP9EhPerVSG6mWqIeJQL+5fuLHixeu0wcdS+11AB9nCARv0Gheo81lQc/W7d
NAa4KxHOv9IsOkCTNRX/CsKfGmHKQjy8TMAmcEwoMlxjCHHxwUEb7tHM92IOjVNY
EWLlbeCZfzlFQp8RkYGUGmYrial/O7vQyg22UpLNXZsHsf/38L8NyqPRDY7XYM52
oXrMZMTNHd0I6X9sp71V592G983JVqd62VYNpNQxScD35aqSuhreFOM8p0EVsoYD
b5npXM0MWwbEZ4T+AHFhNObhp0R+ytZnpC1RTI0gajfdMRP4ZhGfv37ZErNI4yW+
pzyhHUyJ
=DveW
-----END PGP SIGNATURE-----
Merge tag 'asym-keys-fix-for-linus-v6.4-rc5' of https://github.com/robertosassu/linux
Pull asymmetric keys fix from Roberto Sassu:
"Here is a small fix to make an unconditional copy of the buffer passed
to crypto operations, to take into account the case of the stack not
in the linear mapping area.
It has been tested and verified to fix the bug"
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: David Howells <dhowells@redhat.com>
* tag 'asym-keys-fix-for-linus-v6.4-rc5' of https://github.com/robertosassu/linux:
KEYS: asymmetric: Copy sig and digest in public_key_verify_signature()
Mat Martineau says:
====================
mptcp: Fixes for address advertisement
Patches 1 and 2 allow address advertisements to be removed without
affecting current connected subflows, and updates associated self tests.
Patches 3 and 4 correctly track (and allow removal of) addresses that
were implicitly announced as part of subflow creation. Also updates
associated self tests.
Patch 5 makes subflow and address announcement counters work consistently
between the userspace and in-kernel path managers.
====================
Signed-off-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Increase pm subflows counter on both server side and client side when
userspace pm creates a new subflow, and decrease the counter when it
closes a subflow.
Increase add_addr_signaled counter in mptcp_nl_cmd_announce() when the
address is announced by userspace PM.
This modification is similar to how the in-kernel PM is updating the
counter: when additional subflows are created/removed.
Fixes: 9ab4807c84 ("mptcp: netlink: Add MPTCP_PM_CMD_ANNOUNCE")
Fixes: 702c2f646d ("mptcp: netlink: allow userspace-driven subflow establishment")
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/329
Cc: stable@vger.kernel.org
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
To align with what is done by the in-kernel PM, update userspace pm
subflow selftests, by sending the a remove_addrs command together
before the remove_subflows command. This will get a RM_ADDR in
chk_rm_nr().
Fixes: d9a4594eda ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
Fixes: 5e986ec468 ("selftests: mptcp: userspace pm subflow tests")
Link: https://github.com/multipath-tcp/mptcp_net-next/issues/379
Cc: stable@vger.kernel.org
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add the address into userspace_pm_local_addr_list when the subflow is
created. Make sure it can be found in mptcp_nl_cmd_remove(). And delete
it in the new helper mptcp_userspace_pm_delete_local_addr().
By doing this, the "REMOVE" command also works with subflows that have
been created via the "SUB_CREATE" command instead of restricting to
the addresses that have been announced via the "ANNOUNCE" command.
Fixes: d9a4594eda ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
Link: https://github.com/multipath-tcp/mptcp_net-next/issues/379
Cc: stable@vger.kernel.org
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch is linked to the previous commit ("mptcp: only send RM_ADDR in
nl_cmd_remove").
To align with what is done by the in-kernel PM, update userspace pm addr
selftests, by sending a remove_subflows command together after the
remove_addrs command.
Fixes: d9a4594eda ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
Fixes: 97040cf980 ("selftests: mptcp: userspace pm address tests")
Cc: stable@vger.kernel.org
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The specifications from [1] about the "REMOVE" command say:
Announce that an address has been lost to the peer
It was then only supposed to send a RM_ADDR and not trying to delete
associated subflows.
A new helper mptcp_pm_remove_addrs() is then introduced to do just
that, compared to mptcp_pm_remove_addrs_and_subflows() also removing
subflows.
To delete a subflow, the userspace daemon can use the "SUB_DESTROY"
command, see mptcp_nl_cmd_sf_destroy().
Fixes: d9a4594eda ("mptcp: netlink: Add MPTCP_PM_CMD_REMOVE")
Link: https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.96/include/uapi/linux/mptcp.h [1]
Cc: stable@vger.kernel.org
Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
According to Bspec, the voltage level for 480MHz is to be set as 1
instead of 2.
BSpec: 49208
Fixes: 06f1b06dc5 ("drm/i915/display: Add 480 MHz CDCLK steps for RPL-U")
v2: rebase
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230529060747.3972259-1-chaitanya.kumar.borah@intel.com
(cherry picked from commit 5a3c46b809)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
kernel_context() returns an error pointer. Use pointer-error
conversion functions to evaluate its return value, rather than
checking for a '0' return.
Fixes: eb5c10cbbc ("drm/i915: Remove I915_USER_PRIORITY_SHIFT")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v5.13+
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230526124138.2006110-1-andi.shyti@linux.intel.com
(cherry picked from commit edad9ee94f)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
We must not assign plat_dat->dwmac4_addrs unconditionally as for
structures which don't set them, this will result in the core driver
using zeroes everywhere and breaking the driver for older HW. On EMAC < 2
the address should remain NULL.
Fixes: b68376191c ("net: stmmac: dwmac-qcom-ethqos: Add EMAC3 support")
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
There seems to be a bug within the mv64xxx I2C controller, wherein the
status register may not necessarily contain valid value immediately
after the IFLG flag is set in the control register.
My theory is that the controller:
- first sets the IFLG in control register
- then updates the status register
- then raises an interrupt
This may sometime cause weird bugs when in atomic mode, since in this
mode we do not wait for an interrupt, but instead we poll the control
register for IFLG and read status register immediately after.
I encountered -ENXIO from mv64xxx_i2c_fsm() due to this issue when using
this driver in atomic mode.
Note that I've only seen this issue on Armada 385, I don't know whether
other SOCs with this controller are also affected. Also note that this
fix has been in U-Boot for over 4 years [1] without anybody complaining,
so it should not cause regressions.
[1] https://source.denx.de/u-boot/u-boot/-/commit/d50e29662f78
Fixes: 544a8d75f3 ("i2c: mv64xxx: Add atomic_xfer method to driver")
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEDs2BvajyNKlf9TJQvlAcSiqKBOgFAmR9gUwTHG1rbEBwZW5n
dXRyb25peC5kZQAKCRC+UBxKKooE6HnqB/9KHVOrMGHHHDPWXrWp+vP80lzfgw+d
4hIe9CgT6bgPcBCxqGN6domJH3XQv0Uvyr/zfKrFjAD2J0I+HLMEy3K8LnX+gcBv
xaUEGs5sBZEd5n5TgPrgYCf+LDud/bUaomNf4zJ4zq6h4exJ5cSH4G0eR9S33kUF
K3wLfBKuZifspYd/525ODe1RKYDFQy5bbvKqg4ng3ux+4MaR/w1Q+tDXXJIYgPG4
cuTG9vWp+Ves1EbzwvCq2t4/7wdMFdtMK4LTxj+VN3Dhfe6hZhA2SF9HgXcX3vLD
CKFFt0xUUyWhAN5qcGK2+fLQhzf3zmGln6pVJoDEhOQVpXwFnL2Z6tgc
=/vPI
-----END PGP SIGNATURE-----
Merge tag 'linux-can-fixes-for-6.4-20230605' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
this is a pull request of 3 patches for net/master.
All 3 patches target the j1939 stack.
The 1st patch is by Oleksij Rempel and fixes the error queue handling
for (E)TP sessions that run into timeouts.
The last 2 patches are by Fedor Pchelkin and fix a potential
use-after-free in j1939_netdev_start() if j1939_can_rx_register()
fails.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
With IC_INTR_RX_FULL slave interrupt handler reads data in a loop until
RX FIFO is empty. When testing with the slave-eeprom, each transaction
has 2 bytes for address/index and 1 byte for value, the address byte
can be written as data byte due to dropping STOP condition.
In the test below, the master continuously writes to the slave, first 2
bytes are index, 3rd byte is value and follow by a STOP condition.
i2c_write: i2c-3 #0 a=04b f=0000 l=3 [00-D1-D1]
i2c_write: i2c-3 #0 a=04b f=0000 l=3 [00-D2-D2]
i2c_write: i2c-3 #0 a=04b f=0000 l=3 [00-D3-D3]
Upon receiving STOP condition slave eeprom would reset `idx_write_cnt` so
next 2 bytes can be treated as buffer index for upcoming transaction.
Supposedly the slave eeprom buffer would be written as
EEPROM[0x00D1] = 0xD1
EEPROM[0x00D2] = 0xD2
EEPROM[0x00D3] = 0xD3
When CPU load is high the slave irq handler may not read fast enough,
the interrupt status can be seen as 0x204 with both DW_IC_INTR_STOP_DET
(0x200) and DW_IC_INTR_RX_FULL (0x4) bits. The slave device may see
the transactions below.
0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4
0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4
0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4
0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1794 : INTR_STAT=0x204
0x1 STATUS SLAVE_ACTIVITY=0x0 : RAW_INTR_STAT=0x1790 : INTR_STAT=0x200
0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4
0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4
0x1 STATUS SLAVE_ACTIVITY=0x1 : RAW_INTR_STAT=0x1594 : INTR_STAT=0x4
After `D1` is received, read loop continues to read `00` which is the
first bype of next index. Since STOP condition is ignored by the loop,
eeprom buffer index increased to `D2` and `00` is written as value.
So the slave eeprom buffer becomes
EEPROM[0x00D1] = 0xD1
EEPROM[0x00D2] = 0x00
EEPROM[0x00D3] = 0xD3
The fix is to use `FIRST_DATA_BYTE` (bit 11) in `IC_DATA_CMD` to split
the transactions. The first index byte in this case would have bit 11
set. Check this indication to inject I2C_SLAVE_WRITE_REQUESTED event
which will reset `idx_write_cnt` in slave eeprom.
Signed-off-by: David Zheng <david.zheng@intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Rather than casting pci1xxxx_i2c_shutdown to an incompatible function type,
update the type to match that expected by __devm_add_action.
Reported by clang-16 with W-1:
.../i2c-mchp-pci1xxxx.c:1159:29: error: cast from 'void (*)(struct pci1xxxx_i2c *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict]
ret = devm_add_action(dev, (void (*)(void *))pci1xxxx_i2c_shutdown, i2c);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/device.h:251:29: note: expanded from macro 'devm_add_action'
__devm_add_action(release, action, data, #action)
^~~~~~
No functional change intended.
Compile tested only.
Signed-off-by: Simon Horman <horms@kernel.org>
Reviewed-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
Reviewed-by: Tharun Kumar P<tharunkumar.pasumarthi@microchip.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
I will help Wolfram out with the i2c controllers patches.
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Headset microphone on this platform does not work without
ALC897_FIXUP_HEADSET_MIC_PIN fixup.
Signed-off-by: RenHai <kean0048@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230602003604.975892-1-kean0048@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
GCC 11.3.0 issues warnings in this module about wrong sizes of format
specifiers:
pcm-test.c: In function ‘test_pcm_time’:
pcm-test.c:384:68: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 \
has type ‘unsigned int’ [-Wformat=]
384 | snprintf(msg, sizeof(msg), "rate mismatch %ld != %ld", rate, rrate);
pcm-test.c:455:53: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has \
type ‘long int’ [-Wformat=]
455 | "expected %d, wrote %li", rate, frames);
pcm-test.c:462:53: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has \
type ‘long int’ [-Wformat=]
462 | "expected %d, wrote %li", rate, frames);
pcm-test.c:467:53: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has \
type ‘long int’ [-Wformat=]
467 | "expected %d, wrote %li", rate, frames);
Simple fix according to compiler's suggestion removed the warnings.
Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230524191528.13203-1-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fedor Pchelkin <pchelkin@ispras.ru> says:
The patch series fixes a possible racy use-after-free scenario
described in 2/2: if j1939_can_rx_register() fails then the concurrent
thread may have already read the invalid priv structure.
The 1/2 makes j1939_netdev_lock a mutex so that access to
j1939_can_rx_register() can be serialized without changing GFP_KERNEL
to GFP_ATOMIC inside can_rx_register(). This seems to be safe.
Note that the patch series has been tested only via Syzkaller and not
with a real device.
Link: https://lore.kernel.org/r/20230526171910.227615-1-pchelkin@ispras.ru
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
It turns out access to j1939_can_rx_register() needs to be serialized,
otherwise j1939_priv can be corrupted when parallel threads call
j1939_netdev_start() and j1939_can_rx_register() fails. This issue is
thoroughly covered in other commit which serializes access to
j1939_can_rx_register().
Change j1939_netdev_lock type to mutex so that we do not need to remove
GFP_KERNEL from can_rx_register().
j1939_netdev_lock seems to be used in normal contexts where mutex usage
is not prohibited.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Fixes: 9d71dd0c70 ("can: add support of SAE J1939 protocol")
Suggested-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru>
Tested-by: Oleksij Rempel <o.rempel@pengutronix.de>
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20230526171910.227615-2-pchelkin@ispras.ru
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This patch addresses an issue within the j1939_sk_send_loop_abort()
function in the j1939/socket.c file, specifically in the context of
Transport Protocol (TP) sessions.
Without this patch, when a TP session is initiated and a Clear To Send
(CTS) frame is received from the remote side requesting one data packet,
the kernel dispatches the first Data Transport (DT) frame and then waits
for the next CTS. If the remote side doesn't respond with another CTS,
the kernel aborts due to a timeout. This leads to the user-space
receiving an EPOLLERR on the socket, and the socket becomes active.
However, when trying to read the error queue from the socket with
sock.recvmsg(, , socket.MSG_ERRQUEUE), it returns -EAGAIN,
given that the socket is non-blocking. This situation results in an
infinite loop: the user-space repeatedly calls epoll(), epoll() returns
the socket file descriptor with EPOLLERR, but the socket then blocks on
the recv() of ERRQUEUE.
This patch introduces an additional check for the J1939_SOCK_ERRQUEUE
flag within the j1939_sk_send_loop_abort() function. If the flag is set,
it indicates that the application has subscribed to receive error queue
messages. In such cases, the kernel can communicate the current transfer
state via the error queue. This allows for the function to return early,
preventing the unnecessary setting of the socket into an error state,
and breaking the infinite loop. It is crucial to note that a socket
error is only needed if the application isn't using the error queue, as,
without it, the application wouldn't be aware of transfer issues.
Fixes: 9d71dd0c70 ("can: add support of SAE J1939 protocol")
Reported-by: David Jander <david@protonic.nl>
Tested-by: David Jander <david@protonic.nl>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/r/20230526081946.715190-1-o.rempel@pengutronix.de
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Unlinked list recovery requires errors removing the inode the from
the unlinked list get fed back to the main recovery loop. Now that
we offload the unlinking to the inodegc work, we don't get errors
being fed back when we trip over a corruption that prevents the
inode from being removed from the unlinked list.
This means we never clear the corrupt unlinked list bucket,
resulting in runtime operations eventually tripping over it and
shutting down.
Fix this by collecting inodegc worker errors and feed them
back to the flush caller. This is largely best effort - the only
context that really cares is log recovery, and it only flushes a
single inode at a time so we don't need complex synchronised
handling. Essentially the inodegc workers will capture the first
error that occurs and the next flush will gather them and clear
them. The flush itself will only report the first gathered error.
In the cases where callers can return errors, propagate the
collected inodegc flush error up the error handling chain.
In the case of inode unlinked list recovery, there are several
superfluous calls to flush queued unlinked inodes -
xlog_recover_iunlink_bucket() guarantees that it has flushed the
inodegc and collected errors before it returns. Hence nothing in the
calling path needs to run a flush, even when an error is returned.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Bad things happen in defered extent freeing operations if it is
passed a bad block number in the xefi. This can come from a bogus
agno/agbno pair from deferred agfl freeing, or just a bad fsbno
being passed to __xfs_free_extent_later(). Either way, it's very
difficult to diagnose where a null perag oops in EFI creation
is coming from when the operation that queued the xefi has already
been completed and there's no longer any trace of it around....
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
If the agfl or the indexing in the AGF has been corrupted, getting a
block form the AGFL could return an invalid block number. If this
happens, bad things happen. Check the agbno we pull off the AGFL
and return -EFSCORRUPTED if we find somethign bad.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
When a v4 filesystem has fl_last - fl_first != fl_count, we do not
not detect the corruption and allow the AGF to be used as it if was
fully valid. On V5 filesystems, we reset the AGFL to empty in these
cases and avoid the corruption at a small cost of leaked blocks.
If we don't catch the corruption on V4 filesystems, bad things
happen later when an allocation attempts to trim the free list
and either double-frees stale entries in the AGFl or tries to free
NULLAGBNO entries.
Either way, this is bad. Prevent this from happening by using the
AGFL_NEED_RESET logic for v4 filesysetms, too.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
xfs_bmap_longest_free_extent() can return an error when accessing
the AGF fails. In this case, the behaviour of
xfs_filestream_pick_ag() is conditional on the error. We may
continue the loop, or break out of it. The error handling after the
loop cleans up the perag reference held when the break occurs. If we
continue, the next loop iteration handles cleaning up the perag
reference.
EIther way, we don't need to release the active perag reference when
xfs_bmap_longest_free_extent() fails. Doing so means we do a double
decrement on the active reference count, and this causes tha active
reference count to fall to zero. At this point, new active
references will fail.
This leads to unmount hanging because it tries to grab active
references to that perag, only for it to fail. This happens inside a
loop that retries until a inode tree radix tree tag is cleared,
which cannot happen because we can't get an active reference to the
perag.
The unmount livelocks in this path:
xfs_reclaim_inodes+0x80/0xc0
xfs_unmount_flush_inodes+0x5b/0x70
xfs_unmountfs+0x5b/0x1a0
xfs_fs_put_super+0x49/0x110
generic_shutdown_super+0x7c/0x1a0
kill_block_super+0x27/0x50
deactivate_locked_super+0x30/0x90
deactivate_super+0x3c/0x50
cleanup_mnt+0xc2/0x160
__cleanup_mnt+0x12/0x20
task_work_run+0x5e/0xa0
exit_to_user_mode_prepare+0x1bc/0x1c0
syscall_exit_to_user_mode+0x16/0x40
do_syscall_64+0x40/0x80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Reported-by: Pengfei Xu <pengfei.xu@intel.com>
Fixes: eb70aa2d8e ("xfs: use for_each_perag_wrap in xfs_filestream_pick_ag")
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Commit 6bc6c99a944c was a well-intentioned effort to initiate
consolidation of adjacent bmbt mapping records by setting the PREEN
flag. Consolidation can only happen if the length of the combined
record doesn't overflow the 21-bit blockcount field of the bmbt
recordset. Unfortunately, the length test is inverted, leading to it
triggering on data forks like these:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL
0: [0..16777207]: 76110848..92888055 0 (76110848..92888055) 16777208
1: [16777208..20639743]: 92888056..96750591 0 (92888056..96750591) 3862536
Note that record 0 has a length of 16777208 512b blocks. This
corresponds to 2097151 4k fsblocks, which is the maximum. Hence the two
records cannot be merged.
However, the logic is still wrong even if we change the in-loop
comparison, because the scope of our examination isn't broad enough
inside the loop to detect mappings like this:
0: [0..9]: 76110838..76110847 0 (76110838..76110847) 10
1: [10..16777217]: 76110848..92888055 0 (76110848..92888055) 16777208
2: [16777218..20639753]: 92888056..96750591 0 (92888056..96750591) 3862536
These three records could be merged into two, but one cannot determine
this purely from looking at records 0-1 or 1-2 in isolation.
Hoist the mergability detection outside the loop, and base its decision
making on whether or not a merged mapping could be expressed in fewer
bmbt records. While we're at it, fix the incorrect return type of the
iter function.
Fixes: 336642f792 ("xfs: alert the user about data/attr fork mappings that could be merged")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
With gcc-5:
In file included from ./include/trace/define_trace.h:102:0,
from ./fs/xfs/scrub/trace.h:988,
from fs/xfs/scrub/trace.c:40:
./fs/xfs/./scrub/trace.h: In function ‘trace_raw_output_xchk_fsgate_class’:
./fs/xfs/scrub/scrub.h:111:28: error: initializer element is not constant
#define XREP_ALREADY_FIXED (1 << 31) /* checking our repair work */
^
Shifting the (signed) value 1 into the sign bit is undefined behavior.
Fix this for all definitions in the file by shifting "1U" instead of
"1".
This was exposed by the first user added in commit 466c525d6d
("xfs: minimize overhead of drain wakeups by using jump labels").
Fixes: 160b5a7845 ("xfs: hoist the already_fixed variable to the scrub context")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Lock order in XFS is AGI -> AGF, hence for operations involving
inode unlinked list operations we always lock the AGI first. Inode
unlinked list operations operate on the inode cluster buffer,
so the lock order there is AGI -> inode cluster buffer.
For O_TMPFILE operations, this now means the lock order set down in
xfs_rename and xfs_link is AGI -> inode cluster buffer -> AGF as the
unlinked ops are done before the directory modifications that may
allocate space and lock the AGF.
Unfortunately, we also now lock the inode cluster buffer when
logging an inode so that we can attach the inode to the cluster
buffer and pin it in memory. This creates a lock order of AGF ->
inode cluster buffer in directory operations as we have to log the
inode after we've allocated new space for it.
This creates a lock inversion between the AGF and the inode cluster
buffer. Because the inode cluster buffer is shared across multiple
inodes, the inversion is not specific to individual inodes but can
occur when inodes in the same cluster buffer are accessed in
different orders.
To fix this we need move all the inode log item cluster buffer
interactions to the end of the current transaction. Unfortunately,
xfs_trans_log_inode() calls are littered throughout the transactions
with no thought to ordering against other items or locking. This
makes it difficult to do anything that involves changing the call
sites of xfs_trans_log_inode() to change locking orders.
However, we do now have a mechanism that allows is to postpone dirty
item processing to just before we commit the transaction: the
->iop_precommit method. This will be called after all the
modifications are done and high level objects like AGI and AGF
buffers have been locked and modified, thereby providing a mechanism
that guarantees we don't lock the inode cluster buffer before those
high level objects are locked.
This change is largely moving the guts of xfs_trans_log_inode() to
xfs_inode_item_precommit() and providing an extra flag context in
the inode log item to track the dirty state of the inode in the
current transaction. This also means we do a lot less repeated work
in xfs_trans_log_inode() by only doing it once per transaction when
all the work is done.
Fixes: 298f7bec50 ("xfs: pin inode backing buffer to the inode log item")
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
To fix a AGI-AGF-inode cluster buffer deadlock, we need to move
inode cluster buffer operations to the ->iop_precommit() method.
However, this means that deferred operations can require precommits
to be run on the final transaction that the deferred ops pass back
to xfs_trans_commit() context. This will be exposed by attribute
handling, in that the last changes to the inode in the attr set
state machine "disappear" because the precommit operation is not run.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
It was accidentally dropped when refactoring the allocation code,
resulting in the AG iteration always doing blocking AG iteration.
This results in a small performance regression for a specific fsmark
test that runs more user data writer threads than there are AGs.
Reported-by: kernel test robot <oliver.sang@intel.com>
Fixes: 2edf06a50f ("xfs: factor xfs_alloc_vextent_this_ag() for _iterate_ags()")
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
When a buffer is unpinned by xfs_buf_item_unpin(), we need to access
the buffer after we've dropped the buffer log item reference count.
This opens a window where we can have two racing unpins for the
buffer item (e.g. shutdown checkpoint context callback processing
racing with journal IO iclog completion processing) and both attempt
to access the buffer after dropping the BLI reference count. If we
are unlucky, the "BLI freed" context wins the race and frees the
buffer before the "BLI still active" case checks the buffer pin
count.
This results in a use after free that can only be triggered
in active filesystem shutdown situations.
To fix this, we need to ensure that buffer existence extends beyond
the BLI reference count checks and until the unpin processing is
complete. This implies that a buffer pin operation must also take a
buffer reference to ensure that the buffer cannot be freed until the
buffer unpin processing is complete.
Reported-by: yangerkun <yangerkun@huawei.com>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Pauli Virtanen