Re: [v4l-dvb-maintainer] Re: [PATCH] V4L: struct video_device corruption

[Trent Piepho <xyzzy@speakeasy.org>]

On Mon, 24 Jul 2006, Andrew Morton wrote:
> On Sat, 15 Jul 2006 22:31:04 -0300
> Mauro Carvalho Chehab <mchehab@infradead.org> wrote:
>
> > Em S�b, 2006-07-15 �s 23:08 +0000, Robert Fitzsimons escreveu:
> > > The layout of struct video_device would change depending on whether
> > > videodev.h (V4L1) was include or not before v4l2-dev.h, which caused
> > > the structure to get corrupted.
> > Hmm... good point! However, I the proper solution would be to trust on
> > CONFIG_VIDEO_V4L1_COMPAT or CONFIG_VIDEO_V4L1 instead. it makes no sense
> > to keep a pointer to an unsupported callback, when V4L1 is not selected.
> >
>
> So I've lost the plot with all of this.  Does the current git-dvb contain
> the desired fixes?

The problem was that the v4l code in general was not using
CONFIG_VIDEO_V4L1* like it should, but was detecting V4L1 support based on
whether on not the V4L1 header file had been included.

Some drivers didn't depend on V4L1 in Kconfig, and would include the V4L1
header when V4L1 was off.  This caused some code to think V4L1 was off and
some code to think it was on.

This caused a serious bug with inconsistent defintions of struct
video_device, as well as other problems.

I posted a patch that fixed the video_device problem, then Mauro made a
comprehensive patch that incorporated this fix and well as all the other
code that was using V4L1 when it shouldn't.  That patch is in the v4l-dvb
Mercurial repository, but not moved on to git yet.

> Do we expect this will fix the various DVB crashes which people (including
> Alex) have reported?

This problem would only appear if VIDEO_V4L1 was turned off.  If it was on,
then all the code would agree it was on, and there would be no problems.
If the crash is still there when VIDEO_V4L1 = y, then it's not related to
this bug.

If VIDEO_V4L1 was turned off, then some drivers (one of which is bttv)
would have a different struct video_device than the video core code.  This
would break things so completely that it could crash just about anywhere.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/