1. 01 2月, 2023 4 次提交
  2. 14 1月, 2023 1 次提交
    • A
      efi: tpm: Avoid READ_ONCE() for accessing the event log · d3f45053
      Ard Biesheuvel 提交于
      Nathan reports that recent kernels built with LTO will crash when doing
      EFI boot using Fedora's GRUB and SHIM. The culprit turns out to be a
      misaligned load from the TPM event log, which is annotated with
      READ_ONCE(), and under LTO, this gets translated into a LDAR instruction
      which does not tolerate misaligned accesses.
      
      Interestingly, this does not happen when booting the same kernel
      straight from the UEFI shell, and so the fact that the event log may
      appear misaligned in memory may be caused by a bug in GRUB or SHIM.
      
      However, using READ_ONCE() to access firmware tables is slightly unusual
      in any case, and here, we only need to ensure that 'event' is not
      dereferenced again after it gets unmapped, but this is already taken
      care of by the implicit barrier() semantics of the early_memunmap()
      call.
      
      Cc: <stable@vger.kernel.org>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Jarkko Sakkinen <jarkko@kernel.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Reported-by: NNathan Chancellor <nathan@kernel.org>
      Tested-by: NNathan Chancellor <nathan@kernel.org>
      Link: https://github.com/ClangBuiltLinux/linux/issues/1782Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      d3f45053
  3. 13 1月, 2023 2 次提交
  4. 12 1月, 2023 3 次提交
  5. 11 1月, 2023 1 次提交
    • H
      ACPI: Fix selecting wrong ACPI fwnode for the iGPU on some Dell laptops · f64e4275
      Hans de Goede 提交于
      The Dell Latitude E6430 both with and without the optional NVidia dGPU
      has a bug in its ACPI tables which is causing Linux to assign the wrong
      ACPI fwnode / companion to the pci_device for the i915 iGPU.
      
      Specifically under the PCI root bridge there are these 2 ACPI Device()s :
      
       Scope (_SB.PCI0)
       {
           Device (GFX0)
           {
               Name (_ADR, 0x00020000)  // _ADR: Address
           }
      
           ...
      
           Device (VID)
           {
               Name (_ADR, 0x00020000)  // _ADR: Address
               ...
      
               Method (_DOS, 1, NotSerialized)  // _DOS: Disable Output Switching
               {
                   VDP8 = Arg0
                   VDP1 (One, VDP8)
               }
      
               Method (_DOD, 0, NotSerialized)  // _DOD: Display Output Devices
               {
                   ...
               }
               ...
           }
       }
      
      The non-functional GFX0 ACPI device is a problem, because this gets
      returned as ACPI companion-device by acpi_find_child_device() for the iGPU.
      
      This is a long standing problem and the i915 driver does use the ACPI
      companion for some things, but works fine without it.
      
      However since commit 63f534b8 ("ACPI: PCI: Rework acpi_get_pci_dev()")
      acpi_get_pci_dev() relies on the physical-node pointer in the acpi_device
      and that is set on the wrong acpi_device because of the wrong
      acpi_find_child_device() return. This breaks the ACPI video code,
      leading to non working backlight control in some cases.
      
      Add a type.backlight flag, mark ACPI video bus devices with this and make
      find_child_checks() return a higher score for children with this flag set,
      so that it picks the right companion-device.
      
      Fixes: 63f534b8 ("ACPI: PCI: Rework acpi_get_pci_dev()")
      Co-developed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Cc: 6.1+ <stable@vger.kernel.org> # 6.1+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f64e4275
  6. 10 1月, 2023 1 次提交
    • M
      net/mlx5: Fix command stats access after free · da2e552b
      Moshe Shemesh 提交于
      Command may fail while driver is reloading and can't accept FW commands
      till command interface is reinitialized. Such command failure is being
      logged to command stats. This results in NULL pointer access as command
      stats structure is being freed and reallocated during mlx5 devlink
      reload (see kernel log below).
      
      Fix it by making command stats statically allocated on driver probe.
      
      Kernel log:
      [ 2394.808802] BUG: unable to handle kernel paging request at 000000000002a9c0
      [ 2394.810610] PGD 0 P4D 0
      [ 2394.811811] Oops: 0002 [#1] SMP NOPTI
      ...
      [ 2394.815482] RIP: 0010:native_queued_spin_lock_slowpath+0x183/0x1d0
      ...
      [ 2394.829505] Call Trace:
      [ 2394.830667]  _raw_spin_lock_irq+0x23/0x26
      [ 2394.831858]  cmd_status_err+0x55/0x110 [mlx5_core]
      [ 2394.833020]  mlx5_access_reg+0xe7/0x150 [mlx5_core]
      [ 2394.834175]  mlx5_query_port_ptys+0x78/0xa0 [mlx5_core]
      [ 2394.835337]  mlx5e_ethtool_get_link_ksettings+0x74/0x590 [mlx5_core]
      [ 2394.836454]  ? kmem_cache_alloc_trace+0x140/0x1c0
      [ 2394.837562]  __rh_call_get_link_ksettings+0x33/0x100
      [ 2394.838663]  ? __rtnl_unlock+0x25/0x50
      [ 2394.839755]  __ethtool_get_link_ksettings+0x72/0x150
      [ 2394.840862]  duplex_show+0x6e/0xc0
      [ 2394.841963]  dev_attr_show+0x1c/0x40
      [ 2394.843048]  sysfs_kf_seq_show+0x9b/0x100
      [ 2394.844123]  seq_read+0x153/0x410
      [ 2394.845187]  vfs_read+0x91/0x140
      [ 2394.846226]  ksys_read+0x4f/0xb0
      [ 2394.847234]  do_syscall_64+0x5b/0x1a0
      [ 2394.848228]  entry_SYSCALL_64_after_hwframe+0x65/0xca
      
      Fixes: 34f46ae0 ("net/mlx5: Add command failures data to debugfs")
      Signed-off-by: NMoshe Shemesh <moshe@nvidia.com>
      Reviewed-by: NShay Drory <shayd@nvidia.com>
      Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
      da2e552b
  7. 07 1月, 2023 1 次提交
  8. 06 1月, 2023 9 次提交
    • D
      rxrpc: Move client call connection to the I/O thread · 9d35d880
      David Howells 提交于
      Move the connection setup of client calls to the I/O thread so that a whole
      load of locking and barrierage can be eliminated.  This necessitates the
      app thread waiting for connection to complete before it can begin
      encrypting data.
      
      This also completes the fix for a race that exists between call connection
      and call disconnection whereby the data transmission code adds the call to
      the peer error distribution list after the call has been disconnected (say
      by the rxrpc socket getting closed).
      
      The fix is to complete the process of moving call connection, data
      transmission and call disconnection into the I/O thread and thus forcibly
      serialising them.
      
      Note that the issue may predate the overhaul to an I/O thread model that
      were included in the merge window for v6.2, but the timing is very much
      changed by the change given below.
      
      Fixes: cf37b598 ("rxrpc: Move DATA transmission into call processor work item")
      Reported-by: syzbot+c22650d2844392afdcfd@syzkaller.appspotmail.com
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Marc Dionne <marc.dionne@auristor.com>
      cc: linux-afs@lists.infradead.org
      9d35d880
    • D
      rxrpc: Set up a connection bundle from a call, not rxrpc_conn_parameters · 1bab27af
      David Howells 提交于
      Use the information now stored in struct rxrpc_call to configure the
      connection bundle and thence the connection, rather than using the
      rxrpc_conn_parameters struct.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Marc Dionne <marc.dionne@auristor.com>
      cc: linux-afs@lists.infradead.org
      1bab27af
    • D
      rxrpc: Offload the completion of service conn security to the I/O thread · 2953d3b8
      David Howells 提交于
      Offload the completion of the challenge/response cycle on a service
      connection to the I/O thread.  After the RESPONSE packet has been
      successfully decrypted and verified by the work queue, offloading the
      changing of the call states to the I/O thread makes iteration over the
      conn's channel list simpler.
      
      Do this by marking the RESPONSE skbuff and putting it onto the receive
      queue for the I/O thread to collect.  We put it on the front of the queue
      as we've already received the packet for it.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Marc Dionne <marc.dionne@auristor.com>
      cc: linux-afs@lists.infradead.org
      2953d3b8
    • D
      rxrpc: Tidy up abort generation infrastructure · 57af281e
      David Howells 提交于
      Tidy up the abort generation infrastructure in the following ways:
      
       (1) Create an enum and string mapping table to list the reasons an abort
           might be generated in tracing.
      
       (2) Replace the 3-char string with the values from (1) in the places that
           use that to log the abort source.  This gets rid of a memcpy() in the
           tracepoint.
      
       (3) Subsume the rxrpc_rx_eproto tracepoint with the rxrpc_abort tracepoint
           and use values from (1) to indicate the trace reason.
      
       (4) Always make a call to an abort function at the point of the abort
           rather than stashing the values into variables and using goto to get
           to a place where it reported.  The C optimiser will collapse the calls
           together as appropriate.  The abort functions return a value that can
           be returned directly if appropriate.
      
      Note that this extends into afs also at the points where that generates an
      abort.  To aid with this, the afs sources need to #define
      RXRPC_TRACE_ONLY_DEFINE_ENUMS before including the rxrpc tracing header
      because they don't have access to the rxrpc internal structures that some
      of the tracepoints make use of.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Marc Dionne <marc.dionne@auristor.com>
      cc: linux-afs@lists.infradead.org
      57af281e
    • D
      rxrpc: Clean up connection abort · a00ce28b
      David Howells 提交于
      Clean up connection abort, using the connection state_lock to gate access
      to change that state, and use an rxrpc_call_completion value to indicate
      the difference between local and remote aborts as these can be pasted
      directly into the call state.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Marc Dionne <marc.dionne@auristor.com>
      cc: linux-afs@lists.infradead.org
      a00ce28b
    • D
      rxrpc: Implement a mechanism to send an event notification to a connection · f2cce89a
      David Howells 提交于
      Provide a means by which an event notification can be sent to a connection
      through such that the I/O thread can pick it up and handle it rather than
      doing it in a separate workqueue.
      
      This is then used to move the deferred final ACK of a call into the I/O
      thread rather than a separate work queue as part of the drive to do all
      transmission from the I/O thread.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Marc Dionne <marc.dionne@auristor.com>
      cc: linux-afs@lists.infradead.org
      f2cce89a
    • D
      rxrpc: Only disconnect calls in the I/O thread · 03fc55ad
      David Howells 提交于
      Only perform call disconnection in the I/O thread to reduce the locking
      requirement.
      
      This is the first part of a fix for a race that exists between call
      connection and call disconnection whereby the data transmission code adds
      the call to the peer error distribution list after the call has been
      disconnected (say by the rxrpc socket getting closed).
      
      The fix is to complete the process of moving call connection, data
      transmission and call disconnection into the I/O thread and thus forcibly
      serialising them.
      
      Note that the issue may predate the overhaul to an I/O thread model that
      were included in the merge window for v6.2, but the timing is very much
      changed by the change given below.
      
      Fixes: cf37b598 ("rxrpc: Move DATA transmission into call processor work item")
      Reported-by: syzbot+c22650d2844392afdcfd@syzkaller.appspotmail.com
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Marc Dionne <marc.dionne@auristor.com>
      cc: linux-afs@lists.infradead.org
      03fc55ad
    • D
      rxrpc: Only set/transmit aborts in the I/O thread · a343b174
      David Howells 提交于
      Only set the abort call completion state in the I/O thread and only
      transmit ABORT packets from there.  rxrpc_abort_call() can then be made to
      actually send the packet.
      
      Further, ABORT packets should only be sent if the call has been exposed to
      the network (ie. at least one attempted DATA transmission has occurred for
      it).
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Marc Dionne <marc.dionne@auristor.com>
      cc: linux-afs@lists.infradead.org
      a343b174
    • D
      rxrpc: Make the local endpoint hold a ref on a connected call · 5040011d
      David Howells 提交于
      Make the local endpoint and it's I/O thread hold a reference on a connected
      call until that call is disconnected.  Without this, we're reliant on
      either the AF_RXRPC socket to hold a ref (which is dropped when the call is
      released) or a queued work item to hold a ref (the work item is being
      replaced with the I/O thread).
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Marc Dionne <marc.dionne@auristor.com>
      cc: linux-afs@lists.infradead.org
      5040011d
  9. 05 1月, 2023 5 次提交
  10. 02 1月, 2023 3 次提交
  11. 01 1月, 2023 2 次提交
  12. 30 12月, 2022 2 次提交
  13. 29 12月, 2022 3 次提交
  14. 28 12月, 2022 3 次提交