* [PATCH] writeback: verify that underlying dev exists before getting its name
@ 2015-09-04 16:45 Sasha Levin
2015-09-04 16:47 ` Tejun Heo
0 siblings, 1 reply; 5+ messages in thread
From: Sasha Levin @ 2015-09-04 16:45 UTC (permalink / raw)
To: rostedt, mingo; +Cc: axboe, tj, linux-kernel, Sasha Levin
We can't assume there is always an underlying device and must verify that
as well. Otherwise, we'd deref a NULL ptr here.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
---
include/trace/events/writeback.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/trace/events/writeback.h b/include/trace/events/writeback.h
index fff846b..8f9efaa 100644
--- a/include/trace/events/writeback.h
+++ b/include/trace/events/writeback.h
@@ -66,7 +66,9 @@ TRACE_EVENT(writeback_dirty_page,
TP_fast_assign(
strncpy(__entry->name,
- mapping ? dev_name(inode_to_bdi(mapping->host)->dev) : "(unknown)", 32);
+ mapping && inode_to_bdi(mapping->host)->dev ?
+ dev_name(inode_to_bdi(mapping->host)->dev) :
+ "(unknown)", 32);
__entry->ino = mapping ? mapping->host->i_ino : 0;
__entry->index = page->index;
),
--
1.7.10.4
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] writeback: verify that underlying dev exists before getting its name
2015-09-04 16:45 [PATCH] writeback: verify that underlying dev exists before getting its name Sasha Levin
@ 2015-09-04 16:47 ` Tejun Heo
2015-09-04 17:20 ` Sasha Levin
0 siblings, 1 reply; 5+ messages in thread
From: Tejun Heo @ 2015-09-04 16:47 UTC (permalink / raw)
To: Sasha Levin; +Cc: rostedt, mingo, axboe, linux-kernel
On Fri, Sep 04, 2015 at 12:45:18PM -0400, Sasha Levin wrote:
> We can't assume there is always an underlying device and must verify that
> as well. Otherwise, we'd deref a NULL ptr here.
Do you have backtrace of this happening? There's a bug in cleanup
path which causes oops (patch is being tested) and this may just be a
symptom of the same problem.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] writeback: verify that underlying dev exists before getting its name
2015-09-04 16:47 ` Tejun Heo
@ 2015-09-04 17:20 ` Sasha Levin
2015-09-04 17:36 ` Tejun Heo
0 siblings, 1 reply; 5+ messages in thread
From: Sasha Levin @ 2015-09-04 17:20 UTC (permalink / raw)
To: Tejun Heo; +Cc: rostedt, mingo, axboe, linux-kernel
On 09/04/2015 12:47 PM, Tejun Heo wrote:
> On Fri, Sep 04, 2015 at 12:45:18PM -0400, Sasha Levin wrote:
>> We can't assume there is always an underlying device and must verify that
>> as well. Otherwise, we'd deref a NULL ptr here.
>
> Do you have backtrace of this happening? There's a bug in cleanup
> path which causes oops (patch is being tested) and this may just be a
> symptom of the same problem.
>
> Thanks.
>
[268773.335933] kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
[268773.337986] Modules linked in:
[268773.338470] CPU: 3 PID: 12812 Comm: trinity-c10 Not tainted 4.2.0-next-20150902-sasha-00045-gd0866f3-dirty #2528
[268773.339903] task: ffff8802f56e4000 ti: ffff880322e10000 task.ti: ffff880322e10000
[268773.340943] RIP: 0010:[<ffffffffaa8b8284>] [<ffffffffaa8b8284>] trace_event_raw_event_writeback_dirty_page+0x1b4/0x420
[268773.342558] RSP: 0018:ffff880322e17810 EFLAGS: 00010006
[268773.343316] RAX: 0000000000000000 RBX: 1ffff100645c2f04 RCX: 0000000000000027
[268773.344321] RDX: dffffc0000000000 RSI: 1ffffffff725af7f RDI: 0000000000000138
[268773.345332] RBP: ffff880322e178c8 R08: 000000000000006e R09: 0000000000000004
[268773.346339] R10: ffff8801e38c6008 R11: 1ffff1003c716a86 R12: ffff8801e38c6b3c
[268773.347504] R13: ffff8802bf107060 R14: ffffea0002cde080 R15: ffff880322e17840
[268773.348582] FS: 00007f4ebe605700(0000) GS:ffff8801e4000000(0000) knlGS:0000000000000000
[268773.349800] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[268773.350666] CR2: 0000000000000004 CR3: 00000002f5df4000 CR4: 00000000000006a0
[268773.351712] Stack:
[268773.352038] ffff8801e38c6afc ffff8802f56e4000 0000000041b58ab3 ffffffffb6c9fdd7
[268773.353217] ffffffffaa8b80d0 0000000000000005 ffff88006bc04800 ffff8801e38c6b38
[268773.354386] ffff88006be0e9a0 ffff8801e38c6b3c 0000000000000082 ffffffff00000004
[268773.355659] Call Trace:
[268773.356090] [<ffffffffaa8b80d0>] ? inode_congested+0x520/0x520
[268773.357088] [<ffffffffaa472cd4>] ? lock_is_held+0x194/0x1f0
[268773.357996] [<ffffffffaa6f0f43>] account_page_dirtied+0x443/0x740
[268773.358881] [<ffffffffaa6f1330>] __set_page_dirty_nobuffers+0xf0/0x2f0
[268773.359893] [<ffffffffaa7e299d>] migrate_page_copy+0xccd/0x1980
[268773.360900] [<ffffffffaa474880>] ? lock_acquired+0x680/0xbe0
[268773.361793] [<ffffffffaa92060c>] ? aio_migratepage+0x22c/0x370
[268773.362697] [<ffffffffaa92061b>] aio_migratepage+0x23b/0x370
[268773.363589] [<ffffffffaa7e3c7c>] move_to_new_page+0x1fc/0x490
[268773.364487] [<ffffffffaa7e3a80>] ? fallback_migrate_page+0x3b0/0x3b0
[268773.365474] [<ffffffffaa77fc20>] ? page_remove_rmap+0x450/0x450
[268773.366380] [<ffffffffaa77c2f0>] ? invalid_migration_vma+0x60/0x60
[268773.367353] [<ffffffffaa782530>] ? page_get_anon_vma+0x2c0/0x2c0
[268773.368260] [<ffffffffaa7df4a3>] ? new_page_node+0x263/0x3b0
[268773.369124] [<ffffffffaa3de54e>] ? ___might_sleep+0x34e/0x470
[268773.370025] [<ffffffffaa7e5453>] migrate_pages+0x1263/0x1ee0
[268773.370916] [<ffffffffaa46814b>] ? get_lock_stats+0x1b/0x80
[268773.371770] [<ffffffffaa7df240>] ? alloc_misplaced_dst_page+0x80/0x80
[268773.372756] [<ffffffffaa7e41f0>] ? buffer_migrate_page+0x2e0/0x2e0
[268773.373708] [<ffffffffaa82def2>] ? follow_page_pte+0x95f/0xa15
[268773.374621] [<ffffffffaa74d6a6>] ? follow_page_mask+0x4e6/0xa90
[268773.375570] [<ffffffffaa7e6b6e>] SYSC_move_pages+0xa9e/0x1070
[268773.376446] [<ffffffffaa7e61c3>] ? SYSC_move_pages+0xf3/0x1070
[268773.377388] [<ffffffffaa7e60d0>] ? migrate_pages+0x1ee0/0x1ee0
[268773.378333] [<ffffffffaa5e91a7>] ? ring_buffer_unlock_commit+0x2f7/0x450
[268773.379361] [<ffffffffaa605be3>] ? trace_buffer_unlock_commit+0x63/0x70
[268773.380403] [<ffffffffaa0057c0>] ? do_audit_syscall_entry+0x310/0x310
[268773.381412] [<ffffffffaa0078eb>] ? syscall_trace_enter_phase2+0x2db/0x690
[268773.382479] [<ffffffffaa7e714e>] SyS_move_pages+0xe/0x10
[268773.383356] [<ffffffffb43a8df8>] tracesys_phase2+0x88/0x8d
[268773.384186] Code: e9 03 80 3c 11 00 0f 85 b5 01 00 00 48 8b 80 b0 06 00 00 48 ba 00 00 00 00 00 fc ff df 48 8d b8 38 01 00 00 48 89 f9 48 c1 e9 03 <80> 3c 11 00 0f 85 74 01 00 00 48 8b b0 38 01 00 00 48 85 f6 0f
[268773.388757] RIP [<ffffffffaa8b8284>] trace_event_raw_event_writeback_dirty_page+0x1b4/0x420
[268773.389999] RSP <ffff880322e17810>
Thanks,
Sasha
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] writeback: verify that underlying dev exists before getting its name
2015-09-04 17:20 ` Sasha Levin
@ 2015-09-04 17:36 ` Tejun Heo
2015-09-09 18:32 ` Sasha Levin
0 siblings, 1 reply; 5+ messages in thread
From: Tejun Heo @ 2015-09-04 17:36 UTC (permalink / raw)
To: Sasha Levin; +Cc: rostedt, mingo, axboe, linux-kernel
Hello,
On Fri, Sep 04, 2015 at 01:20:42PM -0400, Sasha Levin wrote:
> > Do you have backtrace of this happening? There's a bug in cleanup
> > path which causes oops (patch is being tested) and this may just be a
> > symptom of the same problem.
>
> [268773.335933] kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
> [268773.337986] Modules linked in:
> [268773.338470] CPU: 3 PID: 12812 Comm: trinity-c10 Not tainted 4.2.0-next-20150902-sasha-00045-gd0866f3-dirty #2528
> [268773.339903] task: ffff8802f56e4000 ti: ffff880322e10000 task.ti: ffff880322e10000
> [268773.340943] RIP: 0010:[<ffffffffaa8b8284>] [<ffffffffaa8b8284>] trace_event_raw_event_writeback_dirty_page+0x1b4/0x420
Hmm.... did this happen while or around a device removal event? I'm
trying to figure out whether an unregistered bdi can have inodes.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] writeback: verify that underlying dev exists before getting its name
2015-09-04 17:36 ` Tejun Heo
@ 2015-09-09 18:32 ` Sasha Levin
0 siblings, 0 replies; 5+ messages in thread
From: Sasha Levin @ 2015-09-09 18:32 UTC (permalink / raw)
To: Tejun Heo; +Cc: rostedt, mingo, axboe, linux-kernel
On 09/04/2015 01:36 PM, Tejun Heo wrote:
> Hello,
>
> On Fri, Sep 04, 2015 at 01:20:42PM -0400, Sasha Levin wrote:
>>> Do you have backtrace of this happening? There's a bug in cleanup
>>> path which causes oops (patch is being tested) and this may just be a
>>> symptom of the same problem.
>>
>> [268773.335933] kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
>> [268773.337986] Modules linked in:
>> [268773.338470] CPU: 3 PID: 12812 Comm: trinity-c10 Not tainted 4.2.0-next-20150902-sasha-00045-gd0866f3-dirty #2528
>> [268773.339903] task: ffff8802f56e4000 ti: ffff880322e10000 task.ti: ffff880322e10000
>> [268773.340943] RIP: 0010:[<ffffffffaa8b8284>] [<ffffffffaa8b8284>] trace_event_raw_event_writeback_dirty_page+0x1b4/0x420
>
> Hmm.... did this happen while or around a device removal event? I'm
> trying to figure out whether an unregistered bdi can have inodes.
I ran some more tests, and I didn't see device removal events close to it.
Thanks,
Sasha
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-09-09 18:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-04 16:45 [PATCH] writeback: verify that underlying dev exists before getting its name Sasha Levin
2015-09-04 16:47 ` Tejun Heo
2015-09-04 17:20 ` Sasha Levin
2015-09-04 17:36 ` Tejun Heo
2015-09-09 18:32 ` Sasha Levin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).