From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5A8AC433F5 for ; Tue, 15 Feb 2022 15:58:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240950AbiBOP6b (ORCPT ); Tue, 15 Feb 2022 10:58:31 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:55230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238710AbiBOP63 (ORCPT ); Tue, 15 Feb 2022 10:58:29 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A7ED3BD2F9; Tue, 15 Feb 2022 07:58:19 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D1DCD6173A; Tue, 15 Feb 2022 15:58:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDB07C340EB; Tue, 15 Feb 2022 15:58:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644940698; bh=METPB92CtNbr6/d2L9GqXB2/kwPevXX1yNucGxSNXmE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dEdeMFUxg/2iUjXJZUkI26sBeNbtJZ1nmzy6ny2Wfjd4WPddAoev9Refn+mdZssgi 5Iy1xJuuz14QDQDZO3L6YwsWpIiVnG3xavGMamRBOibB6ThAH5fD1+EJMcISjuxgSf 63CPivcTBMEB22svZ0rdC13VHAiq4nb9esFm3em2GzP12n+hNqbYwkllvFjaH8Vk1l zUbqSZqsBRldRQPABcnCTybfLWY134UdEhFTCn3PHXPJq4uhbjSiUOlWBy4s6k3Cf4 HUkPc6t/rQvwS+RlP+vlpPNlfikaNR942cFpPmbTLWZNGvMT+96v1vmm/Bj/OrtYOl EbDDfs202xImQ== Date: Tue, 15 Feb 2022 07:58:16 -0800 From: Jakub Kicinski To: Matt Johnston Cc: Wolfram Sang , "David S . Miller" , Jeremy Kerr , linux-i2c@vger.kernel.org, netdev@vger.kernel.org, Zev Weiss Subject: Re: [PATCH net-next v5 2/2] mctp i2c: MCTP I2C binding driver Message-ID: <20220215075816.4188df1e@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> In-Reply-To: References: <20220210063651.798007-1-matt@codeconstruct.com.au> <20220210063651.798007-3-matt@codeconstruct.com.au> <20220211143815.55fb29e3@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20220214210410.2d49e55f@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Tue, 15 Feb 2022 18:01:25 +0800 Matt Johnston wrote: > Thanks. I'll just make sure to kthread_stop() prior to calling unregister. It > looks like the kthread needs to keep running when the interface is down to > handle MCTP release timeouts which unlock the i2c bus, so can't use ndo_stop. > > Similarly for the RX path, can I safely call netif_rx(skb) after unregister? > It looks like in that case it should be OK, since enqueue_to_backlog() tests > for netif_running() and just drops the packet. (It's running from the I2C > slave irq so can't just use a mutex). I wouldn't do it, using an object after it's unregistered is asking for trouble. RPS seems to happily dereference skb->dev. It may or may not work.