Deferred I/O was utterly broken. Reading the mmap()ed framebuffer
worked, but writing it made the VM endlessly invoke
vm_ops.page_mkwrite(). That happened because we failed to set
page->mapping and page->index.
The fix is to set them, and clean up properly before the framebuffer
gets released.
Fix extracted from this linux-fbdev-devel message:
Subject: [PATCH 1/1 2.6.24] fbdev: defio and Metronomefb
From: Jaya Kumar <[email protected]>
Date: 2008-02-18 13:41:26
Signed-off-by: Jaya Kumar <[email protected]>
Signed-off-by: Markus Armbruster <[email protected]>
---
drivers/video/fb_defio.c | 22 ++++++++++++++++++++--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fb_defio.c b/drivers/video/fb_defio.c
index 0f8cfb9..24843fd 100644
--- a/drivers/video/fb_defio.c
+++ b/drivers/video/fb_defio.c
@@ -4,7 +4,7 @@
* Copyright (C) 2006 Jaya Kumar
*
* This file is subject to the terms and conditions of the GNU General Public
- * License. See the file COPYING in the main directory of this archive
+ * License. See the file COPYING in the main directory of this archive
* for more details.
*/
@@ -31,7 +31,7 @@ static int fb_deferred_io_fault(struct vm_area_struct *vma,
unsigned long offset;
struct page *page;
struct fb_info *info = vma->vm_private_data;
- /* info->screen_base is in System RAM */
+ /* info->screen_base is virtual memory */
void *screen_base = (void __force *) info->screen_base;
offset = vmf->pgoff << PAGE_SHIFT;
@@ -43,6 +43,15 @@ static int fb_deferred_io_fault(struct vm_area_struct *vma,
return VM_FAULT_SIGBUS;
get_page(page);
+
+ if (vma->vm_file)
+ page->mapping = vma->vm_file->f_mapping;
+ else
+ printk(KERN_ERR "no mapping available\n");
+
+ BUG_ON(!page->mapping);
+ page->index = vmf->pgoff;
+
vmf->page = page;
return 0;
}
@@ -138,11 +147,20 @@ EXPORT_SYMBOL_GPL(fb_deferred_io_init);
void fb_deferred_io_cleanup(struct fb_info *info)
{
+ void *screen_base = (void __force *) info->screen_base;
struct fb_deferred_io *fbdefio = info->fbdefio;
+ struct page *page;
+ int i;
BUG_ON(!fbdefio);
cancel_delayed_work(&info->deferred_work);
flush_scheduled_work();
+
+ /* clear out the mapping that we setup */
+ for (i = 0 ; i < info->fix.smem_len; i += PAGE_SIZE) {
+ page = vmalloc_to_page(screen_base + i);
+ page->mapping = NULL;
+ }
}
EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
On Mon, Feb 25, 2008 at 8:03 AM, Markus Armbruster <[email protected]> wrote:
>
> Subject: [PATCH 1/1 2.6.24] fbdev: defio and Metronomefb
> From: Jaya Kumar <[email protected]>
> Date: 2008-02-18 13:41:26
Hi Markus,
Andrew pointed out that there may be race conditions associated with
this patch. [ http://marc.info/?l=linux-fbdev-devel&m=120376473020396&w=2
] So I would not encourage anyone to merge it. I'll try to figure
things out this weekend.
Thanks,
jaya
"Jaya Kumar" <[email protected]> writes:
> On Mon, Feb 25, 2008 at 8:03 AM, Markus Armbruster <[email protected]> wrote:
>>
>> Subject: [PATCH 1/1 2.6.24] fbdev: defio and Metronomefb
>> From: Jaya Kumar <[email protected]>
>> Date: 2008-02-18 13:41:26
>
> Hi Markus,
>
> Andrew pointed out that there may be race conditions associated with
> this patch. [ http://marc.info/?l=linux-fbdev-devel&m=120376473020396&w=2
> ] So I would not encourage anyone to merge it. I'll try to figure
> things out this weekend.
>
> Thanks,
> jaya
Thanks for the timely info. I'm not in an undue hurry to get this
merged. As long as we're moving forward, I'm happy.
What about pushing the fb_defio fixes independently of any new
fb_defio users? If fb_defio was worth merging into Linus's tree, it
should be worth fixing there, whether new users are in shape already
or not.
If we must have a new user, well, I could easily whip up something
like FB_VIRTUAL on top of fb_defio.
On Tue, Feb 26, 2008 at 9:45 AM, Markus Armbruster <[email protected]> wrote:
>
> What about pushing the fb_defio fixes independently of any new
> fb_defio users? If fb_defio was worth merging into Linus's tree, it
> should be worth fixing there, whether new users are in shape already
> or not.
I think that Andrew's message is saying that there may be a race
condition in the defio patch itself as opposed to the defio user
patch.
If there is no race condition or other problems, then I think it would
make sense to merge the defio patch independent of metronomefb or
other new patches that use defio.
Thanks,
jaya
On Wed, 19 Mar 2008 19:24:25 +0800 "Jaya Kumar" <[email protected]> wrote:
> On Wed, Mar 19, 2008 at 6:45 PM, Markus Armbruster <[email protected]> wrote:
> >
> > Any progress on this?
> >
> > Considering that fb_defio is utterly broken without the fix (writing
> > the frame buffer makes the VM endlessly invoke vm_ops.page_mkwrite()),
> > wouldn't it make sense to merge the fix even if it still has issues?
> >
>
> Yes, Andrew has merged the fix into -mm. I see it in mmotm
>
> http://userweb.kernel.org/~akpm/mmotm/broken-out/fbdev-defio-and-metronomefb-v4.patch
>
Do we need some of all of that patch in 2.6.25? I wasn't aware of such a
need.
If the drivers/video/fb_defio.c hunk of that patch fixes something then I'd
be inclined to merge the whole thing - adding a new driver won't hurt
anyone.
"Jaya Kumar" <[email protected]> writes:
> On Tue, Feb 26, 2008 at 9:45 AM, Markus Armbruster <[email protected]> wrote:
>>
>> What about pushing the fb_defio fixes independently of any new
>> fb_defio users? If fb_defio was worth merging into Linus's tree, it
>> should be worth fixing there, whether new users are in shape already
>> or not.
>
> I think that Andrew's message is saying that there may be a race
> condition in the defio patch itself as opposed to the defio user
> patch.
>
> If there is no race condition or other problems, then I think it would
> make sense to merge the defio patch independent of metronomefb or
> other new patches that use defio.
>
> Thanks,
> jaya
Any progress on this?
Considering that fb_defio is utterly broken without the fix (writing
the frame buffer makes the VM endlessly invoke vm_ops.page_mkwrite()),
wouldn't it make sense to merge the fix even if it still has issues?
On Wed, Mar 19, 2008 at 6:45 PM, Markus Armbruster <[email protected]> wrote:
>
> Any progress on this?
>
> Considering that fb_defio is utterly broken without the fix (writing
> the frame buffer makes the VM endlessly invoke vm_ops.page_mkwrite()),
> wouldn't it make sense to merge the fix even if it still has issues?
>
Yes, Andrew has merged the fix into -mm. I see it in mmotm
http://userweb.kernel.org/~akpm/mmotm/broken-out/fbdev-defio-and-metronomefb-v4.patch
Thanks,
jaya
On Thu, Mar 20, 2008 at 2:37 AM, Andrew Morton
<[email protected]> wrote:
>
> Do we need some of all of that patch in 2.6.25? I wasn't aware of such a
> need.
>
> If the drivers/video/fb_defio.c hunk of that patch fixes something then I'd
> be inclined to merge the whole thing - adding a new driver won't hurt
> anyone.
>
Yes, the defio hunk is a bugfix. I agree with pushing the whole thing
to 2.6.25 if there are people who need it in 2.6.25. I believe there
is no risk of impact on anyone else.
Thanks,
jaya
On Thu, 20 Mar 2008 06:30:37 +0800
"Jaya Kumar" <[email protected]> wrote:
> On Thu, Mar 20, 2008 at 2:37 AM, Andrew Morton
> <[email protected]> wrote:
> >
> > Do we need some of all of that patch in 2.6.25? I wasn't aware of such a
> > need.
> >
> > If the drivers/video/fb_defio.c hunk of that patch fixes something then I'd
> > be inclined to merge the whole thing - adding a new driver won't hurt
> > anyone.
> >
>
> Yes, the defio hunk is a bugfix. I agree with pushing the whole thing
> to 2.6.25 if there are people who need it in 2.6.25. I believe there
> is no risk of impact on anyone else.
>
Well all we have in the changelog is
Implement support for the E-Ink Metronome controller. It provides an
mmapable interface to the controller using defio support. It was tested
with a gumstix pxa255 with Vizplex media using Xfbdev and various X
clients such as xeyes, xpdf, xloadimage.
grump. This say nothing at all about the change to drivers/video/fb_defio.c.
a) the changelog _should_ document this change. Please send a paragraph and
I'll add it.
b) If this discussion hadn't happened, that bug (whatever it is) would
have remained unfixed in 2.6.25. As a direct consequence of poor
changelogging.
c) This bugfix (whatever it is) should have been in a separate patch.
Thanks.
On Thu, Mar 20, 2008 at 6:39 AM, Andrew Morton
<[email protected]> wrote:
>
> Well all we have in the changelog is
>
> Implement support for the E-Ink Metronome controller. It provides an
> mmapable interface to the controller using defio support. It was tested
> with a gumstix pxa255 with Vizplex media using Xfbdev and various X
> clients such as xeyes, xpdf, xloadimage.
>
> grump. This say nothing at all about the change to drivers/video/fb_defio.c.
I apologize. I should have done better.
>
> a) the changelog _should_ document this change. Please send a paragraph and
> I'll add it.
This patch fixes the following bug. Defio would cause a hang on write
access to the framebuffer as the page fault would be called
ad-infinitum. It fixes fb_defio by setting the mapping to be used by
page_mkclean.
>
> b) If this discussion hadn't happened, that bug (whatever it is) would
> have remained unfixed in 2.6.25. As a direct consequence of poor
> changelogging.
Understood. The root cause of my flaw was my assumption that other
than me, there weren't any users of defio so I was in no hurry to get
it fixed.
>
> c) This bugfix (whatever it is) should have been in a separate patch.
Understood. It won't happen again.
Thanks,
jaya