This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 5.5.8-rc1
Jim Mattson jmattson@google.com kvm: nVMX: VMWRITE checks unsupported field before read-only field
Jim Mattson jmattson@google.com kvm: nVMX: VMWRITE checks VMCS-link pointer before VMCS field
David Rientjes rientjes@google.com mm, thp: fix defrag setting if newline is not used
Wei Yang richardw.yang@linux.intel.com mm/huge_memory.c: use head to check huge zero page
John Hubbard jhubbard@nvidia.com mm/gup: allow FOLL_FORCE for get_user_pages_fast()
Vlastimil Babka vbabka@suse.cz mm/debug.c: always print flags in dump_page()
Waiman Long longman@redhat.com locking/lockdep: Fix lockdep_stats indentation problem
Daniel Jordan daniel.m.jordan@oracle.com padata: always acquire cpu_hotplug_lock before pinst->lock
Christoph Hellwig hch@lst.de xfs: clear kernel only flags in XFS_IOC_ATTRMULTI_BY_HANDLE
Bjorn Andersson bjorn.andersson@linaro.org clk: qcom: rpmh: Sort OF match table
Sameer Pujar spujar@nvidia.com bus: tegra-aconnect: Remove PM_CLK dependency
Matteo Croce mcroce@redhat.com netfilter: nf_flowtable: fix documentation
Xin Long lucien.xin@gmail.com netfilter: nft_tunnel: no need to call htons() when dumping ports
Florian Fainelli f.fainelli@gmail.com thermal: brcmstb_thermal: Do not use DT coefficients
Linus Walleij linus.walleij@linaro.org thermal: db8500: Depromote debug print
Geert Uytterhoeven geert@linux-m68k.org ubifs: Fix ino_t format warnings in orphan_delete()
Neeraj Upadhyay neeraju@codeaurora.org rcu: Allow only one expedited GP to run concurrently with wakeups
Sean Christopherson sean.j.christopherson@intel.com KVM: x86: Remove spurious clearing of async #PF MSR
Sean Christopherson sean.j.christopherson@intel.com KVM: x86: Remove spurious kvm_mmu_unload() from vcpu destruction path
Peter Xu peterx@redhat.com KVM: X86: Fix kvm_bitmap_or_dest_vcpus() to use irq shorthand
Xiaochen Shen xiaochen.shen@intel.com x86/resctrl: Check monitoring static key in the MBM overflow handler
Cengiz Can cengiz@kernel.wtf perf maps: Add missing unlock to maps__insert() error case
Jiri Olsa jolsa@kernel.org perf ui gtk: Add missing zalloc object
Arnaldo Carvalho de Melo acme@redhat.com perf hists browser: Restore ESC as "Zoom out" of DSO/thread/etc
Uwe Kleine-König u.kleine-koenig@pengutronix.de pwm: omap-dmtimer: put_device() after of_find_device_by_node()
Thomas Gleixner tglx@linutronix.de lib/vdso: Update coarse timekeeper unconditionally
Thomas Gleixner tglx@linutronix.de lib/vdso: Make __arch_update_vdso_data() logic understandable
Masami Hiramatsu mhiramat@kernel.org kprobes: Set unoptimized flag after unoptimizing code
Janne Karhunen janne.karhunen@gmail.com ima: ima/lsm policy rule loading logic bug fixes
Christophe JAILLET christophe.jaillet@wanadoo.fr drivers: net: xgene: Fix the order of the arguments of 'alloc_etherdev_mqs()'
Lijun Ou oulijun@huawei.com RDMA/hns: Bugfix for posting a wqe with sge
Yixian Liu liuyixian@huawei.com RDMA/hns: Simplify the calculation and usage of wqe idx for post verbs
Chao Yu chao@kernel.org f2fs: fix to add swap extent correctly
Cheng Jian cj.chengjian@huawei.com sched/fair: Optimize select_idle_cpu
Sean Christopherson sean.j.christopherson@intel.com KVM: Check for a bad hva before dropping into the ghc slow path
Tom Lendacky thomas.lendacky@amd.com KVM: SVM: Override default MMIO mask if memory encryption is enabled
Jin Yao yao.jin@linux.intel.com perf report: Fix no libunwind compiled warning break s390 issue
Brian Norris briannorris@chromium.org mwifiex: delete unused mwifiex_get_intf_num()
Brian Norris briannorris@chromium.org mwifiex: drop most magic numbers from mwifiex_process_tdls_action_frame()
Aleksa Sarai cyphar@cyphar.com namei: only return -ECHILD from follow_dotdot_rcu()
Tuong Lien tuong.t.lien@dektech.com.au tipc: fix successful connect() but timed out
Arthur Kiyanovski akiyano@amazon.com net: ena: make ena rxfh support ETH_RSS_HASH_NO_CHANGE
Ursula Braun ubraun@linux.ibm.com net/smc: no peer ID in CLC decline for SMCD
Michael Ellerman mpe@ellerman.id.au selftests: Install settings files to fix TIMEOUT failures
Dmitry Bogdanov dbogdanov@marvell.com net: atlantic: fix out of range usage of active_vlans array
Pavel Belous pbelous@marvell.com net: atlantic: possible fault in transition to hibernation
Pavel Belous pbelous@marvell.com net: atlantic: fix potential error handling
Pavel Belous pbelous@marvell.com net: atlantic: fix use after free kasan warn
Nikita Danilov ndanilov@marvell.com net: atlantic: better loopback mode handling
Dmitry Bezrukov dbezrukov@marvell.com net: atlantic: checksum compat issue
Nikolay Aleksandrov nikolay@cumulusnetworks.com net: netlink: cap max groups which will be considered in netlink_bind()
Julian Wiedmann jwi@linux.ibm.com s390/qeth: fix off-by-one in RX copybreak check
Alexandra Winter wintera@linux.ibm.com s390/qeth: vnicc Fix EOPNOTSUPP precedence
Bijan Mottahedeh bijan.mottahedeh@oracle.com nvme-pci: Hold cq_poll_lock while completing CQEs
Peter Chen peter.chen@nxp.com usb: charger: assign specific number for enum value
Haiyang Zhang haiyangz@microsoft.com hv_netvsc: Fix unwanted wakeup in netvsc_attach()
Masahiro Yamada masahiroy@kernel.org kbuild: fix DT binding schema rule to detect command line changes
Andrei Otcheretianski andrei.otcheretianski@intel.com mac80211: Remove a redundant mutex unlock
Johannes Berg johannes.berg@intel.com nl80211: fix potential leak in AP start
Tina Zhang tina.zhang@intel.com drm/i915/gvt: Separate display reset from ALL_ENGINES reset
Chris Wilson chris@chris-wilson.co.uk drm/i915: Avoid recursing onto active vma from the shrinker
Tina Zhang tina.zhang@intel.com drm/i915/gvt: Fix orphan vgpu dmabuf_objs' lifetime
Mark Tomlinson mark.tomlinson@alliedtelesis.co.nz MIPS: cavium_octeon: Fix syncw generation.
Wolfram Sang wsa@the-dreams.de i2c: jz4780: silence log flood on txabrt
Gustavo A. R. Silva gustavo@embeddedor.com i2c: altera: Fix potential integer overflow
Oliver Upton oupton@google.com KVM: nVMX: Emulate MTF when performing instruction emulation
Christophe JAILLET christophe.jaillet@wanadoo.fr MIPS: VPE: Fix a double free and a memory leak in 'release_vpe()'
Anup Patel anup.patel@wdc.com RISC-V: Don't enable all interrupts in trap_init()
dan.carpenter@oracle.com dan.carpenter@oracle.com HID: hiddev: Fix race in in hiddev_disconnect()
Christophe JAILLET christophe.jaillet@wanadoo.fr HID: alps: Fix an error handling path in 'alps_input_configured()'
Cong Wang xiyou.wangcong@gmail.com netfilter: xt_hashlimit: reduce hashlimit_mutex scope for htable_put()
Jozsef Kadlecsik kadlec@netfilter.org netfilter: ipset: Fix forceadd evaluation path
Eugenio Pérez eperezma@redhat.com vhost: Check docket sk_family instead of call getname
Ursula Braun ubraun@linux.ibm.com net/smc: transfer fasync_list in case of fallback
Jozsef Kadlecsik kadlec@netfilter.org netfilter: ipset: Fix "INFO: rcu detected stall in hash_xxx" reports
Jens Axboe axboe@kernel.dk io_uring: fix 32-bit compatability with sendmsg/recvmsg
Rafael J. Wysocki rafael.j.wysocki@intel.com cpufreq: Fix policy initialization for internal governor drivers
Shirish S shirish.s@amd.com amdgpu/gmc_v9: save/restore sdpif regs during S3
Orson Zhai orson.unisoc@gmail.com Revert "PM / devfreq: Modify the device name as devfreq(X) for sysfs"
Steven Rostedt (VMware) rostedt@goodmis.org tracing: Disable trace_printk() on post poned tests
Jan Kara jack@suse.cz blktrace: Protect q->blk_trace with RCU
Wolfram Sang wsa@the-dreams.de macintosh: therm_windtunnel: fix regression when instantiating devices
Daniel Vetter daniel.vetter@ffwll.ch drm/radeon: Inline drm_get_pci_dev
Daniel Vetter daniel.vetter@ffwll.ch drm/amdgpu: Drop DRIVER_USE_AGP
Johan Korsnes jkorsnes@cisco.com HID: core: increase HID report buffer size to 8KiB
Johan Korsnes jkorsnes@cisco.com HID: core: fix off-by-one memset in hid_report_raw_event()
Hans de Goede hdegoede@redhat.com HID: ite: Only bind to keyboard USB interface on Acer SW5-012 keyboard dock
Oliver Upton oupton@google.com KVM: VMX: check descriptor table exits on instruction emulation
Mika Westerberg mika.westerberg@linux.intel.com ACPI: watchdog: Fix gas->access_width usage
Mika Westerberg mika.westerberg@linux.intel.com ACPICA: Introduce ACPI_ACCESS_BYTE_WIDTH() macro
Paul Moore paul@paul-moore.com audit: always check the netlink payload length in audit_receive_msg()
Paul Moore paul@paul-moore.com audit: fix error handling in audit_data_to_entry()
Dan Carpenter dan.carpenter@oracle.com ext4: potential crash on allocation error in ext4_alloc_flex_bg_array()
Kees Cook keescook@chromium.org docs: Fix empty parallelism argument
Benjamin Block bblock@linux.ibm.com scsi: zfcp: fix wrong data and display format of SFP+ temperature
Damien Le Moal damien.lemoal@wdc.com scsi: sd_sbc: Fix sd_zbc_report_zones()
Keith Busch kbusch@kernel.org nvme/pci: move cqe check after device shutdown
Nigel Kirkland nigel.kirkland@broadcom.com nvme: prevent warning triggered by nvme_stop_keep_alive
Anton Eidelman anton@lightbitslabs.com nvme/tcp: fix bug on double requeue when send fails
Guangbin Huang huangguangbin2@huawei.com net: hns3: fix a copying IPv6 address error in hclge_fd_get_flow_tuples()
Yonglong Liu liuyonglong@huawei.com net: hns3: fix VF bandwidth does not take effect in some case
Yufeng Mo moyufeng@huawei.com net: hns3: add management table after IMP reset
Shay Bar shay.bar@celeno.com mac80211: fix wrong 160/80+80 MHz setting
Sergey Matyukevich sergey.matyukevich.os@quantenna.com cfg80211: add missing policy for NL80211_ATTR_STATUS_CODE
Coly Li colyli@suse.de bcache: ignore pending signals when creating gc and allocator thread
Frank Sorenson sorenson@redhat.com cifs: Fix mode output in debugging statements
Jens Axboe axboe@kernel.dk io-wq: don't call kXalloc_node() with non-online node
Ben Shelton benjamin.h.shelton@intel.com ice: Use correct netif error function
Anirudh Venkataramanan anirudh.venkataramanan@intel.com ice: Use ice_pf_to_dev
Bruce Allan bruce.w.allan@intel.com ice: update Unit Load Status bitmask to check after reset
Bruce Allan bruce.w.allan@intel.com ice: fix and consolidate logging of NVM/firmware version information
Brett Creeley brett.creeley@intel.com ice: Don't allow same value for Rx tail to be written twice
Dave Ertman david.m.ertman@intel.com ice: Fix switch between FW and SW LLDP
Arthur Kiyanovski akiyano@amazon.com net: ena: ena-com.c: prevent NULL pointer dereference
Sameeh Jubran sameehj@amazon.com net: ena: ethtool: use correct value for crc32 hash
Arthur Kiyanovski akiyano@amazon.com net: ena: fix corruption of dev_idx_to_host_tbl
Arthur Kiyanovski akiyano@amazon.com net: ena: fix incorrectly saving queue numbers when setting RSS indirection table
Arthur Kiyanovski akiyano@amazon.com net: ena: rss: store hash function as values and not bits
Sameeh Jubran sameehj@amazon.com net: ena: rss: fix failure to get indirection table
Sameeh Jubran sameehj@amazon.com net: ena: rss: do not allocate key when not supported
Arthur Kiyanovski akiyano@amazon.com net: ena: fix incorrect default RSS key
Arthur Kiyanovski akiyano@amazon.com net: ena: add missing ethtool TX timestamping indication
Arthur Kiyanovski akiyano@amazon.com net: ena: fix uses of round_jiffies()
Arthur Kiyanovski akiyano@amazon.com net: ena: fix potential crash when rxfh key is NULL
Brett Creeley brett.creeley@intel.com i40e: Fix the conditional for i40e_vc_validate_vqs_bitmaps
Thierry Reding treding@nvidia.com soc/tegra: fuse: Fix build with Tegra194 configuration
Daniel Kolesa daniel@octaforge.org amdgpu: Prevent build errors regarding soft/hard-float FP ABI tags
Isabel Zhang isabel.zhang@amd.com drm/amd/display: Add initialitions for PLL2 clock source
Yongqiang Sun yongqiang.sun@amd.com drm/amd/display: Limit minimum DPPCLK to 100MHz.
Aric Cyr aric.cyr@amd.com drm/amd/display: Check engine is not NULL before acquiring
Krishnamraju Eraparaju krishna2@chelsio.com RDMA/siw: Remove unwanted WARN_ON in siw_cm_llp_data_ready()
Sung Lee sung.lee@amd.com drm/amd/display: Do not set optimized_require to false after plane disable
Kuninori Morimoto kuninori.morimoto.gx@renesas.com ARM: dts: sti: fixup sound frame-inversion for stihxxx-b2120.dtsi
Xiubo Li xiubli@redhat.com ceph: do not execute direct write in parallel if O_APPEND is specified
Kan Liang kan.liang@linux.intel.com perf/x86/msr: Add Tremont support
Kan Liang kan.liang@linux.intel.com perf/x86/cstate: Add Tremont support
Kan Liang kan.liang@linux.intel.com perf/x86/intel: Add Elkhart Lake support
Peter Zijlstra peterz@infradead.org arm/ftrace: Fix BE text poking
John Garry john.garry@huawei.com perf/smmuv3: Use platform_get_irq_optional() for wired interrupt
Trond Myklebust trondmy@gmail.com NFSv4: Fix races between open and dentry revalidation
Bjørn Mork bjorn@mork.no qmi_wwan: unconditionally reject 2 ep interfaces
Bjørn Mork bjorn@mork.no qmi_wwan: re-add DW5821e pre-production variant
Harald Freudenberger freude@linux.ibm.com s390/zcrypt: fix card and queue total counter wrap
Stefano Garzarella sgarzare@redhat.com io_uring: flush overflowed CQ events in the io_uring_poll()
Sergey Matyukevich sergey.matyukevich.os@quantenna.com cfg80211: check wiphy driver existence for drvinfo report
Johannes Berg johannes.berg@intel.com mac80211: consider more elements in parsing CRC
Jeff Moyer jmoyer@redhat.com dax: pass NOWAIT flag to iomap_apply
Vincent Guittot vincent.guittot@linaro.org sched/fair: Prevent unlimited runtime on throttled group
Peter Zijlstra (Intel) peterz@infradead.org timers/nohz: Update NOHZ load in remote tick
Scott Wood swood@redhat.com sched/core: Don't skip remote tick for idle CPUs
Sean Paul seanpaul@chromium.org drm/msm: Set dma maximum segment size for mdss
Corey Minyard cminyard@mvista.com ipmi:ssif: Handle a possible NULL pointer reference
Eric Dumazet edumazet@google.com net: rtnetlink: fix bugs in rtnl_alt_ifname()
Alexandre Belloni alexandre.belloni@bootlin.com net: macb: Properly handle phylink on at91rm9200
Eric Dumazet edumazet@google.com net: add strict checks in netdev_name_node_alt_destroy()
Shannon Nelson snelson@pensando.io ionic: fix fw_status read
Benjamin Poirier bpoirier@cumulusnetworks.com ipv6: Fix nlmsg_flags when splitting a multipath route
Benjamin Poirier bpoirier@cumulusnetworks.com ipv6: Fix route replacement with dev-only route
Taehee Yoo ap420073@gmail.com bonding: fix lockdep warning in bond_get_stats()
Taehee Yoo ap420073@gmail.com net: export netdev_next_lower_dev_rcu()
Taehee Yoo ap420073@gmail.com bonding: add missing netdev_update_lockdep_key()
Vasundhara Volam vasundhara-v.volam@broadcom.com bnxt_en: Issue PCIe FLR in kdump kernel to cleanup pending DMAs.
Vasundhara Volam vasundhara-v.volam@broadcom.com bnxt_en: Improve device shutdown method.
Xin Long lucien.xin@gmail.com sctp: move the format error check out of __sctp_sf_do_9_1_abort
Willem de Bruijn willemb@google.com udp: rehash on disconnect
Paolo Abeni pabeni@redhat.com Revert "net: dev: introduce support for sch BYPASS for lockless qdisc"
Michal Kalderon michal.kalderon@marvell.com qede: Fix race between rdma destroy workqueue and link change event
Dmitry Osipenko digetx@gmail.com nfc: pn544: Fix occasional HW initialization failure
Rohit Maheshwari rohitm@chelsio.com net/tls: Fix to avoid gettig invalid tls record
Jason Baron jbaron@akamai.com net: sched: correct flower port blocking
Arun Parameswaran arun.parameswaran@broadcom.com net: phy: restore mdio regs in the iproc mdio driver
Horatiu Vultur horatiu.vultur@microchip.com net: mscc: fix in frame extraction
Alexandre Belloni alexandre.belloni@bootlin.com net: macb: ensure interface is not suspended on at91rm9200
Jethro Beekman jethro@fortanix.com net: fib_rules: Correctly set table field when table number exceeds 8 bits
Florian Fainelli f.fainelli@gmail.com net: dsa: b53: Ensure the default VID is untagged
Aristeu Rozanski aris@redhat.com EDAC: skx_common: downgrade message importance on missing PCI device
-------------
Diffstat:
Documentation/networking/nf_flowtable.txt | 2 +- Documentation/sphinx/parallel-wrapper.sh | 2 +- Makefile | 4 +- arch/arm/boot/dts/stihxxx-b2120.dtsi | 2 +- arch/arm/include/asm/vdso/vsyscall.h | 4 +- arch/arm/kernel/ftrace.c | 7 +- arch/mips/include/asm/sync.h | 4 +- arch/mips/kernel/vpe.c | 2 +- arch/riscv/kernel/traps.c | 4 +- arch/x86/events/intel/core.c | 1 + arch/x86/events/intel/cstate.c | 22 +- arch/x86/events/msr.c | 3 +- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/include/uapi/asm/kvm.h | 1 + arch/x86/kernel/cpu/resctrl/internal.h | 1 + arch/x86/kernel/cpu/resctrl/monitor.c | 4 +- arch/x86/kvm/lapic.c | 2 +- arch/x86/kvm/svm.c | 44 ++ arch/x86/kvm/vmx/nested.c | 105 ++-- arch/x86/kvm/vmx/nested.h | 5 + arch/x86/kvm/vmx/vmx.c | 52 +- arch/x86/kvm/vmx/vmx.h | 3 + arch/x86/kvm/x86.c | 8 +- drivers/acpi/acpi_watchdog.c | 3 +- drivers/bus/Kconfig | 1 - drivers/char/ipmi/ipmi_ssif.c | 10 +- drivers/clk/qcom/clk-rpmh.c | 2 +- drivers/cpufreq/cpufreq.c | 12 +- drivers/devfreq/devfreq.c | 4 +- drivers/edac/skx_common.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 1 + drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 37 +- drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile | 6 + .../drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 6 + drivers/gpu/drm/amd/display/dc/dce/dce_aux.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 1 - .../gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 6 + .../drm/amd/include/asic_reg/dce/dce_12_0_offset.h | 2 + drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 4 +- drivers/gpu/drm/i915/gvt/dmabuf.c | 2 +- drivers/gpu/drm/i915/gvt/vgpu.c | 2 +- drivers/gpu/drm/msm/msm_drv.c | 8 + drivers/gpu/drm/radeon/radeon_drv.c | 43 +- drivers/gpu/drm/radeon/radeon_kms.c | 6 + drivers/hid/hid-alps.c | 2 +- drivers/hid/hid-core.c | 4 +- drivers/hid/hid-ite.c | 5 +- drivers/hid/usbhid/hiddev.c | 2 +- drivers/i2c/busses/i2c-altera.c | 2 +- drivers/i2c/busses/i2c-jz4780.c | 36 +- drivers/infiniband/hw/hns/hns_roce_device.h | 3 +- drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 37 +- drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 80 +-- drivers/infiniband/sw/siw/siw_cm.c | 5 +- drivers/macintosh/therm_windtunnel.c | 52 +- drivers/md/bcache/alloc.c | 18 +- drivers/md/bcache/btree.c | 13 + drivers/net/bonding/bond_main.c | 55 +- drivers/net/bonding/bond_options.c | 2 + drivers/net/dsa/b53/b53_common.c | 3 + drivers/net/ethernet/amazon/ena/ena_com.c | 96 ++-- drivers/net/ethernet/amazon/ena/ena_com.h | 9 + drivers/net/ethernet/amazon/ena/ena_ethtool.c | 46 +- drivers/net/ethernet/amazon/ena/ena_netdev.c | 6 +- drivers/net/ethernet/amazon/ena/ena_netdev.h | 2 + drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 2 +- .../net/ethernet/aquantia/atlantic/aq_ethtool.c | 5 + .../net/ethernet/aquantia/atlantic/aq_filters.c | 2 +- drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 8 +- .../net/ethernet/aquantia/atlantic/aq_pci_func.c | 13 +- drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 10 +- drivers/net/ethernet/aquantia/atlantic/aq_ring.h | 3 +- .../ethernet/aquantia/atlantic/hw_atl/hw_atl_b0.c | 18 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 12 +- drivers/net/ethernet/cadence/macb.h | 1 + drivers/net/ethernet/cadence/macb_main.c | 66 ++- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 22 +- .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 4 +- drivers/net/ethernet/intel/ice/ice_base.c | 12 +- drivers/net/ethernet/intel/ice/ice_common.c | 17 +- drivers/net/ethernet/intel/ice/ice_dcb_nl.c | 12 +- drivers/net/ethernet/intel/ice/ice_ethtool.c | 17 +- drivers/net/ethernet/intel/ice/ice_hw_autogen.h | 6 + drivers/net/ethernet/intel/ice/ice_lib.c | 33 +- drivers/net/ethernet/intel/ice/ice_lib.h | 2 - drivers/net/ethernet/intel/ice/ice_main.c | 23 +- drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 2 +- drivers/net/ethernet/intel/ice/ice_virtchnl_pf.c | 8 +- drivers/net/ethernet/mscc/ocelot_board.c | 8 + drivers/net/ethernet/pensando/ionic/ionic_dev.c | 11 +- drivers/net/ethernet/pensando/ionic/ionic_if.h | 1 + drivers/net/ethernet/qlogic/qede/qede.h | 2 + drivers/net/ethernet/qlogic/qede/qede_rdma.c | 29 +- drivers/net/hyperv/netvsc.c | 2 +- drivers/net/hyperv/netvsc_drv.c | 3 + drivers/net/phy/mdio-bcm-iproc.c | 20 + drivers/net/usb/qmi_wwan.c | 43 +- drivers/net/wireless/marvell/mwifiex/main.h | 13 - drivers/net/wireless/marvell/mwifiex/tdls.c | 75 +-- drivers/nfc/pn544/i2c.c | 1 + drivers/nvme/host/core.c | 10 +- drivers/nvme/host/pci.c | 25 +- drivers/nvme/host/rdma.c | 2 +- drivers/nvme/host/tcp.c | 9 +- drivers/perf/arm_smmuv3_pmu.c | 2 +- drivers/pwm/pwm-omap-dmtimer.c | 21 +- drivers/s390/crypto/ap_bus.h | 4 +- drivers/s390/crypto/ap_card.c | 8 +- drivers/s390/crypto/ap_queue.c | 6 +- drivers/s390/crypto/zcrypt_api.c | 16 +- drivers/s390/net/qeth_core_main.c | 2 +- drivers/s390/net/qeth_l2_main.c | 29 +- drivers/s390/scsi/zfcp_fsf.h | 2 +- drivers/s390/scsi/zfcp_sysfs.c | 2 +- drivers/scsi/sd_zbc.c | 7 +- drivers/soc/tegra/fuse/fuse-tegra30.c | 3 +- drivers/thermal/broadcom/brcmstb_thermal.c | 31 +- drivers/thermal/db8500_thermal.c | 4 +- drivers/vhost/net.c | 10 +- drivers/watchdog/wdat_wdt.c | 2 +- fs/ceph/file.c | 17 +- fs/cifs/cifsacl.c | 4 +- fs/cifs/connect.c | 2 +- fs/cifs/inode.c | 2 +- fs/dax.c | 3 + fs/ext4/super.c | 6 +- fs/f2fs/data.c | 32 +- fs/io-wq.c | 22 +- fs/io_uring.c | 12 +- fs/namei.c | 2 +- fs/nfs/nfs4file.c | 1 - fs/nfs/nfs4proc.c | 18 +- fs/ubifs/orphan.c | 4 +- fs/xfs/libxfs/xfs_attr.h | 7 +- fs/xfs/xfs_ioctl.c | 2 + fs/xfs/xfs_ioctl32.c | 2 + include/acpi/actypes.h | 3 +- include/asm-generic/vdso/vsyscall.h | 4 +- include/linux/blkdev.h | 2 +- include/linux/blktrace_api.h | 18 +- include/linux/hid.h | 2 +- include/linux/netdevice.h | 7 +- include/linux/netfilter/ipset/ip_set.h | 11 +- include/linux/sched/nohz.h | 2 + include/net/flow_dissector.h | 9 + include/uapi/linux/usb/charger.h | 16 +- kernel/audit.c | 40 +- kernel/auditfilter.c | 71 +-- kernel/kprobes.c | 4 +- kernel/locking/lockdep_proc.c | 4 +- kernel/padata.c | 4 +- kernel/rcu/tree_exp.h | 11 +- kernel/sched/core.c | 31 +- kernel/sched/fair.c | 7 +- kernel/sched/loadavg.c | 33 +- kernel/time/vsyscall.c | 37 +- kernel/trace/blktrace.c | 114 +++- kernel/trace/trace.c | 2 + mm/debug.c | 8 +- mm/gup.c | 3 +- mm/huge_memory.c | 26 +- net/core/dev.c | 34 +- net/core/fib_rules.c | 2 +- net/core/rtnetlink.c | 26 +- net/ipv4/udp.c | 6 +- net/ipv6/ip6_fib.c | 7 +- net/ipv6/route.c | 1 + net/mac80211/mlme.c | 6 +- net/mac80211/util.c | 34 +- net/netfilter/ipset/ip_set_core.c | 34 +- net/netfilter/ipset/ip_set_hash_gen.h | 635 ++++++++++++++------- net/netfilter/nft_tunnel.c | 4 +- net/netfilter/xt_hashlimit.c | 12 +- net/netlink/af_netlink.c | 5 +- net/sched/cls_flower.c | 1 + net/sctp/sm_statefuns.c | 29 +- net/smc/af_smc.c | 2 + net/smc/smc_clc.c | 4 +- net/tipc/socket.c | 2 + net/tls/tls_device.c | 20 +- net/wireless/ethtool.c | 8 +- net/wireless/nl80211.c | 5 +- scripts/Makefile.lib | 4 +- security/integrity/ima/ima_policy.c | 44 +- tools/perf/builtin-report.c | 6 +- tools/perf/ui/browsers/hists.c | 1 + tools/perf/ui/gtk/Build | 5 + tools/perf/util/map.c | 1 + tools/testing/selftests/ftrace/Makefile | 2 +- tools/testing/selftests/livepatch/Makefile | 2 + tools/testing/selftests/net/fib_tests.sh | 6 + tools/testing/selftests/rseq/Makefile | 2 + tools/testing/selftests/rtc/Makefile | 2 + virt/kvm/kvm_main.c | 12 +- 196 files changed, 2077 insertions(+), 1118 deletions(-)
On 03/03/2020 17:41, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y and the diffstat can be found below.
thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.5: 13 builds: 13 pass, 0 fail 22 boots: 22 pass, 0 fail 40 tests: 40 pass, 0 fail
Linux version: 5.5.8-rc1-g3517b32c0774 Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04
Cheers Jon
On Tue, Mar 03, 2020 at 10:11:19PM +0000, Jon Hunter wrote:
On 03/03/2020 17:41, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y and the diffstat can be found below.
thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.5: 13 builds: 13 pass, 0 fail 22 boots: 22 pass, 0 fail 40 tests: 40 pass, 0 fail
Linux version: 5.5.8-rc1-g3517b32c0774 Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04
thanks for testing all of these and letting me know.
greg k-h
On 3/3/20 10:41 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks, -- Shuah
On Tue, Mar 03, 2020 at 04:01:34PM -0700, shuah wrote:
On 3/3/20 10:41 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Great, thanks for testing these and letting me know.
greg k-h
On Tue, 3 Mar 2020 at 23:16, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. Regressions detected on x86_64 and i386.
Test failure output: CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)
Test description: CVE-2017-5715 branch target injection (Spectre Variant 2)
Impact: Kernel Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors) Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU
ref: https://github.com/speed47/spectre-meltdown-checker https://qa-reports.linaro.org/lkft/linux-stable-rc-5.5-oe/tests/spectre-melt... https://lkft.validation.linaro.org/scheduler/job/1264643#L21206
Summary ------------------------------------------------------------------------
kernel: 5.5.8-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.5.y git commit: 3517b32c0774341d492140b2be08c4bf6d1a833e git describe: v5.5.7-177-g3517b32c0774 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.5-oe/build/v5.5.7-177-g...
Regressions (compared to build v5.5.7) ------------------------------------------------------------------------
i386: spectre-meltdown-checker-test: * CVE-2017-5715
x86: spectre-meltdown-checker-test: * CVE-2017-5715
No fixes (compared to build v5.5.7)
Ran 25662 total tests in the following environments and test suites.
Environments -------------- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - nxp-ls2088 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86
Test Suites ----------- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * linux-log-parser * perf * ltp-cap_bounds-tests * ltp-cpuhotplug-tests * ltp-fcntl-locktests-tests * ltp-fs-tests * ltp-ipc-tests * ltp-sched-tests * network-basic-tests * kvm-unit-tests * libhugetlbfs * ltp-commands-tests * ltp-containers-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-m[ * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * ltp-syscalls-tests * spectre-meltdown-checker-test * v4l2-compliance * ltp-cap_bounds-64k-page_size-tests * ltp-cap_bounds-kasan-tests * ltp-commands-64k-page_size-tests * ltp-commands-kasan-tests * ltp-containers-64k-page_size-tests * ltp-containers-kasan-tests * ltp-cpuhotplug-64k-page_size-tests * ltp-cpuhotplug-kasan-tests * ltp-crypto-64k-page_size-tests * ltp-crypto-kasan-tests * ltp-cve-64k-page_size-tests * ltp-cve-kasan-tests * ltp-dio-64k-page_size-tests * ltp-dio-kasan-tests * ltp-fcntl-locktests-64k-page_size-tests * ltp-fcntl-locktests-kasan-tests * ltp-filecaps-64k-page_size-tests * ltp-filecaps-kasan-tests * ltp-fs-64k-page_size-tests * ltp-fs-kasan-tests * ltp-fs_bind-64k-page_size-tests * ltp-fs_bind-kasan-tests * ltp-fs_perms_simple-64k-page_size-tests * ltp-fs_perms_simple-kasan-tests * ltp-fsx-64k-page_size-tests * ltp-fsx-kasan-tests * ltp-hugetlb-64k-page_size-tests * ltp-hugetlb-kasan-tests * ltp-io-64k-page_size-tests * ltp-io-kasan-tests * ltp-ipc-64k-page_size-tests * ltp-ipc-kasan-tests * ltp-math-64k-page_size-tests * ltp-math-kasan-tests * ltp-math-tests * ltp-mm-64k-page_size-tests * ltp-mm-kasan-tests * ltp-nptl-64k-page_size-tests * ltp-nptl-kasan-tests * ltp-pty-64k-page_size-tests * ltp-pty-kasan-tests * ltp-sched-64k-page_size-tests * ltp-sched-kasan-tests * ltp-securebits-64k-page_size-tests * ltp-securebits-kasan-tests * ltp-syscalls-64k-page_size-tests * ltp-syscalls-compat-tests * ltp-syscalls-kasan-tests * ltp-open-posix-tests * ssuite * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none
On Wed, Mar 04, 2020 at 12:43:42PM +0530, Naresh Kamboju wrote:
On Tue, 3 Mar 2020 at 23:16, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. Regressions detected on x86_64 and i386.
Test failure output: CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)
Test description: CVE-2017-5715 branch target injection (Spectre Variant 2)
Impact: Kernel Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors) Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU
So these are regressions or just new tests?
If regressions, can you do 'git bisect' to find the offending commit?
Also, are you sure you have an updated microcode on these machines and a proper compiler for retpoline?
thanks,
greg k-h
On Wed, Mar 04, 2020 at 09:11:28AM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 04, 2020 at 12:43:42PM +0530, Naresh Kamboju wrote:
On Tue, 3 Mar 2020 at 23:16, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. Regressions detected on x86_64 and i386.
Test failure output: CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)
Test description: CVE-2017-5715 branch target injection (Spectre Variant 2)
Impact: Kernel Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors) Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU
So these are regressions or just new tests?
If regressions, can you do 'git bisect' to find the offending commit?
Also, are you sure you have an updated microcode on these machines and a proper compiler for retpoline?
As an example of just how crazy that script is, here's the output of my machine for that first CVE issue:
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection' * Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling) * Mitigation 1 * Kernel is compiled with IBRS support: YES * IBRS enabled and active: YES (for firmware code only) * Kernel is compiled with IBPB support: YES * IBPB enabled and active: YES * Mitigation 2 * Kernel has branch predictor hardening (arm): NO * Kernel compiled with retpoline option: YES * Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation) * Kernel supports RSB filling: UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))
STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate
So why is this "Vulnerable"? Because it didn't think it could find my kernel image for some odd reason, despite it really being in /boot/ (I don't use netboot)
So please verify that this really is a real issue, and not just the script doing foolish things.
thanks,
greg k-h
On Wed, Mar 04, 2020 at 09:47:02AM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 04, 2020 at 09:11:28AM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 04, 2020 at 12:43:42PM +0530, Naresh Kamboju wrote:
On Tue, 3 Mar 2020 at 23:16, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. Regressions detected on x86_64 and i386.
Test failure output: CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)
Test description: CVE-2017-5715 branch target injection (Spectre Variant 2)
Impact: Kernel Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors) Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU
So these are regressions or just new tests?
If regressions, can you do 'git bisect' to find the offending commit?
Also, are you sure you have an updated microcode on these machines and a proper compiler for retpoline?
As an example of just how crazy that script is, here's the output of my machine for that first CVE issue:
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
- Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling)
- Mitigation 1
- Kernel is compiled with IBRS support: YES
- IBRS enabled and active: YES (for firmware code only)
- Kernel is compiled with IBPB support: YES
- IBPB enabled and active: YES
- Mitigation 2
- Kernel has branch predictor hardening (arm): NO
- Kernel compiled with retpoline option: YES
- Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
- Kernel supports RSB filling: UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))
STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate
So why is this "Vulnerable"? Because it didn't think it could find my kernel image for some odd reason, despite it really being in /boot/ (I don't use netboot)
So please verify that this really is a real issue, and not just the script doing foolish things.
And, if I tell the script where my kernel image is, suddenly all is good:
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection' * Mitigation 1 * Kernel is compiled with IBRS support: YES * IBRS enabled and active: N/A (not testable in offline mode) * Kernel is compiled with IBPB support: YES * IBPB enabled and active: N/A (not testable in offline mode) * Mitigation 2 * Kernel has branch predictor hardening (arm): UNKNOWN * Kernel compiled with retpoline option: UNKNOWN (couldn't read your kernel configuration) * Kernel supports RSB filling: YES
STATUS: NOT VULNERABLE (offline mode: kernel supports IBRS + IBPB to mitigate the vulnerability)
On Wed, 4 Mar 2020 at 14:19, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, Mar 04, 2020 at 09:47:02AM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 04, 2020 at 09:11:28AM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 04, 2020 at 12:43:42PM +0530, Naresh Kamboju wrote:
On Tue, 3 Mar 2020 at 23:16, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. Regressions detected on x86_64 and i386.
Test failure output: CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)
Test description: CVE-2017-5715 branch target injection (Spectre Variant 2)
Impact: Kernel Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors) Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU
So these are regressions or just new tests?
If regressions, can you do 'git bisect' to find the offending commit?
Also, are you sure you have an updated microcode on these machines and a proper compiler for retpoline?
As an example of just how crazy that script is, here's the output of my machine for that first CVE issue:
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
- Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling)
- Mitigation 1
- Kernel is compiled with IBRS support: YES
- IBRS enabled and active: YES (for firmware code only)
- Kernel is compiled with IBPB support: YES
- IBPB enabled and active: YES
- Mitigation 2
- Kernel has branch predictor hardening (arm): NO
- Kernel compiled with retpoline option: YES
- Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
- Kernel supports RSB filling: UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))
STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate
So why is this "Vulnerable"? Because it didn't think it could find my kernel image for some odd reason, despite it really being in /boot/ (I don't use netboot)
Now I know the real reason why this test failed. With this note we can conclude this is not a regression.
No regressions on arm64, arm, x86_64, and i386 for 4.19, 5.4 and 5.5 branches.
Sorry for the noise.
On Wed, Mar 04, 2020 at 04:22:30PM +0530, Naresh Kamboju wrote:
On Wed, 4 Mar 2020 at 14:19, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, Mar 04, 2020 at 09:47:02AM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 04, 2020 at 09:11:28AM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 04, 2020 at 12:43:42PM +0530, Naresh Kamboju wrote:
On Tue, 3 Mar 2020 at 23:16, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.8-rc1.g... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. Regressions detected on x86_64 and i386.
Test failure output: CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate the vulnerability)
Test description: CVE-2017-5715 branch target injection (Spectre Variant 2)
Impact: Kernel Mitigation 1: new opcode via microcode update that should be used by up to date compilers to protect the BTB (by flushing indirect branch predictors) Mitigation 2: introducing "retpoline" into compilers, and recompile software/OS with it Performance impact of the mitigation: high for mitigation 1, medium for mitigation 2, depending on your CPU
So these are regressions or just new tests?
If regressions, can you do 'git bisect' to find the offending commit?
Also, are you sure you have an updated microcode on these machines and a proper compiler for retpoline?
As an example of just how crazy that script is, here's the output of my machine for that first CVE issue:
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
- Mitigated according to the /sys interface: YES (Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling)
- Mitigation 1
- Kernel is compiled with IBRS support: YES
- IBRS enabled and active: YES (for firmware code only)
- Kernel is compiled with IBPB support: YES
- IBPB enabled and active: YES
- Mitigation 2
- Kernel has branch predictor hardening (arm): NO
- Kernel compiled with retpoline option: YES
- Kernel compiled with a retpoline-aware compiler: YES (kernel reports full retpoline compilation)
- Kernel supports RSB filling: UNKNOWN (couldn't check (couldn't find your kernel image in /boot, if you used netboot, this is normal))
STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB+RSB filling, is needed to mitigate
So why is this "Vulnerable"? Because it didn't think it could find my kernel image for some odd reason, despite it really being in /boot/ (I don't use netboot)
Now I know the real reason why this test failed. With this note we can conclude this is not a regression.
No regressions on arm64, arm, x86_64, and i386 for 4.19, 5.4 and 5.5 branches.
Great, thanks for confirming and for testing all of these.
greg k-h
On Wed, Mar 04, 2020 at 12:52:32PM +0100, Greg Kroah-Hartman wrote:
On Wed, Mar 04, 2020 at 04:22:30PM +0530, Naresh Kamboju wrote:
So why is this "Vulnerable"? Because it didn't think it could find my kernel image for some odd reason, despite it really being in /boot/ (I don't use netboot)
Now I know the real reason why this test failed. With this note we can conclude this is not a regression.
No regressions on arm64, arm, x86_64, and i386 for 4.19, 5.4 and 5.5 branches.
Great, thanks for confirming and for testing all of these.
We originally added spectre-meltdown-checker to lkft for informational purposes, so that we could compare its report to any actual tests that produce spectre/meltdown related failures (and help determine if the problem is hardware/firmware or kernel). In practice, it's never been helpful (because it's not an actual test) and so we'll be removing it from LKFT.
Dan
greg k-h
On Tue, Mar 03, 2020 at 06:41:04PM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
Build results: total: 157 pass: 157 fail: 0 Qemu test results: total: 423 pass: 423 fail: 0
Guenter
On Wed, Mar 04, 2020 at 08:53:12AM -0800, Guenter Roeck wrote:
On Tue, Mar 03, 2020 at 06:41:04PM +0100, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.5.8 release. There are 176 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Thu, 05 Mar 2020 17:42:06 +0000. Anything received after that time might be too late.
Build results: total: 157 pass: 157 fail: 0 Qemu test results: total: 423 pass: 423 fail: 0
Wonderful, thanks for testing these and letting me konw.
greg k-h