Re: Magic in videobuf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Hi Pawel,
>
> Pawel Osciak wrote:
>> Hello,
>>
>> is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code
>> besides driver debugging? I intend to remove them, as we weren't able
>> to find any particular use for them when we were discussing this at
>> the memory handling meeting in Norway...
>
> It is a sort of paranoid check to avoid the risk of mass memory corruption
> if something goes deadly wrong with the video buffers.
>
> The original videobuf, written back in 2001/2002 had this code, and I've
> kept it on the redesign I did in 2007, since I know that DMA is very badly
> implemented on some chipsets. There are several reports of the video
> driver
> to corrupt the system memory and damaging the disk data when a PCI
> transfer
> to disk happens at the same time that a PCI2PCI data transfer happens
> (This
> basically affects overlay mode, where the hardware is programmed to
> transfer
> data from the video board to the video adapter board).
>
> The DMA bug is present on several VIA and SYS old chipsets. It happened
> again
> in some newer chips (2007?), and the fix were to add a quirk blocking
> overlay
> mode on the reported broken hardware. It seems that newer BIOSes for those
> newer hardware fixed this issue.
>
> That's said, I never got any report from anyone explicitly saying that
> they
> hit the MAGIC_CHECK() logic.
>
> I prefer to keep this logic, but maybe we can add a CONFIG option to
> disable it.
> Something like:
>
> #ifdef CONFIG_VIDEO_DMA_PARANOID_CHECK
> 	#define MAGIC_CHECK() ...
> #else
> 	#define MAGIC_CHECK()
> #endif

What on earth does this magic check have to do with possible DMA
overruns/memory corruption? This assumes that somehow exactly these magic
fields are overwritten and that you didn't crash because of memory
corruption elsewhere much earlier. It pollutes the code for no good
reason. All it does is oops anyway, so it really doesn't 'avoid' a crash
(as if you could in such scenarios). And most likely the damage has been
done already in that case.

Please let us get rid of this. It makes no sense whatsoever.

Regards,

       Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux