>
>
> On Sat, 6 Mar 1999, Richard Guenther wrote:
> >
> > A bug in videodev.c lets you mmap device memory and free it
> > via close() - this leaves you with a nice "Blanko" mapping
> > of some memory. For example the bttv driver is vulnerable
> > as it frees its buffer in close(). (The drivers itself
> > cannot fix it, since they dont get the vm_area_struct)
>
> What the heck is the driver doing?
>
> A mmap() will keep the file count updated, so the driver has to do _extra_
> work in order to free some memory before all mmap areas have gone away.
> The file->release() thing is called after the very last "fput" of the file
> (ie after all fd's have been closed AND all memory mappings have been
> removed).
>
> This patch looks like extra code to get around some other driver bug, and
> I'd much rather just see the driver fixed properly.
Well, the driver is allocating some memory at mmap() time and maps
it to userspace (its not really file memory and there was (before the
patch) no file pointer associated with the vma). This memory gets
freed at close() time (as the driver cannot catch munmaps) - and
the close() gets delayed only, if there is a file with the vma
(and the use count properly updated).
This is the way I understand the world. file-release() will gain
me nothing!?
Richard.
-- Richard Guenther <richard.guenther@student.uni-tuebingen.de> PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57 WWW: http://www.anatom.uni-tuebingen.de/~richi/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/