From: kbuild test robot <lkp@intel.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: kbuild-all@01.org, linux-kernel@vger.kernel.org,
Petr Mladek <pmladek@suse.com>,
Steven Rostedt <rostedt@goodmis.org>,
Daniel Wang <wonderfly@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
Jiri Slaby <jslaby@suse.com>, Peter Feiner <pfeiner@google.com>,
linux-serial@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [PATCHv3] panic: avoid deadlocks in re-entrant console drivers
Date: Thu, 25 Oct 2018 18:51:01 +0800 [thread overview]
Message-ID: <201810251848.0wSJMnS0%fengguang.wu@intel.com> (raw)
In-Reply-To: <20181025101036.6823-1-sergey.senozhatsky@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5410 bytes --]
Hi Sergey,
I love your patch! Yet something to improve:
[auto build test ERROR on linux-sof-driver/master]
[also build test ERROR on v4.19 next-20181019]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sergey-Senozhatsky/panic-avoid-deadlocks-in-re-entrant-console-drivers/20181025-181929
base: https://github.com/thesofproject/linux master
config: i386-randconfig-x077-201842 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
kernel/panic.c: In function 'panic':
>> kernel/panic.c:237:2: error: implicit declaration of function 'unblank_screen' [-Werror=implicit-function-declaration]
unblank_screen();
^~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/unblank_screen +237 kernel/panic.c
186
187 /*
188 * If we have crashed and we have a crash kernel loaded let it handle
189 * everything else.
190 * If we want to run this after calling panic_notifiers, pass
191 * the "crash_kexec_post_notifiers" option to the kernel.
192 *
193 * Bypass the panic_cpu check and call __crash_kexec directly.
194 */
195 if (!_crash_kexec_post_notifiers) {
196 printk_safe_flush_on_panic();
197 __crash_kexec(NULL);
198
199 /*
200 * Note smp_send_stop is the usual smp shutdown function, which
201 * unfortunately means it may not be hardened to work in a
202 * panic situation.
203 */
204 smp_send_stop();
205 } else {
206 /*
207 * If we want to do crash dump after notifier calls and
208 * kmsg_dump, we will need architecture dependent extra
209 * works in addition to stopping other CPUs.
210 */
211 crash_smp_send_stop();
212 }
213
214 /*
215 * Run any panic handlers, including those that might need to
216 * add information to the kmsg dump output.
217 */
218 atomic_notifier_call_chain(&panic_notifier_list, 0, buf);
219
220 /* Call flush even twice. It tries harder with a single online CPU */
221 printk_safe_flush_on_panic();
222 kmsg_dump(KMSG_DUMP_PANIC);
223
224 /*
225 * If you doubt kdump always works fine in any situation,
226 * "crash_kexec_post_notifiers" offers you a chance to run
227 * panic_notifiers and dumping kmsg before kdump.
228 * Note: since some panic_notifiers can make crashed kernel
229 * more unstable, it can increase risks of the kdump failure too.
230 *
231 * Bypass the panic_cpu check and call __crash_kexec directly.
232 */
233 if (_crash_kexec_post_notifiers)
234 __crash_kexec(NULL);
235
236 #ifdef CONFIG_VT
> 237 unblank_screen();
238 #endif
239 console_unblank();
240
241 /*
242 * We may have ended up stopping the CPU holding the lock (in
243 * smp_send_stop()) while still having some valuable data in the console
244 * buffer. Try to acquire the lock then release it regardless of the
245 * result. The release will also print the buffers out. Locks debug
246 * should be disabled to avoid reporting bad unlock balance when
247 * panic() is not being callled from OOPS.
248 */
249 debug_locks_off();
250 console_flush_on_panic();
251
252 if (!panic_blink)
253 panic_blink = no_blink;
254
255 if (panic_timeout > 0) {
256 /*
257 * Delay timeout seconds before rebooting the machine.
258 * We can't use the "normal" timers since we just panicked.
259 */
260 pr_emerg("Rebooting in %d seconds..\n", panic_timeout);
261
262 for (i = 0; i < panic_timeout * 1000; i += PANIC_TIMER_STEP) {
263 touch_nmi_watchdog();
264 if (i >= i_next) {
265 i += panic_blink(state ^= 1);
266 i_next = i + 3600 / PANIC_BLINK_SPD;
267 }
268 mdelay(PANIC_TIMER_STEP);
269 }
270 }
271 if (panic_timeout != 0) {
272 /*
273 * This will not be a clean reboot, with everything
274 * shutting down. But if there is a chance of
275 * rebooting the system it will be rebooted.
276 */
277 emergency_restart();
278 }
279 #ifdef __sparc__
280 {
281 extern int stop_a_enabled;
282 /* Make sure the user can actually press Stop-A (L1-A) */
283 stop_a_enabled = 1;
284 pr_emerg("Press Stop-A (L1-A) from sun keyboard or send break\n"
285 "twice on console to return to the boot prom\n");
286 }
287 #endif
288 #if defined(CONFIG_S390)
289 {
290 unsigned long caller;
291
292 caller = (unsigned long)__builtin_return_address(0);
293 disabled_wait(caller);
294 }
295 #endif
296 pr_emerg("---[ end Kernel panic - not syncing: %s ]---\n", buf);
297 local_irq_enable();
298 for (i = 0; ; i += PANIC_TIMER_STEP) {
299 touch_softlockup_watchdog();
300 if (i >= i_next) {
301 i += panic_blink(state ^= 1);
302 i_next = i + 3600 / PANIC_BLINK_SPD;
303 }
304 mdelay(PANIC_TIMER_STEP);
305 }
306 }
307
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33530 bytes --]
next prev parent reply other threads:[~2018-10-25 10:52 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-16 5:04 [RFC][PATCHv2 0/4] less deadlock prone serial consoles Sergey Senozhatsky
2018-10-16 5:04 ` [RFC][PATCHv2 1/4] panic: avoid deadlocks in re-entrant console drivers Sergey Senozhatsky
2018-10-17 4:48 ` Sergey Senozhatsky
2018-10-23 11:07 ` Petr Mladek
2018-10-23 11:54 ` Sergey Senozhatsky
2018-10-23 12:04 ` Sergey Senozhatsky
2018-10-23 12:12 ` Sergey Senozhatsky
2018-10-25 9:06 ` Petr Mladek
2018-10-25 9:31 ` Sergey Senozhatsky
2018-10-25 8:29 ` Petr Mladek
2018-10-25 9:05 ` Sergey Senozhatsky
2018-10-25 10:10 ` [PATCHv3] " Sergey Senozhatsky
2018-10-25 10:51 ` kbuild test robot [this message]
2018-10-25 11:56 ` Sergey Senozhatsky
2018-10-31 12:27 ` Petr Mladek
2018-11-01 1:48 ` Sergey Senozhatsky
2018-11-01 8:08 ` Petr Mladek
2018-11-22 13:12 ` Petr Mladek
2018-12-12 0:53 ` Daniel Wang
2018-12-12 5:23 ` Sergey Senozhatsky
2018-12-12 5:59 ` Daniel Wang
2018-12-12 6:06 ` Sergey Senozhatsky
2018-12-12 6:09 ` Daniel Wang
2018-10-16 5:04 ` [RFC][PATCHv2 2/4] printk: move printk_safe macros to printk header Sergey Senozhatsky
2018-10-16 7:27 ` Peter Zijlstra
2018-10-16 11:40 ` Petr Mladek
2018-10-16 12:17 ` Peter Zijlstra
2018-10-17 10:50 ` Petr Mladek
2018-10-17 14:00 ` Peter Zijlstra
2018-10-22 14:30 ` Petr Mladek
2018-10-16 12:27 ` Sergey Senozhatsky
2018-10-16 12:38 ` Peter Zijlstra
2018-10-16 12:54 ` Peter Zijlstra
2018-10-16 14:21 ` Peter Zijlstra
2018-10-17 4:32 ` Sergey Senozhatsky
2018-10-17 7:57 ` Peter Zijlstra
2018-10-17 13:36 ` Sergey Senozhatsky
2018-10-23 6:25 ` Sergey Senozhatsky
2018-10-16 5:04 ` [RFC][PATCHv2 3/4] serial: introduce uart_port locking helpers Sergey Senozhatsky
2018-12-08 3:12 ` Sergey Senozhatsky
2018-12-12 11:08 ` Greg Kroah-Hartman
2018-10-16 5:04 ` [RFC][PATCHv2 4/4] tty: 8250: switch to " Sergey Senozhatsky
2018-10-16 7:23 ` [RFC][PATCHv2 0/4] less deadlock prone serial consoles Peter Zijlstra
2018-10-16 8:12 ` Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201810251848.0wSJMnS0%fengguang.wu@intel.com \
--to=lkp@intel.com \
--cc=akpm@linux-foundation.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=kbuild-all@01.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pfeiner@google.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=wonderfly@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).