Brilliant, thanks a lot, Jeremy. That fits, I'd been inching towards
forming the thought that it was likely to involve a block or char device
(rather than a directory, which is what had prompted the patch).
I'd thought about them when making the patch, but quickly decided that
a device node may live in a tmpfs (and usually does with udev), but
redirects off to somewhere else entirely.
If I open /dev/sda and mmap it, then I don't expect to see pages of
shmem, I expect to see pages from my disk. Though if I open /dev/zero
and mmap it, that character device does happen to be the one which
comes back and delivers pages of shmem.
Now if I open /dev/fb0 here and mmap it as you did, and try to write
to it through those pages, I see nothing bad happening: I don't know
for sure what pages it's making available to me, but I hope they're
pages belonging to that driver.
tmpfs doesn't associate its shmem_file_operations with a device node,
so there wouldn't be a way to mmap it, unless the device driver gives
the struct file its own file_operations, including an .mmap method.
It looks like your fb driver is providing a backing_dev_info which
tells vma_wants_writenotify that it wants mapping_cap_account_dirty:
hmm, I suppose the default one would do that, though shmem provided
one which says not. But not providing any address_space_operations
with a .set_page_dirty which would keep it out of trouble.
Before my patch, the device node happened to stay pointing to
shmem_aops, whose set_page_dirty was safe; now it's getting
default behaviour, and hitting these problems.
As you can see, I'm still groping towards the right answer.
The driver probably needs to provide its own backing_dev_info
(or point to a suitable default), and its own address_space_ops,
and perhaps more (there should be examples elsewhere). But whether
it is actually wrong, or whether I was wrong to mess it up, I've
not yet decided.
An additional useful input would be: what happens if you replace
that /dev/fb0 by a symlink /dev/fb0 pointing to an fb0 device node in
one of your disk filesystems? I rather expect that to cause the same
trouble, which would argue that the driver is wrong and shmem right.
Hugh
--
