The strlcpy should not be used because it doesn't limit the source
length. Preferred is strscpy.
Signed-off-by: XueBing Chen <chenxuebing@jari.cn>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/39aa840f.e31.181ed9461c2.Coremail.chenxuebing@jari.cn
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The type atomic_long_t can have size 4 or 8 bytes, depending on
CONFIG_64BIT; it's only content, the field 'counter', is either an
int or a s64 value.
Current code incorrectly uses the fixed size utils.read_u64() to
read the field 'counter' inside atomic_long_t.
On 32 bits architectures reading the last element 'tail_id' of the
struct prb_desc_ring:
struct prb_desc_ring {
...
atomic_long_t tail_id;
};
causes the utils.read_u64() to access outside the boundary of the
struct and the gdb command 'lx-dmesg' exits with error:
Python Exception <class 'IndexError'>: index out of range
Error occurred in Python: index out of range
Query the really used atomic_long_t counter type size.
Link: https://lore.kernel.org/r/20220617143758.137307-1-antonio.borneo@foss.st.com
Fixes: e60768311a ("scripts/gdb: update for lockless printk ringbuffer")
Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com>
[pmladek@suse.com: Query the really used atomic_long_t counter type size]
Tested-by: Antonio Borneo <antonio.borneo@foss.st.com>
Reviewed-by: John Ogness <john.ogness@linutronix.de>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20220719122831.19890-1-pmladek@suse.com
This enables a few of the core drivers needed to boot the 8cx Gen 3
platform and demotes the Qualcomm USB PHY drivers to modules, as they
don't need to be builtin.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmLYiS8bHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FjjIQANBVwP3aQl7EgVZFwg9I
eswtfjaQf+z/WyU31rP6h616J/7RiHS6Adhac78Kleyj2jgqMESMmhJ/VzCYBtDp
JJv7WJYd0vwlKjQdLybChGNtZbH+8IN8XpLceImLwzAFVweb88+WhAiRVEojUM5P
ZxpyZZGpDlSG4Zxti68NpK5UlhatZbWp0hspGgEDf8sTl9nAQd8MmC5XCUUDwJnz
iE79xYYHCryIMJ3YQx7F5IRe3DVH9JndtOYJUp688DtjqOAB6LxqY8p1s5HwNngz
5MVguNjZH6AIypHQHnKofzlFegkFSdnVULzkUjoSpQCxF+fRxhuV/nvj/WFtt+th
wpXp2j6JYAwzOREBg2UZeHb6vCB3kfGvjlODPFIkj0d9OP/h00tP5ijLPQ0MolP1
WBtBlUVLaghLbOeW/MONSPsMsywZfb8P5OdT0Kq88ymY316zLEcpomsD8J7WRK8I
1uvWy5paUEJt2jeD79rM2C88Mdw/4MAkZUhGSvg92gPiOwGNB0cOsHV5ufHlCnV9
lyn0nTBCRNzP1ZCXQpGNIn1jGXp6akIhQYOh1KOIrdW6UkuAbONoUOQs2ncsF17A
FryQqvDvbB0T5+NfxxTAC1CJGOjMdMI1kYkfQKtvYax3uvPZSuRsUdOhU5w334Sr
wYHebeOpJdBlG0CTrsMln/K/
=KJ5v
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmLZTkwACgkQmmx57+YA
GNlX7A//UGMR9oeb4/HE1TR9z1aibxumFetvFuKbu3NbLxEULNz4B7tpOeezQ88e
MGidzv/AxExzxo1j3CCELqONp+yg/i4BcK/1/MQilMIhsPvqgyIeISaEH3mL5dQe
k1YC3jiSKxGcJzZE/j16bTIC2z1TxlCRKcPfFJOM0Wpi8DEUX7i3o/8TkHqZ+EZP
nlTVnlLw75TwyWX+APL9cXnhjaogUXOBTfenDcA/hSTlNngsdT+JGMIvNgXDsXkf
B1ZQTg4w4fzaS82ItjgBjnFcrDcfw/BjBHkRjqXbg5cWUXk8zUq8AZ/5m8WusttK
tBfyc/dUPShEeYLp3aBMyPAMW+sdA/2uRoNLZyzp+jEAUgFq1CYXScaxdrQ9OsHQ
1JSLXccUszr0m7jJs9HjLkyD8rGJ6/jLrsjE/VvaTxyoupDbVyPXYxq/2IxS4RN4
nalkXS99Ln4406Wg15CiXsJpnD3IQi+Pxz8KoMcAj5qlykBohpcy0v94kmoIVptG
Mj7hleVbDspprNS+HDEWq7a5eq9R5RsWrfUXCJG3CqQ59NdirgKOFv20Ha84Oei/
W5993ZUckrpbEC7cSIlV52lNm2cfuDZ35mqaHtecq4ODNysroNqtMR2LETQJVZrA
QjWlLA/u7qsmZrr9ZQvo5SrRgJtTSrz+FiqdLzE908pLr6xz25Q=
=CCqT
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-defconfig-for-5.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/defconfig
Qualcomm ARM64 defconfig more updates for v5.20
This enables a few of the core drivers needed to boot the 8cx Gen 3
platform and demotes the Qualcomm USB PHY drivers to modules, as they
don't need to be builtin.
* tag 'qcom-arm64-defconfig-for-5.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: defconfig: Demote Qualcomm USB PHYs to modules
arm64: defconfig: Enable Qualcomm SC8280XP providers
Link: https://lore.kernel.org/r/20220720230140.2113129-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Syzkaller found a problem similar to d1a6edecc1 ("bpf: Check
attach_func_proto more carefully in check_return_code") where
attach_func_proto might be NULL:
RIP: 0010:check_helper_call+0x3dcb/0x8d50 kernel/bpf/verifier.c:7330
do_check kernel/bpf/verifier.c:12302 [inline]
do_check_common+0x6e1e/0xb980 kernel/bpf/verifier.c:14610
do_check_main kernel/bpf/verifier.c:14673 [inline]
bpf_check+0x661e/0xc520 kernel/bpf/verifier.c:15243
bpf_prog_load+0x11ae/0x1f80 kernel/bpf/syscall.c:2620
With the following reproducer:
bpf$BPF_PROG_RAW_TRACEPOINT_LOAD(0x5, &(0x7f0000000780)={0xf, 0x4, &(0x7f0000000040)=@framed={{}, [@call={0x85, 0x0, 0x0, 0xbb}]}, &(0x7f0000000000)='GPL\x00', 0x0, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, 0x2b, 0xffffffffffffffff, 0x8, 0x0, 0x0, 0x10, 0x0}, 0x80)
Let's do the same here, only check attach_func_proto for the prog types
where we are certain that attach_func_proto is defined.
Fixes: 69fd337a97 ("bpf: per-cgroup lsm flavor")
Reported-by: syzbot+0f8d989b1fba1addc5e0@syzkaller.appspotmail.com
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/20220720164729.147544-1-sdf@google.com
This adds support for booting secondary cores, SPM, SMD-RPM and RPM
power-domain support for the MSM8909 platform.
It drops an unnecessary print in icc-bwmon, corrects SA8540P entries in
socinfo and a Kconfig build dependency for QCOM_RPMPD.
Lastly it continues to clean up up the Devicetree bindings for the
Qualcomm drivers.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmLYinIbHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FryMQANQKam+7lJrykwF3bt8t
e/ZR1SWPcKTu5dudsnA2GACnycQ8XQr5M06HRVghwveleXbjHyE3beLEy/NwfbTL
P4ufdDtg/UCwZXJ+p2ZDtbKIWQQU1qgItekYiN3lDEnb3Y5R7vI2h2mhdDOZh8yn
HtzI5EeI5gMilZ7yYtqPR3DrXpfdYBaGANshyzmP07eDTz+UyaSSKoALsy7jeWB2
9d4/inH35Tuqv/98oLaf+gK1vH89AVA13N6fVaQxgPOne3FN1bsqBFGc/RvW+phH
CG+D86lrxq7iChdEcvcoPCkabYi4lNqhbKZOiAAimqrwFCIksVJSE7adDul0JcPF
g0ml1jWIx+Jsj5TmuRH01CaxCuLtv9WKARi64vqA8dwSYuak8irP3WXbbtv/sNgW
PokJovzDwwSs71Rh8PmlXC//XY8gbsVj/umI8lEsS5/PrvdCXYsRTjRzvZ5uNtiQ
5s1fm6xMT2AMbp+Y6ZcnmPhuGntfiJZFj9GivfZuaYF44Ov6mRScHnRADC9oXpBf
7qlaC1T05PBUHOMB19xpOOsqtBpfX9TCaCqhsVxhH4bjzzYoMuV+yYlI3CqPv3yL
v9bKfMkbsOpZywCxyve2d6jqCeL8fA2iPw3MzFIlmESRA4MwdXswmxHCE3C7FOHA
SZkdXKa4EeWQRBf9g5ri3EM/
=gLQ3
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmLZTeMACgkQmmx57+YA
GNmWzg//eCc5hZXF1HumCX21ueWjwnAaZWZZECe+Plc0GB6nMnPVgCw2S29SCfYQ
cpR1B0YME/AgK7GiwdxW7mh9wtRzAtR7aSn2Z3nsmF7lMTJI5mJTDVIApoCvgHDu
5eyFIoiwtWYKFht5TLvC56fnOW73Jp6m5K4HElH2q6A387uurc8ClmuhnG7Dbhsp
WCYB7aqfqYlMybf8EYo3BAng63v6wLDf93+HyGokRiRHeh/h7xF4liLVY9XCNxOH
NSxBn8zZDRttEww+xSP+hDpTo316YG3SiNf3XW5ojVMrSUsbJM76DMTuPW70LJvK
obL4SL7zPeo7yH0NiHK699k+jchozb6Uq9WNnWHc3b5ABXK1RV0BoUNPtTHjiYBs
ojJnqjPmGJHaLmrvqEihyzRxXJtFMFU22t2EwdUmxQyYdgffS35W6lJtlNP/q7ph
i+DFoyKsmH8T9zNibNXjoV5NAo73OyKKriWjQS/DYR2/T/kwooXo9h9RS8rppo4M
kqumzGT2gdLoYI/1hBgXurQpMr231XvesLNSNJpQNz3UfYC0cuC7nAe6EQ5Jn2Da
hLQrRSj+TMghSq8dw5yOx1fvWjyYT1uFKiSgOkWXvX6Pcui6UC5oJ3zivv7JOXuc
Jjn+0B31KIBUyh8hq4cNrGaF8edVf8Y0vxp0mKsnnYjQxxuZHkc=
=TP2T
-----END PGP SIGNATURE-----
Merge tag 'qcom-drivers-for-5.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/drivers
More Qualcomm driver changes for v5.20
This adds support for booting secondary cores, SPM, SMD-RPM and RPM
power-domain support for the MSM8909 platform.
It drops an unnecessary print in icc-bwmon, corrects SA8540P entries in
socinfo and a Kconfig build dependency for QCOM_RPMPD.
Lastly it continues to clean up up the Devicetree bindings for the
Qualcomm drivers.
* tag 'qcom-drivers-for-5.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
dt-bindings: soc: qcom: qcom,smd-rpm: add power-controller
dt-bindings: soc: qcom: aoss: document qcom,sm8450-aoss-qmp
dt-bindings: soc: qcom,rpmh-rsc: simplify qcom,tcs-config
ARM: mach-qcom: Add support for MSM8909
dt-bindings: arm: cpus: Document "qcom,msm8909-smp" enable-method
soc: qcom: spm: Add CPU data for MSM8909
dt-bindings: soc: qcom: spm: Add MSM8909 CPU compatible
soc: qcom: rpmpd: Add compatible for MSM8909
dt-bindings: power: qcom-rpmpd: Add MSM8909 power domains
soc: qcom: smd-rpm: Add compatible for MSM8909
dt-bindings: soc: qcom: smd-rpm: Add MSM8909
soc: qcom: icc-bwmon: Remove unnecessary print function dev_err()
soc: qcom: socinfo: Fix the id of SA8540P SoC
soc: qcom: Make QCOM_RPMPD depend on PM
Link: https://lore.kernel.org/r/20220720230648.2113609-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
It contains updates for integration with OP-TEE by having a
dummy outer_cache.write_sec function to avoid triggering
exception when Linux tries to update secure registers.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTsZ8eserC1pmhwqDmejrg/N2X7/QUCYtkKkAAKCRCejrg/N2X7
/daRAP4+Xhqo21g5cX+/TS4/DsjYSrMRdiMpCE2KaoLY/ON2GgD/bSN4ZW/nf40y
NQgTNPK/b6d2/RsEzLaF+U1eb6Ag6Ag=
=BiKA
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmLZTawACgkQmmx57+YA
GNnnuA/+NKrf+D3F5lVF4FKavqBvX0vt1QjJVC2HN+eVTLhTGwIEKbvoxRrv2yEu
6hafPxpv8Tq0NO7oBQ9I/K9h4xJjgreI+CuIBExLe2NN6OCaVSjUrHfLU8ljCcyA
+AsGShjoMieT1bljMWq28AKPJ0xXIwEVY/sz1NRhXo1BmKu//k0QTeI19a2MD4xP
C7EB2colgENWPX4SR+/MEMr3GLOPy0zELSq1iOi4yUtxCd/PKoIkFogG4RsbDS07
QyLBm0Zwh+9UDd+7KaZJLSaxCZyHtv/M1hG/b7dlixLyypmPK4gg6+RXnzLmApMT
VDF5Yon9rdr3Z26qkmoBQ3k9VAXe9VH1zY9fbAXDtqVE1MzmY5jAsOFk7n0lQrm9
dT7i7ZCfi/7lROEZ8l2XXalslf6Hl/IZB/VCX1WZ9BLt6HQNiafvzAbcpCFUyAQt
I+H2Qfpbdi9R/OQkQBJZZy2Buip0NqE6VEXqAECmwSb3ySPJw9y6GMXiH08d6+pY
nBUuC9fjsfusL2ZWQJojtPrsAyZL0Iq8l0rjR1Ntmq72EbqNRkWMG63zsQuAc2aR
2R1ZO3evyNxefEMQl3cD8yzOAJNtB8wrHc8t/BRr/Xu8cUP8x2e15I0uUwemOvFB
l6e7xWUmRQPWWfDEShmb/Ph91N29PLa8prPekZp9JCVs2oAT3WQ=
=ND2S
-----END PGP SIGNATURE-----
Merge tag 'at91-soc-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/soc
AT91 SoC for 5.20
It contains updates for integration with OP-TEE by having a
dummy outer_cache.write_sec function to avoid triggering
exception when Linux tries to update secure registers.
* tag 'at91-soc-5.20' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
ARM: at91: setup outer cache .write_sec() callback if needed
ARM: at91: add sam_linux_is_optee_available() function
Link: https://lore.kernel.org/r/20220721085852.1740924-1-claudiu.beznea@microchip.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
It contains one fix for LAN966 based SoCs fixing the frequency of
sys_clk. sys_clk is feeding different IPs so having proper frequency
for it in DT is necessary for proper working of different drivers.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTsZ8eserC1pmhwqDmejrg/N2X7/QUCYtgTywAKCRCejrg/N2X7
/SHHAQC7vKFPU+mWlZ0e2cGWgKyfKReZFkTbccST5g6OJwOAcAEA+sQBhdtysu2M
Ny+68ihX+4Fx7TqHBXn8iSFfcC8NsAM=
=VC5w
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmLZTYYACgkQmmx57+YA
GNlH6RAAvb5kvKv1xYAPv5SznE0M8t88fozd77QBxoDERv4ETtQ1QFIqKUttK/NB
yFvnLghTi2RWfFiqN4+U/vXDSFhfavmkC6nf7+Ks/+/X8JiYJZWCrgaDdWATuJLA
yiEsRtfNHFG2XPoJA8cDaG85cPk82p2DLZnznTOryZRBXGEbIU6aYTnlCO4xF5ig
/jApSSU0LBkvDCvDgpcT4rWgvo/Yb9A6qX3EhARmcLDZP0II2utX8kdMyhRRoI9q
HxJ1QXPFjsuUU2jv4waQ7tqNqLUMIV9BMycUX+YUg1eAIlUtSmuTEknjPNndvHn3
SZgBjRUww47qpffczgNSQyms405X+PhrNe285TXAB//i8tl68Dds2GHugZLAyVu8
30H71NTep3+yDJha8AZnT7MugyYo3ENj/gbnJ5p/Xb0vGjXXsaDbOb41/o1oOSO9
AL+k7vR6sBKOoKnYiRJ76qLn8Up34PdUz2M19PEly+xQDawM2SAyHsgRyi1gQsSU
e/9+yLtM0obpwwm3QfWEXYO/xazzubP6kXe7bTJCaAmEaaVBYJCN023p7ZRg6Ii5
eyUCy0qasQ39cuYld1oSoB1RFXUfM9AYmj8cpR4doWil8xcbRxRucxqzVA2U2joE
QGi95cDT/mxFp2xOEDXLN5+/yCRom4swcjyAPX0s0gsj1VRC1ds=
=VoCM
-----END PGP SIGNATURE-----
Merge tag 'at91-fixes-5.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into arm/fixes
AT91 fixes for 5.19 #3
It contains one fix for LAN966 based SoCs fixing the frequency of
sys_clk. sys_clk is feeding different IPs so having proper frequency
for it in DT is necessary for proper working of different drivers.
* tag 'at91-fixes-5.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
ARM: dts: lan966x: fix sys_clk frequency
Link: https://lore.kernel.org/r/20220721075705.1739915-1-claudiu.beznea@microchip.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The peripheral may have several FIFOs, but some case just select
some FIFOs from them for data transfer, which means FIFO0 and FIFO2
may be selected. So add FIFO address stride support, 0 means all FIFOs
are continuous, 1 means 1 word stride between FIFOs. All stride between
FIFOs should be same.
Another option words_per_fifo means how many audio channel data copied
to one FIFO one time, 1 means one channel per FIFO, 2 means 2 channels
per FIFO.
If 'n_fifos_src = 4' and 'words_per_fifo = 2', it means the first two
words(channels) fetch from FIFO0 and then jump to FIFO1 for next two words,
and so on after the last FIFO3 fetched, roll back to FIFO0.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1657162829-9273-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
This adds an additional GSBI, hwclock, smem and tsens nodes for IPQ8064,
in addition to fixing up and improving the existing descriptions of the
platform.
USB interrupts are reordered to please the Devicetree binding.
The Light Pulse Generator is defined for PM8941 and LEDs are defined for
the FairPhone2, Nexus 5 and Sony Xperia devices.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmLYi3cbHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FIB4P/Avux6+k6nw9atsXoc8s
tfpkvjXiKct19Meljl6Vuhl6Oe+kdiu3FkS3Hp2AyXxr1FoIoHevrOk+a7QaJBzR
3rqRrDWqGmXoxvoUrvaFuJN7igwW/SLPBsr8P96ViUJynrsOjdOdIq/+tsCHknFT
sDixxVIPlmtX0UycSyZbSVLr/OstNtwSO1EDC/DnF6+pWCX9NhjGNDR/OQioJ2PQ
bPDSlEgTP4jDTJgyT4zU2XD6eKAK+XaXJi1dOs8EkQWx1+EJn3MzyoNeUsN2ihaD
UhSwlhzIyEcN++crfYq0mVILnjG9qk5gzgpV0sMQOii7MzI3MGRGp7SVTM5Qf4FM
/dL24wKDWmyrSaqEZ21GCBMAG0zDWnmD3lnrkksKE9idMnynfAuLb2155QlIuzH/
bvKVdEad1wXhRGwKMLmkIN9yGcYLD4ocFakO14fk0uSCsmSC1z3Rkl/pXHDwKSE5
CRqu//7CM/ukpNKtk712sBsjsPrm5fzL658L7z+qsueKe7I579SChrPNunDhLC/Q
IR2fGoA+CgR/NF3BTiBPxFhw3KTpq2DY9MTgTsyMD1wBB41Y8IgVMRAoT9B5SQq/
4UnWf+wveyoUKupjABLsGv4I4dCBXYrSWNRJF+7GRe8rMqG3QrjnOnExcJB+ecVf
AKcJr5SN9AkLszSrPw35//Hl
=+xsC
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmLZTL0ACgkQmmx57+YA
GNnkNhAAkJl2rEGgTOm4lQeQLL1nhlxpraKlbxOIGDAmdmLZRQXE+4o9F4pOT7DI
Hilwz7jmQFYmbakxRwHmm8c9c93gR7sELeM/0HPmGyNQcKux1mqXsShab3IdncRl
AXLCt5btgDvJHIwSk1FX5/ryY3ZGOM2dIg1W7uc+ZvsKOAjhabm0t74Ghm49ZdYC
KSsct1WxeuF7S7IGrKVvKQcSUroli7kNMe/aIAkWDQQWZHKzMqcvNjPH0twzc1eo
3J7t6NuFr7ksP50CuHloHV0x+c+YXAbQFdpcT1//W9UtwjiiYKzoq3V68UqTxr0K
RFFiDLpaTC3Kjhp96TkM74d8XBYuoGufqQRC7bzUJFnrpCWve2nYNo7BTrH3W9q4
nBO7lDcbcz6ag872q3xKmkz91zfnz/OXZ1hVsMbf2lwhWF6KAh0x31NXQMCaWoWL
6+7cjl3sqneaEUrJvffoywElgHbRkM7x5oNOCgrfqIkYfXlD4s40AAwG/XF/G7I+
0MJMQ3yVtIm06T2xMeirH0GnpmzLc+B/k24HRi0+G80o8a8ht2ActgpbCH9ngxuD
YpiH0hmIioNHiIu1OZDuPvWTp46Lx6Xf/q7PNq5K8YcBSpY1uwXwbez6PEQ21Gc9
lY864zOu87ZLsYd0NB/zW0oFQDE52f5kQS399gRd0z8KiNi8D4s=
=ClPr
-----END PGP SIGNATURE-----
Merge tag 'qcom-dts-for-5.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
More Qualcomm DTS updates for v5.20
This adds an additional GSBI, hwclock, smem and tsens nodes for IPQ8064,
in addition to fixing up and improving the existing descriptions of the
platform.
USB interrupts are reordered to please the Devicetree binding.
The Light Pulse Generator is defined for PM8941 and LEDs are defined for
the FairPhone2, Nexus 5 and Sony Xperia devices.
* tag 'qcom-dts-for-5.20-2' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
ARM: dts: qcom: add rpmcc missing clocks for apq/ipq8064 and msm8660
ARM: dts: qcom: msm8974: Disable remoteprocs by default
ARM: dts: qcom: ipq8064: add missing smem compatible
ARM: dts: qcom: ipq8064: add missing hwlock
ARM: dts: qcom: ipq8064: add speedbin efuse nvmem node
ARM: dts: qcom: ipq8064: fix and add some missing gsbi node
ARM: dts: qcom: ipq8064: reduce pci IO size to 64K
ARM: dts: qcom: ipq8064: disable usb phy by default
ARM: dts: qcom: ipq8064: add missing snps,dwmac compatible for gmac
ARM: dts: qcom: ipq8064: add specific dtsi with smb208 rpm regulators
ARM: dts: qcom: ipq8064: add gsbi6 missing definition
ARM: dts: qcom: ipq8064: add multiple missing pin definition
ARM: dts: qcom: msm8974-hammerhead: Add notification LED
ARM: dts: qcom: msm8974-FP2: Add notification LED
ARM: dts: qcom: msm8974-sony: Enable LPG
ARM: dts: qcom: Add LPG node to pm8941
ARM: dts: qcom: sdx65: reorder USB interrupts
ARM: dts: qcom: apq8064: create tsens device node
Link: https://lore.kernel.org/r/20220720231111.2114025-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The datasheet says that VDD12 must be enabled and at full voltage before
VDD33 is enabled.
Reorder the bulk regulator supply names so that VDD12 is enabled before
VDD33. Any enable ramp delays should be handled by setting proper
constraints on the regulators.
Fixes: bc1aee7fc8 ("drm/bridge: Add I2C based driver for ps8640 bridge")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220721092258.3397461-1-wenst@chromium.org
Some IAX operation code nomenclatures are misleading or don't match with
others:
1. Operation code 0x4c is Zero Compress 32. IAX_OPCODE_DECOMP_32 is a
misleading name. Change it to IAX_OPCODE_ZERO_COMP_32.
2. Operation code 0x4d is Zero Compress 16. IAX_OPCODE_DECOMP_16 is a
misleading name. Change it to IAX_OPCODE_ZERO_COMP_16.
3. IAX_OPCDE_FIND_UNIQUE is corrected to match with other nomenclatures.
Co-developed-by: Li Zhang <li4.zhang@intel.com>
Signed-off-by: Li Zhang <li4.zhang@intel.com>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20220707002052.1546361-1-fenghua.yu@intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Remove mmap callback as ASoC AMD drivers just call
the standard mmap handler.
Signed-off-by: Venkata Prasad Potturu <venkataprasad.potturu@amd.com>
Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://lore.kernel.org/r/20220721062043.3016985-2-venkataprasad.potturu@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fix sparse warning:
sound/soc/fsl/fsl_sai.c:64:39: sparse: warning: Using plain integer as NULL pointer
Fixes: b4ee8a913e ("ASoc: fsl_sai: Add pinctrl operation for PDM and DSD")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1658399393-28777-2-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
If the channel has no descriptor and the interrupt is raised then the
kernel will OOPS. Check the result of vchan_next_desc() in the handler
axi_chan_block_xfer_complete() to avoid the error happening.
Signed-off-by: Ben Dooks <ben.dooks@sifive.com>
Link: https://lore.kernel.org/r/20220708170153.269991-4-ben.dooks@sifive.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
During debugging we have seen an issue where axi_chan_dump_lli()
is passed a NULL LLI pointer which ends up causing an OOPS due
to trying to get fields from it. Simply print NULL LLI and exit
to avoid this.
Signed-off-by: Ben Dooks <ben.dooks@sifive.com>
Link: https://lore.kernel.org/r/20220708170153.269991-3-ben.dooks@sifive.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The return from strcmp() is inverted so it wrongly returns true instead
of false and vice versa.
Fixes: a1c9d61b19 ("libbpf: Improve library identification for uprobe binary path resolution")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Cc: Alan Maguire <alan.maguire@oracle.com>
Link: https://lore.kernel.org/bpf/YtZ+/dAA195d99ak@kili
The code here is supposed to take a signed int and store it in a signed
long long. Unfortunately, the way that the type promotion works with
this conditional statement is that it takes a signed int, type promotes
it to a __u32, and then stores that as a signed long long. The result is
never negative.
This is from static analysis, but I made a little test program just to
test it before I sent the patch:
#include <stdio.h>
int main(void)
{
unsigned long long src = -1ULL;
signed long long dst1, dst2;
int is_signed = 1;
dst1 = is_signed ? *(int *)&src : *(unsigned int *)0;
dst2 = is_signed ? (signed long long)*(int *)&src : *(unsigned int *)0;
printf("%lld\n", dst1);
printf("%lld\n", dst2);
return 0;
}
Fixes: d90ec262b3 ("libbpf: Add enum64 support for btf_dump")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Link: https://lore.kernel.org/bpf/YtZ+LpgPADm7BeEd@kili
Prox-out events may not be reliably sent by some AES firmware. This can
cause problems for users, particularly due to arbitration logic disabling
touch input while the pen is in prox.
This commit adds a timer which is reset every time a new prox event is
received. When the timer expires we check to see if the pen is still in
prox and force it out if necessary. This is patterend off of the same
solution used by 'hid-letsketch' driver which has a similar problem.
Link: https://github.com/linuxwacom/input-wacom/issues/310
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
joycon_dpad_inputs_jc[] is unterminated. This may result in odd warnings
such as
input: input_set_capability: invalid code 3077588140 for type 1
or in kernel crashes in nintendo_hid_probe(). Terminate the array to fix
the problem.
Fixes: 2af16c1f84 ("HID: nintendo: add nintendo switch controller driver")
Cc: Daniel J. Ogorchock <djogorchock@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The double `with' is duplicated in line 769, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Newer AMD SOCs use SFH1.1 memory access with new PCI-id. Hence add new
sfh1_1 sub directory to implement SFH1.1 functionality by defining new
PCI id, interface functions, descriptor functions and handlers which
invokes sfh1.1.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Interrupt handling can be used in multiple files to support all
AMD SOCs. Hence move interrupt handling to common interface.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
amd_sfh_work can be used in multiple files to support all AMD SOCs.
Hence move amd_sfh_work to common interface.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Move global functions declared from header files and make them as static
functions wherever applicable.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add remove operation as part of amd_mp2_ops structure to support all
AMD SOCs and use wherever applicable.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add PM operations as part of amd_mp2_ops structure to support all
AMD SOCs and use wherever applicable.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add dynamic descriptor operations as part of amd_mp2_ops structure to
support all AMD SOCs and use wherever applicable.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
request_list variable can be used in multiple files to support all
AMD SOCs. Hence move request_list variable to client data.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
request_list structure can be used in multiple files to support all
AMD SOCs. Hence move request_list structure to header file.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Introduce common macros and structures to support multiple generations
of AMD SOCs, move them to amd_sfh_common.h.
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
On removal of hid device during SFH set report may cause NULL pointer
exception. Hence add NULL check for hid device before accessing.
Fixes: 4b2c53d93a ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)")
Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit bebcc522fb ("HID: core: for input reports, process the usages by
priority list") split the iteration into two distinct loops in
hid_process_report().
After this change, the variable field is only used while iterating in the
second loop and the assignment of values to this variable in the first loop
is simply not needed.
Remove the unneeded assignment during retrieval. No functional change and
no change in the resulting object code.
This was discovered as a dead store with clang-analyzer.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Tom Rix <trix@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
DisplayLink ethernet devices require NTB buffers larger then 32kb
in order to run with highest performance.
This patch is changing upper limit of the rx and tx buffers.
Those buffers are initialized with CDC_NCM_NTB_DEF_SIZE_RX and
CDC_NCM_NTB_DEF_SIZE_TX which is 16kb so by default no device is
affected by increased limit.
Rx and tx buffer is increased under two conditions:
- Device need to advertise that it supports higher buffer size in
dwNtbMaxInMaxSize and dwNtbMaxOutMaxSize.
- cdc_ncm/rx_max and cdc_ncm/tx_max driver parameters must be adjusted
with udev rule or ethtool.
Summary of testing and performance results:
Tests were performed on following devices:
- DisplayLink DL-3xxx family device
- DisplayLink DL-6xxx family device
- ASUS USB-C2500 2.5G USB3 ethernet adapter
- Plugable USB3 1G USB3 ethernet adapter
- EDIMAX EU-4307 USB-C ethernet adapter
- Dell DBQBCBC064 USB-C ethernet adapter
Performance measurements were done with:
- iperf3 between two linux boxes
- http://openspeedtest.com/ instance running on local test machine
Insights from tests results:
- All except one from third party usb adapters were not affected by
increased buffer size to their advertised dwNtbOutMaxSize and
dwNtbInMaxSize.
Devices were generally reaching 912-940Mbps both download and upload.
Only EDIMAX adapter experienced decreased download size from
929Mbps to 827Mbps with iper3, with openspeedtest decrease was from
968Mbps to 886Mbps.
- DisplayLink DL-3xxx family devices experienced performance increase
with iperf3 download from 300Mbps to 870Mbps and
upload from 782Mbps to 844Mbps.
With openspeedtest download increased from 556Mbps to 873Mbps
and upload from 727Mbps to 973Mbps
- DiplayLink DL-6xxx family devices are not affected by
increased buffer size.
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20220720060518.541-2-lukasz.spintzyk@synaptics.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
This improves performance and stability of
DL-3xxx/DL-5xxx/DL-6xxx device series.
Specifically prevents device from temporary network dropouts when
playing video from the web and network traffic going through is high.
Signed-off-by: Dominik Czerwik <dominik.czerwik@synaptics.com>
Signed-off-by: Łukasz Spintzyk <lukasz.spintzyk@synaptics.com>
Link: https://lore.kernel.org/r/20220720060518.541-1-lukasz.spintzyk@synaptics.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Fix the error of implicit declaration of function 'drmm_of_get_bridge':
drivers/gpu/drm/vc4/vc4_dpi.c:278:11: error: implicit declaration of function ‘drmm_of_get_bridge’; did you mean ‘devm_drm_of_get_bridge’? [-Werror=implicit-function-declaration]
bridge = drmm_of_get_bridge(drm, dev->of_node, 0, 0);
Fixes: 055af0235a ("drm/vc4: dpi: Switch to drmm_of_get_bridge")
Signed-off-by: Wang Jingjin <wangjingjin1@huawei.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220716020741.4124893-1-wangjingjin1@huawei.com
there is an unexpected word "the" in the comments that need to be dropped
file: drivers/hid/intel-ish-hid/ishtp-hid-client.c
line: 331
* @device: Pointer to the the ishtp client device for which this message
changed to
* @device: Pointer to the ishtp client device for which this message
Signed-off-by: Jiang Jian <jiangjian@cdjrlc.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Smatch Warning:
drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy()
'&mcp->txbuf[5]' too small (59 vs 255)
drivers/hid/hid-mcp2221.c:388 mcp_smbus_write() error: __memcpy() 'buf'
too small (34 vs 255)
The 'len' variable can take a value between 0-255 as it can come from
data->block[0] and it is user data. So add an bound check to prevent a
buffer overflow in memcpy().
Fixes: 67a95c2146 ("HID: mcp2221: add usb to i2c-smbus host bridge")
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Now that we finished moving setgid stripping for regular files in setgid
directories into the vfs, individual filesystem don't need to manually
strip the setgid bit anymore. Drop the now unneeded code from ceph.
Link: https://lore.kernel.org/r/1657779088-2242-4-git-send-email-xuyang2018.jy@fujitsu.com
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Christian Brauner (Microsoft)<brauner@kernel.org>
Reviewed-and-Tested-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Move setgid handling out of individual filesystems and into the VFS
itself to stop the proliferation of setgid inheritance bugs.
Creating files that have both the S_IXGRP and S_ISGID bit raised in
directories that themselves have the S_ISGID bit set requires additional
privileges to avoid security issues.
When a filesystem creates a new inode it needs to take care that the
caller is either in the group of the newly created inode or they have
CAP_FSETID in their current user namespace and are privileged over the
parent directory of the new inode. If any of these two conditions is
true then the S_ISGID bit can be raised for an S_IXGRP file and if not
it needs to be stripped.
However, there are several key issues with the current implementation:
* S_ISGID stripping logic is entangled with umask stripping.
If a filesystem doesn't support or enable POSIX ACLs then umask
stripping is done directly in the vfs before calling into the
filesystem.
If the filesystem does support POSIX ACLs then unmask stripping may be
done in the filesystem itself when calling posix_acl_create().
Since umask stripping has an effect on S_ISGID inheritance, e.g., by
stripping the S_IXGRP bit from the file to be created and all relevant
filesystems have to call posix_acl_create() before inode_init_owner()
where we currently take care of S_ISGID handling S_ISGID handling is
order dependent. IOW, whether or not you get a setgid bit depends on
POSIX ACLs and umask and in what order they are called.
Note that technically filesystems are free to impose their own
ordering between posix_acl_create() and inode_init_owner() meaning
that there's additional ordering issues that influence S_SIGID
inheritance.
* Filesystems that don't rely on inode_init_owner() don't get S_ISGID
stripping logic.
While that may be intentional (e.g. network filesystems might just
defer setgid stripping to a server) it is often just a security issue.
This is not just ugly it's unsustainably messy especially since we do
still have bugs in this area years after the initial round of setgid
bugfixes.
So the current state is quite messy and while we won't be able to make
it completely clean as posix_acl_create() is still a filesystem specific
call we can improve the S_SIGD stripping situation quite a bit by
hoisting it out of inode_init_owner() and into the vfs creation
operations. This means we alleviate the burden for filesystems to handle
S_ISGID stripping correctly and can standardize the ordering between
S_ISGID and umask stripping in the vfs.
We add a new helper vfs_prepare_mode() so S_ISGID handling is now done
in the VFS before umask handling. This has S_ISGID handling is
unaffected unaffected by whether umask stripping is done by the VFS
itself (if no POSIX ACLs are supported or enabled) or in the filesystem
in posix_acl_create() (if POSIX ACLs are supported).
The vfs_prepare_mode() helper is called directly in vfs_*() helpers that
create new filesystem objects. We need to move them into there to make
sure that filesystems like overlayfs hat have callchains like:
sys_mknod()
-> do_mknodat(mode)
-> .mknod = ovl_mknod(mode)
-> ovl_create(mode)
-> vfs_mknod(mode)
get S_ISGID stripping done when calling into lower filesystems via
vfs_*() creation helpers. Moving vfs_prepare_mode() into e.g.
vfs_mknod() takes care of that. This is in any case semantically cleaner
because S_ISGID stripping is VFS security requirement.
Security hooks so far have seen the mode with the umask applied but
without S_ISGID handling done. The relevant hooks are called outside of
vfs_*() creation helpers so by calling vfs_prepare_mode() from vfs_*()
helpers the security hooks would now see the mode without umask
stripping applied. For now we fix this by passing the mode with umask
settings applied to not risk any regressions for LSM hooks. IOW, nothing
changes for LSM hooks. It is worth pointing out that security hooks
never saw the mode that is seen by the filesystem when actually creating
the file. They have always been completely misplaced for that to work.
The following filesystems use inode_init_owner() and thus relied on
S_ISGID stripping: spufs, 9p, bfs, btrfs, ext2, ext4, f2fs, hfsplus,
hugetlbfs, jfs, minix, nilfs2, ntfs3, ocfs2, omfs, overlayfs, ramfs,
reiserfs, sysv, ubifs, udf, ufs, xfs, zonefs, bpf, tmpfs.
All of the above filesystems end up calling inode_init_owner() when new
filesystem objects are created through the ->mkdir(), ->mknod(),
->create(), ->tmpfile(), ->rename() inode operations.
Since directories always inherit the S_ISGID bit with the exception of
xfs when irix_sgid_inherit mode is turned on S_ISGID stripping doesn't
apply. The ->symlink() and ->link() inode operations trivially inherit
the mode from the target and the ->rename() inode operation inherits the
mode from the source inode. All other creation inode operations will get
S_ISGID handling via vfs_prepare_mode() when called from their relevant
vfs_*() helpers.
In addition to this there are filesystems which allow the creation of
filesystem objects through ioctl()s or - in the case of spufs -
circumventing the vfs in other ways. If filesystem objects are created
through ioctl()s the vfs doesn't know about it and can't apply regular
permission checking including S_ISGID logic. Therfore, a filesystem
relying on S_ISGID stripping in inode_init_owner() in their ioctl()
callpath will be affected by moving this logic into the vfs. We audited
those filesystems:
* btrfs allows the creation of filesystem objects through various
ioctls(). Snapshot creation literally takes a snapshot and so the mode
is fully preserved and S_ISGID stripping doesn't apply.
Creating a new subvolum relies on inode_init_owner() in
btrfs_new_subvol_inode() but only creates directories and doesn't
raise S_ISGID.
* ocfs2 has a peculiar implementation of reflinks. In contrast to e.g.
xfs and btrfs FICLONE/FICLONERANGE ioctl() that is only concerned with
the actual extents ocfs2 uses a separate ioctl() that also creates the
target file.
Iow, ocfs2 circumvents the vfs entirely here and did indeed rely on
inode_init_owner() to strip the S_ISGID bit. This is the only place
where a filesystem needs to call mode_strip_sgid() directly but this
is self-inflicted pain.
* spufs doesn't go through the vfs at all and doesn't use ioctl()s
either. Instead it has a dedicated system call spufs_create() which
allows the creation of filesystem objects. But spufs only creates
directories and doesn't allo S_SIGID bits, i.e. it specifically only
allows 0777 bits.
* bpf uses vfs_mkobj() but also doesn't allow S_ISGID bits to be created.
The patch will have an effect on ext2 when the EXT2_MOUNT_GRPID mount
option is used, on ext4 when the EXT4_MOUNT_GRPID mount option is used,
and on xfs when the XFS_FEAT_GRPID mount option is used. When any of
these filesystems are mounted with their respective GRPID option then
newly created files inherit the parent directories group
unconditionally. In these cases non of the filesystems call
inode_init_owner() and thus did never strip the S_ISGID bit for newly
created files. Moving this logic into the VFS means that they now get
the S_ISGID bit stripped. This is a user visible change. If this leads
to regressions we will either need to figure out a better way or we need
to revert. However, given the various setgid bugs that we found just in
the last two years this is a regression risk we should take.
Associated with this change is a new set of fstests to enforce the
semantics for all new filesystems.
Link: https://lore.kernel.org/ceph-devel/20220427092201.wvsdjbnc7b4dttaw@wittgenstein [1]
Link: e014f37db1 ("xfs: use setattr_copy to set vfs inode attributes") [2]
Link: 01ea173e10 ("xfs: fix up non-directory creation in SGID directories") [3]
Link: fd84bfdddd ("ceph: fix up non-directory creation in SGID directories") [4]
Link: https://lore.kernel.org/r/1657779088-2242-3-git-send-email-xuyang2018.jy@fujitsu.com
Suggested-by: Dave Chinner <david@fromorbit.com>
Suggested-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-and-Tested-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
[<brauner@kernel.org>: rewrote commit message]
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
