Messages in this thread | | | Date | Sun, 7 Mar 1999 10:24:10 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: BUG in videodev.c [PATCH] |
| |
On Sun, 7 Mar 1999, Richard Guenther wrote: > > 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).
Fair enough. That's how things are supposed to work.
> 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).
The driver _can_ and _will_ catch munmaps. But I see what the problem is now: it appears that the driver has a completely unrelated bug, which is that it doesn't save away the file in the vma, which is why the system gets confused: it doesn't know that the mapping still holds on to driver resources.
This, btw, could result in other nasty problems too, like not keeping track of module counts correctly etc. Happily the fix is really simple.
> This is the way I understand the world. file-release() will gain > me nothing!?
the file release _would_ have worked just fine, except the driver apparently doesn't install the file in the mmap at all. Which is a serious bug anyway, because it means that the VM system doesn't even know that the mmap() is a non-anonymous thing, and the VM system can do some very strange things when merging and unmerging vma's..
Anyway, the fix should be really simple: do a
vma->vm_file = file; file->f_count++;
inside the driver mmap() routine after a successful mmap, and you're all done, and you can remove the silly workarounds for the bug.
Alan, it sounds like the sound drivers have the same problem, considering that you said that they've been getting the same reports.
Btw, this is really easy to check from user mode: if you have the bug, then the /proc/<pid>/maps file will contain bad information (it will show up as an anonymous mapping in the maps file, rather than as a nice pointer to the device file you mmapped).
Maybe I should do the vm_file update inside the mm system, so that nobody can forget this even by mistake. Hmm..
Anyway, this certainly explains everything.
Linus
- 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/
| |