Hi Hans, On 2019-06-07 14:01, Hans Verkuil wrote: > On 6/7/19 1:16 PM, Laurent Pinchart wrote: >> Hi Hans, >> >> Thank you for the patch. >> >> On Fri, Jun 07, 2019 at 10:45:31AM +0200, Hans Verkuil wrote: >>> The __prepare_userptr() function made the incorrect assumption that if the >>> same user pointer was used as the last one for which memory was acquired, then >>> there was no need to re-acquire the memory. This assumption was never properly >>> tested, and after doing that it became clear that this was in fact wrong. >> Could you explain in the commit message why the assumption is not >> correct ? > You can free the memory, then allocate it again and you can get the same pointer, > even though it is not necessarily using the same physical pages for the memory > that the kernel is still using for it. > > Worse, you can free the memory, then allocate only half the memory you need and > get back the same pointer. vb2 wouldn't notice this. And it seems to work (since > the original mapping still remains), but this can corrupt userspace memory > causing the application to crash. It's not quite clear to me how the memory can > get corrupted. I don't know enough of those low-level mm internals to understand > the sequence of events. > > I have test code for v4l2-compliance available if someone wants to test this. I'm interested, I would really like to know what happens in the mm subsystem in such case. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
