netdev - Re: [PATCH net-next v5 2/2] mctp i2c: MCTP I2C binding driver

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: <20220214210410.2d49e55f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date:   Mon, 14 Feb 2022 21:04:10 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Matt Johnston <matt@...econstruct.com.au>
Cc:     Wolfram Sang <wsa@...nel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Jeremy Kerr <jk@...econstruct.com.au>,
        linux-i2c@...r.kernel.org, netdev@...r.kernel.org,
        Zev Weiss <zev@...ilderbeest.net>
Subject: Re: [PATCH net-next v5 2/2] mctp i2c: MCTP I2C binding driver

On Tue, 15 Feb 2022 12:22:14 +0800 Matt Johnston wrote:
> On Fri, 2022-02-11 at 14:38 -0800, Jakub Kicinski wrote:
> >   
> > > +// Removes and unregisters a mctp-i2c netdev
> > > +static void mctp_i2c_free_netdev(struct mctp_i2c_dev *midev)
> > >   
> > You're doing a lot before the unregister call, this is likely racy.
> > The usual flow is to unregister the netdev, then do uninit, then free.
> > For instance you purge the queue but someone may Tx afterwards.
> > needs_free_netdev is a footgun.  
> 
> Thanks Jakub. I've reworked it here to do the work before register/after
> unregister, without needs_free_netdev.
> 
> One question, the tx thread calls netif_wake_queue() - is it safe to call
> that after unregister_netdev()? (before free_netdev)

I don't think so.

> I've moved the kthread_stop() to the post-unregister cleanup.

The usual way to deal with Tx would be to quiesce the worker in
ndo_stop. Maybe keep it simple and add a mutex around the worker?
You can then take the same mutex around:

	stop queue
	purge queue
	
Thanks to the mutex you'd know the worker is not running and as
long as worker does its !skb_queue_empty() under the same mutex
it will not wake the queue.