August 2023 - Linux-stable-mirror

[PATCH v2] iio: cros_ec: fix an use-after-free in cros_ec_sensors_push_data()

by Tzung-Bi Shih

cros_ec_sensors_push_data() reads `indio_dev->active_scan_mask` and calls iio_push_to_buffers_with_timestamp() without making sure the `indio_dev` stays in buffer mode. There is a race if `indio_dev` exits buffer mode right before cros_ec_sensors_push_data() accesses them. An use-after-free on `indio_dev->active_scan_mask` was observed. The call trace: [...] _find_next_bit cros_ec_sensors_push_data cros_ec_sensorhub_event blocking_notifier_call_chain cros_ec_irq_thread It was caused by a race condition: one thread just freed `active_scan_mask` at [1]; while another thread tried to access the memory at [2]. Fix it by calling iio_device_claim_buffer_mode() to ensure the `indio_dev` can't exit buffer mode during cros_ec_sensors_push_data(). [1]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/industrialio-buffe… [2]: https://elixir.bootlin.com/linux/v6.5/source/drivers/iio/common/cros_ec_sen… Cc: stable(a)vger.kernel.org Fixes: aa984f1ba4a4 ("iio: cros_ec: Register to cros_ec_sensorhub when EC supports FIFO") Signed-off-by: Tzung-Bi Shih <tzungbi(a)kernel.org> --- Changes from v1(https://patchwork.kernel.org/project/linux-iio/patch/20230828094339.1248…: - Use iio_device_{claim|release}_buffer_mode() instead of accessing `mlock`. drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c index b72d39fc2434..6bfe5d6847e7 100644 --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c @@ -190,8 +190,11 @@ int cros_ec_sensors_push_data(struct iio_dev *indio_dev, /* * Ignore samples if the buffer is not set: it is needed if the ODR is * set but the buffer is not enabled yet. + * + * Note: iio_device_claim_buffer_mode() returns -EBUSY if the buffer + * is not enabled. */ - if (!iio_buffer_enabled(indio_dev)) + if (iio_device_claim_buffer_mode(indio_dev) < 0) return 0; out = (s16 *)st->samples; @@ -210,6 +213,7 @@ int cros_ec_sensors_push_data(struct iio_dev *indio_dev, iio_push_to_buffers_with_timestamp(indio_dev, st->samples, timestamp + delta); + iio_device_release_buffer_mode(indio_dev); return 0; } EXPORT_SYMBOL_GPL(cros_ec_sensors_push_data); -- 2.42.0.rc2.253.gd59a3bf2b4-goog

6 months, 3 weeks

5
5
0 0

[PATCH] riscv: kprobes: allow writing to x0

by Nam Cao

Instructions can write to x0, so we should simulate these instructions normally. Currently, the kernel hangs if an instruction who writes to x0 is simulated. Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported") Cc: stable(a)vger.kernel.org Signed-off-by: Nam Cao <namcaov(a)gmail.com> --- arch/riscv/kernel/probes/simulate-insn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/kernel/probes/simulate-insn.c b/arch/riscv/kernel/probes/simulate-insn.c index d3099d67816d..6c166029079c 100644 --- a/arch/riscv/kernel/probes/simulate-insn.c +++ b/arch/riscv/kernel/probes/simulate-insn.c @@ -24,7 +24,7 @@ static inline bool rv_insn_reg_set_val(struct pt_regs *regs, u32 index, unsigned long val) { if (index == 0) - return false; + return true; else if (index <= 31) *((unsigned long *)regs + index) = val; else -- 2.34.1

6 months, 4 weeks

4
3
0 0

Fwd: System (Xeon Nvidia) hangs at boot terminal after kernel 6.4.7

by Bagas Sanjaya

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > Kernel 6.4.6 compiled from source worked AOK on my desktop with Intel Xeon cpu and Nvidia graphics - see below for system specs. > > Kernels 6.4.7 & 6.4.8 also compiled from source with identical configs hang with a frozen boot terminal screen after a significant way through the boot sequence (e.g. whilst running /etc/profile). The system may still be running as a sound is emitted when the power button is pressed (only way to escape from the system hang). > > The issue seems to be specific to the hardware of this desktop as the problem kernels do boot through to completion on other machines. > > A test was done with a different build (from Porteus) of kernel 6.5-RC4 and that did not hang - but kernel 6.4.7 from the same builder hung just like my build. > > I apologise that I cannot provide any detailed diagnostics - but I can put diagnostics into /etc/profile and provide screenshots if requested. > > Forum thread with more details and screenshots: > https://forum.puppylinux.com/viewtopic.php?p=95733#p95733 > > Computer Profile: > Machine Dell Inc. Precision WorkStation T5400 (version: Not Specified) > Mainboard Dell Inc. 0RW203 (version: NA) > • BIOS Dell Inc. A11 | Date: 04/30/2012 | Type: Legacy > • CPU Intel(R) Xeon(R) CPU E5450 @ 3.00GHz (4 cores) > • RAM Total: 7955 MB | Used: 1555 MB (19.5%) | Actual Used: 775 MB (9.7%) > Graphics Resolution: 1366x768 pixels | Display Server: X.Org 21.1.8 > • device-0 NVIDIA Corporation GT218 [NVS 300] [10de:10d8] (rev a2) > Audio ALSA > • device-0 Intel Corporation 631xESB/632xESB High Definition Audio Controller [8086:269a] (rev 09) > • device-1 NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1) > Network wlan1 > • device-0 Ethernet: Broadcom Inc. and subsidiaries NetXtreme BCM5754 Gigabit Ethernet PCI Express [14e4:167a] (rev 02) See Bugzilla for the full thread. FYI, this is stable-specific regression since it doesn't appear on mainline. Also, I have asked the reporter to also open the issue on gitlab.freedesktop.org tracker (as it is the standard for DRM subsystem). To the reporter (on To: list): It'd been great if you also have netconsole output on your Bugzilla report, providing that you have another machine connecting to your problematic one. Anyway, I'm adding this regression to be tracked by regzbot: #regzbot introduced: v6.4.6..v6.4.7 https://bugzilla.kernel.org/show_bug.cgi?id=217776 #regzbot link: https://forum.puppylinux.com/viewtopic.php?p=95733#p95733 Thanks. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217776 -- An old man doll... just what I always wanted! - Clara

7 months

3
2
0 0

Fwd: WARNING: CPU: 13 PID: 3837105 at kernel/sched/sched.h:1561 __cfsb_csd_unthrottle+0x149/0x160

by Bagas Sanjaya

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > Hello, we recently got a few kernel crashes with following backtrace. Happened on 6.4.12 (and 6.4.11 I think) but did not happen (I think) on 6.4.4. > > [293790.928007] ------------[ cut here ]------------ > [293790.929905] rq->clock_update_flags & RQCF_ACT_SKIP > [293790.929919] WARNING: CPU: 13 PID: 3837105 at kernel/sched/sched.h:1561 __cfsb_csd_unthrottle+0x149/0x160 > [293790.933694] Modules linked in: xt_owner(E) xt_REDIRECT(E) mptcp_diag(E) xsk_diag(E) raw_diag(E) unix_diag(E) af_packet_diag(E) netlink_diag(E) tcp_diag(E) udp_diag(E) inet_diag(E) rpcsec_gss_krb5(E) auth_rpcgss(E) nfsv4(E) nfs(E) lockd(E) grace(E) fscache(E) netfs(E) nbd(E) rbd(E) libceph(E) dns_resolver(E) xt_set(E) ipt_rpfilter(E) ip_set_hash_ip(E) ip_set_hash_net(E) bpf_preload(E) xt_multiport(E) veth(E) wireguard(E) libchacha20poly1305(E) chacha_x86_64(E) poly1305_x86_64(E) ip6_udp_tunnel(E) udp_tunnel(E) curve25519_x86_64(E) libcurve25519_generic(E) libchacha(E) nf_conntrack_netlink(E) xt_nat(E) xt_statistic(E) xt_addrtype(E) ipt_REJECT(E) nf_reject_ipv4(E) ip_set(E) ip_vs_sh(E) ip_vs_wrr(E) ip_vs_rr(E) ip_vs(E) xt_MASQUERADE(E) nft_chain_nat(E) xt_mark(E) xt_conntrack(E) xt_comment(E) nft_compat(E) nf_tables(E) nfnetlink(E) br_netfilter(E) bridge(E) stp(E) llc(E) iptable_nat(E) nf_nat(E) iptable_filter(E) ip_tables(E) overlay(E) dummy(E) sunrpc(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) > [293790.933738] binfmt_misc(E) tls(E) isofs(E) intel_rapl_msr(E) intel_rapl_common(E) kvm_amd(E) virtio_gpu(E) ccp(E) virtio_dma_buf(E) drm_shmem_helper(E) virtio_net(E) vfat(E) kvm(E) i2c_i801(E) drm_kms_helper(E) net_failover(E) irqbypass(E) syscopyarea(E) fat(E) i2c_smbus(E) failover(E) sysfillrect(E) virtio_balloon(E) sysimgblt(E) drm(E) fuse(E) ext4(E) mbcache(E) jbd2(E) sr_mod(E) cdrom(E) sg(E) ahci(E) libahci(E) crct10dif_pclmul(E) crc32_pclmul(E) polyval_clmulni(E) libata(E) polyval_generic(E) ghash_clmulni_intel(E) sha512_ssse3(E) virtio_blk(E) serio_raw(E) btrfs(E) xor(E) zstd_compress(E) raid6_pq(E) libcrc32c(E) crc32c_intel(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) > [293790.946262] Unloaded tainted modules: edac_mce_amd(E):1 > [293790.956625] CPU: 13 PID: 3837105 Comm: QueryWorker-30f Tainted: G W E 6.4.12-1.gdc.el9.x86_64 #1 > [293790.957963] Hardware name: RDO OpenStack Compute/RHEL, BIOS edk2-20230301gitf80f052277c8-2.el9 03/01/2023 > [293790.959681] RIP: 0010:__cfsb_csd_unthrottle+0x149/0x160 > [293790.960933] Code: 37 fa ff 0f 0b e9 17 ff ff ff 80 3d 41 59 fc 01 00 0f 85 21 ff ff ff 48 c7 c7 98 03 95 9d c6 05 2d 59 fc 01 01 e8 77 37 fa ff <0f> 0b 41 8b 85 88 09 00 00 e9 00 ff ff ff 66 0f 1f 84 00 00 00 00 > [293790.964077] RSP: 0000:ffffb708e7217db8 EFLAGS: 00010086 > [293790.965160] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027 > [293790.966340] RDX: ffff905482c5f708 RSI: 0000000000000001 RDI: ffff905482c5f700 > [293790.967839] RBP: ffff9029bb0e9e00 R08: 0000000000000000 R09: 00000000ffff7fff > [293790.969496] R10: ffffb708e7217c58 R11: ffffffff9e3e2c88 R12: 00000000000317c0 > [293790.970859] R13: ffff903602c317c0 R14: 0000000000000000 R15: ffff905482c726b8 > [293790.972085] FS: 00007ff3b66fe640(0000) GS:ffff905482c40000(0000) knlGS:0000000000000000 > [293790.973678] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [293790.974663] CR2: 00007f16889036c0 CR3: 0000002072e34004 CR4: 0000000000770ee0 > [293790.976108] PKRU: 55555554 > [293790.977048] Call Trace: > [293790.978013] <TASK> > [293790.978678] ? __warn+0x80/0x130 > [293790.979727] ? __cfsb_csd_unthrottle+0x149/0x160 > [293790.980824] ? report_bug+0x195/0x1a0 > [293790.981806] ? handle_bug+0x3c/0x70 > [293790.982884] ? exc_invalid_op+0x14/0x70 > [293790.983837] ? asm_exc_invalid_op+0x16/0x20 > [293790.984626] ? __cfsb_csd_unthrottle+0x149/0x160 > [293790.985599] ? __cfsb_csd_unthrottle+0x149/0x160 > [293790.986583] unregister_fair_sched_group+0x73/0x1d0 > [293790.987682] sched_unregister_group_rcu+0x1a/0x40 > [293790.988752] rcu_do_batch+0x199/0x4d0 > [293790.989643] rcu_core+0x267/0x420 > [293790.990418] __do_softirq+0xc8/0x2ab > [293790.991285] __irq_exit_rcu+0xb9/0xf0 > [293790.992555] sysvec_apic_timer_interrupt+0x3c/0x90 > [293790.993477] asm_sysvec_apic_timer_interrupt+0x16/0x20 > [293790.994171] RIP: 0033:0x7ff4dca91f60 > [293790.994801] Code: 75 15 49 8b f7 c5 f8 77 49 ba 80 6c bf f3 f4 7f 00 00 41 ff d2 eb 0d 4b 89 7c 13 f8 49 83 c2 f8 4d 89 57 70 48 8b c3 c5 f8 77 <48> 83 c4 50 5d 4d 8b 97 08 01 00 00 41 85 02 c3 49 8d 14 fc 8b 7a > [293790.997256] RSP: 002b:00007ff3b66fd190 EFLAGS: 00000246 > [293790.998138] RAX: 0000000655fd6ed0 RBX: 0000000655fd6ed0 RCX: 0000000000000004 > [293790.999184] RDX: 0000000000000000 RSI: 000000066cf4939c RDI: 00007ff4f1180eb7 > [293791.000220] RBP: 0000000000000004 R08: 000000066cf48530 R09: 000000066cf493a8 > [293791.001274] R10: 00000000000007f0 R11: 00007ff3bc00ca80 R12: 0000000000000000 > [293791.002222] R13: 000000066cf49390 R14: 00000000cd9e9272 R15: 00007ff39c033800 > [293791.002966] </TASK> > [293791.003489] ---[ end trace 0000000000000000 ]--- > [293791.004440] ------------[ cut here ]------------ > [293791.005479] rq->clock_update_flags < RQCF_ACT_SKIP > [293791.005493] WARNING: CPU: 0 PID: 3920513 at kernel/sched/sched.h:1496 update_curr+0x162/0x1d0 > > Sadly I don't have more info but hopefully this stacktrace will be enough. > See Bugzilla for the full thread. Anyway, I'm adding this regression to regzbot: #regzbot introduced: ebb83d84e49b54 https://bugzilla.kernel.org/show_bug.cgi?id=217843 Thanks. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217843 -- An old man doll... just what I always wanted! - Clara

7 months

7
9
0 0

[PATCH 5.10 000/135] 5.10.192-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.192 release. There are 135 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 Sat, 26 Aug 2023 17:05:50 +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.192-r… 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(a)linuxfoundation.org> Linux 5.10.192-rc1 Borislav Petkov (AMD) <bp(a)alien8.de> x86/srso: Correct the mitigation status when SMT is disabled Peter Zijlstra <peterz(a)infradead.org> objtool/x86: Fixup frame-pointer vs rethunk Petr Pavlu <petr.pavlu(a)suse.com> x86/retpoline,kprobes: Fix position of thunk sections with CONFIG_LTO_CLANG Borislav Petkov (AMD) <bp(a)alien8.de> x86/srso: Disable the mitigation on unaffected configurations Borislav Petkov (AMD) <bp(a)alien8.de> x86/CPU/AMD: Fix the DIV(0) initial fix attempt Sean Christopherson <seanjc(a)google.com> x86/retpoline: Don't clobber RFLAGS during srso_safe_ret() Peter Zijlstra <peterz(a)infradead.org> x86/static_call: Fix __static_call_fixup() Borislav Petkov (AMD) <bp(a)alien8.de> x86/srso: Explain the untraining sequences a bit more Peter Zijlstra <peterz(a)infradead.org> x86/cpu: Cleanup the untrain mess Peter Zijlstra <peterz(a)infradead.org> x86/cpu: Rename srso_(.*)_alias to srso_alias_\1 Peter Zijlstra <peterz(a)infradead.org> x86/cpu: Rename original retbleed methods Peter Zijlstra <peterz(a)infradead.org> x86/cpu: Clean up SRSO return thunk mess Peter Zijlstra <peterz(a)infradead.org> x86/ibt: Add ANNOTATE_NOENDBR Josh Poimboeuf <jpoimboe(a)redhat.com> objtool: Add frame-pointer-specific function ignore Peter Zijlstra <peterz(a)infradead.org> x86/alternative: Make custom return thunk unconditional Peter Zijlstra <peterz(a)infradead.org> x86/cpu: Fix up srso_safe_ret() and __x86_return_thunk() Peter Zijlstra <peterz(a)infradead.org> x86/cpu: Fix __x86_return_thunk symbol type Yangtao Li <frank.li(a)vivo.com> mmc: f-sdh30: fix order of function calls in sdhci_f_sdh30_remove Jason Xing <kernelxing(a)tencent.com> net: fix the RTO timer retransmitting skb every 1ms if linear option is enabled Jason Wang <jasowang(a)redhat.com> virtio-net: set queues after driver_ok Kuniyuki Iwashima <kuniyu(a)amazon.com> af_unix: Fix null-ptr-deref in unix_stream_sendpage(). Xin Long <lucien.xin(a)gmail.com> netfilter: set default timeout to 3 secs for sctp shutdown send and recv state Yibin Ding <yibin.ding(a)unisoc.com> mmc: block: Fix in_flight[issue_type] value error Yang Yingliang <yangyingliang(a)huawei.com> mmc: wbsd: fix double mmc_free_host() in wbsd_init() Russell Harmon via samba-technical <samba-technical(a)lists.samba.org> cifs: Release folio lock on fscache read hit. dengxiang <dengxiang(a)nfschina.com> ALSA: usb-audio: Add support for Mythware XA001AU capture and playback interfaces. Tony Lindgren <tony(a)atomide.com> serial: 8250: Fix oops for port->pm on uart_change_pm() Alexandre Ghiti <alexghiti(a)rivosinc.com> riscv: uaccess: Return the number of bytes effectively not copied Chen Lifu <chenlifu(a)huawei.com> riscv: lib: uaccess: fix CSR_STATUS SR_SUM bit Jisheng Zhang <jszhang(a)kernel.org> riscv: lib: uaccess: fold fixups into body Akira Tsukamoto <akira.tsukamoto(a)gmail.com> riscv: __asm_copy_to-from_user: Optimize unaligned memory access and pipeline stall Kailang Yang <kailang(a)realtek.com> ALSA: hda/realtek - Remodified 3k pull low procedure Jerome Brunet <jbrunet(a)baylibre.com> ASoC: meson: axg-tdm-formatter: fix channel slot allocation Zhang Shurong <zhang_shurong(a)foxmail.com> ASoC: rt5665: add missed regulator_bulk_disable Christopher Obbard <chris.obbard(a)collabora.com> arm64: dts: rockchip: Disable HS400 for eMMC on ROCK Pi 4 FUKAUMI Naoki <naoki(a)radxa.com> arm64: dts: rockchip: sort nodes/properties on rk3399-rock-4 FUKAUMI Naoki <naoki(a)radxa.com> arm64: dts: rockchip: fix regulator name on rk3399-rock-4 Alex Bee <knaerzche(a)gmail.com> arm64: dts: rockchip: add SPDIF node for ROCK Pi 4 Alex Bee <knaerzche(a)gmail.com> arm64: dts: rockchip: add ES8316 codec for ROCK Pi 4 Vicente Bergas <vicencb(a)gmail.com> arm64: dts: rockchip: use USB host by default on rk3399-rock-pi-4 Vicente Bergas <vicencb(a)gmail.com> arm64: dts: rockchip: fix supplies on rk3399-rock-pi-4 Tony Lindgren <tony(a)atomide.com> bus: ti-sysc: Flush posted write on enable before reset Eric Dumazet <edumazet(a)google.com> net: do not allow gso_size to be set to GSO_BY_FRAGS Abel Wu <wuyun.abel(a)bytedance.com> sock: Fix misuse of sk_under_memory_pressure() Alfred Lee <l00g33k(a)gmail.com> net: dsa: mv88e6xxx: Wait for EEPROM done before HW reset Andrii Staikov <andrii.staikov(a)intel.com> i40e: fix misleading debug logs Ziyang Xuan <william.xuanziyang(a)huawei.com> team: Fix incorrect deletion of ETH_P_8021AD protocol vid from slaves Justin Chen <justin.chen(a)broadcom.com> net: phy: broadcom: stub c45 read/write for 54810 Pablo Neira Ayuso <pablo(a)netfilter.org> netfilter: nft_dynset: disallow object maps Sishuai Gong <sishuai.system(a)gmail.com> ipvs: fix racy memcpy in proc_do_sync_threshold Luca Ceresoli <luca.ceresoli(a)bootlin.com> drm/panel: simple: Fix AUO G121EAN01 panel timings according to the docs Petr Machata <petrm(a)nvidia.com> selftests: mirror_gre_changes: Tighten up the TTL test match Lin Ma <linma(a)zju.edu.cn> xfrm: add forgotten nla_policy for XFRMA_MTIMER_THRESH Lin Ma <linma(a)zju.edu.cn> xfrm: add NULL check in xfrm_update_ae_params Zhengchao Shao <shaozhengchao(a)huawei.com> ip_vti: fix potential slab-use-after-free in decode_session6 Zhengchao Shao <shaozhengchao(a)huawei.com> ip6_vti: fix slab-use-after-free in decode_session6 Zhengchao Shao <shaozhengchao(a)huawei.com> xfrm: fix slab-use-after-free in decode_session6 Lin Ma <linma(a)zju.edu.cn> net: xfrm: Amend XFRMA_SEC_CTX nla_policy structure Lin Ma <linma(a)zju.edu.cn> net: af_key: fix sadb_x_filter validation Lin Ma <linma(a)zju.edu.cn> net: xfrm: Fix xfrm_address_filter OOB read Tam Nguyen <tamnguyenchi(a)os.amperecomputing.com> i2c: designware: Handle invalid SMBus block data response length value xiaoshoukui <xiaoshoukui(a)gmail.com> btrfs: fix BUG_ON condition in btrfs_cancel_balance Sherry Sun <sherry.sun(a)nxp.com> tty: serial: fsl_lpuart: Clear the error flags by writing 1 for lpuart32 platforms Yi Yang <yiyang13(a)huawei.com> tty: n_gsm: fix the UAF caused by race condition in gsm_cleanup_mux Nathan Lynch <nathanl(a)linux.ibm.com> powerpc/rtas_flash: allow user copy to flash block cache objects Yuanjun Gong <ruc_gongyuanjun(a)163.com> fbdev: mmp: fix value check in mmphw_probe() Chengfeng Ye <dg573847474(a)gmail.com> i2c: bcm-iproc: Fix bcm_iproc_i2c_isr deadlock issue Wolfram Sang <wsa+renesas(a)sang-engineering.com> virtio-mmio: don't break lifecycle of vm_dev Tang Bin <tangbin(a)cmss.chinamobile.com> virtio-mmio: Use to_virtio_mmio_device() to simply code Ivan Mikhaylov <fr0st61te(a)gmail.com> net/ncsi: change from ndo_set_mac_address to dev_set_mac_address Masami Hiramatsu (Google) <mhiramat(a)kernel.org> tracing/probes: Fix to update dynamic data counter if fetcharg uses it Steven Rostedt (VMware) <rostedt(a)goodmis.org> tracing/probes: Have process_fetch_insn() take a void * instead of pt_regs Sergey Shtylyov <s.shtylyov(a)omp.ru> mmc: meson-gx: fix deferred probing Heiner Kallweit <hkallweit1(a)gmail.com> mmc: meson-gx: use devm_mmc_alloc_host Heiner Kallweit <hkallweit1(a)gmail.com> mmc: core: add devm_mmc_alloc_host Sergey Shtylyov <s.shtylyov(a)omp.ru> mmc: sunxi: fix deferred probing Sergey Shtylyov <s.shtylyov(a)omp.ru> mmc: bcm2835: fix deferred probing Johan Hovold <johan+linaro(a)kernel.org> USB: dwc3: qcom: fix NULL-deref on suspend Frank Li <Frank.Li(a)nxp.com> usb: cdns3: fix NCM gadget RX speed 20x slow than expection at iMX8QM Frank Li <Frank.Li(a)nxp.com> usb: cdns3: allocate TX FIFO size according to composite EP number Wesley Cheng <wcheng(a)codeaurora.org> usb: gadget: udc: core: Introduce check_config to verify USB configuration Pawel Laszczak <pawell(a)cadence.com> usb: cdnsp: Device side header file for CDNSP driver Jiaxun Yang <jiaxun.yang(a)flygoat.com> irqchip/mips-gic: Use raw spinlock for gic_lock Marc Zyngier <maz(a)kernel.org> irqchip/mips-gic: Get rid of the reliance on irq_cpu_online() Jeffrey Hugo <quic_jhugo(a)quicinc.com> bus: mhi: host: Range check CHDBOFF and ERDBOFF Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> bus: mhi: Move host MHI code to "host" directory Bhaumik Bhatt <bbhatt(a)codeaurora.org> bus: mhi: Add MMIO region length to controller structure Loic Poulain <loic.poulain(a)linaro.org> bus: mhi: Add MHI PCI support for WWAN modems William Breathitt Gray <william.gray(a)linaro.org> iio: addac: stx104: Fix race condition when converting analog-to-digital William Breathitt Gray <william.gray(a)linaro.org> iio: addac: stx104: Fix race condition for stx104_write_raw() William Breathitt Gray <william.gray(a)linaro.org> iio: adc: stx104: Implement and utilize register structures William Breathitt Gray <william.gray(a)linaro.org> iio: adc: stx104: Utilize iomap interface Cosmin Tanislav <demonsingur(a)gmail.com> dt-bindings: iio: add AD74413R Cosmin Tanislav <demonsingur(a)gmail.com> iio: add addac subdirectory Randy Dunlap <rdunlap(a)infradead.org> IMA: allow/fix UML builds Chen Lin <chen.lin5(a)zte.com.cn> ring-buffer: Do not swap cpu_buffer during resize process Benjamin Gray <bgray(a)linux.ibm.com> powerpc/kasan: Disable KCOV in KASAN code Tuo Li <islituo(a)gmail.com> ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync() dengxiang <dengxiang(a)nfschina.com> ALSA: hda/realtek: Add quirks for Unis H3C Desktop B760 & Q760 shanzhulig <shanzhulig(a)gmail.com> drm/amdgpu: Fix potential fence use-after-free v2 Matthew Anderson <ruinairas1992(a)gmail.com> Bluetooth: btusb: Add MT7922 bluetooth ID for the Asus Ally Zhengping Jiang <jiangzp(a)google.com> Bluetooth: L2CAP: Fix use-after-free Armin Wolf <W_Armin(a)gmx.de> pcmcia: rsrc_nonstatic: Fix memory leak in nonstatic_release_resource_db() Tuo Li <islituo(a)gmail.com> gfs2: Fix possible data races in gfs2_show_options() Xu Yang <xu.yang_2(a)nxp.com> usb: chipidea: imx: add missing USB PHY DPDM wakeup setting Xu Yang <xu.yang_2(a)nxp.com> usb: chipidea: imx: don't request QoS for imx8ulp Hans Verkuil <hverkuil-cisco(a)xs4all.nl> media: platform: mediatek: vpu: fix NULL ptr dereference Prashanth K <quic_prashk(a)quicinc.com> usb: gadget: u_serial: Avoid spinlock recursion in __gs_console_push Yunfei Dong <yunfei.dong(a)mediatek.com> media: v4l2-mem2mem: add lock to protect parameter num_rdy Immad Mir <mirimmad17(a)gmail.com> FS: JFS: Check for read-only mounted filesystem in txBegin Immad Mir <mirimmad17(a)gmail.com> FS: JFS: Fix null-ptr-deref Read in txBegin Gustavo A. R. Silva <gustavoars(a)kernel.org> MIPS: dec: prom: Address -Warray-bounds warning Yogesh <yogi.kernel(a)gmail.com> fs: jfs: Fix UBSAN: array-index-out-of-bounds in dbAllocDmapLev Jan Kara <jack(a)suse.cz> udf: Fix uninitialized array access for some pathnames Christian Brauner <brauner(a)kernel.org> ovl: check type and offset of struct vfsmount in ovl_entry Patrisious Haddad <phaddad(a)nvidia.com> RDMA/mlx5: Return the firmware result upon destroying QP/RQ Marco Morandini <marco.morandini(a)polimi.it> HID: add quirk for 03f0:464a HP Elite Presenter Mouse Lang Yu <Lang.Yu(a)amd.com> drm/amdgpu: install stub fence into potential unused fence pointers gaoxu <gaoxu2(a)hihonor.com> dma-remap: use kvmalloc_array/kvfree for larger dma memory remap Ye Bin <yebin10(a)huawei.com> quota: fix warning in dqgrab() Jan Kara <jack(a)suse.cz> quota: Properly disable quotas when add_dquot_ref() fails Geert Uytterhoeven <geert+renesas(a)glider.be> iopoll: Call cpu_relax() in busy loops Uday M Bhat <uday.m.bhat(a)intel.com> ASoC: Intel: sof_sdw: Add support for Rex soundwire Oleksij Rempel <linux(a)rempel-privat.de> ARM: dts: imx6dl: prtrvt, prtvt7, prti6q, prtwd2: fix USB related warnings Sumit Gupta <sumitg(a)nvidia.com> PCI: tegra194: Fix possible array out of bounds access Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> ASoC: Intel: sof_sdw: add quirk for LNL RVP Bard Liao <yung-chuan.liao(a)linux.intel.com> ASoC: Intel: sof_sdw: add quirk for MTL RVP Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> ALSA: emu10k1: roll up loops in DSP setup code for Audigy hackyzh002 <hackyzh002(a)gmail.com> drm/radeon: Fix integer overflow in radeon_cs_parser_init Moshe Shemesh <moshe(a)nvidia.com> net/mlx5: Skip clock update work when device is in error state Eran Ben Elisha <eranbe(a)mellanox.com> net/mlx5: Move all internal timer metadata into a dedicated struct Eran Ben Elisha <eranbe(a)mellanox.com> net/mlx5: Refactor init clock function Eric Dumazet <edumazet(a)google.com> macsec: use DEV_STATS_INC() Clayton Yager <Clayton_Yager(a)selinc.com> macsec: Fix traffic counters/statistics Kunihiko Hayashi <hayashi.kunihiko(a)socionext.com> mmc: sdhci-f-sdh30: Replace with sdhci_pltfm ------------- Diffstat: Documentation/admin-guide/hw-vuln/srso.rst | 4 +- .../bindings/iio/addac/adi,ad74413r.yaml | 158 +++ Makefile | 4 +- arch/arm/boot/dts/imx6dl-prtrvt.dts | 4 + arch/arm/boot/dts/imx6qdl-prti6q.dtsi | 11 +- arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4.dtsi | 207 +-- arch/mips/include/asm/dec/prom.h | 2 +- arch/powerpc/kernel/rtas_flash.c | 6 +- arch/powerpc/mm/kasan/Makefile | 1 + arch/riscv/lib/uaccess.S | 212 ++- arch/x86/include/asm/entry-common.h | 1 + arch/x86/include/asm/nospec-branch.h | 28 +- arch/x86/kernel/cpu/amd.c | 1 + arch/x86/kernel/cpu/bugs.c | 28 +- arch/x86/kernel/static_call.c | 13 + arch/x86/kernel/traps.c | 2 - arch/x86/kernel/vmlinux.lds.S | 18 +- arch/x86/kvm/svm/svm.c | 1 + arch/x86/lib/retpoline.S | 141 +- drivers/bluetooth/btusb.c | 3 + drivers/bus/Makefile | 2 +- drivers/bus/mhi/Kconfig | 18 +- drivers/bus/mhi/Makefile | 4 +- drivers/bus/mhi/host/Kconfig | 31 + drivers/bus/mhi/{core => host}/Makefile | 4 +- drivers/bus/mhi/{core => host}/boot.c | 0 drivers/bus/mhi/{core => host}/debugfs.c | 0 drivers/bus/mhi/{core => host}/init.c | 12 + drivers/bus/mhi/{core => host}/internal.h | 0 drivers/bus/mhi/{core => host}/main.c | 0 drivers/bus/mhi/host/pci_generic.c | 345 +++++ drivers/bus/mhi/{core => host}/pm.c | 0 drivers/bus/ti-sysc.c | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +- drivers/gpu/drm/panel/panel-simple.c | 24 +- drivers/gpu/drm/radeon/radeon_cs.c | 3 +- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-quirks.c | 1 + drivers/i2c/busses/i2c-bcm-iproc.c | 11 +- drivers/i2c/busses/i2c-designware-master.c | 15 +- drivers/iio/Kconfig | 1 + drivers/iio/Makefile | 1 + drivers/iio/adc/stx104.c | 98 +- drivers/iio/addac/Kconfig | 8 + drivers/iio/addac/Makefile | 6 + drivers/infiniband/hw/mlx5/qpc.c | 10 +- drivers/irqchip/irq-mips-gic.c | 63 +- drivers/media/platform/mtk-vpu/mtk_vpu.c | 6 +- drivers/mmc/core/block.c | 7 +- drivers/mmc/core/host.c | 26 + drivers/mmc/host/bcm2835.c | 4 +- drivers/mmc/host/meson-gx-mmc.c | 52 +- drivers/mmc/host/sdhci_f_sdh30.c | 66 +- drivers/mmc/host/sunxi-mmc.c | 4 +- drivers/mmc/host/wbsd.c | 2 - drivers/net/dsa/mv88e6xxx/chip.c | 8 + drivers/net/ethernet/intel/i40e/i40e_nvm.c | 16 +- .../net/ethernet/mellanox/mlx5/core/lib/clock.c | 166 ++- .../net/ethernet/mellanox/mlx5/core/lib/clock.h | 3 +- drivers/net/macsec.c | 70 +- drivers/net/phy/broadcom.c | 13 + drivers/net/team/team.c | 4 +- drivers/net/virtio_net.c | 4 +- drivers/pci/controller/dwc/pcie-tegra194.c | 13 +- drivers/pcmcia/rsrc_nonstatic.c | 2 + drivers/tty/n_gsm.c | 3 +- drivers/tty/serial/8250/8250_port.c | 1 + drivers/tty/serial/fsl_lpuart.c | 4 +- drivers/usb/cdns3/cdnsp-gadget.h | 1463 ++++++++++++++++++++ drivers/usb/cdns3/gadget.c | 60 +- drivers/usb/cdns3/gadget.h | 9 +- drivers/usb/chipidea/ci_hdrc_imx.c | 5 + drivers/usb/chipidea/usbmisc_imx.c | 2 +- drivers/usb/dwc3/dwc3-qcom.c | 11 +- drivers/usb/gadget/function/u_serial.c | 3 + drivers/usb/gadget/udc/core.c | 19 + drivers/video/fbdev/mmp/hw/mmp_ctrl.c | 4 +- drivers/virtio/virtio_mmio.c | 8 +- fs/btrfs/volumes.c | 3 +- fs/cifs/file.c | 2 +- fs/gfs2/super.c | 26 +- fs/jfs/jfs_dmap.c | 3 + fs/jfs/jfs_txnmgr.c | 5 + fs/jfs/namei.c | 5 + fs/overlayfs/ovl_entry.h | 9 + fs/quota/dquot.c | 5 +- fs/udf/unicode.c | 2 +- include/dt-bindings/iio/addac/adi,ad74413r.h | 21 + include/linux/iopoll.h | 2 + include/linux/mhi.h | 2 + include/linux/mlx5/driver.h | 12 +- include/linux/mmc/host.h | 1 + include/linux/objtool.h | 28 + include/linux/usb/gadget.h | 4 + include/linux/virtio_net.h | 4 + include/media/v4l2-mem2mem.h | 18 +- include/net/sock.h | 6 + kernel/dma/remap.c | 4 +- kernel/trace/ring_buffer.c | 14 +- kernel/trace/trace.c | 3 +- kernel/trace/trace_kprobe.c | 3 +- kernel/trace/trace_probe_tmpl.h | 18 +- kernel/trace/trace_uprobe.c | 3 +- net/bluetooth/l2cap_core.c | 5 + net/core/sock.c | 2 +- net/ipv4/ip_vti.c | 4 +- net/ipv4/tcp_timer.c | 4 +- net/ipv6/ip6_vti.c | 4 +- net/key/af_key.c | 4 +- net/ncsi/ncsi-rsp.c | 5 +- net/netfilter/ipvs/ip_vs_ctl.c | 4 + net/netfilter/nf_conntrack_proto_sctp.c | 6 +- net/netfilter/nft_dynset.c | 3 + net/unix/af_unix.c | 9 +- net/xfrm/xfrm_compat.c | 2 +- net/xfrm/xfrm_interface_core.c | 4 +- net/xfrm/xfrm_user.c | 14 +- security/integrity/ima/Kconfig | 2 +- sound/hda/hdac_regmap.c | 7 +- sound/pci/emu10k1/emufx.c | 112 +- sound/pci/hda/patch_realtek.c | 16 +- sound/soc/codecs/rt5665.c | 2 + sound/soc/intel/boards/sof_sdw.c | 25 + sound/soc/meson/axg-tdm-formatter.c | 42 +- sound/usb/quirks-table.h | 29 + tools/include/linux/objtool.h | 28 + tools/objtool/arch/x86/decode.c | 2 +- tools/objtool/check.c | 21 +- .../selftests/net/forwarding/mirror_gre_changes.sh | 3 +- 130 files changed, 3442 insertions(+), 695 deletions(-)

7 months, 1 week

14
161
0 0

[PATCH v1 1/2] clk: composite: Fix handling of high clock rates

by Sebastian Reichel

ULONG_MAX is used by a few drivers to figure out the highest available clock rate via clk_round_rate(clk, ULONG_MAX). Since abs() takes a signed value as input, the current logic effectively calculates with ULONG_MAX = -1, which results in the worst parent clock being chosen instead of the best one. For example on Rockchip RK3588 the eMMC driver tries to figure out the highest available clock rate. There are three parent clocks available resulting in the following rate diffs with the existing logic: GPLL: abs(18446744073709551615 - 1188000000) = 1188000001 CPLL: abs(18446744073709551615 - 1500000000) = 1500000001 XIN24M: abs(18446744073709551615 - 24000000) = 24000001 As a result the clock framework will promote a maximum supported clock rate of 24 MHz, even though 1.5GHz are possible. With the updated logic any casting between signed and unsigned is avoided and the numbers look like this instead: GPLL: 18446744073709551615 - 1188000000 = 18446744072521551615 CPLL: 18446744073709551615 - 1500000000 = 18446744072209551615 XIN24M: 18446744073709551615 - 24000000 = 18446744073685551615 As a result the parent with the highest acceptable rate is chosen instead of the parent clock with the lowest one. Cc: stable(a)vger.kernel.org Fixes: 49502408007b ("mmc: sdhci-of-dwcmshc: properly determine max clock on Rockchip") Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.com> --- drivers/clk/clk-composite.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/clk/clk-composite.c b/drivers/clk/clk-composite.c index edfa94641bbf..66759fe28fad 100644 --- a/drivers/clk/clk-composite.c +++ b/drivers/clk/clk-composite.c @@ -119,7 +119,10 @@ static int clk_composite_determine_rate(struct clk_hw *hw, if (ret) continue; - rate_diff = abs(req->rate - tmp_req.rate); + if (req->rate >= tmp_req.rate) + rate_diff = req->rate - tmp_req.rate; + else + rate_diff = tmp_req.rate - req->rate; if (!rate_diff || !req->best_parent_hw || best_rate_diff > rate_diff) { -- 2.39.2

7 months, 1 week

3
2
0 0

[PATCH v2] pci: loongson: Workaround MIPS firmware MRRS settings

by Jiaxun Yang

This is a partial revert of commit 8b3517f88ff2 ("PCI: loongson: Prevent LS7A MRRS increases") for MIPS based Loongson. There are many MIPS based Loongson systems in wild that shipped with firmware which does not set maximum MRRS properly. Limiting MRRS to 256 for all as MIPS Loongson comes with higher MRRS support is considered rare. Cc: stable(a)vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217680 Fixes: 8b3517f88ff2 ("PCI: loongson: Prevent LS7A MRRS increases") Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> --- v2: Rename quirk name to: loongson_old_mrrs_quirk --- drivers/pci/controller/pci-loongson.c | 38 +++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/drivers/pci/controller/pci-loongson.c b/drivers/pci/controller/pci-loongson.c index fe0f732f6e43..d0f68b102d10 100644 --- a/drivers/pci/controller/pci-loongson.c +++ b/drivers/pci/controller/pci-loongson.c @@ -108,6 +108,44 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON, DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_LOONGSON, DEV_LS7A_PCIE_PORT6, loongson_mrrs_quirk); +#ifdef CONFIG_MIPS +static void loongson_old_mrrs_quirk(struct pci_dev *pdev) +{ + struct pci_bus *bus = pdev->bus; + struct pci_dev *bridge; + static const struct pci_device_id bridge_devids[] = { + { PCI_VDEVICE(LOONGSON, DEV_LS2K_PCIE_PORT0) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT0) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT1) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT2) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT3) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT4) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT5) }, + { PCI_VDEVICE(LOONGSON, DEV_LS7A_PCIE_PORT6) }, + { 0, }, + }; + + /* look for the matching bridge */ + while (!pci_is_root_bus(bus)) { + bridge = bus->self; + bus = bus->parent; + /* + * There are still some wild MIPS Loongson firmware won't + * set MRRS properly. Limiting MRRS to 256 as MIPS Loongson + * comes with higher MRRS support is considered rare. + */ + if (pci_match_id(bridge_devids, bridge)) { + if (pcie_get_readrq(pdev) > 256) { + pci_info(pdev, "limiting MRRS to 256\n"); + pcie_set_readrq(pdev, 256); + } + break; + } + } +} +DECLARE_PCI_FIXUP_ENABLE(PCI_ANY_ID, PCI_ANY_ID, loongson_old_mrrs_quirk); +#endif + static void loongson_pci_pin_quirk(struct pci_dev *pdev) { pdev->pin = 1 + (PCI_FUNC(pdev->devfn) & 3); -- 2.39.2

7 months, 2 weeks

5
17
0 0

[PATCH 5.4 00/68] 5.4.237-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.4.237 release. There are 68 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 Fri, 17 Mar 2023 11:57:10 +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.4.237-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 5.4.237-rc1 Stefan Haberland <sth(a)linux.ibm.com> s390/dasd: add missing discipline function Masahiro Yamada <masahiroy(a)kernel.org> UML: define RUNTIME_DISCARD_EXIT Tom Saeger <tom.saeger(a)oracle.com> sh: define RUNTIME_DISCARD_EXIT Masahiro Yamada <masahiroy(a)kernel.org> s390: define RUNTIME_DISCARD_EXIT to fix link error with GNU ld < 2.36 Michael Ellerman <mpe(a)ellerman.id.au> powerpc/vmlinux.lds: Don't discard .rela* for relocatable builds Michael Ellerman <mpe(a)ellerman.id.au> powerpc/vmlinux.lds: Define RUNTIME_DISCARD_EXIT Masahiro Yamada <masahiroy(a)kernel.org> arch: fix broken BuildID for arm64 and riscv H.J. Lu <hjl.tools(a)gmail.com> x86, vmlinux.lds: Add RUNTIME_DISCARD_EXIT to generic DISCARDS John Harrison <John.C.Harrison(a)Intel.com> drm/i915: Don't use BAR mappings for ring buffers with LLC Corey Minyard <cminyard(a)mvista.com> ipmi:watchdog: Set panic count to proper value on a panic Yejune Deng <yejune.deng(a)gmail.com> ipmi/watchdog: replace atomic_add() and atomic_sub() Paul Elder <paul.elder(a)ideasonboard.com> media: ov5640: Fix analogue gain control Alvaro Karsz <alvaro.karsz(a)solid-run.com> PCI: Avoid FLR for SolidRun SNET DPU rev 1 Alvaro Karsz <alvaro.karsz(a)solid-run.com> PCI: Add SolidRun vendor ID Nathan Chancellor <nathan(a)kernel.org> macintosh: windfarm: Use unsigned type for 1-bit bitfields Edward Humes <aurxenon(a)lunos.org> alpha: fix R_ALPHA_LITERAL reloc for large modules Christophe Leroy <christophe.leroy(a)csgroup.eu> powerpc: Check !irq instead of irq == NO_IRQ and remove NO_IRQ xurui <xurui(a)kylinos.cn> MIPS: Fix a compilation issue Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> clk: qcom: mmcc-apq8084: remove spdm clocks Jan Kara <jack(a)suse.cz> ext4: Fix deadlock during directory rename Alexandre Ghiti <alexghiti(a)rivosinc.com> riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack mode D. Wythe <alibuda(a)linux.alibaba.com> net/smc: fix fallback failed while sendmsg with fastopen Chandrakanth Patil <chandrakanth.patil(a)broadcom.com> scsi: megaraid_sas: Update max supported LD IDs to 240 Lorenz Bauer <lorenz.bauer(a)isovalent.com> btf: fix resolving BTF_KIND_VAR after ARRAY, STRUCT, UNION, PTR Florian Westphal <fw(a)strlen.de> netfilter: tproxy: fix deadlock due to missing BH disable Michael Chan <michael.chan(a)broadcom.com> bnxt_en: Avoid order-5 memory allocation for TPA data Shigeru Yoshida <syoshida(a)redhat.com> net: caif: Fix use-after-free in cfusbl_device_notify() Yuiko Oshino <yuiko.oshino(a)microchip.com> net: lan78xx: fix accessing the LAN7800's internal phy specific registers from the MAC driver Lee Jones <lee.jones(a)linaro.org> net: usb: lan78xx: Remove lots of set but unused 'ret' variables Hangbin Liu <liuhangbin(a)gmail.com> selftests: nft_nat: ensuring the listening side is up before starting the client Eric Dumazet <edumazet(a)google.com> ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping() Kang Chen <void0red(a)gmail.com> nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> drm/msm/a5xx: fix setting of the CP_PREEMPT_ENABLE_LOCAL register Jan Kara <jack(a)suse.cz> ext4: Fix possible corruption when moving a directory Bart Van Assche <bvanassche(a)acm.org> scsi: core: Remove the /proc/scsi/${proc_name} directory earlier Volker Lendecke <vl(a)samba.org> cifs: Fix uninitialized memory read in smb3_qfs_tcon() Amir Goldstein <amir73il(a)gmail.com> SMB3: Backup intent flag missing from some more ops Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> ARM: dts: exynos: correct TMU phandle in Odroid XU3 family Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> ARM: dts: exynos: correct TMU phandle in Odroid HC1 Marek Szyprowski <m.szyprowski(a)samsung.com> ARM: dts: exynos: Add GPU thermal zone cooling maps for Odroid XU3/XU4/HC1 Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> ARM: dts: exynos: correct TMU phandle in Exynos5250 Krzysztof Kozlowski <krzk(a)kernel.org> ARM: dts: exynos: Override thermal by label in Exynos5250 Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> ARM: dts: exynos: correct TMU phandle in Exynos4210 Krzysztof Kozlowski <krzk(a)kernel.org> ARM: dts: exynos: Override thermal by label in Exynos4210 Jacob Pan <jacob.jun.pan(a)linux.intel.com> iommu/vt-d: Fix PASID directory pointer coherency Marc Zyngier <maz(a)kernel.org> irqdomain: Fix domain registration race Bixuan Cui <cuibixuan(a)huawei.com> irqdomain: Change the type of 'size' in __irq_domain_add() to be consistent Corey Minyard <cminyard(a)mvista.com> ipmi:ssif: Add a timer between request retries Corey Minyard <cminyard(a)mvista.com> ipmi:ssif: Increase the message retry time Corey Minyard <cminyard(a)mvista.com> ipmi:ssif: Remove rtc_us_timer Corey Minyard <cminyard(a)mvista.com> ipmi:ssif: resend_msg() cannot fail Liguang Zhang <zhangliguang(a)linux.alibaba.com> ipmi:ssif: make ssif_i2c_send() void Gavrilov Ilia <Ilia.Gavrilov(a)infotecs.ru> iommu/amd: Add a length limitation for the ivrs_acpihid command-line parameter Kim Phillips <kim.phillips(a)amd.com> iommu/amd: Fix ill-formed ivrs_ioapic, ivrs_hpet and ivrs_acpihid options Suravee Suthikulpanit <suravee.suthikulpanit(a)amd.com> iommu/amd: Add PCI segment support for ivrs_[ioapic/hpet/acpihid] commands Jani Nikula <jani.nikula(a)intel.com> drm/edid: fix AVI infoframe aspect ratio handling Wayne Lin <Wayne.Lin(a)amd.com> drm/edid: Add aspect ratios to HDMI 4K modes Ville Syrjälä <ville.syrjala(a)linux.intel.com> drm/edid: Fix HDMI VIC handling Ville Syrjälä <ville.syrjala(a)linux.intel.com> drm/edid: Extract drm_mode_cea_vic() Fedor Pchelkin <pchelkin(a)ispras.ru> nfc: change order inside nfc_se_io error path Zhihao Cheng <chengzhihao1(a)huawei.com> ext4: zero i_disksize when initializing the bootloader inode Ye Bin <yebin10(a)huawei.com> ext4: fix WARNING in ext4_update_inline_data Ye Bin <yebin10(a)huawei.com> ext4: move where set the MAY_INLINE_DATA flag is set Darrick J. Wong <djwong(a)kernel.org> ext4: fix another off-by-one fsmap error on 1k block filesystems Eric Whitney <enwlinux(a)gmail.com> ext4: fix RENAME_WHITEOUT handling for inline directories Harry Wentland <harry.wentland(a)amd.com> drm/connector: print max_requested_bpc in state debugfs Andrew Cooper <andrew.cooper3(a)citrix.com> x86/CPU/AMD: Disable XSAVES on AMD family 0x17 Theodore Ts'o <tytso(a)mit.edu> fs: prevent out-of-bounds array speculation when closing a file descriptor ------------- Diffstat: Documentation/admin-guide/kernel-parameters.txt | 51 +++- Makefile | 4 +- arch/alpha/kernel/module.c | 4 +- arch/arm/boot/dts/exynos4210.dtsi | 35 ++- arch/arm/boot/dts/exynos5250.dtsi | 38 ++- arch/arm/boot/dts/exynos5422-odroidhc1.dts | 38 ++- arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 67 ++++- arch/mips/include/asm/mach-rc32434/pci.h | 2 +- arch/powerpc/include/asm/irq.h | 3 - arch/powerpc/kernel/vmlinux.lds.S | 6 +- arch/powerpc/platforms/44x/fsp2.c | 2 +- arch/riscv/kernel/stacktrace.c | 2 +- arch/s390/kernel/vmlinux.lds.S | 2 + arch/sh/kernel/vmlinux.lds.S | 1 + arch/um/kernel/vmlinux.lds.S | 2 +- arch/x86/kernel/cpu/amd.c | 9 + arch/x86/kernel/vmlinux.lds.S | 2 + drivers/char/ipmi/ipmi_ssif.c | 146 ++++------- drivers/char/ipmi/ipmi_watchdog.c | 8 +- drivers/clk/qcom/mmcc-apq8084.c | 271 --------------------- drivers/gpu/drm/drm_atomic.c | 1 + drivers/gpu/drm/drm_edid.c | 130 ++++++---- drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 +- drivers/iommu/amd_iommu_init.c | 105 ++++++-- drivers/iommu/intel-pasid.c | 7 + drivers/macintosh/windfarm_lm75_sensor.c | 4 +- drivers/macintosh/windfarm_smu_sensors.c | 4 +- drivers/media/i2c/ov5640.c | 2 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 23 +- drivers/net/phy/microchip.c | 32 +++ drivers/net/usb/lan78xx.c | 189 ++++++-------- drivers/nfc/fdp/i2c.c | 4 + drivers/pci/quirks.c | 8 + drivers/s390/block/dasd_diag.c | 7 +- drivers/s390/block/dasd_fba.c | 7 +- drivers/s390/block/dasd_int.h | 1 - drivers/scsi/hosts.c | 2 + drivers/scsi/megaraid/megaraid_sas.h | 2 + drivers/scsi/megaraid/megaraid_sas_fp.c | 2 +- fs/cifs/cifsacl.c | 14 +- fs/cifs/cifsfs.c | 2 +- fs/cifs/cifsglob.h | 6 +- fs/cifs/cifsproto.h | 8 + fs/cifs/connect.c | 2 +- fs/cifs/dir.c | 5 +- fs/cifs/file.c | 10 +- fs/cifs/inode.c | 8 +- fs/cifs/ioctl.c | 2 +- fs/cifs/link.c | 18 +- fs/cifs/smb1ops.c | 19 +- fs/cifs/smb2inode.c | 9 +- fs/cifs/smb2ops.c | 92 +++---- fs/cifs/smb2proto.h | 2 +- fs/ext4/fsmap.c | 2 + fs/ext4/inline.c | 1 - fs/ext4/inode.c | 7 +- fs/ext4/ioctl.c | 1 + fs/ext4/namei.c | 36 ++- fs/ext4/xattr.c | 3 + fs/file.c | 1 + include/asm-generic/vmlinux.lds.h | 16 +- include/linux/irqdomain.h | 2 +- include/linux/pci_ids.h | 2 + include/net/netfilter/nf_tproxy.h | 7 + kernel/bpf/btf.c | 1 + kernel/irq/irqdomain.c | 62 +++-- net/caif/caif_usb.c | 3 + net/ipv4/netfilter/nf_tproxy_ipv4.c | 2 +- net/ipv6/ila/ila_xlat.c | 1 + net/ipv6/netfilter/nf_tproxy_ipv6.c | 2 +- net/nfc/netlink.c | 2 +- net/smc/af_smc.c | 13 +- tools/testing/selftests/netfilter/nft_nat.sh | 2 + 74 files changed, 783 insertions(+), 811 deletions(-)

7 months, 2 weeks

7
78
0 0

Re: [PATCH net 5/6] net: hns3: fix wrong print link down up

by Andrew Lunn

> Now i wounder if you are fixing the wrong thing. Maybe you should be > fixing the PHY so it does not report up and then down? You say 'very > snall intervals', which should in fact be 1 second. So is the PHY > reporting link for a number of poll intervals? 1min to 10 minutes? > > Andrew > > Yes, according to the log records, the phy polls every second, > but the link status changes take time. > Generally, it takes 10 seconds for the phy to detect link down, > but occasionally it takes several minutes to detect link down, What PHY driver is this? It is not so clear what should actually happen with auto-neg turned off. With it on, and the link going down, the PHY should react after about 1 second. It is not supposed to react faster than that, although some PHYs allow fast link down notification to be configured. Have you checked 802.3 to see what it says about auto-neg off and link down detection? I personally would not suppress this behaviour in the MAC driver. Otherwise you are going to have funny combinations of special cases of a feature which very few people actually use, making your maintenance costs higher. Andrew

7 months, 2 weeks

2
5
0 0

[PATCH v2] docs: add backporting and conflict resolution document

by Vegard Nossum

This is a new document based on my 2022 blog post: https://blogs.oracle.com/linux/post/backporting-patches-using-git Although this is aimed at stable contributors and distro maintainers, it does also contain useful tips and tricks for anybody who needs to resolve merge conflicts. By adding this to the kernel as documentation we can more easily point to it e.g. from stable emails about failed backports, as well as allow the community to modify it over time if necessary. I've added this under process/ since it also has process/applying-patches.rst. Another interesting document is maintainer/rebasing-and-merging.rst which maybe should eventually refer to this one, but I'm leaving that as a future cleanup. Thanks to Harshit Mogalapalli for helping with the original blog post as well as this updated document and Bagas Sanjaya for providing thoughtful feedback. v2: fixed heading style, link style, placeholder style, other comments Link: https://lore.kernel.org/linux-doc/20230303162553.17212-1-vegard.nossum@orac… Cc: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> Cc: Bagas Sanjaya <bagasdotme(a)gmail.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Stephen Rothwell <sfr(a)canb.auug.org.au> Cc: Jason A. Donenfeld <Jason(a)zx2c4.com> Cc: Konstantin Ryabitsev <konstantin(a)linuxfoundation.org> Signed-off-by: Vegard Nossum <vegard.nossum(a)oracle.com> --- Documentation/process/backporting.rst | 514 ++++++++++++++++++++++++++ Documentation/process/index.rst | 1 + 2 files changed, 515 insertions(+) create mode 100644 Documentation/process/backporting.rst diff --git a/Documentation/process/backporting.rst b/Documentation/process/backporting.rst new file mode 100644 index 0000000000000..7593980af9659 --- /dev/null +++ b/Documentation/process/backporting.rst @@ -0,0 +1,514 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================== +Backporting and conflict resolution +=================================== + +:Author: Vegard Nossum <vegard.nossum(a)oracle.com> + +.. contents:: + :local: + :depth: 3 + :backlinks: none + +Introduction +============ + +Some developers may never really have to deal with backporting patches, +merging branches, or resolving conflicts in their day-to-day work, so +when a merge conflict does pop up, it can be daunting. Luckily, +resolving conflicts is a skill like any other, and there are many useful +techniques you can use to make the process smoother and increase your +confidence in the result. + +This document aims to be a comprehensive, step-by-step guide to +backporting and conflict resolution. + +Applying the patch to a tree +============================ + +Sometimes the patch you are backporting already exists as a git commit, +in which case you just cherry-pick it directly using +``git cherry-pick``. However, if the patch comes from an email, as it +often does for the Linux kernel, you will need to apply it to a tree +using ``git am``. + +If you've ever used ``git am``, you probably already know that it is +quite picky about the patch applying perfectly to your source tree. In +fact, you've probably had nightmares about ``.rej`` files and trying to +edit the patch to make it apply. + +It is strongly recommended to instead find an appropriate base version +where the patch applies cleanly and *then* cherry-pick it over to your +destination tree, as this will make git output conflict markers and let +you resolve conflicts with the help of git and any other conflict +resolution tools you might prefer to use. For example, if you want to +apply a patch that just arrived on LKML to an older stable kernel, you +can apply it to the most recent mainline kernel and then cherry-pick it +to your older stable branch. + +It's generally better to use the exact same base as the one the patch +was generated from, but it doesn't really matter that much as long as it +applies cleanly and isn't too far from the original base. The only +problem with applying the patch to the "wrong" base is that it may pull +in more unrelated changes in the context of the diff when cherry-picking +it to the older branch. + +If you are using `b4`_. and you are applying the patch directly from an +email, you can use ``b4 am`` with the options ``-g``/``--guess-base`` +and ``-3``/``--prep-3way`` to do some of this automatically (see the +`b4 presentation`_ for more information). However, the rest of this +article will assume that you are doing a plain ``git cherry-pick``. + +.. _b4: https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation +.. _b4 presentation: https://youtu.be/mF10hgVIx9o?t=2996 + +Once you have the patch in git, you can go ahead and cherry-pick it into +your source tree. Don't forget to cherry-pick with ``-x`` if you want a +written record of where the patch came from! + +Note that if you are submiting a patch for stable, the format is +slightly different; the first line after the subject line needs tobe +either:: + + commit <upstream commit> upstream + +or:: + + [ Upstream commit <upstream commit> ] + +Resolving conflicts +=================== + +Uh-oh; the cherry-pick failed with a vaguely threatening message:: + + CONFLICT (content): Merge conflict + +What to do now? + +In general, conflicts appear when the context of the patch (i.e., the +lines being changed and/or the lines surrounding the changes) doesn't +match what's in the tree you are trying to apply the patch *to*. + +For backports, what likely happened was that the branch you are +backporting from contains patches not in the branch you are backporting +to. However, the reverse is also possible. In any case, the result is a +conflict that needs to be resolved. + +If your attempted cherry-pick fails with a conflict, git automatically +edits the files to include so-called conflict markers showing you where +the conflict is and how the two branches have diverged. Resolving the +conflict typically means editing the end result in such a way that it +takes into account these other commits. + +Resolving the conflict can be done either by hand in a regular text +editor or using a dedicated conflict resolution tool. + +Many people prefer to use their regular text editor and edit the +conflict directly, as it may be easier to understand what you're doing +and to control the final result. There are definitely pros and cons to +each method, and sometimes there's value in using both. + +We will not cover using dedicated merge tools here beyond providing some +pointers to various tools that you could use: + +- `vimdiff/gvimdiff <https://linux.die.net/man/1/vimdiff>`__ +- `KDiff3 <http://kdiff3.sourceforge.net/>`__ +- `TortoiseMerge <https://tortoisesvn.net/TortoiseMerge.html>`__ +- `Meld <https://meldmerge.org/help/>`__ +- `P4Merge <https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge>`__ +- `Beyond Compare <https://www.scootersoftware.com/>`__ +- `IntelliJ <https://www.jetbrains.com/help/idea/resolve-conflicts.html>`__ +- `VSCode <https://code.visualstudio.com/docs/editor/versioncontrol>`__ + +To configure git to work with these, see ``git mergetool --help`` or +the official `git-mergetool documentation`_. + +.. _git-mergetool documentation: https://git-scm.com/docs/git-mergetool + +Prerequisite patches +-------------------- + +Most conflicts happen because the branch you are backporting to is +missing some patches compared to the branch you are backporting *from*. +In the more general case (such as merging two independent branches), +development could have happened on either branch, or the branches have +simply diverged -- perhaps your older branch had some other backports +applied to it that themselves needed conflict resolutions, causing a +divergence. + +It's important to always identify the commit or commits that caused the +conflict, as otherwise you cannot be confident in the correctness of +your resolution. As an added bonus, especially if the patch is in an +area you're not that famliar with, the changelogs of these commits will +often give you the context to understand the code and potential problems +or pitfalls with your conflict resolution. + +git log +~~~~~~~ + +A good first step is to look at ``git log`` for the file that has the +conflict -- this is usually sufficient when there aren't a lot of +patches to the file, but may get confusing if the file is big and +frequently patched. You should run ``git log`` on the range of commits +between your currently checked-out branch (``HEAD``) and the parent of +the patch you are picking (``<commit>``), i.e.:: + + git log HEAD..<commit>^ -- <path> + +Even better, if you want to restrict this output to a single function +(because that's where the conflict appears), you can use the following +syntax:: + + git log -L:'\<function\>':<path> HEAD..<commit>^ + +.. note:: + The ``\<`` and ``\>`` around the function name ensure that the + matches are anchored on a word boundary. This is important, as this + part is actually a regex and git only follows the first match, so + if you use ``-L:thread_stack:kernel/fork.c`` it may only give you + results for the function ``try_release_thread_stack_to_cache`` even + though there are many other functions in that file containing the + string ``thread_stack`` in their names. + +Another useful option for ``git log`` is ``-G``, which allows you to +filter on certain strings appearing in the diffs of the commits you are +listing:: + + git log -G'regex' HEAD..<commit>^ -- <path> + +This can also be a handy way to quickly find when something (e.g. a +function call or a variable) was changed, added, or removed. The search +string is a regular expression, which means you can potentially search +for more specific things like assignments to a specific struct member:: + + git log -G'\->index\>.*=' + +git blame +~~~~~~~~~ + +Another way to find prerequisite commits (albeit only the most recent +one for a given conflict) is to run ``git blame``. In this case, you +need to run it against the parent commit of the patch you are +cherry-picking and the file where the conflict appared, i.e.:: + + git blame <commit>^ -- <path> + +This command also accepts the ``-L`` argument (for restricting the +output to a single function), but in this case you specify the filename +at the end of the command as usual:: + + git blame -L:'\<function\>' <commit>^ -- <path> + +Navigate to the place where the conflict occurred. The first column of +the blame output is the commit ID of the patch that added a given line +of code. + +It might be a good idea to ``git show`` these commits and see if they +look like they might be the source of the conflict. Sometimes there will +be more than one of these commits, either because multiple commits +changed different lines of the same conflict area *or* because multiple +subsequent patches changed the same line (or lines) multiple times. In +the latter case, you may have to run ``git blame`` again and specify the +older version of the file to look at in order to dig further back in +the history of the file. + +Prerequisite vs. incidental patches +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Having found the patch that caused the conflict, you need to determine +whether it is a prerequisite for the patch you are backporting or +whether it is just incidental and can be skipped. An incidental patch +would be one that touches the same code as the patch you are +backporting, but does not change the semantics of the code in any +material way. For example, a whitespace cleanup patch is completely +incidental -- likewise, a patch that simply renames a function or a +variable would be incidental as well. On the other hand, if the function +being changed does not even exist in your current branch then this would +not be incidental at all and you need to carefully consider whether the +patch adding the function should be cherry-picked first. + +If you find that there is a necessary prerequisite patch, then you need +to stop and cherry-pick that instead. If you've already resolved some +conflicts in a different file and don't want to do it again, you can +create a temporary copy of that file. + +To abort the current cherry-pick, go ahead and run +``git cherry-pick --abort``, then restart the cherry-picking process +with the commit ID of the prerequisite patch instead. + +Understanding conflict markers +------------------------------ + +Combined diffs +~~~~~~~~~~~~~~ + +Let's say you've decided against picking (or reverting) additional +patches and you just want to resolve the conflict. Git will have +inserted conflict markers into your file. Out of the box, this will look +something like:: + + <<<<<<< HEAD + this is what's in your current tree before cherry-picking + ======= + this is what the patch wants it to be after cherry-picking + >>>>>>> <commit>... title + +This is what you would see if you opened the file in your editor. +However, if you were to run run ``git diff`` without any arguments, the +output would look something like this:: + + $ git diff + [...] + ++<<<<<<<< HEAD + +this is what's in your current tree before cherry-picking + ++======== + + this is what the patch wants it to be after cherry-picking + ++>>>>>>>> <commit>... title + +When you are resolving a conflict, the behavior of ``git diff`` differs +from its normal behavior. Notice the two columns of diff markers +instead of the usual one; this is a so-called "`combined diff`_", here +showing the 3-way diff (or diff-of-diffs) between + +#. the current branch (before cherry-picking) and the current working + directory, and +#. the current branch (before cherry-picking) and the file as it looks + after the original patch has been applied. + +.. _combined diff: https://git-scm.com/docs/diff-format#_combined_diff_format + + +Better diffs +~~~~~~~~~~~~ + +3-way combined diffs include all the other changes that happened to the +file between your current branch and the branch you are cherry-picking +from. While this is useful for spotting other changes that you need to +take into account, this also makes the output of ``git diff`` somewhat +intimidating and difficult to read. You may instead prefer to run +``git diff HEAD`` (or ``git diff --ours``) which shows only the diff +between the current branch before cherry-picking and the current working +directory. It looks like this:: + + $ git diff HEAD + [...] + +<<<<<<<< HEAD + this is what's in your current tree before cherry-picking + +======== + +this is what the patch wants it to be after cherry-picking + +>>>>>>>> <commit>... title + +As you can see, this reads just like any other diff and makes it clear +which lines are in the current branch and which lines are being added +because they are part of the merge conflict or the patch being +cherry-picked. + +Merge styles and diff3 +~~~~~~~~~~~~~~~~~~~~~~ + +The default conflict marker style shown above is known as the ``merge`` +style. There is also another style available, known as the ``diff3`` +style, which looks like this:: + + <<<<<<< HEAD + this is what is in your current tree before cherry-picking + ||||||| parent of <commit> (title) + this is what the patch expected to find there + ======= + this is what the patch wants it to be after being applied + >>>>>>> <commit> (title) + +As you can see, this has 3 parts instead of 2, and includes what git +expected to find there but didn't. Some people vastly prefer this style +as it makes it much clearer what the patch actually changed; i.e., it +allows you to compare the before-and-after versions of the file for the +commit you are cherry-picking. This allows you to make better decisions +about how to resolve the conflict. + +To change conflict marker styles, you can use the following command:: + + git config merge.conflictStyle diff3 + +There is a third option, ``zdiff3``, introduced in `Git 2.35`_, +which has the same 3 sections as ``diff3``, but where common lines have +been trimmed off, making the conflict area smaller in some cases. + +.. _Git 2.35: https://github.blog/2022-01-24-highlights-from-git-2-35/ + +Iterating on conflict resolutions +--------------------------------- + +The first step in any conflict resolution process is to understand the +patch you are backporting. For the Linux kernel this is especially +important, since an incorrect change can lead to the whole system +crashing -- or worse, an undetected security vulnerability. + +Understanding the patch can be easy or difficult depending on the patch +itself, the changelog, and your familiarity with the code being changed. +However, a good question for every change (or every hunk of the patch) +might be: "Why is this hunk in the patch?" The answers to these +questions will inform your conflict resolution. + +Resolution process +~~~~~~~~~~~~~~~~~~ + +Sometimes the easiest thing to do is to just remove all but the first +part of the conflict, leaving the file essentially unchanged, and apply +the changes by hand. Perhaps the patch is changing a function call +argument from ``0`` to ``1`` while a conflicting change added an +entirely new (and insignificant) parameter to the end of the parameter +list; in that case, it's easy enough to change the argument from ``0`` +to ``1`` by hand and leave the rest of the arguments alone. This +technique of manually applying changes is mostly useful if the conflict +pulled in a lot of unrelated context that you don't really need to care +about. + +For particularly nasty conflicts with many conflict markers, you can use +``git add`` or ``git add -i`` to selectively stage your resolutions to +get them out of the way; this also lets you use ``git diff HEAD`` to +always see what remains to be resolved or ``git diff --cached`` to see +what your patch looks like so far. + +Function arguments +~~~~~~~~~~~~~~~~~~ + +Pay attention to changing function arguments! It's easy to gloss over +details and think that two lines are the same but actually they differ +in some small detail like which variable was passed as an argument +(especially if the two variables are both a single character that look +the same, like i and j). + +Error handling +~~~~~~~~~~~~~~ + +If you cherry-pick a patch that includes a ``goto`` statement (typically +for error handling), it is absolutely imperative to double check that +the target label is still correct in the branch you are backporting to. +Error handling is typically located at the bottom of the function, so it +may not be part of the conflict even though could have been changed by +other patches. + +A good way to ensure that you review the error paths is to always use +``git diff -W`` and ``git show -W`` (AKA ``--function-context``) when +inspecting your changes. For C code, this will show you the whole +function that's being changed in a patch. One of the things that often +go wrong during backports is that something else in the function changed +on either of the branches that you're backporting from or to. By +including the whole function in the diff you get more context and can +more easily spot problems that might otherwise go unnoticed. + +Dealing with file renames +~~~~~~~~~~~~~~~~~~~~~~~~~ + +One of the most annoying things that can happen while backporting a +patch is discovering that one of the files being patched has been +renamed, as that typically means git won't even put in conflict markers, +but will just throw up its hands and say (paraphrased): "Unmerged path! +You do the work..." + +There are generally a few ways to deal with this. If the patch to the +renamed file is small, like a one-line change, the easiest thing is to +just go ahead and apply the change by hand and be done with it. On the +other hand, if the change is big or complicated, you definitely don't +want to do it by hand. + +Sometimes the right thing to do will be to also backport the patch that +did the rename, but that's definitely not the most common case. Instead, +what you can do is to temporarily rename the file in the branch you're +backporting to (using ``git mv`` and committing the result), restart the +attempt to cherry-pick the patch, rename the file back (``git mv`` and +committing again), and finally squash the result using ``git rebase -i`` +(see the `rebase tutorial`_) so it appears as a single commit when you +are done. + +.. _rebase tutorial: https://medium.com/@slamflipstrom/a-beginners-guide-to-squashing-commits-wi… + +Verifying the result +==================== + +colordiff +--------- + +Having committed a conflict-free new patch, you can now compare your +patch to the original patch. It is highly recommended that you use a +tool such as `colordiff`_ that can show two files side by side and color +them according to the changes between them:: + + colordiff -yw -W 200 <(git diff -W <upstream commit>^-) <(git diff -W HEAD^-) | less -SR + +.. _colordiff: https://www.colordiff.org/ + +Here, ``-y`` means to do a side-by-side comparison; ``-w`` ignores +whitespace, and ``-W 200`` sets the width of the output (as otherwise it +will use 130 by default, which is often a bit too little). + +The ``rev^-`` syntax is a handy shorthand for ``rev^..rev``, essentially +giving you just the diff for that single commit; also see +the official `git rev-parse documentation`_. + +.. _git rev-parse documentation: https://git-scm.com/docs/git-rev-parse#_other_rev_parent_shorthand_notations + +Again, note the inclusion of ``-W`` for ``git diff``; this ensures that +you will see the full function for any function that has changed. + +One incredibly important thing that colordiff does is to highlight lines +that are different. For example, if an error-handling ``goto`` has +changed labels between the original and backported patch, colordiff will +show these side-by-side but highlighted in a different color. Thus, it +is easy to see that the two ``goto`` statements are jumping to different +labels. Likewise, lines that were not modified by either patch but +differ in the context will also be highlighted and thus stand out during +a manual inspection. + +Of course, this is just a visual inspection; the real test is building +and running the patched kernel (or program). + +Build testing +------------- + +We won't cover runtime testing here, but it can be a good idea to build +just the files touched by the patch as a quick sanity check. For the +Linux kernel you can build single files like this, assuming you have the +``.config`` and build environment set up correctly:: + + make path/to/file.o + +Note that this won't discover linker errors, so you should still do a +full build after verifying that the single file compiles. By compiling +the single file first you can avoid having to wait for a full build *in +case* there are compiler errors in any of the files you've changed. + +Runtime testing +--------------- + +Even a successful build or boot test is not necessarily enough to rule +out a missing dependency somewhere. Even though the chances are small, +there could be code changes where two independent changes to the same +file result in no conflicts, no compile-time errors, and runtime errors +only in exceptional cases. + +One concrete example of this was a pair of patches to the system call +entry code where the first patch saved/restored a register and a later +patch made use of the same register somewhere in the middle of this +sequence. Since there was no overlap between the changes, one could +cherry-pick the second patch, have no conflicts, and believe that +everything was fine, when in fact the code was now scribbling over an +unsaved register. + +Although the vast majority of errors will be caught during compilation +or by superficially exercising the code, the only way to *really* verify +a backport is to review the final patch with the same level of scrutiny +as you would (or should) give to any other patch. Having unit tests and +regression tests or other types of automatic testing can help increase +the confidence in the correctness of a backport. + +Examples +======== + +The above shows roughly the idealized process of backporting a patch. +For a more concrete example, see this video tutorial where two patches +are backported from mainline to stable: +`Backporting Linux Kernel Patches`_. + +.. _Backporting Linux Kernel Patches: https://youtu.be/sBR7R1V2FeA diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index b501cd977053f..13e522752f880 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -66,6 +66,7 @@ lack of a better place. :maxdepth: 1 applying-patches + backporting adding-syscalls magic-number volatile-considered-harmful -- 2.25.1

7 months, 2 weeks

5
8
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2023