linux-kernel - Re: What happens before or in `schedule_preempt

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]

Message-ID: <cfe32337-d1de-d57c-080b-6d4ab852e22b@molgen.mpg.de>
Date:   Wed, 17 Oct 2018 18:47:09 +0200
From:   Paul Menzel <pmenzel@...gen.mpg.de>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: What happens before or in `schedule_preempt_disabled()`?

Dear Thomas,


As always thank you for the quick reply.


On 10/17/18 18:39, Thomas Gleixner wrote:

> On Wed, 17 Oct 2018, Paul Menzel wrote:
>>
>> Please find the debug patches attached. The `random: %i` messages are from
>> `crng_fast_load()`.
>>
>> My question is, how can I figure out, what happens in the code below?
>>
>>         complete(&kthreadd_done);
>>         pr_info("After kthreadd_done\n");
>>
>>         /*
>>          * The boot idle thread must execute schedule()
>>          * at least once to get things moving:
>>          */
>>         schedule_preempt_disabled();
>>         pr_info("After schedule_preempt_disabled\n");
>>
>> Looking at `schedule_preempt_disabled()`, it shouldn’t take much time, and I
>> was unable to find out where `crng_fast_load()` is called from.
>>
>> I guess threading is somehow working at that point, and I would though that
>> it is the `complete()` call, but wonder why the `After kthreadd_done` is
>> printed earlier.
> 
> This creates the init thread from the idle thread with preemption
> disabled. To get the init thread on the CPU the idle thread must schedule
> voluntary, which it does by calling schedule_preempt_disabled(). So the
> scheduler picks the init thread and that executes the init callbacks.
> 
> The random calls are invoked by add_interrupt_randomness() or
> add_hwgenerator_randomness(). But they are probably not consuming all the
> time.
> 
> The time is consumed by the initcalls which are required before bringing up
> the (non boot) CPUs. See kernel_init_freeable() which is called from
> kernel_init(). If you add initcall_debug to the command line you will get
> more information at least about the functions which are marked with
> initcall.

Thank you for the quick reply. Just a note, that `initcall_debug` is present
on the Linux kernel command line. (I didn’t mention that the full output of
`dmesg` was attached to my message.

    [    0.078186] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-rc8-00045-gc92161e11c2a root=/dev/sda1 rw noisapnp cryptomgr.notests quiet initcall_debug init=/lib/systemd/systemd-bootchart iomem=relaxed apparmor=0 selinux=0 kmemleak=off initcall_blacklist=serial8250_init,init_graph_trace udev.children_max=2 udev.log_priority=info

Thank you again for the pointers. I’ll look into those.


Kind regards,

Paul


Download attachment "smime.p7s" of type "application/pkcs7-signature" (5174 bytes)