[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <SJ0PR11MB58658891193D7751F07C3EFD8F712@SJ0PR11MB5865.namprd11.prod.outlook.com>
Date: Thu, 3 Oct 2024 12:07:17 +0000
From: "Romanowski, Rafal" <rafal.romanowski@...el.com>
To: Simon Horman <horms@...nel.org>, Marcin Szycik
<marcin.szycik@...ux.intel.com>
CC: "Keller, Jacob E" <jacob.e.keller@...el.com>, "netdev@...r.kernel.org"
<netdev@...r.kernel.org>, Michal Swiatkowski
<michal.swiatkowski@...ux.intel.com>, "intel-wired-lan@...ts.osuosl.org"
<intel-wired-lan@...ts.osuosl.org>, "Kitszel, Przemyslaw"
<przemyslaw.kitszel@...el.com>
Subject: RE: [Intel-wired-lan] [PATCH iwl-net] ice: Fix increasing MSI-X on VF
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of Simon
> Horman
> Sent: Monday, September 30, 2024 4:52 PM
> To: Marcin Szycik <marcin.szycik@...ux.intel.com>
> Cc: Keller, Jacob E <jacob.e.keller@...el.com>; netdev@...r.kernel.org; Michal
> Swiatkowski <michal.swiatkowski@...ux.intel.com>; intel-wired-
> lan@...ts.osuosl.org; Kitszel, Przemyslaw <przemyslaw.kitszel@...el.com>
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net] ice: Fix increasing MSI-X on VF
>
> On Fri, Sep 27, 2024 at 05:15:40PM +0200, Marcin Szycik wrote:
> > Increasing MSI-X value on a VF leads to invalid memory operations.
> > This is caused by not reallocating some arrays.
> >
> > Reproducer:
> > modprobe ice
> > echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe
> > echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs
> > echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count
> >
> > Default MSI-X is 16, so 17 and above triggers this issue.
> >
> > KASAN reports:
> >
> > BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0
> [ice]
> > Read of size 8 at addr ffff8888b937d180 by task bash/28433
> > (...)
> >
> > Call Trace:
> > (...)
> > ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]
> > kasan_report+0xed/0x120
> > ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]
> > ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice]
> > ice_vsi_cfg_def+0x3360/0x4770 [ice]
> > ? mutex_unlock+0x83/0xd0
> > ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice]
> > ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice]
> > ice_vsi_cfg+0x7f/0x3b0 [ice]
> > ice_vf_reconfig_vsi+0x114/0x210 [ice]
> > ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice]
> > sriov_vf_msix_count_store+0x21c/0x300
> > (...)
> >
> > Allocated by task 28201:
> > (...)
> > ice_vsi_cfg_def+0x1c8e/0x4770 [ice]
> > ice_vsi_cfg+0x7f/0x3b0 [ice]
> > ice_vsi_setup+0x179/0xa30 [ice]
> > ice_sriov_configure+0xcaa/0x1520 [ice]
> > sriov_numvfs_store+0x212/0x390
> > (...)
> >
> > To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi().
> > This causes the required arrays to be reallocated taking the new queue
> > count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and
> > req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set
> > queue count.
> >
> > Additionally, ice_vsi_rebuild() does not remove VSI filters
> > (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer
> > necessary.
> >
> > Reported-by: Jacob Keller <jacob.e.keller@...el.com>
> > Fixes: 2a2cb4c6c181 ("ice: replace ice_vf_recreate_vsi() with
> > ice_vf_reconfig_vsi()")
> > Reviewed-by: Michal Swiatkowski <michal.swiatkowski@...ux.intel.com>
> > Signed-off-by: Marcin Szycik <marcin.szycik@...ux.intel.com>
>
> Reviewed-by: Simon Horman <horms@...nel.org>
Tested-by: Rafal Romanowski <rafal.romanowski@...el.com>
Powered by blists - more mailing lists