mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andreas Haerter <ah@foundata.com>
To: tim770802@gmail.com
Cc: Chih.Hung.Huang@wnc.com.tw, andrew+netdev@lunn.ch,
	chandrashekar.devegowda@intel.com, davem@davemloft.net,
	edumazet@google.com, haijun.liu@mediatek.com, horms@kernel.org,
	ilpo.jarvinen@linux.intel.com, johannes@sipsolutions.net,
	kuba@kernel.org, linux-kernel@vger.kernel.org,
	loic.poulain@oss.qualcomm.com, netdev@vger.kernel.org,
	pabeni@redhat.com, ricardo.martinez@linux.intel.com,
	ryazanov.s.a@gmail.com, tim.jh.chen@wnc.com.tw
Subject: Re: [PATCH net v6 2/4] net: wwan: t7xx: do not exit the TX push kthread on resume failure
Date: Fri,  6 Nov 2026 06:45:30 +0100	[thread overview]
Message-ID: <20261106054532.201311-1-ah@foundata.com> (raw)
In-Reply-To: <20261002014638.47981-3-tim770802@gmail.com>

On Fri, Oct 02, 2026 at 09:46:36AM +0800, Tim JH Chen wrote:
> A later
> t7xx_dpmaif_tx_thread_rel() then calls kthread_stop() on the stale
> pointer [...]

I hit this in normal use on a ThinkPad X13 Gen 6 with a Rolling
RW350R-GL (14c3:4d75, subsystem 2099:3552), on Fedora's 7.2.4 and
7.2.5.

A runtime suspend failed with "[PM] SAP suspend error: -110". After
that, every MBIM write failed with -22 and the modem stayed dead.
Writing to the PCI remove attribute then gave a WARNING at
kernel/kthread.c:84 and, on a later occurrence, this oops:

  BUG: kernel NULL pointer dereference, address: 0000000000000000
  #PF: supervisor write access in kernel mode
  RIP: 0010:kthread_stop+0x44/0x180
  Call Trace:
   t7xx_dpmaif_hif_exit+0x46/0xa0 [mtk_t7xx]
   t7xx_md_exit+0x5c/0xa0 [mtk_t7xx]
   t7xx_pci_remove+0x41/0xc0 [mtk_t7xx]
   pci_device_remove+0x4a/0xb0
   device_release_driver_internal+0x19e/0x200
   pci_stop_bus_device+0x80/0xa0
   pci_stop_and_remove_bus_device_locked+0x1a/0x30
   remove_store+0x83/0xa0

The faulting instruction is the set_bit of KTHREAD_SHOULD_STOP with
worker_private NULL, so the pointer no longer referred to a kthread.
The writing process stayed in D state holding pci_rescan_remove_lock.
Shutdown then hung and the machine needed a forced power-off, which may
be worth a line in the changelog.

One question on the retry. In my case the failure is permanent:
runtime_error is latched, so rpm_resume() returns -EINVAL from then on.
With this patch the crash goes away, but TX stays dead and the thread
retries every 20 ms for as long as the TX lists are non-empty. Is that
the intended end state, or should something report the dead data path?

I have no reproducer, so I cannot offer a Tested-by.

Thanks,
Andreas

-- 
foundata GmbH
Steinhäuserstr. 20
76135 Karlsruhe

Web: https://foundata.com
Sitz der Gesellschaft: Karlsruhe
Registergericht: Amtsgericht Mannheim, HRB 714807
Geschäftsführung: Andreas Haerter
USt-IdNr.: DE284122682

  reply	other threads:[~2026-11-06  5:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02  1:46 [PATCH net v6 0/4] net: wwan: t7xx: fix DPMAIF data path vs system PM suspend Tim JH Chen
2026-10-02  1:46 ` [PATCH net v6 1/4] net: wwan: t7xx: fix runtime PM usage count underflow on -EACCES Tim JH Chen
2026-10-06  2:13   ` netdev-bot+sashiko
2026-10-02  1:46 ` [PATCH net v6 2/4] net: wwan: t7xx: do not exit the TX push kthread on resume failure Tim JH Chen
2026-11-06  5:45   ` Andreas Haerter [this message]
2026-10-02  1:46 ` [PATCH net v6 3/4] net: wwan: t7xx: fix race between TX/RX data path and system PM suspend Tim JH Chen
2026-10-06  2:13   ` netdev-bot+sashiko
2026-10-02  1:46 ` [PATCH net v6 4/4] net: wwan: t7xx: complete NAPI on the not-started RX poll early return Tim JH Chen
2026-10-06  2:13   ` netdev-bot+sashiko

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=20261106054532.201311-1-ah@foundata.com \
    --to=ah@foundata.com \
    --cc=Chih.Hung.Huang@wnc.com.tw \
    --cc=andrew+netdev@lunn.ch \
    --cc=chandrashekar.devegowda@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=haijun.liu@mediatek.com \
    --cc=horms@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=johannes@sipsolutions.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=loic.poulain@oss.qualcomm.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=ricardo.martinez@linux.intel.com \
    --cc=ryazanov.s.a@gmail.com \
    --cc=tim.jh.chen@wnc.com.tw \
    --cc=tim770802@gmail.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®