2017-09-15 10:02:18

by Xiaoming Ni

Subject: [PATCH] tty fix oops when rmmod 8250

After rmmod 8250.ko
tty_kref_put starts kwork (release_one_tty) to release proc interface
oops when accessing driver->driver_name in proc_tty_unregister_driver

Use jprobe, found driver->driver_name point to 8250.ko
static static struct uart_driver serial8250_reg
.driver_name= serial,

Use name in proc_dir_entry instead of driver->driver_name to fix oops

test on linux 4.1.12:

BUG: unable to handle kernel paging request at ffffffffa01979de
IP: [<ffffffff81310f40>] strchr+0x0/0x30
PGD 1a0d067 PUD 1a0e063 PMD 851c1f067 PTE 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: ... ... [last unloaded: 8250]
CPU: 7 PID: 116 Comm: kworker/7:1 Tainted: G O 4.1.12 #1
Hardware name: Insyde RiverForest/Type2 - Board Product Name1, BIOS NE5KV904 12/21/2015
Workqueue: events release_one_tty
task: ffff88085b684960 ti: ffff880852884000 task.ti: ffff880852884000
RIP: 0010:[<ffffffff81310f40>] [<ffffffff81310f40>] strchr+0x0/0x30
RSP: 0018:ffff880852887c90 EFLAGS: 00010282
RAX: ffffffff81a5eca0 RBX: ffffffffa01979de RCX: 0000000000000004
RDX: ffff880852887d10 RSI: 000000000000002f RDI: ffffffffa01979de
RBP: ffff880852887cd8 R08: 0000000000000000 R09: ffff88085f5d94d0
R10: 0000000000000195 R11: 0000000000000000 R12: ffffffffa01979de
R13: ffff880852887d00 R14: ffffffffa01979de R15: ffff88085f02e840
FS: 0000000000000000(0000) GS:ffff88085f5c0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffa01979de CR3: 0000000001a0c000 CR4: 00000000001406e0
Stack:
ffffffff812349b1 ffff880852887cb8 ffff880852887d10 ffff88085f5cd6c2
ffff880852800a80 ffffffffa01979de ffff880852800a84 0000000000000010
ffff88085bb28bd8 ffff880852887d38 ffffffff812354f0 ffff880852887d08
Call Trace:
[<ffffffff812349b1>] ? __xlate_proc_name+0x71/0xd0
[<ffffffff812354f0>] remove_proc_entry+0x40/0x180
[<ffffffff815f6811>] ? _raw_spin_lock_irqsave+0x41/0x60
[<ffffffff813be520>] ? destruct_tty_driver+0x60/0xe0
[<ffffffff81237c68>] proc_tty_unregister_driver+0x28/0x40
[<ffffffff813be548>] destruct_tty_driver+0x88/0xe0
[<ffffffff813be5bd>] tty_driver_kref_put+0x1d/0x20
[<ffffffff813becca>] release_one_tty+0x5a/0xd0
[<ffffffff81074159>] process_one_work+0x139/0x420
[<ffffffff810745a1>] worker_thread+0x121/0x450
[<ffffffff81074480>] ? process_scheduled_works+0x40/0x40
[<ffffffff8107a16c>] kthread+0xec/0x110
[<ffffffff81080000>] ? tg_rt_schedulable+0x210/0x220
[<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80
[<ffffffff815f7292>] ret_from_fork+0x42/0x70
[<ffffffff8107a080>] ? kthread_freezable_should_stop+0x80/0x80

Signed-off-by: nixiaoming <[email protected]>
---
fs/proc/proc_tty.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/proc/proc_tty.c b/fs/proc/proc_tty.c
index 901bd06..20e2c18 100644
--- a/fs/proc/proc_tty.c
+++ b/fs/proc/proc_tty.c
@@ -14,6 +14,7 @@
#include <linux/tty.h>
#include <linux/seq_file.h>
#include <linux/bitops.h>
+#include "internal.h"

/*
* The /proc/tty directory inodes...
@@ -164,7 +165,7 @@ void proc_tty_unregister_driver(struct tty_driver *driver)
if (!ent)
return;

- remove_proc_entry(driver->driver_name, proc_tty_driver);
+ remove_proc_entry(ent->name, proc_tty_driver);

driver->proc_entry = NULL;
}
--
2.11.0.1

2017-09-18 10:50:30

by Jiri Slaby

Subject: Re: [PATCH] tty fix oops when rmmod 8250

On 09/15/2017, 11:45 AM, nixiaoming wrote:
> After rmmod 8250.ko
> tty_kref_put starts kwork (release_one_tty) to release proc interface

I believe you wanted to add a period here.

> oops when accessing driver->driver_name in proc_tty_unregister_driver

"The kernel oopses when"... ?

> Use jprobe, found driver->driver_name point to 8250.ko
> static static struct uart_driver serial8250_reg
> .driver_name= serial,
>
> Use name in proc_dir_entry instead of driver->driver_name to fix oops
>
> test on linux 4.1.12:
...
> @@ -164,7 +165,7 @@ void proc_tty_unregister_driver(struct tty_driver *driver)
> if (!ent)
> return;
>
> - remove_proc_entry(driver->driver_name, proc_tty_driver);
> + remove_proc_entry(ent->name, proc_tty_driver);

Yes, that makes sense. Using possibly stale driver_name cannot really
work out. I only wonder why nobody noticed until now...

So, can you reproduce also on 4.13 or something newer like that?

thanks,
--
js
suse labs