* [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).