| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
# Conflicts:
# crypto/scompress.c
# include/linux/random.h
# include/linux/rcupdate.h
# lib/debugobjects.c
|
|
This is the 4.19.304 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmWbzh8ACgkQONu9yGCS
# aT6nzxAAkwiBVc/j4TFLnZw8XhsDiZdfTMdCHT5BmqH2uz1E9JNShKY3dO3PaTU1
# vSBjpj/K1l0wuQwwyM0uNTDOxCsJ+4xnbQdrN3QsE7jNnSaJRT+tGFF8DED1saky
# 1vvMm+aZmNVuOSm6zrQqq8Mz/pgeyfbvGF0wE+aYQg1b2b7gBJlmtafIg05jChi7
# J+fbZbQpw0/Peb0cNGmiOnypw5cXy/Th8S+Ua9IWTr7UbEf2uRS2ExakCpUbTjHU
# OUOd1gy9qgUMzS2aWacuR9jtfVxVZrC6MhrGNMAohhY9wJbF4ZlKSn75nCJwSDgd
# 150JY6QRwYwMcljJN7LWDW0d9aUV2Gs3y/OgfuHiwLdLG8yc1O88g4booV1dd/+K
# 3+D1layqNNvoT0dDRwBrea3gHD4AyNR9qHtPmiTWi3e1KYbzA/OTc3wucHtc30Bf
# /PwuOPEp6VyKD1wqE75d9cks2TgbsG9rxYrmWyxp3sfGsXO3FgiNul8JNXqz/P3Q
# U9SR9jXJ8GKW/e5DUfM+c6hK9kXFmccK0hf7+2TDoFOxdCss+RY8VTALqxcc89TC
# UISEP+1KeGmSFzNc+Re+FvLpjQKFfTKe8Ak2sVXySdK+w5uZbUGhE82RxaDDldjN
# u7iZRIHkc5Y8GDFWvHED8awsMcFsrqnrGunYmqahBek8eQu7JXU=
# =ck1B
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 08 Jan 2024 05:27:43 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.303 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmWC/FIACgkQONu9yGCS
# aT4PGBAAmX42BpkC8qqWMrV0bmHf7KtjUyPBeMybVKBXaFkhUSbtwraAI0QWkIUM
# mEqzUehaTxFhy+QFGRvA9982ChamygDZsWK+2EOigqTXFmVWrIESC5GJAHrCdc06
# /b+6oNoTFuRcbVIAxyEL9S+K1pJ11/6Da6tvUKiWizczpZnA3IXLT4nbTFr3Q7cS
# wPv6ggk6rdyXlmMSiYrRJA4HjN/0akrUNcwoW00LCgKc8892Y7Q1YfnFiJVC75Fa
# U2+97SSvboM6pJ28mvm3yR4dV02Q8Cs9hI9M1rzIV6ftU8KzEUP3ZCZGaUh4Bwqi
# MOH8T5DaE+Velbp7ECyzQRHOzhu1dGjFOda1ZR9YpbcE/PBzZ4fOSIUf1glP3K6o
# U9FpIJHMn+MQk1j4AA+GYJfhOAeaiBjs5y7z3hhNLV1lvshuZGxRKONUtBtOMhwS
# HfYBW3/7Af7a2q2ITS27RRBCFv6Gqkza0vLzte0Om0XvCn6JFzzIsymFa0cjjg2B
# G++HZDBQqHWF8EEYRA1XsoJQDEk9o2F7IaX+hOar24mAEsqXBYNzOFvqn2uf/a5c
# 9mGBpbDGrq0P5EkwIQjgSovbvmplmmAGB74fBrCSrQVKuXjzloAjUbHQqFVVu49q
# lAMTCtfLxQyioSlTXrYKX1ANKjlR1kqBIF2GP2oHE74MwR3hYSo=
# =V5/I
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 20 Dec 2023 09:38:10 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.301 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmVyySUACgkQONu9yGCS
# aT6OEw/+NbDTTyd6qvilupBXQI0U2zNYYUAgYyI3b+f26bJcGaVS144bvGloFsEJ
# F2kLGRzeHdskQbU8p91XClmkTZ5rne9MMqQjUosfED6On5NT54o51eGPMrfzF44o
# zt63nFLuWYKhzbvMij8JuX8qzjn65t3maUcT0aNR81x2VuaBgCvFRshxMwOgZ7Gg
# ImSJys2VXuQK89zvmKCvJgnhGzv3oLU1yF/AQl/vrcnhsR/75ClvVlGs/eAFsvno
# 8qfwzKHVD3NYtBuR7j1JtjlO2d7ale42EgHukqzaw/vBq/FpUSBu7Q8EAmUQaxjp
# ri6BoApBSc6wNa++owlkt3bbNzNzTtlbV5jyibSfRAEMl5aIHsgz9JQnJmO91UTh
# VWGMTQVHy173ubm0FkpyrDLQ0rqLqKWigIGRGV2ZzfiGPKgME3zwgDnjq9IHAo23
# 8NNSSVBu7JV1eQqm3yG7rCSxWk99O9/yN3scS913CsrTdDCCu4v1NPOozHnNfGXO
# O1N4KClar8zsYJ9ZVXM0P1cH7kOOXdjxYQxODaR/FbTfZQ2Jq/ayo7wvC4+ZF+cX
# VxcJtoK94PcbyC/jub9m74Kq3Ujtz5lYzU9JmzjsuvjY6qeBe5fOiLk69sKa5set
# exg9SSwvPSgA5JndW3eXB5uD+rUY45taUGpZzNmksE/dYANdd84=
# =Xhd3
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 08 Dec 2023 02:43:33 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.298 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmVLYWMACgkQONu9yGCS
# aT7TWxAArWfLx5B55f2sGj/cDvs2xil315t1p/uhXCtgcstc/E+lxRipw3Bi3B0g
# IwoBHoxteAhHVzscTJUypzi/lzNdKuIoNvtD/IxpIt/vcP2T/JMBVzrMTsClGkDI
# xnaMq51lWT6Kpc3zt0k4EeAA9ifAeM45kIbZlPooJ15D6zuCLLMGdKiai8eYbOkM
# X65dzw2FxtCvIP3FfBxr4opRsWmkXSxD7diRVe4XPE/RyLFePPMitFg/NvpK/QLW
# +3aR6n0hhafvsYBE3T2+mb2A408uK7nT4aup25k9JF/RKhSzU2ZKTTZEtp92pZBr
# pHiUGa2bitYryBvSt69wRRamqctonrwXcW0FCAX+JxxujcfBmSR/z1GudQEbKBm8
# ALY2vgoDHeilbVxUCVGqnBpvu8NgwBw7J3z5S5m913X2CtMpeotvGzgksEE+gzdV
# Dw+l6bhj0vxAveYEgA5WVritymrh9NFNPQh32zeMG6FCcQCzuUd3gZPDECjcgFji
# keK3e71vjVemvgsvwAyx1WPpD0KDwjqZCAUL39Zmc7gQUzLZx8E2ujTIabefwJIA
# L3RQHFsVE141FojccKFpHhF/5ne6qAv74ZlXz0DBxstgx/acUCxqN7XJSVZw7OHN
# bpF3F3KNv1xOpN28rh+4Qjzds4TKQ+de9OEVJA3ZG2QuUqoFWXE=
# =013M
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 08 Nov 2023 05:22:27 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.295 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUOpmEACgkQONu9yGCS
# aT6vSQ/8D3yjJUYiUnHkiSzTMZHAtwR5qk0jCsqw1Xlr+XVouGCG/wpk8z7ckT6W
# 4gsG5+QvuB4SfWXmbIn/rPApqQdQSiTicOfHrev705v0U+ib+kw1vgBKv38qkOlI
# EZKuo7Ir1vZUnqghw9uIGperU3kEAt2EvWK37EBryukDoxbzDGIctOvAN7KMMbAJ
# jPQciVOOAJrNNdgPOSrxs1OCdAkEYlDaNuBZ+9j/HjNQLB9KtdtsJ50gerCPA4rS
# oKpZhnx9VJYXI9szor3T7q71iNfpJeL+mOrnpCSFVAFCPkesXQ+MG/GdgJJQDCMJ
# 9VF12W6rpqVcKfYFdPX9WevkqMfHRpE4brotDQx36rpUwVFcP7HClJ2zE3p36QWV
# Mfu4O31ZNkLUF8SmFXc3JXVyrwe/ARiha9nLH9VKZ7cSHoYUKlO4NeSGyHjz5J99
# RErBGpea7SgHTSLk30+sHaB3zhdUZyv8ej++zjTG9QA8bRbMp97I9psQ7FWhWDng
# l6f87mdta1X76OJJPkL3yZfbiB/M58e514ptbDNhu4cnH/S6aB6I3K5IYVtfZI/9
# zESuavKEUks+Ng1vBUGsPGN/eHDaPWUkl7HewP7WXRDOQUjaIX/0saeaSiUFYNI7
# UYa72hD9fKMblkwxIl75ybI/WZRgw9fyrQeGG0DfX3t6kt6BhHM=
# =bQT4
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 23 Sep 2023 04:48:33 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.291 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTWBMYACgkQONu9yGCS
# aT5fcw//f8IqgXhnM1RmdENWcj8Yttld1jY0L8+z2fRvkzmuqFJAnOuTEP/BV9Zk
# iMNH6Hg5iZh/ajGyW4OxsWHvaDNyZtpPOgNtQkhHPPDq5tqAgg+8ZgPlZkmbvnGd
# askxaSJE7OuJOfG193o/Uf0CR/boSIN1ioIu0vumqhrP2NUbe44/PLeSB239ZdGy
# nIaBo1JXffOH8P7kSS4E9NSrfoA9MQEuJgcYPkc1c08W2FWO8MftM/hdQtXGwbNC
# LCy4yGc3PN40MT7tOsXE0w3P+ZUXfP6g8NgHooRKuLimSiAYodLgCwnvELZ/Nsg+
# w1TPDxbLD99te5J16GzlzhN4+9BUtf2qq9ZgiJQ8lmKaGc+hAMRKF2h2E5Qhla8R
# TJubYFjD5yilANlRumVHMzNJZntROw0hG0ZIX6An/1QM5JAy7B736jI6jt+RZFSx
# r08xhBXcO+m3s2Vc2OojJFKLot9i0ugiKkTuQBZsBFDfcOtSrUUarB6Vz6wZvCY8
# sojQOS0eoYb+2GlKJ0UzTPLEHrCpusRkEnv3QMAPfTkw6vqvkrYACfOEbBujfT8e
# TtC7wuS3beULYPKpObe9HrpCooOXX8YQFXyld5e5iBINXwt/UT4daDL85BbMsPEu
# MPaSKrTMGXUsRoOWHiuPumT/MDE5LBSCqhyi41k90R9qRW6M+Wk=
# =KuAb
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 11 Aug 2023 05:52:06 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.288 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSb7KoACgkQONu9yGCS
# aT6s8A//U4Q/1LMrkXiew99gV76v0LlFNuXEVWkd0VqEdeK+UG86gLcfjZUaHmtX
# Jx0nAZ7GWvn90ZaCNgN6PrKQ8LSeABOCGcpdx8cvLxoSGoB0ipjVcwddocAjOIzp
# ly/+1HhC0UadE9NZ7vyaCiUZ3U+0Sj22J85JZz+A4y1FwpYbXHJclGmmmmUg4MCU
# NwBUiu+2ad8D7vR7a0yiTlsdxBAwU2LoEdysteBv8vDHB+BXjNXC0jpBhXsvaaBd
# VN0bav9XWvKHN73CMcWW8I8ABSirJRQhdGC43BMNjE2+I3KIHjOzgqALOvfd9eSJ
# Jl9ztoqO+tI4wee0ZIQbobJ57vgqik+oX4eTGxaAfxD1BgqtuNVaDDw+3Wg3pgpP
# mRdbbfUixFR4tP0VsuLN3b6Ff5q4nhq8h6ZJ0I4tiSRL6K9CNimBKhTh1ECexDPr
# t+se4Zr58KkgrZCM/ERrwn5NvRcjF5PuBA1i3u1DWecHptZ6FNAwHSKMPFM7CoCH
# FTyNikDe6FCtzA2gHkj85bC5W0QahU+SD65OIv7Ziz6SOLKu2HjLYxQbcW/1uCW0
# Nikd5nADhOpDAxLvb7Cjt7Gh1GxWOIVnZaAFXh+KCVT9p/Xt8JimXvRTdSN5PGkp
# Mhg525BLTdXHQPr32IHY3gbeRbiAMCBK/pygPQ2DBKRVS53jkyM=
# =RsRd
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 28 Jun 2023 04:17:46 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.285 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSC4oQACgkQONu9yGCS
# aT4vEhAAjCSfwOvhVr1TG8BBldeXOzPBCsmzNTXMfSmd1YzeApZINmDl+pgMLWZO
# ag9C8gdsfre3rihcmuAPdHUJt8+yYP3T8jPKq1sLii5DUHkWXK3FzwAuSe00v/nQ
# 053uXMWhtwOzHa7oQFN5yGGiL8mgI0Si6wSfPM8FCiaNJEa3AuRNOL2Y5sw8k+jy
# Pe6xl/P3hBKW2FLGKPK2OnMt96WY1ylbwV1SQlSZzV1pXN8vL4HKSvftt4JqESIQ
# Jj8doEUzBRAi5f1r44+2F7RTHbxVcyphP4BJK1jd5yxpyeYTUVL4PeH8X01TTMc8
# CJqbOmuPGeT7mVtieDwZcOnOuinfvsgcLHI6I4f+xyvfD3VlHKCNz7RUDyGmfsyO
# HQFICH3+7BeX19vp98ybIno7B/2DfqB/sIhqgytn2mbspSEinrNCQJmx8xw4++wg
# ByEvUtS+M+PVERPn+zJipeX8/lksbx0rzyFY55WlkKka5oH148TV4uz459beW5WN
# zDczXdOmWIgq24XpAA0eTu6prcUGG2oea605mCiKM/B7TBWSYMtjH04bHDp8QLkr
# yi6yT0S30pVkPBf3JWOiCNHRlcXbuf/60l9oCExlWnfhkieOs//XF085ZRmuLQi0
# pjW6oc92JeRbubSsDRRPUAwAPBHMRKKhiCs7a3QObMInbqkMWVs=
# =W8Lw
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 09 Jun 2023 04:27:48 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.283 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmRkmvoACgkQONu9yGCS
# aT77dw/6A648P7TZgPEqBR5L4aG1u4GC4wE762PUb5YCK1XEWzgUdVPXrcRM6+r4
# ntoKlSJxveJh3TYKLcUAJWvvIt2lbOEdQTb9BS2ALoZv35q5J8Npw/CUP148Vy47
# 52PQwr4M76+WTx8bfckrBeVPHyhgNjFtFjuwg1TLfIvo6pGrDPnuNYo57K1/O38m
# Sid+eFrGBkOIjUVlfaStMIP9RVZTUHpPWHWp+cmqGTDK3B0m8BkoTMXM0hLu/fJH
# HPivMQFnyRNa0ZZAe+iQVmUjiruSPbgqNOAGSqTr5FxxSrZ3ZUjvtI0BYTA7eo7q
# BnPbRHpuRQ+YOnDK0Q+Ps96DDNALCz2j8bXXEjJePpOrqv8IoxU8kGx+GVcbnQiJ
# Bd6bqZwXU3uPN8VLTR0KtfypEH6ELbBrCXjeeSw+RQqAgsdEGSbVSgfBtISo7UMt
# iL/VFwl03qdm4Y+Ww544kNMrtDV+Qmq2MWeP6uHzx54ZH6ic5rFhLGamHEuIUg54
# Ux/9dLoByzbVOEMS5SHaqaxcLd/Qx0FtUq02rhsHeV0IEFxviX4jPRet0kn2vVru
# 8o+Vh92K+gfNW+zT47GPeTCBRIK+YuH2cwsXJRucGkE7IyDccgyA/v1cchZO9xoD
# oetofMcWiZi3QNY26EVuYA8SlIwURWkhb3yTbFoOx2+jQ6JER6k=
# =VSYH
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 17 May 2023 05:14:34 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.281 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmRBDkEACgkQONu9yGCS
# aT6QQRAAuMXhQqInTov+2CjNyHlBGEIdl4F+ydPRkJdr+3ISZ/ocqxXu5ta59RJW
# ohyDRW7B/kHRomHxeh/g3fkR2EhfaigKgSdohUL1e1CUJgmAYqh3wWio8MH2NZKy
# MdNOB5oYKk7BPSBY01v3jLAd1B4Lz5HrvlagbQ5onasnk4+pNQKxG+TjfVPthWX+
# 3PZRS4t7rlVXCqPt09fbpaxG2Xr7OjelmZe3KtUFYfy0f+bZyQcvY4wn/jSZL9uy
# zIHQLCUevYwndgIpswjt6dJl1JittV/977hyEdu9nS1bcqVttLLRriLqpefjciza
# jHNwrWBkFl7G+KeTA7baYW9k0TOmpIr4ROjyeto6u9TEIlULvGzApAZfm57/zSt/
# CzRjkL9pSF9KP1VWDC4Wyx7JRUliBYB34esPVxqXUjW+idj4RII8ZxbacdzoICXT
# U+Je93RR9gQ9Lsp6ESBj3CnkjqGGWsKGZ+JUw0XXzurKqg2SCcHmIkIQ+2EFNJ4P
# 28FTlfnISxhvmvJnLXbecKQvL0qacWD+5Y8JidqlB9QCzGhN+T+4CRe3rjL7TKv/
# INzPF8h67VCA986vafDpUXLWRwhdWjea5gXOhukUsYfKbt1k1yjKNdr3dbkNMnsh
# 3tfJB7xgVcvd49sMDTwCN6fpJTLbj9kgVYpZcW0sHFQyLuztDZs=
# =TJcb
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 20 Apr 2023 06:04:49 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.276 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmQMnvwACgkQONu9yGCS
# aT7Wnw/8D4Y0jHf5hAU2MrVU+8aBdqdJ3CMUuqaq1/zi0yq3cWyDJo7sU5L3Tpdl
# NBDdEtdAPDVK/jZ+BCtgtwccTG8Vnt8uXsVpcKJ50hBPnWfcJ9g+asrEOnIN4MI4
# 2ltYKfDxN/n/QB9j2V1s+Nj5+VT1oTJQ112ksvn354REMO14htiSZtX7Y9Av3qks
# PhHf6R+482/a59zSKM4F3HMGhcSzvPz56FT736MPmd0hvfokDYzSmNRUWx5yKgHh
# MRUmS//yc7Q24VSmrwz4PlOqolso0w2FiIxUz6i2/O/vZ/qQiZMTlanSC9cQ3gx1
# /zEGSxMRzCzTS/huPIbldSIfaLmfRY4zHpnIuKsqT6OSq4xg5BXO1p6MuUkhN9E0
# FB8Wl4xPIcqZ7BMHNYUQIp61tE57NPKzI/WiAaqgDLQPKLDsNp3YOj5aGvxFZ4lc
# beeEIhv3nD7r4+7U1j+yGejdTigOU2LlBVyjjir93pDy0RsgjoGdvzp0pnjZqsPG
# An0R/2PlGINwYX5oROPt/lr6tFbshYKB5QfcMxCJ1+MN5h4T5Nc3SJsuw/U92iH/
# MSUb6oDOsbM3FuqnHlVGJu96ttiKNO3hz6IjC1NtaWFUCTtImbsBxWNn51mJ5Svg
# +YZhzyKFya40pXMQrT3dSV4NxPnUBqI65Il2Lq1LD5zLjZC2eRg=
# =zwmc
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 11 Mar 2023 10:32:12 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.273 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmP2ANYACgkQONu9yGCS
# aT6oNBAArmqskeKikeebAGPOtU1quHBGnnbpSOd0SFZVTLi0N9YD9SjVpJ8RoMTT
# PCPz1yc8qw+1nFL0DQ+nJ/hx7SK9mfGpBB5CP8ZNjI35Hpf7RMmftwXGvEp1FAMX
# 1xTUEB2dS2YH9fp8mZYAEjFAQ76XZ8u5fXntVPCcclJIbxMkcgvdRUKtWkPwK4vd
# rJytrqPYEe9UyPWU3Gw0OyRNNFpZcNB11ZbOWeCpe+G31naZWHiqcjzi7hF9IGsA
# lzElk9pWpMW/WxpPfNkxyJEW5NfnEJTwjaHoV5LF9jONOX6lV5e4hRr10KkrdnxM
# rQB82kN9JC1+r+5Zbkz1Zy8Tmas/aI1Gk1oJmZufi2nhP06uxsRVV06bqdg8MM0U
# z7giLCwj7+gIk7LXm/kmVLvTVuTGMXdhfUaVG1OKxcp9WjLIwpkDJS7raEZ2Iyy3
# 5/IkvICt+cINpc/s/eO3u9CaRZVCb2vUYVRxY4sc9j/+P8U9j/N3DmbIqYD8b3ty
# sO20M/DvD2Ra0PD11QofMqg0fegZTTCvhl9hFPu41gXHTKUlM9d5QqTZPC/JoJ3f
# vd/BoSvXuzxJHyljsQ2W5BUoEyOKbM12EBnbiuxPwospfy/U6y/nENe9v463bWFf
# DuZfaWx6+I3WW5mZeaWA7IMKVmfFazhjhztZqzhd1yUCkVINN70=
# =5lII
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 22 Feb 2023 06:47:34 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.272 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmPgoxsACgkQONu9yGCS
# aT7P4hAAiY1TIECbi0kriTeuRmi/cGkU1eo8ODV+5h0x31cEObCZnsvU6v2LeqOJ
# X0H8U3MwjxyVYoK1L1SUBClgPXqBq0jI4+CrjVSQcl8kWGKhUm/JXzjcOC6wAlB7
# M2BRD2z7M+K4Mem1Q6eV7UEuEBPteLquP4xPlaXKkRAoeWKXcbiRM3ns5h20Acmi
# igDqhzLUAiAIhL429vPAOp34aNDmaZzLXiMt9p0mYkDFP7I904FrlBAsceJV8NZ9
# 6oxxQspkoCf8MjBGrV6JcFwNgHjCHM+zXHWhROCE9WL7rknCJidttQKsOtzNE6Gx
# pFF60qFRx6JVsvm0D2lJpEW+ExdlcQ/aacByy3fXajkdyrsl9sTajiw0+1f6P4Oq
# hX8U+HianG4G1HgpOAUeZZBcTn7k7+pdTcogLaQW5Csch2RHMmmnPMZlZqudGUxD
# yJiyd9dRIEPOa8CAdCzI4/xgjEgogS1snS9jRhJ0rwRtSqL3lLrSRdeFWbVjgA54
# HAF9dR76Y4sbmWv4MbUPK+lvROvWv/NtLeiHXCJCGsxWdcOYQTw8ASenaK2IQRUF
# 1ows0gRXX3Xzm6R8CvpJqT80ta1rUfD3INycV4kUHeRUlVsrBtu48KX325+ZUXD9
# Lvcbips57QvMMigROx6HpQHbmA1fe/42mZfhf36sgzycAmIzThA=
# =yuwn
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 06 Feb 2023 01:50:03 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.270 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmPHynkACgkQONu9yGCS
# aT5AtBAAsdmYCYkmKZsRcS1EUTqdwKVN7FDILDcdMjfmrSp4ZDliaD1dUc0EmDRl
# yy+aNGCrhbuYACk9WdQsSUrUIh1dK0H5VsioB1m0cjCgifbNjsYqjYWK5ewXKUyX
# yjc+NmY1HVUFQDLnYHJxSbnB/o+nobWjts8nGuWHwQmoh7UmFe7lvMqZg753x6Bw
# wCiaC1DrU3aKHYK7IirdWgOiDiGia8DX1nX6PmLi6JTsXj+Io0i8PXKkFzANDf/p
# /rOyg7j8NOXIQPZGN0Zu88QiMWsNk7u2bOORZgtFbwo7r9BFbzXfWk/x8QxzDX1B
# iH1p02XQvBwm44xGJZKiWEY2nZdw4mpyzLXZNOL8V7vn9xhT6HDksVAPnyIkU8Dh
# wsij2r27x18VI9H7sstvAHvIyg6ihmq2E6WuC4W74tUcys7MXxCFc2DuJzMMocf0
# 7LMTmx3/oUHvuM1riJ9STo9mzXbTmfNd6hnqRnFgGKiGGhOE+pX//RHfupaXRieQ
# Rq51ODFKcJdDIM7hxeyPdACYF/kso8sNEODCgQ5/+3opel1mzLdBJ1T2bV12DpQe
# ZhTsESPCVSoUAjCnC9Jje3g0u3qztClYq1faHOXtnjykn9mHmmedVwvdfJL/sOsr
# ec7NgqzM9xvMQVe4CNf0mouugaLpn2m6uQDTu+GWswRfEKuCx2Q=
# =ksam
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 18 Jan 2023 05:31:21 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
|
|
This is the 4.19.268 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmORulwACgkQONu9yGCS
# aT7rlxAAqr6GK3Ei3JnP+/bWtrZxOZaMJ3v4d+o0x680B0MYPiCl8O2MGLOTFh5S
# TLhYsYEddu+xAmLBLDFJzylIPr6EDKXBDS8i4w6/WWJA2Wqvk2vp2Mculm6OeIly
# Np7NycSvqpxxfWCxqzilUqdu5pcTGbUB6fM+iCXIeDxLhFN+q4gztIBSBUwr2fHI
# Okek8QOPHQGT2dQQvQLSo/41MQYm0g6d5U2/mvkRysz9esUKB5TqYBxBkla6hb8s
# A83fZ/TGZwulwyJUhJVbEGsQ0Jbr/uzRS6LrRkAFYMp+FQN194w+2Xb/AN6xiKij
# miVZxUgS+tLbuL2CZ+AjEVlkOdtQMLvzn3GNX+iYAMPnXvPiLq6cVhCvm77EM6Xs
# gQ1fc42REvnLl03lIvYcIBNG6ESXCBzLaX+qHPqPzl3OPcOv9VYVMEzQ0DVXXp+I
# +3fzLoQNLbtV7OSQ17d+Uxijw0U2aXMemoPlGGAxhntIs/Pn/NGhGSKmYed9aImp
# 328YgGIBvaqINrAuenaXLckzEcxXRzfb+iM+V7yJ1gE5pam0eppbbuH2hTQTIzqS
# PPqWdq6fPSjgB/RvRURj36bGgUIMdei8Jt0/GXDWgIe4qgstDJKAQ2fQuiVVOfI0
# arMRtQSW8wTB/gOTOSgGpNiEywqK8mj7EtutOFUdGa5IAdloMZY=
# =+EDx
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 08 Dec 2022 05:20:12 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.267 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmOA8CAACgkQONu9yGCS
# aT6V4BAAxRZAMCEAeeruu1tUNaZHWVmZkpsawlC9c4+lavSkniYbcXenkmgYBBcs
# 4GCklhZawUnDFl9VqC9xrn39aRdLX8jTL5tFSNlN+qbQyZ1SkEgvM2eeXHBzBfWP
# SALX15eLoCe4p4RzhwL5nlZZ9Z1siSnPUKO8og+j81X65DpYrIWRmimZthOY733a
# u6emEYrC7wcpuO9DyEU6ZhkHrvrBRSeaSELeUcShwfK4vlAV5FKSRUgmcIDT7mTe
# gtLSh/qlsEO3t0UxPckqG6tsgDofuK7o04YkLzV6y2TMgRoLSJdzn9bid65e3h2R
# jT8FcnBBxJgA42i/0e1UIbYgIisnt2NG1Tq8OrrVXe6N5eF7KhoFOZXiZ+Qq0xam
# WbxPe6jZu1cgrSh9tV1xOX09By31uzc3C6zAMwz/KQbXYcaDQeL/krl+IolDxab7
# 4fIHDGpmIS26aSr2GMWs9z+UDgIH5KOXEweLCsCquRIEwLcpvsPMnq7fnHlAspMX
# O393TY53BtpGIHYGhHJuWuLFIH11Rb3RiTJxU2lsZzHrETR/THirf6T8a6yYWwCo
# lY8tk1XuHQ89X2e+TAsQJ6LJqz2tnHPo01zqhsH7wJKCmnBE3VMzg1NeNxhW3q/i
# CEpoZYF3NhHSRvg0Jcj/DyGI7zuMGRyxprzhtso348+rQ+lYhVQ=
# =Ufv3
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 25 Nov 2022 11:41:04 AM EST
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.264 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmNj1bgACgkQONu9yGCS
# aT4ABQ/8CCO0lyrHTLSG/hmhXOaLkEq3q4sO5xI2hAAwaIGngivQpjR+qGicUxm2
# MmX9pLihi5uEpayVFM0Gb5+6NRObgUULAetiDk34gSqnWjFQksrS8WZdNzXSIq85
# yn3+1o87Nr+gOTGd1xighmRKw87Kaacqtt80MXBeTQ7SZt7ES7Oxn/I4zw1vjiDz
# 2nfUp+w2yWsUoQHOUGITe3+ae8QmTX1dwQhXf/z0EX8VqgGEKD7Sv6aSxZfmb4cL
# srBYw0D3bi5+cSH/auiN+rxkGQ7CZ24xsqaFZN4L5lAhO+TTfanp6XJAMAKFYm5N
# 1sjeBfNNDq8LEThqBG1RULlaMOkflW7fXAZuA6oGJTr1+V0MP8h79jniKSJ8kGnN
# xpprlnm7hKy0OazbRIcRBPim3hv5fvy+U7eiWQqZCOdYc93hTflzamXeu+OZNpsB
# flAJbUGDUniApKFhyXhEWr8jCz7oQvf2VzQmKRB6KpbEOgaEJ5S8Ls5pGzt3JqdW
# AOQHC4t4/EcyVvOBUcIiXYtnE3VQ4RuOU6bCU5soqDiWTYk1yeRWKFiFLpkzpMAR
# FjKBLFez2Dc+T09DXcXbJZ7V3t510hhLw9Pai1iXuZlkYuk6jJGZ/VMmi8txxyYt
# wChGDUcnv2W/Ub7hLSk9GkxtaXQ3zdLYVk2GtloCkuqorks8EFs=
# =7RS7
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 03 Nov 2022 10:52:40 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.260 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmM0DccACgkQONu9yGCS
# aT7rLA/+Kht2QUTuMXaoGnhRnCICOgQC4RykQgrdLNlp7rmcwh43I8dIwWIGuUKP
# LHB1PQQTKrpAXwkksXUteB0oOwnXoodIwsQX4u21RBySPll1Fs2l1TyyP2hph8nw
# tDEXDcLrd5GdHhS/zR+skKkfyy+gMDEmM5ArDhrQeVjGArRytB5TcXPOUlfhdER+
# C1g1JG0nAG4jM5x7Nq08XTSzn5zucL0R9mOx+2vO0yTjAmghsdu5oHBBifcbBmuH
# DS1ZmKg5u8XxjCYQlkTNoyoh0CcLckZyEKn/f2uQvnMvhinfXz9+qn+jpbL1YrV+
# vAGpQOmLBoX8HSMktwjQGATDygeFi26+JF/cTFpTuL0knbiC4VvmK4V+Wkjpjge1
# piUYv1p9g4+/ZpIQ9OtDpEoCFCJeFGJo1u1fttyNvBw/WXZo0Y4EgDWGNlcPJC7e
# FDL63CQ/VHfoE15yR63z9LzJD7LOiifCLBZvM0mjb+0KSgPRbexCTcyylh28QgHR
# bLU8L0Vs5t7NGOWxWjK/FPLl8eaj+F1jn9N7f5Y6oWvwE/qXtNyZS3b2Vw2WeRVn
# J4U484N3aZl60qbVYArFaEcRmvlASIOKdGk15G2jfwaBcdc4fcajt37ZlHSHXVph
# EDm96/ejTD+H8gHw18TgGtp8aOmovKiK4hHY3GK9/uOitWQG4aE=
# =aRqh
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 28 Sep 2022 05:03:03 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.258 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmMi+60ACgkQONu9yGCS
# aT5vGA/+KE+vkoWSnrIUxwdzned5iCqHJxX08335ZjPHlTu9IueQWr7GjV35EdGD
# Q0JmavR9TcUpWBZgUS9oYSD9J9AVd6VdSJ33fyhvWotsewKrmrTmsVAWeTVb0r/K
# JYCzd7wx5li7xBsjCJ4ofx9+ETCKhgf+QFXMx123IN+nPC+Xk0IFBb07o+j5htLE
# 7N0wx6pWFjo8Wr8Uol6yx5AFIgg1CTWvpYfpgFa0uTodKobfu9qHU8j+GcHtM0YA
# oJmEjRL1l7bX5ezizcOdot1m5v7SUOyYoJVHhbViCIHS14ZzwAwjdYfb5BxsfM+G
# JdJI9TM59At+HGkL3CY1X8Z/mDZSGchEL1OOjqrM8H3xutg8XDg+thSgpQ0sJlB+
# ywfdjt4FXV0NESp9qWJMCpEYCgjZ0XNJgugBqtB2bhuPFjdCX1ZSjJ9bYOJQJPI0
# k+XsFbKzRJUV7EOWUZHBv4IetXnfRHqHW2il/776vf4h4D3S5EHg4qgz3MqyCMPL
# mUhOhYWd9/CSU9Y/SXx150xCJ4qa6bRbD61/M5glBxkW+PkwgXRMk+1v/Iz/emyX
# dUzjPmIn5xA1Cm/D4IZjBYfcY9XntyatB6aUC+vy4LeLaECjDXBwzu5ArQlH8cWY
# b1RJS8dQcjF56hHGky6e4u6i6V8XPv+MiXuejOYhWFvUHD4q2Y8=
# =Acx+
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 15 Sep 2022 06:17:17 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit 24165c5dad7ba7c7624d05575a5e0cc851396c71 ]
Fix a unit_address_vs_reg warning for the USB VBUS fixed regulators
by renaming the regulator nodes from regulator@{0,1} to regulator-usb-p0
and regulator-usb-p1.
Cc: stable@vger.kernel.org
Fixes: c0891284a74a ("arm64: dts: mediatek: add USB3 DRD driver")
Link: https://lore.kernel.org/r/20231025093816.44327-8-angelogioacchino.delregno@collabora.com
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 3c0696076aad60a2f04c019761921954579e1b0e upstream.
It is currently possible for a userspace application to enter an
infinite page fault loop when using HugeTLB pages implemented with
contiguous PTEs when HAFDBS is not available. This happens because:
1. The kernel may sometimes write PTEs that are sw-dirty but hw-clean
(PTE_DIRTY | PTE_RDONLY | PTE_WRITE).
2. If, during a write, the CPU uses a sw-dirty, hw-clean PTE in handling
the memory access on a system without HAFDBS, we will get a page
fault.
3. HugeTLB will check if it needs to update the dirty bits on the PTE.
For contiguous PTEs, it will check to see if the pgprot bits need
updating. In this case, HugeTLB wants to write a sequence of
sw-dirty, hw-dirty PTEs, but it finds that all the PTEs it is about
to overwrite are all pte_dirty() (pte_sw_dirty() => pte_dirty()),
so it thinks no update is necessary.
We can get the kernel to write a sw-dirty, hw-clean PTE with the
following steps (showing the relevant VMA flags and pgprot bits):
i. Create a valid, writable contiguous PTE.
VMA vmflags: VM_SHARED | VM_READ | VM_WRITE
VMA pgprot bits: PTE_RDONLY | PTE_WRITE
PTE pgprot bits: PTE_DIRTY | PTE_WRITE
ii. mprotect the VMA to PROT_NONE.
VMA vmflags: VM_SHARED
VMA pgprot bits: PTE_RDONLY
PTE pgprot bits: PTE_DIRTY | PTE_RDONLY
iii. mprotect the VMA back to PROT_READ | PROT_WRITE.
VMA vmflags: VM_SHARED | VM_READ | VM_WRITE
VMA pgprot bits: PTE_RDONLY | PTE_WRITE
PTE pgprot bits: PTE_DIRTY | PTE_WRITE | PTE_RDONLY
Make it impossible to create a writeable sw-dirty, hw-clean PTE with
pte_modify(). Such a PTE should be impossible to create, and there may
be places that assume that pte_dirty() implies pte_hw_dirty().
Signed-off-by: James Houghton <jthoughton@google.com>
Fixes: 031e6e6b4e12 ("arm64: hugetlb: Avoid unnecessary clearing in huge_ptep_set_access_flags")
Cc: <stable@vger.kernel.org>
Acked-by: Will Deacon <will@kernel.org>
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
Link: https://lore.kernel.org/r/20231204172646.2541916-3-jthoughton@google.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c854188ea01062f5a5fd7f05658feb1863774eaa upstream.
We currently expose the PMU version of the host to the guest via
emulation of the DFR0_EL1 and AA64DFR0_EL1 debug feature registers.
However many of the features offered beyond PMUv3 for 8.1 are not
supported in KVM. Examples of this include support for the PMMIR
registers (added in PMUv3 for ARMv8.4) and 64-bit event counters
added in (PMUv3 for ARMv8.5).
Let's trap the Debug Feature Registers in order to limit
PMUVer/PerfMon in the Debug Feature Registers to PMUv3 for ARMv8.1
to avoid unexpected behaviour.
Both ID_AA64DFR0.PMUVer and ID_DFR0.PerfMon follow the "Alternative ID
scheme used for the Performance Monitors Extension version" where 0xF
means an IMPLEMENTATION DEFINED PMU is implemented, and values 0x0-0xE
are treated as with an unsigned field (with 0x0 meaning no PMU is
present). As we don't expect to expose an IMPLEMENTATION DEFINED PMU,
and our cap is below 0xF, we can treat these fields as unsigned when
applying the cap.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
[Mark: make field names consistent, use perfmon cap]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
[yuzenghui@huawei.com: adjust the context in read_id_reg()]
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8e35aa642ee4dab01b16cc4b2df59d1936f3b3c2 upstream.
When emulating ID registers there is often a need to cap the version
bits of a feature such that the guest will not use features that the
host is not aware of. For example, when KVM mediates access to the PMU
by emulating register accesses.
Let's add a helper that extracts a performance monitors ID field and
caps the version to a given value.
Fields that identify the version of the Performance Monitors Extension
do not follow the standard ID scheme, and instead follow the scheme
described in ARM DDI 0487E.a page D13-2825 "Alternative ID scheme used
for the Performance Monitors Extension version". The value 0xF means an
IMPLEMENTATION DEFINED PMU is present, and values 0x0-OxE can be treated
the same as an unsigned field with 0x0 meaning no PMU is present.
Signed-off-by: Andrew Murray <andrew.murray@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
[Mark: rework to handle perfmon fields]
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
In linux-6.1, the related code is refactored in commit 124c49b1b5d9
("arm64: armv8_deprecated: rework deprected instruction handling") and this
issue was incidentally fixed. I have adapted the patch set to linux stable
5.10. However, 4.19 and 5.10 are too different and the patch set is
hard to adapt to 4.19.
This patch is to solve the problem of repeated addition of linked lists
described below with few changes.
How to reproduce:
CONFIG_ARMV8_DEPRECATED=y, CONFIG_SWP_EMULATION=y, and CONFIG_DEBUG_LIST=y,
then launch two shell executions:
#!/bin/bash
while [ 1 ];
do
echo 1 > /proc/sys/abi/swp
done
or "echo 1 > /proc/sys/abi/swp" and then aunch two shell executions:
#!/bin/bash
while [ 1 ];
do
echo 0 > /proc/sys/abi/swp
done
In emulation_proc_handler(), read and write operations are performed on
insn->current_mode. In the concurrency scenario, mutex only protects
writing insn->current_mode, and not protects the read. Suppose there are
two concurrent tasks, task1 updates insn->current_mode to INSN_EMULATE
in the critical section, the prev_mode of task2 is still the old data
INSN_UNDEF of insn->current_mode. As a result, two tasks call
update_insn_emulation_mode twice with prev_mode = INSN_UNDEF and
current_mode = INSN_EMULATE, then call register_emulation_hooks twice,
resulting in a list_add double problem.
After applying this patch, the following list add or list del double
warnings never occur.
Call trace:
__list_add_valid+0xd8/0xe4
register_undef_hook+0x94/0x13c
update_insn_emulation_mode+0xd0/0x12c
emulation_proc_handler+0xd8/0xf4
proc_sys_call_handler+0x140/0x250
proc_sys_write+0x1c/0x2c
new_sync_write+0xec/0x18c
vfs_write+0x214/0x2ac
ksys_write+0x70/0xfc
__arm64_sys_write+0x24/0x30
el0_svc_common.constprop.0+0x7c/0x1bc
do_el0_svc+0x2c/0x94
el0_svc+0x20/0x30
el0_sync_handler+0xb0/0xb4
el0_sync+0x160/0x180
Call trace:
__list_del_entry_valid+0xac/0x110
unregister_undef_hook+0x34/0x80
update_insn_emulation_mode+0xf0/0x180
emulation_proc_handler+0x8c/0xd8
proc_sys_call_handler+0x1d8/0x208
proc_sys_write+0x14/0x20
new_sync_write+0xf0/0x190
vfs_write+0x304/0x388
ksys_write+0x6c/0x100
__arm64_sys_write+0x1c/0x28
el0_svc_common.constprop.4+0x68/0x188
do_el0_svc+0x24/0xa0
el0_svc+0x14/0x20
el0_sync_handler+0x90/0xb8
el0_sync+0x160/0x180
Fixes: af483947d472 ("arm64: fix oops in concurrently setting insn_emulation sysctls")
Cc: stable@vger.kernel.org#4.19.x
Cc: gregkh@linuxfoundation.org
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit d11a69873d9a7435fe6a48531e165ab80a8b1221 ]
Arm platforms use is_default_overflow_handler() to determine if the
hw_breakpoint code should single-step over the breakpoint trigger or
let the custom handler deal with it.
Since bpf_overflow_handler() currently isn't recognized as a default
handler, attaching a BPF program to a PERF_TYPE_BREAKPOINT event causes
it to keep firing (the instruction triggering the data abort exception
is never skipped). For example:
# bpftrace -e 'watchpoint:0x10000:4:w { print("hit") }' -c ./test
Attaching 1 probe...
hit
hit
[...]
^C
(./test performs a single 4-byte store to 0x10000)
This patch replaces the check with uses_default_overflow_handler(),
which accounts for the bpf_overflow_handler() case by also testing
if one of the perf_event_output functions gets invoked indirectly,
via orig_default_handler.
Signed-off-by: Tomislav Novak <tnovak@meta.com>
Tested-by: Samuel Gosselin <sgosselin@google.com> # arm64
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/linux-arm-kernel/20220923203644.2731604-1-tnovak@fb.com/
Link: https://lore.kernel.org/r/20230605191923.1219974-1-tnovak@meta.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 36541089c4733355ed844c67eebd0c3936953454 ]
The interrupt line was previously not described. Take care of that.
Fixes: 1e39255ed29d ("arm64: dts: msm8996: Add device node for qcom,dwc3")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230627-topic-more_bindings-v1-11-6b4b6cd081e5@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6eb1c8ade5e8665eb97f8416eee0942c9f90b12b ]
Register upper-lower interrupts for each of the two tsens controllers.
Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Andy Gross <agross@kernel.org>
Stable-dep-of: 36541089c473 ("arm64: dts: qcom: msm8996: Add missing interrupt to the USB2 controller")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit db66795f61354c373ecdadbdae1ed253a96c47cb upstream.
The correct dts property for the SCL falling time is
"i2c-scl-falling-time-ns".
Fixes: c8da1d15b8a4 ("arm64: dts: stratix10: i2c clock running out of spec")
Cc: stable@vger.kernel.org
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 1a2c4e5635177939a088d22fa35c6a7032725663 ]
The schematics are misleading, the flow control is for HSCIF1. We need
SCIF1 for GNSS/GPS which does not use flow control.
Fixes: c6c816e22bc8 ("arm64: dts: ulcb-kf: enable SCIF1")
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20230525084823.4195-2-wsa+renesas@sang-engineering.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 8d0f019e4c4f2ee2de81efd9bf1c27e9fb3c0460 ]
Add the missing Set/Way CMOs that apply to tagged memory.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
Link: https://lore.kernel.org/r/20230515204601.1270428-2-maz@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d91d580878064b880f3574ac35b98d8b70ee8620 ]
This patch fixes several sparse warnings for fault.c:
arch/arm64/mm/fault.c:493:24: sparse: warning: incorrect type in return expression (different base types)
arch/arm64/mm/fault.c:493:24: sparse: expected restricted vm_fault_t
arch/arm64/mm/fault.c:493:24: sparse: got int
arch/arm64/mm/fault.c:501:32: sparse: warning: incorrect type in return expression (different base types)
arch/arm64/mm/fault.c:501:32: sparse: expected restricted vm_fault_t
arch/arm64/mm/fault.c:501:32: sparse: got int
arch/arm64/mm/fault.c:503:32: sparse: warning: incorrect type in return expression (different base types)
arch/arm64/mm/fault.c:503:32: sparse: expected restricted vm_fault_t
arch/arm64/mm/fault.c:503:32: sparse: got int
arch/arm64/mm/fault.c:511:24: sparse: warning: incorrect type in return expression (different base types)
arch/arm64/mm/fault.c:511:24: sparse: expected restricted vm_fault_t
arch/arm64/mm/fault.c:511:24: sparse: got int
arch/arm64/mm/fault.c:670:13: sparse: warning: restricted vm_fault_t degrades to integer
arch/arm64/mm/fault.c:670:13: sparse: warning: restricted vm_fault_t degrades to integer
arch/arm64/mm/fault.c:713:39: sparse: warning: restricted vm_fault_t degrades to integer
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Min-Hua Chen <minhuadotchen@gmail.com>
Link: https://lore.kernel.org/r/20230502151909.128810-1-minhuadotchen@gmail.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit af6c0bd59f4f3ad5daad2f7b777954b1954551d5 ]
Currently only the first attempt to single-step has any effect. After
that all further stepping remains "stuck" at the same program counter
value.
Refer to the ARM Architecture Reference Manual (ARM DDI 0487E.a) D2.12,
PSTATE.SS=1 should be set at each step before transferring the PE to the
'Active-not-pending' state. The problem here is PSTATE.SS=1 is not set
since the second single-step.
After the first single-step, the PE transferes to the 'Inactive' state,
with PSTATE.SS=0 and MDSCR.SS=1, thus PSTATE.SS won't be set to 1 due to
kernel_active_single_step()=true. Then the PE transferes to the
'Active-pending' state when ERET and returns to the debugger by step
exception.
Before this patch:
==================
Entering kdb (current=0xffff3376039f0000, pid 1) on processor 0 due to Keyboard Entry
[0]kdb>
[0]kdb>
[0]kdb> bp write_sysrq_trigger
Instruction(i) BP #0 at 0xffffa45c13d09290 (write_sysrq_trigger)
is enabled addr at ffffa45c13d09290, hardtype=0 installed=0
[0]kdb> go
$ echo h > /proc/sysrq-trigger
Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to Breakpoint @ 0xffffad651a309290
[1]kdb> ss
Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to SS trap @ 0xffffad651a309294
[1]kdb> ss
Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to SS trap @ 0xffffad651a309294
[1]kdb>
After this patch:
=================
Entering kdb (current=0xffff6851c39f0000, pid 1) on processor 0 due to Keyboard Entry
[0]kdb> bp write_sysrq_trigger
Instruction(i) BP #0 at 0xffffc02d2dd09290 (write_sysrq_trigger)
is enabled addr at ffffc02d2dd09290, hardtype=0 installed=0
[0]kdb> go
$ echo h > /proc/sysrq-trigger
Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to Breakpoint @ 0xffffc02d2dd09290
[1]kdb> ss
Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd09294
[1]kdb> ss
Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd09298
[1]kdb> ss
Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd0929c
[1]kdb>
Fixes: 44679a4f142b ("arm64: KGDB: Add step debugging support")
Co-developed-by: Wei Li <liwei391@huawei.com>
Signed-off-by: Wei Li <liwei391@huawei.com>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
Link: https://lore.kernel.org/r/20230202073148.657746-3-sumit.garg@linaro.org
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 5d8d4af24460d079ecdb190254b14b528add1228 upstream.
The introduction of the SVE registers to userspace started with a
refactoring of the way we expose any register via the ONE_REG
interface.
Unfortunately, this change doesn't exactly behave as expected
if the number of registers is non-zero and consider everything
to be an error. The visible result is that QEMU barfs very early
when creating vcpus.
Make sure we only exit early in case there is an actual error, rather
than a positive number of registers...
Fixes: be25bbb392fa ("KVM: arm64: Factor out core register ID enumeration")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Takahiro Itazuri <itazur@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit df205b5c63281e4f32caac22adda18fd68795e80 upstream.
Since commit d26c25a9d19b ("arm64: KVM: Tighten guest core register
access from userspace"), KVM_{GET,SET}_ONE_REG rejects register IDs
that do not correspond to a single underlying architectural register.
KVM_GET_REG_LIST was not changed to match however: instead, it
simply yields a list of 32-bit register IDs that together cover the
whole kvm_regs struct. This means that if userspace tries to use
the resulting list of IDs directly to drive calls to KVM_*_ONE_REG,
some of those calls will now fail.
This was not the intention. Instead, iterating KVM_*_ONE_REG over
the list of IDs returned by KVM_GET_REG_LIST should be guaranteed
to work.
This patch fixes the problem by splitting validate_core_offset()
into a backend core_reg_size_from_offset() which does all of the
work except for checking that the size field in the register ID
matches, and kvm_arm_copy_reg_indices() and num_core_regs() are
converted to use this to enumerate the valid offsets.
kvm_arm_copy_reg_indices() now also sets the register ID size field
appropriately based on the value returned, so the register ID
supplied to userspace is fully qualified for use with the register
access ioctls.
Cc: stable@vger.kernel.org
Fixes: d26c25a9d19b ("arm64: KVM: Tighten guest core register access from userspace")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Tested-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Takahiro Itazuri <itazur@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit be25bbb392fad3a721d6d21b78639b60612b5439 upstream.
In preparation for adding logic to filter out some KVM_REG_ARM_CORE
registers from the KVM_GET_REG_LIST output, this patch factors out
the core register enumeration into a separate function and rebuilds
num_core_regs() on top of it.
This may be a little more expensive (depending on how good a job
the compiler does of specialising the code), but KVM_GET_REG_LIST
is not a hot path.
This will make it easier to consolidate ID filtering code in one
place.
No functional change.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Tested-by: zhang.lei <zhang.lei@jp.fujitsu.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Takahiro Itazuri <itazur@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 22925af785fa3470efdf566339616d801119d348 ]
Specify #pwm-cells on pwm@11006000 to make it actually usable.
Fixes: ae457b7679c4 ("arm64: dts: mt7622: add SoC and peripheral related device nodes")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221128112028.58021-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
name
[ Upstream commit d19189f70ba596798ea49166d2d1ef36a8df5289 ]
Fixes:
bus@c8834000: eth-phy-mux: {...} should not be valid under {'type': 'object'}
Link: https://lore.kernel.org/r/20230124-b4-amlogic-bindings-fixups-v1-9-44351528957e@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 61ff70708b98a85516eccb3755084ac97b42cf48 ]
Fixes:
bus@c8834000: rng: {...} should not be valid under {'type': 'object'}
Link: https://lore.kernel.org/r/20230124-b4-amlogic-bindings-fixups-v1-6-44351528957e@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 2ff650051493d5bdb6dd09d4c2850bb37db6be31 ]
Fixes:
scpi: sensors:compatible: 'oneOf' conditional failed, one must be fixed:
['amlogic,meson-gxbb-scpi-sensors'] is too short
'arm,scpi-sensors' was expected
Link: https://lore.kernel.org/r/20230124-b4-amlogic-bindings-fixups-v1-3-44351528957e@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 5b7069d72f03c92a0ab919725017394ebce03a81 ]
Fixes:
scpi: clocks: 'clock-controller' does not match any of the regexes: '^clocks-[0-9a-f]+$', 'pinctrl-[0-9]+'
Link: https://lore.kernel.org/r/20230124-b4-amlogic-bindings-fixups-v1-2-44351528957e@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 2c130695ad5265ce2eb38f55ee0cce26238f7891 ]
Enable SCPI on the axg platform, with cpu clock and hwmon
(core temperature) support
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Stable-dep-of: 5b7069d72f03 ("arm64: dts: amlogic: meson-axg: fix SCPI clock dvfs node name")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 127f79212b07c5d9a6657a87e3eafdd889335814 ]
Fixes:
scpi: clocks: 'clock-controller' does not match any of the regexes: '^clocks-[0-9a-f]+$', 'pinctrl-[0-9]+'
Link: https://lore.kernel.org/r/20230124-b4-amlogic-bindings-fixups-v1-1-44351528957e@linaro.org
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit f189c869ad92787ddd753558bcbae89d75825bb6 ]
Node names should be generic and use hyphens instead of underscores to
not cause warnings. Also nodes without a reg property should not have a
unit-address. Change the scpi_dvfs node to use clock-controller as node
name without a unit address (since it does not have a reg property).
Fixes: 70db166a2baa ("ARM64: dts: meson-gxbb: Add SCPI with cpufreq & sensors Nodes")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20230111211350.1461860-7-martin.blumenstingl@googlemail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 8ed5310356bfa47cc6bb4221ae6b21258c52e3d1 ]
Unit names should use hyphens instead of underscores to not cause
warnings.
Fixes: bfe59f92d306 ("ARM64: dts: amlogic: gxbb: Enable NVMEM")
Suggested-by: Vyacheslav Bocharov <adeep@lexina.in>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20230111211350.1461860-5-martin.blumenstingl@googlemail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit d182bcf300772d8b2e5f43e47fa0ebda2b767cc4 upstream.
The usage of edge-triggered interrupts lead to lost interrupts under load,
see [0]. This was confirmed to be fixed by using level-triggered
interrupts.
The report was about SDIO. However, as the host controller is the same
for SD and MMC, apply the change to all mmc controller instances.
[0] https://www.spinics.net/lists/linux-mmc/msg73991.html
Fixes: 221cf34bac54 ("ARM64: dts: meson-axg: enable the eMMC controller")
Reported-by: Peter Suti <peter.suti@streamunlimited.com>
Tested-by: Vyacheslav Bocharov <adeep@lexina.in>
Tested-by: Peter Suti <peter.suti@streamunlimited.com>
Cc: stable@vger.kernel.org
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/c00655d3-02f8-6f5f-4239-ca2412420cad@gmail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 66e45351f7d6798751f98001d1fcd572024d87f0 upstream.
The usage of edge-triggered interrupts lead to lost interrupts under load,
see [0]. This was confirmed to be fixed by using level-triggered
interrupts.
The report was about SDIO. However, as the host controller is the same
for SD and MMC, apply the change to all mmc controller instances.
[0] https://www.spinics.net/lists/linux-mmc/msg73991.html
Fixes: ef8d2ffedf18 ("ARM64: dts: meson-gxbb: add MMC support")
Cc: stable@vger.kernel.org
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/76e042e0-a610-5ed5-209f-c4d7f879df44@gmail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0e25498f8cd43c1b5aa327f373dd094e9a006da7 upstream.
There are two big uses of do_exit. The first is it's design use to be
the guts of the exit(2) system call. The second use is to terminate
a task after something catastrophic has happened like a NULL pointer
in kernel code.
Add a function make_task_dead that is initialy exactly the same as
do_exit to cover the cases where do_exit is called to handle
catastrophic failure. In time this can probably be reduced to just a
light wrapper around do_task_dead. For now keep it exactly the same so
that there will be no behavioral differences introducing this new
concept.
Replace all of the uses of do_exit that use it for catastraphic
task cleanup with make_task_dead to make it clear what the code
is doing.
As part of this rename rewind_stack_do_exit
rewind_stack_and_make_dead.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 031af50045ea97ed4386eb3751ca2c134d0fc911 ]
The inline assembly for arm64's cmpxchg_double*() implementations use a
+Q constraint to hazard against other accesses to the memory location
being exchanged. However, the pointer passed to the constraint is a
pointer to unsigned long, and thus the hazard only applies to the first
8 bytes of the location.
GCC can take advantage of this, assuming that other portions of the
location are unchanged, leading to a number of potential problems.
This is similar to what we fixed back in commit:
fee960bed5e857eb ("arm64: xchg: hazard against entire exchange variable")
... but we forgot to adjust cmpxchg_double*() similarly at the same
time.
The same problem applies, as demonstrated with the following test:
| struct big {
| u64 lo, hi;
| } __aligned(128);
|
| unsigned long foo(struct big *b)
| {
| u64 hi_old, hi_new;
|
| hi_old = b->hi;
| cmpxchg_double_local(&b->lo, &b->hi, 0x12, 0x34, 0x56, 0x78);
| hi_new = b->hi;
|
| return hi_old ^ hi_new;
| }
... which GCC 12.1.0 compiles as:
| 0000000000000000 <foo>:
| 0: d503233f paciasp
| 4: aa0003e4 mov x4, x0
| 8: 1400000e b 40 <foo+0x40>
| c: d2800240 mov x0, #0x12 // #18
| 10: d2800681 mov x1, #0x34 // #52
| 14: aa0003e5 mov x5, x0
| 18: aa0103e6 mov x6, x1
| 1c: d2800ac2 mov x2, #0x56 // #86
| 20: d2800f03 mov x3, #0x78 // #120
| 24: 48207c82 casp x0, x1, x2, x3, [x4]
| 28: ca050000 eor x0, x0, x5
| 2c: ca060021 eor x1, x1, x6
| 30: aa010000 orr x0, x0, x1
| 34: d2800000 mov x0, #0x0 // #0 <--- BANG
| 38: d50323bf autiasp
| 3c: d65f03c0 ret
| 40: d2800240 mov x0, #0x12 // #18
| 44: d2800681 mov x1, #0x34 // #52
| 48: d2800ac2 mov x2, #0x56 // #86
| 4c: d2800f03 mov x3, #0x78 // #120
| 50: f9800091 prfm pstl1strm, [x4]
| 54: c87f1885 ldxp x5, x6, [x4]
| 58: ca0000a5 eor x5, x5, x0
| 5c: ca0100c6 eor x6, x6, x1
| 60: aa0600a6 orr x6, x5, x6
| 64: b5000066 cbnz x6, 70 <foo+0x70>
| 68: c8250c82 stxp w5, x2, x3, [x4]
| 6c: 35ffff45 cbnz w5, 54 <foo+0x54>
| 70: d2800000 mov x0, #0x0 // #0 <--- BANG
| 74: d50323bf autiasp
| 78: d65f03c0 ret
Notice that at the lines with "BANG" comments, GCC has assumed that the
higher 8 bytes are unchanged by the cmpxchg_double() call, and that
`hi_old ^ hi_new` can be reduced to a constant zero, for both LSE and
LL/SC versions of cmpxchg_double().
This patch fixes the issue by passing a pointer to __uint128_t into the
+Q constraint, ensuring that the compiler hazards against the entire 16
bytes being modified.
With this change, GCC 12.1.0 compiles the above test as:
| 0000000000000000 <foo>:
| 0: f9400407 ldr x7, [x0, #8]
| 4: d503233f paciasp
| 8: aa0003e4 mov x4, x0
| c: 1400000f b 48 <foo+0x48>
| 10: d2800240 mov x0, #0x12 // #18
| 14: d2800681 mov x1, #0x34 // #52
| 18: aa0003e5 mov x5, x0
| 1c: aa0103e6 mov x6, x1
| 20: d2800ac2 mov x2, #0x56 // #86
| 24: d2800f03 mov x3, #0x78 // #120
| 28: 48207c82 casp x0, x1, x2, x3, [x4]
| 2c: ca050000 eor x0, x0, x5
| 30: ca060021 eor x1, x1, x6
| 34: aa010000 orr x0, x0, x1
| 38: f9400480 ldr x0, [x4, #8]
| 3c: d50323bf autiasp
| 40: ca0000e0 eor x0, x7, x0
| 44: d65f03c0 ret
| 48: d2800240 mov x0, #0x12 // #18
| 4c: d2800681 mov x1, #0x34 // #52
| 50: d2800ac2 mov x2, #0x56 // #86
| 54: d2800f03 mov x3, #0x78 // #120
| 58: f9800091 prfm pstl1strm, [x4]
| 5c: c87f1885 ldxp x5, x6, [x4]
| 60: ca0000a5 eor x5, x5, x0
| 64: ca0100c6 eor x6, x6, x1
| 68: aa0600a6 orr x6, x5, x6
| 6c: b5000066 cbnz x6, 78 <foo+0x78>
| 70: c8250c82 stxp w5, x2, x3, [x4]
| 74: 35ffff45 cbnz w5, 5c <foo+0x5c>
| 78: f9400480 ldr x0, [x4, #8]
| 7c: d50323bf autiasp
| 80: ca0000e0 eor x0, x7, x0
| 84: d65f03c0 ret
... sampling the high 8 bytes before and after the cmpxchg, and
performing an EOR, as we'd expect.
For backporting, I've tested this atop linux-4.9.y with GCC 5.5.0. Note
that linux-4.9.y is oldest currently supported stable release, and
mandates GCC 5.1+. Unfortunately I couldn't get a GCC 5.1 binary to run
on my machines due to library incompatibilities.
I've also used a standalone test to check that we can use a __uint128_t
pointer in a +Q constraint at least as far back as GCC 4.8.5 and LLVM
3.9.1.
Fixes: 5284e1b4bc8a ("arm64: xchg: Implement cmpxchg_double")
Fixes: e9a4b795652f ("arm64: cmpxchg_dbl: patch in lse instructions when supported by the CPU")
Reported-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://lore.kernel.org/lkml/Y6DEfQXymYVgL3oJ@boqun-archlinux/
Reported-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/lkml/Y6GXoO4qmH9OIZ5Q@hirez.programming.kicks-ass.net/
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: stable@vger.kernel.org
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Steve Capper <steve.capper@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20230104151626.3262137-1-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
Bruce Ashfield
AngeloGioacchino Del Regno
James Houghton
Andrew Murray
Jinjie Ruan
Tomislav Novak
Konrad Dybcio
Amit Kucheria
Dinh Nguyen
Wolfram Sang
Marc Zyngier
Min-Hua Chen
Sumit Garg
Marc Zyngier
Dave Martin
Neil Armstrong
Jerome Brunet
Martin Blumenstingl
Heiner Kallweit
Eric W. Biederman
Mark Rutland