xen/gntdev: Ignore failure to unmap INVALID_GRANT_HANDLE
The error paths of gntdev_mmap() can call unmap_grant_pages() even
though not all of the pages have been successfully mapped. This will
trigger the WARN_ON()s in __unmap_grant_pages_done(). The number of
warnings can be very large; I have observed thousands of lines of
warnings in the systemd journal.
Avoid this problem by only warning on unmapping failure if the handle
being unmapped is not INVALID_GRANT_HANDLE. The handle field of any
page that was not successfully mapped will be INVALID_GRANT_HANDLE, so
this catches all cases where unmapping can legitimately fail.
Dan Carpenter [Fri, 8 Jul 2022 09:41:04 +0000 (12:41 +0300)]
drm/i915/selftests: fix a couple IS_ERR() vs NULL tests
The shmem_pin_map() function doesn't return error pointers, it returns
NULL.
Fixes: be1cb55a07bf ("drm/i915/gt: Keep a no-frills swappable copy of the default context state") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220708094104.GL2316@kadam
Michael Walle [Wed, 6 Jul 2022 15:15:52 +0000 (17:15 +0200)]
genirq: Allow irq_set_chip_handler_name_locked() to take a const irq_chip
Similar to commit 393e1280f765 ("genirq: Allow irq_chip registration
functions to take a const irq_chip"), allow the
irq_set_chip_handler_name_locked() function to take a const irq_chip
argument.
Andre Przywara [Fri, 8 Jul 2022 10:52:32 +0000 (11:52 +0100)]
dt-bindings: pinctrl: sunxi: allow vcc-pi-supply
The Allwinner H616 SoC contains a VCC_PI pin, which supplies the voltage
for GPIO port I.
Extend the range of supply port names to include vcc-pi-supply to cover
that.
Andre Przywara [Fri, 8 Jul 2022 10:52:30 +0000 (11:52 +0100)]
dt-bindings: pinctrl: sunxi: Make interrupts optional
The R_PIO pinctrl device on the Allwinner H616 SoC does not have an
interrupt (it features only two pins).
However the binding requires at least naming one upstream interrupt,
plus the #interrupt-cells and interrupt-controller properties.
Drop the unconditional requirement for the interrupt properties, and
make them dependent on being not this particular pinctrl device.
Felix Fietkau [Sat, 2 Jul 2022 14:52:27 +0000 (16:52 +0200)]
wifi: mac80211: fix queue selection for mesh/OCB interfaces
When using iTXQ, the code assumes that there is only one vif queue for
broadcast packets, using the BE queue. Allowing non-BE queue marking
violates that assumption and txq->ac == skb_queue_mapping is no longer
guaranteed. This can cause issues with queue handling in the driver and
also causes issues with the recent ATF change, resulting in an AQL
underflow warning.
The GIC user offset is mapped into every process' virtual address and is
therefore part of the hot-path of arch_setup_additional_pages(). Utilize
__pa() such that we are more optimal even when CONFIG_DEBUG_VIRTUAL is
enabled, and while at it utilize PFN_DOWN() instead of open-coding the
right shift by PAGE_SHIFT.
Jianlong Huang [Mon, 27 Jun 2022 08:53:33 +0000 (10:53 +0200)]
pinctrl: starfive: Serialize adding groups and functions
The pinctrl dt_node_to_map method may be called in parallel which leads
us to call pinconf_generic_add_group and pinconf_generic_add_function
in parallel. This is not supported though and leads to errors, so add a
mutex to serialize these calls.
coresight: etm4x: avoid build failure with unrolled loops
When the following configs are enabled:
* CORESIGHT
* CORESIGHT_SOURCE_ETM4X
* UBSAN
* UBSAN_TRAP
Clang fails assemble the kernel with the error:
<instantiation>:1:7: error: expected constant expression in '.inst' directive
.inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8))
^
drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in
macro instantiation
etm4x_relaxed_read32(csa, TRCCNTVRn(i));
^
drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from
macro 'etm4x_relaxed_read32'
read_etm4x_sysreg_offset((offset), false)))
^
drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded
from macro 'read_etm4x_sysreg_offset'
__val = read_etm4x_sysreg_const_offset((offset)); \
^
drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from
macro 'read_etm4x_sysreg_const_offset'
READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset))
^
drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from
macro 'READ_ETM4x_REG'
read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg)))
^
arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro
'read_sysreg_s'
asm volatile(__mrs_s("%0", r) : "=r" (__val)); \
^
arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s'
" mrs_s " v ", " __stringify(r) "\n" \
^
Consider the definitions of TRCSSCSRn and TRCCNTVRn:
drivers/hwtracing/coresight/coresight-etm4x.h:56
#define TRCCNTVRn(n) (0x160 + (n * 4))
drivers/hwtracing/coresight/coresight-etm4x.h:81
#define TRCSSCSRn(n) (0x2A0 + (n * 4))
Where the macro parameter is expanded to i; a loop induction variable
from etm4_disable_hw.
When any compiler can determine that loops may be unrolled, then the
__builtin_constant_p check in read_etm4x_sysreg_offset() defined in
drivers/hwtracing/coresight/coresight-etm4x.h may evaluate to true. This
can lead to the expression `(0x160 + (i * 4))` being passed to
read_etm4x_sysreg_const_offset. Via the trace above, this is passed
through READ_ETM4x_REG, read_sysreg_s, and finally to __mrs_s where it
is string-ified and used directly in inline asm.
Regardless of which compiler or compiler options determine whether a
loop can or can't be unrolled, which determines whether
__builtin_constant_p evaluates to true when passed an expression using a
loop induction variable, it is NEVER safe to allow the preprocessor to
construct inline asm like:
asm volatile (".inst (0x160 + (i * 4))" : "=r"(__val));
^ expected constant expression
Instead of read_etm4x_sysreg_offset() using __builtin_constant_p(), use
__is_constexpr from include/linux/const.h instead to ensure only
expressions that are valid integer constant expressions get passed
through to read_sysreg_s().
This is not a bug in clang; it's a potentially unsafe use of the macro
arguments in read_etm4x_sysreg_offset dependent on __builtin_constant_p.
wifi: mac80211: fix center freq calculation in ieee80211_chandef_downgrade
When mac80211 downgrades working bandwidth, the
center_freq and center_freq1 need to be recalculated.
There is a typo in the case of downgrading bandwidth from
320MHz to 160MHz which would cause a wrong frequency value.
wifi: nl80211: fix sending link ID info of associated BSS
commit dd374f84baec ("wifi: nl80211: expose link ID for associated
BSSes") used a top-level attribute to send link ID of the associated
BSS in the nested attribute NL80211_ATTR_BSS. But since NL80211_ATTR_BSS
is a nested attribute of the attributes defined in enum nl80211_bss,
define a new attribute in enum nl80211_bss and use it for sending the
link ID of the BSS.
Fixes: dd374f84baec ("wifi: nl80211: expose link ID for associated BSSes") Signed-off-by: Veerendranath Jakkam <quic_vjakkam@quicinc.com> Reviewed-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20220708122607.1836958-1-quic_vjakkam@quicinc.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
wifi: cfg80211: fix a comment in cfg80211_mlme_mgmt_tx()
A comment in cfg80211_mlme_mgmt_tx() is describing this API used only
for transmitting action frames. Fix the comment since
cfg80211_mlme_mgmt_tx() can be used to transmit any management frame.
wifi: nl80211: Fix reading NL80211_ATTR_MLO_LINK_ID in nl80211_pre_doit
nl80211_pre_doit() using nla_get_u16() to read u8 attribute
NL80211_ATTR_MLO_LINK_ID. Fix this by using nla_get_u8() to
read NL80211_ATTR_MLO_LINK_ID attribute.
Marc Zyngier [Mon, 11 Jul 2022 07:55:21 +0000 (08:55 +0100)]
gpio: thunderx: Don't directly include asm-generic/msi.h
On architectures that require it, asm-generic/msi.h is already
dragged in by the higher level include files, and is commonly
refered to as 'asm/msi.h'.
It is also architecture specific, and breaks compilation in
a pretty bad way now that linux/gpio/driver.h includes asm/msi.h
(which drags a conflicting but nonetheless correct version
of msi_alloc_info_t on x86).
Martin Kaiser [Sat, 9 Jul 2022 17:09:52 +0000 (19:09 +0200)]
staging: r8188eu: always initialise efuse buffer with 0xff
If BOOT_FROM_EEPROM is set, efuse_buf is not initialised before it is
passed to functions that read from it.
The buffer will be filled with 0x00 in this case like all local variables.
However, the parsing functions expect the buffer to be filled with 0xFF if
reading eeprom/efuse data failed. Fill the buffer with 0xFF before we try
to read the data.
Please note that this problem existed before we started using a local
buffer. Adapter->eeprompriv->efuse_eeprom_data was allocated as a part of
struct adapter by a vzalloc call in rtw_usb_if1_init.
Martin Kaiser [Sat, 9 Jul 2022 17:09:51 +0000 (19:09 +0200)]
staging: r8188eu: use a local buffer for efuse data
The efuse_eeprom_data array in struct eeprom_priv is used only by
ReadAdapterInfo8188EU. We can remove efuse_eeprom_data and use a local
buffer instead.
Use EFUSE_MAP_LEN_88E as buffer size. Its value is the same as
HWSET_MAX_SIZE_512. The functions that access the buffer use
EFUSE_MAP_LEN_88E for its size.
Martin Kaiser [Sat, 9 Jul 2022 17:09:48 +0000 (19:09 +0200)]
staging: r8188eu: remove EepromOrEfuse from struct eeprom_priv
The EepromOrEfuse flag in struct eeprom_priv is used only in the
ReadAdapterInfo8188EU function. We can remove EepromOrEfuse from struct
eeprom_priv.
As the meaning of EepromOrEfuse isn't obvious, there is a macro
is_boot_from_eeprom that's used for checking the value. We don't need the
macro, writing the check as !(eeValue & BOOT_FROM_EEPROM) makes it clear
what is checked.
Martin Kaiser [Sat, 9 Jul 2022 17:09:47 +0000 (19:09 +0200)]
staging: r8188eu: remove unused eeprom defines
Remove some eeprom-related defines which are not used by the r8188eu
driver. This driver uses BOOT_FROM_EEPROM and EEPROM_EN instead of the
defines that this patch removes.
Michael Straube [Sat, 9 Jul 2022 09:44:58 +0000 (11:44 +0200)]
staging: r8188eu: remove HW_VAR_DM_FUNC_CLR from SetHwReg8188EU()
Remove the HW_VAR_DM_FUNC_CLR case from SetHwReg8188EU() and move its
functionality to a static function. This is part of the ongoing effort
to get rid of SetHwReg8188EU().
Michael Straube [Sat, 9 Jul 2022 09:44:57 +0000 (11:44 +0200)]
staging: r8188eu: remove HW_VAR_DM_FUNC_RESET from SetHwReg8188EU()
Remove the HW_VAR_DM_FUNC_RESET case from SetHwReg8188EU() and move
its functionality to a static function. This is part of the ongoing
effort to get rid of SetHwReg8188EU().
Michael Straube [Sat, 9 Jul 2022 09:44:56 +0000 (11:44 +0200)]
staging: r8188eu: remove HW_VAR_DM_FLAG from SetHwReg8188EU()
Remove the HW_VAR_DM_FLAG case from SetHwReg8188EU() and move its
functionality to a static function. This is part of the ongoing
effort to get rid of SetHwReg8188EU().
Michael Straube [Sat, 9 Jul 2022 09:44:55 +0000 (11:44 +0200)]
staging: r8188eu: remove HW_VAR_DM_FUNC_OP from SetHwReg8188EU()
Remove the HW_VAR_DM_FUNC_OP case from SetHwReg8188EU() and move the
functionality to the functions that call SetHwReg8188EU() with
HW_VAR_DM_FUNC_OP. This is part of the ongoing effort to get rid of
SetHwReg8188EU().
Michael Straube [Sat, 9 Jul 2022 09:44:54 +0000 (11:44 +0200)]
staging: r8188eu: remove HW_VAR_BASIC_RATE from SetHwReg8188EU()
Remove the HW_VAR_BASIC_RATE case from SetHwReg8188EU() and move the
functionality to a separate function. This is part of the ongoing
effort to get rid of SetHwReg8188EU().
staging: rtl8192u: Fix sleep in atomic context bug in dm_fsync_timer_callback
There are sleep in atomic context bugs when dm_fsync_timer_callback is
executing. The root cause is that the memory allocation functions with
GFP_KERNEL or GFP_NOIO parameters are called in dm_fsync_timer_callback
which is a timer handler. The call paths that could trigger bugs are
shown below:
Currently, the only way x86 can get an early boot RNG seed is via EFI,
which is generally always used now for physical machines, but is very
rarely used in VMs, especially VMs that are optimized for starting
"instantaneously", such as Firecracker's MicroVM. For tiny fast booting
VMs, EFI is not something you generally need or want.
Rather, the image loader or firmware should be able to pass a single
random seed, exactly as device tree platforms do with the "rng-seed"
property. Additionally, this is something that bootloaders can append,
with their own seed file management, which is something every other
major OS ecosystem has that Linux does not (yet).
Add SETUP_RNG_SEED, similar to the other eight setup_data entries that
are parsed at boot. It also takes care to zero out the seed immediately
after using, in order to retain forward secrecy. This all takes about 7
trivial lines of code.
Then, on kexec_file_load(), a new fresh seed is generated and passed to
the next kernel, just as is done on device tree architectures when
using kexec. And, importantly, I've tested that QEMU is able to properly
pass SETUP_RNG_SEED as well, making this work for every step of the way.
This code too is pretty straight forward.
Together these measures ensure that VMs and nested kexec()'d kernels
always receive a proper boot time RNG seed at the earliest possible
stage from their parents:
- Host [already has strongly initialized RNG]
- QEMU [passes fresh seed in SETUP_RNG_SEED field]
- Linux [uses parent's seed and gathers entropy of its own]
- kexec [passes this in SETUP_RNG_SEED field]
- Linux [uses parent's seed and gathers entropy of its own]
- kexec [passes this in SETUP_RNG_SEED field]
- Linux [uses parent's seed and gathers entropy of its own]
- kexec [passes this in SETUP_RNG_SEED field]
- ...
I've verified in several scenarios that this works quite well from a
host kernel to QEMU and down inwards, mixing and matching loaders, with
every layer providing a seed to the next.
Matthew Rosato [Mon, 6 Jun 2022 20:33:25 +0000 (16:33 -0400)]
MAINTAINERS: additional files related kvm s390 pci passthrough
Add entries from the s390 kvm subdirectory related to pci passthrough.
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Link: https://lore.kernel.org/r/20220606203325.110625-22-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Matthew Rosato [Mon, 6 Jun 2022 20:33:24 +0000 (16:33 -0400)]
KVM: s390: add KVM_S390_ZPCI_OP to manage guest zPCI devices
The KVM_S390_ZPCI_OP ioctl provides a mechanism for managing
hardware-assisted virtualization features for s390x zPCI passthrough.
Add the first 2 operations, which can be used to enable/disable
the specified device for Adapter Event Notification interpretation.
Matthew Rosato [Mon, 6 Jun 2022 20:33:23 +0000 (16:33 -0400)]
vfio-pci/zdev: different maxstbl for interpreted devices
When doing load/store interpretation, the maximum store block length is
determined by the underlying firmware, not the host kernel API. Reflect
that in the associated Query PCI Function Group clp capability and let
userspace decide which is appropriate to present to the guest.
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20220606203325.110625-20-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Matthew Rosato [Mon, 6 Jun 2022 20:33:22 +0000 (16:33 -0400)]
vfio-pci/zdev: add function handle to clp base capability
The function handle is a system-wide unique identifier for a zPCI
device. With zPCI instruction interpretation, the host will no
longer be executing the zPCI instructions on behalf of the guest.
As a result, the guest needs to use the real function handle in
order for firmware to associate the instruction with the proper
PCI function. Let's provide that handle to the guest.
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Link: https://lore.kernel.org/r/20220606203325.110625-19-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Matthew Rosato [Mon, 6 Jun 2022 20:33:21 +0000 (16:33 -0400)]
vfio-pci/zdev: add open/close device hooks
During vfio-pci open_device, pass the KVM associated with the vfio group
(if one exists). This is needed in order to pass a special indicator
(GISA) to firmware to allow zPCI interpretation facilities to be used
for only the specific KVM associated with the vfio-pci device. During
vfio-pci close_device, unregister the notifier.
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Link: https://lore.kernel.org/r/20220606203325.110625-18-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Matthew Rosato [Mon, 6 Jun 2022 20:33:20 +0000 (16:33 -0400)]
KVM: s390: pci: add routines to start/stop interpretive execution
These routines will be invoked at the time an s390x vfio-pci device is
associated with a KVM (or when the association is removed), allowing
the zPCI device to enable or disable load/store intepretation mode;
this requires the host zPCI device to inform firmware of the unique
token (GISA designation) that is associated with the owning KVM.
Matthew Rosato [Mon, 6 Jun 2022 20:33:19 +0000 (16:33 -0400)]
KVM: s390: pci: provide routines for enabling/disabling interrupt forwarding
These routines will be wired into a kvm ioctl in order to respond to
requests to enable / disable a device for Adapter Event Notifications /
Adapter Interuption Forwarding.
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Acked-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Link: https://lore.kernel.org/r/20220606203325.110625-16-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Matthew Rosato [Mon, 6 Jun 2022 20:33:18 +0000 (16:33 -0400)]
KVM: s390: mechanism to enable guest zPCI Interpretation
The guest must have access to certain facilities in order to allow
interpretive execution of zPCI instructions and adapter event
notifications. However, there are some cases where a guest might
disable interpretation -- provide a mechanism via which we can defer
enabling the associated zPCI interpretation facilities until the guest
indicates it wishes to use them.
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Link: https://lore.kernel.org/r/20220606203325.110625-15-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Matthew Rosato [Mon, 6 Jun 2022 20:33:17 +0000 (16:33 -0400)]
KVM: s390: pci: enable host forwarding of Adapter Event Notifications
In cases where interrupts are not forwarded to the guest via firmware,
KVM is responsible for ensuring delivery. When an interrupt presents
with the forwarding bit, we must process the forwarding tables until
all interrupts are delivered.
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Link: https://lore.kernel.org/r/20220606203325.110625-14-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Matthew Rosato [Mon, 6 Jun 2022 20:33:16 +0000 (16:33 -0400)]
KVM: s390: pci: do initial setup for AEN interpretation
Initial setup for Adapter Event Notification Interpretation for zPCI
passthrough devices. Specifically, allocate a structure for forwarding of
adapter events and pass the address of this structure to firmware.
Matthew Rosato [Mon, 6 Jun 2022 20:33:14 +0000 (16:33 -0400)]
vfio/pci: introduce CONFIG_VFIO_PCI_ZDEV_KVM
The current contents of vfio-pci-zdev are today only useful in a KVM
environment; let's tie everything currently under vfio-pci-zdev to
this Kconfig statement and require KVM in this case, reducing complexity
(e.g. symbol lookups).
Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Link: https://lore.kernel.org/r/20220606203325.110625-11-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Matthew Rosato [Mon, 6 Jun 2022 20:33:13 +0000 (16:33 -0400)]
s390/pci: stash dtsm and maxstbl
Store information about what IOAT designation types are supported by
underlying hardware as well as the largest store block size allowed.
These values will be needed by passthrough.
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Link: https://lore.kernel.org/r/20220606203325.110625-10-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Matthew Rosato [Mon, 6 Jun 2022 20:33:12 +0000 (16:33 -0400)]
s390/pci: stash associated GISA designation
For passthrough devices, we will need to know the GISA designation of the
guest if interpretation facilities are to be used. Setup to stash this in
the zdev and set a default of 0 (no GISA designation) for now; a subsequent
patch will set a valid GISA designation for passthrough devices.
Also, extend mpcific routines to specify this stashed designation as part
of the mpcific command.
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Link: https://lore.kernel.org/r/20220606203325.110625-9-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Matthew Rosato [Mon, 6 Jun 2022 20:33:11 +0000 (16:33 -0400)]
s390/pci: externalize the SIC operation controls and routine
A subsequent patch will be issuing SIC from KVM -- export the necessary
routine and make the operation control definitions available from a header.
Because the routine will now be exported, let's rename __zpci_set_irq_ctrl
to zpci_set_irq_ctrl and get rid of the zero'd iib wrapper function of
the same name.
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Link: https://lore.kernel.org/r/20220606203325.110625-8-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Matthew Rosato [Mon, 6 Jun 2022 20:33:10 +0000 (16:33 -0400)]
s390/airq: allow for airq structure that uses an input vector
When doing device passthrough where interrupts are being forwarded from
host to guest, we wish to use a pinned section of guest memory as the
vector (the same memory used by the guest as the vector). To accomplish
this, add a new parameter for airq_iv_create which allows passing an
existing vector to be used instead of allocating a new one. The caller
is responsible for ensuring the vector is pinned in memory as well as for
unpinning the memory when the vector is no longer needed.
A subsequent patch will use this new parameter for zPCI interpretation.
Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Link: https://lore.kernel.org/r/20220606203325.110625-7-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Matthew Rosato [Mon, 6 Jun 2022 20:33:09 +0000 (16:33 -0400)]
s390/airq: pass more TPI info to airq handlers
A subsequent patch will introduce an airq handler that requires additional
TPI information beyond directed vs floating, so pass the entire tpi_info
structure via the handler. Only pci actually uses this information today,
for the other airq handlers this is effectively a no-op.
Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Acked-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Link: https://lore.kernel.org/r/20220606203325.110625-6-mjrosato@linux.ibm.com Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com>
x86/Kconfig: Fix CONFIG_CC_HAS_SANE_STACKPROTECTOR when cross compiling with clang
Chimera Linux notes that CONFIG_CC_HAS_SANE_STACKPROTECTOR cannot be
enabled when cross compiling an x86_64 kernel with clang, even though it
does work when natively compiling.
When clang is invoked without a '--target' flag, code is generated for
the default target, which is usually the host (it is configurable via
cmake). As a result, the has-stack-protector scripts will generate code
for the default target but check for x86 specific segment registers,
which cannot succeed if the default target is not x86.
$(CLANG_FLAGS) contains an explicit '--target' flag so pass that
variable along to the has-stack-protector scripts so that the stack
protector can be enabled when cross compiling with clang. The 32-bit
stack protector cannot currently be enabled with clang, as it does not
support '-mstack-protector-guard-symbol', so this results in no
functional change for ARCH=i386 when cross compiling.
Mustafa Ismail [Tue, 5 Jul 2022 23:08:37 +0000 (18:08 -0500)]
RDMA/irdma: Fix sleep from invalid context BUG
Taking the qos_mutex to process RoCEv2 QP's on netdev events causes a
kernel splat.
Fix this by removing the handling for RoCEv2 in
irdma_cm_teardown_connections that uses the mutex. This handling is only
needed for iWARP to avoid having connections established while the link is
down or having connections remain functional after the IP address is
removed.
Mustafa Ismail [Tue, 5 Jul 2022 23:08:36 +0000 (18:08 -0500)]
RDMA/irdma: Do not advertise 1GB page size for x722
x722 does not support 1GB page size but the irdma driver incorrectly
advertises 1GB page size support for x722 device to ib_core to compute the
best page size to use on this MR. This could lead to incorrect start
offsets computed by hardware on the MR.
Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Mustafa Ismail <mustafa.ismail@intel.com> Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Dan Carpenter [Fri, 8 Jul 2022 08:41:06 +0000 (11:41 +0300)]
drm/i915/gvt: IS_ERR() vs NULL bug in intel_gvt_update_reg_whitelist()
The shmem_pin_map() function returns NULL, it doesn't return error
pointers.
Fixes: 97ea656521c8 ("drm/i915/gvt: Parse default state to update reg whitelist") Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/Ysftoia2BPUyqVcD@kili Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
RISC-V: KVM: Fix SRCU deadlock caused by kvm_riscv_check_vcpu_requests()
The kvm_riscv_check_vcpu_requests() is called with SRCU read lock held
and for KVM_REQ_SLEEP request it will block the VCPU without releasing
SRCU read lock. This causes KVM ioctls (such as KVM_IOEVENTFD) from
other VCPUs of the same Guest/VM to hang/deadlock if there is any
synchronize_srcu() or synchronize_srcu_expedited() in the path.
To fix the above in kvm_riscv_check_vcpu_requests(), we should do SRCU
read unlock before blocking the VCPU and do SRCU read lock after VCPU
wakeup.
Fixes: cce69aff689e ("RISC-V: KVM: Implement VCPU interrupts and requests handling") Reported-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Atish Patra <atishp@rivosinc.com> Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Tested-by: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: Anup Patel <anup@brainfault.org>
There are a bunch of functions that use the PFN from a page table entry
that end up with the svpbmt upper-bits because they are missing the newly
introduced PAGE_PFN_MASK which leads to wrong addresses conversions and
then crash: fix this by adding this mask.
Fixes: 100631b48ded ("riscv: Fix accessing pfn bits in PTEs for non-32bit variants") Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Anup Patel <anup@brainfault.org>
Trond Myklebust [Mon, 27 Jun 2022 20:04:02 +0000 (16:04 -0400)]
NFS: Fix case insensitive renames
For filesystems that are case insensitive and case preserving, we need
to be able to rename from one case folded variant of the filename to
another.
Currently, if we have looked up the target filename before the call to
rename, then we may have a hashed dentry with that target name in the
dcache, causing the vfs to optimise away the rename.
To avoid that, let's drop the target dentry, and leave it to the server
to optimise away the rename if that is the correct thing to do.
The RPC/RDMA driver will return -EPROTO and -ENODEV as connection errors
under certain circumstances. Make sure that we handle them correctly and
avoid cycling forever in a LAYOUTGET/LAYOUTRETURN loop.
Trond Myklebust [Wed, 18 May 2022 20:09:06 +0000 (16:09 -0400)]
pNFS/flexfiles: Report RDMA connection errors to the server
The RPC/RDMA driver will return -EPROTO and -ENODEV as connection errors
under certain circumstances. Make sure that we handle them and report
them to the server. If not, we can end up cycling forever in a
LAYOUTGET/LAYOUTRETURN loop.
Fixes: a12f996d3413 ("NFSv4/pNFS: Use connections to a DS that are all of the same protocol family") Cc: stable@vger.kernel.org # 5.11.x Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Trond Myklebust [Wed, 18 May 2022 20:37:56 +0000 (16:37 -0400)]
Revert "pNFS: nfs3_set_ds_client should set NFS_CS_NOPING"
This reverts commit c6eb58435b98bd843d3179664a0195ff25adb2c3.
If a transport is down, then we want to fail over to other transports if
they are listed in the GETDEVICEINFO reply.
Fixes: c6eb58435b98 ("pNFS: nfs3_set_ds_client should set NFS_CS_NOPING") Cc: stable@vger.kernel.org # 5.11.x Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
This is a collection of three fixes for small annoyances.
Two of these are already pending in other trees, but I really don't want
to release another -rc with these issues pending, so I picked up the
patches for these things directly. We'll end up with duplicate commits
eventually, I prefer that over having these issues pending.
The third one is just me getting rid of another BUG_ON() just because it
was reported and I dislike those things so much.
* merge 'hot-fixes' branch:
ida: don't use BUG_ON() for debugging
drm/aperture: Run fbdev removal before internal helpers
ptrace: fix clearing of JOBCTL_TRACED in ptrace_unfreeze_traced()
This is another old BUG_ON() that just shouldn't exist (see also commit a382f8fee42c: "signal handling: don't use BUG_ON() for debugging").
In fact, as Matthew Wilcox points out, this condition shouldn't really
even result in a warning, since a negative id allocation result is just
a normal allocation failure:
"I wonder if we should even warn here -- sure, the caller is trying to
free something that wasn't allocated, but we don't warn for
kfree(NULL)"
and goes on to point out how that current error check is only causing
people to unnecessarily do their own index range checking before freeing
it.
This was noted by Itay Iellin, because the bluetooth HCI socket cookie
code does *not* do that range checking, and ends up just freeing the
error case too, triggering the BUG_ON().
The HCI code requires CAP_NET_RAW, and seems to just result in an ugly
splat, but there really is no reason to BUG_ON() here, and we have
generally striven for allocation models where it's always ok to just do
free(alloc());
even if the allocation were to fail for some random reason (usually
obviously that "random" reason being some resource limit).
Fixes: 88eca0207cf1 ("ida: simplified functions for id allocation") Reported-by: Itay Iellin <ieitayie@gmail.com> Suggested-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dan Williams [Tue, 7 Jun 2022 18:21:40 +0000 (11:21 -0700)]
cxl/hdm: Initialize decoder type for memory expander devices
Unless and until accelerator (type-2) drivers start registering for
CXL.mem mapping services from the CXL subsystem core, initialize idle
HDM decoders to the "expander" type. I.e. the only CXL devices using the
CXL core presently are those implementing the CXL 2.0 Type-3 memory
expander device class code that the cxl_pci driver claims.
Dan Williams [Wed, 1 Jun 2022 19:49:32 +0000 (12:49 -0700)]
cxl/port: Cache CXL host bridge data
Region creation has need for checking host-bridge connectivity when
adding endpoints to regions. Record, at port creation time, the
host-bridge to provide a useful shortcut from any location in the
topology to the most-significant ancestor.
Dan Williams [Tue, 24 May 2022 06:26:11 +0000 (23:26 -0700)]
tools/testing/cxl: Add partition support
In support of testing DPA allocation mechanisms in the CXL core, the
cxl_test environment needs to support establishing and retrieving the
'pmem partition boundary.
Replace the platform_device_add_resources() method for delineating DPA
within an endpoint with an emulated DEV_SIZE amount of partitionable
capacity. Set DEV_SIZE such that an endpoint has enough capacity to
simultaneously participate in 8 distinct regions.
Dan Williams [Tue, 24 May 2022 15:56:58 +0000 (08:56 -0700)]
tools/testing/cxl: Expand CFMWS windows
For the x2 host-bridge interleave windows, allow for a
x8-endpoint-interleave configuration per memory-type with each device
contributing the minimum 256MB extent. Similarly, for the x1 host-bridge
interleave windows, allow for a x4-endpoint-interleave configuration per
memory-type.
Bump up the number of decoders per-port to support hosting 8 regions.
Dan Williams [Thu, 23 Jun 2022 01:02:37 +0000 (18:02 -0700)]
tools/testing/cxl: Move cxl_test resources to the top of memory
A recent QEMU upgrade resulted in collisions between QEMU's chosen
location for PCI MMIO and cxl_test's fake address location for emulated
CXL purposes. This was great for testing resource collisions, but not so
great for continuing to test the nominal cases. Move cxl_test to the
top-of-memory where it is less likely to collide with other resources.
Dan Williams [Sun, 10 Jul 2022 16:57:28 +0000 (09:57 -0700)]
cxl/debug: Move debugfs init to cxl_core_init()
In preparation for a new cxl debugfs file, move 'cxl' directory
establishment and teardown to the core and let subsequent init routines
reference that setup.
Merge tag 'staging-5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fix from Greg KH:
"Here is a single staging driver fix for a reported problem that showed
up in 5.19-rc1 in the wlan-ng driver. It has been in linux-next for a
week with no reported problems"
* tag 'staging-5.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging/wlan-ng: get the correct struct hfa384x in work callback
projects / people / ms / linux.git / log
