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: <cc0596ad-2cb3-2ffd-3e24-de4d034f0b84@alliedtelesis.co.nz>
Date:   Tue, 21 Mar 2023 20:16:14 +0000
From:   Chris Packham <Chris.Packham@...iedtelesis.co.nz>
To:     Mark Brown <broonie@...nel.org>,
        Mark Rutland <mark.rutland@....com>
CC:     "catalin.marinas@....com" <catalin.marinas@....com>,
        "will@...nel.org" <will@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: Support CMDLINE_EXTEND


On 22/03/23 08:06, Mark Brown wrote:
> On Tue, Mar 21, 2023 at 11:19:55AM +0000, Mark Rutland wrote:
>
>> We deliberately dropped support for CMDLINE_EXTEND in commit:
>>    cae118b6acc3 ("arm64: Drop support for CMDLINE_EXTEND")
>> ... which was mentioned the last time somone tried to re-add it:
>>    https://lore.kernel.org/linux-arm-kernel/ZAh8dWvbNkVQT11C@arm.com/
>> Has something changes such that those issues no longer apply?

I'm not sure I see any "issues" (although perhaps that's just me not 
being able to find the rest of the series on lore).

My specific use case is that I want to have the  sbsa_gwdt watchdog 
driver built-in to the kernel but I also want it to produce panic output 
instead of silently resetting the board so I want to have 
sbsa_gwdt.action=1 in my kernel command line. Either appending or 
prepending that on the command line would work for me.

>>   If so, please
>> call that out explicitly in the commit message. If not, I do not think we
>> should take this patch.

To save a click here is the relevant part from cae118b6acc3

     The documented behaviour for CMDLINE_EXTEND is that the arguments from
     the bootloader are appended to the built-in kernel command line. This
     also matches the option parsing behaviour for the EFI stub and early ID
     register overrides.

     Bizarrely, the fdt behaviour is the other way around: appending the
     built-in command line to the bootloader arguments, resulting in a
     command-line that doesn't necessarily line-up with the parsing 
order and
     definitely doesn't line-up with the documented behaviour.

This appears to be a current problem for arm an powerpc. If it weren't 
for the fact that EFI version had different behaviour I'd be suggesting 
just updating the help text. Maybe that should be done anyway regardless 
of any unification so that the documentation reflects reality.

> Given that there have been multiple attempts to readd it is it worth
> documenting this in the code?

The proposed CMDLINE_APPEND would work well for my use-case but two 
attempts at landing such generic support seem to have failed. I could 
attempt to resurrect [1] or the alternative [2] but I'm worried I'll end 
up with the same road blocks. Also looks like I just found a 3rd [3].

I hope I haven't kicked a hornets nest here.

--

[1] - 
https://lore.kernel.org/lkml/20190319232448.45964-2-danielwa@cisco.com/
[2] - 
https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1554195798.git.christophe.leroy@c-s.fr/
[3] - 
https://lore.kernel.org/lkml/20210416040924.2882771-1-danielwa@cisco.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ