From: Shannon Nelson <snelson@pensando.io> To: Thomas Gleixner <tglx@linutronix.de>, LKML <linux-kernel@vger.kernel.org> Cc: Peter Zijlstra <peterz@infradead.org>, Linus Torvalds <torvalds@linuxfoundation.org>, Paul McKenney <paulmck@kernel.org>, Matthew Wilcox <willy@infradead.org>, Sebastian Andrzej Siewior <bigeasy@linutronix.de>, Pensando Drivers <drivers@pensando.io>, "David S. Miller" <davem@davemloft.net>, Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org, Christian Benvenuti <benve@cisco.com>, Govindarajulu Varadarajan <_govind@gmx.com>, Jonathan Corbet <corbet@lwn.net>, Mauro Carvalho Chehab <mchehab+huawei@kernel.org>, linux-doc@vger.kernel.org, Luc Van Oostenryck <luc.vanoostenryck@gmail.com>, Jay Cliburn <jcliburn@gmail.com>, Chris Snook <chris.snook@gmail.com>, Vishal Kulkarni <vishal@chelsio.com>, Jeff Kirsher <jeffrey.t.kirsher@intel.com>, intel-wired-lan@lists.osuosl.org, Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>, Russell King <linux@armlinux.org.uk>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, Solarflare linux maintainers <linux-net-drivers@solarflare.com>, Edward Cree <ecree@solarflare.com>, Martin Habets <mhabets@solarflare.com>, Jon Mason <jdmason@kudzu.us>, Daniel Drake <dsd@gentoo.org>, Ulrich Kunitz <kune@deine-taler.de>, Kalle Valo <kvalo@codeaurora.org>, linux-wireless@vger.kernel.org, linux-usb@vger.kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Arend van Spriel <arend.vanspriel@broadcom.com>, Franky Lin <franky.lin@broadcom.com>, Hante Meuleman <hante.meuleman@broadcom.com>, Chi-Hsien Lin <chi-hsien.lin@cypress.com>, Wright Feng <wright.feng@cypress.com>, brcm80211-dev-list.pdl@broadcom.com, brcm80211-dev-list@cypress.com, Stanislav Yakovlev <stas.yakovlev@gmail.com>, Stanislaw Gruszka <stf_xl@wp.pl>, Johannes Berg <johannes.berg@intel.com>, Emmanuel Grumbach <emmanuel.grumbach@intel.com>, Luca Coelho <luciano.coelho@intel.com>, Intel Linux Wireless <linuxwifi@intel.com>, Jouni Malinen <j@w1.fi>, Amitkumar Karwar <amitkarwar@gmail.com>, Ganapathi Bhat <ganapathi.bhat@nxp.com>, Xinming Hu <huxinming820@gmail.com>, libertas-dev@lists.infradead.org, Pascal Terjan <pterjan@google.com>, Ping-Ke Shih <pkshih@realtek.com> Subject: Re: [patch 11/35] net: ionic: Replace in_interrupt() usage. Date: Mon, 28 Sep 2020 12:51:14 -0700 [thread overview] Message-ID: <1d0950f8-cab4-9ef2-6cf7-73b71b750a8d@pensando.io> (raw) In-Reply-To: <5e4c3201-9d90-65b1-5c13-e2381445be1d@pensando.io> On 9/28/20 10:24 AM, Shannon Nelson wrote: > On 9/27/20 12:48 PM, Thomas Gleixner wrote: >> From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> >> >> The in_interrupt() usage in this driver tries to figure out which >> context >> may sleep and which context may not sleep. in_interrupt() is not really >> suitable as it misses both preemption disabled and interrupt disabled >> invocations from task context. >> >> Conditionals like that in driver code are frowned upon in general >> because >> invocations of functions from invalid contexts might not be detected >> as the conditional papers over it. >> >> ionic_lif_addr() can be called from: >> >> 1) ->ndo_set_rx_mode() which is under netif_addr_lock_bh()) so it >> must not >> sleep. >> >> 2) Init and setup functions which are in fully preemptible task >> context. >> >> _ionic_lif_rx_mode() has only one call path with BH disabled. Now that I've had my coffee, let's look at this again - there are multiple paths that get us to _ionic_lif_rx_mode(): .ndo_set_rx_mode ionic_set_rx_mode, _ionic_lif_rx_mode { ionic_open, ionic_lif_handle_fw_up, ionic_start_queues_reconfig } ionic_txrx_init ionic_set_rx_mode _ionic_lif_rx_mode We may not want to change this one. sln >> >> ionic_link_status_check_request() has two call paths: >> >> 1) NAPI which obviously cannot sleep >> >> 2) Setup which is again fully preemptible task context >> >> Add 'can_sleep' arguments to the affected functions and let the callers >> provide the context instead of letting the functions deduce it. >> >> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> >> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> >> Cc: Shannon Nelson <snelson@pensando.io> >> Cc: Pensando Drivers <drivers@pensando.io> >> Cc: "David S. Miller" <davem@davemloft.net> >> Cc: Jakub Kicinski <kuba@kernel.org> >> Cc: netdev@vger.kernel.org > > Acked-by: Shannon Nelson <snelson@pensando.io> > >> --- >> >> While reviewing the callpaths, a couple of things were observed which >> could >> be improved: >> >> - ionic_lif_deferred_work() can iterate over the list. There is no need >> to schedule the work item after each iteration > > I think the original writer's intent was to avoid monopolizing the > work thread for very long on any one cycle, with the thought that we'd > be making more use of this than we currently are. I'll address this. > >> >> - ionic_link_status_check_request() could have ionic_deferred_work >> within >> ionic_lif(). This would avoid memory allocation from NAPI. More >> important, once IONIC_LIF_F_LINK_CHECK_REQUESTED is set and that >> alloc >> fails, the link check never happens. > > Thanks, I'll fix up that error condition. > >> >> - ionic_lif_handle_fw_down() sets IONIC_LIF_F_FW_RESET. Invokes then >> ionic_lif_deinit() which only invokes cancel_work_sync() if >> IONIC_LIF_F_FW_RESET is not set. I think the logic is wrong here as >> the work must always be cancled. Also the list with ionic_deferred >> work items needs a clean up. > > I'll look at that, thanks. > > sln > >
WARNING: multiple messages have this Message-ID (diff)
From: Shannon Nelson <snelson@pensando.io> To: intel-wired-lan@osuosl.org Subject: [Intel-wired-lan] [patch 11/35] net: ionic: Replace in_interrupt() usage. Date: Mon, 28 Sep 2020 12:51:14 -0700 [thread overview] Message-ID: <1d0950f8-cab4-9ef2-6cf7-73b71b750a8d@pensando.io> (raw) In-Reply-To: <5e4c3201-9d90-65b1-5c13-e2381445be1d@pensando.io> On 9/28/20 10:24 AM, Shannon Nelson wrote: > On 9/27/20 12:48 PM, Thomas Gleixner wrote: >> From: Sebastian Andrzej Siewior <bigeasy@linutronix.de> >> >> The in_interrupt() usage in this driver tries to figure out which >> context >> may sleep and which context may not sleep. in_interrupt() is not really >> suitable as it misses both preemption disabled and interrupt disabled >> invocations from task context. >> >> Conditionals like that in driver code are frowned upon in general >> because >> invocations of functions from invalid contexts might not be detected >> as the conditional papers over it. >> >> ionic_lif_addr() can be called from: >> >> ? 1) ->ndo_set_rx_mode() which is under netif_addr_lock_bh()) so it >> must not >> ???? sleep. >> >> ? 2) Init and setup functions which are in fully preemptible task >> context. >> >> _ionic_lif_rx_mode() has only one call path with BH disabled. Now that I've had my coffee, let's look at this again - there are multiple paths that get us to _ionic_lif_rx_mode(): .ndo_set_rx_mode ? ionic_set_rx_mode, ??? _ionic_lif_rx_mode { ionic_open, ionic_lif_handle_fw_up, ionic_start_queues_reconfig } ??? ionic_txrx_init ????? ionic_set_rx_mode ??????? _ionic_lif_rx_mode We may not want to change this one. sln >> >> ionic_link_status_check_request() has two call paths: >> >> ? 1) NAPI which obviously cannot sleep >> >> ? 2) Setup which is again fully preemptible task context >> >> Add 'can_sleep' arguments to the affected functions and let the callers >> provide the context instead of letting the functions deduce it. >> >> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> >> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> >> Cc: Shannon Nelson <snelson@pensando.io> >> Cc: Pensando Drivers <drivers@pensando.io> >> Cc: "David S. Miller" <davem@davemloft.net> >> Cc: Jakub Kicinski <kuba@kernel.org> >> Cc: netdev at vger.kernel.org > > Acked-by: Shannon Nelson <snelson@pensando.io> > >> --- >> >> While reviewing the callpaths, a couple of things were observed which >> could >> be improved: >> >> - ionic_lif_deferred_work() can iterate over the list. There is no need >> ?? to schedule the work item after each iteration > > I think the original writer's intent was to avoid monopolizing the > work thread for very long on any one cycle, with the thought that we'd > be making more use of this than we currently are.? I'll address this. > >> >> - ionic_link_status_check_request() could have ionic_deferred_work >> within >> ?? ionic_lif(). This would avoid memory allocation from NAPI. More >> ?? important, once IONIC_LIF_F_LINK_CHECK_REQUESTED is set and that >> alloc >> ?? fails, the link check never happens. > > Thanks, I'll fix up that error condition. > >> >> - ionic_lif_handle_fw_down() sets IONIC_LIF_F_FW_RESET. Invokes then >> ?? ionic_lif_deinit() which only invokes cancel_work_sync() if >> ?? IONIC_LIF_F_FW_RESET is not set. I think the logic is wrong here as >> ?? the work must always be cancled. Also the list with ionic_deferred >> ?? work items needs a clean up. > > I'll look at that, thanks. > > sln > >
next prev parent reply other threads:[~2020-09-28 19:51 UTC|newest] Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-27 19:48 [patch 00/35] net: in_interrupt() cleanup and fixes Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:48 ` [patch 01/35] net: enic: Cure the enic api locking trainwreck Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 22:06 ` kernel test robot 2020-09-27 19:48 ` [patch 02/35] net: caif: Remove unused caif SPI driver Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:48 ` [patch 03/35] net: Add netif_rx_any_context() Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:48 ` [patch 04/35] net: caif: Use netif_rx_any_context() Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:48 ` [patch 05/35] net: atheros: Remove WARN_ON(in_interrupt()) Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:48 ` [patch 06/35] net: cxgb3: Cleanup in_interrupt() usage Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:48 ` [patch 07/35] net: cxbg4: Remove pointless in_interrupt() check Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:48 ` [patch 08/35] net: e100: Remove in_interrupt() usage and pointless GFP_ATOMIC allocation Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:48 ` [patch 09/35] net: fec_mpc52xx: Replace in_interrupt() usage Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:48 ` [patch 10/35] net: intel: Remove in_interrupt() warnings Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-28 23:04 ` Alexander Duyck 2020-09-28 23:04 ` [Intel-wired-lan] " Alexander Duyck 2020-09-27 19:48 ` [patch 11/35] net: ionic: Replace in_interrupt() usage Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-28 17:24 ` Shannon Nelson 2020-09-28 17:24 ` [Intel-wired-lan] " Shannon Nelson 2020-09-28 19:51 ` Shannon Nelson [this message] 2020-09-28 19:51 ` Shannon Nelson 2020-09-29 14:37 ` Thomas Gleixner 2020-09-29 14:37 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:48 ` [patch 12/35] net: ionic: Remove WARN_ON(in_interrupt()) Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-28 17:26 ` Shannon Nelson 2020-09-28 17:26 ` [Intel-wired-lan] " Shannon Nelson 2020-09-27 19:48 ` [patch 13/35] net: mdiobus: Remove WARN_ON_ONCE(in_interrupt()) Thomas Gleixner 2020-09-27 19:48 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 23:00 ` Andrew Lunn 2020-09-27 23:00 ` [Intel-wired-lan] " Andrew Lunn 2020-09-27 19:49 ` [patch 14/35] net: natsemi: Replace in_interrupt() usage Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 15/35] net: sfc: " Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-28 19:03 ` Edward Cree 2020-09-28 19:03 ` [Intel-wired-lan] " Edward Cree 2020-09-28 20:05 ` [RFC PATCH net-next] sfc: replace " Edward Cree 2020-09-28 20:24 ` Thomas Gleixner 2020-09-29 15:15 ` Edward Cree 2020-09-29 19:27 ` Thomas Gleixner 2020-09-29 9:39 ` Martin Habets 2020-09-27 19:49 ` [patch 16/35] net: sunbmac: Replace " Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 17/35] net: sun3lance: Remove redundant checks in interrupt handler Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 18/35] net: vxge: Remove in_interrupt() conditionals Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 19/35] net: zd1211rw: Remove ZD_ASSERT(in_interrupt()) Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 20/35] net: usb: kaweth: Replace kaweth_control() with usb_control_msg() Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 21/35] net: usb: kaweth: Remove last user of kaweth_control() Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-28 6:50 ` Greg Kroah-Hartman 2020-09-28 6:50 ` [Intel-wired-lan] " Greg Kroah-Hartman 2020-09-27 19:49 ` [patch 22/35] net: usb: net1080: Remove in_interrupt() comment Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 23/35] net: wan/lmc: Remove lmc_trace() Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 24/35] net: brcmfmac: Replace in_interrupt() Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-28 7:35 ` Arend Van Spriel 2020-09-28 7:35 ` [Intel-wired-lan] " Arend Van Spriel 2020-09-28 9:19 ` Ulf Hansson 2020-09-28 9:19 ` [Intel-wired-lan] " Ulf Hansson 2020-09-28 9:37 ` Arend Van Spriel 2020-09-28 9:37 ` [Intel-wired-lan] " Arend Van Spriel 2020-09-28 9:40 ` Arend Van Spriel 2020-09-28 9:40 ` [Intel-wired-lan] " Arend Van Spriel 2020-09-27 19:49 ` [patch 25/35] net: brcmfmac: Use netif_rx_any_context() Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-28 8:03 ` Arend Van Spriel 2020-09-28 8:03 ` [Intel-wired-lan] " Arend Van Spriel 2020-09-27 19:49 ` [patch 26/35] net: brcmfmac: Convey allocation mode as argument Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-28 9:34 ` Arend Van Spriel 2020-09-28 9:34 ` [Intel-wired-lan] " Arend Van Spriel 2020-09-27 19:49 ` [patch 27/35] net: ipw2x00,iwlegacy,iwlwifi: Remove in_interrupt() from debug macros Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] [patch 27/35] net: ipw2x00, iwlegacy, iwlwifi: " Thomas Gleixner 2020-09-27 19:49 ` [patch 28/35] net: iwlwifi: Remove in_interrupt() from tracing macro Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-28 6:13 ` Coelho, Luciano 2020-09-28 6:13 ` [Intel-wired-lan] " Coelho, Luciano 2020-09-27 19:49 ` [patch 29/35] net: hostap: Remove in_interrupt() usage Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 30/35] net: mwifiex: Use netif_rx_any_context() Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 31/35] net: libertas libertas_tf: Remove in_interrupt() from debug macro Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 32/35] net: libertas: Use netif_rx_any_context() Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 33/35] net: rtlwifi: Remove void* casts related to delayed work Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 34/35] net: rtlwifi: Remove in_interrupt() from debug macro Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 19:49 ` [patch 35/35] net: rtlwifi: Replace in_interrupt() for context detection Thomas Gleixner 2020-09-27 19:49 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-27 20:22 ` [patch 00/35] net: in_interrupt() cleanup and fixes Joe Perches 2020-09-27 20:22 ` [Intel-wired-lan] " Joe Perches 2020-09-27 20:57 ` David Miller 2020-09-27 20:57 ` [Intel-wired-lan] " David Miller 2020-09-28 10:25 ` Thomas Gleixner 2020-09-28 10:25 ` [Intel-wired-lan] " Thomas Gleixner 2020-09-29 8:01 ` Kalle Valo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1d0950f8-cab4-9ef2-6cf7-73b71b750a8d@pensando.io \ --to=snelson@pensando.io \ --cc=_govind@gmx.com \ --cc=amitkarwar@gmail.com \ --cc=andrew@lunn.ch \ --cc=arend.vanspriel@broadcom.com \ --cc=benve@cisco.com \ --cc=bigeasy@linutronix.de \ --cc=brcm80211-dev-list.pdl@broadcom.com \ --cc=brcm80211-dev-list@cypress.com \ --cc=chi-hsien.lin@cypress.com \ --cc=chris.snook@gmail.com \ --cc=corbet@lwn.net \ --cc=davem@davemloft.net \ --cc=drivers@pensando.io \ --cc=dsd@gentoo.org \ --cc=ecree@solarflare.com \ --cc=emmanuel.grumbach@intel.com \ --cc=franky.lin@broadcom.com \ --cc=ganapathi.bhat@nxp.com \ --cc=gregkh@linuxfoundation.org \ --cc=hante.meuleman@broadcom.com \ --cc=hkallweit1@gmail.com \ --cc=huxinming820@gmail.com \ --cc=intel-wired-lan@lists.osuosl.org \ --cc=j@w1.fi \ --cc=jcliburn@gmail.com \ --cc=jdmason@kudzu.us \ --cc=jeffrey.t.kirsher@intel.com \ --cc=johannes.berg@intel.com \ --cc=kuba@kernel.org \ --cc=kune@deine-taler.de \ --cc=kvalo@codeaurora.org \ --cc=libertas-dev@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-net-drivers@solarflare.com \ --cc=linux-usb@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=linuxwifi@intel.com \ --cc=luc.vanoostenryck@gmail.com \ --cc=luciano.coelho@intel.com \ --cc=mchehab+huawei@kernel.org \ --cc=mhabets@solarflare.com \ --cc=netdev@vger.kernel.org \ --cc=paulmck@kernel.org \ --cc=peterz@infradead.org \ --cc=pkshih@realtek.com \ --cc=pterjan@google.com \ --cc=stas.yakovlev@gmail.com \ --cc=stf_xl@wp.pl \ --cc=tglx@linutronix.de \ --cc=torvalds@linuxfoundation.org \ --cc=tsbogend@alpha.franken.de \ --cc=vishal@chelsio.com \ --cc=willy@infradead.org \ --cc=wright.feng@cypress.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.