Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <a78920881b2ffaf1fba04bc9ebeda591ec0dfd87.camel@ndufresne.ca>
Subject: Re: [PATCH v4 03/24] media: videobuf2-v4l2: Warn on holding buffers
 without support
From:   Nicolas Dufresne <nicolas@ndufresne.ca>
To:     Tomasz Figa <tfiga@chromium.org>,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        Hans Verkuil <hverkuil@xs4all.nl>
Cc:     Sebastian Fricke <sebastian.fricke@collabora.com>,
        linux-media@vger.kernel.org,
        Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>,
        linux-kernel@vger.kernel.org
Date:   Wed, 27 Apr 2022 11:08:24 -0400
In-Reply-To: <CAAFQd5C6qmxmn4y=cx5Mtb3p8vcTAFm6Jfc1vMAE8+x9iwhDZg@mail.gmail.com>
References: <20220426125751.108293-1-nicolas.dufresne@collabora.com>
         <20220426125751.108293-4-nicolas.dufresne@collabora.com>
         <CAAFQd5C6qmxmn4y=cx5Mtb3p8vcTAFm6Jfc1vMAE8+x9iwhDZg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.0 (3.44.0-1.fc36) 
MIME-Version: 1.0
Precedence: bulk

Le mercredi 27 avril 2022 =C3=A0 13:31 +0900, Tomasz Figa a =C3=A9crit=C2=
=A0:
> Hi Nicolas, Sebastian,
>=20
> On Tue, Apr 26, 2022 at 9:58 PM Nicolas Dufresne
> <nicolas.dufresne@collabora.com> wrote:
> >=20
> > From: Sebastian Fricke <sebastian.fricke@collabora.com>
> >=20
> > Using V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF flag without specifying the
> > subsystem flag VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF, results in
> > silently ignoring it.
> > Warn the user via a debug print when the flag is requested but ignored
> > by the videobuf2 framework.
> >=20
> > Signed-off-by: Sebastian Fricke <sebastian.fricke@collabora.com>
> > Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> > Reviewed-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
> > ---
> >  drivers/media/common/videobuf2/videobuf2-v4l2.c | 7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >=20
>=20
> Thanks for the patch. Please see my comments inline.
>=20
> > diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c b/drivers/=
media/common/videobuf2/videobuf2-v4l2.c
> > index 6edf4508c636..812c8d1962e0 100644
> > --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
> > @@ -329,8 +329,13 @@ static int vb2_fill_vb2_v4l2_buffer(struct vb2_buf=
fer *vb, struct v4l2_buffer *b
> >                  */
> >                 vbuf->flags &=3D ~V4L2_BUF_FLAG_TIMECODE;
> >                 vbuf->field =3D b->field;
> > -               if (!(q->subsystem_flags & VB2_V4L2_FL_SUPPORTS_M2M_HOL=
D_CAPTURE_BUF))
> > +               if (!(q->subsystem_flags & VB2_V4L2_FL_SUPPORTS_M2M_HOL=
D_CAPTURE_BUF)) {
> > +                       if (vbuf->flags & V4L2_BUF_FLAG_M2M_HOLD_CAPTUR=
E_BUF)
> > +                               dprintk(q, 1,
> > +                                       "Request holding buffer (%d), u=
nsupported on output queue\n",
> > +                                       b->index);
>=20
> I wonder if we shouldn't just fail such a QBUF operation. Otherwise
> the application would get unexpected behavior from the kernel.
> Although it might be too late to do it now if there are applications
> that rely on this implicit ignore...

In the context of this patchset, the statu quo seems to be the logical thin=
g to
do. We can raise this up in a separate thread. The side effect is of course
confusing for developers, but it is hard for me to tell if a hard failure m=
ay
break an existing software.

regards,
Nicolas

>=20
> Best regards,
> Tomasz