They are now, I hope. I fixed that in 2.4.18-pre2.
drivers/video/fbmem.c:fb_mmap() marks the vma as
VM_IO for all architectures. But perhaps I missed some;
an audit is needed in there, which I'll do.
> It's cute - fbmem.c goes out of its way to set the flag on some
> architectures and not others. I can't imagine why.
>
> But with that, yes, that should fix it.
>
> > > Of course, I would much rather be able to see the contents of the
> > > framebuffer. Any suggestions?
> >
> > Not with this patch, I'm afraid. For your testing purposes you
> > could just remove the VALID_PAGE() test in mm/memory.c:get_page_map(),
> > and then gdb should be able to get at the framebuffer.
>
> I'm sure there's a good reason to not do that in general. Mind
> enlightening me?
Well, get_user_pages is used by several parts of the kernel.
In the O_DIRECT/map_user_kiobuf case, we could end up asking
the disk controller to perform busmastering against the video
PCI device, which will probably explode somewhere down the chain.
Also, just because the hardware is mapped into the process
virtual address space, it's not necessarily all accessible.
It is possible to get a bus fault against part of the mapping.
And the kernel doesn't expect to get bus faults on the source
of copy_to_user, I think.
I'm sure Andrea will have a better notion than I. Sometimes I
just fling out random patches to get people thinking about
things ;)
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/