All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ijc@hellion.org.uk>
To: Hugh Dickins <hugh@veritas.com>
Cc: Johannes Weiner <hannes@saeurebad.de>,
	Jeremy Fitzhardinge <jeremy@goop.org>,
	linux-kernel@vger.kernel.org, Kel Modderman <kel@otaku42.de>,
	Markus Armbruster <armbru@redhat.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Jaya Kumar <jayakumar.lkml@gmail.com>
Subject: Re: kernel BUG at lib/radix-tree.c:473!
Date: Sun, 17 Aug 2008 17:19:32 +0100	[thread overview]
Message-ID: <1218989974.3996.4.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0808150049110.17216@blonde.site>

[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]

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 ;-)

Ian.

diff --git a/drivers/video/fb_defio.c b/drivers/video/fb_defio.c
index 59df132..8414646 100644
--- a/drivers/video/fb_defio.c
+++ b/drivers/video/fb_defio.c
@@ -24,6 +24,10 @@
 #include <linux/rmap.h>
 #include <linux/pagemap.h>
 
+static const struct address_space_operations fb_defio_aops = {
+        .set_page_dirty = __set_page_dirty_no_writeback,
+};
+
 /* this is to find and return the vmalloc-ed fb pages */
 static int fb_deferred_io_fault(struct vm_area_struct *vma,
 				struct vm_fault *vmf)
@@ -119,6 +123,7 @@ static int fb_deferred_io_mmap(struct fb_info *info, struct vm_area_struct *vma)
 	vma->vm_ops = &fb_deferred_io_vm_ops;
 	vma->vm_flags |= ( VM_IO | VM_RESERVED | VM_DONTEXPAND );
 	vma->vm_private_data = info;
+	vma->vm_file->f_mapping->a_ops = &fb_defio_aops;
 	return 0;
 }
 

-- 
Ian Campbell

Wharbat darbid yarbou sarbay?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2008-08-17 16:19 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-14  7:02 kernel BUG at lib/radix-tree.c:473! Ian Campbell
2008-08-14 10:41 ` Peter Zijlstra
2008-08-14 13:06 ` Hugh Dickins
2008-08-14 14:56   ` Ian Campbell
2008-08-14 17:42     ` Hugh Dickins
2008-08-14 17:38   ` Jeremy Fitzhardinge
2008-08-14 19:33   ` Jeremy Fitzhardinge
2008-08-14 21:03     ` Hugh Dickins
2008-08-14 22:04       ` Jeremy Fitzhardinge
2008-08-14 22:48         ` Markus Armbruster
2008-08-17 12:09           ` Jaya Kumar
2008-08-17 14:00             ` zhang wenjie
2008-08-14 23:13         ` Johannes Weiner
2008-08-15  0:00           ` Hugh Dickins
2008-08-17 16:19             ` Ian Campbell [this message]
2008-08-18  1:32               ` Nick Piggin
2008-08-18  7:54                 ` Ian Campbell
2008-08-18  8:04                   ` Peter Zijlstra
2008-08-18  8:05                   ` Nick Piggin
2008-08-18  8:22                   ` Jaya Kumar
  -- strict thread matches above, loose matches on Subject: below --
2008-08-17  3:37 zhang wenjie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1218989974.3996.4.camel@localhost.localdomain \
    --to=ijc@hellion.org.uk \
    --cc=a.p.zijlstra@chello.nl \
    --cc=armbru@redhat.com \
    --cc=hannes@saeurebad.de \
    --cc=hugh@veritas.com \
    --cc=jayakumar.lkml@gmail.com \
    --cc=jeremy@goop.org \
    --cc=kel@otaku42.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.