linux-kernel - Re: RT-Kernel boot stalls because of change in fs/dcache.c

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] [day] [month] [year] [list]

Date:   Wed, 19 Dec 2018 17:24:30 +0000
From:   Schrempf Frieder <frieder.schrempf@...tron.de>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-rt-users@...r.kernel.org" <linux-rt-users@...r.kernel.org>
Subject: Re: RT-Kernel boot stalls because of change in fs/dcache.c

On 19.12.18 14:46, Frieder Schrempf wrote:
> Hi Sebastian,
> 
> On 19.12.18 12:36, Sebastian Andrzej Siewior wrote:
>> On 2018-12-19 07:50:17 [+0000], Schrempf Frieder wrote:
>>> + linux-rt-users
>>>
>>> On 17.12.18 11:42, Frieder Schrempf wrote:
>>>> Hi,
>>>>
>>>> I have tried to boot a 4.14-Kernel with the RT-patches and
>>>> PREEMPT_RT_FULL on an i.MX6UL board. Unfortunately the boot stalls at
>>>> some point and never finishes.
>>>>
>>>> I did some bisecting and found out, that reverting this change: [1],
>>>> makes the board boot correctly.
>>>>
>>>> Can anyone help to come up with a proper fix for this?
>>
>> can you check if the hashtable is initialized twice?
> 
> I'm not sure how to check, but I guess you are on the right track. I can 
> leave the init loop for dentry_hashtable in place and remove the one for 
> in_lookup_hashtable in vfs_caches_init_early() and this also makes the 
> board boot.
> 
> Could it be, that the initializing for dentry_hashtable and 
> in_lookup_hashtable somehow interfere?

So the source of the issue turned out to be completely unrelated to 
this. Although it seems like enabling PREEMPT_RT_FULL triggered the 
problem in my case.

The lockup of the kernel was caused by the SNVS RTC driver. Pulling in 
this patch: [1], solved the problem.

As this patch fixes a real bug I sent a request for it to be backported 
to the stable releases.

[1]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cd7f3a249dbed2858e6c2f30e5be7f1f7a709ee2

>>>>
>>>> [1]:
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/commit/?h=v4.14-rt&id=56684d21f7f8341f7a5ed1433714112f49294590 
>>>>
>>
>> Sebastian
>>