RE: Magic in videobuf

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

 



>Mauro Carvalho Chehab wrote:
>>>>>> 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.
>>> Yes, that's the assumption. As, in general, there are more than one
>>> videobuffer,
>>> and assuming that one buffer physical address is close to the other, if
>>> the data
>>> got miss-aligned at the DMA, it is likely that the magic number of the
>>> next buffer
>>> will be overwritten if something got bad. The real situation will depend
>>> on how
>>> fragmented is the memory.
>>
>> For the record: we are talking about the magic fields as found in
>> include/media/videobuf*.h. None of the magic field there are actually in
>> the video buffers. They are in administrative structures or in ops structs
>> which are unlikely to be close in memory to the actual buffers.
>
>Well, Pawel's email didn't mentioned that he is referring just to one type
>of magic check.

Thanks for the explanation. Although I don't really understand how any of
the magic numbers would help with DMA corruption, short of DMA operations
overwriting random memory areas (or just huge amounts of memory). If I understood
correctly, even the magics in dma-sg code are in structs videobuf_dmabuf and
videobuf_dma_sg_memory. Do dma operations touch those structures directly?


Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center



--
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