From: sashiko-bot@kernel.org
To: "Tapio Reijonen" <tapio.reijonen@vaisala.com>
Cc: linux-serial@vger.kernel.org
Subject: Re: [PATCH v2 1/2] serial: core: do not hold the port mutex while waiting for references
Date: Thu, 12 Nov 2026 04:52:42 +0000 [thread overview]
Message-ID: <sashiko-outbox-210398@kernel.org> (raw)
In-Reply-To: <20261112-serial-core-remove-deadlock-v2-1-d3ee4ccec37a@vaisala.com>
> serial_core_remove_one_port() takes the port mutex and then waits for
> the uart_port_ref() holders to drop their references. Since commit
> 8ca59f7baee7 ("serial: fix ioctl hangup race") uart_wait_until_sent()
> takes the port mutex on every poll iteration to check for the hangup
> before it touches the hardware, while holding its reference for the
> whole wait. A tcdrain() in flight when the port is removed therefore
> deadlocks: the removal holds the mutex and waits for the reference,
> the drain holds the reference and waits for the mutex. Both tasks sit
> uninterruptible, and the port is unusable until a reboot.
>
> Reproduced by unbinding a UART driver while a process drains a few
> kilobytes at 300 baud: the unbind blocks in wait_event() under the
> mutex, the drain in mutex_lock(), and reading the driver's proc file
> blocks on the same mutex.
>
> Drop the mutex around the decrement and the wait. The decrement is an
> atomic paired with uart_port_ref() and uart_port_deref(), which never
> take the mutex; the clearing of the port pointer stays under it, where
> uart_port_check() readers expect it. Between the hangup and this wait
> the removal already runs without the mutex, so a mutex holder seeing
> the released port is not a new state.
> uart_wait_modem_status() takes a reference and then the mutex in the
> same way, with a smaller window, and is covered by the same change.
>
> Fixes: 8ca59f7baee7 ("serial: fix ioctl hangup race")
> Cc: <stable@vger.kernel.org>
> Reviewed-by: Johan Hovold <johan@kernel.org>
> Tested-by: Johan Hovold <johan@kernel.org>
> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
Sashiko has reviewed this patch and found no issues.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261112-serial-core-remove-deadlock-v2-0-d3ee4ccec37a@vaisala.com?part=1
next prev parent reply other threads:[~2026-11-12 4:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 4:37 [PATCH v2 0/2] serial: core: two fixes for the port removal path Tapio Reijonen
2026-11-12 4:37 ` [PATCH v2 1/2] serial: core: do not hold the port mutex while waiting for references Tapio Reijonen
2026-11-12 4:52 ` sashiko-bot [this message]
2026-11-12 4:37 ` [PATCH v2 2/2] serial: core: do not touch the port after dropping the last reference Tapio Reijonen
2026-11-12 4:41 ` sashiko-bot
2026-11-12 14:32 ` Johan Hovold
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=sashiko-outbox-210398@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tapio.reijonen@vaisala.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 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.