Messages in this thread | | | From | Nick Piggin <> | Subject | Re: kernel BUG at lib/radix-tree.c:473! | Date | Mon, 18 Aug 2008 11:32:43 +1000 |
| |
On Monday 18 August 2008 02:19, Ian Campbell wrote: > On Fri, 2008-08-15 at 01:00 +0100, Hugh Dickins wrote: > > On Fri, 15 Aug 2008, Johannes Weiner wrote: > > > Jeremy Fitzhardinge <jeremy@goop.org> writes: > > > > Hugh Dickins wrote: > > > >> 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. > > > > > > > > I don't follow. Do you mean make /dev/fb0 a plain file on a > > > > filesystem? Or make it a disk device node? Something else? > > > > > > Creating a device node on a different filesystem to see if the driver > > > only worked with the safe shmem set_page_dirty and now breaks due to > > > exposure to the generic version. Or if the driver works with the > > > generic version through other mappings and the shmem code screws it up > > > somewhere else. > > > > Yes, that's it. I think it was ext2 I referred to, when I worried > > about this when making the change to tmpfs; and my reading of it > > was that ext2 left a device node's a_ops unset, as I was changing > > tmpfs to do. (Looking at it again, ext2 doesn't even specify its > > .set_page_dirty, so even if it had assigned an a_ops, it wouldn't > > have avoided the default behaviour.) But I'd like to hear what > > actually happens in practice, rather than relying on my reading. > > Creating /tmp/fb0 on an ext3 filesystem gives the same behaviour. > > FWIW the patch below apparently makes it work for me, but I'm not going > to pretend I follow what's going on, why or what else it breaks ;-)
I think Iwould prefer fs_defio to use its own set_page_dirty function. __set_page_dirty_no_writeback is supposed to be used on pagecache, by filesystems.
| |