Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964932AbbEMOZ4 (ORCPT ); Wed, 13 May 2015 10:25:56 -0400 Received: from smtpbg64.qq.com ([103.7.28.238]:59939 "EHLO smtpbg64.qq.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932597AbbEMOZv (ORCPT ); Wed, 13 May 2015 10:25:51 -0400 X-Greylist: delayed 369 seconds by postgrey-1.27 at vger.kernel.org; Wed, 13 May 2015 10:25:50 EDT X-QQ-GoodBg: 0 X-QQ-SSF: 0020000000000080 X-QQ-FEAT: IT6ekswxtdyo9pBGhvvTigQ/d3M0ctQtDOKGWzT2aVpgKWVmgO1GuGfTmwbUS L4CJTAYgWkPSHLk1JNfl8rPNZcwyQ+HEOSCEjK01P0JiMthUKylxoIKzlZsfACAMWDczHyd xjwYfPc33U+F9xH3d3V+Nd2zi5q2Qr+gflzWcb7bDBRKyDbTBQ8y9dllGdLt X-QQ-BUSINESS-ORIGIN: 2 X-Originating-IP: 45.33.105.14 X-QQ-STYLE: X-QQ-mid: bizmail40t1431526494t9282869 From: "=?utf-8?B?546L6b6Z?=" To: "=?utf-8?B?cm9zdGVkdA==?=" , "=?utf-8?B?amtvc2luYQ==?=" , "=?utf-8?B?cGF1bG1jaw==?=" , "=?utf-8?B?cG1sYWRlaw==?=" , "=?utf-8?B?ZHppY2t1cw==?=" Cc: "=?utf-8?B?am9oYW5uZXM=?=" , "=?utf-8?B?a29jdDlp?=" , "=?utf-8?B?dGdseA==?=" , "=?utf-8?B?bWluZ28=?=" , "=?utf-8?B?aHBh?=" , "=?utf-8?B?eDg2?=" , "=?utf-8?B?YXRvbWxpbg==?=" , "=?utf-8?B?YWtwbQ==?=" , "=?utf-8?B?c2FzaGEubGV2aW4=?=" , "=?utf-8?B?bGludXgta2VybmVs?=" , "=?utf-8?B?cGVpZmVpeXVl?=" , "=?utf-8?B?bG9uZy53YW5nbG9uZw==?=" , "=?utf-8?B?bW9yZ2FuLndhbmc=?=" Subject: [RFC] how to perform a safe NMI stack trace on all CPUs on x86? Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Date: Wed, 13 May 2015 22:14:54 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-QQ-SENDSIZE: 520 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t4DEQ2MY026796 Content-Length: 991 Lines: 18 Hi all, In kernel before 3.19, when trigger_all_cpu_backtrace() is called on x86, it will trigger an NMI on each CPU and call show_regs(). But this can lead to a hard lock up if the NMI comes in on another printk(). The commit a9edc88093287183ac934be44f295f183b2c62dd (x86/nmi: Perform a safe NMI stack trace on all CPUs) fix this problem on kernel mainline. when the NMI triggers, it switches the printk routine for that CPU to call a NMI safe printk function that records the printk in a per_cpu seq_buf descriptor. After all NMIs have finished recording its data, the seq_bufs are printed in a safe context. But how do we fix this problem in older version of kernel(eg, 3.10 stable)? The 3.10 stable has no "switch printk routine" and "seq_buf" infrastructures. Could anyone give me some ideas? Best Regards Wang Long????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?