linux-kernel - Re: Bug report: A commit about serial8250 cause the output disorderly at the phase of startup

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:   Tue, 23 Apr 2019 16:26:25 +0800
From:   "Hongzhi, Song" <hongzhi.song@...driver.com>
To:     John Ogness <john.ogness@...utronix.de>
CC:     <linux-kernel@...r.kernel.org>,
        linux-rt-users <linux-rt-users@...r.kernel.org>,
        <bigeasy@...utronix.de>
Subject: Re: Bug report: A commit about serial8250 cause the output disorderly
 at the phase of startup


On 4/23/19 2:48 PM, John Ogness wrote:
> On 2019-04-22, Hongzhi, Song <hongzhi.song@...driver.com> wrote:
>> Anyone notice this issue?
> Yes, I am aware of the issue. It is actually a feature, not a bug. ;-)
> Individual LOG_CONT messages, when classified as emergency messages, are
> printed immediately to the console.

Yes, this is what I have acquired from commit log and code.

The emergency mechanism is a good way.


>   This makes them appear
> "disorderly". It is not yet clear how best to deal with LOG_CONT
> emergency messages.


Extracting a part of log from my LOG_CONT message,

[    0.761635] 000:  (family: 0x6, model: 0xf
[    0.761635] 000: , stepping: 0xb)

It obviously separates a full line. Maybe it is not related to LOG_CONT. ^_^


The counterpart source code:

1499     pr_cont(" (family: 0x%x, model: 0x%x", c->x86, c->x86_model);
1500
1501     if (c->x86_stepping || c->cpuid_level >= 0)
1502         pr_cont(", stepping: 0x%x)\n", c->x86_stepping);
1503     else
1504         pr_cont(")\n");


I don't know if the issue exists in other place except LOG_CONT.

But it indeed influences customer's judgement.


Thanks for you reply.

--Hongzhi


> But I suppose we should introduce a config option to
> disable atomic consoles altogether if users preferred buffered/delayed
> printk output.




>
> John Ogness
>
>
>> On 4/19/19 10:24 AM, Hongzhi, Song wrote:
>>> 1. Issue description:
>>>
>>> Boot kernel( >= linux-rt-devel-v5.0.3 ) with qemu.
>>> Then qemu will print following disorderly messages.
>>>
>>> At the beginning, the messages are disorderly. But then it becomes
>>> normally from printing "[    0.000000] 000: Linux version..."
>>>
>>> --------------------------------------------------
>>> [    0.019000] 000: tsc: Unable to calibrate against PIT
>>> [    0.002583] 000: 6199.83 BogoMIPS (lpj=3099918)
>>> [    0.521247] 000: Intel(R) Core(TM)2 Duo CPU     T7700  @ 2.40GHz
>>> [    0.521247] 000:  (family: 0x6, model: 0xf
>>> [    0.521247] 000: , stepping: 0xb)
>>> [    0.533126] 000: unsupported p6 CPU model 15
>>> [    0.533318] 000: no PMU driver, software events only.
>>> [    0.765082] 000: 1 ACPI AML tables successfully acquired and loaded
>>> [    0.765274] 000:
>>> [    0.785903] 000: Enabled 2 GPEs in block 00 to 0F
>>> [    0.786128] 000:
>>> [    0.835675] 000: acpi PNP0A03:00: fail to add MMCONFIG
>>> information, can't access extended PCI configuration space under
>>> this bridge.
>>> [    0.892056] 000:  5
>>> [    0.892289] 000:  *10
>>> [    0.892416] 000:  11
>>> [    0.892527] 000: )
>>> [    0.892661] 000:
>>>
>>> /* skip some repeated contents */
>>>
>>> [    5.052149] 000: , 512kB Cache
>>> [    0.000000] 000: Linux version 5.0.3-yocto-preempt-rt+
>>> (hsong@...-lpggp1) (gcc version 8.3.0 (GCC)) #24 SMP PREEMPT Thu Apr
>>> 18 03:29:58 EDT 2019
>>> [    0.000000] 000: Command line: root=/dev/vda rw highres=off
>>> console=ttyS0 mem=256M ip=192.168.7.4::192.168.7.3:255.255.255.0
>>> vga=0 uvesafb.mode_opti0
>>> [    0.000000] 000: x86/fpu: x87 FPU will use FXSAVE
>>> [    0.000000] 000: BIOS-provided physical RAM map:
>>> [    0.000000] 000: BIOS-e820: [mem
>>> 0x0000000000000000-0x000000000009fbff]
>>> [    0.000000] 000: BIOS-e820: [mem
>>> 0x000000000009fc00-0x000000000009ffff]
>>> [    0.000000] 000: BIOS-e820: [mem
>>> 0x00000000000f0000-0x00000000000fffff]
>>> [    0.000000] 000: BIOS-e820: [mem
>>> 0x0000000000100000-0x000000000ffdbfff]
>>>
>>> --------------------------------------------------
>>>
>>> 2. Reproduce:
>>> (1)build kernel: (Attachment is my .config)
>>> make ARCH=x86_64
>>> CROSS_COMPILE=[path-to-my-cross-toolchain]/x86_64-wrs-linux-
>>>
>>> (2)boot kernel with qemu:
>>>
>>> qemu-system-x86_64 \
>>> -drive file=qemux86-64.rootfs.ext4,if=virtio,format=raw \
>>> -nographic \
>>> -kernel arch/x86/boot/bzImage \
>>> -append 'root=/dev/vda rw highres=off  console=ttyS0 mem=256M ip=dhcp'
>>>
>>> 3. Analysis:
>>> I find the following commit from >=linux-rt-devel-v5.0.3. cause the
>>> issue.
>>>
>>> b9d460e serial: 8250: implement write_atomic