On Tue, Jan 24, 2017 at 10:23:57AM +0000, Andre Przywara wrote: > Hi, > > so I gave this patch (adapted to live without the soft_pending state) > some testing on my machines (Midway, Juno, GICv3 ITS h/w) and it seemed > to work well - at least if one is nice and starts only one process > accessing vgic-state (see below). I caught some IRQs red-handed and the > output looked plausible. > The only comment I have is that "MPIDR" is a misleading header name for > that column. It's actually a union with the GICv2 targets field, which > is a bitmask of the targetting VCPUs. So the output looks more like a > bitmask and not an MPIDR on many machines. But that's just cosmetic. > > Just discovered one thing: As soon as a second task is reading the file > (with "while [ 1 ]; do cat vgic-state > /dev/null; done &" in the > background, for instance), I get this splat on the host: > > [60796.007461] Unable to handle kernel NULL pointer dereference at > virtual address 00000008 > [60796.015538] pgd = ffff800974e30000 > [60796.018952] [00000008] *pgd=00000009f4d0a003[60796.023067] Internal > error: Oops: 96000006 [#1] PREEMPT SMP > [60796.028588] Modules linked in: > [60796.031626] CPU: 3 PID: 5690 Comm: cat Tainted: G W > 4.9.0-00026-ge24503e-dirty #444 > [60796.040326] Hardware name: ARM Juno development board (r0) (DT) > [60796.046190] task: ffff80097231ab00 task.stack: ffff800973894000 > [60796.052059] PC is at iter_next+0x18/0x80 > [60796.055946] LR is at debug_next+0x38/0x90 > [60796.059917] pc : [<ffff0000080c4b38>] lr : [<ffff0000080c4bd8>] > pstate: 20000145 > [60796.067240] sp : ffff800973897cc0 > [60796.070522] x29: ffff800973897cc0 x28: ffff800973897d60 > [60796.075805] x27: 0000000033c61000 x26: ffff800974e4dd40 > [60796.081086] x25: 0000000000010000 x24: ffff800974da6380 > [60796.086360] x23: ffff800973897eb8 x22: 0000000000000000 > [60796.091634] x21: 0000000000000459 x20: ffff800973897d68 > [60796.096908] x19: 0000000000000000 x18: 0000000000000001 > [60796.102181] x17: 000000000041a1c8 x16: ffff000008275258 > [60796.107456] x15: ffff800975546457 x14: 0000ffffa3912a94 > [60796.112730] x13: 0000000000000000 x12: 0000000005f5e0ff > [60796.118004] x11: 0000000000000000 x10: 000000000000000c > [60796.123282] x9 : 000000000000000f x8 : ffff800973897b08 > [60796.128555] x7 : 0000000000000004 x6 : ffff800975546459 > [60796.133829] x5 : 0000000000000001 x4 : 0000000000000001 > [60796.139103] x3 : ffff0000080c4ba0 x2 : ffff800973897d68 > [60796.144377] x1 : ffff800972074000 x0 : ffff0000080c4bd8 > [60796.149650] > [60796.151128] Process cat (pid: 5690, stack limit = 0xffff800973894020) > [60796.157508] Stack: (0xffff800973897cc0 to 0xffff800973898000) > [60796.163203] 7cc0: ffff800973897ce0 ffff0000080c4bd8 0000000000000000 > ffff800974fc9a00 > [60796.170962] 7ce0: ffff800973897d00 ffff0000082a14d0 ffff800974e4dd00 > ffff800974fc9a00 > [60796.178721] 7d00: ffff800973897d70 ffff000008415410 0000000000000000 > ffff800974da6380 > [60796.186479] 7d20: 0000000033c61000 0000000000010000 ffff800973897eb8 > ffff0000090bc1a8 > [60796.194237] 7d40: 0000000000000123 000000000000003f ffff000008b12000 > ffff800973894000 > [60796.201995] 7d60: 000000000000000d 000000000000000e ffff800973897dc0 > ffff000008272d88 > [60796.209753] 7d80: ffff800974da6380 ffff800973897eb8 0000000000010000 > 0000000033c61000 > [60796.217514] 7da0: 0000000060000000 0000000000000015 0000000000000000 > 0000000100000000 > [60796.225277] 7dc0: ffff800973897e50 ffff000008273d00 0000000000010000 > ffff800974da6380 > [60796.233035] 7de0: 0000000033c61000 ffff800973897eb8 ffff800973897e20 > ffff000008273be8 > [60796.240794] 7e00: ffff800974da6380 0000000000010000 0000000000000000 > ffff800973897eb8 > [60796.248552] 7e20: ffff800973897e50 ffff000008273cdc 0000000000010000 > ffff800974da6380 > [60796.256310] 7e40: 0000000033c61000 ffff800973897eb8 ffff800973897e80 > ffff0000082752ac > [60796.264069] 7e60: ffff800974da6380 ffff800974da6380 0000000033c61000 > 0000000000010000 > [60796.271830] 7e80: 0000000000000000 ffff0000080836f0 0000000000000000 > 000000000041a310 > [60796.279588] 7ea0: ffffffffffffffff 0000ffffa39cd45c 0000000000000123 > 0000000000000000 > [60796.287346] 7ec0: 0000000000000003 0000000033c61000 0000000000010000 > 0000000000000000 > [60796.295103] 7ee0: 0000000000011011 0000000000000001 0000000000000011 > 0000000000000002 > [60796.302861] 7f00: 000000000000003f 1f3c201f7372686b 00000000ffffffff > 0000000000000030 > [60796.310618] 7f20: 0000000000000038 0000000000000000 0000ffffa3912a94 > 0000ffffa3a47588 > [60796.318376] 7f40: 0000000000000000 000000000041a1c8 0000ffffe30bd910 > 0000000000010000 > [60796.326133] 7f60: 000000000041a310 0000000033c61000 0000000000000003 > 000000007fffe000 > [60796.333891] 7f80: 00000000004088d0 0000000000000000 0000000000000000 > 0000000000000000 > [60796.341649] 7fa0: 0000000000010000 0000ffffe30bdbb0 0000000000404dcc > 0000ffffe30bdbb0 > [60796.349407] 7fc0: 0000ffffa39cd45c 0000000060000000 0000000000000003 > 000000000000003f > [60796.357164] 7fe0: 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > [60796.364917] Call trace: > [60796.367342] Exception stack(0xffff800973897af0 to 0xffff800973897c20) > [60796.373729] 7ae0: 0000000000000000 > 0001000000000000 > [60796.381492] 7b00: ffff800973897cc0 ffff0000080c4b38 ffff800973897b20 > ffff000008de460f > [60796.389251] 7b20: ffff800973897ba0 ffff0000082a1a38 ffff800974e4dd00 > ffff800973897c10 > [60796.397009] 7b40: ffff000008de45d0 ffff800972234dc0 ffff800973897eb8 > ffff800974da6380 > [60796.404767] 7b60: 0000000000010000 ffff800974e4dd40 0000000033c61000 > ffff800973897d60 > [60796.412529] 7b80: 0000000000000002 ffff000008b633c8 ffff0000080c4bd8 > ffff800972074000 > [60796.420287] 7ba0: ffff800973897d68 ffff0000080c4ba0 0000000000000001 > 0000000000000001 > [60796.428045] 7bc0: ffff800975546459 0000000000000004 ffff800973897b08 > 000000000000000f > [60796.435802] 7be0: 000000000000000c 0000000000000000 0000000005f5e0ff > 0000000000000000 > [60796.443560] 7c00: 0000ffffa3912a94 ffff800975546457 ffff000008275258 > 000000000041a1c8 > [60796.451320] [<ffff0000080c4b38>] iter_next+0x18/0x80 > [60796.456239] [<ffff0000080c4bd8>] debug_next+0x38/0x90 > [60796.461247] [<ffff0000082a14d0>] seq_read+0x310/0x420 > [60796.466256] [<ffff000008415410>] full_proxy_read+0x60/0x88 > [60796.471693] [<ffff000008272d88>] __vfs_read+0x48/0x130 > [60796.476784] [<ffff000008273d00>] vfs_read+0x88/0x140 > [60796.481703] [<ffff0000082752ac>] SyS_read+0x54/0xb0 > [60796.486538] [<ffff0000080836f0>] el0_svc_naked+0x24/0x28 > [60796.491804] Code: f9000bf3 aa0003f3 aa1e03e0 d503201f (b9400a60) > [60796.498076] ---[ end trace 31bfd09d844bbfc9 ]--- > > As I didn't understand the seq_* semantics in the first place, I didn't > have a look yet what could cause this. Nice catch, I'll have a look at this. Just so I'm sure, these are two processes reading the vgic-state file for the same single VM, right? Thanks for actually testing this! -Christoffer
