FYI: v4l-linuxulator support in FreeBSD-current now [panic]
fbsd at opal.com
Thu Feb 18 20:59:14 UTC 2010
On Thu, 18 Feb 2010 19:23:36 +0100, Lars Engels <lme at FreeBSD.org> wrote:
> > >
> > > 1st) panic: freeing memory in linux_v4l_cliplist_free() which is not
> > > allocated, but there seems to be more which needs to be done.
> Hi jr,
> would you like to join us at #bsdusb at EFNet?
Sorry, not set up for IRC here.
Not sure how much help I would be. Never used video clip lists
myself. The only reason that code is there is to try to offer
more-or-less complete functionality rather than partial code.
The intent of this code is to copy the cliplist in, creating
new structures as it goes. This is necessary because the Linux
list nodes contain Linux pointers to the next node and the pointers
cannot be assumed to be the same size as FreeBSD pointers, especially
on 64-bit archs. So the code walks the list creating a new list, then
does the ioctl using that new list, then frees the new list again.
What I do recall is that some Linux applications apparently do not
use the cliplist but they also do not initialize the clips pointer
to NULL nor do they initialize clipcount. They just assume the
driver will ignore them, so don't bother setting them.
Could the failure you're experiencing be due to the fact that the
FreeBSD linuxulator code is trying to copy a list which is, in fact,
not a valid list?
I tried to avoid that, by only copying the list if clipcount <= 16384,
a value Alexander found in one of the Linux drivers that does support
cliplists. But if clipcount is > 0 && <= 16384, the clips pointer is
followed, and this will fail if the application has not initialized it.
The fix for this would be to either fix the Linux application code
to initialize the list properly, or to add some form of pointer
validation in the linuxulator code.
Oh, and I remembered why I used the double pointer in cliplist_free,
too. The cliplist_copy code uses a double pointer when creating the
list because the head pointer needs to be changed. For code symmetry
I therefore used the same double pointer when freeing the list.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-emulation/attachments/20100218/0fb2aa1a/signature.pgp
More information about the freebsd-emulation