[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <SJ1PR11MB6297E666EE767C6F804BFC539B03A@SJ1PR11MB6297.namprd11.prod.outlook.com>
Date: Fri, 5 Sep 2025 21:25:27 +0000
From: "Salin, Samuel" <samuel.salin@...el.com>
To: Simon Horman <horms@...nel.org>, "Tantilov, Emil S"
<emil.s.tantilov@...el.com>
CC: "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Loktionov, Aleksandr"
<aleksandr.loktionov@...el.com>, "Kitszel, Przemyslaw"
<przemyslaw.kitszel@...el.com>, "Nguyen, Anthony L"
<anthony.l.nguyen@...el.com>, "andrew+netdev@...n.ch"
<andrew+netdev@...n.ch>, "davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org"
<kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>,
"decot@...gle.com" <decot@...gle.com>, "willemb@...gle.com"
<willemb@...gle.com>, "Hay, Joshua A" <joshua.a.hay@...el.com>, "Chittim,
Madhu" <madhu.chittim@...el.com>
Subject: RE: [Intel-wired-lan] [PATCH iwl-net 2/2] idpf: fix possible race in
idpf_vport_stop()
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@...osl.org> On Behalf Of
> Simon Horman
> Sent: Wednesday, August 27, 2025 7:20 AM
> To: Tantilov, Emil S <emil.s.tantilov@...el.com>
> Cc: intel-wired-lan@...ts.osuosl.org; netdev@...r.kernel.org; Loktionov,
> Aleksandr <aleksandr.loktionov@...el.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@...el.com>; Nguyen, Anthony L
> <anthony.l.nguyen@...el.com>; andrew+netdev@...n.ch;
> davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> pabeni@...hat.com; decot@...gle.com; willemb@...gle.com; Hay, Joshua
> A <joshua.a.hay@...el.com>; Chittim, Madhu <madhu.chittim@...el.com>
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net 2/2] idpf: fix possible race in
> idpf_vport_stop()
>
> On Thu, Aug 21, 2025 at 08:52:48PM -0700, Emil Tantilov wrote:
> > Make sure to clear the IDPF_VPORT_UP bit on entry. The
> > idpf_vport_stop() function is void and once called, the vport teardown
> > is guaranteed to happen. Previously the bit was cleared at the end of
> > the function, which opened it up to possible races with all instances
> > in the driver where operations were conditional on this bit being set.
> > For example, on rmmod callbacks in the middle of idpf_vport_stop() end
> > up attempting to remove MAC address filter already removed by the
> function:
> > idpf 0000:83:00.0: Received invalid MAC filter payload (op 536) (len
> > 0)
> >
> > Fixes: 1c325aac10a8 ("idpf: configure resources for TX queues")
> > Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@...el.com>
> > Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@...el.com>
> > Reviewed-by Joshua Hay <joshua.a.hay@...el.com>
> > Reviewed-by: Chittim Madhu <madhu.chittim@...el.com>
> > Signed-off-by: Emil Tantilov <emil.s.tantilov@...el.com>
>
> Reviewed-by: Simon Horman <horms@...nel.org>
Tested-by: Samuel Salin <Samuel.salin@...el.com>
Powered by blists - more mailing lists