netdev - Re: [net-next v5 08/15] iecm: Implement vector allocation

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: <20200827111911.0884af35@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Thu, 27 Aug 2020 11:19:11 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Brady, Alan" <alan.brady@...el.com>
Cc:     "Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "Michael, Alice" <alice.michael@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "sassmann@...hat.com" <sassmann@...hat.com>,
        "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
        "Burra, Phani R" <phani.r.burra@...el.com>,
        "Hay, Joshua A" <joshua.a.hay@...el.com>,
        "Chittim, Madhu" <madhu.chittim@...el.com>,
        "Linga, Pavan Kumar" <pavan.kumar.linga@...el.com>,
        "Skidmore, Donald C" <donald.c.skidmore@...el.com>,
        "Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
        "Samudrala, Sridhar" <sridhar.samudrala@...el.com>
Subject: Re: [net-next v5 08/15] iecm: Implement vector allocation

On Thu, 27 Aug 2020 17:28:29 +0000 Brady, Alan wrote:
> > On Mon, 24 Aug 2020 10:32:59 -0700 Tony Nguyen wrote:  
> > >  static void iecm_mb_intr_rel_irq(struct iecm_adapter *adapter)  {
> > > -	/* stub */
> > > +	int irq_num;
> > > +
> > > +	irq_num = adapter->msix_entries[0].vector;
> > > +	synchronize_irq(irq_num);  
> > 
> > I don't think you need to sync irq before freeing it.
> 
> I see other non-Intel drivers syncing before disable/free and Intel
> drivers have historically done it, not that that's necessarily
> correct, but are you certain?

/**
 *	free_irq - free an interrupt allocated with request_irq
 *	@irq: Interrupt line to free
 *	@dev_id: Device identity to free
 *
 *	Remove an interrupt handler. The handler is removed and if the
 *	interrupt line is no longer in use by any driver it is disabled.
 *	On a shared IRQ the caller must ensure the interrupt is disabled
 *	on the card it drives before calling this function. The function
 *	does not return until any executing interrupts for this IRQ
 *	have completed.
 *
 *	This function must not be called from interrupt context.
 *
 *	Returns the devname argument passed to request_irq.
 */