From: Josef Schlehofer <pepe.schlehofer@gmail.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
Hyunwoo Kim <imv4bel@gmail.com>,
Hans Verkuil <hverkuil@kernel.org>
Subject: [PATCH v2 0/6] media: az6007/drxk/dvb-core: cope with a tuner unplugged while in use
Date: Sun, 4 Oct 2026 12:07:35 +0200 [thread overview]
Message-ID: <20261004100741.71711-1-pepe.schlehofer@gmail.com> (raw)
Unplugging an az6007 based tuner while it is in use can leave parts of
the DVB stack stuck on the disconnected device:
- drxk keeps accessing the device and hides the resulting errors,
- the CA thread can stay stuck polling the removed CAM slot, which
keeps the disconnect from completing,
- userspace waiting on the DVB devices is neither woken up nor told
that the device is gone, so the disconnect can wait indefinitely for
it to close the devices.
This series fixes these issues by:
- treating an unreadable CAM slot status as no CAM,
- propagating -ENODEV from az6007 to drxk and stopping further device
access,
- waking up the users of the demux, dvr and CA devices and returning
-ENODEV or EPOLLERR to them.
Tested on:
- Linux 6.18.44 on a Turris 1.x (v1) and Linux 6.6.151 on a Turris
Omnia (v2, series backported), both with a TechniSat CableStar Combo
HD CI and a CAM,
- v7.3-rc2 in QEMU with vidtv and two vidtv fixes from media next [2]
(v1 and v2).
The tests covered streaming and scanning in tvheadend, blocked read(),
poll() and epoll_wait() calls, sysfs unbind, and unplugging the tuner
or the whole USB hub. In all of them the blocked calls returned and the
disconnect completed. Without the series, unbinding vidtv with a
blocked reader hung, which is the hang that the commit message of the
second vidtv fix [2] asks about.
Changes in v2:
- Patch 5: check dmxdev->exit in the readers instead of storing -ENODEV
in the buffer error, which a concurrent reader could clear, as
reported by Sashiko [1]. With a test-only delay, two readers of one
file reproduced that race in QEMU with v1 but not with v2.
- Patches 1-4 and 6 are unchanged.
v1: https://lore.kernel.org/r/20260923001410.30297-1-pepe.schlehofer@gmail.com
[1] https://linuxtv.org/mailman3/hyperkitty/list/media-ci@linuxtv.org/message/N3XJE5MO4HP2LJYOKFHIRB564HATZCTI/
[2] "media: vidtv: fix frontend reference leak on unbind" and
"media: vidtv: fix uaf in vidtv_bridge_on_new_pkts_avail"
Josef Schlehofer (6):
media: az6007: fix CAM status polling after disconnect
media: az6007: propagate USB errors from I2C transfers
media: drxk: stop retrying after disconnect
media: drxk: stop accessing a disconnected device
media: dvb-core: dmxdev: wake up readers on release
media: dvb-core: wake up CA users on release
drivers/media/dvb-core/dmxdev.c | 36 +++++++++++++++----
drivers/media/dvb-core/dvb_ca_en50221.c | 24 ++++++++++++-
drivers/media/dvb-frontends/drxk_hard.c | 48 +++++++++++++++++++------
drivers/media/dvb-frontends/drxk_hard.h | 2 +-
drivers/media/usb/dvb-usb-v2/az6007.c | 23 ++++++------
5 files changed, 105 insertions(+), 28 deletions(-)
base-commit: df2908090cda368b01ff43709f51890076c56157
--
2.54.0 (Apple Git-157)
next reply other threads:[~2026-10-04 10:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-04 10:07 Josef Schlehofer [this message]
2026-10-04 10:07 ` [PATCH v2 1/6] media: az6007: fix CAM status polling after disconnect Josef Schlehofer
2026-10-04 10:07 ` [PATCH v2 2/6] media: az6007: propagate USB errors from I2C transfers Josef Schlehofer
2026-10-04 10:07 ` [PATCH v2 3/6] media: drxk: stop retrying after disconnect Josef Schlehofer
2026-10-04 10:07 ` [PATCH v2 4/6] media: drxk: stop accessing a disconnected device Josef Schlehofer
2026-10-04 10:07 ` [PATCH v2 5/6] media: dvb-core: dmxdev: wake up readers on release Josef Schlehofer
2026-10-04 10:07 ` [PATCH v2 6/6] media: dvb-core: wake up CA users " Josef Schlehofer
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=20261004100741.71711-1-pepe.schlehofer@gmail.com \
--to=pepe.schlehofer@gmail.com \
--cc=hverkuil@kernel.org \
--cc=imv4bel@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
/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®