linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [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).