Skip to content
  1. Apr 13, 2023
  2. Apr 10, 2023
  3. Apr 07, 2023
    • Hangbin Liu's avatar
      bonding: fix ns validation on backup slaves · 4598380f
      Hangbin Liu authored
      
      
      When arp_validate is set to 2, 3, or 6, validation is performed for
      backup slaves as well. As stated in the bond documentation, validation
      involves checking the broadcast ARP request sent out via the active
      slave. This helps determine which slaves are more likely to function in
      the event of an active slave failure.
      
      However, when the target is an IPv6 address, the NS message sent from
      the active interface is not checked on backup slaves. Additionally,
      based on the bond_arp_rcv() rule b, we must reverse the saddr and daddr
      when checking the NS message.
      
      Note that when checking the NS message, the destination address is a
      multicast address. Therefore, we must convert the target address to
      solicited multicast in the bond_get_targets_ip6() function.
      
      Prior to the fix, the backup slaves had a mii status of "down", but
      after the fix, all of the slaves' mii status was updated to "UP".
      
      Fixes: 4e24be01 ("bonding: add new parameter ns_targets")
      Reviewed-by: default avatarJonathan Toppins <jtoppins@redhat.com>
      Acked-by: default avatarJay Vosburgh <jay.vosburgh@canonical.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4598380f
  4. Apr 06, 2023
  5. Apr 05, 2023
    • Hans de Goede's avatar
      ACPI: video: Add auto_detect arg to __acpi_video_get_backlight_type() · 78dfc9d1
      Hans de Goede authored
      
      
      Allow callers of __acpi_video_get_backlight_type() to pass a pointer
      to a bool which will get set to false if the backlight-type comes from
      the cmdline or a DMI quirk and set to true if auto-detection was used.
      
      And make __acpi_video_get_backlight_type() non static so that it can
      be called directly outside of video_detect.c .
      
      While at it turn the acpi_video_get_backlight_type() and
      acpi_video_backlight_use_native() wrappers into static inline functions
      in include/acpi/video.h, so that we need to export one less symbol.
      
      Fixes: 5aa9d943 ("ACPI: video: Don't enable fallback path for creating ACPI backlight by default")
      Cc: All applicable <stable@vger.kernel.org>
      Reviewed-by: default avatarMario Limonciello <mario.limonciello@amd.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      78dfc9d1
    • Kuniyuki Iwashima's avatar
      raw: Fix NULL deref in raw_get_next(). · 0a78cf72
      Kuniyuki Iwashima authored
      
      
      Dae R. Jeong reported a NULL deref in raw_get_next() [0].
      
      It seems that the repro was running these sequences in parallel so
      that one thread was iterating on a socket that was being freed in
      another netns.
      
        unshare(0x40060200)
        r0 = syz_open_procfs(0x0, &(0x7f0000002080)='net/raw\x00')
        socket$inet_icmp_raw(0x2, 0x3, 0x1)
        pread64(r0, &(0x7f0000000000)=""/10, 0xa, 0x10000000007f)
      
      After commit 0daf07e5 ("raw: convert raw sockets to RCU"), we
      use RCU and hlist_nulls_for_each_entry() to iterate over SOCK_RAW
      sockets.  However, we should use spinlock for slow paths to avoid
      the NULL deref.
      
      Also, SOCK_RAW does not use SLAB_TYPESAFE_BY_RCU, and the slab object
      is not reused during iteration in the grace period.  In fact, the
      lockless readers do not check the nulls marker with get_nulls_value().
      So, SOCK_RAW should use hlist instead of hlist_nulls.
      
      Instead of adding an unnecessary barrier by sk_nulls_for_each_rcu(),
      let's convert hlist_nulls to hlist and use sk_for_each_rcu() for
      fast paths and sk_for_each() and spinlock for /proc/net/raw.
      
      [0]:
      general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
      KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
      CPU: 2 PID: 20952 Comm: syz-executor.0 Not tainted 6.2.0-g048ec869bafd-dirty #7
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
      RIP: 0010:read_pnet include/net/net_namespace.h:383 [inline]
      RIP: 0010:sock_net include/net/sock.h:649 [inline]
      RIP: 0010:raw_get_next net/ipv4/raw.c:974 [inline]
      RIP: 0010:raw_get_idx net/ipv4/raw.c:986 [inline]
      RIP: 0010:raw_seq_start+0x431/0x800 net/ipv4/raw.c:995
      Code: ef e8 33 3d 94 f7 49 8b 6d 00 4c 89 ef e8 b7 65 5f f7 49 89 ed 49 83 c5 98 0f 84 9a 00 00 00 48 83 c5 c8 48 89 e8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 ef e8 00 3d 94 f7 4c 8b 7d 00 48 89 ef
      RSP: 0018:ffffc9001154f9b0 EFLAGS: 00010206
      RAX: 0000000000000005 RBX: 1ffff1100302c8fd RCX: 0000000000000000
      RDX: 0000000000000028 RSI: ffffc9001154f988 RDI: ffffc9000f77a338
      RBP: 0000000000000029 R08: ffffffff8a50ffb4 R09: fffffbfff24b6bd9
      R10: fffffbfff24b6bd9 R11: 0000000000000000 R12: ffff88801db73b78
      R13: fffffffffffffff9 R14: dffffc0000000000 R15: 0000000000000030
      FS:  00007f843ae8e700(0000) GS:ffff888063700000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000055bb9614b35f CR3: 000000003c672000 CR4: 00000000003506e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       <TASK>
       seq_read_iter+0x4c6/0x10f0 fs/seq_file.c:225
       seq_read+0x224/0x320 fs/seq_file.c:162
       pde_read fs/proc/inode.c:316 [inline]
       proc_reg_read+0x23f/0x330 fs/proc/inode.c:328
       vfs_read+0x31e/0xd30 fs/read_write.c:468
       ksys_pread64 fs/read_write.c:665 [inline]
       __do_sys_pread64 fs/read_write.c:675 [inline]
       __se_sys_pread64 fs/read_write.c:672 [inline]
       __x64_sys_pread64+0x1e9/0x280 fs/read_write.c:672
       do_syscall_x64 arch/x86/entry/common.c:51 [inline]
       do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82
       entry_SYSCALL_64_after_hwframe+0x63/0xcd
      RIP: 0033:0x478d29
      Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
      RSP: 002b:00007f843ae8dbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000011
      RAX: ffffffffffffffda RBX: 0000000000791408 RCX: 0000000000478d29
      RDX: 000000000000000a RSI: 0000000020000000 RDI: 0000000000000003
      RBP: 00000000f477909a R08: 0000000000000000 R09: 0000000000000000
      R10: 000010000000007f R11: 0000000000000246 R12: 0000000000791740
      R13: 0000000000791414 R14: 0000000000791408 R15: 00007ffc2eb48a50
       </TASK>
      Modules linked in:
      ---[ end trace 0000000000000000 ]---
      RIP: 0010:read_pnet include/net/net_namespace.h:383 [inline]
      RIP: 0010:sock_net include/net/sock.h:649 [inline]
      RIP: 0010:raw_get_next net/ipv4/raw.c:974 [inline]
      RIP: 0010:raw_get_idx net/ipv4/raw.c:986 [inline]
      RIP: 0010:raw_seq_start+0x431/0x800 net/ipv4/raw.c:995
      Code: ef e8 33 3d 94 f7 49 8b 6d 00 4c 89 ef e8 b7 65 5f f7 49 89 ed 49 83 c5 98 0f 84 9a 00 00 00 48 83 c5 c8 48 89 e8 48 c1 e8 03 <42> 80 3c 30 00 74 08 48 89 ef e8 00 3d 94 f7 4c 8b 7d 00 48 89 ef
      RSP: 0018:ffffc9001154f9b0 EFLAGS: 00010206
      RAX: 0000000000000005 RBX: 1ffff1100302c8fd RCX: 0000000000000000
      RDX: 0000000000000028 RSI: ffffc9001154f988 RDI: ffffc9000f77a338
      RBP: 0000000000000029 R08: ffffffff8a50ffb4 R09: fffffbfff24b6bd9
      R10: fffffbfff24b6bd9 R11: 0000000000000000 R12: ffff88801db73b78
      R13: fffffffffffffff9 R14: dffffc0000000000 R15: 0000000000000030
      FS:  00007f843ae8e700(0000) GS:ffff888063700000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007f92ff166000 CR3: 000000003c672000 CR4: 00000000003506e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      
      Fixes: 0daf07e5 ("raw: convert raw sockets to RCU")
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Reported-by: default avatarDae R. Jeong <threeearcat@gmail.com>
      Link: https://lore.kernel.org/netdev/ZCA2mGV_cmq7lIfV@dragonet/
      
      
      Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      0a78cf72
  6. Apr 04, 2023
    • Arnd Bergmann's avatar
      asm-generic: avoid __generic_cmpxchg_local warnings · 656e9007
      Arnd Bergmann authored
      
      
      Code that passes a 32-bit constant into cmpxchg() produces a harmless
      sparse warning because of the truncation in the branch that is not taken:
      
      fs/erofs/zdata.c: note: in included file (through /home/arnd/arm-soc/arch/arm/include/asm/cmpxchg.h, /home/arnd/arm-soc/arch/arm/include/asm/atomic.h, /home/arnd/arm-soc/include/linux/atomic.h, ...):
      include/asm-generic/cmpxchg-local.h:29:33: warning: cast truncates bits from constant value (5f0ecafe becomes fe)
      include/asm-generic/cmpxchg-local.h:33:34: warning: cast truncates bits from constant value (5f0ecafe becomes cafe)
      include/asm-generic/cmpxchg-local.h:29:33: warning: cast truncates bits from constant value (5f0ecafe becomes fe)
      include/asm-generic/cmpxchg-local.h:30:42: warning: cast truncates bits from constant value (5f0edead becomes ad)
      include/asm-generic/cmpxchg-local.h:33:34: warning: cast truncates bits from constant value (5f0ecafe becomes cafe)
      include/asm-generic/cmpxchg-local.h:34:44: warning: cast truncates bits from constant value (5f0edead becomes dead)
      
      This was reported as a regression to Matt's recent __generic_cmpxchg_local
      patch, though this patch only added more warnings on top of the ones
      that were already there.
      
      Rewording the truncation to use an explicit bitmask instead of a cast
      to a smaller type avoids the warning but otherwise leaves the code
      unchanged.
      
      I had another look at why the cast is even needed for atomic_cmpxchg(),
      and as Matt describes the problem here is that atomic_t contains a
      signed 'int', but cmpxchg() takes an 'unsigned long' argument, and
      converting between the two leads to a 64-bit sign-extension of
      negative 32-bit atomics.
      
      I checked the other implementations of arch_cmpxchg() and did not find
      any others that run into the same problem as __generic_cmpxchg_local(),
      but it's easy to be on the safe side here and always convert the
      signed int into an unsigned int when calling arch_cmpxchg(), as this
      will work even when any of the arch_cmpxchg() implementations run
      into the same problem.
      
      Fixes: 62465415 ("locking/atomic: cmpxchg: Make __generic_cmpxchg_local compare against zero-extended 'old' value")
      Reviewed-by: default avatarMatt Evans <mev@rivosinc.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      656e9007
    • Vladimir Oltean's avatar
      asm-generic/io.h: suppress endianness warnings for relaxed accessors · 05d3855b
      Vladimir Oltean authored
      
      
      Copy the forced type casts from the normal MMIO accessors to suppress
      the sparse warnings that point out __raw_readl() returns a native endian
      word (just like readl()).
      
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      05d3855b
    • Vladimir Oltean's avatar
      asm-generic/io.h: suppress endianness warnings for readq() and writeq() · d564fa1f
      Vladimir Oltean authored
      Commit c1d55d50 ("asm-generic/io.h: Fix sparse warnings on
      big-endian architectures") missed fixing the 64-bit accessors.
      
      Arnd explains in the attached link why the casts are necessary, even if
      __raw_readq() and __raw_writeq() do not take endian-specific types.
      
      Link: https://lore.kernel.org/lkml/9105d6fc-880b-4734-857d-e3d30b87ccf6@app.fastmail.com/
      
      
      Suggested-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      d564fa1f
    • Dmitry Fomichev's avatar
      virtio-blk: fix to match virtio spec · f1ba4e67
      Dmitry Fomichev authored
      The merged patch series to support zoned block devices in virtio-blk
      is not the most up to date version. The merged patch can be found at
      
      https://lore.kernel.org/linux-block/20221016034127.330942-3-dmitry.fomichev@wdc.com/
      
      but the latest and reviewed version is
      
      https://lore.kernel.org/linux-block/20221110053952.3378990-3-dmitry.fomichev@wdc.com/
      
      
      
      The reason is apparently that the correct mailing lists and
      maintainers were not copied.
      
      The differences between the two are mostly cleanups, but there is one
      change that is very important in terms of compatibility with the
      approved virtio-zbd specification.
      
      Before it was approved, the OASIS virtio spec had a change in
      VIRTIO_BLK_T_ZONE_APPEND request layout that is not reflected in the
      current virtio-blk driver code. In the running code, the status is
      the first byte of the in-header that is followed by some pad bytes
      and the u64 that carries the sector at which the data has been written
      to the zone back to the driver, aka the append sector.
      
      This layout turned out to be problematic for implementing in QEMU and
      the request status byte has been eventually made the last byte of the
      in-header. The current code doesn't expect that and this causes the
      append sector value always come as zero to the block layer. This needs
      to be fixed ASAP.
      
      Fixes: 95bfec41 ("virtio-blk: add support for zoned block devices")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Fomichev <dmitry.fomichev@wdc.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarDamien Le Moal <damien.lemoal@opensource.wdc.com>
      Message-Id: <20230330214953.1088216-2-dmitry.fomichev@wdc.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      f1ba4e67
  7. Apr 03, 2023
  8. Mar 31, 2023
    • Michael Sit Wei Hong's avatar
      net: phylink: add phylink_expects_phy() method · 653a1809
      Michael Sit Wei Hong authored
      
      
      Provide phylink_expects_phy() to allow MAC drivers to check if it
      is expecting a PHY to attach to. Since fixed-linked setups do not
      need to attach to a PHY.
      
      Provides a boolean value as to if the MAC should expect a PHY.
      Returns true if a PHY is expected.
      
      Reviewed-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarMichael Sit Wei Hong <michael.wei.hong.sit@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      653a1809
    • Kan Liang's avatar
      iommu/vt-d: Fix an IOMMU perfmon warning when CPU hotplug · 16812c96
      Kan Liang authored
      
      
      A warning can be triggered when hotplug CPU 0.
      $ echo 0 > /sys/devices/system/cpu/cpu0/online
      
       ------------[ cut here ]------------
       Voluntary context switch within RCU read-side critical section!
       WARNING: CPU: 0 PID: 19 at kernel/rcu/tree_plugin.h:318
                rcu_note_context_switch+0x4f4/0x580
       RIP: 0010:rcu_note_context_switch+0x4f4/0x580
       Call Trace:
        <TASK>
        ? perf_event_update_userpage+0x104/0x150
        __schedule+0x8d/0x960
        ? perf_event_set_state.part.82+0x11/0x50
        schedule+0x44/0xb0
        schedule_timeout+0x226/0x310
        ? __perf_event_disable+0x64/0x1a0
        ? _raw_spin_unlock+0x14/0x30
        wait_for_completion+0x94/0x130
        __wait_rcu_gp+0x108/0x130
        synchronize_rcu+0x67/0x70
        ? invoke_rcu_core+0xb0/0xb0
        ? __bpf_trace_rcu_stall_warning+0x10/0x10
        perf_pmu_migrate_context+0x121/0x370
        iommu_pmu_cpu_offline+0x6a/0xa0
        ? iommu_pmu_del+0x1e0/0x1e0
        cpuhp_invoke_callback+0x129/0x510
        cpuhp_thread_fun+0x94/0x150
        smpboot_thread_fn+0x183/0x220
        ? sort_range+0x20/0x20
        kthread+0xe6/0x110
        ? kthread_complete_and_exit+0x20/0x20
        ret_from_fork+0x1f/0x30
        </TASK>
       ---[ end trace 0000000000000000 ]---
      
      The synchronize_rcu() will be invoked in the perf_pmu_migrate_context(),
      when migrating a PMU to a new CPU. However, the current for_each_iommu()
      is within RCU read-side critical section.
      
      Two methods were considered to fix the issue.
      - Use the dmar_global_lock to replace the RCU read lock when going
        through the drhd list. But it triggers a lockdep warning.
      - Use the cpuhp_setup_state_multi() to set up a dedicated state for each
        IOMMU PMU. The lock can be avoided.
      
      The latter method is implemented in this patch. Since each IOMMU PMU has
      a dedicated state, add cpuhp_node and cpu in struct iommu_pmu to track
      the state. The state can be dynamically allocated now. Remove the
      CPUHP_AP_PERF_X86_IOMMU_PERF_ONLINE.
      
      Fixes: 46284c6c ("iommu/vt-d: Support cpumask for IOMMU perfmon")
      Reported-by: default avatarAmmy Yi <ammy.yi@intel.com>
      Signed-off-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Link: https://lore.kernel.org/r/20230328182028.1366416-1-kan.liang@linux.intel.com
      
      
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Link: https://lore.kernel.org/r/20230329134721.469447-4-baolu.lu@linux.intel.com
      
      
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      16812c96
  9. Mar 30, 2023
  10. Mar 27, 2023
    • Dmytro Maluka's avatar
      KVM: x86/ioapic: Resample the pending state of an IRQ when unmasking · fef8f2b9
      Dmytro Maluka authored
      
      
      KVM irqfd based emulation of level-triggered interrupts doesn't work
      quite correctly in some cases, particularly in the case of interrupts
      that are handled in a Linux guest as oneshot interrupts (IRQF_ONESHOT).
      Such an interrupt is acked to the device in its threaded irq handler,
      i.e. later than it is acked to the interrupt controller (EOI at the end
      of hardirq), not earlier.
      
      Linux keeps such interrupt masked until its threaded handler finishes,
      to prevent the EOI from re-asserting an unacknowledged interrupt.
      However, with KVM + vfio (or whatever is listening on the resamplefd)
      we always notify resamplefd at the EOI, so vfio prematurely unmasks the
      host physical IRQ, thus a new physical interrupt is fired in the host.
      This extra interrupt in the host is not a problem per se. The problem is
      that it is unconditionally queued for injection into the guest, so the
      guest sees an extra bogus interrupt. [*]
      
      There are observed at least 2 user-visible issues caused by those
      extra erroneous interrupts for a oneshot irq in the guest:
      
      1. System suspend aborted due to a pending wakeup interrupt from
         ChromeOS EC (drivers/platform/chrome/cros_ec.c).
      2. Annoying "invalid report id data" errors from ELAN0000 touchpad
         (drivers/input/mouse/elan_i2c_core.c), flooding the guest dmesg
         every time the touchpad is touched.
      
      The core issue here is that by the time when the guest unmasks the IRQ,
      the physical IRQ line is no longer asserted (since the guest has
      acked the interrupt to the device in the meantime), yet we
      unconditionally inject the interrupt queued into the guest by the
      previous resampling. So to fix the issue, we need a way to detect that
      the IRQ is no longer pending, and cancel the queued interrupt in this
      case.
      
      With IOAPIC we are not able to probe the physical IRQ line state
      directly (at least not if the underlying physical interrupt controller
      is an IOAPIC too), so in this patch we use irqfd resampler for that.
      Namely, instead of injecting the queued interrupt, we just notify the
      resampler that this interrupt is done. If the IRQ line is actually
      already deasserted, we are done. If it is still asserted, a new
      interrupt will be shortly triggered through irqfd and injected into the
      guest.
      
      In the case if there is no irqfd resampler registered for this IRQ, we
      cannot fix the issue, so we keep the existing behavior: immediately
      unconditionally inject the queued interrupt.
      
      This patch fixes the issue for x86 IOAPIC only. In the long run, we can
      fix it for other irqchips and other architectures too, possibly taking
      advantage of reading the physical state of the IRQ line, which is
      possible with some other irqchips (e.g. with arm64 GIC, maybe even with
      the legacy x86 PIC).
      
      [*] In this description we assume that the interrupt is a physical host
          interrupt forwarded to the guest e.g. by vfio. Potentially the same
          issue may occur also with a purely virtual interrupt from an
          emulated device, e.g. if the guest handles this interrupt, again, as
          a oneshot interrupt.
      
      Signed-off-by: default avatarDmytro Maluka <dmy@semihalf.com>
      Link: https://lore.kernel.org/kvm/31420943-8c5f-125c-a5ee-d2fde2700083@semihalf.com/
      Link: https://lore.kernel.org/lkml/87o7wrug0w.wl-maz@kernel.org/
      
      
      Message-Id: <20230322204344.50138-3-dmy@semihalf.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      fef8f2b9
    • Dmytro Maluka's avatar
      KVM: irqfd: Make resampler_list an RCU list · d583fbd7
      Dmytro Maluka authored
      
      
      It is useful to be able to do read-only traversal of the list of all the
      registered irqfd resamplers without locking the resampler_lock mutex.
      In particular, we are going to traverse it to search for a resampler
      registered for the given irq of an irqchip, and that will be done with
      an irqchip spinlock (ioapic->lock) held, so it is undesirable to lock a
      mutex in this context. So turn this list into an RCU list.
      
      For protecting the read side, reuse kvm->irq_srcu which is already used
      for protecting a number of irq related things (kvm->irq_routing,
      irqfd->resampler->list, kvm->irq_ack_notifier_list,
      kvm->arch.mask_notifier_list).
      
      Signed-off-by: default avatarDmytro Maluka <dmy@semihalf.com>
      Message-Id: <20230322204344.50138-2-dmy@semihalf.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      d583fbd7
    • Russell King (Oracle)'s avatar
      net: phy: constify fwnode_get_phy_node() fwnode argument · 4a0faa02
      Russell King (Oracle) authored
      
      
      fwnode_get_phy_node() does not motify the fwnode structure, so make
      the argument const,
      
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a0faa02
    • Russell King (Oracle)'s avatar
      net: sfp: make sfp_bus_find_fwnode() take a const fwnode · a90ac762
      Russell King (Oracle) authored
      
      
      sfp_bus_find_fwnode() does not write to the fwnode, so let's make it
      const.
      
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Reviewed-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a90ac762
  11. Mar 24, 2023
  12. Mar 22, 2023
  13. Mar 21, 2023
    • Lukas Wunner's avatar
      cxl/pci: Fix CDAT retrieval on big endian · fbaa3821
      Lukas Wunner authored
      
      
      The CDAT exposed in sysfs differs between little endian and big endian
      arches:  On big endian, every 4 bytes are byte-swapped.
      
      PCI Configuration Space is little endian (PCI r3.0 sec 6.1).  Accessors
      such as pci_read_config_dword() implicitly swap bytes on big endian.
      That way, the macros in include/uapi/linux/pci_regs.h work regardless of
      the arch's endianness.  For an example of implicit byte-swapping, see
      ppc4xx_pciex_read_config(), which calls in_le32(), which uses lwbrx
      (Load Word Byte-Reverse Indexed).
      
      DOE Read/Write Data Mailbox Registers are unlike other registers in
      Configuration Space in that they contain or receive a 4 byte portion of
      an opaque byte stream (a "Data Object" per PCIe r6.0 sec 7.9.24.5f).
      They need to be copied to or from the request/response buffer verbatim.
      So amend pci_doe_send_req() and pci_doe_recv_resp() to undo the implicit
      byte-swapping.
      
      The CXL_DOE_TABLE_ACCESS_* and PCI_DOE_DATA_OBJECT_DISC_* macros assume
      implicit byte-swapping.  Byte-swap requests after constructing them with
      those macros and byte-swap responses before parsing them.
      
      Change the request and response type to __le32 to avoid sparse warnings.
      Per a request from Jonathan, replace sizeof(u32) with sizeof(__le32) for
      consistency.
      
      Fixes: c9700604 ("cxl/port: Read CDAT table")
      Tested-by: default avatarIra Weiny <ira.weiny@intel.com>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Reviewed-by: default avatarDan Williams <dan.j.williams@intel.com>
      Cc: stable@vger.kernel.org # v6.0+
      Reviewed-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Link: https://lore.kernel.org/r/3051114102f41d19df3debbee123129118fc5e6d.1678543498.git.lukas@wunner.de
      
      
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      fbaa3821
    • Josh Poimboeuf's avatar
      entry: Fix noinstr warning in __enter_from_user_mode() · f87d2867
      Josh Poimboeuf authored
      
      
      __enter_from_user_mode() is triggering noinstr warnings with
      CONFIG_DEBUG_PREEMPT due to its call of preempt_count_add() via
      ct_state().
      
      The preemption disable isn't needed as interrupts are already disabled.
      And the context_tracking_enabled() check in ct_state() also isn't needed
      as that's already being done by the CT_WARN_ON().
      
      Just use __ct_state() instead.
      
      Fixes the following warnings:
      
        vmlinux.o: warning: objtool: enter_from_user_mode+0xba: call to preempt_count_add() leaves .noinstr.text section
        vmlinux.o: warning: objtool: syscall_enter_from_user_mode+0xf9: call to preempt_count_add() leaves .noinstr.text section
        vmlinux.o: warning: objtool: syscall_enter_from_user_mode_prepare+0xc7: call to preempt_count_add() leaves .noinstr.text section
        vmlinux.o: warning: objtool: irqentry_enter_from_user_mode+0xba: call to preempt_count_add() leaves .noinstr.text section
      
      Fixes: 17147677 ("context_tracking: Convert state to atomic_t")
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@kernel.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lore.kernel.org/r/d8955fa6d68dc955dda19baf13ae014ae27926f5.1677369694.git.jpoimboe@kernel.org
      f87d2867
    • Jens Axboe's avatar
      block/io_uring: pass in issue_flags for uring_cmd task_work handling · 9d2789ac
      Jens Axboe authored
      
      
      io_uring_cmd_done() currently assumes that the uring_lock is held
      when invoked, and while it generally is, this is not guaranteed.
      Pass in the issue_flags associated with it, so that we have
      IO_URING_F_UNLOCKED available to be able to lock the CQ ring
      appropriately when completing events.
      
      Cc: stable@vger.kernel.org
      Fixes: ee692a21 ("fs,io_uring: add infrastructure for uring-cmd")
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      9d2789ac
  14. Mar 19, 2023
  15. Mar 18, 2023
    • Hans de Goede's avatar
      efi: sysfb_efi: Fix DMI quirks not working for simpledrm · 3615c786
      Hans de Goede authored
      
      
      Commit 8633ef82 ("drivers/firmware: consolidate EFI framebuffer setup
      for all arches") moved the sysfb_apply_efi_quirks() call in sysfb_init()
      from before the [sysfb_]parse_mode() call to after it.
      But sysfb_apply_efi_quirks() modifies the global screen_info struct which
      [sysfb_]parse_mode() parses, so doing it later is too late.
      
      This has broken all DMI based quirks for correcting wrong firmware efifb
      settings when simpledrm is used.
      
      To fix this move the sysfb_apply_efi_quirks() call back to its old place
      and split the new setup of the efifb_fwnode (which requires
      the platform_device) into its own function and call that at
      the place of the moved sysfb_apply_efi_quirks(pd) calls.
      
      Fixes: 8633ef82 ("drivers/firmware: consolidate EFI framebuffer setup for all arches")
      Cc: stable@vger.kernel.org
      Cc: Javier Martinez Canillas <javierm@redhat.com>
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarJavier Martinez Canillas <javierm@redhat.com>
      Signed-off-by: default avatarArd Biesheuvel <ardb@kernel.org>
      3615c786
  16. Mar 17, 2023
  17. Mar 15, 2023
Loading