netdev - RE: [Intel-wired-lan] [PATCH iwl-next v3] i40e: add ability to reset vf for tx and rx mdd events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <DM4PR11MB6117A1340C6493FB75ED984382932@DM4PR11MB6117.namprd11.prod.outlook.com>
Date: Tue, 3 Sep 2024 19:44:59 +0000
From: "Fijalkowski, Maciej" <maciej.fijalkowski@...el.com>
To: "Loktionov, Aleksandr" <aleksandr.loktionov@...el.com>, mschmidt
	<mschmidt@...hat.com>
CC: "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
	"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "Sokolowski, Jan" <jan.sokolowski@...el.com>,
	"Connolly, Padraig J" <padraig.j.connolly@...el.com>
Subject: RE: [Intel-wired-lan] [PATCH iwl-next v3] i40e: add ability to reset
 vf for tx and rx mdd events

> > On Fri, Aug 30, 2024 at 9:28 PM Aleksandr Loktionov
> > <aleksandr.loktionov@...el.com> wrote:
> > >
> > > In cases when vf sends malformed packets that are classified as
> > > malicious, sometimes it causes tx queue to freeze. This frozen queue
> > > can be stuck for several minutes being unusable. When mdd event
> > > occurs, there is a posibility to perform a graceful vf reset to
> > > quickly bring vf back to operational state.
> > >
> > > Currently vf iqueues are being disabled if mdd event occurs.
> > > Add the ability to reset vf if tx or rx mdd occurs.
> > > Add mdd events logging throttling /* avoid dmesg polution */.
> > > Unify tx rx mdd messages formats.
> > >
> > > Co-developed-by: Jan Sokolowski <jan.sokolowski@...el.com>
> > > Signed-off-by: Jan Sokolowski <jan.sokolowski@...el.com>
> > > Co-developed-by: Padraig J Connolly <padraig.j.connolly@...el.com>
> > > Signed-off-by:  Padraig J Connolly <padraig.j.connolly@...el.com>
> > > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@...el.com>
> > > ---
> >
> > Thanks, we need this. ice has the same ability.
> > Just one question about the patch:
> >
> > [...]
> > >  static void i40e_handle_mdd_event(struct i40e_pf *pf)  {
> > >         struct i40e_hw *hw = &pf->hw;
> > >         bool mdd_detected = false;
> > >         struct i40e_vf *vf;
> > >         u32 reg;
> > >         int i;
> > >
> > > -       if (!test_bit(__I40E_MDD_EVENT_PENDING, pf->state))
> > > +       if (!test_and_clear_bit(__I40E_MDD_EVENT_PENDING, pf-
> > >state))
> > > + {
> >
> > OK, using test_and_clear_bit is good, but ...:
> >
> > [...]
> > >
> > >         /* re-enable mdd interrupt cause */
> > >         clear_bit(__I40E_MDD_EVENT_PENDING, pf->state);
> >
> > Here the bit is cleared again. Why?
> >
> He code with clear_bit() is legacy and >7y old. So I can guess it's to avoid race condition.
> This patch introduced new functionality without changing legacy control flow, and has been tested in OOT driver.
> If you have suggestions in control flow change I'd suggest to merge this patch first and then try to refactor.
> What do you think?

Doesn't matter how old the referred code is, you are touching the same
bit so it's your responsibility to address this additional bit clearing...

> 
> > >         reg = rd32(hw, I40E_PFINT_ICR0_ENA);
> > >         reg |=  I40E_PFINT_ICR0_ENA_MAL_DETECT_MASK;
> > >         wr32(hw, I40E_PFINT_ICR0_ENA, reg);
> > >         i40e_flush(hw);
> > > +
> > > +       i40e_print_vfs_mdd_events(pf);
> > >  }
> >
> > Michal