Hi, Peter Chen <hzpeterchen@xxxxxxxxx> writes: > On Tue, Nov 15, 2016 at 07:58:16AM +0100, Greg KH wrote: >> On Tue, Nov 15, 2016 at 02:02:47PM +0800, Peter Chen wrote: >> > This can fix below dump when the lock is accessed at host >> > mode due to it is not initialized. >> > >> > [ 46.119638] INFO: trying to register non-static key. >> > [ 46.124643] the code is fine but needs lockdep annotation. >> > [ 46.130144] turning off the locking correctness validator. >> > [ 46.135659] CPU: 0 PID: 690 Comm: cat Not tainted 4.9.0-rc3-00079-g4b75f1d #1210 >> > [ 46.143075] Hardware name: Freescale i.MX6 SoloX (Device Tree) >> > [ 46.148923] Backtrace: >> > [ 46.151448] [<c010c460>] (dump_backtrace) from [<c010c658>] (show_stack+0x18/0x1c) >> > [ 46.159038] r7:edf52000 >> > [ 46.161412] r6:60000193 >> > [ 46.163967] r5:00000000 >> > [ 46.165035] r4:c0e25c2c >> > >> > [ 46.169109] [<c010c640>] (show_stack) from [<c03f58a4>] (dump_stack+0xb4/0xe8) >> > [ 46.176362] [<c03f57f0>] (dump_stack) from [<c016d690>] (register_lock_class+0x4fc/0x56c) >> > [ 46.184554] r10:c0e25d24 >> > [ 46.187014] r9:edf53e70 >> > [ 46.189569] r8:c1642444 >> > [ 46.190637] r7:ee9da024 >> > [ 46.193191] r6:00000000 >> > [ 46.194258] r5:00000000 >> > [ 46.196812] r4:00000000 >> > [ 46.199185] r3:00000001 >> > >> > [ 46.203259] [<c016d194>] (register_lock_class) from [<c0171294>] (__lock_acquire+0x80/0x10f0) >> > [ 46.211797] r10:c0e25d24 >> > [ 46.214257] r9:edf53e70 >> > [ 46.216813] r8:ee9da024 >> > [ 46.217880] r7:c1642444 >> > [ 46.220435] r6:edcd1800 >> > [ 46.221502] r5:60000193 >> > [ 46.224057] r4:00000000 >> > >> > [ 46.227953] [<c0171214>] (__lock_acquire) from [<c01726c0>] (lock_acquire+0x74/0x94) >> > [ 46.235710] r10:00000001 >> > [ 46.238169] r9:edf53e70 >> > [ 46.240723] r8:edf53f80 >> > [ 46.241790] r7:00000001 >> > [ 46.244344] r6:00000001 >> > [ 46.245412] r5:60000193 >> > [ 46.247966] r4:00000000 >> > >> > [ 46.251866] [<c017264c>] (lock_acquire) from [<c096c8fc>] (_raw_spin_lock_irqsave+0x40/0x54) >> > [ 46.260319] r7:ee1c6a00 >> > [ 46.262691] r6:c062a570 >> > [ 46.265247] r5:20000113 >> > [ 46.266314] r4:ee9da014 >> > >> > [ 46.270393] [<c096c8bc>] (_raw_spin_lock_irqsave) from [<c062a570>] (ci_port_test_show+0x2c/0x70) >> > [ 46.279280] r6:eebd2000 >> > [ 46.281652] r5:ee9da010 >> > [ 46.284207] r4:ee9da014 >> > >> > [ 46.286810] [<c062a544>] (ci_port_test_show) from [<c0248d04>] (seq_read+0x1ac/0x4f8) >> > [ 46.294655] r9:edf53e70 >> > [ 46.297028] r8:edf53f80 >> > [ 46.299583] r7:ee1c6a00 >> > [ 46.300650] r6:00000001 >> > [ 46.303205] r5:00000000 >> > [ 46.304273] r4:eebd2000 >> > [ 46.306850] [<c0248b58>] (seq_read) from [<c039e864>] (full_proxy_read+0x54/0x6c) >> > [ 46.314348] r10:00000000 >> > [ 46.316808] r9:c0a6ad30 >> > [ 46.319363] r8:edf53f80 >> > [ 46.320430] r7:00020000 >> > [ 46.322986] r6:b6de3000 >> > [ 46.324053] r5:ee1c6a00 >> > [ 46.326607] r4:c0248b58 >> > >> > [ 46.330505] [<c039e810>] (full_proxy_read) from [<c021ec98>] (__vfs_read+0x34/0x118) >> > [ 46.338262] r9:edf52000 >> > [ 46.340635] r8:c0107fc4 >> > [ 46.343190] r7:00020000 >> > [ 46.344257] r6:edf53f80 >> > [ 46.346812] r5:c039e810 >> > [ 46.347879] r4:ee1c6a00 >> > [ 46.350447] [<c021ec64>] (__vfs_read) from [<c021fbd0>] (vfs_read+0x8c/0x11c) >> > [ 46.357597] r9:edf52000 >> > [ 46.359969] r8:c0107fc4 >> > [ 46.362524] r7:edf53f80 >> > [ 46.363592] r6:b6de3000 >> > [ 46.366147] r5:ee1c6a00 >> > [ 46.367214] r4:00020000 >> > [ 46.369782] [<c021fb44>] (vfs_read) from [<c0220a4c>] (SyS_read+0x4c/0xa8) >> > [ 46.376672] r8:c0107fc4 >> > [ 46.379045] r7:00020000 >> > [ 46.381600] r6:b6de3000 >> > [ 46.382667] r5:ee1c6a00 >> > [ 46.385222] r4:ee1c6a00 >> > >> > [ 46.387817] [<c0220a00>] (SyS_read) from [<c0107e20>] (ret_fast_syscall+0x0/0x1c) >> > [ 46.395314] r7:00000003 >> > [ 46.397687] r6:b6de3000 >> > [ 46.400243] r5:00020000 >> > [ 46.401310] r4:00020000 >> > >> > Cc: <stable@xxxxxxxxxxxxxxx> #v4.1+ >> >> Any idea what commit caused the problem? >> > > This issue has been existed from this driver has written, and the > structure refined later, this patch can be applied after that > (4 years ago), I think v4.1 is the last stable tree it can be > applied. from a quick read, it looks to me like commit e443b333629f82ca0da91a05ca638050943bbedd is the first one where this would be reproducible. That would be v3.5, IIRC. We still have a few longterm kernels before v4.1 which might wanna use this commit. -- balbi
Attachment:
signature.asc
Description: PGP signature
