* [PATCH 5.10 000/286] 5.10.209-rc1 review
@ 2024-01-22 23:55 Greg Kroah-Hartman
2024-01-23 3:32 ` Dominique Martinet
` (3 more replies)
0 siblings, 4 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2024-01-22 23:55 UTC (permalink / raw)
To: stable
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml
This is the start of the stable review cycle for the 5.10.209 release.
There are 286 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.209-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 5.10.209-rc1
Marek Szyprowski <m.szyprowski@samsung.com>
i2c: s3c24xx: fix transferring more than one message in polling mode
Marek Szyprowski <m.szyprowski@samsung.com>
i2c: s3c24xx: fix read transfers in polling mode
Amit Cohen <amcohen@nvidia.com>
selftests: mlxsw: qos_pfc: Adjust the test to support 8 lanes
Petr Machata <petrm@nvidia.com>
selftests: mlxsw: qos_pfc: Convert to iproute2 dcb
Ido Schimmel <idosch@nvidia.com>
mlxsw: spectrum_acl_tcam: Fix stack corruption
Ido Schimmel <idosch@nvidia.com>
mlxsw: spectrum_acl_tcam: Reorder functions to avoid forward declarations
Ido Schimmel <idosch@nvidia.com>
mlxsw: spectrum_acl_tcam: Make fini symmetric to init
Ido Schimmel <idosch@nvidia.com>
mlxsw: spectrum_acl_tcam: Add missing mutex_destroy()
Christophe JAILLET <christophe.jaillet@wanadoo.fr>
mlxsw: spectrum: Use 'bitmap_zalloc()' when applicable
Amit Cohen <amcohen@nvidia.com>
mlxsw: spectrum_acl_erp: Fix error flow of pool allocation failure
Ludvig Pärsson <ludvig.parsson@axis.com>
ethtool: netlink: Add missing ethnl_ops_begin/complete
Christophe JAILLET <christophe.jaillet@wanadoo.fr>
kdb: Fix a potential buffer overflow in kdb_local()
Fedor Pchelkin <pchelkin@ispras.ru>
ipvs: avoid stat macros calls from preemptible context
Pablo Neira Ayuso <pablo@netfilter.org>
netfilter: nf_tables: reject NFT_SET_CONCAT with not field length description
Pablo Neira Ayuso <pablo@netfilter.org>
netfilter: nf_tables: skip dead set elements in netlink dump
Pablo Neira Ayuso <pablo@netfilter.org>
netfilter: nf_tables: do not allow mismatch field size and set key length
Kunwu Chan <chentao@kylinos.cn>
net: dsa: vsc73xx: Add null pointer check to vsc73xx_gpio_probe
Nikita Yushchenko <nikita.yoush@cogentembedded.com>
net: ravb: Fix dma_addr_t truncation in error case
Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
net: phy: micrel: populate .soft_reset for KSZ9131
Sanjuán García, Jorge <Jorge.SanjuanGarcia@duagon.com>
net: ethernet: ti: am65-cpsw: Fix max mtu to fit ethernet frames
Lin Ma <linma@zju.edu.cn>
net: qualcomm: rmnet: fix global oob in rmnet_policy
Niklas Schnelle <schnelle@linux.ibm.com>
s390/pci: fix max size calculation in zpci_memcpy_toio()
Siddharth Vadapalli <s-vadapalli@ti.com>
PCI: keystone: Fix race condition when initializing PHYs
Maurizio Lombardi <mlombard@redhat.com>
nvmet-tcp: Fix the H2C expected PDU len calculation
Christoph Niedermaier <cniedermaier@dh-electronics.com>
serial: imx: Correct clock error message in function probe()
Fedor Pchelkin <pchelkin@ispras.ru>
apparmor: avoid crash when parsed profile name is empty
Ian Rogers <irogers@google.com>
perf env: Avoid recursively taking env->bpf_progs.lock
Maurizio Lombardi <mlombard@redhat.com>
nvmet-tcp: fix a crash in nvmet_req_complete()
Maurizio Lombardi <mlombard@redhat.com>
nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length
Oliver Neukum <oneukum@suse.com>
usb: cdc-acm: return correct error code on unsupported break
Jiri Slaby (SUSE) <jirislaby@kernel.org>
tty: use 'if' in send_break() instead of 'goto'
Jiri Slaby (SUSE) <jirislaby@kernel.org>
tty: don't check for signal_pending() in send_break()
Jiri Slaby (SUSE) <jirislaby@kernel.org>
tty: early return from send_break() on TTY_DRIVER_HARDWARE_BREAK
Jiri Slaby (SUSE) <jirislaby@kernel.org>
tty: change tty_write_lock()'s ndelay parameter to bool
Namhyung Kim <namhyung@kernel.org>
perf genelf: Set ELF program header addresses properly
Nuno Sa <nuno.sa@analog.com>
iio: adc: ad9467: fix scale setting
Nuno Sa <nuno.sa@analog.com>
iio: adc: ad9467: don't ignore error codes
Nuno Sa <nuno.sa@analog.com>
iio: adc: ad9467: fix reset gpio handling
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
iio: adc: ad9467: Benefit from devm_clk_get_enabled() to simplify
Paul Geurts <paul_geurts@live.nl>
serial: imx: fix tx statemachine deadlock
Sakari Ailus <sakari.ailus@linux.intel.com>
software node: Let args be NULL in software_node_get_reference_args
Sakari Ailus <sakari.ailus@linux.intel.com>
acpi: property: Let args be NULL in __acpi_node_get_property_reference
Arnaldo Carvalho de Melo <acme@redhat.com>
libapi: Add missing linux/types.h header to get the __u64 type on io.h
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed
Jan Palus <jpalus@fastmail.com>
power: supply: cw2015: correct time_to_empty units in sysfs
Christophe JAILLET <christophe.jaillet@wanadoo.fr>
MIPS: Alchemy: Fix an out-of-bound access in db1550_dev_setup()
Christophe JAILLET <christophe.jaillet@wanadoo.fr>
MIPS: Alchemy: Fix an out-of-bound access in db1200_dev_setup()
Serge Semin <fancer.lancer@gmail.com>
mips: Fix incorrect max_low_pfn adjustment
Serge Semin <fancer.lancer@gmail.com>
mips: dmi: Fix early remap on MIPS32
Dang Huynh <danct12@riseup.net>
leds: aw2013: Select missing dependency REGMAP_I2C
Kunwu Chan <chentao@kylinos.cn>
mfd: syscon: Fix null pointer dereference in of_syscon_register()
Jason Gerecke <jason.gerecke@wacom.com>
HID: wacom: Correct behavior when processing some confidence == false touches
Marcelo Schmitt <marcelo.schmitt@analog.com>
iio: adc: ad7091r: Pass iio_dev to event handler
Oliver Upton <oliver.upton@linux.dev>
KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache
Marc Zyngier <maz@kernel.org>
KVM: arm64: vgic-v4: Restore pending state on host userspace write
Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
x86/kvm: Do not try to disable kvmclock if it was not enabled
David Lin <yu-hao.lin@nxp.com>
wifi: mwifiex: configure BSSID consistently when starting AP
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
wifi: rtlwifi: Convert LNKCTL change to PCIe cap RMW accessors
Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
wifi: rtlwifi: Remove bogus and dangerous ASPM disable/enable code
Rob Clark <robdclark@chromium.org>
iommu/arm-smmu-qcom: Add missing GMU entry to match table
Gui-Dong Han <2045gemini@gmail.com>
Bluetooth: Fix atomicity violation in {min,max}_key_size_set
Stefan Berger <stefanb@linux.ibm.com>
rootfs: Fix support for rootfstype= when root= is given
Jens Axboe <axboe@kernel.dk>
io_uring/rw: ensure io->bytes_done is always initialized
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
pwm: jz4740: Don't use dev_err_probe() in .request()
Nam Cao <namcao@linutronix.de>
fbdev: flush deferred work in fb_deferred_io_fsync()
Çağhan Demir <caghandemir@marun.edu.tr>
ALSA: hda/relatek: Enable Mute LED on HP Laptop 15s-fq2xxx
Takashi Iwai <tiwai@suse.de>
ALSA: oxygen: Fix right channel of capture volume mixer
Christoph Niedermaier <cniedermaier@dh-electronics.com>
serial: imx: Ensure that imx_uart_rs485_config() is called with enabled clock
Gui-Dong Han <2045gemini@gmail.com>
usb: mon: Fix atomicity violation in mon_bin_vma_fault
RD Babiera <rdbabiera@google.com>
usb: typec: class: fix typec_altmode_put_partner to put plugs
Heikki Krogerus <heikki.krogerus@linux.intel.com>
Revert "usb: typec: class: fix typec_altmode_put_partner to put plugs"
Xu Yang <xu.yang_2@nxp.com>
usb: chipidea: wait controller resume finished for wakeup irq
Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Revert "usb: dwc3: don't reset device side if dwc3 was configured as host-only"
Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Revert "usb: dwc3: Soft reset phy on probe for host"
Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
usb: dwc: ep0: Update request status in dwc3_ep0_stall_restart
Xu Yang <xu.yang_2@nxp.com>
usb: phy: mxs: remove CONFIG_USB_OTG condition for mxs_phy_is_otg_host()
Heiko Carstens <hca@linux.ibm.com>
tick-sched: Fix idle and iowait sleeptime accounting vs CPU hotplug
Carlos Llamas <cmllamas@google.com>
binder: fix race between mmput() and do_exit()
Jan Beulich <jbeulich@suse.com>
xen-netback: don't produce zero-size SKB frags
Chukun Pan <amadeus@jmu.edu.cn>
net: ethernet: mtk_eth_soc: remove duplicate if statements
Masami Hiramatsu (Google) <mhiramat@kernel.org>
kprobes: Fix to handle forcibly unoptimized kprobes on freeing_list
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "ASoC: atmel: Remove system clock tree configuration for at91sam9g20ek"
Wei Yongjun <weiyongjun1@huawei.com>
virtio-crypto: fix memory leak in virtio_crypto_alg_skcipher_close_session()
lei he <helei.sig11@bytedance.com>
virtio-crypto: fix memory-leak
Ren Zhijie <renzhijie2@huawei.com>
dma-mapping: Fix build error unused-value
Hans de Goede <hdegoede@redhat.com>
Input: atkbd - use ab83 as id when skipping the getid command
Carlos Llamas <cmllamas@google.com>
binder: fix use-after-free in shinker's callback
Carlos Llamas <cmllamas@google.com>
binder: fix unused alloc->free_async_space
Carlos Llamas <cmllamas@google.com>
binder: fix async space check for 0-sized buffers
David Howells <dhowells@redhat.com>
keys, dns: Fix size check of V1 server-list header
Geert Uytterhoeven <geert+renesas@glider.be>
of: unittest: Fix of_count_phandle_with_args() expected value message
Christian A. Ehrhardt <lk@c--e.de>
of: Fix double free in of_parse_phandle_with_args_map
Sergey Gorenko <sergeygo@nvidia.com>
IB/iser: Prevent invalidating wrong MR
Peter Robinson <pbrobinson@gmail.com>
mmc: sdhci_omap: Fix TI SoC dependencies
Peter Robinson <pbrobinson@gmail.com>
mmc: sdhci_am654: Fix TI SoC dependencies
Philipp Zabel <p.zabel@pengutronix.de>
pwm: stm32: Fix enable count for clk in .probe()
Philipp Zabel <p.zabel@pengutronix.de>
pwm: stm32: Use hweight32 in stm32_pwm_detect_channels
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
pwm: stm32: Use regmap_clear_bits and regmap_set_bits where applicable
Théo Lebrun <theo.lebrun@bootlin.com>
clk: fixed-rate: fix clk_hw_register_fixed_rate_with_accuracy_parent_hw
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
clk: fixed-rate: add devm_clk_hw_register_fixed_rate
Su Hui <suhui@nfschina.com>
clk: si5341: fix an error code problem in si5341_output_clk_set_rate
Vignesh Raghavendra <vigneshr@ti.com>
watchdog: rti_wdt: Drop runtime pm reference count when watchdog is unused
Stefan Wahren <wahrenst@gmx.net>
watchdog: bcm2835_wdt: Fix WDIOC_SETTIMEOUT handling
Jerry Hoemann <jerry.hoemann@hpe.com>
watchdog/hpwdt: Only claim UNKNOWN NMI if from iLO
Curtis Klein <curtis.klein@hpe.com>
watchdog: set cdev owner before adding
Jay Buddhabhatti <jay.buddhabhatti@amd.com>
drivers: clk: zynqmp: update divider round rate logic
Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
clk: zynqmp: Add a check for NULL pointer
Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
clk: zynqmp: make bestdiv unsigned
Jay Buddhabhatti <jay.buddhabhatti@amd.com>
drivers: clk: zynqmp: calculate closest mux rate
Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
clk: qcom: videocc-sm8150: Add missing PLL config property
Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
clk: qcom: videocc-sm8150: Update the videocc resets
Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
dt-bindings: clock: Update the videocc resets for sm8150
Zhipeng Lu <alexious@zju.edu.cn>
gpu/drm/radeon: fix two memleaks in radeon_vm_init
Zhipeng Lu <alexious@zju.edu.cn>
drivers/amd/pm: fix a use-after-free in kv_parse_power_table
Zhipeng Lu <alexious@zju.edu.cn>
drm/amd/pm: fix a double-free in si_dpm_init
Alex Deucher <alexander.deucher@amd.com>
drm/amdgpu/debugfs: fix error code when smc register accessors are NULL
Christophe JAILLET <christophe.jaillet@wanadoo.fr>
media: dvb-frontends: m88ds3103: Fix a memory leak in an error handling path of m88ds3103_probe()
Dan Carpenter <dan.carpenter@linaro.org>
media: dvbdev: drop refcount on error path in dvb_device_open()
Chao Yu <chao@kernel.org>
f2fs: fix to update iostat correctly in f2fs_filemap_fault()
Chao Yu <chao@kernel.org>
f2fs: fix to check compress file in f2fs_move_file_range()
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
media: rkisp1: Disable runtime PM in probe error path
Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
clk: qcom: gpucc-sm8150: Update the gpu_cc_pll1 config
Zhipeng Lu <alexious@zju.edu.cn>
media: cx231xx: fix a memleak in cx231xx_init_isoc
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
drm/bridge: tc358767: Fix return value on error case
Zhipeng Lu <alexious@zju.edu.cn>
drm/radeon/trinity_dpm: fix a memleak in trinity_parse_power_table
Zhipeng Lu <alexious@zju.edu.cn>
drm/radeon/dpm: fix a memleak in sumo_parse_power_table
Yang Yingliang <yangyingliang@huawei.com>
drm/radeon: check the alloc_workqueue return value in radeon_crtc_init()
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
drm/drv: propagate errors from drm_modeset_register_all()
Konrad Dybcio <konrad.dybcio@linaro.org>
drm/msm/dsi: Use pm_runtime_resume_and_get to prevent refcnt leaks
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
drm/msm/mdp4: flush vblank event on disable
Linus Walleij <linus.walleij@linaro.org>
ASoC: cs35l34: Fix GPIO name and drop legacy include
Linus Walleij <linus.walleij@linaro.org>
ASoC: cs35l33: Fix GPIO name and drop legacy include
Nikita Zhandarovich <n.zhandarovich@fintech.ru>
drm/radeon: check return value of radeon_ring_lock()
Nikita Zhandarovich <n.zhandarovich@fintech.ru>
drm/radeon/r100: Fix integer overflow issues in r100_cs_track_check()
Nikita Zhandarovich <n.zhandarovich@fintech.ru>
drm/radeon/r600_cs: Fix possible int overflows in r600_cs_check_reg()
Chao Yu <chao@kernel.org>
f2fs: fix to avoid dirent corruption
Dario Binacchi <dario.binacchi@amarulasolutions.com>
drm/bridge: Fix typo in post_disable() description
Ricardo B. Marliere <ricardo@marliere.net>
media: pvrusb2: fix use after free on context disconnection
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function
Abhinav Singh <singhabhinav9051571833@gmail.com>
drm/nouveau/fence:: fix warning directly dereferencing a rcu pointer
Paul E. McKenney <paulmck@kernel.org>
rcu: Create an unrcu_pointer() to remove __rcu from a pointer
Chris Morgan <macromorgan@hotmail.com>
drm/panel-elida-kd35t133: hold panel in reset for unprepare
Leon Romanovsky <leon@kernel.org>
RDMA/usnic: Silence uninitialized symbol smatch warnings
Arnd Bergmann <arnd@arndb.de>
ARM: davinci: always select CONFIG_CPU_ARM926T
Eric Dumazet <edumazet@google.com>
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
Francesco Dolcini <francesco.dolcini@toradex.com>
Bluetooth: btmtkuart: fix recv_buf() return value
Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: Fix bogus check for re-auth no supported with non-ssp
Florian Westphal <fw@strlen.de>
netfilter: nf_tables: mark newset as dead on transaction abort
Su Hui <suhui@nfschina.com>
wifi: rtlwifi: rtl8192se: using calculate_bit_shift()
Su Hui <suhui@nfschina.com>
wifi: rtlwifi: rtl8192ee: using calculate_bit_shift()
Su Hui <suhui@nfschina.com>
wifi: rtlwifi: rtl8192de: using calculate_bit_shift()
Colin Ian King <colin.king@canonical.com>
rtlwifi: rtl8192de: make arrays static const, makes object smaller
Su Hui <suhui@nfschina.com>
wifi: rtlwifi: rtl8192ce: using calculate_bit_shift()
Su Hui <suhui@nfschina.com>
wifi: rtlwifi: rtl8192cu: using calculate_bit_shift()
Su Hui <suhui@nfschina.com>
wifi: rtlwifi: rtl8192c: using calculate_bit_shift()
Su Hui <suhui@nfschina.com>
wifi: rtlwifi: rtl8188ee: phy: using calculate_bit_shift()
Su Hui <suhui@nfschina.com>
wifi: rtlwifi: add calculate_bit_shift()
Joakim Zhang <joakim.zhang@cixtech.com>
dma-mapping: clear dev->dma_mem to NULL after freeing it
Mark-PK Tsai <mark-pk.tsai@mediatek.com>
dma-mapping: Add dma_release_coherent_memory to DMA API
Arseniy Krasnov <avkrasnov@salutedevices.com>
virtio/vsock: fix logic which reduces credit update messages
Hangbin Liu <liuhangbin@gmail.com>
selftests/net: fix grep checking for fib_nexthop_multiprefix
Yihang Li <liyihang9@huawei.com>
scsi: hisi_sas: Replace with standard error code return value
Andrei Matei <andreimatei1@gmail.com>
bpf: Fix verification of indirect var-off stack access
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
arm64: dts: qcom: sdm845-db845c: correct LED panic indicator
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
arm64: dts: qcom: qrb5165-rb5: correct LED panic indicator
Artem Chernyshev <artem.chernyshev@red-soft.ru>
scsi: fnic: Return error if vmalloc() failed
Andrii Nakryiko <andrii@kernel.org>
bpf: fix check for attempt to corrupt spilled pointer
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
arm64: dts: ti: k3-am65-main: Fix DSS irq trigger type
Su Hui <suhui@nfschina.com>
wifi: rtlwifi: rtl8821ae: phy: fix an undefined bitwise shift behavior
Dmitry Rokosov <ddrokosov@sberdevices.ru>
firmware: meson_sm: populate platform devices from sm device tree data
Christophe JAILLET <christophe.jaillet@wanadoo.fr>
firmware: ti_sci: Fix an off-by-one in ti_sci_debugfs_create()
Peter Delevoryas <peter@pjd.dev>
net/ncsi: Fix netlink major/minor version numbers
Bhaskar Chowdhury <unixbhaskar@gmail.com>
ncsi: internal.h: Fix a spello
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
ARM: dts: qcom: apq8064: correct XOADC register address
Arnd Bergmann <arnd@arndb.de>
wifi: libertas: stop selecting wext
Luca Weiss <luca.weiss@fairphone.com>
wifi: ath11k: Defer on rproc_get failure
Jordan Rome <jordalgo@meta.com>
bpf: Add crosstask check to __bpf_get_stack
Florian Lehner <dev@der-flo.net>
bpf, lpm: Fix check prefixlen before walking trie
Chih-Kang Chang <gary.chang@realtek.com>
wifi: rtw88: fix RX filter in FIF_ALLMULTI flag
Trond Myklebust <trond.myklebust@hammerspace.com>
NFSv4.1/pnfs: Ensure we handle the error NFS4ERR_RETURNCONFLICT
Benjamin Coddington <bcodding@redhat.com>
blocklayoutdriver: Fix reference leak of pnfs_device_node
Chengming Zhou <zhouchengming@bytedance.com>
crypto: scomp - fix req->dst buffer overflow
Ovidiu Panait <ovidiu.panait@windriver.com>
crypto: sahara - do not resize req->src when doing hash operations
Ovidiu Panait <ovidiu.panait@windriver.com>
crypto: sahara - fix processing hash requests with req->nbytes < sg->length
Ovidiu Panait <ovidiu.panait@windriver.com>
crypto: sahara - improve error handling in sahara_sha_process()
Ovidiu Panait <ovidiu.panait@windriver.com>
crypto: sahara - fix wait_for_completion_timeout() error handling
Ovidiu Panait <ovidiu.panait@windriver.com>
crypto: sahara - fix ahash reqsize
Ovidiu Panait <ovidiu.panait@windriver.com>
crypto: sahara - handle zero-length aes requests
Ovidiu Panait <ovidiu.panait@windriver.com>
crypto: sahara - avoid skcipher fallback code duplication
wangyangxin <wangyangxin1@huawei.com>
crypto: virtio - Wait for tasklet to complete on device remove
Osama Muhammad <osmtendev@gmail.com>
gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump
Andreas Gruenbacher <agruenba@redhat.com>
gfs2: Also reflect single-block allocations in rgd->rd_extfail_pt
Andreas Gruenbacher <agruenba@redhat.com>
Revert "gfs2: Don't reject a supposedly full bitmap if we have blocks reserved"
Christian Brauner <brauner@kernel.org>
fs: indicate request originates from old mount API
Sergey Shtylyov <s.shtylyov@omp.ru>
pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
Ovidiu Panait <ovidiu.panait@windriver.com>
crypto: sahara - fix error handling in sahara_hw_descriptor_create()
Ovidiu Panait <ovidiu.panait@windriver.com>
crypto: sahara - fix processing requests with cryptlen < sg->length
Ovidiu Panait <ovidiu.panait@windriver.com>
crypto: sahara - fix ahash selftest failure
Ovidiu Panait <ovidiu.panait@windriver.com>
crypto: sahara - fix cbc selftest failure
Ovidiu Panait <ovidiu.panait@windriver.com>
crypto: sahara - remove FLAGS_NEW_KEY logic
Herbert Xu <herbert@gondor.apana.org.au>
crypto: af_alg - Disallow multiple in-flight AIO requests
Dinghao Liu <dinghao.liu@zju.edu.cn>
crypto: ccp - fix memleak in ccp_init_dm_workarea
Chen Ni <nichen@iscas.ac.cn>
crypto: sa2ul - Return crypto_aead_setkey to transfer the error
Gonglei (Arei) <arei.gonglei@huawei.com>
crypto: virtio - Handle dataq logic with tasklet
zhenwei pi <pizhenwei@bytedance.com>
virtio-crypto: wait ctrl queue instead of busy polling
zhenwei pi <pizhenwei@bytedance.com>
virtio-crypto: use private buffer for control request
zhenwei pi <pizhenwei@bytedance.com>
virtio-crypto: change code style
zhenwei pi <pizhenwei@bytedance.com>
virtio-crypto: implement RSA algorithm
zhenwei pi <pizhenwei@bytedance.com>
virtio-crypto: introduce akcipher service
zhenwei pi <pizhenwei@bytedance.com>
virtio_crypto: Introduce VIRTIO_CRYPTO_NOSPC
Mickaël Salaün <mic@digikod.net>
selinux: Fix error priority for bind with AF_UNSPEC on PF_INET6 socket
ZhaoLong Wang <wangzhaolong1@huawei.com>
mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
Tony Luck <tony.luck@intel.com>
ACPI: extlog: Clear Extended Error Log status when RAS_CEC handled the error
Wolfram Sang <wsa+renesas@sang-engineering.com>
spi: sh-msiof: Enforce fixed DTDL for R-Car H3
Ilias Apalodimas <ilias.apalodimas@linaro.org>
efivarfs: force RO when remounting if SetVariable is not supported
Gavrilov Ilia <Ilia.Gavrilov@infotecs.ru>
calipso: fix memory leak in netlbl_calipso_add_pass()
Zheng Yejian <zhengyejian1@huawei.com>
netlabel: remove unused parameter in netlbl_netlink_auditinfo()
Andrew Lunn <andrew@lunn.ch>
net: netlabel: Fix kerneldoc warnings
Alexandra Diupina <adiupina@astralinux.ru>
cpufreq: scmi: process the result of devm_of_clk_add_hw_provider()
Rob Herring <robh@kernel.org>
cpufreq: Use of_property_present() for testing DT property presence
Rob Herring <robh@kernel.org>
of: Add of_property_present() helper
Michael Walle <michael@walle.cc>
of: property: define of_property_read_u{8,16,32,64}_array() unconditionally
Nikita Kiryushin <kiryushin@ancud.ru>
ACPI: LPIT: Avoid u32 multiplication overflow
Nikita Kiryushin <kiryushin@ancud.ru>
ACPI: video: check for error while searching for backlight device parent
Ronald Monthero <debug.penguin32@gmail.com>
mtd: rawnand: Increment IFC_TIMEOUT_MSECS for nand controller response
Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
spi: spi-zynqmp-gqspi: fix driver kconfig dependencies
Kunwu Chan <chentao@kylinos.cn>
powerpc/imc-pmu: Add a null pointer check in update_events_in_group()
Kunwu Chan <chentao@kylinos.cn>
powerpc/powernv: Add a null pointer check in opal_powercap_init()
Kunwu Chan <chentao@kylinos.cn>
powerpc/powernv: Add a null pointer check in opal_event_init()
Kunwu Chan <chentao@kylinos.cn>
powerpc/powernv: Add a null pointer check to scom_debug_init_one()
Michael Ellerman <mpe@ellerman.id.au>
selftests/powerpc: Fix error handling in FPU/VMX preemption tests
Nathan Lynch <nathanl@linux.ibm.com>
powerpc/pseries/memhp: Fix access beyond end of drmem array
Laurent Dufour <ldufour@linux.ibm.com>
powerpc/pseries/memhotplug: Quieten some DLPAR operations
Randy Dunlap <rdunlap@infradead.org>
powerpc/44x: select I2C for CURRITUCK
Christophe Leroy <christophe.leroy@csgroup.eu>
powerpc: Remove in_kernel_text()
Masahiro Yamada <masahiroy@kernel.org>
powerpc: add crtsavres.o to always-y instead of extra-y
Arnd Bergmann <arnd@arndb.de>
EDAC/thunderx: Fix possible out-of-bounds string access
Colin Ian King <colin.i.king@gmail.com>
x86/lib: Fix overflow when counting digits
James Clark <james.clark@arm.com>
coresight: etm4x: Fix width of CCITMIN field
LeoLiuoc <LeoLiu-oc@zhaoxin.com>
PCI: Add ACS quirk for more Zhaoxin Root Ports
Cameron Williams <cang1@live.co.uk>
parport: parport_serial: Add Brainboxes device IDs and geometry
Cameron Williams <cang1@live.co.uk>
parport: parport_serial: Add Brainboxes BAR details
Guanghui Feng <guanghuifeng@linux.alibaba.com>
uio: Fix use-after-free in uio_open
Carlos Llamas <cmllamas@google.com>
binder: fix comment on binder_alloc_new_buf() return value
Carlos Llamas <cmllamas@google.com>
binder: fix trivial typo of binder_free_buf_locked()
Carlos Llamas <cmllamas@google.com>
binder: use EPOLLERR from eventpoll.h
Hans de Goede <hdegoede@redhat.com>
ACPI: resource: Add another DMI match for the TongFang GMxXGxx
Jani Nikula <jani.nikula@intel.com>
drm/crtc: fix uninitialized variable use
Stefan Wahren <wahrenst@gmx.net>
ARM: sun9i: smp: fix return code check of of_property_match_string
Sarannya S <quic_sarannya@quicinc.com>
net: qrtr: ns: Return 0 if server port is not present
Matthew Wilcox (Oracle) <willy@infradead.org>
ida: Fix crash in ida_free when the bitmap is empty
Jensen Huang <jensenhuang@friendlyarm.com>
i2c: rk3x: fix potential spinlock recursion on poll
Luca Weiss <luca@z3ntu.xyz>
Input: xpad - add Razer Wolverine V2 support
Vineet Gupta <vgupta@kernel.org>
ARC: fix spare error
Vineeth Vijayan <vneethv@linux.ibm.com>
s390/scm: fix virtual vs physical address confusion
Esther Shimanovich <eshimanovich@chromium.org>
Input: i8042 - add nomux quirk for Acer P459-G2-M
Hans de Goede <hdegoede@redhat.com>
Input: atkbd - skip ATKBD_CMD_GETID in translated mode
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
reset: hisilicon: hi6220: fix Wvoid-pointer-to-enum-cast warning
Steven Rostedt (Google) <rostedt@goodmis.org>
ring-buffer: Do not record in NMI if the arch does not support cmpxchg in NMI
Steven Rostedt (Google) <rostedt@goodmis.org>
tracing: Add size check when printing trace_marker output
Steven Rostedt (Google) <rostedt@goodmis.org>
tracing: Have large events show up as '[LINE TOO BIG]' instead of nothing
Ye Bin <yebin10@huawei.com>
jbd2: fix soft lockup in journal_finish_inode_data_buffers()
Judy Hsiao <judyhsiao@chromium.org>
neighbour: Don't let neigh_forced_gc() disable preemption for long
Ziqi Zhao <astrajoan@yahoo.com>
drm/crtc: Fix uninit-value bug in drm_mode_setcrtc
Zhang Yi <yi.zhang@huawei.com>
jbd2: correct the printing of write_flags in jbd2_write_superblock()
Weihao Li <cn.liweihao@gmail.com>
clk: rockchip: rk3128: Fix HCLK_OTG gate register
Inki Dae <inki.dae@samsung.com>
drm/exynos: fix a wrong error checking
Xiang Yang <xiangyang3@huawei.com>
drm/exynos: fix a potential error pointer dereference
Keith Busch <kbusch@kernel.org>
nvme: introduce helper function to get ctrl state
David Rau <David.Rau.opensource@dm.renesas.com>
ASoC: da7219: Support low DC impedance headset
Thinh Tran <thinhtr@linux.vnet.ibm.com>
net/tg3: fix race condition in tg3_reset_task()
Dave Airlie <airlied@redhat.com>
nouveau/tu102: flush all pdbs on vmm flush
Shuming Fan <shumingf@realtek.com>
ASoC: rt5650: add mutex to avoid the jack detection failure
Maciej Strozek <mstrozek@opensource.cirrus.com>
ASoC: cs43130: Fix incorrect frame delay configuration
Maciej Strozek <mstrozek@opensource.cirrus.com>
ASoC: cs43130: Fix the position of const qualifier
Kamil Duljas <kamil.duljas@gmail.com>
ASoC: Intel: Skylake: mem leak in skl register function
David Lin <CTLIN0@nuvoton.com>
ASoC: nau8822: Fix incorrect type in assignment and cast to restricted __be16
Kamil Duljas <kamil.duljas@gmail.com>
ASoC: Intel: Skylake: Fix mem leak in few functions
Charles Keepax <ckeepax@opensource.cirrus.com>
ASoC: wm8974: Correct boost mixer inputs
Keith Busch <kbusch@kernel.org>
nvme-core: check for too small lba shift
Lu Yao <yaolu@kylinos.cn>
drm/amdgpu: Fix cat debugfs amdgpu_regs_didt causes kernel null pointer
Johannes Berg <johannes.berg@intel.com>
debugfs: fix automount d_fsdata usage
Edward Adam Davis <eadavis@qq.com>
mptcp: fix uninit-value in mptcp_incoming_options
Vasiliy Kovalev <kovalev@altlinux.org>
ALSA: hda - Fix speaker and headset mic pin config for CHUWI CoreBook XPro
Charles Keepax <ckeepax@opensource.cirrus.com>
pinctrl: lochnagar: Don't build on MIPS
Eric Biggers <ebiggers@google.com>
f2fs: explicitly null-terminate the xattr list
-------------
Diffstat:
Makefile | 4 +-
arch/arc/kernel/signal.c | 6 +-
arch/arm/boot/dts/qcom-apq8064.dtsi | 2 +-
arch/arm/mach-davinci/Kconfig | 1 +
arch/arm/mach-sunxi/mc_smp.c | 4 +-
arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 2 +-
arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 2 +-
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 2 +-
arch/arm64/kvm/vgic/vgic-its.c | 5 +
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 27 +-
arch/mips/alchemy/devboards/db1200.c | 2 +-
arch/mips/alchemy/devboards/db1550.c | 2 +-
arch/mips/include/asm/dmi.h | 2 +-
arch/mips/kernel/setup.c | 4 +-
arch/powerpc/include/asm/sections.h | 8 -
arch/powerpc/lib/Makefile | 2 +-
arch/powerpc/perf/imc-pmu.c | 6 +
arch/powerpc/platforms/44x/Kconfig | 1 +
arch/powerpc/platforms/powernv/opal-irqchip.c | 2 +
arch/powerpc/platforms/powernv/opal-powercap.c | 6 +
arch/powerpc/platforms/powernv/opal-xscom.c | 5 +
arch/powerpc/platforms/pseries/hotplug-memory.c | 21 +-
arch/s390/include/asm/pci_io.h | 32 +-
arch/s390/pci/pci_mmio.c | 12 +-
arch/x86/kernel/kvmclock.c | 12 +-
arch/x86/lib/misc.c | 2 +-
crypto/af_alg.c | 14 +-
crypto/scompress.c | 6 +
drivers/acpi/acpi_extlog.c | 7 +-
drivers/acpi/acpi_lpit.c | 2 +-
drivers/acpi/acpi_video.c | 12 +-
drivers/acpi/property.c | 4 +
drivers/acpi/resource.c | 7 +
drivers/android/binder.c | 2 +-
drivers/android/binder_alloc.c | 32 +-
drivers/base/swnode.c | 3 +
drivers/bluetooth/btmtkuart.c | 11 +-
drivers/clk/clk-fixed-rate.c | 28 +-
drivers/clk/clk-si5341.c | 4 +-
drivers/clk/qcom/gpucc-sm8150.c | 4 +-
drivers/clk/qcom/videocc-sm8150.c | 5 +
drivers/clk/rockchip/clk-rk3128.c | 2 +-
drivers/clk/zynqmp/clk-mux-zynqmp.c | 2 +-
drivers/clk/zynqmp/divider.c | 63 +--
drivers/cpufreq/cpufreq-dt-platdev.c | 2 +-
drivers/cpufreq/imx-cpufreq-dt.c | 2 +-
drivers/cpufreq/imx6q-cpufreq.c | 4 +-
drivers/cpufreq/scmi-cpufreq.c | 7 +-
drivers/cpufreq/tegra20-cpufreq.c | 2 +-
drivers/crypto/ccp/ccp-ops.c | 5 +-
drivers/crypto/sa2ul.c | 3 +-
drivers/crypto/sahara.c | 248 ++++-----
drivers/crypto/virtio/Kconfig | 3 +
drivers/crypto/virtio/Makefile | 1 +
.../crypto/virtio/virtio_crypto_akcipher_algs.c | 591 +++++++++++++++++++++
drivers/crypto/virtio/virtio_crypto_algs.c | 143 +++--
drivers/crypto/virtio/virtio_crypto_common.h | 26 +-
drivers/crypto/virtio/virtio_crypto_core.c | 82 ++-
drivers/crypto/virtio/virtio_crypto_mgr.c | 11 +
drivers/edac/thunderx_edac.c | 10 +-
drivers/firmware/meson/meson_sm.c | 5 +-
drivers/firmware/ti_sci.c | 10 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 10 +-
drivers/gpu/drm/amd/pm/powerplay/kv_dpm.c | 4 +-
drivers/gpu/drm/amd/pm/powerplay/si_dpm.c | 5 +-
drivers/gpu/drm/bridge/tc358767.c | 2 +-
drivers/gpu/drm/bridge/ti-tpd12s015.c | 4 +-
drivers/gpu/drm/drm_crtc.c | 8 +-
drivers/gpu/drm/drm_drv.c | 10 +-
drivers/gpu/drm/exynos/exynos_drm_dma.c | 8 +-
drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 9 +
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 +-
drivers/gpu/drm/nouveau/nv04_fence.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmtu102.c | 2 +-
drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +
drivers/gpu/drm/radeon/r100.c | 4 +-
drivers/gpu/drm/radeon/r600_cs.c | 4 +-
drivers/gpu/drm/radeon/radeon_display.c | 7 +-
drivers/gpu/drm/radeon/radeon_vm.c | 8 +-
drivers/gpu/drm/radeon/si.c | 4 +
drivers/gpu/drm/radeon/sumo_dpm.c | 4 +-
drivers/gpu/drm/radeon/trinity_dpm.c | 4 +-
drivers/hid/wacom_wac.c | 32 +-
drivers/hwtracing/coresight/coresight-etm4x.h | 2 +-
drivers/i2c/busses/i2c-rk3x.c | 13 +-
drivers/i2c/busses/i2c-s3c2410.c | 40 +-
drivers/iio/adc/ad7091r-base.c | 6 +-
drivers/iio/adc/ad9467.c | 114 ++--
drivers/iio/adc/adi-axi-adc.c | 74 +--
drivers/infiniband/hw/mthca/mthca_cmd.c | 4 +-
drivers/infiniband/hw/mthca/mthca_main.c | 2 +-
drivers/infiniband/ulp/iser/iscsi_iser.h | 2 -
drivers/infiniband/ulp/iser/iser_initiator.c | 5 +-
drivers/infiniband/ulp/iser/iser_memory.c | 8 +-
drivers/infiniband/ulp/iser/iser_verbs.c | 1 -
drivers/input/joystick/xpad.c | 1 +
drivers/input/keyboard/atkbd.c | 50 +-
drivers/input/serio/i8042-acpipnpio.h | 8 +
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
drivers/leds/Kconfig | 1 +
drivers/media/dvb-core/dvbdev.c | 2 +
drivers/media/dvb-frontends/m88ds3103.c | 7 +-
drivers/media/usb/cx231xx/cx231xx-core.c | 2 +
drivers/media/usb/pvrusb2/pvrusb2-context.c | 3 +-
drivers/mfd/syscon.c | 4 +
drivers/mmc/host/Kconfig | 10 +-
drivers/mtd/mtd_blkdevs.c | 4 +-
drivers/mtd/nand/raw/fsl_ifc_nand.c | 2 +-
drivers/net/dsa/vitesse-vsc73xx-core.c | 2 +
drivers/net/ethernet/broadcom/tg3.c | 11 +-
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 1 -
.../ethernet/mellanox/mlxsw/spectrum_acl_atcam.c | 8 +-
.../net/ethernet/mellanox/mlxsw/spectrum_acl_erp.c | 8 +-
.../ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 131 ++---
drivers/net/ethernet/mellanox/mlxsw/spectrum_cnt.c | 9 +-
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 11 +-
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c | 2 +-
drivers/net/ethernet/renesas/ravb_main.c | 2 +-
drivers/net/ethernet/ti/am65-cpsw-nuss.c | 5 +-
drivers/net/phy/micrel.c | 1 +
drivers/net/wireless/ath/ath11k/ahb.c | 4 +-
drivers/net/wireless/marvell/libertas/Kconfig | 2 -
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 +
drivers/net/wireless/marvell/mwifiex/fw.h | 1 +
drivers/net/wireless/marvell/mwifiex/ioctl.h | 1 +
drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 8 +
drivers/net/wireless/realtek/rtlwifi/pci.c | 79 +--
drivers/net/wireless/realtek/rtlwifi/pci.h | 5 -
.../net/wireless/realtek/rtlwifi/rtl8188ee/phy.c | 14 +-
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.c | 12 +-
.../wireless/realtek/rtlwifi/rtl8192c/phy_common.h | 1 -
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192ce/phy.h | 1 -
.../net/wireless/realtek/rtlwifi/rtl8192cu/phy.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 61 +--
.../net/wireless/realtek/rtlwifi/rtl8192ee/phy.c | 16 +-
.../net/wireless/realtek/rtlwifi/rtl8192se/phy.c | 15 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 5 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 7 +
drivers/net/wireless/realtek/rtw88/mac80211.c | 4 +-
drivers/net/xen-netback/netback.c | 44 +-
drivers/nvme/host/core.c | 5 +-
drivers/nvme/host/nvme.h | 5 +
drivers/nvme/target/tcp.c | 20 +-
drivers/of/base.c | 1 +
drivers/of/unittest-data/tests-phandle.dtsi | 10 +-
drivers/of/unittest.c | 74 +--
drivers/parport/parport_serial.c | 64 +++
drivers/pci/controller/dwc/pci-keystone.c | 9 +
drivers/pci/quirks.c | 8 +-
drivers/pinctrl/cirrus/Kconfig | 3 +-
drivers/power/supply/cw2015_battery.c | 2 +-
drivers/pwm/pwm-jz4740.c | 7 +-
drivers/pwm/pwm-stm32.c | 63 +--
drivers/reset/hisilicon/hi6220_reset.c | 2 +-
drivers/s390/block/scm_blk.c | 7 +-
drivers/scsi/fnic/fnic_debugfs.c | 3 +-
drivers/scsi/hisi_sas/hisi_sas_main.c | 4 +-
drivers/scsi/hisi_sas/hisi_sas_v3_hw.c | 2 +-
drivers/spi/Kconfig | 3 +-
drivers/spi/spi-sh-msiof.c | 17 +
drivers/staging/media/rkisp1/rkisp1-dev.c | 3 +-
drivers/tty/serial/8250/8250_omap.c | 2 +-
drivers/tty/serial/imx.c | 29 +-
drivers/tty/tty.h | 2 +-
drivers/tty/tty_io.c | 35 +-
drivers/tty/tty_ioctl.c | 2 +-
drivers/uio/uio.c | 7 +-
drivers/usb/chipidea/core.c | 7 +
drivers/usb/class/cdc-acm.c | 3 +
drivers/usb/dwc3/core.c | 39 +-
drivers/usb/dwc3/ep0.c | 5 +-
drivers/usb/mon/mon_bin.c | 7 +-
drivers/usb/phy/phy-mxs-usb.c | 3 +-
drivers/usb/typec/class.c | 4 +-
drivers/video/fbdev/core/fb_defio.c | 6 +-
drivers/watchdog/bcm2835_wdt.c | 3 +-
drivers/watchdog/hpwdt.c | 2 +-
drivers/watchdog/rti_wdt.c | 13 +-
drivers/watchdog/watchdog_dev.c | 3 +-
fs/debugfs/file.c | 8 +
fs/debugfs/inode.c | 27 +-
fs/debugfs/internal.h | 10 +-
fs/efivarfs/super.c | 12 +
fs/f2fs/file.c | 7 +-
fs/f2fs/namei.c | 2 +-
fs/f2fs/xattr.c | 6 +
fs/gfs2/rgrp.c | 23 +-
fs/jbd2/commit.c | 1 +
fs/jbd2/journal.c | 4 +-
fs/namespace.c | 11 +
fs/nfs/blocklayout/blocklayout.c | 2 +
fs/nfs/nfs4proc.c | 3 +
fs/pstore/ram_core.c | 2 +-
include/crypto/if_alg.h | 3 +
include/drm/drm_bridge.h | 2 +-
include/dt-bindings/clock/qcom,videocc-sm8150.h | 4 +
include/linux/clk-provider.h | 33 +-
include/linux/dma-map-ops.h | 3 +
include/linux/iio/adc/adi-axi-adc.h | 4 +
include/linux/of.h | 291 +++++-----
include/linux/rcupdate.h | 14 +
include/net/bluetooth/hci_core.h | 1 -
include/uapi/linux/bpf.h | 3 +
include/uapi/linux/virtio_crypto.h | 82 ++-
init/do_mounts.c | 9 +-
io_uring/io_uring.c | 9 +-
kernel/bpf/lpm_trie.c | 3 +
kernel/bpf/stackmap.c | 11 +-
kernel/bpf/verifier.c | 16 +-
kernel/debug/kdb/kdb_main.c | 2 -
kernel/dma/coherent.c | 12 +-
kernel/kprobes.c | 23 +-
kernel/time/tick-sched.c | 5 +
kernel/trace/ring_buffer.c | 6 +
kernel/trace/trace.c | 6 +-
kernel/trace/trace_output.c | 6 +-
lib/idr.c | 2 +-
lib/test_ida.c | 40 ++
net/bluetooth/hci_conn.c | 8 +-
net/bluetooth/hci_debugfs.c | 12 +-
net/bluetooth/hci_event.c | 11 +-
net/core/neighbour.c | 9 +-
net/dns_resolver/dns_key.c | 2 +-
net/ethtool/features.c | 9 +-
net/ipv6/ip6_tunnel.c | 26 +-
net/mptcp/options.c | 1 +
net/ncsi/internal.h | 9 +-
net/ncsi/ncsi-netlink.c | 4 +-
net/ncsi/ncsi-pkt.h | 7 +-
net/ncsi/ncsi-rsp.c | 26 +-
net/netfilter/ipvs/ip_vs_xmit.c | 4 +-
net/netfilter/nf_tables_api.c | 15 +-
net/netlabel/netlabel_calipso.c | 52 +-
net/netlabel/netlabel_cipso_v4.c | 4 +-
net/netlabel/netlabel_mgmt.c | 8 +-
net/netlabel/netlabel_unlabeled.c | 10 +-
net/netlabel/netlabel_user.h | 4 +-
net/qrtr/ns.c | 4 +-
net/vmw_vsock/virtio_transport_common.c | 13 +-
security/apparmor/policy_unpack.c | 4 +
security/selinux/hooks.c | 7 +
sound/pci/hda/patch_realtek.c | 11 +
sound/pci/oxygen/oxygen_mixer.c | 2 +-
sound/soc/atmel/sam9g20_wm8731.c | 61 +++
sound/soc/codecs/cs35l33.c | 4 +-
sound/soc/codecs/cs35l34.c | 4 +-
sound/soc/codecs/cs43130.c | 6 +-
sound/soc/codecs/da7219-aad.c | 2 +-
sound/soc/codecs/nau8822.c | 9 +-
sound/soc/codecs/rt5645.c | 10 +-
sound/soc/codecs/wm8974.c | 6 +-
sound/soc/intel/skylake/skl-pcm.c | 9 +-
sound/soc/intel/skylake/skl-sst-ipc.c | 4 +-
tools/include/uapi/linux/bpf.h | 3 +
tools/lib/api/io.h | 1 +
tools/perf/util/bpf-event.c | 8 +-
tools/perf/util/bpf-event.h | 12 +-
tools/perf/util/env.c | 50 +-
tools/perf/util/env.h | 4 +
tools/perf/util/genelf.c | 6 +-
tools/perf/util/header.c | 8 +-
.../testing/selftests/drivers/net/mlxsw/qos_pfc.sh | 40 +-
.../drivers/net/mlxsw/spectrum-2/tc_flower.sh | 106 +++-
.../selftests/net/fib_nexthop_multiprefix.sh | 4 +-
tools/testing/selftests/powerpc/math/fpu_preempt.c | 9 +-
tools/testing/selftests/powerpc/math/vmx_preempt.c | 10 +-
268 files changed, 2886 insertions(+), 1471 deletions(-)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-22 23:55 [PATCH 5.10 000/286] 5.10.209-rc1 review Greg Kroah-Hartman
@ 2024-01-23 3:32 ` Dominique Martinet
2024-01-23 21:19 ` Florian Fainelli
` (2 subsequent siblings)
3 siblings, 0 replies; 17+ messages in thread
From: Dominique Martinet @ 2024-01-23 3:32 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml
Greg Kroah-Hartman wrote on Mon, Jan 22, 2024 at 03:55:06PM -0800:
> This is the start of the stable review cycle for the 5.10.209 release.
> There are 286 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.209-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
Tested 3c264a5f70c7 ("Linux 5.10.209-rc1") on:
- arm i.MX6ULL (Armadillo 640)
- arm64 i.MX8MP (Armadillo G4)
No obvious regression in dmesg or basic tests:
Tested-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
--
Dominique
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-22 23:55 [PATCH 5.10 000/286] 5.10.209-rc1 review Greg Kroah-Hartman
2024-01-23 3:32 ` Dominique Martinet
@ 2024-01-23 21:19 ` Florian Fainelli
2024-01-24 11:25 ` Naresh Kamboju
2024-01-26 16:46 ` Guenter Roeck
3 siblings, 0 replies; 17+ messages in thread
From: Florian Fainelli @ 2024-01-23 21:19 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, sudipm.mukherjee, srw, rwarsow,
conor, allen.lkml
On 1/22/24 15:55, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.209 release.
> There are 286 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.209-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels build tested on
BMIPS_GENERIC:
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-22 23:55 [PATCH 5.10 000/286] 5.10.209-rc1 review Greg Kroah-Hartman
2024-01-23 3:32 ` Dominique Martinet
2024-01-23 21:19 ` Florian Fainelli
@ 2024-01-24 11:25 ` Naresh Kamboju
2024-01-26 16:46 ` Guenter Roeck
3 siblings, 0 replies; 17+ messages in thread
From: Naresh Kamboju @ 2024-01-24 11:25 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml
On Tue, 23 Jan 2024 at 06:16, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 5.10.209 release.
> There are 286 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.209-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## Build
* kernel: 5.10.209-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.10.y
* git commit: 3c264a5f70c74960386987716dab9e042db1689b
* git describe: v5.10.208-287-g3c264a5f70c7
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.208-287-g3c264a5f70c7
## Test Regressions (compared to v5.10.208)
## Metric Regressions (compared to v5.10.208)
## Test Fixes (compared to v5.10.208)
## Metric Fixes (compared to v5.10.208)
## Test result summary
total: 97987, pass: 74379, fail: 4011, skip: 19507, xfail: 90
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 117 total, 117 passed, 0 failed
* arm64: 44 total, 44 passed, 0 failed
* i386: 35 total, 35 passed, 0 failed
* mips: 24 total, 24 passed, 0 failed
* parisc: 3 total, 0 passed, 3 failed
* powerpc: 25 total, 25 passed, 0 failed
* riscv: 11 total, 11 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 38 total, 38 passed, 0 failed
## Test suites summary
* boot
* kselftest-android
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timens
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-22 23:55 [PATCH 5.10 000/286] 5.10.209-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2024-01-24 11:25 ` Naresh Kamboju
@ 2024-01-26 16:46 ` Guenter Roeck
2024-01-26 17:51 ` Greg Kroah-Hartman
3 siblings, 1 reply; 17+ messages in thread
From: Guenter Roeck @ 2024-01-26 16:46 UTC (permalink / raw)
To: Greg Kroah-Hartman, stable
Cc: patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml
On 1/22/24 15:55, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.209 release.
> There are 286 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> Anything received after that time might be too late.
>
[ ... ]
> zhenwei pi <pizhenwei@bytedance.com>
> virtio-crypto: implement RSA algorithm
>
Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
It is quite beyond a bug fix. Also, unless I am really missing something,
the series (or at least this patch) was not applied to v5.15.y, so we now
have functionality in v5.10.y which is not in v5.15.y.
Guenter
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-26 16:46 ` Guenter Roeck
@ 2024-01-26 17:51 ` Greg Kroah-Hartman
2024-01-26 18:17 ` Guenter Roeck
0 siblings, 1 reply; 17+ messages in thread
From: Greg Kroah-Hartman @ 2024-01-26 17:51 UTC (permalink / raw)
To: Guenter Roeck
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml
On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
> On 1/22/24 15:55, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 5.10.209 release.
> > There are 286 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> > Anything received after that time might be too late.
> >
> [ ... ]
>
> > zhenwei pi <pizhenwei@bytedance.com>
> > virtio-crypto: implement RSA algorithm
> >
>
> Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
> It is quite beyond a bug fix. Also, unless I am really missing something,
> the series (or at least this patch) was not applied to v5.15.y, so we now
> have functionality in v5.10.y which is not in v5.15.y.
See the commit text, it was a dependency of a later fix and documented
as such.
Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
gladly accepted :)
thanks,
greg k-h
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-26 17:51 ` Greg Kroah-Hartman
@ 2024-01-26 18:17 ` Guenter Roeck
2024-01-26 18:48 ` Greg Kroah-Hartman
2024-01-26 20:34 ` Nathan Chancellor
0 siblings, 2 replies; 17+ messages in thread
From: Guenter Roeck @ 2024-01-26 18:17 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml
On 1/26/24 09:51, Greg Kroah-Hartman wrote:
> On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
>> On 1/22/24 15:55, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 5.10.209 release.
>>> There are 286 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
>>> Anything received after that time might be too late.
>>>
>> [ ... ]
>>
>>> zhenwei pi <pizhenwei@bytedance.com>
>>> virtio-crypto: implement RSA algorithm
>>>
>>
>> Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
>> It is quite beyond a bug fix. Also, unless I am really missing something,
>> the series (or at least this patch) was not applied to v5.15.y, so we now
>> have functionality in v5.10.y which is not in v5.15.y.
>
> See the commit text, it was a dependency of a later fix and documented
> as such.
>
> Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
> gladly accepted :)
>
We reverted the entire series from the merge because it results in a build
failure for us.
In file included from /home/groeck/src/linux-chromeos/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c:10:
In file included from /home/groeck/src/linux-chromeos/include/linux/mpi.h:21:
In file included from /home/groeck/src/linux-chromeos/include/linux/scatterlist.h:5:
In file included from /home/groeck/src/linux-chromeos/include/linux/string.h:293:
/home/groeck/src/linux-chromeos/include/linux/fortify-string.h:512:4: error: call to __read_overflow2_field declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
__read_overflow2_field(q_size_field, size);
I also see that upstream (starting with 6.1) when trying to build it with clang,
so I guess it is one of those bug-for-bug compatibility things. I really have
no idea what causes it, or why we don't see the problem when building
chromeos-6.1 or chromeos-6.6, but (so far) only with chromeos-5.10 after
merging 5.10.209 into it. Making things worse, the problem isn't _always_
seen. Sometimes I can compile the file in 6.1.y without error, sometimes not.
I have no idea what triggers the problem. Of course, on top of all that,
the error message is completely useless.
Either case, we don't use that code in chromeos-5.10, so reverting the
entire series from the merge was the easiest way to proceed. But we really
don't have an incentive to apply the series to v5.15.y because we don't
need/use it there, and we might end up having to revert it from there
as well if it is applied.
Guenter
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-26 18:17 ` Guenter Roeck
@ 2024-01-26 18:48 ` Greg Kroah-Hartman
2024-01-26 20:34 ` Nathan Chancellor
1 sibling, 0 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2024-01-26 18:48 UTC (permalink / raw)
To: Guenter Roeck
Cc: stable, patches, linux-kernel, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee, srw,
rwarsow, conor, allen.lkml
On Fri, Jan 26, 2024 at 10:17:23AM -0800, Guenter Roeck wrote:
> On 1/26/24 09:51, Greg Kroah-Hartman wrote:
> > On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
> > > On 1/22/24 15:55, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 5.10.209 release.
> > > > There are 286 patches in this series, all will be posted as a response
> > > > to this one. If anyone has any issues with these being applied, please
> > > > let me know.
> > > >
> > > > Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> > > > Anything received after that time might be too late.
> > > >
> > > [ ... ]
> > >
> > > > zhenwei pi <pizhenwei@bytedance.com>
> > > > virtio-crypto: implement RSA algorithm
> > > >
> > >
> > > Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
> > > It is quite beyond a bug fix. Also, unless I am really missing something,
> > > the series (or at least this patch) was not applied to v5.15.y, so we now
> > > have functionality in v5.10.y which is not in v5.15.y.
> >
> > See the commit text, it was a dependency of a later fix and documented
> > as such.
> >
> > Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
> > gladly accepted :)
> >
>
> We reverted the entire series from the merge because it results in a build
> failure for us.
>
> In file included from /home/groeck/src/linux-chromeos/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c:10:
> In file included from /home/groeck/src/linux-chromeos/include/linux/mpi.h:21:
> In file included from /home/groeck/src/linux-chromeos/include/linux/scatterlist.h:5:
> In file included from /home/groeck/src/linux-chromeos/include/linux/string.h:293:
> /home/groeck/src/linux-chromeos/include/linux/fortify-string.h:512:4: error: call to __read_overflow2_field declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
> __read_overflow2_field(q_size_field, size);
>
> I also see that upstream (starting with 6.1) when trying to build it with clang,
> so I guess it is one of those bug-for-bug compatibility things. I really have
> no idea what causes it, or why we don't see the problem when building
> chromeos-6.1 or chromeos-6.6, but (so far) only with chromeos-5.10 after
> merging 5.10.209 into it. Making things worse, the problem isn't _always_
> seen. Sometimes I can compile the file in 6.1.y without error, sometimes not.
> I have no idea what triggers the problem. Of course, on top of all that,
> the error message is completely useless.
>
> Either case, we don't use that code in chromeos-5.10, so reverting the
> entire series from the merge was the easiest way to proceed. But we really
> don't have an incentive to apply the series to v5.15.y because we don't
> need/use it there, and we might end up having to revert it from there
> as well if it is applied.
If this is causing build issues, I'll drop this, I was worried about it
during review but no one had any reports then, but now it looks like it
should be reworked. I'll go revert them, thanks.
greg k-h
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-26 18:17 ` Guenter Roeck
2024-01-26 18:48 ` Greg Kroah-Hartman
@ 2024-01-26 20:34 ` Nathan Chancellor
2024-01-26 21:01 ` Guenter Roeck
1 sibling, 1 reply; 17+ messages in thread
From: Nathan Chancellor @ 2024-01-26 20:34 UTC (permalink / raw)
To: Guenter Roeck
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds,
akpm, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, llvm,
keescook
On Fri, Jan 26, 2024 at 10:17:23AM -0800, Guenter Roeck wrote:
> On 1/26/24 09:51, Greg Kroah-Hartman wrote:
> > On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
> > > On 1/22/24 15:55, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 5.10.209 release.
> > > > There are 286 patches in this series, all will be posted as a response
> > > > to this one. If anyone has any issues with these being applied, please
> > > > let me know.
> > > >
> > > > Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> > > > Anything received after that time might be too late.
> > > >
> > > [ ... ]
> > >
> > > > zhenwei pi <pizhenwei@bytedance.com>
> > > > virtio-crypto: implement RSA algorithm
> > > >
> > >
> > > Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
> > > It is quite beyond a bug fix. Also, unless I am really missing something,
> > > the series (or at least this patch) was not applied to v5.15.y, so we now
> > > have functionality in v5.10.y which is not in v5.15.y.
> >
> > See the commit text, it was a dependency of a later fix and documented
> > as such.
> >
> > Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
> > gladly accepted :)
> >
>
> We reverted the entire series from the merge because it results in a build
> failure for us.
>
> In file included from /home/groeck/src/linux-chromeos/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c:10:
> In file included from /home/groeck/src/linux-chromeos/include/linux/mpi.h:21:
> In file included from /home/groeck/src/linux-chromeos/include/linux/scatterlist.h:5:
> In file included from /home/groeck/src/linux-chromeos/include/linux/string.h:293:
> /home/groeck/src/linux-chromeos/include/linux/fortify-string.h:512:4: error: call to __read_overflow2_field declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
> __read_overflow2_field(q_size_field, size);
For what it's worth, this is likely self inflicted for chromeos-5.10,
which carries a revert of commit eaafc590053b ("fortify: Explicitly
disable Clang support") as commit c19861d34c003 ("CHROMIUM: Revert
"fortify: Explicitly disable Clang support""). I don't see the series
that added proper support for clang to fortify in 5.18 that ended with
commit 281d0c962752 ("fortify: Add Clang support") in that ChromeOS
branch, so this seems somewhat expected.
> I also see that upstream (starting with 6.1) when trying to build it with clang,
> so I guess it is one of those bug-for-bug compatibility things. I really have
> no idea what causes it, or why we don't see the problem when building
> chromeos-6.1 or chromeos-6.6, but (so far) only with chromeos-5.10 after
> merging 5.10.209 into it. Making things worse, the problem isn't _always_
> seen. Sometimes I can compile the file in 6.1.y without error, sometimes not.
> I have no idea what triggers the problem.
Have a .config that reproduces it on upstream? I have not personally
seen this warning in my build matrix nor has our continuous-integration
matrix (I don't see it in the warning output at the bottom but that
could have missed something for some reason) in 6.1:
https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/7662499796
https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/7662534888
Reverting this series from 5.10 seems reasonable given your other
comments but if there is still something to sort out upstream, I
definitely want to.
> Of course, on top of all that, the error message is completely useless.
Indeed, outstanding papercut unfortunately:
https://github.com/ClangBuiltLinux/linux/issues/1571
Cheers,
Nathan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-26 20:34 ` Nathan Chancellor
@ 2024-01-26 21:01 ` Guenter Roeck
2024-01-26 21:53 ` Greg Kroah-Hartman
2024-01-26 22:35 ` Nathan Chancellor
0 siblings, 2 replies; 17+ messages in thread
From: Guenter Roeck @ 2024-01-26 21:01 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds,
akpm, shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, llvm,
keescook
On 1/26/24 12:34, Nathan Chancellor wrote:
> On Fri, Jan 26, 2024 at 10:17:23AM -0800, Guenter Roeck wrote:
>> On 1/26/24 09:51, Greg Kroah-Hartman wrote:
>>> On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
>>>> On 1/22/24 15:55, Greg Kroah-Hartman wrote:
>>>>> This is the start of the stable review cycle for the 5.10.209 release.
>>>>> There are 286 patches in this series, all will be posted as a response
>>>>> to this one. If anyone has any issues with these being applied, please
>>>>> let me know.
>>>>>
>>>>> Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
>>>>> Anything received after that time might be too late.
>>>>>
>>>> [ ... ]
>>>>
>>>>> zhenwei pi <pizhenwei@bytedance.com>
>>>>> virtio-crypto: implement RSA algorithm
>>>>>
>>>>
>>>> Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
>>>> It is quite beyond a bug fix. Also, unless I am really missing something,
>>>> the series (or at least this patch) was not applied to v5.15.y, so we now
>>>> have functionality in v5.10.y which is not in v5.15.y.
>>>
>>> See the commit text, it was a dependency of a later fix and documented
>>> as such.
>>>
>>> Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
>>> gladly accepted :)
>>>
>>
>> We reverted the entire series from the merge because it results in a build
>> failure for us.
>>
>> In file included from /home/groeck/src/linux-chromeos/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c:10:
>> In file included from /home/groeck/src/linux-chromeos/include/linux/mpi.h:21:
>> In file included from /home/groeck/src/linux-chromeos/include/linux/scatterlist.h:5:
>> In file included from /home/groeck/src/linux-chromeos/include/linux/string.h:293:
>> /home/groeck/src/linux-chromeos/include/linux/fortify-string.h:512:4: error: call to __read_overflow2_field declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
>> __read_overflow2_field(q_size_field, size);
>
> For what it's worth, this is likely self inflicted for chromeos-5.10,
> which carries a revert of commit eaafc590053b ("fortify: Explicitly
> disable Clang support") as commit c19861d34c003 ("CHROMIUM: Revert
> "fortify: Explicitly disable Clang support""). I don't see the series
> that added proper support for clang to fortify in 5.18 that ended with
> commit 281d0c962752 ("fortify: Add Clang support") in that ChromeOS
> branch, so this seems somewhat expected.
>
That explains that ;-). I don't mind if the patches stay in v5.10.y,
we have them reverted anyway.
The revert was a pure process issue, as you may see when looking into
commit c19861d34c003, so, yes, I agree that it is self-inflicted damage.
Still, that doesn't explain why the problem exists in 5.18+.
>> I also see that upstream (starting with 6.1) when trying to build it with clang,
>> so I guess it is one of those bug-for-bug compatibility things. I really have
>> no idea what causes it, or why we don't see the problem when building
>> chromeos-6.1 or chromeos-6.6, but (so far) only with chromeos-5.10 after
>> merging 5.10.209 into it. Making things worse, the problem isn't _always_
>> seen. Sometimes I can compile the file in 6.1.y without error, sometimes not.
>> I have no idea what triggers the problem.
>
> Have a .config that reproduces it on upstream? I have not personally
> seen this warning in my build matrix nor has our continuous-integration
> matrix (I don't see it in the warning output at the bottom but that
> could have missed something for some reason) in 6.1:
>
The following command sequence reproduces the problem for me with all stable
branches starting with 5.18.y (plus mainline).
rm -rf /tmp/crypto-build
mkdir /tmp/crypto-build
make -j CC=clang-15 mrproper >/dev/null 2>&1
make -j O=/tmp/crypto-build CC=clang-15 allmodconfig >/dev/null 2>&1
make -j O=/tmp/crypto-build W=1 CC=clang-15 drivers/crypto/virtio/virtio_crypto_akcipher_algs.o
I tried clang versions 14, 15, and 16. This is with my home system running
Ubuntu 22.04, no ChromeOS or Google specifics/internals involved. For clang-15,
the version is
Ubuntu clang version 15.0.7
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Guenter
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-26 21:01 ` Guenter Roeck
@ 2024-01-26 21:53 ` Greg Kroah-Hartman
2024-01-26 22:35 ` Nathan Chancellor
1 sibling, 0 replies; 17+ messages in thread
From: Greg Kroah-Hartman @ 2024-01-26 21:53 UTC (permalink / raw)
To: Guenter Roeck
Cc: Nathan Chancellor, stable, patches, linux-kernel, torvalds, akpm,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, srw, rwarsow, conor, allen.lkml, llvm,
keescook
On Fri, Jan 26, 2024 at 01:01:15PM -0800, Guenter Roeck wrote:
> On 1/26/24 12:34, Nathan Chancellor wrote:
> > On Fri, Jan 26, 2024 at 10:17:23AM -0800, Guenter Roeck wrote:
> > > On 1/26/24 09:51, Greg Kroah-Hartman wrote:
> > > > On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
> > > > > On 1/22/24 15:55, Greg Kroah-Hartman wrote:
> > > > > > This is the start of the stable review cycle for the 5.10.209 release.
> > > > > > There are 286 patches in this series, all will be posted as a response
> > > > > > to this one. If anyone has any issues with these being applied, please
> > > > > > let me know.
> > > > > >
> > > > > > Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> > > > > > Anything received after that time might be too late.
> > > > > >
> > > > > [ ... ]
> > > > >
> > > > > > zhenwei pi <pizhenwei@bytedance.com>
> > > > > > virtio-crypto: implement RSA algorithm
> > > > > >
> > > > >
> > > > > Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
> > > > > It is quite beyond a bug fix. Also, unless I am really missing something,
> > > > > the series (or at least this patch) was not applied to v5.15.y, so we now
> > > > > have functionality in v5.10.y which is not in v5.15.y.
> > > >
> > > > See the commit text, it was a dependency of a later fix and documented
> > > > as such.
> > > >
> > > > Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
> > > > gladly accepted :)
> > > >
> > >
> > > We reverted the entire series from the merge because it results in a build
> > > failure for us.
> > >
> > > In file included from /home/groeck/src/linux-chromeos/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c:10:
> > > In file included from /home/groeck/src/linux-chromeos/include/linux/mpi.h:21:
> > > In file included from /home/groeck/src/linux-chromeos/include/linux/scatterlist.h:5:
> > > In file included from /home/groeck/src/linux-chromeos/include/linux/string.h:293:
> > > /home/groeck/src/linux-chromeos/include/linux/fortify-string.h:512:4: error: call to __read_overflow2_field declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
> > > __read_overflow2_field(q_size_field, size);
> >
> > For what it's worth, this is likely self inflicted for chromeos-5.10,
> > which carries a revert of commit eaafc590053b ("fortify: Explicitly
> > disable Clang support") as commit c19861d34c003 ("CHROMIUM: Revert
> > "fortify: Explicitly disable Clang support""). I don't see the series
> > that added proper support for clang to fortify in 5.18 that ended with
> > commit 281d0c962752 ("fortify: Add Clang support") in that ChromeOS
> > branch, so this seems somewhat expected.
> >
>
> That explains that ;-). I don't mind if the patches stay in v5.10.y,
> we have them reverted anyway.
Ok, I'll leave them as-is for now, thanks.
greg k-h
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-26 21:01 ` Guenter Roeck
2024-01-26 21:53 ` Greg Kroah-Hartman
@ 2024-01-26 22:35 ` Nathan Chancellor
2024-01-26 23:55 ` Guenter Roeck
1 sibling, 1 reply; 17+ messages in thread
From: Nathan Chancellor @ 2024-01-26 22:35 UTC (permalink / raw)
To: Guenter Roeck
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds,
llvm, keescook, arei.gonglei, mst, jasowang, virtualization,
linux-crypto
(slimming up the CC list, I don't think this is too relevant to the
wider stable community)
On Fri, Jan 26, 2024 at 01:01:15PM -0800, Guenter Roeck wrote:
> On 1/26/24 12:34, Nathan Chancellor wrote:
> > On Fri, Jan 26, 2024 at 10:17:23AM -0800, Guenter Roeck wrote:
> > > On 1/26/24 09:51, Greg Kroah-Hartman wrote:
> > > > On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
> > > > > On 1/22/24 15:55, Greg Kroah-Hartman wrote:
> > > > > > This is the start of the stable review cycle for the 5.10.209 release.
> > > > > > There are 286 patches in this series, all will be posted as a response
> > > > > > to this one. If anyone has any issues with these being applied, please
> > > > > > let me know.
> > > > > >
> > > > > > Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> > > > > > Anything received after that time might be too late.
> > > > > >
> > > > > [ ... ]
> > > > >
> > > > > > zhenwei pi <pizhenwei@bytedance.com>
> > > > > > virtio-crypto: implement RSA algorithm
> > > > > >
> > > > >
> > > > > Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
> > > > > It is quite beyond a bug fix. Also, unless I am really missing something,
> > > > > the series (or at least this patch) was not applied to v5.15.y, so we now
> > > > > have functionality in v5.10.y which is not in v5.15.y.
> > > >
> > > > See the commit text, it was a dependency of a later fix and documented
> > > > as such.
> > > >
> > > > Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
> > > > gladly accepted :)
> > > >
> > >
> > > We reverted the entire series from the merge because it results in a build
> > > failure for us.
> > >
> > > In file included from /home/groeck/src/linux-chromeos/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c:10:
> > > In file included from /home/groeck/src/linux-chromeos/include/linux/mpi.h:21:
> > > In file included from /home/groeck/src/linux-chromeos/include/linux/scatterlist.h:5:
> > > In file included from /home/groeck/src/linux-chromeos/include/linux/string.h:293:
> > > /home/groeck/src/linux-chromeos/include/linux/fortify-string.h:512:4: error: call to __read_overflow2_field declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
> > > __read_overflow2_field(q_size_field, size);
> >
> > For what it's worth, this is likely self inflicted for chromeos-5.10,
> > which carries a revert of commit eaafc590053b ("fortify: Explicitly
> > disable Clang support") as commit c19861d34c003 ("CHROMIUM: Revert
> > "fortify: Explicitly disable Clang support""). I don't see the series
> > that added proper support for clang to fortify in 5.18 that ended with
> > commit 281d0c962752 ("fortify: Add Clang support") in that ChromeOS
> > branch, so this seems somewhat expected.
> >
>
> That explains that ;-). I don't mind if the patches stay in v5.10.y,
> we have them reverted anyway.
>
> The revert was a pure process issue, as you may see when looking into
> commit c19861d34c003, so, yes, I agree that it is self-inflicted damage.
> Still, that doesn't explain why the problem exists in 5.18+.
>
> > > I also see that upstream (starting with 6.1) when trying to build it with clang,
> > > so I guess it is one of those bug-for-bug compatibility things. I really have
> > > no idea what causes it, or why we don't see the problem when building
> > > chromeos-6.1 or chromeos-6.6, but (so far) only with chromeos-5.10 after
> > > merging 5.10.209 into it. Making things worse, the problem isn't _always_
> > > seen. Sometimes I can compile the file in 6.1.y without error, sometimes not.
> > > I have no idea what triggers the problem.
> >
> > Have a .config that reproduces it on upstream? I have not personally
> > seen this warning in my build matrix nor has our continuous-integration
> > matrix (I don't see it in the warning output at the bottom but that
> > could have missed something for some reason) in 6.1:
> >
>
> The following command sequence reproduces the problem for me with all stable
> branches starting with 5.18.y (plus mainline).
>
> rm -rf /tmp/crypto-build
> mkdir /tmp/crypto-build
> make -j CC=clang-15 mrproper >/dev/null 2>&1
> make -j O=/tmp/crypto-build CC=clang-15 allmodconfig >/dev/null 2>&1
> make -j O=/tmp/crypto-build W=1 CC=clang-15 drivers/crypto/virtio/virtio_crypto_akcipher_algs.o
>
> I tried clang versions 14, 15, and 16. This is with my home system running
> Ubuntu 22.04, no ChromeOS or Google specifics/internals involved. For clang-15,
> the version is
>
> Ubuntu clang version 15.0.7
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
Okay interesting, this warning is hidden behind W=1, which our CI does
not test with. Looks like it has been that way since the introduction of
these checks in f68f2ff91512 ("fortify: Detect struct member overflows
in memcpy() at compile-time").
I think this is a legitimate warning though. It is complaining about the
second memcpy() in virtio_crypto_alg_akcipher_init_session():
memcpy(&ctrl->u, para, sizeof(ctrl->u));
where ctrl is:
struct virtio_crypto_op_ctrl_req {
struct virtio_crypto_ctrl_header header; /* 0 16 */
union {
struct virtio_crypto_sym_create_session_req sym_create_session; /* 16 56 */
struct virtio_crypto_hash_create_session_req hash_create_session; /* 16 56 */
struct virtio_crypto_mac_create_session_req mac_create_session; /* 16 56 */
struct virtio_crypto_aead_create_session_req aead_create_session; /* 16 56 */
struct virtio_crypto_akcipher_create_session_req akcipher_create_session; /* 16 56 */
struct virtio_crypto_destroy_session_req destroy_session; /* 16 56 */
__u8 padding[56]; /* 16 56 */
} u; /* 16 56 */
union {
struct virtio_crypto_sym_create_session_req sym_create_session; /* 0 56 */
struct virtio_crypto_hash_create_session_req hash_create_session; /* 0 56 */
struct virtio_crypto_mac_create_session_req mac_create_session; /* 0 56 */
struct virtio_crypto_aead_create_session_req aead_create_session; /* 0 56 */
struct virtio_crypto_akcipher_create_session_req akcipher_create_session; /* 0 56 */
struct virtio_crypto_destroy_session_req destroy_session; /* 0 56 */
__u8 padding[56]; /* 0 56 */
};
/* size: 72, cachelines: 2, members: 2 */
/* last cacheline: 8 bytes */
};
(so size and p_size_field should be 56) and the type of the para
parameter in virtio_crypto_alg_akcipher_init_session() is 'void *' but
the para passed by reference to
virtio_crypto_alg_akcipher_init_session() in virtio_crypto_rsa_set_key()
has a type of 'struct virtio_crypto_akcipher_session_para':
struct virtio_crypto_akcipher_session_para {
__le32 algo; /* 0 4 */
__le32 keytype; /* 4 4 */
__le32 keylen; /* 8 4 */
union {
struct virtio_crypto_rsa_session_para rsa; /* 12 8 */
struct virtio_crypto_ecdsa_session_para ecdsa; /* 12 8 */
} u; /* 12 8 */
union {
struct virtio_crypto_rsa_session_para rsa; /* 0 8 */
struct virtio_crypto_ecdsa_session_para ecdsa; /* 0 8 */
};
/* size: 20, cachelines: 1, members: 4 */
/* last cacheline: 20 bytes */
};
(so q_size_field would be 20 if clang were able to do inlining to see
through the 'void *'...?), which would result in the
__compiletime_lessthan(q_size_field, size)
check succeeding and triggering the warning because 20 < 56, so it does
seem like there is an overread of the source buffer here? Adding the
maintainers of the driver and subsystem in question.
Cheers,
Nathan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-26 22:35 ` Nathan Chancellor
@ 2024-01-26 23:55 ` Guenter Roeck
2024-01-27 0:03 ` Nathan Chancellor
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Guenter Roeck @ 2024-01-26 23:55 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds,
llvm, keescook, arei.gonglei, mst, jasowang, virtualization,
linux-crypto
On 1/26/24 14:35, Nathan Chancellor wrote:
> (slimming up the CC list, I don't think this is too relevant to the
> wider stable community)
>
> On Fri, Jan 26, 2024 at 01:01:15PM -0800, Guenter Roeck wrote:
>> On 1/26/24 12:34, Nathan Chancellor wrote:
>>> On Fri, Jan 26, 2024 at 10:17:23AM -0800, Guenter Roeck wrote:
>>>> On 1/26/24 09:51, Greg Kroah-Hartman wrote:
>>>>> On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
>>>>>> On 1/22/24 15:55, Greg Kroah-Hartman wrote:
>>>>>>> This is the start of the stable review cycle for the 5.10.209 release.
>>>>>>> There are 286 patches in this series, all will be posted as a response
>>>>>>> to this one. If anyone has any issues with these being applied, please
>>>>>>> let me know.
>>>>>>>
>>>>>>> Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
>>>>>>> Anything received after that time might be too late.
>>>>>>>
>>>>>> [ ... ]
>>>>>>
>>>>>>> zhenwei pi <pizhenwei@bytedance.com>
>>>>>>> virtio-crypto: implement RSA algorithm
>>>>>>>
>>>>>>
>>>>>> Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
>>>>>> It is quite beyond a bug fix. Also, unless I am really missing something,
>>>>>> the series (or at least this patch) was not applied to v5.15.y, so we now
>>>>>> have functionality in v5.10.y which is not in v5.15.y.
>>>>>
>>>>> See the commit text, it was a dependency of a later fix and documented
>>>>> as such.
>>>>>
>>>>> Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
>>>>> gladly accepted :)
>>>>>
>>>>
>>>> We reverted the entire series from the merge because it results in a build
>>>> failure for us.
>>>>
>>>> In file included from /home/groeck/src/linux-chromeos/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c:10:
>>>> In file included from /home/groeck/src/linux-chromeos/include/linux/mpi.h:21:
>>>> In file included from /home/groeck/src/linux-chromeos/include/linux/scatterlist.h:5:
>>>> In file included from /home/groeck/src/linux-chromeos/include/linux/string.h:293:
>>>> /home/groeck/src/linux-chromeos/include/linux/fortify-string.h:512:4: error: call to __read_overflow2_field declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
>>>> __read_overflow2_field(q_size_field, size);
>>>
>>> For what it's worth, this is likely self inflicted for chromeos-5.10,
>>> which carries a revert of commit eaafc590053b ("fortify: Explicitly
>>> disable Clang support") as commit c19861d34c003 ("CHROMIUM: Revert
>>> "fortify: Explicitly disable Clang support""). I don't see the series
>>> that added proper support for clang to fortify in 5.18 that ended with
>>> commit 281d0c962752 ("fortify: Add Clang support") in that ChromeOS
>>> branch, so this seems somewhat expected.
>>>
>>
>> That explains that ;-). I don't mind if the patches stay in v5.10.y,
>> we have them reverted anyway.
>>
>> The revert was a pure process issue, as you may see when looking into
>> commit c19861d34c003, so, yes, I agree that it is self-inflicted damage.
>> Still, that doesn't explain why the problem exists in 5.18+.
>>
>>>> I also see that upstream (starting with 6.1) when trying to build it with clang,
>>>> so I guess it is one of those bug-for-bug compatibility things. I really have
>>>> no idea what causes it, or why we don't see the problem when building
>>>> chromeos-6.1 or chromeos-6.6, but (so far) only with chromeos-5.10 after
>>>> merging 5.10.209 into it. Making things worse, the problem isn't _always_
>>>> seen. Sometimes I can compile the file in 6.1.y without error, sometimes not.
>>>> I have no idea what triggers the problem.
>>>
>>> Have a .config that reproduces it on upstream? I have not personally
>>> seen this warning in my build matrix nor has our continuous-integration
>>> matrix (I don't see it in the warning output at the bottom but that
>>> could have missed something for some reason) in 6.1:
>>>
>>
>> The following command sequence reproduces the problem for me with all stable
>> branches starting with 5.18.y (plus mainline).
>>
>> rm -rf /tmp/crypto-build
>> mkdir /tmp/crypto-build
>> make -j CC=clang-15 mrproper >/dev/null 2>&1
>> make -j O=/tmp/crypto-build CC=clang-15 allmodconfig >/dev/null 2>&1
>> make -j O=/tmp/crypto-build W=1 CC=clang-15 drivers/crypto/virtio/virtio_crypto_akcipher_algs.o
>>
>> I tried clang versions 14, 15, and 16. This is with my home system running
>> Ubuntu 22.04, no ChromeOS or Google specifics/internals involved. For clang-15,
>> the version is
>>
>> Ubuntu clang version 15.0.7
>> Target: x86_64-pc-linux-gnu
>> Thread model: posix
>> InstalledDir: /usr/bin
>
> Okay interesting, this warning is hidden behind W=1, which our CI does
> not test with. Looks like it has been that way since the introduction of
> these checks in f68f2ff91512 ("fortify: Detect struct member overflows
> in memcpy() at compile-time").
>
Interestingly the warning is seen in chromeos-5.10, without this patch,
and without W=1. I guess that must have to do with the revert which is
finally biting us.
> I think this is a legitimate warning though. It is complaining about the
> second memcpy() in virtio_crypto_alg_akcipher_init_session():
>
> memcpy(&ctrl->u, para, sizeof(ctrl->u));
>
> where ctrl is:
>
> struct virtio_crypto_op_ctrl_req {
> struct virtio_crypto_ctrl_header header; /* 0 16 */
> union {
> struct virtio_crypto_sym_create_session_req sym_create_session; /* 16 56 */
> struct virtio_crypto_hash_create_session_req hash_create_session; /* 16 56 */
> struct virtio_crypto_mac_create_session_req mac_create_session; /* 16 56 */
> struct virtio_crypto_aead_create_session_req aead_create_session; /* 16 56 */
> struct virtio_crypto_akcipher_create_session_req akcipher_create_session; /* 16 56 */
> struct virtio_crypto_destroy_session_req destroy_session; /* 16 56 */
> __u8 padding[56]; /* 16 56 */
> } u; /* 16 56 */
> union {
> struct virtio_crypto_sym_create_session_req sym_create_session; /* 0 56 */
> struct virtio_crypto_hash_create_session_req hash_create_session; /* 0 56 */
> struct virtio_crypto_mac_create_session_req mac_create_session; /* 0 56 */
> struct virtio_crypto_aead_create_session_req aead_create_session; /* 0 56 */
> struct virtio_crypto_akcipher_create_session_req akcipher_create_session; /* 0 56 */
> struct virtio_crypto_destroy_session_req destroy_session; /* 0 56 */
> __u8 padding[56]; /* 0 56 */
> };
>
>
> /* size: 72, cachelines: 2, members: 2 */
> /* last cacheline: 8 bytes */
> };
>
> (so size and p_size_field should be 56) and the type of the para
> parameter in virtio_crypto_alg_akcipher_init_session() is 'void *' but
> the para passed by reference to
> virtio_crypto_alg_akcipher_init_session() in virtio_crypto_rsa_set_key()
> has a type of 'struct virtio_crypto_akcipher_session_para':
>
> struct virtio_crypto_akcipher_session_para {
> __le32 algo; /* 0 4 */
> __le32 keytype; /* 4 4 */
> __le32 keylen; /* 8 4 */
> union {
> struct virtio_crypto_rsa_session_para rsa; /* 12 8 */
> struct virtio_crypto_ecdsa_session_para ecdsa; /* 12 8 */
> } u; /* 12 8 */
> union {
> struct virtio_crypto_rsa_session_para rsa; /* 0 8 */
> struct virtio_crypto_ecdsa_session_para ecdsa; /* 0 8 */
> };
>
>
> /* size: 20, cachelines: 1, members: 4 */
> /* last cacheline: 20 bytes */
> };
>
> (so q_size_field would be 20 if clang were able to do inlining to see
> through the 'void *'...?), which would result in the
>
> __compiletime_lessthan(q_size_field, size)
>
> check succeeding and triggering the warning because 20 < 56, so it does
> seem like there is an overread of the source buffer here? Adding the
Looks like it; I think either the passed 'para' should be of type
virtio_crypto_akcipher_create_session_req() or it should only copy
sizeof(struct virtio_crypto_akcipher_session_para) bytes.
Anyway, how did you find that ? Is there a magic trick to find the
actual code causing the warning ? I am asking because we had seen
similar warnings before, and it would help to know how to find the
problematic code.
Thanks,
Guenter
> maintainers of the driver and subsystem in question.
>
> Cheers,
> Nathan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-26 23:55 ` Guenter Roeck
@ 2024-01-27 0:03 ` Nathan Chancellor
2024-01-28 11:13 ` Michael S. Tsirkin
2024-01-29 8:46 ` Michael S. Tsirkin
2 siblings, 0 replies; 17+ messages in thread
From: Nathan Chancellor @ 2024-01-27 0:03 UTC (permalink / raw)
To: Guenter Roeck
Cc: Greg Kroah-Hartman, stable, patches, linux-kernel, torvalds,
llvm, keescook, arei.gonglei, mst, jasowang, virtualization,
linux-crypto
On Fri, Jan 26, 2024 at 03:55:02PM -0800, Guenter Roeck wrote:
> Anyway, how did you find that ? Is there a magic trick to find the
> actual code causing the warning ? I am asking because we had seen
> similar warnings before, and it would help to know how to find the
> problematic code.
The easiest way I have found is figuring out what primitive is causing
the warning (memset, memcpy) then just commenting out the uses in the
particular file until the warning goes away. Sometimes it is quick like
in this case since there were only two instances of memcpy() in that
file but other cases it can definitely take time. There could be
potential issues with that approach if the problematic use is in a
header, at which point you could generate a preprocessed ('.i') file and
see where fortify_memcpy_chk() or fortify_memset_chk() come from in that
file.
Cheers,
Nathan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-26 23:55 ` Guenter Roeck
2024-01-27 0:03 ` Nathan Chancellor
@ 2024-01-28 11:13 ` Michael S. Tsirkin
2024-01-29 8:46 ` Michael S. Tsirkin
2 siblings, 0 replies; 17+ messages in thread
From: Michael S. Tsirkin @ 2024-01-28 11:13 UTC (permalink / raw)
To: Guenter Roeck
Cc: Nathan Chancellor, Greg Kroah-Hartman, stable, patches,
linux-kernel, torvalds, llvm, keescook, arei.gonglei, jasowang,
virtualization, linux-crypto, Wei Yongjun
On Fri, Jan 26, 2024 at 03:55:02PM -0800, Guenter Roeck wrote:
> On 1/26/24 14:35, Nathan Chancellor wrote:
> > (slimming up the CC list, I don't think this is too relevant to the
> > wider stable community)
> >
> > On Fri, Jan 26, 2024 at 01:01:15PM -0800, Guenter Roeck wrote:
> > > On 1/26/24 12:34, Nathan Chancellor wrote:
> > > > On Fri, Jan 26, 2024 at 10:17:23AM -0800, Guenter Roeck wrote:
> > > > > On 1/26/24 09:51, Greg Kroah-Hartman wrote:
> > > > > > On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
> > > > > > > On 1/22/24 15:55, Greg Kroah-Hartman wrote:
> > > > > > > > This is the start of the stable review cycle for the 5.10.209 release.
> > > > > > > > There are 286 patches in this series, all will be posted as a response
> > > > > > > > to this one. If anyone has any issues with these being applied, please
> > > > > > > > let me know.
> > > > > > > >
> > > > > > > > Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> > > > > > > > Anything received after that time might be too late.
> > > > > > > >
> > > > > > > [ ... ]
> > > > > > >
> > > > > > > > zhenwei pi <pizhenwei@bytedance.com>
> > > > > > > > virtio-crypto: implement RSA algorithm
> > > > > > > >
> > > > > > >
> > > > > > > Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
> > > > > > > It is quite beyond a bug fix. Also, unless I am really missing something,
> > > > > > > the series (or at least this patch) was not applied to v5.15.y, so we now
> > > > > > > have functionality in v5.10.y which is not in v5.15.y.
> > > > > >
> > > > > > See the commit text, it was a dependency of a later fix and documented
> > > > > > as such.
> > > > > >
> > > > > > Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
> > > > > > gladly accepted :)
> > > > > >
> > > > >
> > > > > We reverted the entire series from the merge because it results in a build
> > > > > failure for us.
> > > > >
> > > > > In file included from /home/groeck/src/linux-chromeos/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c:10:
> > > > > In file included from /home/groeck/src/linux-chromeos/include/linux/mpi.h:21:
> > > > > In file included from /home/groeck/src/linux-chromeos/include/linux/scatterlist.h:5:
> > > > > In file included from /home/groeck/src/linux-chromeos/include/linux/string.h:293:
> > > > > /home/groeck/src/linux-chromeos/include/linux/fortify-string.h:512:4: error: call to __read_overflow2_field declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
> > > > > __read_overflow2_field(q_size_field, size);
> > > >
> > > > For what it's worth, this is likely self inflicted for chromeos-5.10,
> > > > which carries a revert of commit eaafc590053b ("fortify: Explicitly
> > > > disable Clang support") as commit c19861d34c003 ("CHROMIUM: Revert
> > > > "fortify: Explicitly disable Clang support""). I don't see the series
> > > > that added proper support for clang to fortify in 5.18 that ended with
> > > > commit 281d0c962752 ("fortify: Add Clang support") in that ChromeOS
> > > > branch, so this seems somewhat expected.
> > > >
> > >
> > > That explains that ;-). I don't mind if the patches stay in v5.10.y,
> > > we have them reverted anyway.
> > >
> > > The revert was a pure process issue, as you may see when looking into
> > > commit c19861d34c003, so, yes, I agree that it is self-inflicted damage.
> > > Still, that doesn't explain why the problem exists in 5.18+.
> > >
> > > > > I also see that upstream (starting with 6.1) when trying to build it with clang,
> > > > > so I guess it is one of those bug-for-bug compatibility things. I really have
> > > > > no idea what causes it, or why we don't see the problem when building
> > > > > chromeos-6.1 or chromeos-6.6, but (so far) only with chromeos-5.10 after
> > > > > merging 5.10.209 into it. Making things worse, the problem isn't _always_
> > > > > seen. Sometimes I can compile the file in 6.1.y without error, sometimes not.
> > > > > I have no idea what triggers the problem.
> > > >
> > > > Have a .config that reproduces it on upstream? I have not personally
> > > > seen this warning in my build matrix nor has our continuous-integration
> > > > matrix (I don't see it in the warning output at the bottom but that
> > > > could have missed something for some reason) in 6.1:
> > > >
> > >
> > > The following command sequence reproduces the problem for me with all stable
> > > branches starting with 5.18.y (plus mainline).
> > >
> > > rm -rf /tmp/crypto-build
> > > mkdir /tmp/crypto-build
> > > make -j CC=clang-15 mrproper >/dev/null 2>&1
> > > make -j O=/tmp/crypto-build CC=clang-15 allmodconfig >/dev/null 2>&1
> > > make -j O=/tmp/crypto-build W=1 CC=clang-15 drivers/crypto/virtio/virtio_crypto_akcipher_algs.o
> > >
> > > I tried clang versions 14, 15, and 16. This is with my home system running
> > > Ubuntu 22.04, no ChromeOS or Google specifics/internals involved. For clang-15,
> > > the version is
> > >
> > > Ubuntu clang version 15.0.7
> > > Target: x86_64-pc-linux-gnu
> > > Thread model: posix
> > > InstalledDir: /usr/bin
> >
> > Okay interesting, this warning is hidden behind W=1, which our CI does
> > not test with. Looks like it has been that way since the introduction of
> > these checks in f68f2ff91512 ("fortify: Detect struct member overflows
> > in memcpy() at compile-time").
> >
>
> Interestingly the warning is seen in chromeos-5.10, without this patch,
> and without W=1. I guess that must have to do with the revert which is
> finally biting us.
>
> > I think this is a legitimate warning though. It is complaining about the
> > second memcpy() in virtio_crypto_alg_akcipher_init_session():
> >
> > memcpy(&ctrl->u, para, sizeof(ctrl->u));
> >
> > where ctrl is:
> >
> > struct virtio_crypto_op_ctrl_req {
> > struct virtio_crypto_ctrl_header header; /* 0 16 */
> > union {
> > struct virtio_crypto_sym_create_session_req sym_create_session; /* 16 56 */
> > struct virtio_crypto_hash_create_session_req hash_create_session; /* 16 56 */
> > struct virtio_crypto_mac_create_session_req mac_create_session; /* 16 56 */
> > struct virtio_crypto_aead_create_session_req aead_create_session; /* 16 56 */
> > struct virtio_crypto_akcipher_create_session_req akcipher_create_session; /* 16 56 */
> > struct virtio_crypto_destroy_session_req destroy_session; /* 16 56 */
> > __u8 padding[56]; /* 16 56 */
> > } u; /* 16 56 */
> > union {
> > struct virtio_crypto_sym_create_session_req sym_create_session; /* 0 56 */
> > struct virtio_crypto_hash_create_session_req hash_create_session; /* 0 56 */
> > struct virtio_crypto_mac_create_session_req mac_create_session; /* 0 56 */
> > struct virtio_crypto_aead_create_session_req aead_create_session; /* 0 56 */
> > struct virtio_crypto_akcipher_create_session_req akcipher_create_session; /* 0 56 */
> > struct virtio_crypto_destroy_session_req destroy_session; /* 0 56 */
> > __u8 padding[56]; /* 0 56 */
> > };
> >
> >
> > /* size: 72, cachelines: 2, members: 2 */
> > /* last cacheline: 8 bytes */
> > };
> >
> > (so size and p_size_field should be 56) and the type of the para
> > parameter in virtio_crypto_alg_akcipher_init_session() is 'void *' but
> > the para passed by reference to
> > virtio_crypto_alg_akcipher_init_session() in virtio_crypto_rsa_set_key()
> > has a type of 'struct virtio_crypto_akcipher_session_para':
> >
> > struct virtio_crypto_akcipher_session_para {
> > __le32 algo; /* 0 4 */
> > __le32 keytype; /* 4 4 */
> > __le32 keylen; /* 8 4 */
> > union {
> > struct virtio_crypto_rsa_session_para rsa; /* 12 8 */
> > struct virtio_crypto_ecdsa_session_para ecdsa; /* 12 8 */
> > } u; /* 12 8 */
> > union {
> > struct virtio_crypto_rsa_session_para rsa; /* 0 8 */
> > struct virtio_crypto_ecdsa_session_para ecdsa; /* 0 8 */
> > };
> >
> >
> > /* size: 20, cachelines: 1, members: 4 */
> > /* last cacheline: 20 bytes */
> > };
> >
> > (so q_size_field would be 20 if clang were able to do inlining to see
> > through the 'void *'...?), which would result in the
> >
> > __compiletime_lessthan(q_size_field, size)
> >
> > check succeeding and triggering the warning because 20 < 56, so it does
> > seem like there is an overread of the source buffer here? Adding the
>
> Looks like it; I think either the passed 'para' should be of type
> virtio_crypto_akcipher_create_session_req() or it should only copy
> sizeof(struct virtio_crypto_akcipher_session_para) bytes.
>
> Anyway, how did you find that ? Is there a magic trick to find the
> actual code causing the warning ? I am asking because we had seen
> similar warnings before, and it would help to know how to find the
> problematic code.
>
> Thanks,
> Guenter
>
> > maintainers of the driver and subsystem in question.
> >
> > Cheers,
> > Nathan
CC patch contributor before I revert the whole thing.
--
MST
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-26 23:55 ` Guenter Roeck
2024-01-27 0:03 ` Nathan Chancellor
2024-01-28 11:13 ` Michael S. Tsirkin
@ 2024-01-29 8:46 ` Michael S. Tsirkin
2024-01-29 9:58 ` zhenwei pi
2 siblings, 1 reply; 17+ messages in thread
From: Michael S. Tsirkin @ 2024-01-29 8:46 UTC (permalink / raw)
To: Guenter Roeck
Cc: Nathan Chancellor, Greg Kroah-Hartman, stable, patches,
linux-kernel, torvalds, llvm, keescook, arei.gonglei, jasowang,
virtualization, linux-crypto, zhenwei pi
On Fri, Jan 26, 2024 at 03:55:02PM -0800, Guenter Roeck wrote:
> On 1/26/24 14:35, Nathan Chancellor wrote:
> > (slimming up the CC list, I don't think this is too relevant to the
> > wider stable community)
> >
> > On Fri, Jan 26, 2024 at 01:01:15PM -0800, Guenter Roeck wrote:
> > > On 1/26/24 12:34, Nathan Chancellor wrote:
> > > > On Fri, Jan 26, 2024 at 10:17:23AM -0800, Guenter Roeck wrote:
> > > > > On 1/26/24 09:51, Greg Kroah-Hartman wrote:
> > > > > > On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
> > > > > > > On 1/22/24 15:55, Greg Kroah-Hartman wrote:
> > > > > > > > This is the start of the stable review cycle for the 5.10.209 release.
> > > > > > > > There are 286 patches in this series, all will be posted as a response
> > > > > > > > to this one. If anyone has any issues with these being applied, please
> > > > > > > > let me know.
> > > > > > > >
> > > > > > > > Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
> > > > > > > > Anything received after that time might be too late.
> > > > > > > >
> > > > > > > [ ... ]
> > > > > > >
> > > > > > > > zhenwei pi <pizhenwei@bytedance.com>
> > > > > > > > virtio-crypto: implement RSA algorithm
> > > > > > > >
> > > > > > >
> > > > > > > Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
> > > > > > > It is quite beyond a bug fix. Also, unless I am really missing something,
> > > > > > > the series (or at least this patch) was not applied to v5.15.y, so we now
> > > > > > > have functionality in v5.10.y which is not in v5.15.y.
> > > > > >
> > > > > > See the commit text, it was a dependency of a later fix and documented
> > > > > > as such.
> > > > > >
> > > > > > Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
> > > > > > gladly accepted :)
> > > > > >
> > > > >
> > > > > We reverted the entire series from the merge because it results in a build
> > > > > failure for us.
> > > > >
> > > > > In file included from /home/groeck/src/linux-chromeos/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c:10:
> > > > > In file included from /home/groeck/src/linux-chromeos/include/linux/mpi.h:21:
> > > > > In file included from /home/groeck/src/linux-chromeos/include/linux/scatterlist.h:5:
> > > > > In file included from /home/groeck/src/linux-chromeos/include/linux/string.h:293:
> > > > > /home/groeck/src/linux-chromeos/include/linux/fortify-string.h:512:4: error: call to __read_overflow2_field declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
> > > > > __read_overflow2_field(q_size_field, size);
> > > >
> > > > For what it's worth, this is likely self inflicted for chromeos-5.10,
> > > > which carries a revert of commit eaafc590053b ("fortify: Explicitly
> > > > disable Clang support") as commit c19861d34c003 ("CHROMIUM: Revert
> > > > "fortify: Explicitly disable Clang support""). I don't see the series
> > > > that added proper support for clang to fortify in 5.18 that ended with
> > > > commit 281d0c962752 ("fortify: Add Clang support") in that ChromeOS
> > > > branch, so this seems somewhat expected.
> > > >
> > >
> > > That explains that ;-). I don't mind if the patches stay in v5.10.y,
> > > we have them reverted anyway.
> > >
> > > The revert was a pure process issue, as you may see when looking into
> > > commit c19861d34c003, so, yes, I agree that it is self-inflicted damage.
> > > Still, that doesn't explain why the problem exists in 5.18+.
> > >
> > > > > I also see that upstream (starting with 6.1) when trying to build it with clang,
> > > > > so I guess it is one of those bug-for-bug compatibility things. I really have
> > > > > no idea what causes it, or why we don't see the problem when building
> > > > > chromeos-6.1 or chromeos-6.6, but (so far) only with chromeos-5.10 after
> > > > > merging 5.10.209 into it. Making things worse, the problem isn't _always_
> > > > > seen. Sometimes I can compile the file in 6.1.y without error, sometimes not.
> > > > > I have no idea what triggers the problem.
> > > >
> > > > Have a .config that reproduces it on upstream? I have not personally
> > > > seen this warning in my build matrix nor has our continuous-integration
> > > > matrix (I don't see it in the warning output at the bottom but that
> > > > could have missed something for some reason) in 6.1:
> > > >
> > >
> > > The following command sequence reproduces the problem for me with all stable
> > > branches starting with 5.18.y (plus mainline).
> > >
> > > rm -rf /tmp/crypto-build
> > > mkdir /tmp/crypto-build
> > > make -j CC=clang-15 mrproper >/dev/null 2>&1
> > > make -j O=/tmp/crypto-build CC=clang-15 allmodconfig >/dev/null 2>&1
> > > make -j O=/tmp/crypto-build W=1 CC=clang-15 drivers/crypto/virtio/virtio_crypto_akcipher_algs.o
> > >
> > > I tried clang versions 14, 15, and 16. This is with my home system running
> > > Ubuntu 22.04, no ChromeOS or Google specifics/internals involved. For clang-15,
> > > the version is
> > >
> > > Ubuntu clang version 15.0.7
> > > Target: x86_64-pc-linux-gnu
> > > Thread model: posix
> > > InstalledDir: /usr/bin
> >
> > Okay interesting, this warning is hidden behind W=1, which our CI does
> > not test with. Looks like it has been that way since the introduction of
> > these checks in f68f2ff91512 ("fortify: Detect struct member overflows
> > in memcpy() at compile-time").
> >
>
> Interestingly the warning is seen in chromeos-5.10, without this patch,
> and without W=1. I guess that must have to do with the revert which is
> finally biting us.
>
> > I think this is a legitimate warning though. It is complaining about the
> > second memcpy() in virtio_crypto_alg_akcipher_init_session():
> >
> > memcpy(&ctrl->u, para, sizeof(ctrl->u));
> >
> > where ctrl is:
> >
> > struct virtio_crypto_op_ctrl_req {
> > struct virtio_crypto_ctrl_header header; /* 0 16 */
> > union {
> > struct virtio_crypto_sym_create_session_req sym_create_session; /* 16 56 */
> > struct virtio_crypto_hash_create_session_req hash_create_session; /* 16 56 */
> > struct virtio_crypto_mac_create_session_req mac_create_session; /* 16 56 */
> > struct virtio_crypto_aead_create_session_req aead_create_session; /* 16 56 */
> > struct virtio_crypto_akcipher_create_session_req akcipher_create_session; /* 16 56 */
> > struct virtio_crypto_destroy_session_req destroy_session; /* 16 56 */
> > __u8 padding[56]; /* 16 56 */
> > } u; /* 16 56 */
> > union {
> > struct virtio_crypto_sym_create_session_req sym_create_session; /* 0 56 */
> > struct virtio_crypto_hash_create_session_req hash_create_session; /* 0 56 */
> > struct virtio_crypto_mac_create_session_req mac_create_session; /* 0 56 */
> > struct virtio_crypto_aead_create_session_req aead_create_session; /* 0 56 */
> > struct virtio_crypto_akcipher_create_session_req akcipher_create_session; /* 0 56 */
> > struct virtio_crypto_destroy_session_req destroy_session; /* 0 56 */
> > __u8 padding[56]; /* 0 56 */
> > };
> >
> >
> > /* size: 72, cachelines: 2, members: 2 */
> > /* last cacheline: 8 bytes */
> > };
> >
> > (so size and p_size_field should be 56) and the type of the para
> > parameter in virtio_crypto_alg_akcipher_init_session() is 'void *' but
> > the para passed by reference to
> > virtio_crypto_alg_akcipher_init_session() in virtio_crypto_rsa_set_key()
> > has a type of 'struct virtio_crypto_akcipher_session_para':
> >
> > struct virtio_crypto_akcipher_session_para {
> > __le32 algo; /* 0 4 */
> > __le32 keytype; /* 4 4 */
> > __le32 keylen; /* 8 4 */
> > union {
> > struct virtio_crypto_rsa_session_para rsa; /* 12 8 */
> > struct virtio_crypto_ecdsa_session_para ecdsa; /* 12 8 */
> > } u; /* 12 8 */
> > union {
> > struct virtio_crypto_rsa_session_para rsa; /* 0 8 */
> > struct virtio_crypto_ecdsa_session_para ecdsa; /* 0 8 */
> > };
> >
> >
> > /* size: 20, cachelines: 1, members: 4 */
> > /* last cacheline: 20 bytes */
> > };
> >
> > (so q_size_field would be 20 if clang were able to do inlining to see
> > through the 'void *'...?), which would result in the
> >
> > __compiletime_lessthan(q_size_field, size)
> >
> > check succeeding and triggering the warning because 20 < 56, so it does
> > seem like there is an overread of the source buffer here? Adding the
>
> Looks like it; I think either the passed 'para' should be of type
> virtio_crypto_akcipher_create_session_req() or it should only copy
> sizeof(struct virtio_crypto_akcipher_session_para) bytes.
>
> Anyway, how did you find that ? Is there a magic trick to find the
> actual code causing the warning ? I am asking because we had seen
> similar warnings before, and it would help to know how to find the
> problematic code.
>
> Thanks,
> Guenter
Cc: zhenwei pi <pizhenwei@bytedance.com>
Zhenwei I think you wrote most of the code here.
Can you take a look please?
Stack overflows are plus plus ungood.
> > maintainers of the driver and subsystem in question.
> >
> > Cheers,
> > Nathan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Re: [PATCH 5.10 000/286] 5.10.209-rc1 review
2024-01-29 8:46 ` Michael S. Tsirkin
@ 2024-01-29 9:58 ` zhenwei pi
0 siblings, 0 replies; 17+ messages in thread
From: zhenwei pi @ 2024-01-29 9:58 UTC (permalink / raw)
To: Michael S. Tsirkin, Guenter Roeck
Cc: Nathan Chancellor, Greg Kroah-Hartman, stable, patches,
linux-kernel, torvalds, llvm, keescook, arei.gonglei, jasowang,
virtualization, linux-crypto
On 1/29/24 16:46, Michael S. Tsirkin wrote:
> On Fri, Jan 26, 2024 at 03:55:02PM -0800, Guenter Roeck wrote:
>> On 1/26/24 14:35, Nathan Chancellor wrote:
>>> (slimming up the CC list, I don't think this is too relevant to the
>>> wider stable community)
>>>
>>> On Fri, Jan 26, 2024 at 01:01:15PM -0800, Guenter Roeck wrote:
>>>> On 1/26/24 12:34, Nathan Chancellor wrote:
>>>>> On Fri, Jan 26, 2024 at 10:17:23AM -0800, Guenter Roeck wrote:
>>>>>> On 1/26/24 09:51, Greg Kroah-Hartman wrote:
>>>>>>> On Fri, Jan 26, 2024 at 08:46:42AM -0800, Guenter Roeck wrote:
>>>>>>>> On 1/22/24 15:55, Greg Kroah-Hartman wrote:
>>>>>>>>> This is the start of the stable review cycle for the 5.10.209 release.
>>>>>>>>> There are 286 patches in this series, all will be posted as a response
>>>>>>>>> to this one. If anyone has any issues with these being applied, please
>>>>>>>>> let me know.
>>>>>>>>>
>>>>>>>>> Responses should be made by Wed, 24 Jan 2024 23:56:49 +0000.
>>>>>>>>> Anything received after that time might be too late.
>>>>>>>>>
>>>>>>>> [ ... ]
>>>>>>>>
>>>>>>>>> zhenwei pi <pizhenwei@bytedance.com>
>>>>>>>>> virtio-crypto: implement RSA algorithm
>>>>>>>>>
>>>>>>>>
>>>>>>>> Curious: Why was this (and its subsequent fixes) backported to v5.10.y ?
>>>>>>>> It is quite beyond a bug fix. Also, unless I am really missing something,
>>>>>>>> the series (or at least this patch) was not applied to v5.15.y, so we now
>>>>>>>> have functionality in v5.10.y which is not in v5.15.y.
>>>>>>>
>>>>>>> See the commit text, it was a dependency of a later fix and documented
>>>>>>> as such.
>>>>>>>
>>>>>>> Having it in 5.10 and not 5.15 is a bit odd, I agree, so patches are
>>>>>>> gladly accepted :)
>>>>>>>
>>>>>>
>>>>>> We reverted the entire series from the merge because it results in a build
>>>>>> failure for us.
>>>>>>
>>>>>> In file included from /home/groeck/src/linux-chromeos/drivers/crypto/virtio/virtio_crypto_akcipher_algs.c:10:
>>>>>> In file included from /home/groeck/src/linux-chromeos/include/linux/mpi.h:21:
>>>>>> In file included from /home/groeck/src/linux-chromeos/include/linux/scatterlist.h:5:
>>>>>> In file included from /home/groeck/src/linux-chromeos/include/linux/string.h:293:
>>>>>> /home/groeck/src/linux-chromeos/include/linux/fortify-string.h:512:4: error: call to __read_overflow2_field declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
>>>>>> __read_overflow2_field(q_size_field, size);
>>>>>
>>>>> For what it's worth, this is likely self inflicted for chromeos-5.10,
>>>>> which carries a revert of commit eaafc590053b ("fortify: Explicitly
>>>>> disable Clang support") as commit c19861d34c003 ("CHROMIUM: Revert
>>>>> "fortify: Explicitly disable Clang support""). I don't see the series
>>>>> that added proper support for clang to fortify in 5.18 that ended with
>>>>> commit 281d0c962752 ("fortify: Add Clang support") in that ChromeOS
>>>>> branch, so this seems somewhat expected.
>>>>>
>>>>
>>>> That explains that ;-). I don't mind if the patches stay in v5.10.y,
>>>> we have them reverted anyway.
>>>>
>>>> The revert was a pure process issue, as you may see when looking into
>>>> commit c19861d34c003, so, yes, I agree that it is self-inflicted damage.
>>>> Still, that doesn't explain why the problem exists in 5.18+.
>>>>
>>>>>> I also see that upstream (starting with 6.1) when trying to build it with clang,
>>>>>> so I guess it is one of those bug-for-bug compatibility things. I really have
>>>>>> no idea what causes it, or why we don't see the problem when building
>>>>>> chromeos-6.1 or chromeos-6.6, but (so far) only with chromeos-5.10 after
>>>>>> merging 5.10.209 into it. Making things worse, the problem isn't _always_
>>>>>> seen. Sometimes I can compile the file in 6.1.y without error, sometimes not.
>>>>>> I have no idea what triggers the problem.
>>>>>
>>>>> Have a .config that reproduces it on upstream? I have not personally
>>>>> seen this warning in my build matrix nor has our continuous-integration
>>>>> matrix (I don't see it in the warning output at the bottom but that
>>>>> could have missed something for some reason) in 6.1:
>>>>>
>>>>
>>>> The following command sequence reproduces the problem for me with all stable
>>>> branches starting with 5.18.y (plus mainline).
>>>>
>>>> rm -rf /tmp/crypto-build
>>>> mkdir /tmp/crypto-build
>>>> make -j CC=clang-15 mrproper >/dev/null 2>&1
>>>> make -j O=/tmp/crypto-build CC=clang-15 allmodconfig >/dev/null 2>&1
>>>> make -j O=/tmp/crypto-build W=1 CC=clang-15 drivers/crypto/virtio/virtio_crypto_akcipher_algs.o
>>>>
>>>> I tried clang versions 14, 15, and 16. This is with my home system running
>>>> Ubuntu 22.04, no ChromeOS or Google specifics/internals involved. For clang-15,
>>>> the version is
>>>>
>>>> Ubuntu clang version 15.0.7
>>>> Target: x86_64-pc-linux-gnu
>>>> Thread model: posix
>>>> InstalledDir: /usr/bin
>>>
>>> Okay interesting, this warning is hidden behind W=1, which our CI does
>>> not test with. Looks like it has been that way since the introduction of
>>> these checks in f68f2ff91512 ("fortify: Detect struct member overflows
>>> in memcpy() at compile-time").
>>>
>>
>> Interestingly the warning is seen in chromeos-5.10, without this patch,
>> and without W=1. I guess that must have to do with the revert which is
>> finally biting us.
>>
>>> I think this is a legitimate warning though. It is complaining about the
>>> second memcpy() in virtio_crypto_alg_akcipher_init_session():
>>>
>>> memcpy(&ctrl->u, para, sizeof(ctrl->u));
>>>
>>> where ctrl is:
>>>
>>> struct virtio_crypto_op_ctrl_req {
>>> struct virtio_crypto_ctrl_header header; /* 0 16 */
>>> union {
>>> struct virtio_crypto_sym_create_session_req sym_create_session; /* 16 56 */
>>> struct virtio_crypto_hash_create_session_req hash_create_session; /* 16 56 */
>>> struct virtio_crypto_mac_create_session_req mac_create_session; /* 16 56 */
>>> struct virtio_crypto_aead_create_session_req aead_create_session; /* 16 56 */
>>> struct virtio_crypto_akcipher_create_session_req akcipher_create_session; /* 16 56 */
>>> struct virtio_crypto_destroy_session_req destroy_session; /* 16 56 */
>>> __u8 padding[56]; /* 16 56 */
>>> } u; /* 16 56 */
>>> union {
>>> struct virtio_crypto_sym_create_session_req sym_create_session; /* 0 56 */
>>> struct virtio_crypto_hash_create_session_req hash_create_session; /* 0 56 */
>>> struct virtio_crypto_mac_create_session_req mac_create_session; /* 0 56 */
>>> struct virtio_crypto_aead_create_session_req aead_create_session; /* 0 56 */
>>> struct virtio_crypto_akcipher_create_session_req akcipher_create_session; /* 0 56 */
>>> struct virtio_crypto_destroy_session_req destroy_session; /* 0 56 */
>>> __u8 padding[56]; /* 0 56 */
>>> };
>>>
>>>
>>> /* size: 72, cachelines: 2, members: 2 */
>>> /* last cacheline: 8 bytes */
>>> };
>>>
>>> (so size and p_size_field should be 56) and the type of the para
>>> parameter in virtio_crypto_alg_akcipher_init_session() is 'void *' but
>>> the para passed by reference to
>>> virtio_crypto_alg_akcipher_init_session() in virtio_crypto_rsa_set_key()
>>> has a type of 'struct virtio_crypto_akcipher_session_para':
>>>
>>> struct virtio_crypto_akcipher_session_para {
>>> __le32 algo; /* 0 4 */
>>> __le32 keytype; /* 4 4 */
>>> __le32 keylen; /* 8 4 */
>>> union {
>>> struct virtio_crypto_rsa_session_para rsa; /* 12 8 */
>>> struct virtio_crypto_ecdsa_session_para ecdsa; /* 12 8 */
>>> } u; /* 12 8 */
>>> union {
>>> struct virtio_crypto_rsa_session_para rsa; /* 0 8 */
>>> struct virtio_crypto_ecdsa_session_para ecdsa; /* 0 8 */
>>> };
>>>
>>>
>>> /* size: 20, cachelines: 1, members: 4 */
>>> /* last cacheline: 20 bytes */
>>> };
>>>
>>> (so q_size_field would be 20 if clang were able to do inlining to see
>>> through the 'void *'...?), which would result in the
>>>
>>> __compiletime_lessthan(q_size_field, size)
>>>
>>> check succeeding and triggering the warning because 20 < 56, so it does
>>> seem like there is an overread of the source buffer here? Adding the
>>
>> Looks like it; I think either the passed 'para' should be of type
>> virtio_crypto_akcipher_create_session_req() or it should only copy
>> sizeof(struct virtio_crypto_akcipher_session_para) bytes.
>>
>> Anyway, how did you find that ? Is there a magic trick to find the
>> actual code causing the warning ? I am asking because we had seen
>> similar warnings before, and it would help to know how to find the
>> problematic code.
>>
>> Thanks,
>> Guenter
>
>
>
> Cc: zhenwei pi <pizhenwei@bytedance.com>
>
> Zhenwei I think you wrote most of the code here.
> Can you take a look please?
> Stack overflows are plus plus ungood.
>
>
>
>
>>> maintainers of the driver and subsystem in question.
>>>
>>> Cheers,
>>> Nathan
>
I can also reproduce this warning by commands on ubuntu-2204:
make -j CC=clang-14 mrproper >/dev/null 2>&1
make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1
make -j O=/tmp/crypto-build W=1 CC=clang-14
drivers/crypto/virtio/virtio_crypto_akcipher_algs.o
so sorry on this issue, I think Guenter's suggestion is right(also test
by these commands), I'll send a fix later.
--
zhenwei pi
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2024-01-29 9:58 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-22 23:55 [PATCH 5.10 000/286] 5.10.209-rc1 review Greg Kroah-Hartman
2024-01-23 3:32 ` Dominique Martinet
2024-01-23 21:19 ` Florian Fainelli
2024-01-24 11:25 ` Naresh Kamboju
2024-01-26 16:46 ` Guenter Roeck
2024-01-26 17:51 ` Greg Kroah-Hartman
2024-01-26 18:17 ` Guenter Roeck
2024-01-26 18:48 ` Greg Kroah-Hartman
2024-01-26 20:34 ` Nathan Chancellor
2024-01-26 21:01 ` Guenter Roeck
2024-01-26 21:53 ` Greg Kroah-Hartman
2024-01-26 22:35 ` Nathan Chancellor
2024-01-26 23:55 ` Guenter Roeck
2024-01-27 0:03 ` Nathan Chancellor
2024-01-28 11:13 ` Michael S. Tsirkin
2024-01-29 8:46 ` Michael S. Tsirkin
2024-01-29 9:58 ` zhenwei pi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).