Hello,
After several RFC series [0][1][2][3][4], here is the first set of
patches to rework the printk subsystem. This first set of patches
only replace the existing ringbuffer implementation. No locking is
removed. No semantics/behavior of printk are changed.
The VMCOREINFO is updated, which wil
On (20/02/05 12:25), lijiang wrote:
> Hi, John Ogness
>
> Thank you for improving the patch series and making great efforts.
>
> I'm not sure if I missed anything else. Or are there any other related
> patches to be applied?
>
> After applying this patch series, NMI watchdog detected a hard loc
On (20/02/05 12:25), lijiang wrote:
[..]
> [ 42.111004] Kernel Offset: 0x1f00 from 0x8100 (relocation
> range: 0x8000-0xbfff)
> [ 42.111005] general protection fault: [#1] SMP PTI
> [ 42.111005] CPU: 15 PID: 1395 Comm: systemd-journal Not tainted
On (20/02/05 13:48), Sergey Senozhatsky wrote:
> On (20/02/05 12:25), lijiang wrote:
> [..]
> > [ 42.111004] Kernel Offset: 0x1f00 from 0x8100
> > (relocation range: 0x8000-0xbfff)
> > [ 42.111005] general protection fault: [#1] SMP PTI
> > [ 42.1
> On (20/02/05 13:48), Sergey Senozhatsky wrote:
>> On (20/02/05 12:25), lijiang wrote:
>> [..]
>>> [ 42.111004] Kernel Offset: 0x1f00 from 0x8100
>>> (relocation range: 0x8000-0xbfff)
>>> [ 42.111005] general protection fault: [#1] SMP PTI
>>> [
On (20/02/05 13:38), lijiang wrote:
> > On (20/02/05 13:48), Sergey Senozhatsky wrote:
> >> On (20/02/05 12:25), lijiang wrote:
[..]
> >>
> >> So there is a General protection fault. That's the type of a problem that
> >> kills the boot for me as well (different backtrace, tho).
> >
> > Do you h
On 2020-02-05, Sergey Senozhatsky wrote:
So there is a General protection fault. That's the type of a
problem that kills the boot for me as well (different backtrace,
tho).
>>>
>>> Do you have CONFIG_RELOCATABLE and CONFIG_RANDOMIZE_BASE (KASLR)
>>> enabled?
>>
>> Yes. These two o
On (20/02/05 10:00), John Ogness wrote:
> On 2020-02-05, Sergey Senozhatsky wrote:
> So there is a General protection fault. That's the type of a
> problem that kills the boot for me as well (different backtrace,
> tho).
> >>>
> >>> Do you have CONFIG_RELOCATABLE and CONFIG_RANDOMI
> On (20/02/05 13:38), lijiang wrote:
>>> On (20/02/05 13:48), Sergey Senozhatsky wrote:
On (20/02/05 12:25), lijiang wrote:
>
> [..]
>
So there is a General protection fault. That's the type of a problem that
kills the boot for me as well (different backtrace, tho).
>>>
>>> D
> On 2020-02-05, Sergey Senozhatsky wrote:
> So there is a General protection fault. That's the type of a
> problem that kills the boot for me as well (different backtrace,
> tho).
Do you have CONFIG_RELOCATABLE and CONFIG_RANDOMIZE_BASE (KASLR)
enabled?
>>>
>>> Yes. The
On (20/02/05 10:00), John Ogness wrote:
> On 2020-02-05, Sergey Senozhatsky wrote:
> So there is a General protection fault. That's the type of a
> problem that kills the boot for me as well (different backtrace,
> tho).
> >>>
> >>> Do you have CONFIG_RELOCATABLE and CONFIG_RANDOMI
On 2020-02-05, Sergey Senozhatsky wrote:
> 3BUG: KASAN: wild-memory-access in copy_data+0x129/0x220>
> 3Write of size 4 at addr 5a5a5a5a5a5a5a5a by task cat/474>
The problem was due to an uninitialized pointer.
Very recently the ringbuffer API was expanded so that it could
optionally count lines
On 2020-02-05, lijiang wrote:
> Do you have any suggestions about the size of CONFIG_LOG_* and
> CONFIG_PRINTK_* options by default?
The new printk implementation consumes more than double the memory that
the current printk implementation requires. This is because dictionaries
and meta-data are n
On Wed, 2020-02-05 at 16:48 +0100, John Ogness wrote:
> On 2020-02-05, Sergey Senozhatsky wrote:
> > 3BUG: KASAN: wild-memory-access in copy_data+0x129/0x220>
> > 3Write of size 4 at addr 5a5a5a5a5a5a5a5a by task cat/474>
>
> The problem was due to an uninitialized pointer.
>
> Very recently the
On (20/02/05 16:48), John Ogness wrote:
> On 2020-02-05, Sergey Senozhatsky wrote:
> > 3BUG: KASAN: wild-memory-access in copy_data+0x129/0x220>
> > 3Write of size 4 at addr 5a5a5a5a5a5a5a5a by task cat/474>
>
> The problem was due to an uninitialized pointer.
>
> Very recently the ringbuffer AP
在 2020年02月05日 23:48, John Ogness 写道:
> On 2020-02-05, Sergey Senozhatsky wrote:
>> 3BUG: KASAN: wild-memory-access in copy_data+0x129/0x220>
>> 3Write of size 4 at addr 5a5a5a5a5a5a5a5a by task cat/474>
>
> The problem was due to an uninitialized pointer.
>
> Very recently the ringbuffer API was
> On 2020-02-05, lijiang wrote:
>> Do you have any suggestions about the size of CONFIG_LOG_* and
>> CONFIG_PRINTK_* options by default?
>
> The new printk implementation consumes more than double the memory that
> the current printk implementation requires. This is because dictionaries
> and met
在 2020年01月29日 00:19, John Ogness 写道:
> Hello,
>
> After several RFC series [0][1][2][3][4], here is the first set of
> patches to rework the printk subsystem. This first set of patches
> only replace the existing ringbuffer implementation. No locking is
> removed. No semantics/behavior of printk a
On Wed, 05 Feb 2020 16:48:32 +0100
John Ogness wrote:
> The quick fixup:
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index d0d24ee1d1f4..5ad67ff60cd9 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -883,6 +883,7 @@ static int devkmsg_open(struct i
On 2020-02-07, Steven Rostedt wrote:
>> The quick fixup:
>>
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index d0d24ee1d1f4..5ad67ff60cd9 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -883,6 +883,7 @@ static int devkmsg_open(struct inode *inode
On Wed 2020-02-05 17:12:12, John Ogness wrote:
> On 2020-02-05, lijiang wrote:
> > Do you have any suggestions about the size of CONFIG_LOG_* and
> > CONFIG_PRINTK_* options by default?
>
> The new printk implementation consumes more than double the memory that
> the current printk implementation
On (20/02/13 14:07), Petr Mladek wrote:
> On Wed 2020-02-05 17:12:12, John Ogness wrote:
> > On 2020-02-05, lijiang wrote:
> > > Do you have any suggestions about the size of CONFIG_LOG_* and
> > > CONFIG_PRINTK_* options by default?
> >
> > The new printk implementation consumes more than double
On Wed 2020-02-05 16:48:32, John Ogness wrote:
> On 2020-02-05, Sergey Senozhatsky wrote:
> > 3BUG: KASAN: wild-memory-access in copy_data+0x129/0x220>
> > 3Write of size 4 at addr 5a5a5a5a5a5a5a5a by task cat/474>
>
> The problem was due to an uninitialized pointer.
>
> Very recently the ringbu
On 2020-02-14, Petr Mladek wrote:
>> I oversaw that devkmsg_open() setup a printk_record and so I did not
>> see to add the extra NULL initialization of text_line_count. There
>> should be be an initializer function/macro to avoid this danger.
>>
>> John Ogness
>>
>> The quick fixup:
>>
>> diff
On Mon 2020-02-17 12:13:25, John Ogness wrote:
> On 2020-02-14, Petr Mladek wrote:
> >> I oversaw that devkmsg_open() setup a printk_record and so I did not
> >> see to add the extra NULL initialization of text_line_count. There
> >> should be be an initializer function/macro to avoid this danger.
Hi, John Ogness
Thank you for improving the patch series and making great efforts.
I'm not sure if I missed anything else. Or are there any other related patches
to be applied?
After applying this patch series, NMI watchdog detected a hard lockup, which
caused that kernel can not boot, please
On 2020-02-17, Petr Mladek wrote:
> Alternative solution would be to get rid of record_print_text()
> and use record_print_text_inline() everywhere. It will have some
> advantages:
>
> + _inline() variant will get real testing
> + no code duplication
> + saving the extra buffer also in conso
27 matches
Mail list logo
