https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-2603 Lustre <p>When I was repeating mount/umount and "lctl --device ${devno} deactivate" on a client node, kernel panic happened.<br/> The below is the stack trace of the thread which caused the kernel panic.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>PID: 7160 TASK: ffff88060a370aa0 CPU: 2 COMMAND: "lctl" #0 [ffff8805f8ba7b20] machine_kexec at ffffffff8103281b #1 [ffff8805f8ba7b80] crash_kexec at ffffffff810ba792 #2 [ffff8805f8ba7c50] oops_end at ffffffff81501700 #3 [ffff8805f8ba7c80] die at ffffffff8100f26b #4 [ffff8805f8ba7cb0] do_general_protection at ffffffff81501292 #5 [ffff8805f8ba7ce0] general_protection at ffffffff81500a65 [exception RIP: class_handle_ioctl+4926] RIP: ffffffffa04e776e RSP: ffff8805f8ba7d98 RFLAGS: 00010206 RAX: 0000000000000000 RBX: ffff8805f4f0c800 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88062808b500 RBP: ffff8805f8ba7e38 R8: 0000000000000000 R9: ffffffff8163abc0 R10: 0000000000000001 R11: 0000000000000000 R12: 00000000c0086815 R13: 00007fff38122d70 R14: 5a5a5a5a5a5a5a5a R15: 0000000000000240 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #6 [ffff8805f8ba7d90] class_handle_ioctl at ffffffffa04e76f4 [obdclass] #7 [ffff8805f8ba7e40] obd_class_ioctl at ffffffffa04d12ab [obdclass] #8 [ffff8805f8ba7e60] vfs_ioctl at ffffffff8118dff2 #9 [ffff8805f8ba7ea0] do_vfs_ioctl at ffffffff8118e194 #10 [ffff8805f8ba7f30] sys_ioctl at ffffffff8118e711 #11 [ffff8805f8ba7f80] system_call_fastpath at ffffffff8100b0f2 RIP: 00000032e3adf7b7 RSP: 00007fff38122d08 RFLAGS: 00010202 RAX: 0000000000000010 RBX: ffffffff8100b0f2 RCX: 0000000000000018 RDX: 00007fff38122d70 RSI: 00000000c0086815 RDI: 0000000000000003 RBP: 0000000000000001 R8: 0000000000000000 R9: 0000000000000240 R10: 00007fff38122a90 R11: 0000000000000202 R12: 00000000c0086815 R13: 00007fff38122d70 R14: 0000000000676ae0 R15: 0000000000000003 ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b </pre> </div></div> <p>Actually class_handle_ioctl() has some if-statements which check obd status such as obd_stopping, obd_set_up and obd_attached. But there's no protection when class_handle_ioctl has already passed all of the if-statements. So, class_decref() can release an obd_device while class_handle_ioctl() is refering the obd_device. </p> <p>I'll upload a patch for this problem soon, so I will be pleased if someone checks my patch.</p> <p>Thank you.</p> LU-2603

kernel panic in class_handle_ioctl() when deactivating OSC

Bug Critical Resolved Won't Fix Cliff White Hiroya Nozaki patch Fri, 11 Jan 2013 01:40:12 +0000 Tue, 5 Aug 2014 20:04:05 +0000 Tue, 5 Aug 2014 20:04:05 +0000 Lustre 2.4.0 Lustre 2.1.5 Lustre 1.8.8 0 3 <p>patch for master<br/> <a href="http://review.whamcloud.com/5024" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5024</a></p> <p>Has there been any time to work on an improved patch?</p> <p>Just only I was thinking about the problem. </p> <p>I guess that we need to make some more similar functions like class_name2obd() and class_uuid2obd() with checking some obd's flags such as obd_stopping and obd_setup,<br/> and replace some class_uuid2obd() and class_name2obd() with the new ones if needed.</p> <p>And ... you know, it seems to me that it'll take me excessively lots of time, so now I'm hesitating starting it ... Do you have better ideas ?</p> <p>Has there been time for any further work on this? Is this still an issue?</p> <p>I am going to close this issue, due to lack of activity, please reopen if needed.</p> Development Rank 1|hzvezb: Rank (Obsolete) 6072 Severity