1. 29 4月, 2022 4 次提交
  2. 28 4月, 2022 11 次提交
    • Y
      net: fec: add missing of_node_put() in fec_enet_init_stop_mode() · d2b52ec0
      Yang Yingliang 提交于
      Put device node in error path in fec_enet_init_stop_mode().
      
      Fixes: 8a448bf8 ("net: ethernet: fec: move GPR register offset and bit into DT")
      Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
      Link: https://lore.kernel.org/r/20220426125231.375688-1-yangyingliang@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      d2b52ec0
    • M
      bnx2x: fix napi API usage sequence · af68656d
      Manish Chopra 提交于
      While handling PCI errors (AER flow) driver tries to
      disable NAPI [napi_disable()] after NAPI is deleted
      [__netif_napi_del()] which causes unexpected system
      hang/crash.
      
      System message log shows the following:
      =======================================
      [ 3222.537510] EEH: Detected PCI bus error on PHB#384-PE#800000 [ 3222.537511] EEH: This PCI device has failed 2 times in the last hour and will be permanently disabled after 5 failures.
      [ 3222.537512] EEH: Notify device drivers to shutdown [ 3222.537513] EEH: Beginning: 'error_detected(IO frozen)'
      [ 3222.537514] EEH: PE#800000 (PCI 0384:80:00.0): Invoking
      bnx2x->error_detected(IO frozen)
      [ 3222.537516] bnx2x: [bnx2x_io_error_detected:14236(eth14)]IO error detected [ 3222.537650] EEH: PE#800000 (PCI 0384:80:00.0): bnx2x driver reports:
      'need reset'
      [ 3222.537651] EEH: PE#800000 (PCI 0384:80:00.1): Invoking
      bnx2x->error_detected(IO frozen)
      [ 3222.537651] bnx2x: [bnx2x_io_error_detected:14236(eth13)]IO error detected [ 3222.537729] EEH: PE#800000 (PCI 0384:80:00.1): bnx2x driver reports:
      'need reset'
      [ 3222.537729] EEH: Finished:'error_detected(IO frozen)' with aggregate recovery state:'need reset'
      [ 3222.537890] EEH: Collect temporary log [ 3222.583481] EEH: of node=0384:80:00.0 [ 3222.583519] EEH: PCI device/vendor: 168e14e4 [ 3222.583557] EEH: PCI cmd/status register: 00100140 [ 3222.583557] EEH: PCI-E capabilities and status follow:
      [ 3222.583744] EEH: PCI-E 00: 00020010 012c8da2 00095d5e 00455c82 [ 3222.583892] EEH: PCI-E 10: 10820000 00000000 00000000 00000000 [ 3222.583893] EEH: PCI-E 20: 00000000 [ 3222.583893] EEH: PCI-E AER capability register set follows:
      [ 3222.584079] EEH: PCI-E AER 00: 13c10001 00000000 00000000 00062030 [ 3222.584230] EEH: PCI-E AER 10: 00002000 000031c0 000001e0 00000000 [ 3222.584378] EEH: PCI-E AER 20: 00000000 00000000 00000000 00000000 [ 3222.584416] EEH: PCI-E AER 30: 00000000 00000000 [ 3222.584416] EEH: of node=0384:80:00.1 [ 3222.584454] EEH: PCI device/vendor: 168e14e4 [ 3222.584491] EEH: PCI cmd/status register: 00100140 [ 3222.584492] EEH: PCI-E capabilities and status follow:
      [ 3222.584677] EEH: PCI-E 00: 00020010 012c8da2 00095d5e 00455c82 [ 3222.584825] EEH: PCI-E 10: 10820000 00000000 00000000 00000000 [ 3222.584826] EEH: PCI-E 20: 00000000 [ 3222.584826] EEH: PCI-E AER capability register set follows:
      [ 3222.585011] EEH: PCI-E AER 00: 13c10001 00000000 00000000 00062030 [ 3222.585160] EEH: PCI-E AER 10: 00002000 000031c0 000001e0 00000000 [ 3222.585309] EEH: PCI-E AER 20: 00000000 00000000 00000000 00000000 [ 3222.585347] EEH: PCI-E AER 30: 00000000 00000000 [ 3222.586872] RTAS: event: 5, Type: Platform Error (224), Severity: 2 [ 3222.586873] EEH: Reset without hotplug activity [ 3224.762767] EEH: Beginning: 'slot_reset'
      [ 3224.762770] EEH: PE#800000 (PCI 0384:80:00.0): Invoking
      bnx2x->slot_reset()
      [ 3224.762771] bnx2x: [bnx2x_io_slot_reset:14271(eth14)]IO slot reset initializing...
      [ 3224.762887] bnx2x 0384:80:00.0: enabling device (0140 -> 0142) [ 3224.768157] bnx2x: [bnx2x_io_slot_reset:14287(eth14)]IO slot reset
      --> driver unload
      
      Uninterruptible tasks
      =====================
      crash> ps | grep UN
           213      2  11  c000000004c89e00  UN   0.0       0      0  [eehd]
           215      2   0  c000000004c80000  UN   0.0       0      0
      [kworker/0:2]
          2196      1  28  c000000004504f00  UN   0.1   15936  11136  wickedd
          4287      1   9  c00000020d076800  UN   0.0    4032   3008  agetty
          4289      1  20  c00000020d056680  UN   0.0    7232   3840  agetty
         32423      2  26  c00000020038c580  UN   0.0       0      0
      [kworker/26:3]
         32871   4241  27  c0000002609ddd00  UN   0.1   18624  11648  sshd
         32920  10130  16  c00000027284a100  UN   0.1   48512  12608  sendmail
         33092  32987   0  c000000205218b00  UN   0.1   48512  12608  sendmail
         33154   4567  16  c000000260e51780  UN   0.1   48832  12864  pickup
         33209   4241  36  c000000270cb6500  UN   0.1   18624  11712  sshd
         33473  33283   0  c000000205211480  UN   0.1   48512  12672  sendmail
         33531   4241  37  c00000023c902780  UN   0.1   18624  11648  sshd
      
      EEH handler hung while bnx2x sleeping and holding RTNL lock
      ===========================================================
      crash> bt 213
      PID: 213    TASK: c000000004c89e00  CPU: 11  COMMAND: "eehd"
        #0 [c000000004d477e0] __schedule at c000000000c70808
        #1 [c000000004d478b0] schedule at c000000000c70ee0
        #2 [c000000004d478e0] schedule_timeout at c000000000c76dec
        #3 [c000000004d479c0] msleep at c0000000002120cc
        #4 [c000000004d479f0] napi_disable at c000000000a06448
                                              ^^^^^^^^^^^^^^^^
        #5 [c000000004d47a30] bnx2x_netif_stop at c0080000018dba94 [bnx2x]
        #6 [c000000004d47a60] bnx2x_io_slot_reset at c0080000018a551c [bnx2x]
        #7 [c000000004d47b20] eeh_report_reset at c00000000004c9bc
        #8 [c000000004d47b90] eeh_pe_report at c00000000004d1a8
        #9 [c000000004d47c40] eeh_handle_normal_event at c00000000004da64
      
      And the sleeping source code
      ============================
      crash> dis -ls c000000000a06448
      FILE: ../net/core/dev.c
      LINE: 6702
      
         6697  {
         6698          might_sleep();
         6699          set_bit(NAPI_STATE_DISABLE, &n->state);
         6700
         6701          while (test_and_set_bit(NAPI_STATE_SCHED, &n->state))
      * 6702                  msleep(1);
         6703          while (test_and_set_bit(NAPI_STATE_NPSVC, &n->state))
         6704                  msleep(1);
         6705
         6706          hrtimer_cancel(&n->timer);
         6707
         6708          clear_bit(NAPI_STATE_DISABLE, &n->state);
         6709  }
      
      EEH calls into bnx2x twice based on the system log above, first through
      bnx2x_io_error_detected() and then bnx2x_io_slot_reset(), and executes
      the following call chains:
      
      bnx2x_io_error_detected()
        +-> bnx2x_eeh_nic_unload()
             +-> bnx2x_del_all_napi()
                  +-> __netif_napi_del()
      
      bnx2x_io_slot_reset()
        +-> bnx2x_netif_stop()
             +-> bnx2x_napi_disable()
                  +->napi_disable()
      
      Fix this by correcting the sequence of NAPI APIs usage,
      that is delete the NAPI after disabling it.
      
      Fixes: 7fa6f340 ("bnx2x: AER revised")
      Reported-by: NDavid Christensen <drc@linux.vnet.ibm.com>
      Tested-by: NDavid Christensen <drc@linux.vnet.ibm.com>
      Signed-off-by: NManish Chopra <manishc@marvell.com>
      Signed-off-by: NAriel Elior <aelior@marvell.com>
      Link: https://lore.kernel.org/r/20220426153913.6966-1-manishc@marvell.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      af68656d
    • P
      drm/amdgpu: keep mmhub clock gating being enabled during s2idle suspend · fb8cc331
      Prike Liang 提交于
      Without MMHUB clock gating being enabled then MMHUB will not disconnect
      from DF and will result in DF C-state entry can't be accessed during S2idle
      suspend, and eventually s0ix entry will be blocked.
      Signed-off-by: NPrike Liang <Prike.Liang@amd.com>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      fb8cc331
    • E
      drm/amd/pm: fix the deadlock issue observed on SI · a71849cd
      Evan Quan 提交于
      The adev->pm.mutx is already held at the beginning of
      amdgpu_dpm_compute_clocks/amdgpu_dpm_enable_uvd/amdgpu_dpm_enable_vce.
      But on their calling path, amdgpu_display_bandwidth_update will be
      called and thus its sub functions amdgpu_dpm_get_sclk/mclk. They
      will then try to acquire the same adev->pm.mutex and deadlock will
      occur.
      
      By placing amdgpu_display_bandwidth_update outside of adev->pm.mutex
      protection(considering logically they do not need such protection) and
      restructuring the call flow accordingly, we can eliminate the deadlock
      issue. This comes with no real logics change.
      
      Fixes: 3712e7a4 ("drm/amd/pm: unified lock protections in amdgpu_dpm.c")
      Reported-by: NPaul Menzel <pmenzel@molgen.mpg.de>
      Reported-by: NArthur Marsh <arthur.marsh@internode.on.net>
      Link: https://lore.kernel.org/all/9e689fea-6c69-f4b0-8dee-32c4cf7d8f9c@molgen.mpg.de/
      BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1957Signed-off-by: NEvan Quan <evan.quan@amd.com>
      Reviewed-by: NLijo Lazar <lijo.lazar@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      a71849cd
    • M
      drm/amd/display: Fix memory leak in dcn21_clock_source_create · 65e54987
      Miaoqian Lin 提交于
      When dcn20_clk_src_construct() fails, we need to release clk_src.
      
      Fixes: 6f4e6361 ("drm/amd/display: Add Renoir resource (v2)")
      Signed-off-by: NMiaoqian Lin <linmq006@gmail.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      65e54987
    • A
      drm/amdgpu: don't runtime suspend if there are displays attached (v3) · f95af4a9
      Alex Deucher 提交于
      We normally runtime suspend when there are displays attached if they
      are in the DPMS off state, however, if something wakes the GPU
      we send a hotplug event on resume (in case any displays were connected
      while the GPU was in suspend) which can cause userspace to light
      up the displays again soon after they were turned off.
      
      Prior to
      commit 087451f3 ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's."),
      the driver took a runtime pm reference when the fbdev emulation was
      enabled because we didn't implement proper shadowing support for
      vram access when the device was off so the device never runtime
      suspended when there was a console bound.  Once that commit landed,
      we now utilize the core fb helper implementation which properly
      handles the emulation, so runtime pm now suspends in cases where it did
      not before.  Ultimately, we need to sort out why runtime suspend in not
      working in this case for some users, but this should restore similar
      behavior to before.
      
      v2: move check into runtime_suspend
      v3: wake ups -> wakeups in comment, retain pm_runtime behavior in
          runtime_idle callback
      
      Fixes: 087451f3 ("drm/amdgpu: use generic fb helpers instead of setting up AMD own's.")
      Link: https://lore.kernel.org/r/20220403132322.51c90903@darkstar.example.org/Tested-by: NMichele Ballabio <ballabio.m@gmail.com>
      Reviewed-by: NEvan Quan <evan.quan@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      f95af4a9
    • D
      drm/amdkfd: CRIU add support for GWS queues · f567656f
      David Yat Sin 提交于
      Add support to checkpoint/restore GWS (Global Wave Sync) queues.
      Signed-off-by: NDavid Yat Sin <david.yatsin@amd.com>
      Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      f567656f
    • D
      drm/amdkfd: Fix GWS queue count · 7c6b6e18
      David Yat Sin 提交于
      dqm->gws_queue_count and pdd->qpd.mapped_gws_queue need to be updated
      each time the queue gets evicted.
      
      Fixes: b8020b03 ("drm/amdkfd: Enable over-subscription with >1 GWS queue")
      Signed-off-by: NDavid Yat Sin <david.yatsin@amd.com>
      Reviewed-by: NFelix Kuehling <Felix.Kuehling@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      7c6b6e18
    • A
      intel_idle: Fix SPR C6 optimization · 7eac3bd3
      Artem Bityutskiy 提交于
      The Sapphire Rapids (SPR) C6 optimization was added to the end of the
      'spr_idle_state_table_update()' function. However, the function has a
      'return' which may happen before the optimization has a chance to run.
      And this may prevent the optimization from happening.
      
      This is an unlikely scenario, but possible if user boots with, say,
      the 'intel_idle.preferred_cstates=6' kernel boot option.
      
      This patch fixes the issue by eliminating the problematic 'return'
      statement.
      
      Fixes: 3a9cf77b ("intel_idle: add core C6 optimization for SPR")
      Suggested-by: NJan Beulich <jbeulich@suse.com>
      Reported-by: NJan Beulich <jbeulich@suse.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      [ rjw: Minor changelog edits ]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7eac3bd3
    • A
      intel_idle: Fix the 'preferred_cstates' module parameter · 39c184a6
      Artem Bityutskiy 提交于
      Problem description.
      
      When user boots kernel up with the 'intel_idle.preferred_cstates=4' option,
      we enable C1E and disable C1 states on Sapphire Rapids Xeon (SPR). In order
      for C1E to work on SPR, we have to enable the C1E promotion bit on all
      CPUs.  However, we enable it only on one CPU.
      
      Fix description.
      
      The 'intel_idle' driver already has the infrastructure for disabling C1E
      promotion on every CPU. This patch uses the same infrastructure for
      enabling C1E promotion on every CPU. It changes the boolean
      'disable_promotion_to_c1e' variable to a tri-state 'c1e_promotion'
      variable.
      
      Tested on a 2-socket SPR system. I verified the following combinations:
      
       * C1E promotion enabled and disabled in BIOS.
       * Booted with and without the 'intel_idle.preferred_cstates=4' kernel
         argument.
      
      In all 4 cases C1E promotion was correctly set on all CPUs.
      
      Also tested on an old Broadwell system, just to make sure it does not cause
      a regression. C1E promotion was correctly disabled on that system, both C1
      and C1E were exposed (as expected).
      
      Fixes: da0e58c0 ("intel_idle: add 'preferred_cstates' module argument")
      Reported-by: NJan Beulich <jbeulich@suse.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      [ rjw: Minor changelog edits ]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      39c184a6
    • W
      floppy: disable FDRAWCMD by default · 233087ca
      Willy Tarreau 提交于
      Minh Yuan reported a concurrency use-after-free issue in the floppy code
      between raw_cmd_ioctl and seek_interrupt.
      
      [ It turns out this has been around, and that others have reported the
        KASAN splats over the years, but Minh Yuan had a reproducer for it and
        so gets primary credit for reporting it for this fix   - Linus ]
      
      The problem is, this driver tends to break very easily and nowadays,
      nobody is expected to use FDRAWCMD anyway since it was used to
      manipulate non-standard formats.  The risk of breaking the driver is
      higher than the risk presented by this race, and accessing the device
      requires privileges anyway.
      
      Let's just add a config option to completely disable this ioctl and
      leave it disabled by default.  Distros shouldn't use it, and only those
      running on antique hardware might need to enable it.
      
      Link: https://lore.kernel.org/all/000000000000b71cdd05d703f6bf@google.com/
      Link: https://lore.kernel.org/lkml/CAKcFiNC=MfYVW-Jt9A3=FPJpTwCD2PL_ULNCpsCVE5s8ZeBQgQ@mail.gmail.com
      Link: https://lore.kernel.org/all/CAEAjamu1FRhz6StCe_55XY5s389ZP_xmCF69k987En+1z53=eg@mail.gmail.comReported-by: NMinh Yuan <yuanmingbuaa@gmail.com>
      Reported-by: syzbot+8e8958586909d62b6840@syzkaller.appspotmail.com
      Reported-by: Ncruise k <cruise4k@gmail.com>
      Reported-by: NKyungtae Kim <kt0755@gmail.com>
      Suggested-by: NLinus Torvalds <torvalds@linuxfoundation.org>
      Tested-by: NDenis Efremov <efremov@linux.com>
      Signed-off-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      233087ca
  3. 27 4月, 2022 14 次提交
    • T
      platform/x86/intel: pmc/core: change pmc_lpm_modes to static · eb2fd9b4
      Tom Rix 提交于
      Sparse reports this issue
      core.c: note: in included file:
      core.h:239:12: warning: symbol 'pmc_lpm_modes' was not declared. Should it be static?
      
      Global variables should not be defined in headers.  This only works
      because core.h is only included by core.c. Single file use
      variables should be static, so change its storage-class specifier
      to static.
      Signed-off-by: NTom Rix <trix@redhat.com>
      Reviewed-by: NDavid E. Box <david.e.box@linux.intel.com>
      Link: https://lore.kernel.org/r/20220423123048.591405-1-trix@redhat.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
      eb2fd9b4
    • D
      platform/x86/intel/sdsi: Fix bug in multi packet reads · 00dd3ace
      David E. Box 提交于
      Fix bug that added an offset to the mailbox addr during multi-packet
      reads. Did not affect current ABI since it doesn't support multi-packet
      transactions.
      
      Fixes: 2546c600 ("platform/x86: Add Intel Software Defined Silicon driver")
      Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
      Link: https://lore.kernel.org/r/20220420155622.1763633-4-david.e.box@linux.intel.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      00dd3ace
    • D
      platform/x86/intel/sdsi: Poll on ready bit for writes · a30393b3
      David E. Box 提交于
      Due to change in firmware flow, update mailbox writes to poll on ready bit
      instead of run_busy bit. This change makes the polling method consistent
      for both writes and reads, which also uses the ready bit.
      
      Fixes: 2546c600 ("platform/x86: Add Intel Software Defined Silicon driver")
      Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
      Link: https://lore.kernel.org/r/20220420155622.1763633-3-david.e.box@linux.intel.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      a30393b3
    • D
      platform/x86/intel/sdsi: Handle leaky bucket · 679c7a3f
      David E. Box 提交于
      To prevent an agent from indefinitely holding the mailbox firmware has
      implemented a leaky bucket algorithm. Repeated access to the mailbox may
      now incur a delay of up to 2.1 seconds. Add a retry loop that tries for
      up to 2.5 seconds to acquire the mailbox.
      
      Fixes: 2546c600 ("platform/x86: Add Intel Software Defined Silicon driver")
      Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
      Link: https://lore.kernel.org/r/20220420155622.1763633-2-david.e.box@linux.intel.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      679c7a3f
    • S
      platform/x86: intel-uncore-freq: Prevent driver loading in guests · 8d75f7b4
      Srinivas Pandruvada 提交于
      Loading this driver in guests results in unchecked MSR access error for
      MSR 0x620.
      
      There is no use of reading and modifying package/die scope uncore MSRs
      in guests. So check for CPU feature X86_FEATURE_HYPERVISOR to prevent
      loading of this driver in guests.
      
      Fixes: dbce412a ("platform/x86/intel-uncore-freq: Split common and enumeration part")
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215870Suggested-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Link: https://lore.kernel.org/r/20220427100304.2562990-1-srinivas.pandruvada@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
      8d75f7b4
    • D
    • G
      platform/x86: dell-laptop: Add quirk entry for Latitude 7520 · 89a8f23f
      Gabriele Mazzotta 提交于
      The Latitude 7520 supports AC timeouts, but it has no KBD_LED_AC_TOKEN
      and so changes to stop_timeout appear to have no effect if the laptop
      is plugged in.
      Signed-off-by: NGabriele Mazzotta <gabriele.mzt@gmail.com>
      Acked-by: NPali Rohár <pali@kernel.org>
      Link: https://lore.kernel.org/r/20220426120827.12363-1-gabriele.mzt@gmail.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
      89a8f23f
    • H
      platform/x86: asus-wmi: Fix driver not binding when fan curve control probe fails · 9fe1bb29
      Hans de Goede 提交于
      Before this commit fan_curve_check_present() was trying to not cause
      the probe to fail on devices without fan curve control by testing for
      known error codes returned by asus_wmi_evaluate_method_buf().
      
      Checking for ENODATA or ENODEV, with the latter being returned by this
      function when an ACPI integer with a value of ASUS_WMI_UNSUPPORTED_METHOD
      is returned. But for other ACPI integer returns this function just returns
      them as is, including the ASUS_WMI_DSTS_UNKNOWN_BIT value of 2.
      
      On the Asus U36SD ASUS_WMI_DSTS_UNKNOWN_BIT gets returned, leading to:
      
        asus-nb-wmi: probe of asus-nb-wmi failed with error 2
      
      Instead of playing whack a mole with error codes here, simply treat all
      errors as there not being any fan curves, fixing the driver no longer
      loading on the Asus U36SD laptop.
      
      Fixes: e3d13da7 ("platform/x86: asus-wmi: Fix regression when probing for fan curve control")
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2079125
      Cc: Luke D. Jones <luke@ljones.dev>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Link: https://lore.kernel.org/r/20220427114956.332919-1-hdegoede@redhat.com
      9fe1bb29
    • D
      platform/x86: asus-wmi: Potential buffer overflow in asus_wmi_evaluate_method_buf() · 4345ece8
      Dan Carpenter 提交于
      This code tests for if the obj->buffer.length is larger than the buffer
      but then it just does the memcpy() anyway.
      
      Fixes: 0f0ac158 ("platform/x86: asus-wmi: Add support for custom fan curves")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Link: https://lore.kernel.org/r/20220413073744.GB8812@kiliReviewed-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      4345ece8
    • M
      net: dsa: lantiq_gswip: Don't set GSWIP_MII_CFG_RMII_CLK · 71cffebf
      Martin Blumenstingl 提交于
      Commit 4b592324 ("net: dsa: lantiq_gswip: Configure all remaining
      GSWIP_MII_CFG bits") added all known bits in the GSWIP_MII_CFGp
      register. It helped bring this register into a well-defined state so the
      driver has to rely less on the bootloader to do things right.
      Unfortunately it also sets the GSWIP_MII_CFG_RMII_CLK bit without any
      possibility to configure it. Upon further testing it turns out that all
      boards which are supported by the GSWIP driver in OpenWrt which use an
      RMII PHY have a dedicated oscillator on the board which provides the
      50MHz RMII reference clock.
      
      Don't set the GSWIP_MII_CFG_RMII_CLK bit (but keep the code which always
      clears it) to fix support for the Fritz!Box 7362 SL in OpenWrt. This is
      a board with two Atheros AR8030 RMII PHYs. With the "RMII clock" bit set
      the MAC also generates the RMII reference clock whose signal then
      conflicts with the signal from the oscillator on the board. This results
      in a constant cycle of the PHY detecting link up/down (and as a result
      of that: the two ports using the AR8030 PHYs are not working).
      
      At the time of writing this patch there's no known board where the MAC
      (GSWIP) has to generate the RMII reference clock. If needed this can be
      implemented in future by providing a device-tree flag so the
      GSWIP_MII_CFG_RMII_CLK bit can be toggled per port.
      
      Fixes: 4b592324 ("net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits")
      Tested-by: NJan Hoffmann <jan@3e8.eu>
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Acked-by: NHauke Mehrtens <hauke@hauke-m.de>
      Link: https://lore.kernel.org/r/20220425152027.2220750-1-martin.blumenstingl@googlemail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      71cffebf
    • J
      ice: fix use-after-free when deinitializing mailbox snapshot · b668f4cd
      Jacob Keller 提交于
      During ice_sriov_configure, if num_vfs is 0, we are being asked by the
      kernel to remove all VFs.
      
      The driver first de-initializes the snapshot before freeing all the VFs.
      This results in a use-after-free BUG detected by KASAN. The bug occurs
      because the snapshot can still be accessed until all VFs are removed.
      
      Fix this by freeing all the VFs first before calling
      ice_mbx_deinit_snapshot.
      
      [  +0.032591] ==================================================================
      [  +0.000021] BUG: KASAN: use-after-free in ice_mbx_vf_state_handler+0x1c3/0x410 [ice]
      [  +0.000315] Write of size 28 at addr ffff889908eb6f28 by task kworker/55:2/1530996
      
      [  +0.000029] CPU: 55 PID: 1530996 Comm: kworker/55:2 Kdump: loaded Tainted: G S        I       5.17.0-dirty #1
      [  +0.000022] Hardware name: Dell Inc. PowerEdge R740/0923K0, BIOS 1.6.13 12/17/2018
      [  +0.000013] Workqueue: ice ice_service_task [ice]
      [  +0.000279] Call Trace:
      [  +0.000012]  <TASK>
      [  +0.000011]  dump_stack_lvl+0x33/0x42
      [  +0.000030]  print_report.cold.13+0xb2/0x6b3
      [  +0.000028]  ? ice_mbx_vf_state_handler+0x1c3/0x410 [ice]
      [  +0.000295]  kasan_report+0xa5/0x120
      [  +0.000026]  ? __switch_to_asm+0x21/0x70
      [  +0.000024]  ? ice_mbx_vf_state_handler+0x1c3/0x410 [ice]
      [  +0.000298]  kasan_check_range+0x183/0x1e0
      [  +0.000019]  memset+0x1f/0x40
      [  +0.000018]  ice_mbx_vf_state_handler+0x1c3/0x410 [ice]
      [  +0.000304]  ? ice_conv_link_speed_to_virtchnl+0x160/0x160 [ice]
      [  +0.000297]  ? ice_vsi_dis_spoofchk+0x40/0x40 [ice]
      [  +0.000305]  ice_is_malicious_vf+0x1aa/0x250 [ice]
      [  +0.000303]  ? ice_restore_all_vfs_msi_state+0x160/0x160 [ice]
      [  +0.000297]  ? __mutex_unlock_slowpath.isra.15+0x410/0x410
      [  +0.000022]  ? ice_debug_cq+0xb7/0x230 [ice]
      [  +0.000273]  ? __kasan_slab_alloc+0x2f/0x90
      [  +0.000022]  ? memset+0x1f/0x40
      [  +0.000017]  ? do_raw_spin_lock+0x119/0x1d0
      [  +0.000022]  ? rwlock_bug.part.2+0x60/0x60
      [  +0.000024]  __ice_clean_ctrlq+0x3a6/0xd60 [ice]
      [  +0.000273]  ? newidle_balance+0x5b1/0x700
      [  +0.000026]  ? ice_print_link_msg+0x2f0/0x2f0 [ice]
      [  +0.000271]  ? update_cfs_group+0x1b/0x140
      [  +0.000018]  ? load_balance+0x1260/0x1260
      [  +0.000022]  ? ice_process_vflr_event+0x27/0x130 [ice]
      [  +0.000301]  ice_service_task+0x136e/0x1470 [ice]
      [  +0.000281]  process_one_work+0x3b4/0x6c0
      [  +0.000030]  worker_thread+0x65/0x660
      [  +0.000023]  ? __kthread_parkme+0xe4/0x100
      [  +0.000021]  ? process_one_work+0x6c0/0x6c0
      [  +0.000020]  kthread+0x179/0x1b0
      [  +0.000018]  ? kthread_complete_and_exit+0x20/0x20
      [  +0.000022]  ret_from_fork+0x22/0x30
      [  +0.000026]  </TASK>
      
      [  +0.000018] Allocated by task 10742:
      [  +0.000013]  kasan_save_stack+0x1c/0x40
      [  +0.000018]  __kasan_kmalloc+0x84/0xa0
      [  +0.000016]  kmem_cache_alloc_trace+0x16c/0x2e0
      [  +0.000015]  intel_iommu_probe_device+0xeb/0x860
      [  +0.000015]  __iommu_probe_device+0x9a/0x2f0
      [  +0.000016]  iommu_probe_device+0x43/0x270
      [  +0.000015]  iommu_bus_notifier+0xa7/0xd0
      [  +0.000015]  blocking_notifier_call_chain+0x90/0xc0
      [  +0.000017]  device_add+0x5f3/0xd70
      [  +0.000014]  pci_device_add+0x404/0xa40
      [  +0.000015]  pci_iov_add_virtfn+0x3b0/0x550
      [  +0.000016]  sriov_enable+0x3bb/0x600
      [  +0.000013]  ice_ena_vfs+0x113/0xa79 [ice]
      [  +0.000293]  ice_sriov_configure.cold.17+0x21/0xe0 [ice]
      [  +0.000291]  sriov_numvfs_store+0x160/0x200
      [  +0.000015]  kernfs_fop_write_iter+0x1db/0x270
      [  +0.000018]  new_sync_write+0x21d/0x330
      [  +0.000013]  vfs_write+0x376/0x410
      [  +0.000013]  ksys_write+0xba/0x150
      [  +0.000012]  do_syscall_64+0x3a/0x80
      [  +0.000012]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      [  +0.000028] Freed by task 10742:
      [  +0.000011]  kasan_save_stack+0x1c/0x40
      [  +0.000015]  kasan_set_track+0x21/0x30
      [  +0.000016]  kasan_set_free_info+0x20/0x30
      [  +0.000012]  __kasan_slab_free+0x104/0x170
      [  +0.000016]  kfree+0x9b/0x470
      [  +0.000013]  devres_destroy+0x1c/0x20
      [  +0.000015]  devm_kfree+0x33/0x40
      [  +0.000012]  ice_mbx_deinit_snapshot+0x39/0x70 [ice]
      [  +0.000295]  ice_sriov_configure+0xb0/0x260 [ice]
      [  +0.000295]  sriov_numvfs_store+0x1bc/0x200
      [  +0.000015]  kernfs_fop_write_iter+0x1db/0x270
      [  +0.000016]  new_sync_write+0x21d/0x330
      [  +0.000012]  vfs_write+0x376/0x410
      [  +0.000012]  ksys_write+0xba/0x150
      [  +0.000012]  do_syscall_64+0x3a/0x80
      [  +0.000012]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      [  +0.000024] Last potentially related work creation:
      [  +0.000010]  kasan_save_stack+0x1c/0x40
      [  +0.000016]  __kasan_record_aux_stack+0x98/0xa0
      [  +0.000013]  insert_work+0x34/0x160
      [  +0.000015]  __queue_work+0x20e/0x650
      [  +0.000016]  queue_work_on+0x4c/0x60
      [  +0.000015]  nf_nat_masq_schedule+0x297/0x2e0 [nf_nat]
      [  +0.000034]  masq_device_event+0x5a/0x60 [nf_nat]
      [  +0.000031]  raw_notifier_call_chain+0x5f/0x80
      [  +0.000017]  dev_close_many+0x1d6/0x2c0
      [  +0.000015]  unregister_netdevice_many+0x4e3/0xa30
      [  +0.000015]  unregister_netdevice_queue+0x192/0x1d0
      [  +0.000014]  iavf_remove+0x8f9/0x930 [iavf]
      [  +0.000058]  pci_device_remove+0x65/0x110
      [  +0.000015]  device_release_driver_internal+0xf8/0x190
      [  +0.000017]  pci_stop_bus_device+0xb5/0xf0
      [  +0.000014]  pci_stop_and_remove_bus_device+0xe/0x20
      [  +0.000016]  pci_iov_remove_virtfn+0x19c/0x230
      [  +0.000015]  sriov_disable+0x4f/0x170
      [  +0.000014]  ice_free_vfs+0x9a/0x490 [ice]
      [  +0.000306]  ice_sriov_configure+0xb8/0x260 [ice]
      [  +0.000294]  sriov_numvfs_store+0x1bc/0x200
      [  +0.000015]  kernfs_fop_write_iter+0x1db/0x270
      [  +0.000016]  new_sync_write+0x21d/0x330
      [  +0.000012]  vfs_write+0x376/0x410
      [  +0.000012]  ksys_write+0xba/0x150
      [  +0.000012]  do_syscall_64+0x3a/0x80
      [  +0.000012]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      [  +0.000025] The buggy address belongs to the object at ffff889908eb6f00
                     which belongs to the cache kmalloc-96 of size 96
      [  +0.000016] The buggy address is located 40 bytes inside of
                     96-byte region [ffff889908eb6f00, ffff889908eb6f60)
      
      [  +0.000026] The buggy address belongs to the physical page:
      [  +0.000010] page:00000000b7e99a2e refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1908eb6
      [  +0.000016] flags: 0x57ffffc0000200(slab|node=1|zone=2|lastcpupid=0x1fffff)
      [  +0.000024] raw: 0057ffffc0000200 ffffea0069d9fd80 dead000000000002 ffff88810004c780
      [  +0.000015] raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
      [  +0.000009] page dumped because: kasan: bad access detected
      
      [  +0.000016] Memory state around the buggy address:
      [  +0.000012]  ffff889908eb6e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
      [  +0.000014]  ffff889908eb6e80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
      [  +0.000014] >ffff889908eb6f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
      [  +0.000011]                                   ^
      [  +0.000013]  ffff889908eb6f80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
      [  +0.000013]  ffff889908eb7000: fa fb fb fb fb fb fb fb fc fc fc fc fa fb fb fb
      [  +0.000012] ==================================================================
      
      Fixes: 0891c896 ("ice: warn about potentially malicious VFs")
      Reported-by: NSlawomir Laba <slawomirx.laba@intel.com>
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      b668f4cd
    • P
      ice: wait 5 s for EMP reset after firmware flash · b537752e
      Petr Oros 提交于
      We need to wait 5 s for EMP reset after firmware flash. Code was extracted
      from OOT driver (ice v1.8.3 downloaded from sourceforge). Without this
      wait, fw_activate let card in inconsistent state and recoverable only
      by second flash/activate. Flash was tested on these fw's:
      From -> To
       3.00 -> 3.10/3.20
       3.10 -> 3.00/3.20
       3.20 -> 3.00/3.10
      
      Reproducer:
      [root@host ~]# devlink dev flash pci/0000:ca:00.0 file E810_XXVDA4_FH_O_SEC_FW_1p6p1p9_NVM_3p10_PLDMoMCTP_0.11_8000AD7B.bin
      Preparing to flash
      [fw.mgmt] Erasing
      [fw.mgmt] Erasing done
      [fw.mgmt] Flashing 100%
      [fw.mgmt] Flashing done 100%
      [fw.undi] Erasing
      [fw.undi] Erasing done
      [fw.undi] Flashing 100%
      [fw.undi] Flashing done 100%
      [fw.netlist] Erasing
      [fw.netlist] Erasing done
      [fw.netlist] Flashing 100%
      [fw.netlist] Flashing done 100%
      Activate new firmware by devlink reload
      [root@host ~]# devlink dev reload pci/0000:ca:00.0 action fw_activate
      reload_actions_performed:
          fw_activate
      [root@host ~]# ip link show ens7f0
      71: ens7f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000
          link/ether b4:96:91:dc:72:e0 brd ff:ff:ff:ff:ff:ff
          altname enp202s0f0
      
      dmesg after flash:
      [   55.120788] ice: Copyright (c) 2018, Intel Corporation.
      [   55.274734] ice 0000:ca:00.0: Get PHY capabilities failed status = -5, continuing anyway
      [   55.569797] ice 0000:ca:00.0: The DDP package was successfully loaded: ICE OS Default Package version 1.3.28.0
      [   55.603629] ice 0000:ca:00.0: Get PHY capability failed.
      [   55.608951] ice 0000:ca:00.0: ice_init_nvm_phy_type failed: -5
      [   55.647348] ice 0000:ca:00.0: PTP init successful
      [   55.675536] ice 0000:ca:00.0: DCB is enabled in the hardware, max number of TCs supported on this port are 8
      [   55.685365] ice 0000:ca:00.0: FW LLDP is disabled, DCBx/LLDP in SW mode.
      [   55.692179] ice 0000:ca:00.0: Commit DCB Configuration to the hardware
      [   55.701382] ice 0000:ca:00.0: 126.024 Gb/s available PCIe bandwidth, limited by 16.0 GT/s PCIe x8 link at 0000:c9:02.0 (capable of 252.048 Gb/s with 16.0 GT/s PCIe x16 link)
      Reboot doesn’t help, only second flash/activate with OOT or patched
      driver put card back in consistent state.
      
      After patch:
      [root@host ~]# devlink dev flash pci/0000:ca:00.0 file E810_XXVDA4_FH_O_SEC_FW_1p6p1p9_NVM_3p10_PLDMoMCTP_0.11_8000AD7B.bin
      Preparing to flash
      [fw.mgmt] Erasing
      [fw.mgmt] Erasing done
      [fw.mgmt] Flashing 100%
      [fw.mgmt] Flashing done 100%
      [fw.undi] Erasing
      [fw.undi] Erasing done
      [fw.undi] Flashing 100%
      [fw.undi] Flashing done 100%
      [fw.netlist] Erasing
      [fw.netlist] Erasing done
      [fw.netlist] Flashing 100%
      [fw.netlist] Flashing done 100%
      Activate new firmware by devlink reload
      [root@host ~]# devlink dev reload pci/0000:ca:00.0 action fw_activate
      reload_actions_performed:
          fw_activate
      [root@host ~]# ip link show ens7f0
      19: ens7f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
          link/ether b4:96:91:dc:72:e0 brd ff:ff:ff:ff:ff:ff
          altname enp202s0f0
      
      Fixes: 399e27db ("ice: support immediate firmware activation via devlink reload")
      Signed-off-by: NPetr Oros <poros@redhat.com>
      Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      b537752e
    • I
      ice: Protect vf_state check by cfg_lock in ice_vc_process_vf_msg() · 77d64d28
      Ivan Vecera 提交于
      Previous patch labelled "ice: Fix incorrect locking in
      ice_vc_process_vf_msg()"  fixed an issue with ignored messages
      sent by VF driver but a small race window still left.
      
      Recently caught trace during 'ip link set ... vf 0 vlan ...' operation:
      
      [ 7332.995625] ice 0000:3b:00.0: Clearing port VLAN on VF 0
      [ 7333.001023] iavf 0000:3b:01.0: Reset indication received from the PF
      [ 7333.007391] iavf 0000:3b:01.0: Scheduling reset task
      [ 7333.059575] iavf 0000:3b:01.0: PF returned error -5 (IAVF_ERR_PARAM) to our request 3
      [ 7333.059626] ice 0000:3b:00.0: Invalid message from VF 0, opcode 3, len 4, error -1
      
      Setting of VLAN for VF causes a reset of the affected VF using
      ice_reset_vf() function that runs with cfg_lock taken:
      
      1. ice_notify_vf_reset() informs IAVF driver that reset is needed and
         IAVF schedules its own reset procedure
      2. Bit ICE_VF_STATE_DIS is set in vf->vf_state
      3. Misc initialization steps
      4. ice_sriov_post_vsi_rebuild() -> ice_vf_set_initialized() and that
         clears ICE_VF_STATE_DIS in vf->vf_state
      
      Step 3 is mentioned race window because IAVF reset procedure runs in
      parallel and one of its step is sending of VIRTCHNL_OP_GET_VF_RESOURCES
      message (opcode==3). This message is handled in ice_vc_process_vf_msg()
      and if it is received during the mentioned race window then it's
      marked as invalid and error is returned to VF driver.
      
      Protect vf_state check in ice_vc_process_vf_msg() by cfg_lock to avoid
      this race condition.
      
      Fixes: e6ba5273 ("ice: Fix race conditions between virtchnl handling and VF ndo ops")
      Tested-by: NFei Liu <feliu@redhat.com>
      Signed-off-by: NIvan Vecera <ivecera@redhat.com>
      Reviewed-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      77d64d28
    • I
      ice: Fix incorrect locking in ice_vc_process_vf_msg() · aaf461af
      Ivan Vecera 提交于
      Usage of mutex_trylock() in ice_vc_process_vf_msg() is incorrect
      because message sent from VF is ignored and never processed.
      
      Use mutex_lock() instead to fix the issue. It is safe because this
      mutex is used to prevent races between VF related NDOs and
      handlers processing request messages from VF and these handlers
      are running in ice_service_task() context. Additionally move this
      mutex lock prior ice_vc_is_opcode_allowed() call to avoid potential
      races during allowlist access.
      
      Fixes: e6ba5273 ("ice: Fix race conditions between virtchnl handling and VF ndo ops")
      Signed-off-by: NIvan Vecera <ivecera@redhat.com>
      Tested-by: NKonrad Jankowski <konrad0.jankowski@intel.com>
      Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      aaf461af
  4. 26 4月, 2022 9 次提交
    • S
      drm/sun4i: Remove obsolete references to PHYS_OFFSET · dc3ae06c
      Samuel Holland 提交于
      commit b4bdc4fb ("soc: sunxi: Deal with the MBUS DMA offsets in a
      central place") added a platform device notifier that sets the DMA
      offset for all of the display engine frontend and backend devices.
      
      The code applying the offset to DMA buffer physical addresses was then
      removed from the backend driver in commit 756668ba ("drm/sun4i:
      backend: Remove the MBUS quirks"), but the code subtracting PHYS_OFFSET
      was left in the frontend driver.
      
      As a result, the offset was applied twice in the frontend driver. This
      likely went unnoticed because it only affects specific configurations
      (scaling or certain pixel formats) where the frontend is used, on boards
      with both one of these older SoCs and more than 1 GB of DRAM.
      
      In addition, the references to PHYS_OFFSET prevent compiling the driver
      on architectures where PHYS_OFFSET is not defined.
      
      Fixes: b4bdc4fb ("soc: sunxi: Deal with the MBUS DMA offsets in a central place")
      Reviewed-by: NJernej Skrabec <jernej.skrabec@gmail.com>
      Signed-off-by: NSamuel Holland <samuel@sholland.org>
      Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220424162633.12369-4-samuel@sholland.org
      dc3ae06c
    • N
      virtio_net: fix wrong buf address calculation when using xdp · acb16b39
      Nikolay Aleksandrov 提交于
      We received a report[1] of kernel crashes when Cilium is used in XDP
      mode with virtio_net after updating to newer kernels. After
      investigating the reason it turned out that when using mergeable bufs
      with an XDP program which adjusts xdp.data or xdp.data_meta page_to_buf()
      calculates the build_skb address wrong because the offset can become less
      than the headroom so it gets the address of the previous page (-X bytes
      depending on how lower offset is):
       page_to_skb: page addr ffff9eb2923e2000 buf ffff9eb2923e1ffc offset 252 headroom 256
      
      This is a pr_err() I added in the beginning of page_to_skb which clearly
      shows offset that is less than headroom by adding 4 bytes of metadata
      via an xdp prog. The calculations done are:
       receive_mergeable():
       headroom = VIRTIO_XDP_HEADROOM; // VIRTIO_XDP_HEADROOM == 256 bytes
       offset = xdp.data - page_address(xdp_page) -
                vi->hdr_len - metasize;
      
       page_to_skb():
       p = page_address(page) + offset;
       ...
       buf = p - headroom;
      
      Now buf goes -4 bytes from the page's starting address as can be seen
      above which is set as skb->head and skb->data by build_skb later. Depending
      on what's done with the skb (when it's freed most often) we get all kinds
      of corruptions and BUG_ON() triggers in mm[2]. We have to recalculate
      the new headroom after the xdp program has run, similar to how offset
      and len are recalculated. Headroom is directly related to
      data_hard_start, data and data_meta, so we use them to get the new size.
      The result is correct (similar pr_err() in page_to_skb, one case of
      xdp_page and one case of virtnet buf):
       a) Case with 4 bytes of metadata
       [  115.949641] page_to_skb: page addr ffff8b4dcfad2000 offset 252 headroom 252
       [  121.084105] page_to_skb: page addr ffff8b4dcf018000 offset 20732 headroom 252
       b) Case of pushing data +32 bytes
       [  153.181401] page_to_skb: page addr ffff8b4dd0c4d000 offset 288 headroom 288
       [  158.480421] page_to_skb: page addr ffff8b4dd00b0000 offset 24864 headroom 288
       c) Case of pushing data -33 bytes
       [  835.906830] page_to_skb: page addr ffff8b4dd3270000 offset 223 headroom 223
       [  840.839910] page_to_skb: page addr ffff8b4dcdd68000 offset 12511 headroom 223
      
      Offset and headroom are equal because offset points to the start of
      reserved bytes for the virtio_net header which are at buf start +
      headroom, while data points at buf start + vnet hdr size + headroom so
      when data or data_meta are adjusted by the xdp prog both the headroom size
      and the offset change equally. We can use data_hard_start to compute the
      new headroom after the xdp prog (linearized / page start case, the
      virtnet buf case is similar just with bigger base offset):
       xdp.data_hard_start = page_address + vnet_hdr
       xdp.data = page_address + vnet_hdr + headroom
       new headroom after xdp prog = xdp.data - xdp.data_hard_start - metasize
      
      An example reproducer xdp prog[3] is below.
      
      [1] https://github.com/cilium/cilium/issues/19453
      
      [2] Two of the many traces:
       [   40.437400] BUG: Bad page state in process swapper/0  pfn:14940
       [   40.916726] BUG: Bad page state in process systemd-resolve  pfn:053b7
       [   41.300891] kernel BUG at include/linux/mm.h:720!
       [   41.301801] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
       [   41.302784] CPU: 1 PID: 1181 Comm: kubelet Kdump: loaded Tainted: G    B   W         5.18.0-rc1+ #37
       [   41.304458] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014
       [   41.306018] RIP: 0010:page_frag_free+0x79/0xe0
       [   41.306836] Code: 00 00 75 ea 48 8b 07 a9 00 00 01 00 74 e0 48 8b 47 48 48 8d 50 ff a8 01 48 0f 45 fa eb d0 48 c7 c6 18 b8 30 a6 e8 d7 f8 fc ff <0f> 0b 48 8d 78 ff eb bc 48 8b 07 a9 00 00 01 00 74 3a 66 90 0f b6
       [   41.310235] RSP: 0018:ffffac05c2a6bc78 EFLAGS: 00010292
       [   41.311201] RAX: 000000000000003e RBX: 0000000000000000 RCX: 0000000000000000
       [   41.312502] RDX: 0000000000000001 RSI: ffffffffa6423004 RDI: 00000000ffffffff
       [   41.313794] RBP: ffff993c98823600 R08: 0000000000000000 R09: 00000000ffffdfff
       [   41.315089] R10: ffffac05c2a6ba68 R11: ffffffffa698ca28 R12: ffff993c98823600
       [   41.316398] R13: ffff993c86311ebc R14: 0000000000000000 R15: 000000000000005c
       [   41.317700] FS:  00007fe13fc56740(0000) GS:ffff993cdd900000(0000) knlGS:0000000000000000
       [   41.319150] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       [   41.320152] CR2: 000000c00008a000 CR3: 0000000014908000 CR4: 0000000000350ee0
       [   41.321387] Call Trace:
       [   41.321819]  <TASK>
       [   41.322193]  skb_release_data+0x13f/0x1c0
       [   41.322902]  __kfree_skb+0x20/0x30
       [   41.343870]  tcp_recvmsg_locked+0x671/0x880
       [   41.363764]  tcp_recvmsg+0x5e/0x1c0
       [   41.384102]  inet_recvmsg+0x42/0x100
       [   41.406783]  ? sock_recvmsg+0x1d/0x70
       [   41.428201]  sock_read_iter+0x84/0xd0
       [   41.445592]  ? 0xffffffffa3000000
       [   41.462442]  new_sync_read+0x148/0x160
       [   41.479314]  ? 0xffffffffa3000000
       [   41.496937]  vfs_read+0x138/0x190
       [   41.517198]  ksys_read+0x87/0xc0
       [   41.535336]  do_syscall_64+0x3b/0x90
       [   41.551637]  entry_SYSCALL_64_after_hwframe+0x44/0xae
       [   41.568050] RIP: 0033:0x48765b
       [   41.583955] Code: e8 4a 35 fe ff eb 88 cc cc cc cc cc cc cc cc e8 fb 7a fe ff 48 8b 7c 24 10 48 8b 74 24 18 48 8b 54 24 20 48 8b 44 24 08 0f 05 <48> 3d 01 f0 ff ff 76 20 48 c7 44 24 28 ff ff ff ff 48 c7 44 24 30
       [   41.632818] RSP: 002b:000000c000a2f5b8 EFLAGS: 00000212 ORIG_RAX: 0000000000000000
       [   41.664588] RAX: ffffffffffffffda RBX: 000000c000062000 RCX: 000000000048765b
       [   41.681205] RDX: 0000000000005e54 RSI: 000000c000e66000 RDI: 0000000000000016
       [   41.697164] RBP: 000000c000a2f608 R08: 0000000000000001 R09: 00000000000001b4
       [   41.713034] R10: 00000000000000b6 R11: 0000000000000212 R12: 00000000000000e9
       [   41.728755] R13: 0000000000000001 R14: 000000c000a92000 R15: ffffffffffffffff
       [   41.744254]  </TASK>
       [   41.758585] Modules linked in: br_netfilter bridge veth netconsole virtio_net
      
       and
      
       [   33.524802] BUG: Bad page state in process systemd-network  pfn:11e60
       [   33.528617] page ffffe05dc0147b00 ffffe05dc04e7a00 ffff8ae9851ec000 (1) len 82 offset 252 metasize 4 hroom 0 hdr_len 12 data ffff8ae9851ec10c data_meta ffff8ae9851ec108 data_end ffff8ae9851ec14e
       [   33.529764] page:000000003792b5ba refcount:0 mapcount:-512 mapping:0000000000000000 index:0x0 pfn:0x11e60
       [   33.532463] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)
       [   33.532468] raw: 000fffffc0000000 0000000000000000 dead000000000122 0000000000000000
       [   33.532470] raw: 0000000000000000 0000000000000000 00000000fffffdff 0000000000000000
       [   33.532471] page dumped because: nonzero mapcount
       [   33.532472] Modules linked in: br_netfilter bridge veth netconsole virtio_net
       [   33.532479] CPU: 0 PID: 791 Comm: systemd-network Kdump: loaded Not tainted 5.18.0-rc1+ #37
       [   33.532482] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1.fc35 04/01/2014
       [   33.532484] Call Trace:
       [   33.532496]  <TASK>
       [   33.532500]  dump_stack_lvl+0x45/0x5a
       [   33.532506]  bad_page.cold+0x63/0x94
       [   33.532510]  free_pcp_prepare+0x290/0x420
       [   33.532515]  free_unref_page+0x1b/0x100
       [   33.532518]  skb_release_data+0x13f/0x1c0
       [   33.532524]  kfree_skb_reason+0x3e/0xc0
       [   33.532527]  ip6_mc_input+0x23c/0x2b0
       [   33.532531]  ip6_sublist_rcv_finish+0x83/0x90
       [   33.532534]  ip6_sublist_rcv+0x22b/0x2b0
      
      [3] XDP program to reproduce(xdp_pass.c):
       #include <linux/bpf.h>
       #include <bpf/bpf_helpers.h>
      
       SEC("xdp_pass")
       int xdp_pkt_pass(struct xdp_md *ctx)
       {
                bpf_xdp_adjust_head(ctx, -(int)32);
                return XDP_PASS;
       }
      
       char _license[] SEC("license") = "GPL";
      
       compile: clang -O2 -g -Wall -target bpf -c xdp_pass.c -o xdp_pass.o
       load on virtio_net: ip link set enp1s0 xdpdrv obj xdp_pass.o sec xdp_pass
      
      CC: stable@vger.kernel.org
      CC: Jason Wang <jasowang@redhat.com>
      CC: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
      CC: Daniel Borkmann <daniel@iogearbox.net>
      CC: "Michael S. Tsirkin" <mst@redhat.com>
      CC: virtualization@lists.linux-foundation.org
      Fixes: 8fb7da9e ("virtio_net: get build_skb() buf by data ptr")
      Signed-off-by: NNikolay Aleksandrov <razor@blackwall.org>
      Reviewed-by: NXuan Zhuo <xuanzhuo@linux.alibaba.com>
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NMichael S. Tsirkin <mst@redhat.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      Link: https://lore.kernel.org/r/20220425103703.3067292-1-razor@blackwall.orgSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
      acb16b39
    • N
      net: dsa: mv88e6xxx: Fix port_hidden_wait to account for port_base_addr · 24cbdb91
      Nathan Rossi 提交于
      The other port_hidden functions rely on the port_read/port_write
      functions to access the hidden control port. These functions apply the
      offset for port_base_addr where applicable. Update port_hidden_wait to
      use the port_wait_bit so that port_base_addr offsets are accounted for
      when waiting for the busy bit to change.
      
      Without the offset the port_hidden_wait function would timeout on
      devices that have a non-zero port_base_addr (e.g. MV88E6141), however
      devices that have a zero port_base_addr would operate correctly (e.g.
      MV88E6390).
      
      Fixes: 60907013 ("net: dsa: mv88e6xxx: update code operating on hidden registers")
      Signed-off-by: NNathan Rossi <nathan@nathanrossi.com>
      Reviewed-by: NMarek Behún <kabel@kernel.org>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Link: https://lore.kernel.org/r/20220425070454.348584-1-nathan@nathanrossi.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
      24cbdb91
    • B
      net: phy: marvell10g: fix return value on error · 0ed9704b
      Baruch Siach 提交于
      Return back the error value that we get from phy_read_mmd().
      
      Fixes: c84786fa ("net: phy: marvell10g: read copper results from CSSR1")
      Signed-off-by: NBaruch Siach <baruch.siach@siklu.com>
      Reviewed-by: NMarek Behún <kabel@kernel.org>
      Reviewed-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Link: https://lore.kernel.org/r/f47cb031aeae873bb008ba35001607304a171a20.1650868058.git.baruch@tkos.co.ilSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
      0ed9704b
    • J
      net: bcmgenet: hide status block before TX timestamping · acac0541
      Jonathan Lemon 提交于
      The hardware checksum offloading requires use of a transmit
      status block inserted before the outgoing frame data, this was
      updated in '9a9ba2a4 ("net: bcmgenet: always enable status blocks")'
      
      However, skb_tx_timestamp() assumes that it is passed a raw frame
      and PTP parsing chokes on this status block.
      
      Fix this by calling __skb_pull(), which hides the TSB before calling
      skb_tx_timestamp(), so an outgoing PTP packet is parsed correctly.
      
      As the data in the skb has already been set up for DMA, and the
      dma_unmap_* calls use a separately stored address, there is no
      no effective change in the data transmission.
      Signed-off-by: NJonathan Lemon <jonathan.lemon@gmail.com>
      Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Link: https://lore.kernel.org/r/20220424165307.591145-1-jonathan.lemon@gmail.com
      Fixes: d03825fb ("net: bcmgenet: add skb_tx_timestamp call")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      acac0541
    • V
      drm/i915/fbc: Consult hw.crtc instead of uapi.crtc · f7e1089f
      Ville Syrjälä 提交于
      plane_state->uapi.crtc is not what we want to be looking at.
      If bigjoiner is used hw.crtc is what tells us what crtc the plane
      is supposedly using.
      
      Not an actual problem on current hardware as the only FBC capable
      pipe (A) can't be a bigjoiner slave and thus uapi.crtc==hw.crtc
      always here. But when we get more FBC instances this will become
      actually important.
      
      Fixes: 2e6c99f8 ("drm/i915/fbc: Nuke lots of crap from intel_fbc_state_cache")
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220413152852.7336-1-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>
      (cherry picked from commit 3e1faae3)
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      f7e1089f
    • I
      drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses · 4ae4dd2e
      Imre Deak 提交于
      Fix typo in the _SEL_FETCH_PLANE_BASE_1_B register base address.
      
      Fixes: a5523e2f ("drm/i915: Add PSR2 selective fetch registers")
      References: https://gitlab.freedesktop.org/drm/intel/-/issues/5400
      Cc: José Roberto de Souza <jose.souza@intel.com>
      Cc: <stable@vger.kernel.org> # v5.9+
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220421162221.2261895-1-imre.deak@intel.com
      (cherry picked from commit af2cbc6e)
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      4ae4dd2e
    • V
      cpufreq: qcom-cpufreq-hw: Clear dcvs interrupts · e4e64486
      Vladimir Zapolskiy 提交于
      It's noted that dcvs interrupts are not self-clearing, thus an interrupt
      handler runs constantly, which leads to a severe regression in runtime.
      To fix the problem an explicit write to clear interrupt register is
      required, note that on OSM platforms the register may not be present.
      
      Fixes: 275157b3 ("cpufreq: qcom-cpufreq-hw: Add dcvs interrupt support")
      Signed-off-by: NVladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      e4e64486
    • A
      video: fbdev: clps711x-fb: Use syscon_regmap_lookup_by_phandle · 6fbe0cc5
      Alexander Shiyan 提交于
      Since version 5.13, the standard syscon bindings have been added
      to all clps711x DT nodes, so we can now use the more general
      syscon_regmap_lookup_by_phandle function to get the syscon pointer.
      Signed-off-by: NAlexander Shiyan <eagle.alexander923@gmail.com>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      6fbe0cc5
  5. 25 4月, 2022 2 次提交
    • V
      net: mscc: ocelot: don't add VID 0 to ocelot->vlans when leaving VLAN-aware bridge · 1fcb8fb3
      Vladimir Oltean 提交于
      DSA, through dsa_port_bridge_leave(), first notifies the port of the
      fact that it left a bridge, then, if that bridge was VLAN-aware, it
      notifies the port of the change in VLAN awareness state, towards
      VLAN-unaware mode.
      
      So ocelot_port_vlan_filtering() can be called when ocelot_port->bridge
      is NULL, and this makes ocelot_add_vlan_unaware_pvid() create a struct
      ocelot_bridge_vlan with a vid of 0 and an "untagged" setting of true on
      that port.
      
      In a way this structure correctly reflects the reality, but by design,
      VID 0 (OCELOT_STANDALONE_PVID) was not meant to be kept in the bridge
      VLAN list of the driver, but managed separately.
      
      Having OCELOT_STANDALONE_PVID in ocelot->vlans makes us trip up on
      several sanity checks that did not expect to have this VID there.
      For example, after we leave a VLAN-aware bridge and we re-join it, we
      can no longer program egress-tagged VLANs to hardware:
      
       # ip link add br0 type bridge vlan_filtering 1 && ip link set br0 up
       # ip link set swp0 master br0
       # ip link set swp0 nomaster
       # ip link set swp0 master br0
       # bridge vlan add dev swp0 vid 100
      Error: mscc_ocelot_switch_lib: Port with more than one egress-untagged VLAN cannot have egress-tagged VLANs.
      
      But this configuration is in fact supported by the hardware, since we
      could use OCELOT_PORT_TAG_NATIVE. According to its comment:
      
      /* all VLANs except the native VLAN and VID 0 are egress-tagged */
      
      yet when assessing the eligibility for this mode, we do not check for
      VID 0 in ocelot_port_uses_native_vlan(), instead we just ensure that
      ocelot_port_num_untagged_vlans() == 1. This is simply because VID 0
      doesn't have a bridge VLAN structure.
      
      The way I identify the problem is that ocelot_port_vlan_filtering(false)
      only means to call ocelot_add_vlan_unaware_pvid() when we dynamically
      turn off VLAN awareness for a bridge we are under, and the PVID changes
      from the bridge PVID to a reserved PVID based on the bridge number.
      
      Since OCELOT_STANDALONE_PVID is statically added to the VLAN table
      during ocelot_vlan_init() and never removed afterwards, calling
      ocelot_add_vlan_unaware_pvid() for it is not intended and does not serve
      any purpose.
      
      Fix the issue by avoiding the call to ocelot_add_vlan_unaware_pvid(vid=0)
      when we're resetting VLAN awareness after leaving the bridge, to become
      a standalone port.
      
      Fixes: 54c31984 ("net: mscc: ocelot: enforce FDB isolation when VLAN-unaware")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1fcb8fb3
    • V
      net: mscc: ocelot: ignore VID 0 added by 8021q module · 9323ac36
      Vladimir Oltean 提交于
      Both the felix DSA driver and ocelot switchdev driver declare
      dev->features & NETIF_F_HW_VLAN_CTAG_FILTER under certain circumstances*,
      so the 8021q module will add VID 0 to our RX filter when the port goes
      up, to ensure 802.1p traffic is not dropped.
      
      We treat VID 0 as a special value (OCELOT_STANDALONE_PVID) which
      deliberately does not have a struct ocelot_bridge_vlan associated with
      it. Instead, this gets programmed to the VLAN table in ocelot_vlan_init().
      
      If we allow external calls to modify VID 0, we reach the following
      situation:
      
       # ip link add br0 type bridge vlan_filtering 1 && ip link set br0 up
       # ip link set swp0 master br0
       # ip link set swp0 up # this adds VID 0 to ocelot->vlans with untagged=false
      bridge vlan
      port              vlan-id
      swp0              1 PVID Egress Untagged # the bridge also adds VID 1
      br0               1 PVID Egress Untagged
       # bridge vlan add dev swp0 vid 100 untagged
      Error: mscc_ocelot_switch_lib: Port with egress-tagged VLANs cannot have more than one egress-untagged (native) VLAN.
      
      This configuration should have been accepted, because
      ocelot_port_manage_port_tag() should select OCELOT_PORT_TAG_NATIVE.
      Yet it isn't, because we have an entry in ocelot->vlans which says
      VID 0 should be egress-tagged, something the hardware can't do.
      
      Fix this by suppressing additions/deletions on VID 0 and managing this
      VLAN exclusively using OCELOT_STANDALONE_PVID.
      
      *DSA toggles it when the port becomes VLAN-aware by joining a VLAN-aware
      bridge. Ocelot declares it unconditionally for some reason.
      
      Fixes: 54c31984 ("net: mscc: ocelot: enforce FDB isolation when VLAN-unaware")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9323ac36
新手
引导
客服 返回
顶部