Merge remote-tracking branch 'hwmon-staging/hwmon-next'

Merge remote-tracking branch 'dmi/dmi-for-next'

Merge remote-tracking branch 'i3c/i3c/next'

Merge remote-tracking branch 'i2c/i2c/for-next'

Merge remote-tracking branch 'hid/for-next'

Merge remote-tracking branch 'pstore/for-next/pstore'

Merge remote-tracking branch 'pci/next'

Merge remote-tracking branch 'printk/for-next'

Merge remote-tracking branch 'vfs/for-next'

# Conflicts:
# fs/btrfs/ioctl.c
# fs/overlayfs/file.c
# fs/xfs/xfs_ioctl.c

Merge remote-tracking branch 'file-locks/locks-next'

Merge remote-tracking branch 'iomap/iomap-for-next'

Merge remote-tracking branch 'xfs/for-next'

Merge remote-tracking branch 'v9fs/9p-next'

Merge remote-tracking branch 'overlayfs/overlayfs-next'

Merge remote-tracking branch 'cel/for-next'

Merge remote-tracking branch 'jfs/jfs-next'

Merge remote-tracking branch 'fuse/for-next'

Merge remote-tracking branch 'f2fs/dev'

Merge remote-tracking branch 'ext4/dev'

Merge remote-tracking branch 'ext3/for_next'

Merge remote-tracking branch 'exfat/dev'

Merge remote-tracking branch 'erofs/dev'

Merge remote-tracking branch 'ecryptfs/next'

Merge remote-tracking branch 'cifsd/cifsd-for-next'

Merge remote-tracking branch 'cifs/for-next'

Merge remote-tracking branch 'btrfs/for-next'

Merge remote-tracking branch 'fscache/fscache-next'

Merge remote-tracking branch 'pidfd/for-next'

Merge remote-tracking branch 'xtensa/xtensa-for-next'

Merge remote-tracking branch 'sh/for-next'

Merge remote-tracking branch 's390/for-next'

Merge remote-tracking branch 'risc-v/for-next'

Merge remote-tracking branch 'powerpc/next'

Merge remote-tracking branch 'parisc-hd/for-next'

Merge remote-tracking branch 'mips/mips-next'

Merge remote-tracking branch 'microblaze/next'

Merge remote-tracking branch 'm68knommu/for-next'

Merge remote-tracking branch 'm68k/for-next'

Merge remote-tracking branch 'h8300/h8300-next'

Merge remote-tracking branch 'csky/linux-next'

Merge remote-tracking branch 'clk/clk-next'

Merge remote-tracking branch 'ti-k3/ti-k3-next'

Merge remote-tracking branch 'tegra/for-next'

Merge remote-tracking branch 'sunxi/sunxi/for-next'

Merge remote-tracking branch 'scmi/for-linux-next'

Merge remote-tracking branch 'samsung-krzk/for-next'

Merge remote-tracking branch 'rockchip/for-next'

Merge remote-tracking branch 'reset/reset/next'

Merge remote-tracking branch 'renesas/next'

Merge remote-tracking branch 'realtek/for-next'

Merge remote-tracking branch 'raspberrypi/for-next'

# Conflicts:
# arch/arm/boot/dts/bcm2711.dtsi

Merge remote-tracking branch 'qcom/for-next'

Merge remote-tracking branch 'omap/for-next'

Merge remote-tracking branch 'mvebu/for-next'

Merge remote-tracking branch 'mediatek/for-next'

Merge remote-tracking branch 'keystone/next'

Merge remote-tracking branch 'imx-mxs/for-next'

Merge remote-tracking branch 'drivers-memory/for-next'

Merge remote-tracking branch 'at91/at91-next'

Merge remote-tracking branch 'aspeed/for-next'

Merge remote-tracking branch 'amlogic/for-next'

Merge remote-tracking branch 'actions/for-next'

Merge remote-tracking branch 'arm-soc/for-next'

Merge remote-tracking branch 'arm64/for-next/core'

# Conflicts:
# arch/arm64/include/asm/cpucaps.h

Merge remote-tracking branch 'arm/for-next'

Merge remote-tracking branch 'asm-generic/master'

hwmon: (intel-m10-bmc-hwmon) add sensor support of Intel D5005 card

Like the Intel N3000 card, the Intel D5005 has a MAX10 based
BMC.  This commit adds support for the D5005 sensors that are
monitored by the MAX10 BMC.

Signed-off-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
Signed-off-by: Russ Weight <russell.h.weight@linux.intel.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20210413225835.459662-3-matthew.gerlach@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>

Merge remote-tracking branch 'dma-mapping/for-next'

Merge remote-tracking branch 'kbuild/for-next'

Merge remote-tracking branch 'pinctrl-intel-fixes/fixes'

Merge remote-tracking branch 'gpio-brgl-fixes/gpio/for-current'

Merge remote-tracking branch 'pidfd-fixes/fixes'

Merge remote-tracking branch 'risc-v-fixes/fixes'

Merge remote-tracking branch 'rtc-fixes/rtc-fixes'

Merge remote-tracking branch 'drm-intel-fixes/for-linux-next-fixes'

Merge remote-tracking branch 'scsi-fixes/fixes'

Merge remote-tracking branch 'btrfs-fixes/next-fixes'

Merge remote-tracking branch 'nvdimm-fixes/libnvdimm-fixes'

Merge remote-tracking branch 'kvm-fixes/master'

Merge remote-tracking branch 'v4l-dvb-fixes/fixes'

Merge remote-tracking branch 'dmaengine-fixes/fixes'

Merge remote-tracking branch 'vfio-fixes/for-linus'

Merge remote-tracking branch 'ide/master'

Merge remote-tracking branch 'input-current/for-linus'

Merge remote-tracking branch 'soundwire-fixes/fixes'

Merge remote-tracking branch 'phy/fixes'

Merge remote-tracking branch 'pci-current/for-linus'

Merge remote-tracking branch 'spi-fixes/for-linus'

Merge remote-tracking branch 'regulator-fixes/for-linus'

Merge remote-tracking branch 'regmap-fixes/for-linus'

Merge remote-tracking branch 'sound-asoc-fixes/for-linus'

Merge remote-tracking branch 'bpf/master'

Merge remote-tracking branch 'net/master'

Merge remote-tracking branch 's390-fixes/fixes'

Merge remote-tracking branch 'arm-soc-fixes/arm/fixes'

Merge remote-tracking branch 'arm64-fixes/for-next/fixes'

Merge remote-tracking branch 'arm-current/fixes'

Merge remote-tracking branch 'arc-current/for-curr'

xen-netback: Check for hotplug-status existence before watching

The logic in connect() is currently written with the assumption that
xenbus_watch_pathfmt() will return an error for a node that does not
exist.  This assumption is incorrect: xenstore does allow a watch to
be registered for a nonexistent node (and will send notifications
should the node be subsequently created).

As of commit 1f2565780 ("xen-netback: remove 'hotplug-status' once it
has served its purpose"), this leads to a failure when a domU
transitions into XenbusStateConnected more than once.  On the first
domU transition into Connected state, the "hotplug-status" node will
be deleted by the hotplug_status_changed() callback in dom0.  On the
second or subsequent domU transition into Connected state, the
hotplug_status_changed() callback will therefore never be invoked, and
so the backend will remain stuck in InitWait.

This failure prevents scenarios such as reloading the xen-netfront
module within a domU, or booting a domU via iPXE.  There is
unfortunately no way for the domU to work around this dom0 bug.

Fix by explicitly checking for existence of the "hotplug-status" node,
thereby creating the behaviour that was previously assumed to exist.

Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

KVM: VMX: Don't use vcpu->run->internal.ndata as an array index

__vmx_handle_exit() uses vcpu->run->internal.ndata as an index for
an array access.  Since vcpu->run is (can be) mapped to a user address
space with a writer permission, the 'ndata' could be updated by the
user process at anytime (the user process can set it to outside the
bounds of the array).
So, it is not safe that __vmx_handle_exit() uses the 'ndata' that way.

Fixes: 1aa561b1a4c0 ("kvm: x86: Add "last CPU" to some KVM_EXIT information")
Signed-off-by: Reiji Watanabe <reijiw@google.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Message-Id: <20210413154739.490299-1-reijiw@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>