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