linux-kernel - Re: [lkp] [printk] 34578dc67f: EIP is at vprintk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160302103006.GB3166@pathway.suse.cz>
Date:	Wed, 2 Mar 2016 11:30:06 +0100
From:	Petr Mladek <pmladek@...e.com>
To:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	kernel test robot <ying.huang@...ux.intel.com>, lkp@...org,
	Rob Herring <robh+dt@...nel.org>,
	Frank Rowand <frowand.list@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	devicetree@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Calvin Owens <calvinowens@...com>,
	Dave Jones <davej@...emonkey.org.uk>,
	Kyle McMartin <kyle@...nel.org>, Tejun Heo <tj@...nel.org>,
	Jan Kara <jack@...e.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [lkp] [printk] 34578dc67f: EIP is at vprintk_emit+0x1ea/0x600

On Thu 2016-02-25 14:10:05, Sergey Senozhatsky wrote:
> CONFIG_PREEMPT_NONE=y
> # CONFIG_PREEMPT_VOLUNTARY is not set
> # CONFIG_PREEMPT is not set
> CONFIG_PREEMPT_COUNT=y

I was curious why your patch actually did not help to avoid the
softlockup. The infinite printk loop was called in a safe context,
CONFIG_PREEMPT_COUNT=y, so it did set console_may_schedule = 1.

But it never got console_sem, never called console_unlock()
and never called cond_resched() there. So, it never got preempted
in the PREEMPT_NONE kernel. The console_sem was owned by
another process that was busy handling the flood of messages.

Note that the infinite cycle calling printk() might be interrupted anywhere
by the NMI watchdog. It explains why the original report pointed
at the beginning of the printk. It was not a deadlock.
I got the softlockup on random locations here.

Also it is not the classic softlockup in console_unlock().
The process handling the console actually could sleep if it
has console_may_schedule = 1. This is why console_unlock()
did not appeared in the softlockup backtrace.

Conclusion:

Sergey is correct and his patches are innocent here.

Sergey, if you send the fix for
of_unittest_destroy_tracked_overlays(), please add me into CC.

Best Regards,
Petr

PS: I am sorry for the noise and that it took me so long to shake my
head around this problem. Thanks a lot for patience.