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

From: Fabio M. Di Nitto
Date: Sat Jul 15 2017 - 01:05:54 EST


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
>