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: <aSuyYXnVqPp0HGwt@MiWiFi-R3L-srv>
Date: Sun, 30 Nov 2025 10:56:33 +0800
From: Baoquan He <bhe@...hat.com>
To: Sourabh Jain <sourabhjain@...ux.ibm.com>
Cc: akpm@...ux-foundation.org, Qiang Ma <maqianga@...ontech.com>,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	shivang upadhyay <shivangu@...ux.ibm.com>
Subject: Re: [PATCH v3 0/3] kexec: print out debugging message if required
 for kexec_load

On 11/28/25 at 03:11pm, Sourabh Jain wrote:
> Hello Baoquan,
> 
> On 27/11/25 21:00, Baoquan He wrote:
> > On 11/27/25 at 05:31pm, Sourabh Jain wrote:
> > > Hello All,
> > > 
> > > Do we have plan to support KEXEC_DEBUG flag?
> > > 
> > > Because upstream kexec-tools already added support for KEXEC_DEBUG flag
> > > and that breaks the kexec_load with -d option.
> > > 
> > > - kexec: add kexec flag to support debug printing
> > >    https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/?id=71d6fd99af7e
> > I think we should revert that kexec-tools commit.
> 
> Yeah, userspace changes shouldn't go in until the kernel patches are
> finalized. It seems that there are disagreements regarding the approach
> and usefulness of this patch series, so reverting the kexec-tools patch
> might be the right thing to avoid breaking anything for now.

The patch 1 is issue fixing, that is a good one. While patch 2, 3 are
trying to add debugging printing for kexec_load interface which I think
is not needed. I added debugging printing for kexec_file_load because I
has been using 'kexec -d' to debug for kexec_load while kexec_file_load
didn't have. So I mimicked kexec_load's debugging printing to add one
for kexec_file_load. Now patch 2,3's adding doesn't make sense as he
said he is doing for future need.

> 
> I have one question: should the kernel advertise KEXEC_DEBUG so that
> backward compatibility can be maintained between the kernel and
> kexec-tools? Or is that too much for a debugging flag? How was backward
> compatibility handled when we added the KEXEC_FILE_DEBUG flag?

When I added KEXEC_FILE_DEBUG, I didn't consider backward compatibility.
That is making the then latest kernel match the then latest kexec-tools.

> 
> > This whole patchset is
> > non-sense. Because of my carelessness, that userspace patch was merged.
> > 
> > Hi Sourabh,
> > 
> > Could you go through this patchset and help check if they are really
> > needed? I can't find anything to convince myself. Thanks.
> 
> Sure I will review this patch series.

Thanks. Please check patch 2,3 to see if we really need the debugging
printing for kexec_load, or its adding really brings benefit even if
it's a little bit compared with the mess it brings; and if my objecting
is too subjective.

Thanks
Baoquan


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ