Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1687369 > unrolled thread

Re: [PATCH 0/2] Avoid crashes by early (boot) consoles using init memory

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/2] Avoid crashes by early (boot) consoles using init  memory "Fabio M. Di Nitto" <fdinitto@redhat.com> - 2017-07-14 15:00 +0200
    Re: [PATCH 0/2] Avoid crashes by early (boot) consoles using init  memory Petr Mladek <pmladek@suse.com> - 2017-07-14 16:40 +0200
      Re: [PATCH 0/2] Avoid crashes by early (boot) consoles using init  memory "Fabio M. Di Nitto" <fdinitto@redhat.com> - 2017-07-15 07:10 +0200

#1687369 — Re: [PATCH 0/2] Avoid crashes by early (boot) consoles using init memory

Hi Petr,

On 7/14/2017 2:51 PM, Petr Mladek wrote:
> Some early consoles have code and data in the init section. It makes some
> sense but this might cause problems when they are not replaced by
> the real console in time. The two patches fix the safequard and
> help to avoid the problems.
> 
> I though about removing keep_bootcon option completely. But it is useful
> at least for now.

Let´s just keep in mind that keep_bootcon was introduced only to debug
issues (read crashes or hangs) that could happen between disabling
bootconsole and enabling the real console. It shouldn´t be used for
anything else really.

If the new code can replace keep_bootcon, by all mean, go for it :-)

Cheers
Fabio

> There is not an easy way to disable a particular bootconsole
> when the related real console is installed. Instead all bootconsoles are
> removed when the preferred (last on the commandline) console is registered.
> But this is a bit cumbersome and non-intuitive.
> 
> In addition, the same problems might happen when the real console is
> registered using a deferred probe or when it is not registered at all
> for some reason.
> 
> The patchset is based on and inspired by the original patch from
> Matt Redfearn, see the discussion starting by the mail
> https://lkml.kernel.org/r/1499337481-19397-1-git-send-email-matt.redfearn@imgtec.com
> 
> Matt Redfearn (1):
>   printk/console: Always disable boot consoles that use init memory
>     before it is freed
> 
> Petr Mladek (1):
>   printk/console: Enhance the check for consoles using init memory
> 
>  kernel/printk/printk.c | 28 +++++++++++++++++-----------
>  1 file changed, 17 insertions(+), 11 deletions(-)
> 

[toc] | [next] | [standalone]

#1687479

On Fri 2017-07-14 14:57:45, Fabio M. Di Nitto wrote:
> Hi Petr,
> 
> On 7/14/2017 2:51 PM, Petr Mladek wrote:
> > Some early consoles have code and data in the init section. It makes some
> > sense but this might cause problems when they are not replaced by
> > the real console in time. The two patches fix the safequard and
> > help to avoid the problems.
> > 
> > I though about removing keep_bootcon option completely. But it is useful
> > at least for now.
> 
> Let´s just keep in mind that keep_bootcon was introduced only to debug
> issues (read crashes or hangs) that could happen between disabling
> bootconsole and enabling the real console. It shouldn´t be used for
> anything else really.

This was my initial replay as well. But then I realized that
it was a bad idea to use a freed code and data to debug any other
issue. It would just create crazy issues on its own.

I tried to google 'keep_bootcon'. It found several links to strange
crashes related to this option. Maybe I was not patient enough but
I did not find any page where this option was suggested and helped.

I still think that the option makes some sense but only when
it does not cause more breakages on its own.

> If the new code can replace keep_bootcon, by all mean, go for it :-)

keep_bootcon stays usable for most early consoles. We print a warning
when an unusable console is disabled too early. Also there is a
comment how to fix it.

Best Regards,
Petr

[toc] | [prev] | [next] | [standalone]

#1687858

On 7/14/2017 4:37 PM, Petr Mladek wrote:
> On Fri 2017-07-14 14:57:45, Fabio M. Di Nitto wrote:
>> Hi Petr,
>>
>> On 7/14/2017 2:51 PM, Petr Mladek wrote:
>>> Some early consoles have code and data in the init section. It makes some
>>> sense but this might cause problems when they are not replaced by
>>> the real console in time. The two patches fix the safequard and
>>> help to avoid the problems.
>>>
>>> I though about removing keep_bootcon option completely. But it is useful
>>> at least for now.
>>
>> Let´s just keep in mind that keep_bootcon was introduced only to debug
>> issues (read crashes or hangs) that could happen between disabling
>> bootconsole and enabling the real console. It shouldn´t be used for
>> anything else really.
> 
> This was my initial replay as well. But then I realized that
> it was a bad idea to use a freed code and data to debug any other
> issue. It would just create crazy issues on its own.

Perhaps some changes that were made later in the code introduced this
behavior. I honestly didn´t check. It´s been just so long ago :-)

> 
> I tried to google 'keep_bootcon'. It found several links to strange
> crashes related to this option. Maybe I was not patient enough but
> I did not find any page where this option was suggested and helped.

It´s in Documentation/admin-guide/kernel-parameters.txt. It´s also rare
that consoles are not working or something is crashing in that small
window, so I am not entirely surprised that there are few to none
references of users using it.

> 
> I still think that the option makes some sense but only when
> it does not cause more breakages on its own.

agreed.

Cheers
Fabio

> 
>> If the new code can replace keep_bootcon, by all mean, go for it :-)
> 
> keep_bootcon stays usable for most early consoles. We print a warning
> when an unusable console is disabled too early. Also there is a
> comment how to fix it.
> 
> Best Regards,
> Petr
> 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web