On Mon, 30 Jan 2023 09:28:36 +0100,
Thomas Zimmermann wrote:
Hi
Am 29.01.23 um 09:28 schrieb Takashi Iwai:
When a fbdev with deferred I/O is once opened and closed, the dirty
pages still remain queued in the pageref list, and eventually later
those may be processed in the delayed work. This may lead to a
corruption of pages, hitting an Oops.
Do you have more information on this problem?
The details are in SUSE bugzilla, but that's an internal bug entry
(and you know the number :) It happens at the following at least:
- A VM is started with VGA console, no fb, on the installer
- VM is switched to bochs drm
- Start fbiterm on VT1, switching to the graphics mode on VT
- Exit fbiterm, going back to the text mode on VT;
at this moment, it gets Oops like:
[ 42.338319][ T122] BUG: unable to handle page fault for address:
ffffe570c1000030
[ 42.340063][ T122] #PF: supervisor read access in kernel mode
[ 42.340519][ T122] #PF: error_code(0x0000) - not-present page
[ 42.340979][ T122] PGD 34c38067 P4D 34c38067 PUD 34c37067 PMD 0
[ 42.341456][ T122] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 42.341853][ T122] CPU: 1 PID: 122 Comm: kworker/1:2 Not tainted
5.14.21-150500.5.g2ad24ee-default #1 SLE15-SP5 (unreleased)
b7a28d028376a517e888a7ff28c5e5dede93267c
[ 42.343000][ T122] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014
[ 42.343929][ T122] Workqueue: events fb_deferred_io_work
[ 42.344355][ T122] RIP: 0010:page_mapped+0x5e/0x90
[ 42.344743][ T122] Code: a8 01 75 d7 8b 47 30 f7 d0 c1 e8 1f c3 cc cc cc cc
48 89 df e8 33 9c 05 00 89 c1 31 c0 85 c9 74 13 eb d3 48 c1 e2 06 48 01 da <8b>
42 30 85 c0 79 c0 83 c1 01 48 8b 33 48 63 d1 b8 01 00 00 00 f7
[ 42.346285][ T122] RSP: 0018:ffffb68640207e08 EFLAGS: 00010286
[ 42.346749][ T122] RAX: 00000000b3aea8f0 RBX: ffffe570c0f00000 RCX:
0000000000004000
[ 42.347355][ T122] RDX: ffffe570c1000000 RSI: 000fffffc0010009 RDI:
ffffe570c0f00000
[ 42.347960][ T122] RBP: ffffffffc0503050 R08: 0000000000000000 R09:
0000000000000001
[ 42.348568][ T122] R10: 0000000000000000 R11: ffffb68640207c88 R12:
ffffffffc0503020
[ 42.349180][ T122] R13: ffff921281dcdc00 R14: ffff9212bcf08000 R15:
ffffe570c0f00000
[ 42.349789][ T122] FS: 0000000000000000(0000) GS:ffff9212b3b00000(0000)
knlGS:0000000000000000
[ 42.350471][ T122] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 42.350975][ T122] CR2: ffffe570c1000030 CR3: 000000001b810000 CR4:
00000000000006e0
[ 42.351588][ T122] Call Trace:
[ 42.351845][ T122] <TASK>
[ 42.352069][ T122] page_mkclean+0x6e/0xc0
[ 42.352400][ T122] ? page_referenced_one+0x190/0x190
[ 42.353714][ T122] ? pmdp_collapse_flush+0x60/0x60
[ 42.354106][ T122] fb_deferred_io_work+0x13d/0x190
[ 42.354496][ T122] process_one_work+0x267/0x440
[ 42.354866][ T122] ? process_one_work+0x440/0x440
[ 42.355247][ T122] worker_thread+0x2d/0x3d0
[ 42.355590][ T122] ? process_one_work+0x440/0x440
[ 42.355972][ T122] kthread+0x156/0x180
[ 42.356281][ T122] ? set_kthread_struct+0x50/0x50
[ 42.356662][ T122] ret_from_fork+0x22/0x30
[ 42.357006][ T122] </TASK>
The page info shows that it's a compound page but it's somehow
broken. On VM, it's triggered reliably with the scenario above,
always at the same position.
FWIW, the Oops is hit even if there is no rewrite on the screen.
That is, another procedure is:
- Start VM, run fbiterm on VT1
- Switch to VT2, text mode
- On VT2, kill fbiterm; the crash still happens even if no screen
change is performed
The mmap'ed buffer of the fbdev device comes from a vmalloc call. That
memory's location never changes; even across pairs of open/close on
the device file. I'm surprised that a page entry becomes invalid.
In drm_fbdev_cleanup(), we first remove the fbdefio at [1] and then
vfree() the shadow buffer. So the memory should still be around until
fbdevio is gone.
Yes, that's the puzzling part, too. Also, another thing is that the
bug couldn't be triggered easily when the fb is started in a different
way. e.g. when you run fbiterm & exit on the VM that had efifb, it
didn't hit.
So, overall, it might be that I'm scratching a wrong surface. But at
least it "fixes" the problem above apparently, and the deferred io
base code itself has certainly the potential problem in general as my
patch suggests.
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_fb_helper.c#L2146
This patch makes sure to cancel the delayed work and clean up the
pageref list at closing the device for addressing the bug. A part of
the cleanup code is factored out as a new helper function that is
called from the common fb_release().
The delayed work is required to copy the framebuffer to the device
output. So if it's just canceled, could this result in missing
updates?
There's a call to cancel_delayed_work_sync() in the new helper
fb_deferred_io_release(). Is this the right function? Maybe
flush_delayed_work() is a better choice.
I thought of that, but took a shorter path.
OK, let's check whether this keeps working with that change.
Reviewed-by: Patrik Jakobsson <patrik.r.jakobsson@xxxxxxxxx>
Cc: <stable@xxxxxxxxxxxxxxx>
Signed-off-by: Takashi Iwai <tiwai@xxxxxxx>
This could use a Fixes tag. It's not exactly clear to me when this
problem got originally introduced, but the recent refactoring seems a
candidate.
Fixes: 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref struct")
Hrm, this might be. Maybe Patrik can test with the revert of this?
Cc: Thomas Zimmermann <tzimmermann@xxxxxxx>
Cc: Javier Martinez Canillas <javierm@xxxxxxxxxx>
Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
Cc: Maxime Ripard <mripard@xxxxxxxxxx>
Cc: Zack Rusin <zackr@xxxxxxxxxx>
Cc: VMware Graphics Reviewers <linux-graphics-maintainer@xxxxxxxxxx>
Cc: Jaya Kumar <jayalk@xxxxxxxxxxxx>
Cc: Daniel Vetter <daniel@xxxxxxxx>
Cc: "K. Y. Srinivasan" <kys@xxxxxxxxxxxxx>
Cc: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>
Cc: Wei Liu <wei.liu@xxxxxxxxxx>
Cc: Dexuan Cui <decui@xxxxxxxxxxxxx>
Cc: Steve Glendinning <steve.glendinning@xxxxxxxxxxx>
Cc: Bernie Thompson <bernie@xxxxxxxxxxxx>
Cc: Helge Deller <deller@xxxxxx>
Cc: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Cc: Stephen Kitt <steve@xxxxxxx>
Cc: Peter Suti <peter.suti@xxxxxxxxxxxxxxxxxxx>
Cc: Sam Ravnborg <sam@xxxxxxxxxxxx>
Cc: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
Cc: ye xingchen <ye.xingchen@xxxxxxxxxx>
Cc: Petr Mladek <pmladek@xxxxxxxx>
Cc: John Ogness <john.ogness@xxxxxxxxxxxxx>
Cc: Tom Rix <trix@xxxxxxxxxx>
Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx
Cc: linux-fbdev@xxxxxxxxxxxxxxx
Cc: linux-hyperv@xxxxxxxxxxxxxxx
Cc: <stable@xxxxxxxxxxxxxxx> # v5.19+
Nah, please don't. Too many Cc's, literally a spam.
---
v1->v2: Fix build error without CONFIG_FB_DEFERRED_IO
drivers/video/fbdev/core/fb_defio.c | 10 +++++++++-
drivers/video/fbdev/core/fbmem.c | 4 ++++
include/linux/fb.h | 1 +
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fb_defio.c b/drivers/video/fbdev/core/fb_defio.c
index c730253ab85c..583cbcf09446 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -313,7 +313,7 @@ void fb_deferred_io_open(struct fb_info *info,
}
EXPORT_SYMBOL_GPL(fb_deferred_io_open);
-void fb_deferred_io_cleanup(struct fb_info *info)
+void fb_deferred_io_release(struct fb_info *info)
{
struct fb_deferred_io *fbdefio = info->fbdefio;
struct page *page;
@@ -327,6 +327,14 @@ void fb_deferred_io_cleanup(struct fb_info *info)
page = fb_deferred_io_page(info, i);
page->mapping = NULL;
}
+}
+EXPORT_SYMBOL_GPL(fb_deferred_io_release);
It's all in the same module. No need to export this symbol.
I noticed it, too, but just keep the same style as other functions :)
That said, the other exported symbols are also useless. I can prepare
another patch to clean it up.
thanks,
Takashi
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature