* Linux 5.7-rc2 @ 2020-04-19 21:58 Linus Torvalds [not found] ` <428bac87-b6dd-0867-c8f8-622cd606de3e@skogtun.org> 0 siblings, 1 reply; 12+ messages in thread From: Linus Torvalds @ 2020-04-19 21:58 UTC (permalink / raw) To: Linux Kernel Mailing List Here we are, a week later, and rc2 looks pretty nice and calm. Of course, it usually does that - people taking a breather after the merge window, and we may not have had enough time to see all the problem reports yet. Everything continues to look fairly normal, with commit counts right in the middle of what you'd expect for rc2. And most of the changes are tiny and don't look scary at all. In fact, about 30% of the patch is tooling, and even there a lot of it is because of one larger diff due to the x86 system call table being re-synchronized with the main kernel side. Outside of that, we've got driver fixes (ethernet stands out, but there's also other networking, GPU, sound, hwmon, i2c, clk..). And filesystems (afs, btrfs, xfs, ext4, cifs, proc). And Documentation, networking and arch fixes. And small random things elsewhere. Some of the spread out noise is the replacement of zero-sized arrays with flexible ones - we've had that come in through the various subsystems for a while now, and then Gustavo sent a pull request for another random collection. Nothing that really should be seen as all that exciting. Which is all good. The more noticeable one might be fixing the regression that was due to the EFI loaders not clearing the BSS section and us having lost the workaround for that. That caused boot problems for some. Not perhaps exciting, but an example of the kind of solid (boring?) small pedestrian things we've had. Shortlog appended so that you can scan the details if you want. Linus --- Adam Barber (1): ALSA: hda/realtek - Enable the headset mic on Asus FX505DT Alex Deucher (1): drm/amdgpu/gfx9: add gfxoff quirk Alexandru Tachici (1): dt-bindings: iio: dac: AD5570R fix bindings errors Amol Grover (1): netfilter: ipset: Pass lockdep expression to RCU lists Andrei Vagin (1): proc, time/namespace: Show clock symbolic names in /proc/pid/timens_offsets Andrew Lunn (2): net: dsa: mv88e6xxx: Configure MAC when using fixed link net: dsa: Down cpu/dsa ports phylink will control Andrey Ignatov (2): libbpf: Fix bpf_get_link_xdp_id flags handling selftests/bpf: Add test for bpf_get_link_xdp_id Andrii Nakryiko (3): bpf: Prevent re-mmap()'ing BPF map as writable for initially r/o mapping selftests/bpf: Validate frozen map contents stays frozen libbpf: Always specify expected_attach_type on program load if supported Ann T Ropea (1): hwmon: (drivetemp) Use drivetemp's true module name in Kconfig section Ard Biesheuvel (5): efi/arm: Deal with ADR going out of range in efi_enter_kernel() Documentation/x86, efi/x86: Clarify EFI handover protocol and its requirements efi/libstub/file: Merge file name buffers to reduce stack usage efi/x86: Don't remap text<->rodata gap read-only for mixed mode efi/x86: Revert struct layout change to fix kexec boot regression Arnaldo Carvalho de Melo (14): tools arch x86: Sync the msr-index.h copy with the kernel sources perf python: Check if clang supports -fno-semantic-interposition tools headers: Update linux/vdso.h and grab a copy of vdso/const.h tools headers UAPI: Sync sched.h with the kernel tools headers UAPI: Sync linux/mman.h with the kernel tools arch x86: Sync asm/cpufeatures.h with the kernel sources tools include UAPI: Sync linux/vhost.h with the kernel sources tools headers UAPI: Sync linux/fscrypt.h with the kernel sources tools headers kvm: Sync linux/kvm.h with the kernel sources tools headers UAPI: Update tools's copy of drm.h headers tools headers UAPI: Sync drm/i915_drm.h with the kernel sources tools headers: Update x86's syscall_64.tbl with the kernel sources tools headers: Adopt verbatim copy of compiletime_assert() from kernel sources tools headers: Synchronize linux/bits.h with the kernel sources Arnd Bergmann (4): net/tls: fix const assignment warning clk: asm9260: fix __clk_hw_register_fixed_rate_with_accuracy typo clk: mmp2: fix link error without mmp2 rtw88: avoid unused function warnings Arvind Sankar (2): efi/x86: Move efi stub globals from .bss to .data efi/x86: Always relocate the kernel for EFI handover entry Ashutosh Dixit (1): drm/i915/perf: Do not clear pollin for small user read buffers Atish Patra (1): irqchip/sifive-plic: Fix maximum priority threshold value Atsushi Nemoto (2): net: phy: micrel: use genphy_read_status for KSZ9131 net: stmmac: socfpga: Allow all RGMII modes Ben Skeggs (1): drm/nouveau/sec2/gv100-: add missing MODULE_FIRMWARE() Björn Töpel (1): riscv, bpf: Remove BPF JIT for nommu builds Bodo Stroesser (3): scsi: target: Write NULL to *port_nexus_ptr if no ISID scsi: target: fix PR IN / READ FULL STATUS for FC scsi: target: tcmu: reset_ring should reset TCMU_DEV_BIT_BROKEN Borislav Petkov (1): sched/vtime: Work around an unitialized variable warning Brian Foster (1): xfs: acquire superblock freeze protection on eofblocks scans Brian Geffon (1): mm: Fix MREMAP_DONTUNMAP accounting on VMA merge Cambda Zhu (1): Documentation: Fix tcp_challenge_ack_limit default value Chris Packham (1): docs: timekeeping: Use correct prototype for deprecated functions Christophe JAILLET (4): soc: qcom: ipa: Add a missing '\n' in a log message net: ethernet: ti: Add missing '\n' in log messages net: mvneta: Fix a typo platform/chrome: cros_ec_sensorhub: Add missing '\n' in log messages Chunyan Zhang (1): clk: sprd: don't gate uart console clock Clemens Gruber (1): net: phy: marvell: Fix pause frame negotiation Colin Ian King (5): bpf: Fix spelling mistake "arithmatic" -> "arithmetic" in test_verifier net-sysfs: remove redundant assignment to variable ret net: neterion: remove redundant assignment to variable tmp64 efi/libstub/x86: Remove redundant assignment to pointer hdr ipv6: remove redundant assignment to variable err DENG Qingfang (1): net: dsa: mt7530: fix tagged frames pass-through in VLAN-unaware mode Dan Carpenter (1): platform/chrome: cros_ec_sensorhub: Off by one in cros_sensorhub_send_sample() Daniel T. Lee (1): tools, bpftool: Fix struct_ops command invalid pointer free Darrick J. Wong (2): xfs: fix partially uninitialized structure in xfs_reflink_remap_extent xfs: move inode flush to the sync workqueue David Ahern (1): xdp: Reset prog in dev_change_xdp_fd when fd is negative David Howells (7): afs: Fix missing XDR advance in xdr_decode_{AFS,YFS}FSFetchStatus() afs: Fix decoding of inline abort codes from version 1 status records afs: Fix rename operation status delivery afs: Fix length of dump of bad YFSFetchStatus record afs: Fix race between post-modification dir edit and readdir/d_revalidate afs: Fix afs_d_validate() to set the right directory version rxrpc: Fix DATA Tx to disable nofrag for UDP on AF_INET6 socket Dmitry Osipenko (2): i2c: tegra: Better handle case where CPU0 is busy for a long time i2c: tegra: Synchronize DMA before termination Dmytro Linkin (1): net/mlx5e: Fix nest_level for vlan pop action Eli Cohen (1): net/mlx5: Fix condition for termination table cleanup Eran Ben Elisha (1): net/mlx5e: Add missing release firmware call Eric Biggers (1): docs: admin-guide: merge sections for the kernel.modprobe sysctl Eric Dumazet (1): netfilter: nf_tables: do not leave dangling pointer in nf_tables_set_alloc_name Eric W. Biederman (1): proc: Handle umounts cleanly Eugene Syromiatnikov (4): btrfs: re-instantiate the removed BTRFS_SUBVOL_CREATE_ASYNC definition clone3: fix cgroup argument sanity check clone3: add a check for the user struct size if CLONE_INTO_CGROUP is set clone3: add build-time CLONE_ARGS_SIZE_VER* validity checks Evan Quan (2): drm/amd/powerplay: unload mp1 for Arcturus RAS baco reset drm/amdgpu: fix wrong vram lost counter increment V2 Fabio Estevam (4): dt-bindings: iio: dac: ad5770r: Add vendor to compatible string dt-bindings: iio: dac: ad5770r: Fix the file path dt-bindings: touchscreen: edt-ft5x06: Remove unneeded I2C unit name dt-bindings: clock: syscon-icst: Remove unneeded unit name Fangrui Song (1): arm64: Delete the space separator in __emit_inst Filipe Manana (3): btrfs: fix lost i_size update after cloning inline extent btrfs: make full fsyncs always operate on the entire file again btrfs: fix reclaim counter leak of space_info objects Florian Fainelli (1): net: stmmac: dwmac-sunxi: Provide TX and RX fifo sizes Florian Westphal (1): mptcp: fix double-unlock in mptcp_poll Frank Rowand (5): of: unittest: kmemleak on changeset destroy of: unittest: kmemleak in of_unittest_platform_populate() of: unittest: kmemleak in of_unittest_overlay_high_level() of: overlay: kmemleak in dup_and_fixup_symbol_prop() of: unittest: kmemleak in duplicate property update Gary Lin (1): efi/x86: Fix the deletion of variables in mixed mode Geert Uytterhoeven (2): m68k: Drop redundant generic-y += hardirq.h dt-bindings: Fix misspellings of "Analog Devices" Gilberto Bertin (1): net: tun: record RX queue in skb before do_xdp_generic() Grygorii Strashko (1): irqchip/ti-sci-inta: Fix processing of masked irqs Guenter Roeck (3): mtd: spi-nor: Compile files in controllers/ directory hwmon: (pmbus/isl68137) Fix up chip IDs hwmon: (drivetemp) Return -ENODATA for invalid temperatures Gustavo A. R. Silva (29): hv: hyperv_vmbus.h: Replace zero-length array with flexible-array member bio: Replace zero-length array with flexible-array member blk-mq: Replace zero-length array with flexible-array member blk_types: Replace zero-length array with flexible-array member can: dev: peak_canfd.h: Replace zero-length array with flexible-array member digsig.h: Replace zero-length array with flexible-array member dirent.h: Replace zero-length array with flexible-array member enclosure.h: Replace zero-length array with flexible-array member energy_model.h: Replace zero-length array with flexible-array member ethtool.h: Replace zero-length array with flexible-array member genalloc.h: Replace zero-length array with flexible-array member igmp.h: Replace zero-length array with flexible-array member ihex.h: Replace zero-length array with flexible-array member irq.h: Replace zero-length array with flexible-array member lib: cpu_rmap: Replace zero-length array with flexible-array member list_lru.h: Replace zero-length array with flexible-array member memcontrol.h: Replace zero-length array with flexible-array member platform_data: wilco-ec.h: Replace zero-length array with flexible-array member posix_acl.h: Replace zero-length array with flexible-array member rio.h: Replace zero-length array with flexible-array member rslib.h: Replace zero-length array with flexible-array member sched: topology.h: Replace zero-length array with flexible-array member skbuff.h: Replace zero-length array with flexible-array member swap.h: Replace zero-length array with flexible-array member ti_wilink_st.h: Replace zero-length array with flexible-array member tpm_eventlog.h: Replace zero-length array with flexible-array member uapi: linux: dlm_device.h: Replace zero-length array with flexible-array member uapi: linux: fiemap.h: Replace zero-length array with flexible-array member xattr.h: Replace zero-length array with flexible-array member Hans de Goede (1): i2c: designware: platdrv: Remove DPM_FLAG_SMART_SUSPEND flag on BYT and CHT Hui Wang (1): ALSA: hda: call runtime_allow() for all hda controllers Ilya Dryomov (4): rbd: avoid a deadlock on header_rwsem when flushing notifies rbd: call rbd_dev_unprobe() after unwatching and flushing notifies rbd: don't test rbd_dev->opts in rbd_dev_image_release() rbd: don't mess with a page vector in rbd_notify_op_lock() Jakub Kicinski (1): docs: networking: convert DIM to RST Jakub Sitnicki (1): net, sk_msg: Don't use RCU_INIT_POINTER on sk_user_data James Morse (1): x86/resctrl: Preserve CDP enable over CPU hotplug Jan Kara (1): ext4: do not zeroout extents beyond i_disksize Jason Gunthorpe (2): net/cxgb4: Check the return from t4_query_params properly net/rds: Use ERR_PTR for rds_message_alloc_sgs() Jason Yan (9): hwmon: (k10temp) make some symbols static x86/umip: Make umip_insns static net: tulip: make early_486_chipsets static ext4: remove set but not used variable 'es' ext4: remove set but not used variable 'es' in ext4_jbd2.c mISDN: make dmril and dmrim static arm/xen: make _xen_start_info static irqchip/irq-mvebu-icu: Make legacy_bindings static irqchip/irq-bcm7038-l1: Make bcm7038_l1_of_init() static Jeff Layton (1): ceph: fix potential bad pointer deref in async dirops cb's Jens Axboe (4): io_uring: correct O_NONBLOCK check for splice punt io_uring: check for need to re-wait in polled async handling io_uring: io_async_task_func() should check and honor cancelation io_uring: only post events in io_poll_remove_all() if we completed some Jeremy Cline (1): libbpf: Initialize *nl_pid so gcc 10 is happy Jin Yao (1): perf stat: Fix no metric header if --per-socket and --metric-only set Joe Stringer (1): bpf: Fix use of sk->sk_reuseport from sk_assign Johan Jonker (1): dt-bindings: net: ethernet-phy: add desciption for ethernet-phy-id1234.d400 Johannes Berg (1): nl80211: fix NL80211_ATTR_FTM_RESPONDER policy John Allen (1): x86/microcode/AMD: Increase microcode PATCH_MAX_SIZE John Garry (1): blk-mq: Put driver tag in blk_mq_dispatch_rq_list() when no budget Jones Syue (1): cifs: improve read performance for page size 64KB & cache=strict & vers=2.1+ Josef Bacik (2): btrfs: check commit root generation in should_ignore_root btrfs: fix setting last_trans for reloc roots Josh Poimboeuf (5): objtool: Fix CONFIG_UBSAN_TRAP unreachable warnings objtool: Support Clang non-section symbols in ORC dump objtool: Support Clang non-section symbols in ORC generation objtool: Fix switch table detection in .text.unlikely objtool: Make BP scratch register warning more robust Josh Triplett (1): ext4: fix return-value types in several function comments Juergen Gross (1): xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant status KP Singh (1): bpf, lsm: Fix the file_mprotect LSM test. Ka-Cheong Poon (2): net/rds: Replace struct rds_mr's r_refcount with struct kref net/rds: Fix MR reference counting problem Kai-Heng Feng (1): ahci: Add Intel Comet Lake PCH-U PCI ID Konstantin Khlebnikov (1): net: revert default NAPI poll timeout to 2 jiffies Li Bin (1): scsi: sg: add sg_remove_request in sg_common_write Li RongQing (1): xsk: Fix out of boundary write in __xsk_rcv_memcpy Likun Gao (1): Revert "drm/amdgpu: change SH MEM alignment mode for gfx10" Linus Torvalds (1): Linux 5.7-rc2 Lothar Rubusch (4): net: sock.h: fix skb_steal_sock() kernel-doc Documentation: mdio_bus.c - fix warnings Documentation: devlink: fix broken link warning cfg80211: fix kernel-doc notation Luke Nelson (3): riscv, bpf: Fix offset range checking for auipc+jalr on RV64 arm, bpf: Fix bugs with ALU64 {RSH, ARSH} BPF_K shift by 0 arm, bpf: Fix offset overflow for BPF_MEM BPF_DW Maciej Żenczykowski (1): netfilter: xt_IDLETIMER: target v1 - match Android layout Magnus Karlsson (1): xsk: Add missing check on user supplied headroom size Marc Zyngier (3): irqchip/gic-v4.1: Add support for VPENDBASER's Dirty+Valid signaling irqchip/gic-v4.1: Update effective affinity of virtual SGIs irqchip/meson-gpio: Fix HARDIRQ-safe -> HARDIRQ-unsafe lock order Mark Rutland (1): arm64: vdso: don't free unallocated pages Martin Fuzzey (4): net: fec: set GPR bit on suspend by DT configuration. ARM: dts: imx6: Use gpc for FEC interrupt controller to fix wake on LAN. dt-bindings: fec: document the new gpr property. ARM: dts: imx6: add fec gpr property. Masahiro Yamada (1): kbuild: check libyaml installation for 'make dt_binding_check' Matti Vaittinen (1): dt-bindings: BD718x7 - add missing I2C bus properties Mauro Carvalho Chehab (6): docs: dt: fix broken reference to phy-cadence-torrent.yaml docs: dt: qcom,dwc3.txt: fix cross-reference for a converted file docs: dt: fix a broken reference for a file converted to json docs: dt: rockchip,dwc3.txt: fix a pointer to a renamed file MAINTAINERS: dt: update display/allwinner file entry MAINTAINERS: dt: fix pointers for ARM Integrator, Versatile and RealView Michael Walle (1): watchdog: sp805: fix restart handler Michael Weiß (1): l2tp: Allow management of tunnels and session in user namespace Moshe Shemesh (1): net/mlx5: Fix frequent ioread PCI access during recovery Nilesh Javali (2): scsi: qla2xxx: Fix regression warnings scsi: MAINTAINERS: Update qla2xxx FC-SCSI driver maintainer Olaf Hering (1): x86: hyperv: report value of misc_features Ondrej Mosnacek (1): selinux: free str on error in str_read() Pablo Neira Ayuso (3): netfilter: nf_tables: do not update stateful expressions if lookup is inverted netfilter: nf_tables: report EOPNOTSUPP on unsupported flags/object type netfilter: nf_tables: reintroduce the NFT_SET_CONCAT flag Parav Pandit (2): net/mlx5e: Fix pfnum in devlink port attribute net/mlx5e: Fix devlink port netdev unregistration sequence Paul Blakey (2): net: sched: Fix setting last executed chain on skb extension net/mlx5e: CT: Use rhashtable's ct entries instead of a separate list Paul E. McKenney (1): rcu: Don't acquire lock in NMI handler in rcu_nmi_enter_common() Pavel Begunkov (8): io_uring: remove obsolete @mm_fault io_uring: track mm through current->mm io_uring: early submission req fail code io_uring: keep all sqe->flags in req->flags io_uring: move all request init code in one place io_uring: fix cached_sq_head in io_timeout() io_uring: kill already cached timeout.seq_offset io_uring: don't count rqs failed after current one Peter Maydell (1): scripts/kernel-doc: Add missing close-paren in c:function directives Peter Xu (1): sched/isolation: Allow "isolcpus=" to skip unknown sub-parameters Prike Liang (1): drm/amdgpu: fix the hw hang during perform system reboot and reset Qiujun Huang (1): bpf: Fix a typo "inacitve" -> "inactive" Rafał Miłecki (1): brcmfmac: add stub for monitor interface xmit Rajendra Nayak (1): opp: Manage empty OPP tables with clk handle Randy Dunlap (1): docs: networking: add full DIM API Reinette Chatre (1): x86/resctrl: Fix invalid attempt at removing the default resource group René van Dorst (2): net: dsa: mt7530: move mt7623 settings out off the mt7530 net: ethernet: mediatek: move mt7623 settings out off the mt7530 Rob Herring (4): dt-bindings: Fix dtc warnings on reg and ranges in examples dt-bindings: hwmon: Fix incorrect $id paths dt-bindings: interrupt-controller: Fix loongson,parent_int_map property schema dt-bindings: pwm: Fix cros-ec-pwm example dtc 'reg' warning Roi Dayan (1): net/mlx5e: Fix missing pedit action after ct clear action Roman Gushchin (1): ext4: use non-movable memory for superblock readahead Roman Mashak (1): tc-testing: remove duplicate code in tdc.py Ronnie Sahlberg (1): cifs: dump the session id and keys also for SMB2 sessions Roy Spliet (1): ALSA: hda: Explicitly permit using autosuspend if runtime PM is supported Russell King (2): net: marvell10g: report firmware version net: marvell10g: soft-reset the PHY when coming out of low power Sascha Hauer (1): hwmon: (jc42) Fix name to have no illegal characters Sebastian Andrzej Siewior (1): amd-xgbe: Use __napi_schedule() in BH context Sergei Lopatin (1): drm/amd/powerplay: force the trim of the mclk dpm_levels if OD is enabled Shannon Nelson (4): ionic: replay filters after fw upgrade ionic: set station addr only if needed ionic: add dynamic_debug header ionic: fix unused assignment Slava Bacherikov (1): kbuild, btf: Fix dependencies for DEBUG_INFO_BTF Stefan Haberland (1): s390/dasd: remove IOSCHED_DEADLINE from DASD Kconfig Stefano Brivio (1): netfilter: nft_set_rbtree: Drop spurious condition for overlap detection on insertion Steve French (1): smb3: remove overly noisy debug line in signing errors Sumit Garg (1): mac80211: fix race in ieee80211_register_hw() Taehee Yoo (2): hsr: check protocol version in hsr_newlink() net: macsec: fix using wrong structure in macsec_changelink() Takashi Iwai (11): ALSA: usb-audio: Filter error from connector kctl ops, too ALSA: usb-audio: Don't override ignore_ctl_error value from the map ALSA: usb-audio: Don't create jack controls for PCM terminals ALSA: usb-audio: Check mapping at creating connector controls, too ALSA: hda: Don't release card at firmware loading error ALSA: hda: Honor PM disablement in PM freeze and thaw_noirq ops ALSA: hda: Release resources at error in delayed probe ALSA: hda: Keep the controller initialization even if no codecs found ALSA: hda: Skip controller resume if not needed ALSA: hda: Allow setting preallocation again for x86 efi/cper: Use scnprintf() for avoiding potential buffer overflow Tamizh chelvam (1): mac80211: fix channel switch trigger from unknown mesh peer Taras Chornyi (1): net: ipv4: devinet: Fix crash when add/del multicast IP with autojoin Theodore Ts'o (2): ext4: increase wait time needed before reuse of deleted inode numbers ext4: convert BUG_ON's to WARN_ON's in mballoc.c Tianyu Lan (6): x86/Hyper-V: Unload vmbus channel in hv panic callback x86/Hyper-V: Free hv_panic_page when fail to register kmsg dump x86/Hyper-V: Trigger crash enlightenment only once during system crash. x86/Hyper-V: Report crash register data or kmsg before running crash kernel x86/Hyper-V: Report crash register data when sysctl_record_panic_msg is not set x86/Hyper-V: Report crash data in die() when panic_on_oops is set Tiezhu Yang (1): scripts: documentation-file-ref-check: Add line break before exit Tim Stallard (2): net: icmp6: do not select saddr from iif when route has prefsrc set net: ipv6: do not consider routes via gateways for anycast address check Toke Høiland-Jørgensen (2): libbpf: Fix type of old_fd in bpf_xdp_set_link_opts selftests/bpf: Check for correct program attach/detach in xdp_attach test Tommi Rantala (2): blk-wbt: Use tracepoint_string() for wbt_step tracepoint string literals blk-wbt: Drop needless newlines from tracepoint format strings Tony Luck (3): x86/split_lock: Update to use X86_MATCH_INTEL_FAM6_MODEL() x86/split_lock: Bits in IA32_CORE_CAPABILITIES are not architectural x86/split_lock: Add Tremont family CPU models Trond Myklebust (1): NFS: Fix an ABBA spinlock issue in pnfs_update_layout() Tuomas Tynkkynen (1): mac80211_hwsim: Use kstrndup() in place of kasprintf() Tuong Lien (1): tipc: fix incorrect increasing of link window Vasily Averin (1): keys: Fix proc_keys_next to increase position index Vladimir Oltean (1): net: mscc: ocelot: fix untagged packet drops when enslaving to vlan aware bridge Wang Wenhu (1): net: qrtr: send msgs from local of same id as broadcast Wolfram Sang (2): i2c: altera: use proper variable to hold errno i2c: remove i2c_new_probed_device API Xiao Yang (1): tracing: Fix the race between registering 'snapshot' event trigger and triggering 'snapshot' operation Xiaoguang Wang (1): io_uring: restore req->work when canceling poll request Xu Wang (1): ALSA: ctxfi: Remove unnecessary cast in kfree Yan Zhao (3): drm/i915/gvt: hold reference of VFIO group during opening of vgpu drm/i915/gvt: subsitute kvm_read/write_guest with vfio_dma_rw drm/i915/gvt: switch to user vfio_group_pin/upin_pages YueHaibing (3): hv_debugfs: Make hv_debug_root static ath11k: fix compiler warnings without CONFIG_THERMAL scsi: hisi_sas: Fix build error without SATA_HOST Zenghui Yu (1): irqchip/mbigen: Free msi_desc on device teardown Zhiqiang Liu (2): signal: check sig before setting info in kill_pid_usb_asyncio signal: use kill_proc_info instead of kill_pid_info in kill_something_info Zou Wei (1): bpf: remove unneeded conversion to bool in __mark_reg_unknown afzal mohammed (1): genirq: Remove setup_irq() and remove_irq() yangerkun (1): ext4: use matching invalidatepage in ext4_writepage ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <428bac87-b6dd-0867-c8f8-622cd606de3e@skogtun.org>]
* Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2) [not found] ` <428bac87-b6dd-0867-c8f8-622cd606de3e@skogtun.org> @ 2020-04-21 19:03 ` Linus Torvalds 2020-04-21 21:23 ` Peter Zijlstra 2020-04-22 9:32 ` Harald Arnesen 0 siblings, 2 replies; 12+ messages in thread From: Linus Torvalds @ 2020-04-21 19:03 UTC (permalink / raw) To: Harald Arnesen, Peter Zijlstra, Ingo Molnar, Rafael J. Wysocki Cc: Linux Kernel Mailing List, Giovanni Gherdovich On Mon, Apr 20, 2020 at 1:52 AM Harald Arnesen <harald@skogtun.org> wrote: > > Neither rc1 nor rc2 will boot on my laptop. The attached picture is all > I have been able to capture. I know you saw the reply about this probably being fixed by https://lore.kernel.org/lkml/20200416054745.740-1-ggherdovich@suse.cz/ but it would be lovely if you could actually verify that that series of four patches does indeed fix it for you. Your oops is on that divide instruction: freq_scale = div64_u64(acnt, mcnt); and while we had a check for mcnt not being zero earlier, we did mcnt *= arch_max_freq_ratio; after that check. I could see it becoming zero either due to an overflow, or due to arch_max_freq_ratio being 0. I think the first commit in that series is supposed to fix that arch_max_freq_ratio being 0 case, but it still feels like the code that does the divide is checking for zero in the wrong place... Linus ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2) 2020-04-21 19:03 ` [BISECTED]: Kernel panic (was: Linux 5.7-rc2) Linus Torvalds @ 2020-04-21 21:23 ` Peter Zijlstra 2020-04-21 21:30 ` Linus Torvalds 2020-04-22 9:02 ` Giovanni Gherdovich 2020-04-22 9:32 ` Harald Arnesen 1 sibling, 2 replies; 12+ messages in thread From: Peter Zijlstra @ 2020-04-21 21:23 UTC (permalink / raw) To: Linus Torvalds Cc: Harald Arnesen, Ingo Molnar, Rafael J. Wysocki, Linux Kernel Mailing List, Giovanni Gherdovich On Tue, Apr 21, 2020 at 12:03:10PM -0700, Linus Torvalds wrote: > On Mon, Apr 20, 2020 at 1:52 AM Harald Arnesen <harald@skogtun.org> wrote: > > > > Neither rc1 nor rc2 will boot on my laptop. The attached picture is all > > I have been able to capture. > > I know you saw the reply about this probably being fixed by > > https://lore.kernel.org/lkml/20200416054745.740-1-ggherdovich@suse.cz/ > > but it would be lovely if you could actually verify that that series > of four patches does indeed fix it for you. (not seeing the original report in the archives or my list copy) I'm assuming it's some sort of dodgy virt setup, actual real proper hardware should never get here like that. > Your oops is on that divide instruction: > > freq_scale = div64_u64(acnt, mcnt); > > and while we had a check for mcnt not being zero earlier, we did > > mcnt *= arch_max_freq_ratio; > > after that check. I could see it becoming zero either due to an > overflow, or due to arch_max_freq_ratio being 0. Right, so that's not supposed to happen, as you say, we should not enable this code if the ratio is 0, and we should not overflow mcnt due to reading that reg once per tick. But yeha, virt, anything can happen :/ > I think the first commit in that series is supposed to fix that > arch_max_freq_ratio being 0 case, but it still feels like the code > that does the divide is checking for zero in the wrong place... Yeah, we can certainly modify that. As is, real actual hardware should never even hit that case either. So we might as well move that check and then also make it disable all this frequency scaling stuff if we ever do hit it. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2) 2020-04-21 21:23 ` Peter Zijlstra @ 2020-04-21 21:30 ` Linus Torvalds 2020-04-21 21:41 ` Peter Zijlstra 2020-04-22 9:02 ` Giovanni Gherdovich 1 sibling, 1 reply; 12+ messages in thread From: Linus Torvalds @ 2020-04-21 21:30 UTC (permalink / raw) To: Peter Zijlstra Cc: Harald Arnesen, Ingo Molnar, Rafael J. Wysocki, Linux Kernel Mailing List, Giovanni Gherdovich On Tue, Apr 21, 2020 at 2:23 PM Peter Zijlstra <peterz@infradead.org> wrote: > > (not seeing the original report in the archives or my list copy) Hmm. It was cc'd to lkml, but maybe the attached 3.2MB picture ended up making it too big to actually make it to the list... The picture was just the bottom of the oops - I decoded the Code: section just to verify that yeah, it's the div instruction in arch_scale_freq_tick, from kernel_init -> native_smp_prepapre_cpus (the rest of the oops has scrolled off the page). > I'm assuming it's some sort of dodgy virt setup, actual real proper > hardware should never get here like that. It actually looks like a native boot on a Lenovo T510i laptop to me. Also, see https://lore.kernel.org/lkml/b90ba443-9b9d-481e-7ecc-d5a25816e02f@oracle.com/ where Dave Kleikamp seems to say that it happens on his Lenovo T410. So I do think it's real, and _not_ virtualization. Please don't dismiss it as some vmware artifact. Looks more like it's triggered by some Lenovo Thinkpad BIOS setup issue. Linus ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2) 2020-04-21 21:30 ` Linus Torvalds @ 2020-04-21 21:41 ` Peter Zijlstra 0 siblings, 0 replies; 12+ messages in thread From: Peter Zijlstra @ 2020-04-21 21:41 UTC (permalink / raw) To: Linus Torvalds Cc: Harald Arnesen, Ingo Molnar, Rafael J. Wysocki, Linux Kernel Mailing List, Giovanni Gherdovich On Tue, Apr 21, 2020 at 02:30:06PM -0700, Linus Torvalds wrote: > Also, see > > https://lore.kernel.org/lkml/b90ba443-9b9d-481e-7ecc-d5a25816e02f@oracle.com/ > > where Dave Kleikamp seems to say that it happens on his Lenovo T410. > > So I do think it's real, and _not_ virtualization. Please don't > dismiss it as some vmware artifact. Looks more like it's triggered by > some Lenovo Thinkpad BIOS setup issue. Oh, right (I actually saw that email when I picked up the patches, but clearly instantly forgot about it again). If the BIOS gets the tables funny we hit the same paths. Anyway, it would be good if the reporter can confirm, I've also queued those patches for /urgent, so they should show up soonish. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2) 2020-04-21 21:23 ` Peter Zijlstra 2020-04-21 21:30 ` Linus Torvalds @ 2020-04-22 9:02 ` Giovanni Gherdovich 2020-04-22 9:37 ` Harald Arnesen 2020-04-22 14:12 ` Dave Kleikamp 1 sibling, 2 replies; 12+ messages in thread From: Giovanni Gherdovich @ 2020-04-22 9:02 UTC (permalink / raw) To: Peter Zijlstra, Linus Torvalds, Harald Arnesen, Dave Kleikamp Cc: Ingo Molnar, Rafael J. Wysocki, Linux Kernel Mailing List Linus, Peter: the panic seen by Harald Arnesen (and Dave Kleikamp) is unrelated to virtualization, and happens on all machines that have a CPU with less than 4 physical cores. It's a very serious (and very stupid) bug in the original version of my code and is fixed by patch 2/4 "x86, sched: Account for CPUs with less than 4 cores in freq. invariance" in the series https://lore.kernel.org/lkml/20200416054745.740-1-ggherdovich@suse.cz Harald, Dave: for peace of mind, can you please share the output of turbostat --interval 1 sleep 0 from your machines? This should print a long list of power management-related information, including your CPU model and the content of MSR_TURBO_RATIO_LIMIT. In all likelihood that MSR says that the "4 cores turbo frequency" of your CPU is zero, and the buggy code divides by that value. Harald: I'll echo Linus' request of testing that the patch series linked above fixes the problem on your machine. Since you're testing -rc kernels and bisecting bugs I assume you're comfortable with patching and compiling kernels, but if that is not the case I am more than happy to assist by providing either an RPM or a DEB package, depending on the distribution you're running. Let me know. More comments below. On Tue, 2020-04-21 at 23:23 +0200, Peter Zijlstra wrote: > On Tue, Apr 21, 2020 at 12:03:10PM -0700, Linus Torvalds wrote: > > On Mon, Apr 20, 2020 at 1:52 AM Harald Arnesen <harald@skogtun.org> wrote: > > > > > > Neither rc1 nor rc2 will boot on my laptop. The attached picture is all > > > I have been able to capture. > > > > I know you saw the reply about this probably being fixed by > > > > https://lore.kernel.org/lkml/20200416054745.740-1-ggherdovich@suse.cz/ > > > > but it would be lovely if you could actually verify that that series > > of four patches does indeed fix it for you. > > (not seeing the original report in the archives or my list copy) > > I'm assuming it's some sort of dodgy virt setup, actual real proper > hardware should never get here like that. I think Peter is mentioning virtualization because in another patch of my bugfix series I address a separate issue, indeed arising in hypervisors: patch 1/4 "x86, sched: Bail out of frequency invariance if base frequency is unknown". The thing is that my original code does two divisions (just grep for "div" in the patch 1567c3e3467c "x86, sched: Add support for frequency invariance"). One of them divides by zero when num_cpus < 4, the other divides by zero on some hypervisors (basically). Here are the incriminated statements (file arch/x86/kernel/smpboot.c): (1) arch_turbo_freq_ratio = div_u64(turbo_freq * SCHED_CAPACITY_SCALE, base_freq); /* ... stuff ... */ mcnt *= arch_max_freq_ratio; (2) freq_scale = div64_u64(acnt, mcnt); Hypervisors: If base_freq is zero, division (1) fails. This is addressed by patch 1/4 in the bugfix series linked above. base_freq is read from MSR_PLATFORM_INFO (no BIOS involved, it's straight from the CPU) and is the max CPU clock frequency without counting turbo. The Intel SDM specifies this MSR's content, none of the machines I tested said "my base clock frequency is zero", but I didn't think of hypervisors. Small machines: If turbo_freq is zero, division (2) fails. This is addressed by patch 2/4 "x86, sched: Account for CPUs with less than 4 cores in freq. invariance". I read turbo_freq from MSR_TURBO_RATIO_LIMIT (again: no BIOS involved), at a specific offset where it should contain the clock frequency sustainable by 4 cores simultaneously. If the machines has less than for cores, this data is rightfully zero and thus the panic that Harald Arnesen and Dave Kleikamp observed. It's an embarrassing mistake I made, I tested on several machines including a consumer-level Atom Airmont (Dell Wyse thin client) but all had at least 4 cores so I didn't see it. For the records: there is a report for the "small machines" div-by-zero bug from a 24 core Atom P-Series (new product line from 2020), but the fix works on that machine, see https://lore.kernel.org/lkml/bf43772d-48e5-01d4-dd03-330110e487fa@linux.intel.com/ > > > Your oops is on that divide instruction: > > > > freq_scale = div64_u64(acnt, mcnt); > > > > and while we had a check for mcnt not being zero earlier, we did > > > > mcnt *= arch_max_freq_ratio; > > > > after that check. I could see it becoming zero either due to an > > overflow, or due to arch_max_freq_ratio being 0. > > Right, so that's not supposed to happen, as you say, we should not > enable this code if the ratio is 0, and we should not overflow mcnt due > to reading that reg once per tick. > > But yeha, virt, anything can happen :/ > > > I think the first commit in that series is supposed to fix that > > arch_max_freq_ratio being 0 case, but it still feels like the code > > that does the divide is checking for zero in the wrong place... > > Yeah, we can certainly modify that. As is, real actual hardware should > never even hit that case either. So we might as well move that check and > then also make it disable all this frequency scaling stuff if we ever do > hit it. I'm going to send the following patch. There are a number of reasons why mcnt overflowing and landing exactly at zero is unlikely (we read MPERF once every tick, and arch_max_freq_ratio is a small number) but it's still a real problem (eg. tickless kernels) and the zero check is 4 lines above where it should be, it just needs to move down. diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 8c89e4d9ad28..fb71395cbcad 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -2055,14 +2055,14 @@ void arch_scale_freq_tick(void) acnt = aperf - this_cpu_read(arch_prev_aperf); mcnt = mperf - this_cpu_read(arch_prev_mperf); - if (!mcnt) - return; this_cpu_write(arch_prev_aperf, aperf); this_cpu_write(arch_prev_mperf, mperf); acnt <<= 2*SCHED_CAPACITY_SHIFT; mcnt *= arch_max_freq_ratio; + if (!mcnt) + return; freq_scale = div64_u64(acnt, mcnt); Giovanni ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2) 2020-04-22 9:02 ` Giovanni Gherdovich @ 2020-04-22 9:37 ` Harald Arnesen 2020-04-22 10:22 ` Harald Arnesen 2020-04-22 14:12 ` Dave Kleikamp 1 sibling, 1 reply; 12+ messages in thread From: Harald Arnesen @ 2020-04-22 9:37 UTC (permalink / raw) To: Giovanni Gherdovich, Peter Zijlstra, Linus Torvalds, Dave Kleikamp Cc: Ingo Molnar, Rafael J. Wysocki, Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 705 bytes --] Giovanni Gherdovich [22.04.2020 11:02]: > Harald, Dave: > > for peace of mind, can you please share the output of > > turbostat --interval 1 sleep 0 Output from turbostat is attached. > Harald: > > I'll echo Linus' request of testing that the patch series linked above fixes > the problem on your machine. Since you're testing -rc kernels and bisecting > bugs I assume you're comfortable with patching and compiling kernels, but if > that is not the case I am more than happy to assist by providing either an RPM > or a DEB package, depending on the distribution you're running. Let me know. Will try patching first, if I'm not successful, you may compile a DEB package for me. -- Hilsen Harald [-- Attachment #2: turbostat.out --] [-- Type: text/plain, Size: 1750 bytes --] turbostat version 18.07.27 - Len Brown <lenb@kernel.org> CPUID(0): GenuineIntel 0xb CPUID levels; 0x80000008 xlevels; family:model:stepping 0x6:25:2 (6:37:2) CPUID(1): SSE3 MONITOR - EIST TM2 TSC MSR ACPI-TM HT TM CPUID(6): APERF, TURBO, DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, No-EPB cpu2: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST MWAIT PREFETCH TURBO) CPUID(7): No-SGX cpu2: MSR_MISC_PWR_MGMT: 0x00400000 (ENable-EIST_Coordination DISable-EPB DISable-OOB) cpu2: MSR_PLATFORM_INFO: 0x90020011100 9 * 133.3 = 1200.0 MHz max efficiency frequency 17 * 133.3 = 2266.6 MHz base frequency cpu2: MSR_IA32_POWER_CTL: 0x00000000 (C1E auto-promotion: DISabled) cpu2: MSR_TURBO_RATIO_LIMIT: 0x00001313 19 * 133.3 = 2533.3 MHz max turbo 2 active cores 19 * 133.3 = 2533.3 MHz max turbo 1 active cores cpu2: MSR_PKG_CST_CONFIG_CONTROL: 0x00000403 (UNlocked, pkg-cstate-limit=3 (pc6)) cpu2: POLL: CPUIDLE CORE POLL IDLE cpu2: C1: MWAIT 0x00 cpu2: C1E: MWAIT 0x01 cpu2: C3: MWAIT 0x10 cpu2: C6: MWAIT 0x20 cpu2: cpufreq driver: acpi-cpufreq cpu2: cpufreq governor: userspace cpufreq boost: 1 cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x00690a00 (105 C) 0.002757 sec Node Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz IRQ SMI POLL C1 C1E C3 C6 POLL% C1% C1E% C3% C6% CPU%c1 CPU%c3 CPU%c6 CoreTmp Pkg%pc3 Pkg%pc6 - - - 324 26.34 1251 2231 8 0 0 0 0 5 7 0.00 0.00 0.00 49.33 24.12 29.52 29.99 14.15 36 0.00 0.00 -1 0 0 179 11.33 1625 2204 1 0 0 0 0 1 1 0.00 0.00 0.00 71.56 15.67 57.73 20.62 10.31 36 0.00 0.00 -1 0 1 665 56.41 1211 2204 5 0 0 0 0 2 1 0.00 0.00 0.00 30.11 12.77 12.64 -1 2 2 145 12.20 1200 2250 1 0 0 0 0 1 2 0.00 0.00 0.00 54.15 34.42 30.56 39.29 17.96 29 -1 2 3 309 25.72 1199 2268 1 0 0 0 0 1 3 0.00 0.00 0.00 41.57 33.66 17.47 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2) 2020-04-22 9:37 ` Harald Arnesen @ 2020-04-22 10:22 ` Harald Arnesen 2020-04-22 11:01 ` Giovanni Gherdovich 0 siblings, 1 reply; 12+ messages in thread From: Harald Arnesen @ 2020-04-22 10:22 UTC (permalink / raw) To: Giovanni Gherdovich, Peter Zijlstra, Linus Torvalds, Dave Kleikamp Cc: Ingo Molnar, Rafael J. Wysocki, Linux Kernel Mailing List Harald Arnesen [22.04.2020 11:37]: > Giovanni Gherdovich [22.04.2020 11:02]: >> >> Harald: >> >> I'll echo Linus' request of testing that the patch series linked above fixes >> the problem on your machine. Since you're testing -rc kernels and bisecting >> bugs I assume you're comfortable with patching and compiling kernels, but if >> that is not the case I am more than happy to assist by providing either an RPM >> or a DEB package, depending on the distribution you're running. Let me know. > Will try patching first, if I'm not successful, you may compile a DEB > package for me. I can confirm that my Thinkpad T510i boots normally with the four patches added. Thanks! -- Hilsen Harald ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2) 2020-04-22 10:22 ` Harald Arnesen @ 2020-04-22 11:01 ` Giovanni Gherdovich 0 siblings, 0 replies; 12+ messages in thread From: Giovanni Gherdovich @ 2020-04-22 11:01 UTC (permalink / raw) To: Harald Arnesen, Peter Zijlstra, Linus Torvalds, Dave Kleikamp Cc: Ingo Molnar, Rafael J. Wysocki, Linux Kernel Mailing List On Wed, 2020-04-22 at 12:22 +0200, Harald Arnesen wrote: > Harald Arnesen [22.04.2020 11:37]: > > > Giovanni Gherdovich [22.04.2020 11:02]: > > > > > > Harald: > > > > > > I'll echo Linus' request of testing that the patch series linked above fixes > > > the problem on your machine. Since you're testing -rc kernels and bisecting > > > bugs I assume you're comfortable with patching and compiling kernels, but if > > > that is not the case I am more than happy to assist by providing either an RPM > > > or a DEB package, depending on the distribution you're running. Let me know. > > Will try patching first, if I'm not successful, you may compile a DEB > > package for me. > > I can confirm that my Thinkpad T510i boots normally with the four > patches added. > > Thanks! That's awesome, thank you for testing. Regarding the turbostat output you attached to an earlier email, it confirms the suspicion that the 4C turbo is reported as zero (being a 2 cores / 4 threads machine), explaining why the fix works: cpu2: MSR_TURBO_RATIO_LIMIT: 0x00001313 19 * 133.3 = 2533.3 MHz max turbo 2 active cores 19 * 133.3 = 2533.3 MHz max turbo 1 active cores In the above, bits 31:24 are zero. It's not a universal rule, though: my laptop also has a 2 cores / 4 threads cpu, and that same MSR says: cpu3: MSR_TURBO_RATIO_LIMIT: 0x1b1b1b1b1b1d 27 * 100.0 = 2700.0 MHz max turbo 6 active cores 27 * 100.0 = 2700.0 MHz max turbo 5 active cores 27 * 100.0 = 2700.0 MHz max turbo 4 active cores 27 * 100.0 = 2700.0 MHz max turbo 3 active cores 27 * 100.0 = 2700.0 MHz max turbo 2 active cores 29 * 100.0 = 2900.0 MHz max turbo 1 active cores So despite my CPU being similar to yours, it wouldn't show the bug. There is even more: the bug can show on large core counts too, as seen in https://lore.kernel.org/lkml/bf43772d-48e5-01d4-dd03-330110e487fa@linux.intel.com/ Like Xu from Intel has an Atom P-Series with 24 physical cores, yet their MSR goes like: MSR_TURBO_RATIO_LIMIT: 0x00000016 which means only the 1C turbo is reported non-zero (that machine doesn't have turbo at all, 1C turbo is the same as base frequency). Thanks, Giovanni ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2) 2020-04-22 9:02 ` Giovanni Gherdovich 2020-04-22 9:37 ` Harald Arnesen @ 2020-04-22 14:12 ` Dave Kleikamp 2020-04-22 14:49 ` Giovanni Gherdovich 1 sibling, 1 reply; 12+ messages in thread From: Dave Kleikamp @ 2020-04-22 14:12 UTC (permalink / raw) To: Giovanni Gherdovich, Peter Zijlstra, Linus Torvalds, Harald Arnesen Cc: Ingo Molnar, Rafael J. Wysocki, Linux Kernel Mailing List On 4/22/20 4:02 AM, Giovanni Gherdovich wrote: > Linus, Peter: > > the panic seen by Harald Arnesen (and Dave Kleikamp) is unrelated to > virtualization, and happens on all machines that have a CPU with less than 4 > physical cores. It's a very serious (and very stupid) bug in the original > version of my code and is fixed by patch 2/4 "x86, sched: Account for CPUs > with less than 4 cores in freq. invariance" in the series > > https://lore.kernel.org/lkml/20200416054745.740-1-ggherdovich@suse.cz > > Harald, Dave: > > for peace of mind, can you please share the output of > > turbostat --interval 1 sleep 0 This is a Lenovo T410. turbostat version 20.03.20 - Len Brown <lenb@kernel.org> CPUID(0): GenuineIntel 0xb CPUID levels; 0x80000008 xlevels; family:model:stepping 0x6:25:5 (6:37:5) CPUID(1): SSE3 MONITOR SMX EIST TM2 TSC MSR ACPI-TM HT TM CPUID(6): APERF, TURBO, DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, No-EPB cpu0: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST MWAIT PREFETCH TURBO) CPUID(7): No-SGX cpu0: MSR_MISC_PWR_MGMT: 0x00400000 (ENable-EIST_Coordination DISable-EPB DISable-OOB) cpu0: MSR_PLATFORM_INFO: 0x90020011200 9 * 133.3 = 1200.0 MHz max efficiency frequency 18 * 133.3 = 2399.9 MHz base frequency cpu0: MSR_IA32_POWER_CTL: 0x00000000 (C1E auto-promotion: DISabled) cpu0: MSR_TURBO_RATIO_LIMIT: 0x00001416 20 * 133.3 = 2666.6 MHz max turbo 2 active cores 22 * 133.3 = 2933.3 MHz max turbo 1 active cores cpu0: MSR_PKG_CST_CONFIG_CONTROL: 0x00000403 (UNlocked, pkg-cstate-limit=3 (pc6)) current_driver: intel_idle current_governor_ro: menu cpu0: POLL: CPUIDLE CORE POLL IDLE cpu0: C1: MWAIT 0x00 cpu0: C1E: MWAIT 0x01 cpu0: C3: MWAIT 0x10 cpu0: C6: MWAIT 0x20 cpu0: cpufreq driver: acpi-cpufreq cpu0: cpufreq governor: ondemand cpufreq boost: 1 cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x00690a00 (105 C) 0.001871 sec Node Core CPU Avg_MHz Busy% Bzy_MHz TSC_MHz IRQ SMI POLL C1 C1E C3 C6 POLL% C1% C1E% C3% C6% CPU%c1 CPU%c3 CPU%c6 CoreTmp Pkg%pc3 Pkg%pc6 - - - 395 26.14 1493 2430 12 0 0 1 1 10 0 0.00 1.50 0.59 73.54 0.00 28.45 45.41 0.00 63 0.00 0.00 -1 0 0 239 16.27 1473 2397 3 0 0 1 0 2 0 0.00 5.92 0.00 79.10 0.00 51.50 32.23 0.00 62 0.00 0.00 -1 0 1 784 50.12 1574 2385 3 0 0 0 1 2 0 0.00 0.00 2.37 47.20 0.00 17.26 -1 2 2 171 10.80 1598 2373 2 0 0 0 0 2 0 0.00 0.00 0.00 90.00 0.00 30.33 58.88 0.00 63 -1 2 3 358 27.42 1319 2377 4 0 0 0 0 4 0 0.00 0.00 0.00 72.18 0.00 14.64 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2) 2020-04-22 14:12 ` Dave Kleikamp @ 2020-04-22 14:49 ` Giovanni Gherdovich 0 siblings, 0 replies; 12+ messages in thread From: Giovanni Gherdovich @ 2020-04-22 14:49 UTC (permalink / raw) To: Dave Kleikamp, Peter Zijlstra, Linus Torvalds, Harald Arnesen Cc: Ingo Molnar, Rafael J. Wysocki, Linux Kernel Mailing List On Wed, 2020-04-22 at 09:12 -0500, Dave Kleikamp wrote: > On 4/22/20 4:02 AM, Giovanni Gherdovich wrote: > > Linus, Peter: > > > > the panic seen by Harald Arnesen (and Dave Kleikamp) is unrelated to > > virtualization, and happens on all machines that have a CPU with less than 4 > > physical cores. It's a very serious (and very stupid) bug in the original > > version of my code and is fixed by patch 2/4 "x86, sched: Account for CPUs > > with less than 4 cores in freq. invariance" in the series > > > > https://lore.kernel.org/lkml/20200416054745.740-1-ggherdovich@suse.cz > > > > Harald, Dave: > > > > for peace of mind, can you please share the output of > > > > turbostat --interval 1 sleep 0 > > This is a Lenovo T410. > > turbostat version 20.03.20 - Len Brown <lenb@kernel.org> > CPUID(0): GenuineIntel 0xb CPUID levels; 0x80000008 xlevels; family:model:stepping 0x6:25:5 (6:37:5) > [...] > cpu0: MSR_TURBO_RATIO_LIMIT: 0x00001416 > 20 * 133.3 = 2666.6 MHz max turbo 2 active cores > 22 * 133.3 = 2933.3 MHz max turbo 1 active cores 2 cores/ 4 threads, reported 4C turbo frequency of zero (i.e. bits 31:24 in MSR_TURBO_RATIO_LIMIT). This is consistent with all other occurrences of this bug that have been reported. Thanks Dave for your reply. Giovanni ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [BISECTED]: Kernel panic (was: Linux 5.7-rc2) 2020-04-21 19:03 ` [BISECTED]: Kernel panic (was: Linux 5.7-rc2) Linus Torvalds 2020-04-21 21:23 ` Peter Zijlstra @ 2020-04-22 9:32 ` Harald Arnesen 1 sibling, 0 replies; 12+ messages in thread From: Harald Arnesen @ 2020-04-22 9:32 UTC (permalink / raw) To: Linus Torvalds, Peter Zijlstra, Ingo Molnar, Rafael J. Wysocki Cc: Linux Kernel Mailing List, Giovanni Gherdovich Linus Torvalds [21.04.2020 21:03]: > On Mon, Apr 20, 2020 at 1:52 AM Harald Arnesen <harald@skogtun.org> wrote: >> >> Neither rc1 nor rc2 will boot on my laptop. The attached picture is all >> I have been able to capture. > > I know you saw the reply about this probably being fixed by > > https://lore.kernel.org/lkml/20200416054745.740-1-ggherdovich@suse.cz/ > > but it would be lovely if you could actually verify that that series > of four patches does indeed fix it for you. > > Your oops is on that divide instruction: > > freq_scale = div64_u64(acnt, mcnt); > > and while we had a check for mcnt not being zero earlier, we did > > mcnt *= arch_max_freq_ratio; > > after that check. I could see it becoming zero either due to an > overflow, or due to arch_max_freq_ratio being 0. > > I think the first commit in that series is supposed to fix that > arch_max_freq_ratio being 0 case, but it still feels like the code > that does the divide is checking for zero in the wrong place... > > Linus I will try the patches today, and report back. -- Hilsen Harald ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-04-22 14:49 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-19 21:58 Linux 5.7-rc2 Linus Torvalds [not found] ` <428bac87-b6dd-0867-c8f8-622cd606de3e@skogtun.org> 2020-04-21 19:03 ` [BISECTED]: Kernel panic (was: Linux 5.7-rc2) Linus Torvalds 2020-04-21 21:23 ` Peter Zijlstra 2020-04-21 21:30 ` Linus Torvalds 2020-04-21 21:41 ` Peter Zijlstra 2020-04-22 9:02 ` Giovanni Gherdovich 2020-04-22 9:37 ` Harald Arnesen 2020-04-22 10:22 ` Harald Arnesen 2020-04-22 11:01 ` Giovanni Gherdovich 2020-04-22 14:12 ` Dave Kleikamp 2020-04-22 14:49 ` Giovanni Gherdovich 2020-04-22 9:32 ` Harald Arnesen
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).