| Age | Commit message (Collapse) | Author |
|---|
|
This is the 4.19.306 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmWy4ccACgkQONu9yGCS
# aT7XAhAA09gfOmHXHb5ihjjWyBHEEzKLP+tQ3pDsWeZ3i35GzxVqi51LPSeI8dZ8
# znzS42iJbRyUOARItxd9NYcZqLusQNsPcPC7DKPgQ5GzKoG7cPpeG217ZsCKsMlY
# DvlJO5l3GYBoddB+3Mkw1CJ76N7FU63kOBqTFv4tEelnnROdqho5noIPVxMMX8O9
# HDyRiNFpOEGur/p6u3SKP9XHW3V3MUUkXQZEE/BQDoge6HO/719RNaFESmm6aueB
# rzB9leumm0WvYQWZTOuvsn5Hp4DA1swxB52Dd2RI25m8xpkJ1pRErOBK5UH8Wixk
# PC3ynZtdGFFT02rOqYESJcPkL95SVnaFfuzg75fbT0JQ1MviaQO6ih0qfVICzdVm
# 3AIcieVepK1Ki5owZ+9BrBjYzykrDzvk+yXSipeocxn7BS7GTaxsj0XVJds6aQRg
# aDzzU9/r9yBTOQp7cfit9f24mD44vVemCj9vMO1nHjS6QNDlF3/s6BXvIGmEA6+T
# WYn1LRt8B0C9bDKTBhUiWcWfV9/tRMkqh+k60PclEAIDj0rgBxzdN+UneehOU8/u
# l99fAogk05QVXKfpj3pYRakHV7oQUyvRqXvwqiaX57Gq0C+EVepcPfu5EXoxVeiB
# bsP0s5rg559Mp+x+HOJKXIQ39l2Gez1NaGB84f7p6jnI4Wyr9X8=
# =ErsS
# -----END PGP SIGNATURE-----
# gpg: Signature made Thu 25 Jan 2024 05:33:43 PM 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.297 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmU43RMACgkQONu9yGCS
# aT6DURAAlNjp1I2Hi2sO/hvlYcY6vkZHAIDof1SXqJkthU4Chd8fvinjxbHTcuRd
# vYGBB/u+fTjKiyRYFYiK2vLVQsD2YBIuP+bQtK3v1s+62qarGf+ahbFqRRlHIoRR
# dE3rglx7SMITaZPdq4KFuC1etM206+JR0yU7lTcdLocNQRmZv9DEnVTq6SGLebUB
# C0l+CaHy7F1yn1uuBVJi/gJH1+obTHyAViJzKY38E2Nevq8a0rUZd6V0xfGHUFue
# x41NX+pjUkaAyH8qKahFxdIuabE/oNBjt6ZqEmceu2bOrjFI36a3r2/XYfqNxkD8
# HT9qEz+jY0ig2Zj4TdGcjrm58Ck3ZjTS9RBodeaYBYlqz/EnlR8Qk7kspfXGACF9
# iy5WcL0iSMbC3o5dy17k2Dhh6G9ZmhLlpzXuHlLvfM3U1dlO0aa48LhAO7MTNu6N
# Abdyfqv1q4tSqsixUyVe2MQqAoZ7Px1FJRq5l24xvqKljNKFOgBnw9sjKfcRfG1K
# O2F1dvEzLjFNxn7P+iZMfdoyg2Hf+GQ0gtLmq9fK04uAGW8UQRu51efJmujLZ42b
# XVeAI4iw+uR1bFt9YI+WeAx3vg/lzP768+2YPf0zWUDf2k7RORvnP4XUZbddajet
# fhqakuVIORwc53IM5m2XtMs7N88sWFrprbqjyoUPJYcgpzQyyOo=
# =0+07
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 25 Oct 2023 05:17:07 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.296 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmUlqccACgkQONu9yGCS
# aT4gqQ/+MgTjBf9wQ4KfZI5RZaQJhRVuubL58TmHD0HMkGhaQhPgsswQ7Sil5nQ2
# 889+PhxTJ6p9tNFYdYz/urv0qM197vWFOpWvkKqBlLLkHEIU14e7OiLdZuydYPVV
# iyFXNrEr5xVerYo7tTsmuOYNzgArwVxmEa/GNlpy/AJl7uP/wxt5g8sbChziM1k2
# erSmRrBp0tCG2xVjLWx1LEIWqmB11rTuP0Kl5j86THnS5czzCmdQyvWypMDB+M1o
# UX6SF1bFMdvh59ultJQN+SYfq+HSo66xxKNDCRRiqvBi2BvBOYKwnDZYwLuf9H8/
# ELOQ//RbWv42wrhosoj637748CwWlgJQCNYR1RiV09CA/bHqlKDwfZM7sUbzeebM
# 5/Z+ODM/WtJ1/jdbvu1KkkurVLFaKGOmDKefiosZt+4KMXPbyy6jg6J6/moLZqJ8
# hbym4x8n6KWYMBrvxQt9Ukyo/SBkcoFAJfCdks1hqtkEL7L+VAxaC1mfUqcNzhlY
# RXopvFhEoMlBQ2pOQzK1lDy2m3rZS+md5UUO8G+DZ0keerK7oKVLKVstBTBzx++k
# d2SZ7ijRHqqvSfCYbtNrzgBdc06Ou9zT5vOK9KuWR5CQxIwW3NTu23umg7AmMcdT
# WkdxqcpO1YZCCbH9oK40ynbP4Ap0fYzZ0SGIoNuclknGX+NJ1E0=
# =LBDu
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 10 Oct 2023 03:45:11 PM EDT
# 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.293 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTvUuwACgkQONu9yGCS
# aT7LpA/+N7Em43G700yL9LlPAwa6xWE22OMyidakDJfd2pZ/yfi7/rsdCKMpPi4o
# Y+jyax8jj1V473rAM1emBUpy8EMnJD+0Fh/279rO3C0F61wgt8QLU9M+8bb5g/lE
# IWziYXdugRoBsLvp22GYlNT1s/EAd1g5eWrUYkPaL0nZe6p1eF+rFF0+qUCbY77q
# q3jSh3SCeGPn9x3IGBwD7v21dA4ZlpIkbie3Pd8ARSKfeGKKaiRSVNH4xoEcimFt
# 6j13d0VEdJC4Ew5Ir5S0oFHaTsYAR8EcKiJoaPsJ+SAUNh+RH2v3D+t8+oBbXkj5
# JxTRwohL2P9MQAW/xXrArwuKN4PghtJeE3xZGjkwS/wJzuQ0oqxfZwFNsU1p467O
# KkInV+soyD9GoAAzpbGO3GwgP1mybUOpLzS5ERwn43yKgOad6XjYiTw7PIzahgJ7
# gvBrqqOQMFOMrPoLhVzhWnUP9kcVSjvn49HJ9blX0sg5ShDra/q0bs8l9fSIAJnv
# GBZkV7CyqoZNULXjG8/jqlzijf5FpGwTX4mHJ1n2M58CskmXxqRt2bP/KmFzn8j/
# ny3aVIN06c6VTNZ4Cu2h9CC1T4ZW0CNteMzweHMY+0PU8Y3BA+XBQVnQ1F+r+TF5
# hbSxiPB5uYJJFfTkUlf8QMAfC7h1pbxgCy4YsJ1QlEt3Ai8ypo4=
# =gx/M
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 30 Aug 2023 10:32:12 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.290 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmTSgNMACgkQONu9yGCS
# aT7WJRAAne2EBFiKaxX9FLoGJ1+YTcx7QbG1kbxE3pVxSVRRmrGA+9D1L6p1bxlw
# 6oi4l12999o+fL9IZMfKPESrkU2lGeFc9ifwOkDRc2JOpn/Ejq7HBQ6xijs9TTdz
# X8HbHWUWevwGZXkcAbKXDJ7D1y6cVV6K7UxEe4eKbmbpHdaOfS1/KB1WDlfq2pIh
# 32JVcO0+tVn/1HjZNvNRV7qbsnLVmLH6vFEsBhOfSlaDU6Wdi5iF2B3stg7+TMSz
# AnVKT/Gv9LIHse2dmZlcTN1xeGYsmYXlN1JHqJ58X8Bsa/9FARxVDpOUxOlO4B2M
# A4tWi6SguIMeseFBo9iwDFvRG84x7Ht1CoNiTeX5TeBNI+hkcuXMCxKlzdc5JGE/
# Pz7+ryyWreW67VSX4CZfd20Ppm757dZUQ95MacWhhcMcm7HpmQT5dbi0ijHcJbBM
# wvcrU/XGGzAj44yFuhT2u6c0bFLjTn3AdsAnItadYdoIFI6J1akHXM8TC+p9TgW8
# T5D8M+6zDeHJQaQVwhp2Sp2Xjxbp/4L7Hh0tb3YfWcDbFrrWKazl9Bl0D6bvAg0g
# UkPl/yoYPjWraw1SGCegWsHkUVxGaegCLCYRUITmZ+Z7Cajdm87G7MI5wrpl1H0g
# YE8H7xyGevPMsIySdmkU1WGdnxPPE1dq89ZIKCJoi+lfeyI+xd0=
# =GaK6
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 08 Aug 2023 01:52:19 PM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
This is the 4.19.287 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmSS/c0ACgkQONu9yGCS
# aT660BAA1cbdy5pn+U5yYzVs4PktXel3eGZlobJH1/KKkNp4STZhALrnWbpMjMvr
# lYe4HSR7qsPf03+gXiO2q2uo33NiZmtpnwiTYQKuMT5dHGYK+SY+geJhWu5AFTtL
# OYWrJt5M/ZDtx5vnC5RrQ+hKUI3up7n9ZzXvAOb41V1D1aA4GYk9eeC5c7ghx80T
# gOZH+97nc2AhOXKazksV9EFfScBsl11NcGbV4HUjmI1T3Rif/bo6QXzgA3nYMRtr
# miFJax/STYZ9cnvrGH3K6mNth1Of5rLmgoO8HEgd1Xsdz1N/m3SHZdXaln+YAG1n
# c60Q2I/HaNj9a+R+XhXTLWtdDE7ZF3oZGvgX9XucTdv0d8srv4DDetD9/AHcvqxw
# CobKbxM9tFxoPnykpM7hix6tsQv19c/wthYo8yPR0jwcYnWgGX60nDofO2gnCC7M
# ZdkGwjDH5+Hhl8trI16Csf57IUwmswTe+zfNyfi2cr1zxx+0uChP8JPXXUZ0sDi+
# 1pnPrUaJXMhFxoCeIQYRAnEBBChDo9PkPJtJbqJijjdufrJDAJvL0KSA0Ue9DB9q
# L/A0idYIvfT9d/WJhoLRGLVPhf8nzivBUjtsdHuE3Yu8Pdm476sxNil2NfHWPDRI
# SclcA7+nG1ZXD3W5Fd5Le7msLCztOevpQfzaRtvywtM8j4hsr8o=
# =94Sv
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 21 Jun 2023 09:40:29 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.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.274 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmP56E4ACgkQONu9yGCS
# aT5TjQ//fjhU2pECdzAsZ0GCnXqMfVgdUQtvPfzU16cHqhDcAZORuX4bgn1SuGZq
# VOWjfTED2zYtd/dffM2J0eGssSQk2nYtCiMPhweeOITyP4bIGWpScYGuO7rdJFRY
# 8AKUscMnIvH5y7cA8oMH/O/LlBD2JWEc5xBfSym99JICTrFOKvKKxWTbHPJS40/m
# Ppw4UVX229/ZgeSvrxIQ3ZCn74R90Wb60ZohaXp7uN9nIE1gjkk75l8Whhoaf4L6
# JuTZBdun1lY/nM/mhvw2efOzHEiobJZZkROKWHjJuEzTq0ZodV8wUaY/SSgBgDLh
# UDgzohjW/2pcEdlHCY+zkhTD4+UR7WlRP8y4XlMtMAtlg099Y6L1iO3aGTBdt/Ix
# Lkfk+CbjhWWqYIiatnT2XM6XJsqCLJVOueGbAUlTpctyzYdogqUML3Mp89t2EATV
# coqmVXULB7wYXn7iU5hDGtidmYB6fyADyT3SCezTEZ9u/Cqity3QRniWMyJxttfr
# RjLjAZx9GqFVVjAhaoOkc+PtEcxgZvimcu0t/9fixg551ssVfPJdikA4QrOlLoDK
# THZc8zJb8xeJakG+r/PMsJadwRuarTXQiNy2/HTrkn23APkxLZribG3ZKjpGL6t7
# S7q0ZU5pXtQhvqooFC4iS+l3QXZirSP97i6szQmWcmjcOPiViSg=
# =HaZo
# -----END PGP SIGNATURE-----
# gpg: Signature made Sat 25 Feb 2023 05:51:58 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.262 stable release
# -----BEGIN PGP SIGNATURE-----
#
# iQIzBAABCAAdFiEEZH8oZUiU471FcZm+ONu9yGCSaT4FAmNZGCIACgkQONu9yGCS
# aT5dEQ//Q2YBvqn1WGhMJRRtIYeczfwvLh3b5duyt1nbf7KOA7yrjpmaQvszunLj
# FanBKsf9QrekTxMUJ9++RlFQy/pxkexy39P3ddlE+QQnKeY+lBr5fc/XSBOmmvm+
# f1CInT4C6nRRn/r/vCumGfuhZ6o+BLwPPgkTCOs9ima6iaq7nLqgFquznVQ2XFJG
# SCtS+OPjnoH7HMOw9vXefd53KJJj5kpE+2fMnEBjdW7x4mPM6nwY3ZxB8sIUdLXe
# dtfDku6W1I8qnGSnI0B+I8/4psNYr/7j4UVTgEKSGmlKKzc78qypdX8YiOGExa84
# MWQrEcIGBOzOaMt5F5RWbGbQmwDtlZC2yuTc5YeJ1eSZ6WfZ42rRu+SkMgloRpjO
# bCzKI8bZ6jmRFNeAPSuR9sF/fRrXlgPsszWYALwy9TTPMvG33jrJaiGwYCOuRxP/
# Fn9C1AshGI+Yy7pX5PR+yOWeII4fgwFBo3Oxritm0RG31KZoXKsrVdyb5CwAD0Sf
# VMb4SNapWwjWKOqi39jAzxgmvkFAwv99HC77dLZhTzwsW+c0+8CH0ccpX/V9997v
# i2IfCLEoOODlpjjoEgeoZ1lwOSX4/cSrlO4L7qcw+vkmXplEkOnD5Lj5Sdw+m9Hp
# 1uwQGVZyngK/eMxInDLlrOFY9SOASCIs+XjJpzqimXp1cTLLEHM=
# =2I2l
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 26 Oct 2022 07:21:06 AM EDT
# gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E
# gpg: Can't check signature: No public key
|
|
[ Upstream commit 0a233867a39078ebb0f575e2948593bbff5826b3 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
Fixes: 885dcd709ba9 ("powerpc/perf: Add nest IMC PMU support")
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231126093719.1440305-1-chentao@kylinos.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 8649829a1dd25199bbf557b2621cedb4bf9b3050 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
Fixes: 2717a33d6074 ("powerpc/opal-irqchip: Use interrupt names if present")
Signed-off-by: Kunwu Chan <chentao@kylinos.cn>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231127030755.1546750-1-chentao@kylinos.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5 ]
dlpar_memory_remove_by_index() may access beyond the bounds of the
drmem lmb array when the LMB lookup fails to match an entry with the
given DRC index. When the search fails, the cursor is left pointing to
&drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the
last valid entry in the array. The debug message at the end of the
function then dereferences this pointer:
pr_debug("Failed to hot-remove memory at %llx\n",
lmb->base_addr);
This was found by inspection and confirmed with KASAN:
pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234
==================================================================
BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658
Read of size 8 at addr c000000364e97fd0 by task bash/949
dump_stack_lvl+0xa4/0xfc (unreliable)
print_report+0x214/0x63c
kasan_report+0x140/0x2e0
__asan_load8+0xa8/0xe0
dlpar_memory+0x298/0x1658
handle_dlpar_errorlog+0x130/0x1d0
dlpar_store+0x18c/0x3e0
kobj_attr_store+0x68/0xa0
sysfs_kf_write+0xc4/0x110
kernfs_fop_write_iter+0x26c/0x390
vfs_write+0x2d4/0x4e0
ksys_write+0xac/0x1a0
system_call_exception+0x268/0x530
system_call_vectored_common+0x15c/0x2ec
Allocated by task 1:
kasan_save_stack+0x48/0x80
kasan_set_track+0x34/0x50
kasan_save_alloc_info+0x34/0x50
__kasan_kmalloc+0xd0/0x120
__kmalloc+0x8c/0x320
kmalloc_array.constprop.0+0x48/0x5c
drmem_init+0x2a0/0x41c
do_one_initcall+0xe0/0x5c0
kernel_init_freeable+0x4ec/0x5a0
kernel_init+0x30/0x1e0
ret_from_kernel_user_thread+0x14/0x1c
The buggy address belongs to the object at c000000364e80000
which belongs to the cache kmalloc-128k of size 131072
The buggy address is located 0 bytes to the right of
allocated 98256-byte region [c000000364e80000, c000000364e97fd0)
==================================================================
pseries-hotplug-mem: Failed to hot-remove memory at 0
Log failed lookups with a separate message and dereference the
cursor only when it points to a valid entry.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Fixes: 51925fb3c5c9 ("powerpc/pseries: Implement memory hotplug remove in the kernel")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231114-pseries-memhp-fixes-v1-1-fb8f2bb7c557@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 20e9de85edae3a5866f29b6cce87c9ec66d62a1b ]
When attempting to remove by index a set of LMBs a lot of messages are
displayed on the console, even when everything goes fine:
pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 8000002d
Offlined Pages 4096
pseries-hotplug-mem: Memory at 2d0000000 was hot-removed
The 2 messages prefixed by "pseries-hotplug-mem" are not really
helpful for the end user, they should be debug outputs.
In case of error, because some of the LMB's pages couldn't be
offlined, the following is displayed on the console:
pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 8000003e
pseries-hotplug-mem: Failed to hot-remove memory at 3e0000000
dlpar: Could not handle DLPAR request "memory remove index 0x8000003e"
Again, the 2 messages prefixed by "pseries-hotplug-mem" are useless,
and the generic DLPAR prefixed message should be enough.
These 2 first changes are mainly triggered by the changes introduced
in drmgr:
https://groups.google.com/g/powerpc-utils-devel/c/Y6ef4NB3EzM/m/9cu5JHRxAQAJ
Also, when adding a bunch of LMBs, a message is displayed in the console per LMB
like these ones:
pseries-hotplug-mem: Memory at 7e0000000 (drc index 8000007e) was hot-added
pseries-hotplug-mem: Memory at 7f0000000 (drc index 8000007f) was hot-added
pseries-hotplug-mem: Memory at 800000000 (drc index 80000080) was hot-added
pseries-hotplug-mem: Memory at 810000000 (drc index 80000081) was hot-added
When adding 1TB of memory and LMB size is 256MB, this leads to 4096
messages to be displayed on the console. These messages are not really
helpful for the end user, so moving them to the DEBUG level.
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
[mpe: Tweak change log wording]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20201211145954.90143-1-ldufour@linux.ibm.com
Stable-dep-of: bd68ffce69f6 ("powerpc/pseries/memhp: Fix access beyond end of drmem array")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 4a74197b65e69c46fe6e53f7df2f4d6ce9ffe012 ]
Fix build errors when CURRITUCK=y and I2C is not builtin (=m or is
not set). Fixes these build errors:
powerpc-linux-ld: arch/powerpc/platforms/44x/ppc476.o: in function `avr_halt_system':
ppc476.c:(.text+0x58): undefined reference to `i2c_smbus_write_byte_data'
powerpc-linux-ld: arch/powerpc/platforms/44x/ppc476.o: in function `ppc47x_device_probe':
ppc476.c:(.init.text+0x18): undefined reference to `i2c_register_driver'
Fixes: 2a2c74b2efcb ("IBM Akebono: Add the Akebono platform")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Closes: lore.kernel.org/r/202312010820.cmdwF5X9-lkp@intel.com
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231201055159.8371-1-rdunlap@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 719736e1cc12b2fc28eba2122893a449eee66d08 ]
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:
...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:
config FOO
bool
config FOO
bool
default n
With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Stable-dep-of: 4a74197b65e6 ("powerpc/44x: select I2C for CURRITUCK")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 1b1e38002648819c04773647d5242990e2824264 ]
crtsavres.o is linked to modules. However, as explained in commit
d0e628cd817f ("kbuild: doc: clarify the difference between extra-y
and always-y"), 'make modules' does not build extra-y.
For example, the following command fails:
$ make ARCH=powerpc LLVM=1 KBUILD_MODPOST_WARN=1 mrproper ps3_defconfig modules
[snip]
LD [M] arch/powerpc/platforms/cell/spufs/spufs.ko
ld.lld: error: cannot open arch/powerpc/lib/crtsavres.o: No such file or directory
make[3]: *** [scripts/Makefile.modfinal:56: arch/powerpc/platforms/cell/spufs/spufs.ko] Error 1
make[2]: *** [Makefile:1844: modules] Error 2
make[1]: *** [/home/masahiro/workspace/linux-kbuild/Makefile:350: __build_one_by_one] Error 2
make: *** [Makefile:234: __sub-make] Error 2
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Fixes: baa25b571a16 ("powerpc/64: Do not link crtsavres.o in vmlinux")
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231120232332.4100288-1-masahiroy@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 4b3338aaa74d7d4ec5b6734dc298f0db94ec83d2 upstream.
Commit 41a506ef71eb ("powerpc/ftrace: Create a dummy stackframe to fix
stack unwind") added use of a new stack frame on ftrace entry to fix
stack unwind. However, the commit missed updating the offset used while
tearing down the ftrace stack when ftrace is disabled. Fix the same.
In addition, the commit missed saving the correct stack pointer in
pt_regs. Update the same.
Fixes: 41a506ef71eb ("powerpc/ftrace: Create a dummy stackframe to fix stack unwind")
Cc: stable@vger.kernel.org # v6.5+
Signed-off-by: Naveen N Rao <naveen@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20231130065947.2188860-1-naveen@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 41a506ef71eb38d94fe133f565c87c3e06ccc072 upstream.
With ppc64 -mprofile-kernel and ppc32 -pg, profiling instructions to
call into ftrace are emitted right at function entry. The instruction
sequence used is minimal to reduce overhead. Crucially, a stackframe is
not created for the function being traced. This breaks stack unwinding
since the function being traced does not have a stackframe for itself.
As such, it never shows up in the backtrace:
/sys/kernel/debug/tracing # echo 1 > /proc/sys/kernel/stack_tracer_enabled
/sys/kernel/debug/tracing # cat stack_trace
Depth Size Location (17 entries)
----- ---- --------
0) 4144 32 ftrace_call+0x4/0x44
1) 4112 432 get_page_from_freelist+0x26c/0x1ad0
2) 3680 496 __alloc_pages+0x290/0x1280
3) 3184 336 __folio_alloc+0x34/0x90
4) 2848 176 vma_alloc_folio+0xd8/0x540
5) 2672 272 __handle_mm_fault+0x700/0x1cc0
6) 2400 208 handle_mm_fault+0xf0/0x3f0
7) 2192 80 ___do_page_fault+0x3e4/0xbe0
8) 2112 160 do_page_fault+0x30/0xc0
9) 1952 256 data_access_common_virt+0x210/0x220
10) 1696 400 0xc00000000f16b100
11) 1296 384 load_elf_binary+0x804/0x1b80
12) 912 208 bprm_execve+0x2d8/0x7e0
13) 704 64 do_execveat_common+0x1d0/0x2f0
14) 640 160 sys_execve+0x54/0x70
15) 480 64 system_call_exception+0x138/0x350
16) 416 416 system_call_common+0x160/0x2c4
Fix this by having ftrace create a dummy stackframe for the function
being traced. With this, backtraces now capture the function being
traced:
/sys/kernel/debug/tracing # cat stack_trace
Depth Size Location (17 entries)
----- ---- --------
0) 3888 32 _raw_spin_trylock+0x8/0x70
1) 3856 576 get_page_from_freelist+0x26c/0x1ad0
2) 3280 64 __alloc_pages+0x290/0x1280
3) 3216 336 __folio_alloc+0x34/0x90
4) 2880 176 vma_alloc_folio+0xd8/0x540
5) 2704 416 __handle_mm_fault+0x700/0x1cc0
6) 2288 96 handle_mm_fault+0xf0/0x3f0
7) 2192 48 ___do_page_fault+0x3e4/0xbe0
8) 2144 192 do_page_fault+0x30/0xc0
9) 1952 608 data_access_common_virt+0x210/0x220
10) 1344 16 0xc0000000334bbb50
11) 1328 416 load_elf_binary+0x804/0x1b80
12) 912 64 bprm_execve+0x2d8/0x7e0
13) 848 176 do_execveat_common+0x1d0/0x2f0
14) 672 192 sys_execve+0x54/0x70
15) 480 64 system_call_exception+0x138/0x350
16) 416 416 system_call_common+0x160/0x2c4
This results in two additional stores in the ftrace entry code, but
produces reliable backtraces.
Fixes: 153086644fd1 ("powerpc/ftrace: Add support for -mprofile-kernel ftrace ABI")
Cc: stable@vger.kernel.org
Signed-off-by: Naveen N Rao <naveen@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230621051349.759567-1-naveen@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5e1d824f9a283cbf90f25241b66d1f69adb3835b upstream.
During floating point and vector save to thread data f0/vs0 are
clobbered by the FPSCR/VSCR store routine. This has been obvserved to
lead to userspace register corruption and application data corruption
with io-uring.
Fix it by restoring f0/vs0 after FPSCR/VSCR store has completed for
all the FP, altivec, VMX register save paths.
Tested under QEMU in kvm mode, running on a Talos II workstation with
dual POWER9 DD2.2 CPUs.
Additional detail (mpe):
Typically save_fpu() is called from __giveup_fpu() which saves the FP
regs and also *turns off FP* in the tasks MSR, meaning the kernel will
reload the FP regs from the thread struct before letting the task use FP
again. So in that case save_fpu() is free to clobber f0 because the FP
regs no longer hold live values for the task.
There is another case though, which is the path via:
sys_clone()
...
copy_process()
dup_task_struct()
arch_dup_task_struct()
flush_all_to_thread()
save_all()
That path saves the FP regs but leaves them live. That's meant as an
optimisation for a process that's using FP/VSX and then calls fork(),
leaving the regs live means the parent process doesn't have to take a
fault after the fork to get its FP regs back. The optimisation was added
in commit 8792468da5e1 ("powerpc: Add the ability to save FPU without
giving it up").
That path does clobber f0, but f0 is volatile across function calls,
and typically programs reach copy_process() from userspace via a syscall
wrapper function. So in normal usage f0 being clobbered across a
syscall doesn't cause visible data corruption.
But there is now a new path, because io-uring can call copy_process()
via create_io_thread() from the signal handling path. That's OK if the
signal is handled as part of syscall return, but it's not OK if the
signal is handled due to some other interrupt.
That path is:
interrupt_return_srr_user()
interrupt_exit_user_prepare()
interrupt_exit_user_prepare_main()
do_notify_resume()
get_signal()
task_work_run()
create_worker_cb()
create_io_worker()
copy_process()
dup_task_struct()
arch_dup_task_struct()
flush_all_to_thread()
save_all()
if (tsk->thread.regs->msr & MSR_FP)
save_fpu()
# f0 is clobbered and potentially live in userspace
Note the above discussion applies equally to save_altivec().
Fixes: 8792468da5e1 ("powerpc: Add the ability to save FPU without giving it up")
Cc: stable@vger.kernel.org # v4.6+
Closes: https://lore.kernel.org/all/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/
Closes: https://lore.kernel.org/linuxppc-dev/480221078.47953493.1700206777956.JavaMail.zimbra@raptorengineeringinc.com/
Tested-by: Timothy Pearson <tpearson@raptorengineering.com>
Tested-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
[mpe: Reword change log to describe exact path of corruption & other minor tweaks]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/1921539696.48534988.1700407082933.JavaMail.zimbra@raptorengineeringinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 5ea0bbaa32e8f54e9a57cfee4a3b8769b80be0d2 ]
Commit 45201c879469 ("powerpc/nohash: Remove hash related code from
nohash headers.") replaced:
if ((pte_val(*ptep) & (_PAGE_ACCESSED | _PAGE_HASHPTE)) == 0)
return 0;
By:
if (pte_young(*ptep))
return 0;
But it should be:
if (!pte_young(*ptep))
return 0;
Fix it.
Fixes: 45201c879469 ("powerpc/nohash: Remove hash related code from nohash headers.")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/8bb7f06494e21adada724ede47a4c3d97e879d40.1695659959.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 4ff3ba4db5943cac1045e3e4a3c0463ea10f6930 ]
Valid domain value is in range 1 to HV_PERF_DOMAIN_MAX. Current code has
check for domain value greater than or equal to HV_PERF_DOMAIN_MAX. But
the check for domain value 0 is missing.
Fix this issue by adding check for domain value 0.
Before:
# ./perf stat -v -e hv_24x7/CPM_ADJUNCT_INST,domain=0,core=1/ sleep 1
Using CPUID 00800200
Control descriptor is not initialized
Error:
The sys_perf_event_open() syscall returned with 5 (Input/output error) for
event (hv_24x7/CPM_ADJUNCT_INST,domain=0,core=1/).
/bin/dmesg | grep -i perf may provide additional information.
Result from dmesg:
[ 37.819387] hv-24x7: hcall failed: [0 0x60040000 0x100 0] => ret
0xfffffffffffffffc (-4) detail=0x2000000 failing ix=0
After:
# ./perf stat -v -e hv_24x7/CPM_ADJUNCT_INST,domain=0,core=1/ sleep 1
Using CPUID 00800200
Control descriptor is not initialized
Warning:
hv_24x7/CPM_ADJUNCT_INST,domain=0,core=1/ event is not supported by the kernel.
failed to read counter hv_24x7/CPM_ADJUNCT_INST,domain=0,core=1/
Fixes: ebd4a5a3ebd9 ("powerpc/perf/hv-24x7: Minor improvements")
Reported-by: Krishan Gopal Sarawast <krishang@linux.vnet.ibm.com>
Signed-off-by: Kajol Jain <kjain@linux.ibm.com>
Tested-by: Disha Goel <disgoel@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230825055601.360083-1-kjain@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit afda85b963c12947e298ad85d757e333aa40fd74 ]
If device_register() returns error in ibmebus_bus_init(), name of kobject
which is allocated in dev_set_name() called in device_add() is leaked.
As comment of device_add() says, it should call put_device() to drop
the reference count that was set in device_initialize() when it fails,
so the name can be freed in kobject_cleanup().
Signed-off-by: ruanjinjie <ruanjinjie@huawei.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20221110011929.3709774-1-ruanjinjie@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c37b6908f7b2bd24dcaaf14a180e28c9132b9c58 ]
fail_iommu_setup() registers the fail_iommu_bus_notifier struct to both
PCI and VIO buses. struct notifier_block is a linked list node, so this
causes any notifiers later registered to either bus type to also be
registered to the other since they share the same node.
This causes issues in (at least) the vgaarb code, which registers a
notifier for PCI buses. pci_notify() ends up being called on a vio
device, converted with to_pci_dev() even though it's not a PCI device,
and finally makes a bad access in vga_arbiter_add_pci_device() as
discovered with KASAN:
BUG: KASAN: slab-out-of-bounds in vga_arbiter_add_pci_device+0x60/0xe00
Read of size 4 at addr c000000264c26fdc by task swapper/0/1
Call Trace:
dump_stack_lvl+0x1bc/0x2b8 (unreliable)
print_report+0x3f4/0xc60
kasan_report+0x244/0x698
__asan_load4+0xe8/0x250
vga_arbiter_add_pci_device+0x60/0xe00
pci_notify+0x88/0x444
notifier_call_chain+0x104/0x320
blocking_notifier_call_chain+0xa0/0x140
device_add+0xac8/0x1d30
device_register+0x58/0x80
vio_register_device_node+0x9ac/0xce0
vio_bus_scan_register_devices+0xc4/0x13c
__machine_initcall_pseries_vio_device_init+0x94/0xf0
do_one_initcall+0x12c/0xaa8
kernel_init_freeable+0xa48/0xba8
kernel_init+0x64/0x400
ret_from_kernel_thread+0x5c/0x64
Fix this by creating separate notifier_block structs for each bus type.
Fixes: d6b9a81b2a45 ("powerpc: IOMMU fault injection")
Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Russell Currey <ruscur@russell.cc>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
[mpe: Add #ifdef to fix CONFIG_IBMVIO=n build]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230322035322.328709-1-ruscur@russell.cc
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit b51ba4fe2e134b631f9c8f45423707aab71449b5 upstream.
The assembler says:
arch/powerpc/kernel/head_32.S:1095: Warning: invalid register expression
It's objecting to the use of r0 as the RA argument. That's because
when RA = 0 the literal value 0 is used, rather than the content of
r0, making the use of r0 in the source potentially confusing.
Fix it to use a literal 0, the generated code is identical.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/2b69ac8e1cddff6f808fc7415907179eab4aae9e.1596693679.git.christophe.leroy@csgroup.eu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 98ecc6768e8fdba95da1fc1efa0ef2d769e7fe1c upstream.
When building a 32 bit powerpc kernel with Binutils 2.31.1 this warning
is emitted:
powerpc-linux-gnu-ld: warning: orphan section `.branch_lt' from
`arch/powerpc/kernel/head_44x.o' being placed in section `.branch_lt'
As of binutils commit 2d7ad24e8726 ("Support PLT16 relocs against local
symbols")[1], 32 bit targets can produce .branch_lt sections in their
output.
Include these symbols in the .data section as the ppc64 kernel does.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2d7ad24e8726ba4c45c9e67be08223a146a837ce
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Alan Modra <amodra@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 25ea739ea1d4d3de41acc4f4eb2d1a97eee0eb75 ]
binutils v2.37 drops unused section symbols, which prevents recordmcount
from capturing mcount locations in sections that have no non-weak
symbols. This results in a build failure with a message such as:
Cannot find symbol for section 12: .text.perf_callchain_kernel.
kernel/events/callchain.o: failed
The change to binutils was reverted for v2.38, so this behavior is
specific to binutils v2.37:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c09c8b42021180eee9495bd50d8b35e683d3901b
Objtool is able to cope with such sections, so this issue is specific to
recordmcount.
Fail the build and print a warning if binutils v2.37 is detected and if
we are using recordmcount.
Cc: stable@vger.kernel.org
Suggested-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Naveen N Rao <naveen@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230530061436.56925-1-naveen@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit bad96de8d31ba65dc26645af5550135315ea0b19 ]
Clean up the leftover of commit f2910f0e6835 ("powerpc: remove old
GCC version checks").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Stable-dep-of: 25ea739ea1d4 ("powerpc: Fail build if using recordmcount with binutils v2.37")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c3ff2a5193fa61b1b284cfb1d79628814ed0e95a ]
This functionality was tentatively added in the past
(commit 6533b7c16ee5 ("powerpc: Initial stack protector
(-fstack-protector) support")) but had to be reverted
(commit f2574030b0e3 ("powerpc: Revert the initial stack
protector support") because of GCC implementing it differently
whether it had been built with libc support or not.
Now, GCC offers the possibility to manually set the
stack-protector mode (global or tls) regardless of libc support.
This time, the patch selects HAVE_STACKPROTECTOR only if
-mstack-protector-guard=tls is supported by GCC.
On PPC32, as register r2 points to current task_struct at
all time, the stack_canary located inside task_struct can be
used directly by using the following GCC options:
-mstack-protector-guard=tls
-mstack-protector-guard-reg=r2
-mstack-protector-guard-offset=offsetof(struct task_struct, stack_canary))
The protector is disabled for prom_init and bootx_init as
it is too early to handle it properly.
$ echo CORRUPT_STACK > /sys/kernel/debug/provoke-crash/DIRECT
[ 134.943666] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: lkdtm_CORRUPT_STACK+0x64/0x64
[ 134.943666]
[ 134.955414] CPU: 0 PID: 283 Comm: sh Not tainted 4.18.0-s3k-dev-12143-ga3272be41209 #835
[ 134.963380] Call Trace:
[ 134.965860] [c6615d60] [c001f76c] panic+0x118/0x260 (unreliable)
[ 134.971775] [c6615dc0] [c001f654] panic+0x0/0x260
[ 134.976435] [c6615dd0] [c032c368] lkdtm_CORRUPT_STACK_STRONG+0x0/0x64
[ 134.982769] [c6615e00] [ffffffff] 0xffffffff
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Stable-dep-of: 25ea739ea1d4 ("powerpc: Fail build if using recordmcount with binutils v2.37")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 4f3175979e62de3b929bfa54a0db4b87d36257a7 upstream.
With hardened usercopy enabled (CONFIG_HARDENED_USERCOPY=y), using the
/proc/powerpc/rtas/firmware_update interface to prepare a system
firmware update yields a BUG():
kernel BUG at mm/usercopy.c:102!
Oops: Exception in kernel mode, sig: 5 [#1]
LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 2232 Comm: dd Not tainted 6.5.0-rc3+ #2
Hardware name: IBM,8408-E8E POWER8E (raw) 0x4b0201 0xf000004 of:IBM,FW860.50 (SV860_146) hv:phyp pSeries
NIP: c0000000005991d0 LR: c0000000005991cc CTR: 0000000000000000
REGS: c0000000148c76a0 TRAP: 0700 Not tainted (6.5.0-rc3+)
MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 24002242 XER: 0000000c
CFAR: c0000000001fbd34 IRQMASK: 0
[ ... GPRs omitted ... ]
NIP usercopy_abort+0xa0/0xb0
LR usercopy_abort+0x9c/0xb0
Call Trace:
usercopy_abort+0x9c/0xb0 (unreliable)
__check_heap_object+0x1b4/0x1d0
__check_object_size+0x2d0/0x380
rtas_flash_write+0xe4/0x250
proc_reg_write+0xfc/0x160
vfs_write+0xfc/0x4e0
ksys_write+0x90/0x160
system_call_exception+0x178/0x320
system_call_common+0x160/0x2c4
The blocks of the firmware image are copied directly from user memory
to objects allocated from flash_block_cache, so flash_block_cache must
be created using kmem_cache_create_usercopy() to mark it safe for user
access.
Fixes: 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
[mpe: Trim and indent oops]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230810-rtas-flash-vs-hardened-usercopy-v2-1-dcf63793a938@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 66b2ca086210732954a7790d63d35542936fc664 ]
It was reported that soft dirty tracking doesn't work when using the
Radix MMU.
The tracking is supposed to work by clearing the soft dirty bit for a
mapping and then write protecting the PTE. If/when the page is written
to, a page fault occurs and the soft dirty bit is added back via
pte_mkdirty(). For example in wp_page_reuse():
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
if (ptep_set_access_flags(vma, vmf->address, vmf->pte, entry, 1))
update_mmu_cache(vma, vmf->address, vmf->pte);
Unfortunately on radix _PAGE_SOFTDIRTY is being dropped by
radix__ptep_set_access_flags(), called from ptep_set_access_flags(),
meaning the soft dirty bit is not set even though the page has been
written to.
Fix it by adding _PAGE_SOFTDIRTY to the set of bits that are able to be
changed in radix__ptep_set_access_flags().
Fixes: b0b5e9b13047 ("powerpc/mm/radix: Add radix pte #defines")
Cc: stable@vger.kernel.org # v4.7+
Reported-by: Dan Horák <dan@danny.cz>
Link: https://lore.kernel.org/r/20230511095558.56663a50f86bdc4cd97700b7@danny.cz
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230511114224.977423-1-mpe@ellerman.id.au
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e66c3209c7fd17209ccc4cbbee8b1b1bd5c438dd ]
This patch moves the files related to page table dump in a
dedicated subdirectory.
The purpose is to clean a bit arch/powerpc/mm by regrouping
multiple files handling a dedicated function.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
[mpe: Shorten the file names while we're at it]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Stable-dep-of: 66b2ca086210 ("powerpc/64s/radix: Fix soft dirty tracking")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 7c91efce1608325634494b25ff6491320208e457 ]
This patch adds a debugfs file to dump block address translation:
~# cat /sys/kernel/debug/powerpc/block_address_translation
---[ Instruction Block Address Translations ]---
0: -
1: -
2: 0xc0000000-0xcfffffff 0x00000000 Kernel EXEC coherent
3: 0xd0000000-0xdfffffff 0x10000000 Kernel EXEC coherent
4: -
5: -
6: -
7: -
---[ Data Block Address Translations ]---
0: -
1: -
2: 0xc0000000-0xcfffffff 0x00000000 Kernel RW coherent
3: 0xd0000000-0xdfffffff 0x10000000 Kernel RW coherent
4: -
5: -
6: -
7: -
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Stable-dep-of: 66b2ca086210 ("powerpc/64s/radix: Fix soft dirty tracking")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 0261a508c9fcb33e60f09cac42032f85c31e2039 ]
This patch creates a debugfs file to see content of
segment registers
# cat /sys/kernel/debug/segment_registers
---[ User Segments ]---
0x00000000-0x0fffffff Kern key 1 User key 1 VSID 0xade2b0
0x10000000-0x1fffffff Kern key 1 User key 1 VSID 0xade3c1
0x20000000-0x2fffffff Kern key 1 User key 1 VSID 0xade4d2
0x30000000-0x3fffffff Kern key 1 User key 1 VSID 0xade5e3
0x40000000-0x4fffffff Kern key 1 User key 1 VSID 0xade6f4
0x50000000-0x5fffffff Kern key 1 User key 1 VSID 0xade805
0x60000000-0x6fffffff Kern key 1 User key 1 VSID 0xade916
0x70000000-0x7fffffff Kern key 1 User key 1 VSID 0xadea27
0x80000000-0x8fffffff Kern key 1 User key 1 VSID 0xadeb38
0x90000000-0x9fffffff Kern key 1 User key 1 VSID 0xadec49
0xa0000000-0xafffffff Kern key 1 User key 1 VSID 0xaded5a
0xb0000000-0xbfffffff Kern key 1 User key 1 VSID 0xadee6b
---[ Kernel Segments ]---
0xc0000000-0xcfffffff Kern key 0 User key 1 VSID 0x000ccc
0xd0000000-0xdfffffff Kern key 0 User key 1 VSID 0x000ddd
0xe0000000-0xefffffff Kern key 0 User key 1 VSID 0x000eee
0xf0000000-0xffffffff Kern key 0 User key 1 VSID 0x000fff
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
[mpe: Move it under /sys/kernel/debug/powerpc, make sr_init() __init]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Stable-dep-of: 66b2ca086210 ("powerpc/64s/radix: Fix soft dirty tracking")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d09780f3a8d48fd49136d7bae8f0ae30de7f261a ]
This patch move pgtable_t into platform headers.
It gets rid of the CONFIG_PPC_64K_PAGES case for PPC64
as nohash/64 doesn't support CONFIG_PPC_64K_PAGES.
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Stable-dep-of: 66b2ca086210 ("powerpc/64s/radix: Fix soft dirty tracking")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 994da93d196866f914c9d64aafb86e95e3decbb2 ]
The purpose of this patch is to move platform specific
mmu-xxx.h files in platform directories like pte-xxx.h files.
In the meantime this patch creates common nohash and
nohash/32 + nohash/64 mmu.h files for future common parts.
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Stable-dep-of: 66b2ca086210 ("powerpc/64s/radix: Fix soft dirty tracking")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6722b25712054c0f903b839b8f5088438dd04df3 ]
altmap->free includes the entire free space from which altmap blocks
can be allocated. So when checking whether the kernel is doing altmap
block free, compute the boundary correctly, otherwise memory hotunplug
can fail.
Fixes: 9ef34630a461 ("powerpc/mm: Fallback to RAM if the altmap is unusable")
Signed-off-by: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230724181320.471386-1-aneesh.kumar@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 79e8328e5acbe691bbde029a52c89d70dcbc22f3 ]
Compiling big-endian targets with Clang produces the diagnostic:
fs/namei.c:2173:13: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical]
} while (!(has_zero(a, &adata, &constants) | has_zero(b, &bdata, &constants)));
~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
||
fs/namei.c:2173:13: note: cast one or both operands to int to silence this warning
It appears that when has_zero was introduced, two definitions were
produced with different signatures (in particular different return
types).
Looking at the usage in hash_name() in fs/namei.c, I suspect that
has_zero() is meant to be invoked twice per while loop iteration; using
logical-or would not update `bdata` when `a` did not have zeros. So I
think it's preferred to always return an unsigned long rather than a
bool than update the while loop in hash_name() to use a logical-or
rather than bitwise-or.
[ Also changed powerpc version to do the same - Linus ]
Link: https://github.com/ClangBuiltLinux/linux/issues/1832
Link: https://lore.kernel.org/lkml/20230801-bitwise-v1-1-799bec468dc4@google.com/
Fixes: 36126f8f2ed8 ("word-at-a-time: make the interfaces truly generic")
Debugged-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 39f49684036d24af800ff194c33c7b2653c591d7 ]
In a randconfig with CONFIG_SERIAL_CPM=m and
CONFIG_PPC_EARLY_DEBUG_CPM=y, there is a build error:
ERROR: modpost: "udbg_putc" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined!
Prevent the build error by allowing PPC_EARLY_DEBUG_CPM only when
SERIAL_CPM=y.
Fixes: c374e00e17f1 ("[POWERPC] Add early debug console for CPM serial ports.")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20230701054714.30512-1-rdunlap@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit 3f649ab728cda8038259d8f14492fe400fbab911 upstream.
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.
In preparation for removing[2] the[3] macro[4], remove all remaining
needless uses with the following script:
git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \
xargs perl -pi -e \
's/\buninitialized_var\(([^\)]+)\)/\1/g;
s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;'
drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid
pathological white-space.
No outstanding warnings were found building allmodconfig with GCC 9.3.0
for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64,
alpha, and m68k.
[1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/
[2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/
[3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/
[4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/
Reviewed-by: Leon Romanovsky <leonro@mellanox.com> # drivers/infiniband and mlx4/mlx5
Acked-by: Jason Gunthorpe <jgg@mellanox.com> # IB
Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless drivers
Reviewed-by: Chao Yu <yuchao0@huawei.com> # erofs
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 61235b24b9cb37c13fcad5b9596d59a1afdcec30 upstream
Everything is converted over to arch_cpu_finalize_init(). Remove the
check_bugs() leftovers including the empty stubs in asm-generic, alpha,
parisc, powerpc and xtensa.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Link: https://lore.kernel.org/r/20230613224545.553215951@linutronix.de
Signed-off-by: Daniel Sneddon <daniel.sneddon@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit af5cd05de5dd38cf25d14ea4d30ae9b791d2420b upstream.
Our logic for choosing defconfig doesn't work well in some situations.
For example if you're on a ppc64le machine but you specify a non-empty
CROSS_COMPILE, in order to use a non-default toolchain, then defconfig
will give you ppc64_defconfig (big endian):
$ make CROSS_COMPILE=~/toolchains/gcc-8/bin/powerpc-linux- defconfig
*** Default configuration is based on 'ppc64_defconfig'
This is because we assume that CROSS_COMPILE being set means we
can't be on a ppc machine and rather than checking we just default to
ppc64_defconfig.
We should just ignore CROSS_COMPILE, instead check the machine with
uname and if it's one of ppc, ppc64 or ppc64le then use that
defconfig. If it's none of those then we fall back to ppc64_defconfig.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1202cdd665315c525b5237e96e0bedc76d7e754f upstream.
DECnet is an obsolete network protocol that receives more attention
from kernel janitors than users. It belongs in computer protocol
history museum not in Linux kernel.
It has been "Orphaned" in kernel since 2010. The iproute2 support
for DECnet was dropped in 5.0 release. The documentation link on
Sourceforge says it is abandoned there as well.
Leave the UAPI alone to keep userspace programs compiling.
This means that there is still an empty neighbour table
for AF_DECNET.
The table of /proc/sys/net entries was updated to match
current directories and reformatted to be alphabetical.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: David Ahern <dsahern@kernel.org>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 20188baceb7a1463dc0bcb0c8678b69c2f447df6 upstream.
If profile-guided optimization is enabled, the purgatory ends up with
multiple .text sections. This is not supported by kexec and crashes the
system.
Link: https://lkml.kernel.org/r/20230321-kexec_clang16-v7-3-b05c520b7296@chromium.org
Fixes: 930457057abe ("kernel/kexec_file.c: split up __kexec_load_puragory")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: <stable@vger.kernel.org>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Baoquan He <bhe@redhat.com>
Cc: Borislav Petkov (AMD) <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Philipp Rudo <prudo@redhat.com>
Cc: Ross Zwisler <zwisler@google.com>
Cc: Simon Horman <horms@kernel.org>
Cc: Steven Rostedt (Google) <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Rix <trix@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
Bruce Ashfield
Kunwu Chan
Nathan Lynch
Laurent Dufour
Randy Dunlap
Bartlomiej Zolnierkiewicz
Masahiro Yamada
Naveen N Rao
Timothy Pearson
Christophe Leroy
Kajol Jain
ruanjinjie
Russell Currey
Joel Stanley
Masahiro Yamada
Christophe Leroy
Michael Ellerman
Aneesh Kumar K.V
ndesaulniers@google.com
Kees Cook
Thomas Gleixner
Stephen Hemminger
Ricardo Ribalda