From: Hans Verkuil <hverkuil+cisco@kernel.org>
To: Marek Szyprowski <m.szyprowski@samsung.com>,
Benjamin Gaignard <benjamin.gaignard@collabora.com>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Tomasz Figa <tfiga@chromium.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
Hans Verkuil <hverkuil@kernel.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] media: videobuf2: forbid create_bufs/remove_bufs when legacy fileio is active
Date: Mon, 20 Oct 2025 09:39:57 +0200 [thread overview]
Message-ID: <1f2748a5-1955-48dd-93e4-69e032d895e0@kernel.org> (raw)
In-Reply-To: <84133573-986d-4cc8-8147-246f0da34640@samsung.com>
On 20/10/2025 09:34, Marek Szyprowski wrote:
> On 20.10.2025 09:11, Benjamin Gaignard wrote:
>>
>> Le 16/10/2025 à 13:11, Marek Szyprowski a écrit :
>>> create_bufs and remove_bufs ioctl calls manipulate queue internal buffer
>>> list, potentially overwriting some pointers used by the legacy fileio
>>> access mode. Simply forbid those calls when fileio is active to protect
>>> internal queue state between subsequent read/write calls.
>>
>> Hi Marek,
>>
>> I may be wrong but using fileio API and create/remove API at the same
>> time
>> sound incorrect from application point of view, right ? If that not the
>> case maybe we should also add a test in v4l2-compliance.
>
> Definitely that's incorrect and v4l2-core must forbid such calls. The
> standard reqbufs/qbuf/dqbuf API is also forbidden. Extending
> v4l2-compliance tools is probably a good idea.
Yes, please! A patch is welcome.
I also wonder if its a
> good time to add a kernel option to completely disable legacy fileio
> access mode, as it is not really needed for most of the systems nowadays.
No, that will break applications. Using read() is very common (and convenient!)
for MPEG encoders such as the cx18 driver.
The fileio code is not blocking any new development, it's just there for those
drivers were it makes sense.
Regards,
Hans
>
> > ...
>
> Best regards
next prev parent reply other threads:[~2025-10-20 7:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20251016111208eucas1p24cd8cc1e952a8cdf73fbadea704b499d@eucas1p2.samsung.com>
2025-10-16 11:11 ` Marek Szyprowski
2025-10-20 7:11 ` Benjamin Gaignard
2025-10-20 7:34 ` Marek Szyprowski
2025-10-20 7:39 ` Hans Verkuil [this message]
2025-10-20 7:48 ` Benjamin Gaignard
2025-10-20 8:21 ` Marek Szyprowski
2025-10-20 8:30 ` Benjamin Gaignard
2025-10-20 16:05 ` Marek Szyprowski
2025-10-20 7:36 ` Marek Szyprowski
2025-10-18 18:34 Bai, Shuangpeng
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=1f2748a5-1955-48dd-93e4-69e032d895e0@kernel.org \
--to=hverkuil+cisco@kernel.org \
--cc=benjamin.gaignard@collabora.com \
--cc=g.liakhovetski@gmx.de \
--cc=hverkuil@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mchehab@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tfiga@chromium.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®