Re: Re:

[Sven Neumann]

Hi,

On Fri, 2012-12-14 at 19:39 +0530, Naresh Bhat wrote:

> I can see you have tested a patch from "Daniel Mack"
> http://lists.infradead.org/pipermail/kexec/2012-December/007526.html
> 
> Can you please help me with the following
> 
> 1. On which target it has been tested ?
> 2. Which kernel is used for testing ?
> 3. What are the --command-line arguments you have passed ?

The target is a custom hardware based on an TI AM33xx ARM Cortex A8
processor. The platform is quite similar to a Beaglebone.

We've tested with Linux 3.7-rc8.

We used

 kexec --append="`cat /proc/cmdline` " 
--dtb= --force uImage

where  is an extra boot parameter that we append to the
currently used cmdline and  is the filename of a
device-tree-blob created using dtc.


Regards,
Sven



___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Re:

[Naresh Bhat]

Hi,

The KEXEC feature is working fine on ARM cortex-a15 versatile express
target.  I have used bleeding edge kexec-tools and v3.8-rc2 kernel.

Thank you very  much for all the support and help.

Regards
-Naresh Bhat

On Fri, Dec 14, 2012 at 8:05 PM, Sven Neumann  wrote:
> Hi,
>
> On Fri, 2012-12-14 at 19:39 +0530, Naresh Bhat wrote:
>
>> I can see you have tested a patch from "Daniel Mack"
>> http://lists.infradead.org/pipermail/kexec/2012-December/007526.html
>>
>> Can you please help me with the following
>>
>> 1. On which target it has been tested ?
>> 2. Which kernel is used for testing ?
>> 3. What are the --command-line arguments you have passed ?
>
> The target is a custom hardware based on an TI AM33xx ARM Cortex A8
> processor. The platform is quite similar to a Beaglebone.
>
> We've tested with Linux 3.7-rc8.
>
> We used
>
>  kexec --append="`cat /proc/cmdline` " 
> --dtb= --force uImage
>
> where  is an extra boot parameter that we append to the
> currently used cmdline and  is the filename of a
> device-tree-blob created using dtc.
>
>
> Regards,
> Sven
>
>



-- 
"For things to change, we must change"
-Naresh Bhat

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re:

[H.A]

With profound love in my heart, I Kindly Oblige your interest to very important 
proposal.. It is Truly Divine and require your utmost attention..

S hlubokou láskou v mém srdci, Laskave jsem prinutit svuj zájem k návrhu .. Je 
velmi duležité, skutecne Divine a vyžadují vaši nejvyšší pozornost.

  Kontaktujte me prímo pres: helenarobert...@gmail.com pro úplné 
podrobnosti.complete.


HELINA .A ROBERTS

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re:

[Amos Kalonzo]

Attn:

I am wondering why You haven't respond to my email for some days now.
reference to my client's contract balance payment of (11.7M,USD)
Kindly get back to me for more details.

Best Regards

Amos Kalonzo

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re

[info]

Your e-mail has been granted £ 950,000.00 pounds in the UK British National 
Petroleum Coporation. To receive send your name: Address: Phone: Country.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE

[Gareth and Catherine]

We are donating to you the sum of £800,000.00,send your  
Name,Country,Occupation

&Phone,read-Article for info http://www.dailymail.co.uk/news/article-2091124


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE:

[Deborah Mayher]

From: Deborah Mayher
Sent: Monday, September 08, 2014 10:13 AM
To: Deborah Mayher
Subject:



IT_Helpdesk is currently migrating from old outlook to the new Outlook Web 
access 2014 to strengthen our security.  You need to update your account 
immediately for activation. Click the website below for activation:

Click Here

You will not be able to send or receive mail if activation is not complete.

IT Message Center.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re

[Centro de Noticias]

Usted tiene una transferencia de dinero de $ 85.000. Por favor confirmar la
recepcion con su nombre y su pais. Enviar por correo electronico:
wud...@w.cn


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re:

[Daniel Mack]

On 30.11.2012 14:58, Naresh Bhat wrote:
> Hi,
> 
> I am using Versatile express target at Daughterboard Site 1:
> V2P-CA15_A7 Cortex A15
> 
> root@arm-cortex-a15:~# kexec -f zImage --dtb=vexpress.dtb
> --append="root=/dev/nfs rw ip=dhcp
> nfsroot=:/mnt/sda3/nfs/cortexa15/core-image
> console=ttyAMA0,38400n8 nosmp"
> Starting new kernel
> Bye!
> Uncompressing Linux...

That could be just that the new kernel is missing its bootargs cmdline
with the appropriate console= tag. How are you booting the first kernel?
Does you bootloader add a /chosen tag?

Some suggestions:

1. Add a static CMDLINE to the second kernel, so it doesn't rely on that
information being passed from the first on.

2. Try running kexec without the --dtb option. kexec will then walk
/proc/device-tree and build up one dynamically (CONFIG_PROC_DEVICETREE
is needed for that).

3. Try passing --command-line to kexec. Note that this won't work
together with --dtb, as there's currently no code that adds the cmdline
to a dtb binary blob. But with two patches I recently submitted, it
works with the dynamic /proc/device-tree parsing mode.

4. In case you have LEDs connected to GPIOs on your board, configure
them to the heartbeat trigger mode. If that works, you know that the
kernel is actually booting, but just not showing anything on the console.

5. If 4) fails, try to toggle the GPIOs very early in the boot process,
as some sort of interface to trace the control flow, even without a JTAG.

6. In case you have CONFIG_THUMB2_KERNEL set, switch it off. I had no
luck yet booting into a kernel that was compiled in Thumb-2 mode.


Daniel


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re:

[Naresh Bhat]

Hi Sven Neumann,

I can see you have tested a patch from "Daniel Mack"
http://lists.infradead.org/pipermail/kexec/2012-December/007526.html

Can you please help me with the following

1. On which target it has been tested ?
2. Which kernel is used for testing ?
3. What are the --command-line arguments you have passed ?

I really appreciate your help.

Thanks and Regards
-Naresh Bhat

On Fri, Nov 30, 2012 at 7:57 PM, Daniel Mack  wrote:
> On 30.11.2012 14:58, Naresh Bhat wrote:
>> Hi,
>>
>> I am using Versatile express target at Daughterboard Site 1:
>> V2P-CA15_A7 Cortex A15
>>
>> root@arm-cortex-a15:~# kexec -f zImage --dtb=vexpress.dtb
>> --append="root=/dev/nfs rw ip=dhcp
>> nfsroot=:/mnt/sda3/nfs/cortexa15/core-image
>> console=ttyAMA0,38400n8 nosmp"
>> Starting new kernel
>> Bye!
>> Uncompressing Linux...
>
> That could be just that the new kernel is missing its bootargs cmdline
> with the appropriate console= tag. How are you booting the first kernel?
> Does you bootloader add a /chosen tag?
>
> Some suggestions:
>
> 1. Add a static CMDLINE to the second kernel, so it doesn't rely on that
> information being passed from the first on.
>
> 2. Try running kexec without the --dtb option. kexec will then walk
> /proc/device-tree and build up one dynamically (CONFIG_PROC_DEVICETREE
> is needed for that).
>
> 3. Try passing --command-line to kexec. Note that this won't work
> together with --dtb, as there's currently no code that adds the cmdline
> to a dtb binary blob. But with two patches I recently submitted, it
> works with the dynamic /proc/device-tree parsing mode.
>
> 4. In case you have LEDs connected to GPIOs on your board, configure
> them to the heartbeat trigger mode. If that works, you know that the
> kernel is actually booting, but just not showing anything on the console.
>
> 5. If 4) fails, try to toggle the GPIOs very early in the boot process,
> as some sort of interface to trace the control flow, even without a JTAG.
>
> 6. In case you have CONFIG_THUMB2_KERNEL set, switch it off. I had no
> luck yet booting into a kernel that was compiled in Thumb-2 mode.
>
>
> Daniel
>

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: `

[Chen Zhou]

Hi John,

On 2019/12/20 2:33, John Donnelly wrote:
> 
> 
>> On Dec 18, 2019, at 8:56 PM, Chen Zhou  wrote:
>>
>> Hi John,
>>
>> On 2019/12/19 1:18, John Donnelly wrote:
>>> HI 
>>>
>>> SEE INLINE ON A QUESTION :
>>>
 On Dec 17, 2019, at 8:07 PM, Chen Zhou  wrote:

 Hi all,

 Friendly ping...

 On 2019/8/30 15:11, Chen Zhou wrote:
> I am busy with other things, so it was a long time before this version was
> released.
>
> This patch series enable reserving crashkernel above 4G in arm64.
>
> There are following issues in arm64 kdump:
> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
> when there is no enough low memory.
> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
> in this case, if swiotlb or DMA buffers are requierd, crash dump kernel
> will boot failure because there is no low memory available for allocation.
>>>
>>>
>>>  Can you elaborate when the boot failures may fail due to lacking  
>>> swiotlb or DMA buffers ? Are these related to certain adapters or specific  
>>> platforms  ? 
>>>
>>> I have not seen this when using   crashkernel=2024M@35GB . 
>>>
>>
>> For example, in my environment "Huawei TaiShan 2280",
>> we need to use mpt3sas driver in crash dump kernel for dumping vmcore.
>>
>> mpt3sas driver needs to call dma_pool_alloc to allocate some pages,
>> if there is no DMA buffer, page allocation will fail, which leads to crash 
>> dump kernel boot failure,
>> like this:
>>
>> [2019/12/19 9:12:41] [   12.403501] mpt3sas_cm0: diag reset: SUCCESS
>> [2019/12/19 9:12:41] [   12.456076] mpt3sas_cm0: reply_post_free pool: 
>> dma_pool_alloc failed
>> [2019/12/19 9:12:41] [   12.462515] pci 0004:48:00.0: can't derive routing 
>> for PCI INT A
>> [2019/12/19 9:12:41] [   12.468761] mpt3sas 0004:49:00.0: PCI INT A: no GSI
>> [2019/12/19 9:12:41] [   12.476348] mpt3sas_cm0: failure at 
>> drivers/scsi/mpt3sas/mpt3sas_scsih.c:10626/_scsih_probe()!
>> [2019/12/19 9:14:38] [ TIME ] Timed out waiting for device 
>> dev-di…b3\x2d890a\x2d2ead7df26f48.device.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root Device.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for /sysroot.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Initrd Root File System.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for Reload Configuration 
>> from the Real Root.
>> [2019/12/19 9:14:38] [DEPEND] Dependency failed for File System 
>> C…40bae-9eb8-46b3-890a-2ead7df26f48.
> 
> 
>  Thank you for sharing .  We are not seeing this issue on a 5.4.0.rc8 ;
> Like I said in a previous email we can  take crash dumps using 
> crashkernel=768M for a  “ standard “ small VMcore to local storage :
> 
> 0004:01:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3316 
> [Intruder] (rev 01)
>   Subsystem: Broadcom / LSI MegaRAID SAS 9361-16i
>   Kernel driver in use: megaraid_sas 
> 
> 
> What version of the kernel are you using ?

5.5.0.rc1

As I said in the patch series cover-letter, this patch series address following 
cases/isssues.

There are following issues in arm64 kdump:
1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
when there is no enough low memory.
2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
in this case, if swiotlb or DMA buffers are required, crash dump kernel
will boot failure because there is no low memory available for allocation.

From your description, you use crashkernel=768M.
There are enough crashkernel below 4G, so crashkernel will be
reserved successfully and kdump be ok. （This case has no DMA buffers issue.）

or you use crashkernel=2024M@35GB, and this case is ok?
If your driver doesn't need DMA buffers(I am not sure about it), kdump will 
also be ok.


If i understand your question and explain clearly?

Thanks,
Chen Zhou

> 
> 
>>
>> Thanks,
>> Chen Zhou
>>
>>>
>
> To solve these issues, introduce crashkernel=X,low to reserve specified
> size low memory.
> Crashkernel=X tries to reserve memory for the crash dump kernel under
> 4G. If crashkernel=Y,low is specified simultaneously, reserve spcified
> size low memory for crash kdump kernel devices firstly and then reserve
> memory above 4G.
>
> When crashkernel is reserved above 4G in memory, that is, 
> crashkernel=X,low
> is specified simultaneously, kernel should reserve specified size low 
> memory
> for crash dump kernel devices. So there may be two crash kernel regions, 
> one
> is below 4G, the other is above 4G.
> In order to distinct from the high region and make no effect to the use of
> kexec-tools, rename the low region as "Crash kernel (low)", and add DT 
> property
> "linux,low-memory-range" to crash dump kernel's dtb to pass the low 
> region.
>
> Besides, we need to modify kexec-tools:
> arm64: kdump: add another DT property to crash d

Re:

[Alex Anadi]

Attention: Sir/Madam,

Compliments of the season.

I am Mr Alex Anadi a senior staff of Computer Telex Dept of central
bank of Nigeria.

I decided to contact you because of the prevailing security report
reaching my office and the intense nature of polity in Nigeria.

This is to inform you about the recent plan of federal government of
Nigeria to send your fund to you via diplomatic immunity CASH DELIVERY
SYSTEM valued at $10.6 Million United states dollars only, contact me
for further details.

Regards,
Mr Alex Anadi.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re:

[Mackenzie Scott]

Hello, 
  
I'm Mackenzie Scott Ex-wife of Amazon CEO and founder, I'm donating $ 4 billion 
Dollars to charities, individuals, colleges across the Globe from Scott's 
foundation, to provide immediate support to people suffering economically from 
COVID-19 pandemic and you're one of the lucky winners, i have a donation grant 
worth $100,800,000.00 Dollars for you, you can contact me for more information 
if you're interested.

Regards,
Mackenzie Scott.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Re: x86_64 kernel relocation question

[kevint]

* kevint <[EMAIL PROTECTED]> [2008-01-10 01:45]:


I am relatively new to kexec, and am running into some problems with
relocations when I try to use kexec to load several different X86_64
kernels.  I think this is the correct list to post to, but please  
point me

in the right direction if it isn't.

Here is some of the information on my test environment:

$ kexec --version
kexec-tools-testing 20071030 released 30th October 2007

$ uname -r
2.6.21.5


Just to make sure, is CONFIG_RELOCATABLE set?



I was a bit confused about this.  I have two kernels:  the kernel I  
want to kexec from and the one I want to kexec to.  From what I've  
read, the kernel I kexec from needs to have kexec support  
(CONFIG_KEXEC=y) and the kernel I want to kexec to needs to be  
relocatable.


It appears from:

http://lists.infradead.org/pipermail/kexec/2007-April/12.html

that this configuration option (CONFIG_RELOCATABLE) is no longer  
required.  I am going to dig around a bit more to see if I can find  
out more on how to build a relocatable x86_64 kernel.


Please correct me if I am missing something here.


$ kexec -l /tmp/vmlinuz
Unhandled rela relocation: 4258616

I noticed this line in the source file,
kexec/arch/x86_64/kexec-elf-rel-x86_64.c:

die("Unhandled rela relocation: %lu\n", reloc_name(r_type));

I figured %lu should be %s, so I changed it, and got the following  
output:


Can you make a patch and send it to this list so that it get fixed in
kexec-tools-testing? Cc Simon Horman <[EMAIL PROTECTED]>, the
maintainer.




Sent patch in previous message.



Bernhard



--


Thanks again!


Kevin Tegtmeier
HPC-3 Scientific Computing Resources
Los Alamos National Laboratory
email:  [EMAIL PROTECTED]
phone: 505.667.3488




___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Fwd: RE: Fwd: Re: makedumpfile security key enhancement using SIAL

[Aravinda Prasad]

Hi Luc,

Could you please let us know by when you are planning to create the
project and associated git for SIAL? Right now we are extracting
libsial from the crash tar ball and using it.

Regards,
Aravinda

On Wednesday 28 March 2012 10:30 PM, Aravinda Prasad wrote:

Thanks Luc. We will let you know if in case we need any info/help.

I am also forwarding this mail to kexec mailing list.

Regards,
Aravinda


 Original Message 
Subject: RE: Fwd: Re: makedumpfile security key enhancement using SIAL
Date: Wed, 28 Mar 2012 07:07:49 -0400
From: Luc Chouinard 
To: Aravinda Prasad 

Libsial is meant to be a pluggable entity and as such should not require
other pieces to be there ( crash or gdb).
I want to create project and associated git for the library soon. For
now you can extract libsial from the crash tar ball and manage any
modifications using a simple patch mechanism. When the git is available,
we can merge any fixes or enhancements you created for support of
makedumpfile.

Makedumpfile and crash would then feed off of specific branches/versions
of the git repository.
If you have any suggestions or want to help in setting up a public git /
project page for sial, please let me know.


-Luc


-Original Message-
From: Aravinda Prasad [mailto:aravi...@linux.vnet.ibm.com]
Sent: Wednesday, March 28, 2012 1:31 AM
To: Luc Chouinard
Subject: Fwd: Fwd: Re: makedumpfile security key enhancement using SIAL

Forwarding to your s2sys email ID. Details in mail forward.

Regards,
Aravinda


 Original Message 
Subject: Fwd: Re: makedumpfile security key enhancement using SIAL
Date: Tue, 20 Mar 2012 17:28:21 +0530
From: Aravinda Prasad 
To: Luc Chouinard 
CC: Atsushi Kumagai , Masaki Tachibana
, Mahesh J Salgaonkar
, Ananth N Mavinakayanahalli
, Dave Anderson 

Hi Luc,

We are looking for utilising SIAL as a language construct for the
makedumpfile
kernel data filtering from vmcore feature. The details of which are in
the mail
forward.

The proposed enhancement will require libsial.a and as SIAL is not
currently
built/shipped, we are looking for possibilities on how libsial.a can
be made
available to makedumpfile. Please let us know your opinion on the same.

Regards,
Aravinda


 Original Message 
Subject: Re: makedumpfile security key enhancement using SIAL
Date: Tue, 13 Mar 2012 10:27:43 -0400 (EDT)
From: Dave Anderson 
To: Aravinda Prasad 
CC: Atsushi Kumagai , Masaki
Tachibana , Ananth N
Mavinakayanahalli , Mahesh J Salgaonkar




- Original Message -
> Hi Dave,
>
> Last year, we worked on the makedumpfile security key filtering where
> we added support to filter out kernel data from vmcore. This year, we
> are working on enhancing the framework to provide more flexibility for
> the customers to specify rules to traverse and filter out kernel data
> - for which we are planning to use SIAL.
>
> We are looking into using SIAL as language construct to specify
> rules/commands to erase data in the image file. The makedumpfile would
> interpret the rules provided in SIAL macro using SIAL library (which
> could be dynamically loaded) and erase out suitable data in the vmcore.
> We are planning to reuse SIAL as it provides a C language like
> construct, which is flexible and powerful enough to specify rules to
> erase data in vmcore.
>
> As SIAL is not built and shipped along with crash, we are looking for
> possibilities on how SIAL can be leveraged by makedumpfile and would
> like to know your opinion.

Sorry but I cannot give you any help with SIAL. Luc Chouinard is the
maintainer
of the SIAL extension module adaptation for the crash utility, and he
can answer
your questions w/respect to adapting it for makedumpfile.
And ultimately, that's a question for the makedumpfile maintainers.

Dave





___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: Fwd: RE: Fwd: Re: makedumpfile security key enhancement using SIAL

[Luc Chouinard]

My hope  is to have something available 2 weeks from now. No promises - I have 
a few  critical deliveries to take care here @ s2 first.
First step is to finish off some significant  fixes and enhancements to the 
compiler (like the support for typeof() and typed symbols) which will make it 
possible to include and use what I now found to be pervasive macros like 
hlist_for_each_entry_rcu(), offsetof(), container_of() as-is.

  -Luc

> -Original Message-
> From: Aravinda Prasad [mailto:aravi...@linux.vnet.ibm.com]
> Sent: Tuesday, April 03, 2012 7:42 AM
> To: Luc Chouinard
> Cc: kexec@lists.infradead.org; Ananth N Mavinakayanahalli; Mahesh J
> Salgaonkar; Masaki Tachibana; Atsushi Kumagai; David Anderson
> Subject: Re: Fwd: RE: Fwd: Re: makedumpfile security key enhancement using
> SIAL
> 
> Hi Luc,
> 
> Could you please let us know by when you are planning to create the project 
> and
> associated git for SIAL? Right now we are extracting libsial from the crash 
> tar
> ball and using it.
> 
> Regards,
> Aravinda
> 
> On Wednesday 28 March 2012 10:30 PM, Aravinda Prasad wrote:
> > Thanks Luc. We will let you know if in case we need any info/help.
> >
> > I am also forwarding this mail to kexec mailing list.
> >
> > Regards,
> > Aravinda
> >
> >
> >  Original Message 
> > Subject: RE: Fwd: Re: makedumpfile security key enhancement using SIAL
> > Date: Wed, 28 Mar 2012 07:07:49 -0400
> > From: Luc Chouinard 
> > To: Aravinda Prasad 
> >
> > Libsial is meant to be a pluggable entity and as such should not
> > require other pieces to be there ( crash or gdb).
> > I want to create project and associated git for the library soon. For
> > now you can extract libsial from the crash tar ball and manage any
> > modifications using a simple patch mechanism. When the git is
> > available, we can merge any fixes or enhancements you created for
> > support of makedumpfile.
> >
> > Makedumpfile and crash would then feed off of specific
> > branches/versions of the git repository.
> > If you have any suggestions or want to help in setting up a public git
> > / project page for sial, please let me know.
> >
> >
> > -Luc
> >
> >> -Original Message-
> >> From: Aravinda Prasad [mailto:aravi...@linux.vnet.ibm.com]
> >> Sent: Wednesday, March 28, 2012 1:31 AM
> >> To: Luc Chouinard
> >> Subject: Fwd: Fwd: Re: makedumpfile security key enhancement using
> >> SIAL
> >>
> >> Forwarding to your s2sys email ID. Details in mail forward.
> >>
> >> Regards,
> >> Aravinda
> >>
> >>
> >>  Original Message 
> >> Subject: Fwd: Re: makedumpfile security key enhancement using SIAL
> >> Date: Tue, 20 Mar 2012 17:28:21 +0530
> >> From: Aravinda Prasad 
> >> To: Luc Chouinard 
> >> CC: Atsushi Kumagai , Masaki
> >> Tachibana , Mahesh J Salgaonkar
> >> , Ananth N Mavinakayanahalli
> >> , Dave Anderson 
> >>
> >> Hi Luc,
> >>
> >> We are looking for utilising SIAL as a language construct for the
> >> makedumpfile kernel data filtering from vmcore feature. The details
> >> of which are in the mail forward.
> >>
> >> The proposed enhancement will require libsial.a and as SIAL is not
> >> currently built/shipped, we are looking for possibilities on how
> >> libsial.a can be made available to makedumpfile. Please let us know
> >> your opinion on the same.
> >>
> >> Regards,
> >> Aravinda
> >>
> >>
> >>  Original Message 
> >> Subject: Re: makedumpfile security key enhancement using SIAL
> >> Date: Tue, 13 Mar 2012 10:27:43 -0400 (EDT)
> >> From: Dave Anderson 
> >> To: Aravinda Prasad 
> >> CC: Atsushi Kumagai , Masaki
> >> Tachibana , Ananth N Mavinakayanahalli
> >> , Mahesh J Salgaonkar 
> >>
> >>
> >>
> >> - Original Message -
> >> > Hi Dave,
> >> >
> >> > Last year, we worked on the makedumpfile security key filtering
> >> > where we added support to filter out kernel data from vmcore. This
> >> > year, we are working on enhancing the framework to provide more
> >> > flexibility for the customers to specify rules to traverse and
> >> > filter out kernel data
> >> > - for which we are planning to use SIAL.
> >> >
> >> > We are looking into using SIAL as language construct

Re: Re: [PATCH V4] kernel, add bug_on_warn

[Masami Hiramatsu]

(2014/10/28 3:15), Prarit Bhargava wrote:
> 
> 
> On 10/27/2014 02:05 PM, Jason Baron wrote:
>> Hi Prarit,
>>
>> On 10/24/2014 08:53 AM, Prarit Bhargava wrote:
>>> There have been several times where I have had to rebuild a kernel to
>>> cause a panic when hitting a WARN() in the code in order to get a crash
>>> dump from a system.  Sometimes this is easy to do, other times (such as
>>> in the case of a remote admin) it is not trivial to send new images to the
>>> user.panic_on_stackoverflow
>>>
>>> A much easier method would be a switch to change the WARN() over to a
>>> BUG().  This makes debugging easier in that I can now test the actual
>>> image the WARN() was seen on and I do not have to engage in remote
>>> debugging.
>>>
>>> This patch adds a bug_on_warn kernel parameter and
>>> /proc/sys/kernel/bug_on_warn calls BUG() in the warn_slowpath_common()
>>> path.  The function will still print out the location of the warning.
>>>
>>> An example of the bug_on_warn output:
>>>
>>> The first line below is from the WARN_ON() to output the WARN_ON()'s 
>>> location.
>>> After that the new BUG() call is displayed.
>>>
>>>  WARNING: CPU: 27 PID: 3204 at
>>> /home/rhel7/redhat/debug/dummy-module/dummy-module.c:25 init_dummy+0x28/0x30
>>> [dummy_module]()
>>>  bug_on_warn set, calling BUG()...
>>>  [ cut here ]
>>>  kernel BUG at kernel/panic.c:434!
>>
>> Seems reasonable-I'm wondering why you just don't call panic() in this
>> case. The BUG() call at line '434' doesn't at anything since its just being
>> called from panic.c.

+1, I like calling panic() instead of BUG() :)

Thank you,

> 
> Hmm ... I didn't even think about that.
> 
>>
>> So something like 'panic_on_warn' would seem to be more appropriate
>> in keeping with things like 'panic_on_oops' or 'panic_on_stackoverflow'.
> 
> I like it a lot better that way too :)  I'm changing it to panic_on_warn 
> unless
> anyone has any strenuous objections.
> 
> P.
> 
>>
>> Thanks,
>>
>> -Jason
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com



___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Re: kexec: Overlapping memory segments error

[wille]

Yes, the git tree, which I built, includes your patch:
  kexec: fix /sys/firmware/memmap memory range overlaps

I thought this patch would fix my problem, but it didn't seem to help.  
Perhaps the list of memory ranges gets added to after 
fixup_memory_ranges_sysfs() is called.  Could the --initrd option do this?  
I wonder, because the error disappears when I don't include the 
kexec --initrd option.

-wille

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

***~~BULK~~*** Re:

[Maria Reyes]

Your email won €4,000,000.00 El Gordo (First Prize) in the End of year Spanish 
Christmas Lottery Bonanza 2016 (Lotería de Navidad). Contact 
spanishlottery2...@rogers.com to claim.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: ATTENTION!!!

[Loretta Robles]

From: Loretta Robles
Sent: Friday, December 29, 2017 1:01 PM
To: Loretta Robles
Subject: ATTENTION!!!

You have been randomly selected for a donation. Contact soriz4...@gmail.com for 
claims.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: hello

[Azzam Yuan]

--
Good day Valued Customers, Have  you been going through some financial crisis?
Then here is the time for you to live above your financial crisis by  
writing to:
azzam.1loanfir...@gmail.com so that we can enlighten and empower you  
in the area

of finances. Here you will obtain a loan to start up your own business or even
upgrade your present business if you are into one already. For more  
information
just write to us in the email address above and below:  
azzam.1loanfir...@gmail.com







___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: XenDump

[Itsuro ODA]

Hi,

dom0cut is obsolate.
crash command can use a vmcore directly for both dom-0 and
hypervisor analysis.
You can use makedumpfile command to reduce the size of a vmcore.
It can select only dom-0 and hypervisor part.

Thanks.

On Tue, 18 Sep 2007 15:11:28 +0200
Bernhard Walle <[EMAIL PROTECTED]> wrote:

> Hello,
> 
> does somebody know where the software from
> http://wiki.xensource.com/xenwiki/XenKdumpAnalysis is available now?
> Only dead links ...
> 
> 
> Thanks,
>Bernhard
> 
> 
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

-- 
Itsuro ODA <[EMAIL PROTECTED]>


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: reloc_name

[Simon Horman]

On Tue, Jan 15, 2008 at 05:53:19PM -0700, kevint wrote:
> This isn't a high priority issue- just something I am looking at in my 
> spare time.  I would appreciate any advice you can provide.
>
> I am looking through some of the kexec elf relocation code, and noticed 
> that reloc_name is only defined for x86_64.  I started writing this 
> function for the other architectures, but noticed that some of the other 
> architectures do not have contiguous r_type numbers (from include/elf.h). 
>  In the x86_64 reloc_name code, r_name is an array of strings with all of 
> the relocation names.  I can't (AFAIK) use a similar approach to 
> architectures with non-contiguous r_type numbers.
>
> My questions:
>
> Is it valuable to print out the relocation type as a string?  (I  
> personally find it helpful)
>
> If so, should the reloc_name function still reside in the kexec-elf- 
> rel-$ARCH.c file?  There are 81 IA64 relocations, which make the file  
> considerably longer.
>
> If not, should there be consistency between the different architectures 
> with regards to these types of error messages?  Should the X86_64 file 
> print out the r_type instead of the string?

I also noticed this when I applied your patch to pront out r_string on
x86_64. I'm all in favour of consistency. Though I think its ok
to have an r_type and an r_string version, where the latter can
be viewd as the aim for arhitectures that use the former.

As for bloating rel-$ARCH.c, I don't think that is much of
a problem if there is no existing header to use.

-- 
Horms


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [ARM]

[SUNDEEP BORRA]

Dear Eric,

I got the Apt sources for ARM-KEXEC from Simon Horman. As I claimed before, 
neither the purgatory nor the testing code of the repository till date has got 
only dummy functions and no ARM specific code is ready. The one I got from 
Simon Horman, maintaining it with all updates to all architectures, is working 
fine.

It is at ftp://ftp.kernel.org/pub/linux/kernel/people/horms/kexec-tools/

Thanks for your response,

Regards,
Sundeep Borra



___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] kexec: remove some re zero-assignment

[Simon Horman]

On Sat, Nov 29, 2014 at 08:45:32AM +0800, HuKeping wrote:
> since we have already cleared kexec_info with memset,
> there is no need to do that again to the struct members.
> 
> Signed-off-by: Hu Keping 

Thanks, applied.

> ---
>  kexec/kexec.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/kexec/kexec.c b/kexec/kexec.c
> index a5e78c6..b088916 100644
> --- a/kexec/kexec.c
> +++ b/kexec/kexec.c
> @@ -662,10 +662,6 @@ static int my_load(const char *type, int fileind, int 
> argc, char **argv,
>   int guess_only = 0;
>  
>   memset(&info, 0, sizeof(info));
> - info.segment = NULL;
> - info.nr_segments = 0;
> - info.entry = NULL;
> - info.backup_start = 0;
>   info.kexec_flags = kexec_flags;
>  
>   result = 0;
> -- 
> 1.8.5.5
> 
> 
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Question re: mem= usage and resultant vmcore

[Vivek Goyal]

On Wed, Aug 01, 2007 at 12:29:59PM -0400, Dave Anderson wrote:
> 
> On an 4GB x86_64 kernel, with memory restricted with "mem=" like so:
> 
>kernel /vmlinuz-2.6.18-36.el5 ro root=/dev/VolGroup00/LogVol00
>console=ttyS0,115200 mem=2000m [EMAIL PROTECTED]
> 
> The secondary kernel boots fine with this:
> 
>Kernel command line: ro root=/dev/VolGroup00/LogVol00 console=ttyS0,115200
>mem=2000m  irqpoll maxcpus=1 memmap=exactmap [EMAIL PROTECTED]
>[EMAIL PROTECTED] [EMAIL PROTECTED] elfcorehdr=147440K
>memmap=76K#3406720K memmap=564K#3406796K
> 
> The /proc/vmcore shows 4GB:
> 
># ls -l /proc/vmcore
>-r 1 root root 4164192032 Aug  1 10:57 /proc/vmcore
>#
> 
> I'm not sure whether that's supposed to reflect the "mem=2000m" size
> or not?
> 

Hi Dave,

/proc/iomem on i386 and x86_64 behave differently when passed with mem=
parameter. I think on i386, only memory specified by mem= is visible but
in case of x86_64, all the memory passed by BIOS to kernel is visible.

Kexec/kdump retrieve the physical memory info from /proc/iomem. We need
both the behaviours for two scenarios.

- For kexec, we want to see whole of the memory (irrespective of the fact
  how much current kernel is using), so that next kernel can potentially
  use all the memory to boot in.

- For kdump, we want to know about only the physical memory current kernel
  is using and not all the memory system has.

Here the issue is that despite the fact you have passed mem=2000m, /proc/iomem
will show 4G physical memory and kdump will create elf header for 4G of 
memory. That's why /proc/vmcore size is 4G. I am not sure why it did not
copy whole 4G on disk and stoppped after 2000m. To me it should have copied
whole of the 4G.

Bottom line, we need to do some work in this area.

- Make /proc/iomem behaviour consistent across i386 and x86_64. I think
  it can be changed to reflect the physical memory currently used by 
  kernel (based on mem=) parameter.

- Create another /proc interface, lets say /proc/physmem, which will reflect
  all the physical memory system has, irrespective of the fact what is being
  used by the kernel.

In this case kexec can make use of /proc/physmem and kdump can make use
of /proc/iomem and things will be fine.

Anybody interested in writing patches for this?

Thanks
Vivek

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Question re: mem= usage and resultant vmcore

[Dave Anderson]

Vivek Goyal wrote:
> On Wed, Aug 01, 2007 at 12:29:59PM -0400, Dave Anderson wrote:
> 
>>On an 4GB x86_64 kernel, with memory restricted with "mem=" like so:
>>
>>   kernel /vmlinuz-2.6.18-36.el5 ro root=/dev/VolGroup00/LogVol00
>>   console=ttyS0,115200 mem=2000m [EMAIL PROTECTED]
>>
>>The secondary kernel boots fine with this:
>>
>>   Kernel command line: ro root=/dev/VolGroup00/LogVol00 console=ttyS0,115200
>>   mem=2000m  irqpoll maxcpus=1 memmap=exactmap [EMAIL PROTECTED]
>>   [EMAIL PROTECTED] [EMAIL PROTECTED] elfcorehdr=147440K
>>   memmap=76K#3406720K memmap=564K#3406796K
>>
>>The /proc/vmcore shows 4GB:
>>
>>   # ls -l /proc/vmcore
>>   -r 1 root root 4164192032 Aug  1 10:57 /proc/vmcore
>>   #
>>
>>I'm not sure whether that's supposed to reflect the "mem=2000m" size
>>or not?
>>
> 
> 
> Hi Dave,
> 
> /proc/iomem on i386 and x86_64 behave differently when passed with mem=
> parameter. I think on i386, only memory specified by mem= is visible but
> in case of x86_64, all the memory passed by BIOS to kernel is visible.
> 
> Kexec/kdump retrieve the physical memory info from /proc/iomem. We need
> both the behaviours for two scenarios.
> 
> - For kexec, we want to see whole of the memory (irrespective of the fact
>   how much current kernel is using), so that next kernel can potentially
>   use all the memory to boot in.
> 
> - For kdump, we want to know about only the physical memory current kernel
>   is using and not all the memory system has.
> 
> Here the issue is that despite the fact you have passed mem=2000m, /proc/iomem
> will show 4G physical memory and kdump will create elf header for 4G of 
> memory. That's why /proc/vmcore size is 4G. I am not sure why it did not
> copy whole 4G on disk and stoppped after 2000m. To me it should have copied
> whole of the 4G.

Yeah -- I haven't verified it, but I'm guessing that read_vmcore()
fails due to its call to map_offset_to_paddr(), which doesn't
find the physical memory beyond 2000m in the vmcore_list?

Interestingly enough, this may never have been noticed except for
the save_core() function in the /etc/init.d/kdump file in Red Hat's
kexec-tools package:

function save_core()
{
 coredir="/var/crash/`date +"%Y-%m-%d-%H:%M"`"

 mkdir -p $coredir
 cp /proc/vmcore $coredir/vmcore-incomplete
 exitcode=$?
 if [ $exitcode == 0 ]; then
 mv $coredir/vmcore-incomplete $coredir/vmcore
 $LOGGER "saved a vmcore to $coredir"
 else
 $LOGGER "failed to save a vmcore to $coredir"
 fi
 return $exitcode
}

And even though the ELF header reflects the 4GB memory size,
the vmcore-incomplete file is "complete" w/respect to the
primary kernel.  In other words, even though the ELF header
advertises non-existent physical memory beyond the 2000m
limit, there's never a need to access it from the crash utility,
so it's kind of a benign bug.

Dave


> 
> Bottom line, we need to do some work in this area.
> 
> - Make /proc/iomem behaviour consistent across i386 and x86_64. I think
>   it can be changed to reflect the physical memory currently used by 
>   kernel (based on mem=) parameter.
> 
> - Create another /proc interface, lets say /proc/physmem, which will reflect
>   all the physical memory system has, irrespective of the fact what is being
>   used by the kernel.
> 
> In this case kexec can make use of /proc/physmem and kdump can make use
> of /proc/iomem and things will be fine.
> 
> Anybody interested in writing patches for this?
> 
> Thanks
> Vivek



___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Fwd: Re: makedumpfile security key enhancement using SIAL

[Atsushi Kumagai]

Hello Aravinda,

I have two questions, could you answer me ?

First, what problems do you have about the current format of makedumpfile.conf ?
Second, what benefits do you expect from using SIAL ? I can't imagine 
specific benefits with using SIAL now.

By the way, could you add kexec-ML to CC field from next time ?

  kexec mailing list:
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


Thanks
Atsushi Kumagai


On Tue, 20 Mar 2012 17:28:21 +0530
Aravinda Prasad  wrote:

> Hi Luc,
> 
> We are looking for utilising SIAL as a language construct for the 
> makedumpfile kernel data filtering from vmcore feature. The details of 
> which are in the mail forward.
> 
> The proposed enhancement will require libsial.a and as SIAL is not 
> currently built/shipped, we are looking for possibilities on how 
> libsial.a can be made available to makedumpfile. Please let us know your 
> opinion on the same.
> 
> Regards,
> Aravinda
> 
> 
>  Original Message 
> Subject: Re: makedumpfile security key enhancement using SIAL
> Date: Tue, 13 Mar 2012 10:27:43 -0400 (EDT)
> From: Dave Anderson 
> To: Aravinda Prasad 
> CC: Atsushi Kumagai , Masaki 
> Tachibana ,Ananth N 
> Mavinakayanahalli ,Mahesh J Salgaonkar 
> 
> 
> 
> 
> - Original Message -
> > Hi Dave,
> >
> > Last year, we worked on the makedumpfile security key filtering where we
> > added support to filter out kernel data from vmcore. This year, we are
> > working on enhancing the framework to provide more flexibility for the
> > customers to specify rules to traverse and filter out kernel data - for
> > which we are planning to use SIAL.
> >
> > We are looking into using SIAL as language construct to specify
> > rules/commands to erase data in the image file. The makedumpfile would
> > interpret the rules provided in SIAL macro using SIAL library (which
> > could be dynamically loaded) and erase out suitable data in the vmcore.
> > We are planning to reuse SIAL as it provides a C language like
> > construct, which is flexible and powerful enough to specify rules to
> > erase data in vmcore.
> >
> > As SIAL is not built and shipped along with crash, we are looking for
> > possibilities on how SIAL can be leveraged by makedumpfile and would
> > like to know your opinion.
> 
> Sorry but I cannot give you any help with SIAL.  Luc Chouinard is the
> maintainer of the SIAL extension module adaptation for the crash utility,
> and he can answer your questions w/respect to adapting it for makedumpfile.
> And ultimately, that's a question for the makedumpfile maintainers.
> 
> Dave

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Fwd: Re: makedumpfile security key enhancement using SIAL

[Aravinda Prasad]

On Wednesday 21 March 2012 12:13 PM, Atsushi Kumagai wrote:

Hello Aravinda,

I have two questions, could you answer me ?

First, what problems do you have about the current format of makedumpfile.conf ?


Even though makedumpfile.conf is capable of filtering out data from the
vmocore, it is not possible to specify and erase complex
data-structures. For example it is not possible to traverse a nested
list or a tree and then erase a particular node based on some
conditions. Extending makedumpfile.conf to support these would require
implementing a lot of language constructs. But we can reuse SIAL
instead of extending makedumpfile.conf.


Second, what benefits do you expect from using SIAL ? I can't imagine
specific benefits with using SIAL now.


SIAL can be used as a language construct to specify rules/commands to
erase data in the image file. The makedumpfile would interpret the
rules/commands provided by SIAL macros with the help of SIAL library
and would suitably erase the required data in the dump file. As SIAL
provides a lot of language constructs like conditional statements,
logical and arithmetic operators, nested loops, functions etc, it would
be possible to traverse nested lists and trees and conditionally erase
data in the dump file, enabling users to literally erase any data in
the dump file.



By the way, could you add kexec-ML to CC field from next time ?


Included.



   kexec mailing list:
 kexec@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/kexec


Thanks
Atsushi Kumagai


On Tue, 20 Mar 2012 17:28:21 +0530
Aravinda Prasad  wrote:


Hi Luc,

We are looking for utilising SIAL as a language construct for the
makedumpfile kernel data filtering from vmcore feature. The details of
which are in the mail forward.

The proposed enhancement will require libsial.a and as SIAL is not
currently built/shipped, we are looking for possibilities on how
libsial.a can be made available to makedumpfile. Please let us know your
opinion on the same.

Regards,
Aravinda


 Original Message 
Subject: Re: makedumpfile security key enhancement using SIAL
Date: Tue, 13 Mar 2012 10:27:43 -0400 (EDT)
From: Dave Anderson
To: Aravinda Prasad
CC: Atsushi Kumagai, Masaki
Tachibana,Ananth N
Mavinakayanahalli,Mahesh J Salgaonkar




- Original Message -

Hi Dave,

Last year, we worked on the makedumpfile security key filtering where we
added support to filter out kernel data from vmcore. This year, we are
working on enhancing the framework to provide more flexibility for the
customers to specify rules to traverse and filter out kernel data - for
which we are planning to use SIAL.

We are looking into using SIAL as language construct to specify
rules/commands to erase data in the image file. The makedumpfile would
interpret the rules provided in SIAL macro using SIAL library (which
could be dynamically loaded) and erase out suitable data in the vmcore.
We are planning to reuse SIAL as it provides a C language like
construct, which is flexible and powerful enough to specify rules to
erase data in vmcore.

As SIAL is not built and shipped along with crash, we are looking for
possibilities on how SIAL can be leveraged by makedumpfile and would
like to know your opinion.


Sorry but I cannot give you any help with SIAL.  Luc Chouinard is the
maintainer of the SIAL extension module adaptation for the crash utility,
and he can answer your questions w/respect to adapting it for makedumpfile.
And ultimately, that's a question for the makedumpfile maintainers.

Dave


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


Regards,
Aravinda


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Fwd: Re: makedumpfile security key enhancement using SIAL

[Atsushi Kumagai]

Hello Aravinda,

On Thu, 22 Mar 2012 22:56:30 +0530
Aravinda Prasad  wrote:

> On Wednesday 21 March 2012 12:13 PM, Atsushi Kumagai wrote:
> > Hello Aravinda,
> >
> > I have two questions, could you answer me ?
> >
> > First, what problems do you have about the current format of 
> > makedumpfile.conf ?
> 
> Even though makedumpfile.conf is capable of filtering out data from the
> vmocore, it is not possible to specify and erase complex
> data-structures. For example it is not possible to traverse a nested
> list or a tree and then erase a particular node based on some
> conditions. Extending makedumpfile.conf to support these would require
> implementing a lot of language constructs. But we can reuse SIAL
> instead of extending makedumpfile.conf.
> 
> > Second, what benefits do you expect from using SIAL ? I can't imagine
> > specific benefits with using SIAL now.
> 
> SIAL can be used as a language construct to specify rules/commands to
> erase data in the image file. The makedumpfile would interpret the
> rules/commands provided by SIAL macros with the help of SIAL library
> and would suitably erase the required data in the dump file. As SIAL
> provides a lot of language constructs like conditional statements,
> logical and arithmetic operators, nested loops, functions etc, it would
> be possible to traverse nested lists and trees and conditionally erase
> data in the dump file, enabling users to literally erase any data in
> the dump file.

Thank you for your explanation.
It seems good to specify rules with SIAL.

If makedumpfile uses SIAL library, I will discard the current format of 
makedumpfile.conf to reduce the size of source code.
What do you think about it ?


Thanks
Atsushi Kumagai

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Fwd: Re: makedumpfile security key enhancement using SIAL

[Aravinda Prasad]

Hello Kumagai-san,

On Friday 30 March 2012 08:32 AM, Atsushi Kumagai wrote:

Hello Aravinda,

On Thu, 22 Mar 2012 22:56:30 +0530
Aravinda Prasad  wrote:


On Wednesday 21 March 2012 12:13 PM, Atsushi Kumagai wrote:

Hello Aravinda,

I have two questions, could you answer me ?

First, what problems do you have about the current format of makedumpfile.conf ?


Even though makedumpfile.conf is capable of filtering out data from the
vmocore, it is not possible to specify and erase complex
data-structures. For example it is not possible to traverse a nested
list or a tree and then erase a particular node based on some
conditions. Extending makedumpfile.conf to support these would require
implementing a lot of language constructs. But we can reuse SIAL
instead of extending makedumpfile.conf.


Second, what benefits do you expect from using SIAL ? I can't imagine
specific benefits with using SIAL now.


SIAL can be used as a language construct to specify rules/commands to
erase data in the image file. The makedumpfile would interpret the
rules/commands provided by SIAL macros with the help of SIAL library
and would suitably erase the required data in the dump file. As SIAL
provides a lot of language constructs like conditional statements,
logical and arithmetic operators, nested loops, functions etc, it would
be possible to traverse nested lists and trees and conditionally erase
data in the dump file, enabling users to literally erase any data in
the dump file.


Thank you for your explanation.
It seems good to specify rules with SIAL.

If makedumpfile uses SIAL library, I will discard the current format of
makedumpfile.conf to reduce the size of source code.
What do you think about it ?



I will come up with a prototype for integrating SIAL with makedumpfile
and then we can discuss whether to discard the existing
makedumpfile.conf format or not. Because the planned makedumpfile
enhancement with SIAL could use some infrastructure provided by
existing implementation like code to erase data in dump file and also
the makedumpfile.conf file can be used to specify SIAL macros.

Regards,
Aravinda



Thanks
Atsushi Kumagai




___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [External] RE: Makedumpfile compile errors on Debian 10

[Jiang Wang .]

Hi Kazu,

I see. I will post a patch for this. I will try 1.6.8 to see if it
works for me or not. Thanks for the info.

Regards,

Jiang

On Thu, Jan 28, 2021 at 8:43 PM HAGIO KAZUHITO(萩尾　一仁)
 wrote:
>
> Hi Jiang,
>
> -Original Message-
> > Hi there,
> >
> > I tried to compile version 1.6.7 and master on Debian 10 and got
> > following error:
> >
> > root@gitlab-runner-stretch:/home/gitlab-runner/makedumpfile-master# make
> > cc  -g -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> > -D_LARGEFILE64_SOURCE -DVERSION='"1.6.8++"' -DRELEASE_DATE='"16 Nov
> > 2020"' -D__x86_64__   print_info.
> > o dwarf_info.o elf_info.o erase_info.o sadump_info.o cache.o tools.o
> > printk.o arch/arm.o arch/arm64.o arch/x86.o arch/x86_64.o arch/ia64.o
> > arch/ppc64.o arch/s390
> > x.o arch/ppc.o arch/sparc64.o -rdynamic -o makedumpfile makedumpfile.c
> > -lpthread -static -ldw -lbz2 -ldl -lelf -lz -llzma  -lebl
> > /usr/bin/ld: erase_info.o: in function `process_eppic_file':
> > /home/gitlab-runner/makedumpfile-master/erase_info.c:2202: warning:
> > Using 'dlopen' in statically linked applications requires at runtime
> > the shared libraries fro
> > m the glibc version used for linking
> > /usr/bin/ld: //usr/local/lib/libdw.a(dwarf_abbrev_hash.o): in function
> > `Dwarf_Abbrev_Hash_insert':
> > /home/gitlab-runner/elfutils-0.182/libdw/../lib/dynamicsizehash_concurrent.c:394:
> > undefined reference to `pthread_rwlock_tryrdlock'
> > /usr/bin/ld: 
> > /home/gitlab-runner/elfutils-0.182/libdw/../lib/dynamicsizehash_concurrent.c:394:
> > undefined reference to `pthread_rwlock_tryrdlock'
> > /usr/bin/ld: 
> > /home/gitlab-runner/elfutils-0.182/libdw/../lib/dynamicsizehash_concurrent.c:394:
> > undefined reference to `pthread_rwlock_tryrdlock'
> > /usr/bin/ld: //usr/local/lib/libdw.a(dwarf_abbrev_hash.o): in function
> > `Dwarf_Abbrev_Hash_find':
> > /home/gitlab-runner/elfutils-0.182/libdw/../lib/dynamicsizehash_concurrent.c:461:
> > undefined reference to `pthread_rwlock_tryrdlock'
> > /usr/bin/ld: //usr/local/lib/libdw.a(dwarf_sig8_hash.o): in function
> > `Dwarf_Sig8_Hash_insert':
> > /home/gitlab-runner/elfutils-0.182/libdw/../lib/dynamicsizehash_concurrent.c:394:
> > undefined reference to `pthread_rwlock_tryrdlock'
> > /usr/bin/ld:
> > //usr/local/lib/libdw.a(dwarf_sig8_hash.o):/home/gitlab-runner/elfutils-0.182/libdw/../lib/dynamicsize
> > hash_concurrent.c:394:
> > more undefined referenc
> > es to `pthread_rwlock_tryrdlock' follow
> > collect2: error: ld returned 1 exit status
> > make: *** [Makefile:100: makedumpfile] Error 1
> > To fix it, I have to make the following change:
> > diff --git a/Makefile b/Makefile
> > index 388faf7..7006f81 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -65,7 +65,7 @@ LIBS := -lsnappy $(LIBS)
> >  CFLAGS += -DUSESNAPPY
> >  endif
> >
> > -LIBS := -lpthread $(LIBS)
> > +LIBS := $(LIBS) -lpthread
> >
> >  try-run = $(shell set -e;  \
> > TMP="..tmp";\
> > Not sure if it is an issue of Debian or makedumpfile. If it is the
> > latter, please fix the Makefile. Thanks.
>
> Thanks for the report.
>
> I'm not sure why it doesn't occur on my recent Fedora machine with
> elfutils-0.182, but seems that -lpthread should be put after -ldw, so
> the change looks good to me.
>
> Would you post a formal patch?  or I can fix it with your tag
> like Signed-off-by or Reported-by.
>
> > Also, I tried the master and version 1.6.7 on Linux kernel 5.10 and
> > got a kernel not supported error. Do we know when 5.10 will be
> > supported? Thanks.
>
> The latest is makedumpfile-1.6.8, but it was tested with up to kernel 5.9.
> I've tested the current master with kernel 5.10 to 5.11-rc5 on x86_64,
> it's ok so far.  The next version will support 5.10 officially and
> will be released this spring or summer, but not scheduled yet.
>
> Thanks,
> Kazu
>

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: [External] RE: Makedumpfile compile errors on Debian 10

[萩尾 一仁]

-Original Message-
> Hi Kazu,
> 
> I see. I will post a patch for this. I will try 1.6.8 to see if it
> works for me or not. Thanks for the info.

oh, please note that 1.6.8's --dump-dmesg does not support kernel 5.10,
which has the new printk ringbuffer, it needs the following two patches
in the master branch:

44b073b7ec46 [PATCH 2/2] printk: use committed/finalized state values
c617ec633392 [PATCH 1/2] printk: add support for lockless ringbuffer

Thanks,
Kazu

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [External] RE: Makedumpfile compile errors on Debian 10

[Jiang Wang .]

Got it. Thanks. I just sent the patch. Please let me know if there is
any problem with the patch. Thanks.

Regards,

Jiang

On Thu, Jan 28, 2021 at 10:23 PM HAGIO KAZUHITO(萩尾　一仁)
 wrote:
>
> -Original Message-
> > Hi Kazu,
> >
> > I see. I will post a patch for this. I will try 1.6.8 to see if it
> > works for me or not. Thanks for the info.
>
> oh, please note that 1.6.8's --dump-dmesg does not support kernel 5.10,
> which has the new printk ringbuffer, it needs the following two patches
> in the master branch:
>
> 44b073b7ec46 [PATCH 2/2] printk: use committed/finalized state values
> c617ec633392 [PATCH 1/2] printk: add support for lockless ringbuffer
>
> Thanks,
> Kazu
>

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: [EXTERNAL] Re: [PATCH] kexec: Add kexec reboot string

[Joe LeVeque]

Hi Andrew,

Is this all your looking for? If not, please let me know.

> Signed-off-by: Joe LeVeque 

Thanks,
Joe

-Original Message-
From: Andrew Morton  
Sent: Wednesday, March 10, 2021 9:33 PM
To: Paul Menzel 
Cc: Eric Biederman ; kexec@lists.infradead.org; 
linux-ker...@vger.kernel.org; Guohan Lu ; Joe LeVeque 

Subject: [EXTERNAL] Re: [PATCH] kexec: Add kexec reboot string

On Thu,  4 Mar 2021 13:46:26 +0100 Paul Menzel  wrote:

> From: Joe LeVeque 
> 
> The purpose is to notify the kernel module for fast reboot.
> 
> Upstream a patch from the SONiC network operating system [1].
> 
> [1]: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FAzure%2Fsonic-linux-kernel%2Fpull%2F46&data=04%7C01%7Cjol
> evequ%40microsoft.com%7Cddd7ea68d7d14ecdbd6608d8e44f225b%7C72f988bf86f
> 141af91ab2d7cd011db47%7C1%7C0%7C637510375952624615%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C1000&sdata=0lxaoVz%2BYyu5C4HvzSGMf0NpJJUWZFWdp7m3hLlL9MM%3D&am
> p;reserved=0
> 
> Signed-off-by: Paul Menzel 

We should have Joe's signed-off-by: for this.  Joe, can you please send it?


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [EXTERNAL] Re: [PATCH] kexec: Add kexec reboot string

[Andrew Morton]

On Thu, 11 Mar 2021 18:14:19 + Joe LeVeque  wrote:

> Is this all your looking for? If not, please let me know.
> 
> > Signed-off-by: Joe LeVeque 

Yes, thanks.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [EXTERNAL] Re: [PATCH] kexec: Add kexec reboot string

[Paul Menzel]

Dear Joe,


Thank you for replying.


Am 11.03.21 um 19:14 schrieb Joe LeVeque:


Is this all your looking for? If not, please let me know.


Signed-off-by: Joe LeVeque 


It’d be great if you answered Baoquan He’s question, how it’s actually 
used in SONiC. (I just sent the patch upstream to reduce the out-of-tree 
patches in SONiC.)



Kind regards,

Paul

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [External] Re: [PATCH 2/4] kexec: add CONFING_KEXEC_PURGATORY_SKIP_SIG

[黄杰]

maybe a boot parameter ?

Jason A. Donenfeld  于2022年7月25日周一 20:15写道：
>
> Hi Albert,
>
> On Mon, Jul 25, 2022 at 04:38:54PM +0800, Albert Huang wrote:
> > +config KEXEC_PURGATORY_SKIP_SIG
> > + bool "skip kexec purgatory signature verification"
> > + depends on ARCH_HAS_KEXEC_PURGATORY
> > + help
> > +   this options makes the kexec purgatory do  not signature 
> > verification
> > +   which would get hundreds of milliseconds saved during kexec boot. 
> > If we can
> > +   confirm that the data of each segment loaded by kexec will not 
> > change we may
> > +   enable this option
> > +
>
> Some grammar nits here, but actually, wouldn't it be better to make this
> depend on some other signature things instead? Like if the parent kernel
> actually did a big signature computation, then maybe the purgatory step
> is needed, but if it didn't bother, then maybe you can skip it. This
> way, you don't need a compile-time option that might change some aspect
> of signature verification people might otherwise be relying on.
>
> Jason

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [External] Re: [PATCH 0/4] faster kexec reboot

[黄杰]

Hi
Eric W. Biederman
Thank you for your advice and opinion, I am very honored

Eric W. Biederman  于2022年7月26日周二 01:04写道：
>
> Albert Huang  writes:
>
> > From: "huangjie.albert" 
> >
> > In many time-sensitive scenarios, we need a shorter time to restart
> > the kernel. However, in the current kexec fast restart code, there
> > are many places in the memory copy operation, verification operation
> > and decompression operation, which take more time than 500ms. Through
> > the following patch series. machine_kexec-->start_kernel only takes
> > 15ms
>
> Is this a tiny embedded device you are taking the timings of?
>
> How are you handling driver shutdown and restart?  I would expect those
> to be a larger piece of the puzzle than memory.

There is no way to make the code universal in the time optimization here,
and various devices need to be customized, but we have some solutions to
achieve the maintenance and recovery of these devices,
especially the scanning and initialization of pci devices

>
> My desktop can do something like 128GiB/s.  Which would suggest that
> copying 128MiB of kernel+initrd would take perhaps 10ms.  The SHA256
> implementation may not be tuned so that could be part of the performance
> issue.  The SHA256 hash has a reputation for having fast
> implementations.  I chose SHA256 originally simply because it has more
> bits so it makes the odds of detecting an error higher.
>

Yes, sha256 is a better choice, but if there is no memory copy between
kexec load
and kexec -e, and this part of the memory is reserved. Don't think
this part of memory will be changed.
Especially in virtual machine scenarios

>
> If all you care about is booting a kernel as fast as possible it make
> make sense to have a large reserved region of memory like we have for
> the kexec on panic kernel.  If that really makes sense I recommend
> adding a second kernel command line option and a reserving second region
> of reserved memory.  That makes telling if the are any conflicts simple.
>

I initially implemented re-adding a parameter and region, but I
figured out later
that it doesn't really make sense and would waste extra memory.

>
> I am having a hard time seeing how anyone else would want these options.
> Losing megabytes of memory simply because you might reboot using kexec
> seems like the wrong side of a trade-off.

Reuse the memory reserved by the crash kernel? Why does it increase
memory consumption?

>
> The CONFIG_KEXEC_PURGATORY_SKIP_SIG option is very misnamed.  It is not
> signature verification that is happening it is a hash verification.
> There are not encrypted bits at play.  Instead there is a check to
> ensure that the kernel has not been corrupted by in-flight DMA that some
> driver forgot to shut down.
>
Thanks for pointing that out.
but Even if the data is detected to have been changed, there is
currently no way to recover it.
I don't have a good understanding of this place yet. maybe for security reasons？


> So you are building a version of kexec that if something goes wrong it
> could very easily eat your data, or otherwise do some very bad things
> that are absolutely non-trivial to debug.
>
> That the decision to skip the sha256 hash that prevents corruption is
> happening at compile time, instead of at run-time, will guarantee the
> option is simply not available on any general purpose kernel
> configuration.  Given how dangerous it is to skip the hash verification
> it is probably not a bad thing overall, but it is most definitely
> something that will make maintenance more difficult.
>

Maybe parameters will be a better choice. What do you think ?

>
> If done well I don't see why anyone would mind a uncompressed kernel
> but I don't see what the advantage of what you are doing is over using
> vmlinux is the build directory.  It isn't a bzImage but it is the
> uncompressed kernel.
>


> As I proof of concept I think what you are doing goes a way to showing
> that things can be improved.  My overall sense is that improving things
> the way you are proposing does not help the general case and simply adds
> to the maintenance burden.

I don't think so. The kernel startup time of some lightweight virtual
machines maybe
100-200ms (start_kernel->init). But this kexec->start_kernel took more
than 500ms.
This is still valuable, and the overall code size is also very small.

> Eric
>
> >
> > How to measure time:
> >
> > c code:
> > uint64_t current_cycles(void)
> > {
> > uint32_t low, high;
> > asm volatile("rdtsc" : "=a"(low), "=d"(high));
> > return ((uint64_t)low) | ((uint64_t)high << 32);
> > }
> > assembly

Re: [External] Re: [PATCH 0/4] faster kexec reboot

[黄杰]

黄杰  于2022年7月26日周二 13:53写道：
>
> Hi
> Eric W. Biederman
> Thank you for your advice and opinion, I am very honored
>
> Eric W. Biederman  于2022年7月26日周二 01:04写道：
> >
> > Albert Huang  writes:
> >
> > > From: "huangjie.albert" 
> > >
> > > In many time-sensitive scenarios, we need a shorter time to restart
> > > the kernel. However, in the current kexec fast restart code, there
> > > are many places in the memory copy operation, verification operation
> > > and decompression operation, which take more time than 500ms. Through
> > > the following patch series. machine_kexec-->start_kernel only takes
> > > 15ms
> >
> > Is this a tiny embedded device you are taking the timings of?
> >
> > How are you handling driver shutdown and restart?  I would expect those
> > to be a larger piece of the puzzle than memory.
>
> There is no way to make the code universal in the time optimization here,
> and various devices need to be customized, but we have some solutions to
> achieve the maintenance and recovery of these devices,
> especially the scanning and initialization of pci devices
>
> >
> > My desktop can do something like 128GiB/s.  Which would suggest that
> > copying 128MiB of kernel+initrd would take perhaps 10ms.  The SHA256
> > implementation may not be tuned so that could be part of the performance
> > issue.  The SHA256 hash has a reputation for having fast
> > implementations.  I chose SHA256 originally simply because it has more
> > bits so it makes the odds of detecting an error higher.
> >
>
> Yes, sha256 is a better choice, but if there is no memory copy between
> kexec load
> and kexec -e, and this part of the memory is reserved. Don't think
> this part of memory will be changed.
> Especially in virtual machine scenarios
>

hi  Eric :

Do you know why this sha256 check is put here? I feel that it is
better to put it in the system call of kexec -e.
If the verification is not passed, the second kernel will not be
started, and some prompt information will be
printed at the same time, which seems to be better than when the
second kernel is started.
Doing the verification operation will be more friendly, and it can
also reduce downtime.

BR
albert.

> >
> > If all you care about is booting a kernel as fast as possible it make
> > make sense to have a large reserved region of memory like we have for
> > the kexec on panic kernel.  If that really makes sense I recommend
> > adding a second kernel command line option and a reserving second region
> > of reserved memory.  That makes telling if the are any conflicts simple.
> >
>
> I initially implemented re-adding a parameter and region, but I
> figured out later
> that it doesn't really make sense and would waste extra memory.
>
> >
> > I am having a hard time seeing how anyone else would want these options.
> > Losing megabytes of memory simply because you might reboot using kexec
> > seems like the wrong side of a trade-off.
>
> Reuse the memory reserved by the crash kernel? Why does it increase
> memory consumption?
>
> >
> > The CONFIG_KEXEC_PURGATORY_SKIP_SIG option is very misnamed.  It is not
> > signature verification that is happening it is a hash verification.
> > There are not encrypted bits at play.  Instead there is a check to
> > ensure that the kernel has not been corrupted by in-flight DMA that some
> > driver forgot to shut down.
> >
> Thanks for pointing that out.
> but Even if the data is detected to have been changed, there is
> currently no way to recover it.
> I don't have a good understanding of this place yet. maybe for security 
> reasons？
>
>
> > So you are building a version of kexec that if something goes wrong it
> > could very easily eat your data, or otherwise do some very bad things
> > that are absolutely non-trivial to debug.
> >
> > That the decision to skip the sha256 hash that prevents corruption is
> > happening at compile time, instead of at run-time, will guarantee the
> > option is simply not available on any general purpose kernel
> > configuration.  Given how dangerous it is to skip the hash verification
> > it is probably not a bad thing overall, but it is most definitely
> > something that will make maintenance more difficult.
> >
>
> Maybe parameters will be a better choice. What do you think ?
>
> >
> > If done well I don't see why anyone would mind a uncompressed kernel
> > but I don't see what the advantage of what you are doing is over using
> > vmlinux is the build directory.  It isn't a bzImage bu

Re: [External] Re: [PATCH 2/4] kexec: add CONFING_KEXEC_PURGATORY_SKIP_SIG

[黄杰]

Does anyone know why this sha256 checksum is put here? I feel that it
is better to put it in the system call of kexec -e.
If the verification is not passed, the second kernel will not be
started, and some prompt information will be printed at the
same time, which seems to be better than when the second kernel is
started. Doing the verification operation will be more friendly,
 and it can also reduce downtime.

黄杰  于2022年7月25日周一 21:32写道：
>
> maybe a boot parameter ?
>
> Jason A. Donenfeld  于2022年7月25日周一 20:15写道：
> >
> > Hi Albert,
> >
> > On Mon, Jul 25, 2022 at 04:38:54PM +0800, Albert Huang wrote:
> > > +config KEXEC_PURGATORY_SKIP_SIG
> > > + bool "skip kexec purgatory signature verification"
> > > + depends on ARCH_HAS_KEXEC_PURGATORY
> > > + help
> > > +   this options makes the kexec purgatory do  not signature 
> > > verification
> > > +   which would get hundreds of milliseconds saved during kexec boot. 
> > > If we can
> > > +   confirm that the data of each segment loaded by kexec will not 
> > > change we may
> > > +   enable this option
> > > +
> >
> > Some grammar nits here, but actually, wouldn't it be better to make this
> > depend on some other signature things instead? Like if the parent kernel
> > actually did a big signature computation, then maybe the purgatory step
> > is needed, but if it didn't bother, then maybe you can skip it. This
> > way, you don't need a compile-time option that might change some aspect
> > of signature verification people might otherwise be relying on.
> >
> > Jason

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: your mail

[Simon Horman]

On Fri, Apr 29, 2016 at 04:22:20PM +0200, Nikolaus Schulz wrote:
> Hi Simon,
> 
> here is v2 of the patch series from Avionic Design.  There are no
> content changes, only the setup_dtb_prop patch has a reworked commit
> message, as requested.

Thanks, Applied.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [PATCH] temp

[Pratyush Anand]

Ohhh..Please ignore this patch. This temporary changes were lying in
my directory and went away.

Sorry for this noise.

~Pratyush

On Mon, Oct 24, 2016 at 10:18 PM, Pratyush Anand  wrote:
> Signed-off-by: Pratyush Anand 
> ---
>  arch/x86_64.c  | 10 --
>  makedumpfile.h |  4 ++--
>  2 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86_64.c b/arch/x86_64.c
> index ddf7be6bc57b..3a53b4fa03ed 100644
> --- a/arch/x86_64.c
> +++ b/arch/x86_64.c
> @@ -187,6 +187,12 @@ vtop4_x86_64(unsigned long vaddr)
>  {
> unsigned long page_dir, pml4, pgd_paddr, pgd_pte, pmd_paddr, pmd_pte;
> unsigned long pte_paddr, pte;
> +   unsigned long phys_base;
> +
> +   if (SYMBOL(phys_base) != NOT_FOUND_SYMBOL)
> +   phys_base = info->phys_base;
> +   else
> +   phys_base = 0;
>
> if (SYMBOL(init_level4_pgt) == NOT_FOUND_SYMBOL) {
> ERRMSG("Can't get the symbol of init_level4_pgt.\n");
> @@ -196,9 +202,9 @@ vtop4_x86_64(unsigned long vaddr)
> /*
>  * Get PGD.
>  */
> -   page_dir  = SYMBOL(init_level4_pgt);
> +   page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + phys_base;
> page_dir += pml4_index(vaddr) * sizeof(unsigned long);
> -   if (!readmem(VADDR, page_dir, &pml4, sizeof pml4)) {
> +   if (!readmem(PADDR, page_dir, &pml4, sizeof pml4)) {
> ERRMSG("Can't get pml4 (page_dir:%lx).\n", page_dir);
> return NOT_PADDR;
> }
> diff --git a/makedumpfile.h b/makedumpfile.h
> index f0154226bcb8..f64652e34901 100644
> --- a/makedumpfile.h
> +++ b/makedumpfile.h
> @@ -876,12 +876,12 @@ int is_vmalloc_addr_x86_64(ulong vaddr);
>  int get_phys_base_x86_64(void);
>  int get_machdep_info_x86_64(void);
>  int get_versiondep_info_x86_64(void);
> -unsigned long long vaddr_to_paddr_x86_64(unsigned long vaddr);
> +unsigned long long vtop4_x86_64(unsigned long vaddr);
>  #define find_vmemmap() find_vmemmap_x86_64()
>  #define get_phys_base()get_phys_base_x86_64()
>  #define get_machdep_info() get_machdep_info_x86_64()
>  #define get_versiondep_info()  get_versiondep_info_x86_64()
> -#define vaddr_to_paddr(X)  vaddr_to_paddr_x86_64(X)
> +#define vaddr_to_paddr(X)  vtop4_x86_64(X)
>  #define is_phys_addr(X)(!is_vmalloc_addr_x86_64(X))
>  #endif /* x86_64 */
>
> --
> 2.7.4
>

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Steve Bhatti.//..

[Santander Bank Plc.]

G. Steve Batija
Operations / regionalni direktor
Santander Bank Plc,
47-48 Piccadilly
PICCADILLY
W1J0DT
London, Združeno Kraljestvo
 
Good Day Spoštovani,

Kako se vi in ??vaša družina? Upam, da danes moje pismo ste se sestaja na svoje 
najboljše razpoloženje. Sem Dr. Steve Batija, od Harlesden North West London, 
vodja oddelka racunovodskega revidiranja in formalno višji vodja programer pri 
Deutsche bank, tukaj v Angliji (Santander Bank Plc). Delal sem tudi za novejše 
ministrov Bank Plc.
 
Rabim nujno pomoc pri prenosu vsoto (£ 21,5 GBP) Twenty One Million, pet tisoc 
britanskih funtov na svoj racun v 11 ali 15 bancnih dni. Ta denar je bil v 
mirovanju za let v naši banki brez zahtevka. Želim banka sprostiti denar za 
vas, najbližje osebe v naši pokojnega Stranka (lastnik racuna), ki je na žalost 
izgubil življenje februarja 2003 po južnem ZDA raketoplana Columbia, je umrl en 
sam clovek. Sem ugotovil, da ni natancno koli ožjih sorodnikov ali pa bo 
upravicencu na njegov racun po tekoc skozi njegov spis v naši banki in nocem 
denarja, da gredo na racun zakladništva kot zapušceni sklada. To je torej 
razlog, zakaj sem kontakt z vami, da bi lahko banka spustite denar za vas, saj 
naj ožjih sorodnikov / Will upravicenec do pokojnika stranko (Late David 
McDowell Brown), ameriški državljan Arlington v Virginiji. Prosim, jaz bi tudi 
rad, da ta predlog kot top skrivnost in ga izbrisati, ce vas ne zanimajo.
 
Tu je razmerje delitev; 50% za mene in 40% za vas, medtem ko 10% je za vse 
stroške, ki so nastali v casu transakcije. Ce ste zainteresirani, se obrnite mi 
neposredno preko mojega zasebnega e-pošta: steve.s.bha...@gmail.com

Navedite mi sledi spodaj, kot smo 7 dni teci skozi. To je zelo nujna.
 
1. Polno ime:
2. Direct Mobile Število:
3. Kontaktni naslov:
4. Poklic:
5. Age:
6. Spol:
7. Državljanstvo:

To je, da bi mi upload svoje podatke v našem bancnem bazi podatkov, da odraža v 
sistemu bancnega omrežja, ki ga so poimenovali
ožjih sorodnikov / volje prejemnika tega racuna, potem vas bom vodil na 
komunikacijo z banko za nadaljnji prenos tega sklada za vas.
OPOMBA: Imamo nekaj bancnih dni za izvršitev te transakcije posel.
Hvala v pricakovanju vašega takojšen odziv.
 
S spoštovanjem,
Dr. Steve Bhatti.
Tel: +447042043211

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Representative Needed.

[PPMC OFFSHORE]

Good day,

  I am seeking your concept with great gratitude to present you as a 
representative to carry out business transactions with a reasonable share upon 
your interest and cooperation to work with us in trust. If interested please 
get back.

Regards
Kingsley

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[SPAM] Re: Greetings....

[events]

I am Ms. Liza Wong the Head of Accounting Audit Department of HSBC BANK 
(HSBC)in  Malaysia.
In my department in the Bank where i work, I discovered a sum of $85.5 Million 
USD In an account that belongs to one of our foreign deceased customers, a 
billionaire Business Mogul Late Mr.Moises Saba Masri, a Jew from Mexico who was 
a victim of a helicopter crash since 2010 which resulting to his death and his 
family members.

You can see more information about Saba Masri Mr.Moises unfortunate end 
accident on the website-link below.

http://www.ynetnews.com/articles/0,7340,L-3832556,00.html

A Mexican business tycoon was killed along with at least two members of his 
family in a helicopter crash on the outskirts of Mexico City on Sunday night, 
emergency ...

Now our bank has been waiting for any of the relatives to come forth for the  
claim but nobody has done that SINCE 2010. I personally have been unsuccessful 
in locating the relatives,Which the Board of Directors are planning to share 
this funds among them-self. Which i have good heart to use this funds to help 
the poor and street children also  the motherless home.. I want to build my 
orphanage home I dont know about you.
 I seek your consent as my foreign business partner in this transaction to 
present you as the next of kin/Beneficiary to the deseased, so that the funds 
of this account valued at $85.5 Million usd can be paid to your local bank 
account in your country. Also this transaction is 100% free risk, because i 
have all the legal document with me to make this transaction possible, and the 
funds we be share 50/50

Do Provide me the following few information about you, as we have few days to 
run it through.

1, Your Full names:.
2, Your age:..
3, Your private phone number:...
4, Your current country and residential address:
5, Your Occupation:.

Please on your confirmation of this message and indicating your interest,
i will furnish you with more information on this business transaction once i 
get your respond back asap.

Best Regard
Ms. Liza Wong

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

-- Re: Very Urgent............

[Fabian Morision]

Greetings from gulf region

Thanks for the e-mail. I am very interested on funding lucrative
business partnership with you acting as the manager and sole
controller of the investment while i remain a silent investor for a
period of ten yrs , though I am only looking at investment
opportunities within the range you specified for a start. You can
reply me here (fmoris...@yahoo.com)

Let me know your thought asap

Regards

Financial Consultant

Mr.Fabian Morision

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: Vive l’expérience

[Pierre]

Bonjour à tous. 
Je me présente Pierre Boutin.  J’ai 26 ans et suis célibataire. Ces derniers 
temps, après avoir eu des relations avec des filles de mon âge pendant des 
années, comme tout le monde, je me suis intéressé à des femmes un peu plus 
mûres. Evidemment, je choisi pas des croulantes, mais des femmes de 30-40 ans 
qui ont déjà un vécu, souvent divorcées, parfois mariées. Et je peux vous dire 
que c’est autre chose ! Avec elles, il n’ y a pas de tabous, elles aiment tout. 
J’ai même découvert des choses que j’aurai imaginé, moi qui croyait avoir fait 
le tour de la question. Il y a un site où il y en a vraiment beaucoup et où 
elles viennent juste pour se taper des jeunots :

 http://cougar91.fr/

Alors à bientôt les amis, profitez-en, y en a pour tout le même, on dirait même 
que la réserve est illimitée !



pour vous désabonner de cette liste d'envoi merci de répondre STOP au présent 
message. Le filtre de désabonnement ne lis que le terme STOP. Merci de ne pas 
écrire d'autre phrase.

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Cash Alert

[© 2014 Heritage Lottery Board]

2014 Heritage Lottery Board
Congrats:You have won (  500,000.00 Pounds )Contact Mr Williams Hunter: 
wu.transfer...@qq.com . Mobile:+447937683022


www.ikc.edu.tr

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Cash Alert

[© 2014 Heritage Lottery Board]

2014 Heritage Lottery Board
Congrats:You have won (  500,000.00 Pounds )Contact Mr Williams Hunter: 
wu.transfer...@qq.com . Mobile:+447937683022


www.ikc.edu.tr

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: mips: elfinfo

[Maxim Uvarov]

2010/12/16 Simon Horman :
> Hi Maxim,
>
> I noticed that your change "Patch adds kernel data section to final vmcore.
> This forces gdb read kernel" causes the build to break as it was applied
> after Eric's "crashdump: Move kern_vaddr_start from kexec_info into
> crash_elf_info" patch.
>
> I have it in mind to resolve this something along the lines of
> the patch below. However, I now see the following warning:
>
>        kexec/arch/mips/crashdump-mips.c: In function 
> `get_kernel_vaddr_and_size':
>        kexec/arch/mips/crashdump-mips.c:81: warning: integer constant is too 
> large for "unsigned long" type
>
> Which corresponds to this code:
>
>        elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
>                                        0x8000UL;
>
> I am compiling for 32-bit, so at a glance that constant does
> seem to large.
>

Ah, yes this values does not fit to 32 bit UL.

> Also, if you have any tips on a cross-compiling environment for 64bit
> on a x86_32 or x86_64 host I would be most grateful.
>

I tested it with building on 32 bit host. readelf -a shows that vmcore
had memory segment according to kernel memory.
So that, gdb began to read real values instead of uninitialized.

Actually  elf_info->kern_paddr_start | 0x8000UL; is needed
only for 64 bit mips.
Because we read kernel memory ranges from /proc/vmcore and there are
values without 0x at the beginning.
But 0xf... are needed in case if we need access to this address from kernel.

32 bit mips kernel does not need adding 0xfff.  But it think there
will be only warning and nothing wrong.

Maxim.

>
> diff --git a/kexec/arch/mips/crashdump-mips.c 
> b/kexec/arch/mips/crashdump-mips.c
> index 5ea4f4f..b937ab5 100644
> --- a/kexec/arch/mips/crashdump-mips.c
> +++ b/kexec/arch/mips/crashdump-mips.c
> @@ -51,7 +51,7 @@ unsigned long long saved_max_mem;
>
>  /* Read kernel physical load addr from the file returned by proc_iomem()
>  * (Kernel Code) and store in kexec_info */
> -static int get_kernel_paddr(struct kexec_info *info)
> +static int get_kernel_paddr(struct crash_elf_info *elf_info)
>  {
>        uint64_t start;
>
> @@ -59,7 +59,7 @@ static int get_kernel_paddr(struct kexec_info *info)
>                return 0;
>
>        if (parse_iomem_single("Kernel code\n", &start, NULL) == 0) {
> -               info->kern_paddr_start = start;
> +               elf_info->kern_paddr_start = start;
>  #ifdef DEBUG
>                printf("kernel load physical addr start = 0x%lx\n", start);
>  #endif
> @@ -70,21 +70,22 @@ static int get_kernel_paddr(struct kexec_info *info)
>        return -1;
>  }
>
> -static int get_kernel_vaddr_and_size(struct kexec_info *info)
> +static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info)
>  {
>        uint64_t end;
>
> -       if (!info->kern_paddr_start)
> +       if (!elf_info->kern_paddr_start)
>                return -1;
>
> -       info->kern_vaddr_start =  info->kern_paddr_start | 
> 0x8000UL;
> +       elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
> +                                       0x8000UL;
>        if (parse_iomem_single("Kernel data\n", NULL, &end) == 0) {
> -               info->kern_size = end - info->kern_paddr_start;
> +               elf_info->kern_size = end - elf_info->kern_paddr_start;
>  #ifdef DEBUG
>                printf("kernel_vaddr= 0x%llx paddr %llx\n",
> -                               info->kern_vaddr_start,
> -                               info->kern_paddr_start);
> -               printf("kernel size = 0x%llx\n", info->kern_size);
> +                               elf_info->kern_vaddr_start,
> +                               elf_info->kern_paddr_start);
> +               printf("kernel size = 0x%llx\n", elf_info->kern_size);
>  #endif
>                return 0;
>                }
> @@ -355,11 +356,20 @@ int load_crashdump_segments(struct kexec_info *info, 
> char* mod_cmdline,
>        unsigned long sz, elfcorehdr;
>        int nr_ranges, align = 1024;
>        struct memory_range *mem_range;
> +       crash_create_elf_headers_func crash_create = 
> crash_create_elf32_headers;
> +       struct crash_elf_info *elf_info = &elf_info32;
>
> -       if (get_kernel_paddr(info))
> +#ifdef __mips64
> +       if (arch_options.core_header_type == CORE_TYPE_ELF64) {
> +               elf_info = &elf_info64;
> +               crash_create = crash_create_elf64;
> +       }
> +#endif
> +
> +       if (get_kernel_paddr(elf_info))
>                return -1;
>
> -       if (get_kernel_vaddr_and_size(info))
> +       if (get_kernel_vaddr_and_size(elf_info))
>                return -1;
>
>        if (get_crash_memory_ranges(&mem_range, &nr_ranges) < 0)
> @@ -373,28 +383,9 @@ int load_crashdump_segments(struct kexec_info *info, 
> char* mod_cmdline,
>                                crash_reserved_mem.start,
>                                crash_reserved_mem.end, -1);
>
> -#ifdef __mips64
> -     

Re: kexec fixes?

[Simon Horman]

On Thu, Dec 16, 2010 at 02:53:45PM -0800, Eric W. Biederman wrote:
> 
> Simon did you ever get my last round of fixes for i386 after
> my other changes merged?
> 
> I was testing them in my tree, and I was trying to be careful
> and not send you something bad.  I completed my testing and
> but I forget to send you a pull request.

Hi Eric,

I don't think that I received a pull request and in
any case I don't have anything other than mips fix(es) pending.
So if its not in my tree could you (rebase and) send it again?

Its been a while since there was a release, so it might
be nice (for me) to get a 2.0.3 out the door some time.


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: mips: elfinfo

[Simon Horman]

On Thu, Dec 16, 2010 at 06:33:25PM +0300, Maxim Uvarov wrote:
> 2010/12/16 Simon Horman :
> > Hi Maxim,
> >
> > I noticed that your change "Patch adds kernel data section to final vmcore.
> > This forces gdb read kernel" causes the build to break as it was applied
> > after Eric's "crashdump: Move kern_vaddr_start from kexec_info into
> > crash_elf_info" patch.
> >
> > I have it in mind to resolve this something along the lines of
> > the patch below. However, I now see the following warning:
> >
> >        kexec/arch/mips/crashdump-mips.c: In function 
> > `get_kernel_vaddr_and_size':
> >        kexec/arch/mips/crashdump-mips.c:81: warning: integer constant is 
> > too large for "unsigned long" type
> >
> > Which corresponds to this code:
> >
> >        elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
> >                                        0x8000UL;
> >
> > I am compiling for 32-bit, so at a glance that constant does
> > seem to large.
> >
> 
> Ah, yes this values does not fit to 32 bit UL.
> 
> > Also, if you have any tips on a cross-compiling environment for 64bit
> > on a x86_32 or x86_64 host I would be most grateful.
> >
> 
> I tested it with building on 32 bit host. readelf -a shows that vmcore
> had memory segment according to kernel memory.
> So that, gdb began to read real values instead of uninitialized.
> 
> Actually  elf_info->kern_paddr_start | 0x8000UL; is needed
> only for 64 bit mips.
> Because we read kernel memory ranges from /proc/vmcore and there are
> values without 0x at the beginning.
> But 0xf... are needed in case if we need access to this address from 
> kernel.
> 
> 32 bit mips kernel does not need adding 0xfff.  But it think there
> will be only warning and nothing wrong.

Understood, but it would be nice to eliminate the warning.
As load_crashdump_segments() is already 32/64 bit aware I wonder
if we could just pass appropriate constant from there as
a parameter of get_kernel_vaddr_and_size().

Perhaps something like the following which
applies on top of my previous patch.

diff --git a/kexec/arch/mips/crashdump-mips.c b/kexec/arch/mips/crashdump-mips.c
index b937ab5..aa50109 100644
--- a/kexec/arch/mips/crashdump-mips.c
+++ b/kexec/arch/mips/crashdump-mips.c
@@ -70,7 +70,8 @@ static int get_kernel_paddr(struct crash_elf_info *elf_info)
return -1;
 }
 
-static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info)
+static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info,
+unsigned long start_offset)
 {
uint64_t end;
 
@@ -78,7 +79,7 @@ static int get_kernel_vaddr_and_size(struct crash_elf_info 
*elf_info)
return -1;
 
elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
-   0x8000UL;
+   start_offset;
if (parse_iomem_single("Kernel data\n", NULL, &end) == 0) {
elf_info->kern_size = end - elf_info->kern_paddr_start;
 #ifdef DEBUG
@@ -358,18 +359,20 @@ int load_crashdump_segments(struct kexec_info *info, 
char* mod_cmdline,
struct memory_range *mem_range;
crash_create_elf_headers_func crash_create = crash_create_elf32_headers;
struct crash_elf_info *elf_info = &elf_info32;
+   unsigned long start_offset = 0x8000UL;
 
 #ifdef __mips64
if (arch_options.core_header_type == CORE_TYPE_ELF64) {
elf_info = &elf_info64;
crash_create = crash_create_elf64;
+   start_offset = 0x8000UL;
}
 #endif
 
if (get_kernel_paddr(elf_info))
return -1;
 
-   if (get_kernel_vaddr_and_size(elf_info))
+   if (get_kernel_vaddr_and_size(elf_info, start_offset))
return -1;
 
if (get_crash_memory_ranges(&mem_range, &nr_ranges) < 0)

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: mips: elfinfo

[Maxim Uvarov]

2010/12/20 Simon Horman :
> On Thu, Dec 16, 2010 at 06:33:25PM +0300, Maxim Uvarov wrote:
>> 2010/12/16 Simon Horman :
>> > Hi Maxim,
>> >
>> > I noticed that your change "Patch adds kernel data section to final vmcore.
>> > This forces gdb read kernel" causes the build to break as it was applied
>> > after Eric's "crashdump: Move kern_vaddr_start from kexec_info into
>> > crash_elf_info" patch.
>> >
>> > I have it in mind to resolve this something along the lines of
>> > the patch below. However, I now see the following warning:
>> >
>> >        kexec/arch/mips/crashdump-mips.c: In function 
>> > `get_kernel_vaddr_and_size':
>> >        kexec/arch/mips/crashdump-mips.c:81: warning: integer constant is 
>> > too large for "unsigned long" type
>> >
>> > Which corresponds to this code:
>> >
>> >        elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
>> >                                        0x8000UL;
>> >
>> > I am compiling for 32-bit, so at a glance that constant does
>> > seem to large.
>> >
>>
>> Ah, yes this values does not fit to 32 bit UL.
>>
>> > Also, if you have any tips on a cross-compiling environment for 64bit
>> > on a x86_32 or x86_64 host I would be most grateful.
>> >
>>
>> I tested it with building on 32 bit host. readelf -a shows that vmcore
>> had memory segment according to kernel memory.
>> So that, gdb began to read real values instead of uninitialized.
>>
>> Actually  elf_info->kern_paddr_start | 0x8000UL; is needed
>> only for 64 bit mips.
>> Because we read kernel memory ranges from /proc/vmcore and there are
>> values without 0x at the beginning.
>> But 0xf... are needed in case if we need access to this address from 
>> kernel.
>>
>> 32 bit mips kernel does not need adding 0xfff.  But it think there
>> will be only warning and nothing wrong.
>
> Understood, but it would be nice to eliminate the warning.
> As load_crashdump_segments() is already 32/64 bit aware I wonder
> if we could just pass appropriate constant from there as
> a parameter of get_kernel_vaddr_and_size().
>
> Perhaps something like the following which
> applies on top of my previous patch.
>
Yes, that has to work. Thanks.

> diff --git a/kexec/arch/mips/crashdump-mips.c 
> b/kexec/arch/mips/crashdump-mips.c
> index b937ab5..aa50109 100644
> --- a/kexec/arch/mips/crashdump-mips.c
> +++ b/kexec/arch/mips/crashdump-mips.c
> @@ -70,7 +70,8 @@ static int get_kernel_paddr(struct crash_elf_info *elf_info)
>        return -1;
>  }
>
> -static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info)
> +static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info,
> +                                    unsigned long start_offset)
>  {
>        uint64_t end;
>
> @@ -78,7 +79,7 @@ static int get_kernel_vaddr_and_size(struct crash_elf_info 
> *elf_info)
>                return -1;
>
>        elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
> -                                       0x8000UL;
> +                                       start_offset;
>        if (parse_iomem_single("Kernel data\n", NULL, &end) == 0) {
>                elf_info->kern_size = end - elf_info->kern_paddr_start;
>  #ifdef DEBUG
> @@ -358,18 +359,20 @@ int load_crashdump_segments(struct kexec_info *info, 
> char* mod_cmdline,
>        struct memory_range *mem_range;
>        crash_create_elf_headers_func crash_create = 
> crash_create_elf32_headers;
>        struct crash_elf_info *elf_info = &elf_info32;
> +       unsigned long start_offset = 0x8000UL;
>
>  #ifdef __mips64
>        if (arch_options.core_header_type == CORE_TYPE_ELF64) {
>                elf_info = &elf_info64;
>                crash_create = crash_create_elf64;
> +               start_offset = 0x8000UL;
>        }
>  #endif
>
>        if (get_kernel_paddr(elf_info))
>                return -1;
>
> -       if (get_kernel_vaddr_and_size(elf_info))
> +       if (get_kernel_vaddr_and_size(elf_info, start_offset))
>                return -1;
>
>        if (get_crash_memory_ranges(&mem_range, &nr_ranges) < 0)
>



-- 
Best regards,
Maxim Uvarov

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: mips: elfinfo

[Simon Horman]

On Tue, Dec 21, 2010 at 10:04:34AM +0300, Maxim Uvarov wrote:
> 2010/12/20 Simon Horman :
> > On Thu, Dec 16, 2010 at 06:33:25PM +0300, Maxim Uvarov wrote:
> >> 2010/12/16 Simon Horman :
> >> > Hi Maxim,
> >> >
> >> > I noticed that your change "Patch adds kernel data section to final 
> >> > vmcore.
> >> > This forces gdb read kernel" causes the build to break as it was applied
> >> > after Eric's "crashdump: Move kern_vaddr_start from kexec_info into
> >> > crash_elf_info" patch.
> >> >
> >> > I have it in mind to resolve this something along the lines of
> >> > the patch below. However, I now see the following warning:
> >> >
> >> >        kexec/arch/mips/crashdump-mips.c: In function 
> >> > `get_kernel_vaddr_and_size':
> >> >        kexec/arch/mips/crashdump-mips.c:81: warning: integer constant is 
> >> > too large for "unsigned long" type
> >> >
> >> > Which corresponds to this code:
> >> >
> >> >        elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
> >> >                                        0x8000UL;
> >> >
> >> > I am compiling for 32-bit, so at a glance that constant does
> >> > seem to large.
> >> >
> >>
> >> Ah, yes this values does not fit to 32 bit UL.
> >>
> >> > Also, if you have any tips on a cross-compiling environment for 64bit
> >> > on a x86_32 or x86_64 host I would be most grateful.
> >> >
> >>
> >> I tested it with building on 32 bit host. readelf -a shows that vmcore
> >> had memory segment according to kernel memory.
> >> So that, gdb began to read real values instead of uninitialized.
> >>
> >> Actually  elf_info->kern_paddr_start | 0x8000UL; is needed
> >> only for 64 bit mips.
> >> Because we read kernel memory ranges from /proc/vmcore and there are
> >> values without 0x at the beginning.
> >> But 0xf... are needed in case if we need access to this address from 
> >> kernel.
> >>
> >> 32 bit mips kernel does not need adding 0xfff.  But it think there
> >> will be only warning and nothing wrong.
> >
> > Understood, but it would be nice to eliminate the warning.
> > As load_crashdump_segments() is already 32/64 bit aware I wonder
> > if we could just pass appropriate constant from there as
> > a parameter of get_kernel_vaddr_and_size().
> >
> > Perhaps something like the following which
> > applies on top of my previous patch.
> >
> Yes, that has to work. Thanks.

Thanks, I have pushed this and the previous change.


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec fixes?

[Simon Horman]

On Fri, Dec 17, 2010 at 09:50:31AM +0900, Simon Horman wrote:
> On Thu, Dec 16, 2010 at 02:53:45PM -0800, Eric W. Biederman wrote:
> > 
> > Simon did you ever get my last round of fixes for i386 after
> > my other changes merged?
> > 
> > I was testing them in my tree, and I was trying to be careful
> > and not send you something bad.  I completed my testing and
> > but I forget to send you a pull request.
> 
> Hi Eric,
> 
> I don't think that I received a pull request and in
> any case I don't have anything other than mips fix(es) pending.
> So if its not in my tree could you (rebase and) send it again?
> 
> Its been a while since there was a release, so it might
> be nice (for me) to get a 2.0.3 out the door some time.

Hi Eric,

do you have any pending changes?

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [KEXEC] [ARM]

[zhangchenyu]

hi:
I have compiled kexe-tools-2.0.2 for arm,

LDFLAGS=-static TARGET_CC=/opt/arm-eabi-4.4.0/bin/arm-eabi-gcc 
./configure arm --build=arm-none-linux-gnueabi 
--target=arm-none-linux-gnueabi --host=i686-pc-linux-gnu


and generated kexec and kdump in kexec-tools-2.0.2/build/sbin/. Then I 
used "adb push" command to download kexec and kdump in /data which is an 
android directory, and made "chmod 755 /data/kexec". But when I did 
"/data/kexec", I got the result as follow:


# /data/kexec
/data/kexec
重櫶?戝鄉%s鄉%嗔B鄉%?C鄉%怋C: not found
ELF

: not found
/data/kexec: 2: Syntax error: word unexpected (expecting ")")

I do not why. Can some one tell me?

Thank you very much.


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [KEXEC] [ARM]

[zhangchenyu]

hi:
I used standard arm-linux-gcc, and configured as follow:

LDFLAGS=-static 
TARGET_CC=/opt/usr/local/arm/4.3.2/bin/arm-none-linux-gnueabi-gcc 
TARGET_LD=/opt/usr/local/arm/4.3.2/bin/arm-none-linux-gnueabi-ld 
./configure arm --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu 
--target=arm-none-linux-gnueabi


and when I execute on android as follow:
# /data/kexec
/data/kexec
/data/kexec: 6: Syntax error: end of file unexpected (expecting ")")

and I found that "/build/sbin/kexec" I compiled is for x86_64:
root@zcy618-OptiPlex-380:/zcy_workspace/zcy_linux_accumulation/kdump+kexec/kexec-tools-2.0.2# 
file build/sbin/kexec
build/sbin/kexec: ELF 64-bit LSB executable, x86-64, version 1 
(GNU/Linux), statically linked, for GNU/Linux 2.6.15, not stripped


root@zcy618-OptiPlex-380:/zcy_workspace/zcy_linux_accumulation/kdump+kexec/kexec-tools-2.0.2# 
file build/sbin/kdump
build/sbin/kdump: ELF 32-bit LSB executable, ARM, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped


and I want to know how to compile it for arm, because I thought that I 
have made makefile for arm but it is not.


Could somebody help me? I would very appreciate it.

Thank you very much.

On 2011年04月19日 20:18, zhangchenyu wrote:

hi:
I have compiled kexe-tools-2.0.2 for arm,

LDFLAGS=-static TARGET_CC=/opt/arm-eabi-4.4.0/bin/arm-eabi-gcc 
./configure arm --build=arm-none-linux-gnueabi 
--target=arm-none-linux-gnueabi --host=i686-pc-linux-gnu


and generated kexec and kdump in kexec-tools-2.0.2/build/sbin/. Then I 
used "adb push" command to download kexec and kdump in /data which is 
an android directory, and made "chmod 755 /data/kexec". But when I did 
"/data/kexec", I got the result as follow:


# /data/kexec
/data/kexec
重櫶?戝鄉%s鄉%嗔B鄉%?C鄉%怋C: not found
ELF

: not found
/data/kexec: 2: Syntax error: word unexpected (expecting ")")

I do not why. Can some one tell me?

Thank you very much.




___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kexec question

[WANG Cong]

On Mon, 12 Sep 2011 10:50:33 -0700, Mark Maule wrote:

> Resending - did not include the kexec list in my prior email:
> 
> I'm experimenting with kexec on x86_64.  I see ppc64 has the ability to
> reuse the initrd, which is something I would be very interested in using
> for x86_64.
> 
> Is the reason it is not supported for x86_64 that no one has requested
> it, or are there other technical reasons for this?
> 

What do you mean by "reuse the initrd"?

kexec on x86_64 is pretty mature, I don't know which feature
you are referring here.


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: cyclic makedumpfile

[Atsushi Kumagai]

Hello Cliff,

On Tue, 23 Oct 2012 17:51:05 -0500
Cliff Wickman  wrote:

> Hello Mr. Kumagai,
> 
>   I was looking for some information about the "cyclic" processing in 
>   makedumpfile, and came upon this:
>  http://lists.infradead.org/pipermail/kexec/2012-July/006480.html
>   That's why I'm sending this question to you.

Thank you for your suggestion for improvement.

>   I work on the Linux kernel here at SGI.  We are trying to dump some very
>   large memories, and so we are very interested in this cyclic feature.
> 
>   I built makedumpfile-1.5.0 and tried it out.
>   It seems to work fine, but does spend a lot of time building bitmaps.
>   
>   If I set the cyclic-buffer value to create 3 cycles, then
>   exclude_unneccessary_pages_cyclic() is entered 6 times:
>   - 3 times from get_num_dumpable_cyclic() (via update_region_cyclic())
>   - 3 times from write_kdump_pages_and_bitmap_cyclic()
> (also via update_region_cyclic())
>
>   These page structure scans of /proc/vmcore for terabytes of memory can
>   take a long time, and so I think something might be done to remove the
>   redundant scans.
>
>   Could it not be possible to save the bitmaps created during the
>   get_num_dumpable_cyclic() pass?  And then retrieve them for the
>   write_kdump_pages_and_bitmap_cyclic() pass?  I think this could save
>   literally hours on a very large memory.
>
>   Perhaps they could be written to a file, or files.

makedumpfile should work also on the environment which doesn't mount a root
filesystem when 2nd-kernel is running. In such environments, writing to a file
isn't the solution because the bitmap file is created on 2nd-kernel's memory.
This is the starting point of our discussion.

Therefore, we can save only a chunk of bitmap at a time, so we have to scan
each region twice.

>   But I'm sure you understand the logic of makedumpfile much better than I.
>   Do you think such an enhancement is possible?
>   Or perhaps you already have another workaround?

Now, I plan to do the two enhancement for performance, please see below.

  in v1.5.1:
- Minimaize the number of cycle
  http://lists.infradead.org/pipermail/kexec/2012-October/006864.html

  in v1.5.2:
- Improve the filtering logic
  http://lists.infradead.org/pipermail/kexec/2012-June/006441.html


Thanks
Atsushi Kumagai

> 
> Thanks much.
> -Cliff Wickman

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Ember Proposal

[postmaster]

I am writing to find out if you have received my previous email regarding a 
business proposal. please get back to me as this is the second time i am 
writing you.If no read below again

I am Ms. Liza Wong the Head of Accounting Audit Department of HSBC BANK 
(HSBC)in  Malaysia.
In my department in the Bank where i work, I discovered a sum of $85.5 Million 
USD.
 In an account that belongs to one of our foreign deceased customers, a 
billionaire Business Mogul Late Mr.Moises Saba Masri, a Jew from Mexico who was 
a victim of a helicopter crash since 2010 which resulted in his death and his 
family members.

You can see more information about Saba Masri Mr.Moises unfortunate end 
accident on the website-link below.

http://www.ynetnews.com/articles/0,7340,L-3832556,00.html

A Mexican business tycoon was killed along with at least two members of his 
family in a helicopter crash on the outskirts of Mexico City on Sunday night, 
in an emergency .

Now our bank has been waiting for any of the relatives to come forth for the  
claim but nobody has done that SINCE 2010. I personally have been unsuccessful 
in locating the relatives,Which the Board of Directors are planning to share 
these funds among them-self.
I have a good heart to use this funds to help the poor and street children who 
also  have a motherless home. I want to build my orphanage home, which is a 
setting NGO for the disability people that can not afford to eat 3 square meals 
a day. I don't know about you.
I do seek your consent as my foreign business partner in this transaction to 
present you as the next of kin/Beneficiary to the deceased, so that the funds 
of this accoun valued at $85.5 Million USD can be paid to your local bank 
account in your country. Also know that the transaction is 100% free risk, 
because I have all the legal documents with me to make this transaction 
possible, and the funds we will share are 50/50.

Please Provide me the following few information about you, as we have a few 
days to run it through to achieve our goal.

1, Your Full names:.
2, Your age:..
3, Your private phone number:...
4, Your current country and residential address:
5, Your Occupation:.

Please on your message and indicate your interest,
i will furnish you with more information on this business transaction once I 
get your response back asap.

Best Regard
Ms. Liza Wong

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Need Help

[Ken'ichi Ohmichi]

Hi,

Thank you for the report.

Muniyappa, Rangappa wrote:
> I have suse 10.1 linux kernel 
> 
> for this kernel which kexec rpm package is compatible and 
> 
> do we need kdump helpers package
> 
> and tell me which makedumpfile rpm is compatible for this version

To resolve the issue, I want to know your environment.
Could you please tell me the following items ?

- The cpu architecture and the kernel version
  # please send me the output of 'uname -a'.

- The memory model (flatmem/discontigmem/sparsemem)
  # please send me the kernel config file (/boot/config-2.6.XX).

- The makedumpfile version
  # please send me the output of 'makedumpfile -v'.


The latest makedumpfile (version 1.2.5) supports the following kernels,
and you can get it from 
https://sourceforge.net/project/showfiles.php?group_id=178938.

 |  FLATMEM  |   DISCONTIGMEM| SPARSEMEM
 |---+---+---
   Kernel|| x86|| PPC|| x86|| PPC|| x86|| PPC
  Version| x86| _64|ia64|  64| x86| _64|ia64|  64| x86| _64|ia64|  64
  ---++++++++++++
  2.6.15 | OK | -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
  2.6.16 | OK | OK | -- || -- | OK | OK | -- | -- || -- |
  2.6.17 | OK | OK | -- || -- | OK | -- | -- | -- | OK | -- |
  2.6.18 | OK | OK | -- | OK | -- | OK | OK | -- | -- | OK | OK | OK
  2.6.19 | OK | OK | -- | OK | OK | OK |TODO| -- | OK | OK | OK | OK
  2.6.20 | OK | OK | -- | KP | OK | OK |TODO| -- | OK | OK | OK | KP
  21-rc5 | OK | OK | -- | OK | OK | OK |TODO| -- | OK | OK | OK | OK
  2.6.21 | OK | OK | -- || OK | OK |TODO| -- | OK | OK | OK |
  2.6.22 | OK | OK | -- || OK | OK |TODO| -- | OK | OK | OK |
  2.6.23 | OK | OK | -- || OK | OK |TODO| -- | OK | OK | OK |
  2.6.24 | OK | OK | -- || OK | OK |TODO| -- | OK | OK | OK |


Thanks
Ken'ichi Ohmichi

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Need Help

[Ken'ichi Ohmichi]

Hi,

Muniyappa, Rangappa wrote:
> 1) The cpu architecture and the kernel version
> 
> Linux linux-ugsi 2.6.16.46-0.12-debug #1 SMP Wed Mar 26 15:54:11 IST
> 2008 i686 i686 i386 GNU/Linux
> 
> 2) The memory model (config-2.6.16.46-0.12-kdump)
> 
> I am attaching the config file with this mail.
> 
> 3) The makedumpfile version
> 
> makedumpfile: version 1.0.8 (released on 22 December 2006)

Thank you for the information.
I guess that the cause is due to an invalid ELF header of /proc/vmcore.
To confirm it, could you please give me more information ?

1. Is your system's memory 4GB or bigger ?

2. Is an ELF header of /proc/vmcore ELF32 ?
   # Please send me the output of 'readelf -a /proc/vmcore'

3. If the above answers are 'yes', could you run the following
   operations and report the result ?
   - When preloading kdump kernel, add "--elf64-core-headers"
 option to kexec command.
   - Make a panic.
   - After switching to kdump kernel, run makedumpfile.

Note:
  makedumpfile gets the pfn from an ELF header of /proc/vmcore.
  ELF32 header cannot represent physical address 4GB or bigger,
  and it is invalid. As the result, makedumpfile cannot get valid pfn.


Thanks
Ken'ichi Ohmichi


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Need Help

[Ken'ichi Ohmichi]

Hi,

Muniyappa, Rangappa wrote:
> Its bigger than 4GB.
>
> And output of 'readelf -a /proc/vmcore'
> 
> ELF Header:
>   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>   Class: ELF32

(snip)

> 3) in this point u telling to set something when preloading the kdump ,
> may I know hw to set that one

In /etc/sysconfig/kdump file, there is "KEXEC_OPTIONS" and I guess
that you can do it if adding "--elf64-core-headers" to this item.

## Type:string
## Default: ""
## ServiceRestart:  kdump
#
# Additional arguments passed to kexec.  For example, to generate
# ELF32 dump on x86-64 to allow i386 systems to read dump, set
# "--elf32-core-headers" here.
#
# Keep this empty in most cases.
#
KEXEC_OPTIONS=""


Thanks
Ken'ichi Ohmichi

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [KEXEC] [ARM]

[Eric W. Biederman]

I've added the kexec list as there may be other people that can help
out.

On Fri, 2008-04-11 at 09:51 +0530, Sundeep Borra wrote:
> Dear Eric,
> 
> I am working on KEXEC tool for ARM platform with linux-2.6.22.6.
> I have problem loading and running the zImage that is compiled with
> kexec_syscall support.
> 
> I found no code related to ARM architecture either in pugatory or in
> other branch of Kexec-tools source tree.

Have you looked at the kexec-tools-testing repository.  That is where
the work has been happening lately.

> I searched for Corresponding Patches on Net and those patches had
> nothign significant about ARM support on Purgatory,
> 
> Where to start from, inorder to get ARm specific purgatory code.

Well we compile purgatory as a relocatable object file and then 
process the relocations so we can put it in memory wherever we want
so there is relocation support.

Beyond that for purgatory it should just be a handful of stubs from
assembly to C that should be straight forward to write if you know
the architecture.

> I would like to donate ARM specific code if one doesn't exist

Well.  I don't know a lot about the ARM architecture but I can give some
general guidance.

As I recall ARM has the option to disable the MMU like x86 and the
kernel starts in that mode by default which makes things straight 
forward.

The biggest part is to figure out the format that the ARM kernel
accepts arguments in and generate those arguments when you load
an ARM kernel.  Basically that the kexec code really does collect
up the information a boot loader would pass and it passes it to the
kernel.


> -
> KEXEC-tools Version: 1.101
> 
> 
> PLATFORM: ARM926
> 
> 
> COMMAND:
> --
> ./kexec -l vmlinux
> 
> 
> ERROR:
> 
> 
> kernel: 0x4012c008 kernel_size: 191e72
> kexec_load: entry = 0xa0008000 flags = 28
> nr_segments = 1
> segment[0].buf   = 0x4012c008
> segment[0].bufsz = 191e72
> segment[0].mem   = 0xa0008000
> segment[0].memsz = 192000
> kexec_load failed: Function not implemented
-ENOSYS?

Is the kernel portion of kexec implemented on ARM?

> entry   = 0xa0008000 flags = 28
> nr_segments = 1
> segment[0].buf   = 0x4012c008
> segment[0].bufsz = 191e72
> segment[0].mem   = 0xa0008000
> segment[0].memsz = 192000
> 
> 
> CAUSE: syscall is failing in file kexec/kexec.c
> 
> -
> Please help me in this regard,
> 
> Thanks in advance.

Hope this helps some.

Eric



___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Freeze problem

[Bernhard Walle]

Hi,

* Armin ranjbar <[EMAIL PROTECTED]> [2008-05-25 15:19]:
> 
> i have a problem with kexec , when i load a panic kernel with kexec -p
> which goes successful and panic the kernel using alt+sysrc+c , well ,
> nothing happens , system says that triggering a panic and it freezes . 
> note that the main kernel and crash kernel are the same and are
> relocate able . 
> .config of kernel http://pastebin.ca/1028714

Did you also try via serial console? Or vga=normal? Does the keyboard
LED work (i.e. toggle CapsLock and see if the LED is still
repsonding). VGA is a known problem when dumping, and often the panic
kernel just boots fine, only the user doesn't recognise.



Bernhard

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Freeze problem

[Armin ranjbar]

On Sun, 25 May 2008 13:07:32 +0200
Bernhard Walle <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> * Armin ranjbar <[EMAIL PROTECTED]> [2008-05-25 15:19]:
> > 
> > i have a problem with kexec , when i load a panic kernel with kexec -p
> > which goes successful and panic the kernel using alt+sysrc+c , well ,
> > nothing happens , system says that triggering a panic and it freezes . 
> > note that the main kernel and crash kernel are the same and are
> > relocate able . 
> > .config of kernel http://pastebin.ca/1028714
> 
> Did you also try via serial console? Or vga=normal? Does the keyboard
> LED work (i.e. toggle CapsLock and see if the LED is still
> repsonding). VGA is a known problem when dumping, and often the panic
> kernel just boots fine, only the user doesn't recognise.
> 
> 
> 
>   Bernhard
> 
> ___
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

Dear Bernhard

-- 
Armin ranjbar , System Administrator
i did tried vga=normal , still freezes , different is that the shell
cursor is still blinking , very strange . 
no panic like LED flashing , in fact no flashing at all .

its 2.6.25 , debian testing :) 

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Freeze problem

[Bernhard Walle]

* Armin ranjbar <[EMAIL PROTECTED]> [2008-05-25 17:03]:
>
> Armin ranjbar , System Administrator
> i did tried vga=normal , still freezes , different is that the shell
> cursor is still blinking , very strange . 
> no panic like LED flashing , in fact no flashing at all .

That's a hardware cursor, it always blinks. That doesn't mean anything.

However, you might try serial console to get a bit more diagnostic.
Also, please try (if you still use VGA)

   kexec --console-vga --debug -p /boot/vmlinux 

That gives a bit more diagnostics in purgatory code to see where the
system hangs. However, not sure if that also works when booting the
crashkernel. Can you try a normal kexec (with -l) first and see if that
works in your configuration?


Bernhard

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Freeze problem

[Armin ranjbar]

On Sun, 25 May 2008 15:27:20 +0200
Bernhard Walle <[EMAIL PROTECTED]> wrote:
>kexec --console-vga --debug -p /boot/vmlinux 
> 
> That gives a bit more diagnostics in purgatory code to see where the
> system hangs. However, not sure if that also works when booting the
> crashkernel. Can you try a normal kexec (with -l) first and see if that
> works in your configuration?

Yes thats works perfectly ( with -l ), 
you want result of that debug command if it failed or not ?

-- 
Armin ranjbar , System Administrator

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Freeze problem

[Armin ranjbar]

On Sun, 25 May 2008 18:19:54 +0430
> > That gives a bit more diagnostics in purgatory code to see where the
> > system hangs. However, not sure if that also works when booting the
> > crashkernel. Can you try a normal kexec (with -l) first and see if that
> > works in your configuration?

with debug and serial console output , result is the same, freeze .
by the way -d did  not print any more info than normal kexec run .

-- 
Armin ranjbar , System Administrator

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: doctor data

[boone]

Here are some of the USA contact databases we have for sale:

Physicians
Chiropractors
Alternative Medicine
Dentists
Veterinarians
Hospitals
Nursing Homes
Pharmaceutical Companies
Physical Therapists
Acupuncturists
Massage Therapists
Medical Equipment Suppliers
Mental Health Counselors
Visiting Nurses & RN's
Optometrists
Psychologists

Each list has many different fields including phone, fax, postal address, email 
and much more. I can give you any 3 of the above for $299. Email me at 
august...@bestandcheapest.us.
























To stop future email correspondence please send a blank email to 
rem...@bestandcheapest.us


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: ARM misdetection

[Simon Horman]

On Thu, Oct 01, 2009 at 03:34:01PM +0200, Andrea Adami wrote:
> Hello,
> 
> Building kexec-tools_2.0.1 against glibc for armv5te I found out the
> code in kexec/phys_arch.c can lead to arch misdetection.
> The uname's output of my kernel is "armv5tel" and this won't match the
> string "arm".
> 
> I added a patch to the OpenEmbedded buildsystem following the example
> in the old kexec-tools-arm.patch (arch_compat_trampoline).
> 
> http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/kexec/files/fix-arm-arch-detection.patch
> 
> Other than adding some overhead for other archies, it just seems to work.

Extra blank lines and {} aside, this seems like a reasonable approach to me,
Could you submit it to this list with a Signed-off-by line[1]?

[1] http://linux.yyz.us/patch-format.html



___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: MD Lists

[Brenda Clifford]

Certified MDs in the United States 

788,586 in total <> 17,647 emails

34 primary and secondary specialties

Can easily be sorted by 16 different fields

Price for this week only =  $397


<><><> Take all 4 items below for F REE when you order <><><>

US Pharmaceutical Company Executives Listing
47,000 names and emails of the major positions

Database of US Hospitals
23,000 Admins in more than 7,000 hospitals {a $399 value]

Contact List of US Dentists
A complete Database or dentists and related services (valued at $399)

Directory of US Chiropractors
100,000 Chiropractors in the USA (worth $250 alone)

reply to:  mine...@listpro.co.cc

  

sale for THIS WEEK ONLY


By emailing e...@listpro.co.cc you will have your email taken off




___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Jin, Yanjiang]

Hi Bhupesh,

1.  To be clearer, I listed my memory layout again here:

In the first kernel, execute the below command to get the last virtual memory:

#dmesg | grep memory
..
memory  : 0x8020 - 0x8018

The use readelf to get the last Program Header from vmcore:

# readelf -l vmcore

ELF Header:


Program Headers:
  Type   Offset VirtAddr   PhysAddr 
FileSizMemSiz  Flags  Align
..
  LOAD0x76d4 0x80017fe0 0x00018000  
   0x00168000 0x00168000  RWE0

Do a simple calculation:

(VirtAddr + MemSiz) = 0x80017fe0 + 0x00168000 = 
0x8017FFE0 != 0x8018.

The end virtual memory node are mismatch between vmlinux and vmcore. If you do 
the same 3 steps, I think you will get the same results as mine.


2. But why you can’t reproduce my issue? The reason is my address of symbol 
“log_buf” is located in the last 2M.
I guess it isn’t in the last 2M bytes on your environment, so we get the 
different vmcore-dmesg results.
You can simply check the log_buf’s address through crash as below:

crash> print log_buf
$1 = 0x8017ffe9 ""

In vmcore-dmesg.c, the function dump_dmesg_structured() wants to get log_buf 
offset through the below codes:

log_buf_offset = read_file_pointer(fd, vaddr_to_offset(log_buf_vaddr));
log_buf_offset = vaddr_to_offset(log_buf);

Error happens in vaddr_to_offset(), it reports the below error on my board:
“No program header covering vaddr 0x8017ffe9 found kexec bug?”

If I adjust my memory’s layout, don’t put log_buf into the last 2M, 
vmcore-dmesg will succeed. But this issue still exists, vmlinux and vmcore’s 
layouts are mismatch.

log_buf in the last 2M is not common, but it does happen on my board.


3. Now let's go back to the code itself. No matter we can reproduce this bug or 
not, phys_offset’s code’s issue always exists.

In kernel:
arm64_memblock_init() calls round_down to recalculate memstart_addr:

memstart_addr = round_down(memblock_start_of_DRAM(),  ARM64_MEMSTART_ALIGN);

memblock_start_of_DRAM() is 0x20, it is the first memblock’s base.
ARM64_MEMSTART_ALIGN is 0x4000 on my board.

So memstart_addr is 0, and phys_offset = memstart_addr = 0;

But in kexec-tools:
phys_offset is set in the function get_memory_ranges_iomem_cb() :

get_memory_ranges_iomem_cb()->set_phys_offset().

This function is just get the first memblock’s base(first block of 
“/proc/iomem”), no round_down() operation.

To align with kernel, kexec-tools should call the similar round_down() function 
for this base. But obviously, kexec-tools doesn’t do this step.
It’s hard to get kernel’s round_down parameters in kexec-tools, but read 
memstart_addr’s value from DEVMEM is safe, we can always get the correct value 
regardless of whether KASLR is enabled.

Thanks!
Yanjiang

> -Original Message-
> From: Bhupesh Sharma [mailto:bhsha...@redhat.com]
> Sent: 2018年5月30日 23:56
> To: Jin, Yanjiang ; Pratyush Anand
> 
> Cc: kexec@lists.infradead.org; jinyanji...@gmail.com; ho...@verge.net.au;
> Zheng, Joey 
> Subject: [此邮件可能存在风险] Re: [PATCH] arm64: update PHYS_OFFSET to
> conform to kernel
>
> On 05/30/2018 03:50 PM, Jin, Yanjiang wrote:
> >
> >
> >> -Original Message-
> >> From: Bhupesh Sharma [mailto:bhsha...@redhat.com]
> >> Sent: 2018年5月30日 16:39
> >> To: Jin, Yanjiang ; Pratyush Anand
> >> 
> >> Cc: kexec@lists.infradead.org; jinyanji...@gmail.com;
> >> ho...@verge.net.au; Zheng, Joey 
> >> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
> >>
> >> Hi Yanjiang,
> >>
> >> On 05/30/2018 01:09 PM, Jin, Yanjiang wrote:
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Pratyush Anand [mailto:pratyush.an...@gmail.com]
> >>>> Sent: 2018年5月30日 12:16
> >>>> To: Jin, Yanjiang 
> >>>> Cc: kexec@lists.infradead.org; jinyanji...@gmail.com;
> >>>> ho...@verge.net.au
> >>>> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
> >>>>
> >>>> Hi Yanjiang,
> >>>>
> >>>> On Wed, May 30, 2018 at 8:33 AM, Jin, Yanjiang
> >>>> 
> >>>> wrote:
> >>>>> Hi Pratyush,
> >>>>>
> >>>>> Thanks for your help! but please see my reply inline.
> >>>>>
> >>>>
> >>>> [...]
> >>>>
> >>

Re: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Pratyush Anand]

On Thu, May 31, 2018 at 11:01 AM, Jin, Yanjiang
 wrote:
> Hi Bhupesh,
>
> 1.  To be clearer, I listed my memory layout again here:
>
> In the first kernel, execute the below command to get the last virtual memory:
>
> #dmesg | grep memory
> ..
> memory  : 0x8020 - 0x8018
>
> The use readelf to get the last Program Header from vmcore:
>
> # readelf -l vmcore
>
> ELF Header:
> 
>
> Program Headers:
>   Type   Offset VirtAddr   PhysAddr   
>   FileSizMemSiz  Flags  Align
> ..
>   LOAD0x76d4 0x80017fe0 0x00018000
>  0x00168000 0x00168000  RWE0
>
> Do a simple calculation:
>
> (VirtAddr + MemSiz) = 0x80017fe0 + 0x00168000 = 
> 0x8017FFE0 != 0x8018.
>
> The end virtual memory node are mismatch between vmlinux and vmcore. If you 
> do the same 3 steps, I think you will get the same results as mine.
>
>
> 2. But why you can’t reproduce my issue? The reason is my address of symbol 
> “log_buf” is located in the last 2M.
> I guess it isn’t in the last 2M bytes on your environment, so we get the 
> different vmcore-dmesg results.
> You can simply check the log_buf’s address through crash as below:
>
> crash> print log_buf
> $1 = 0x8017ffe9 ""
>
> In vmcore-dmesg.c, the function dump_dmesg_structured() wants to get log_buf 
> offset through the below codes:
>
> log_buf_offset = read_file_pointer(fd, vaddr_to_offset(log_buf_vaddr));
> log_buf_offset = vaddr_to_offset(log_buf);
>
> Error happens in vaddr_to_offset(), it reports the below error on my board:
> “No program header covering vaddr 0x8017ffe9 found kexec bug?”

OK, so it happened because Virtual Address programmed in PT_LOAD was
not correct in kexec-tools.

>
> If I adjust my memory’s layout, don’t put log_buf into the last 2M, 
> vmcore-dmesg will succeed. But this issue still exists, vmlinux and vmcore’s 
> layouts are mismatch.
>
> log_buf in the last 2M is not common, but it does happen on my board.

OK.

>
>
> 3. Now let's go back to the code itself. No matter we can reproduce this bug 
> or not, phys_offset’s code’s issue always exists.
>
> In kernel:
> arm64_memblock_init() calls round_down to recalculate memstart_addr:
>
> memstart_addr = round_down(memblock_start_of_DRAM(),  ARM64_MEMSTART_ALIGN);
>
> memblock_start_of_DRAM() is 0x20, it is the first memblock’s base.
> ARM64_MEMSTART_ALIGN is 0x4000 on my board.
>
> So memstart_addr is 0, and phys_offset = memstart_addr = 0;

Humm, OK, so your PHYS_OFFSET is not same as the lowest start address
in /proc/iomem. So, we may always have problem, when start of DRAM is
neither 0 nor multiple of ARM64_MEMSTART_ALIGN.

>
> But in kexec-tools:
> phys_offset is set in the function get_memory_ranges_iomem_cb() :
>
> get_memory_ranges_iomem_cb()->set_phys_offset().
>
> This function is just get the first memblock’s base(first block of 
> “/proc/iomem”), no round_down() operation.
>
> To align with kernel, kexec-tools should call the similar round_down() 
> function for this base. But obviously, kexec-tools doesn’t do this step.
> It’s hard to get kernel’s round_down parameters in kexec-tools, but read 
> memstart_addr’s value from DEVMEM is safe, we can always get the correct 
> value regardless of whether KASLR is enabled.

Reading from /dev/mem is not a good idea, because of simple reason
that /dev/mem may not be available in all the cases.
We can have one way or another to know ARM64_MEMSTART_ALIGN in user
space. For example, by looking after top bits of _text, we can know
the VA_BITS. If we know the VA_BITS, we can know the page table size
and level, and so can now PUD_SHIFT etc. But, that may not be the
solution when KASLR is enabled.

Lets see what others says. I think on the same line as Bhupesh had
said. We will need it to fix in kexec-tools as well as kernel.

IMO,  kexec-tools may write only real physical address in PT_LOAD and
can write an invalid (0) virtual address (if it is not able to
calculate the same correctly). Kernel can update the virtual address
with correct value if it is invalid.

Regards
Pratyush

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Bhupesh Sharma]

e in the user-space side) e.g. makedumpfile in
addition to kexec-tools to correctly handle this unique use-case where
we have value of memblock_start_of_DRAM() < ARM64_MEMSTART_ALIGN

[1] https://www.spinics.net/lists/arm-kernel/msg655933.html

Thanks,
Bhupesh


>
>> -Original Message-
>> From: Bhupesh Sharma [mailto:bhsha...@redhat.com]
>> Sent: 2018年5月30日 23:56
>> To: Jin, Yanjiang ; Pratyush Anand
>> 
>> Cc: kexec@lists.infradead.org; jinyanji...@gmail.com; ho...@verge.net.au;
>> Zheng, Joey 
>> Subject: [此邮件可能存在风险] Re: [PATCH] arm64: update PHYS_OFFSET to
>> conform to kernel
>>
>> On 05/30/2018 03:50 PM, Jin, Yanjiang wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Bhupesh Sharma [mailto:bhsha...@redhat.com]
>> >> Sent: 2018年5月30日 16:39
>> >> To: Jin, Yanjiang ; Pratyush Anand
>> >> 
>> >> Cc: kexec@lists.infradead.org; jinyanji...@gmail.com;
>> >> ho...@verge.net.au; Zheng, Joey 
>> >> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
>> >>
>> >> Hi Yanjiang,
>> >>
>> >> On 05/30/2018 01:09 PM, Jin, Yanjiang wrote:
>> >>>
>> >>>
>> >>>> -Original Message-
>> >>>> From: Pratyush Anand [mailto:pratyush.an...@gmail.com]
>> >>>> Sent: 2018年5月30日 12:16
>> >>>> To: Jin, Yanjiang 
>> >>>> Cc: kexec@lists.infradead.org; jinyanji...@gmail.com;
>> >>>> ho...@verge.net.au
>> >>>> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
>> >>>>
>> >>>> Hi Yanjiang,
>> >>>>
>> >>>> On Wed, May 30, 2018 at 8:33 AM, Jin, Yanjiang
>> >>>> 
>> >>>> wrote:
>> >>>>> Hi Pratyush,
>> >>>>>
>> >>>>> Thanks for your help! but please see my reply inline.
>> >>>>>
>> >>>>
>> >>>> [...]
>> >>>>
>> >>>>>>> If an application, for example, vmcore-dmesg, wants to access
>> >>>>>>> the kernel symbol which is located in the last 2M address, it
>> >>>>>>> would fail with the below error:
>> >>>>>>>
>> >>>>>>> "No program header covering vaddr 0x8017ffe9 found
>> >>>>>>> kexec
>> >> bug?"
>> >>>>>>
>> >>>>>> I think, fix might not be correct.
>> >>>>>>
>> >>>>>> Problem is in vmcore-dmesg and that should be fixed and not the kexec.
>> >>>>>> See here
>> >>>>>> (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-
>> >>>>>> tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261).
>> >>>>>
>> >>>>> Firstly, for my patch, vmcore-dmesg is just an auxiliary
>> >>>>> application to help to
>> >>>> reproduce this issue. The function, which is to generate vmcore,
>> >>>> is the root
>> >> cause.
>> >>>>
>> >>>> ...and the function which generates vmcore is not the kexec rather
>> >>>> the secondary kernel.
>> >>>>
>> >>>>>
>> >>>>> On the other hand, vmcore-dmesg is under kexec-tools, it has no a
>> >>>>> standalone
>> >>>> git repo.  Even we want to fix vmcore-dmesg, we still need to send
>> >>>> the patch to kexec-tools, right?
>> >>>>
>> >>>> Sure. I meant `kexec` application. We have three applications in 
>> >>>> kexec-tools.
>> >>>> `kexec`, `vmcore-dmesg` and `kdump`. [I hope kdump is useless and
>> >>>> we are going to get rid off it very soon.]
>> >>>>
>> >>>>>
>> >>>>> Yanjiang
>> >>>>>
>> >>>>>> How symbols are extracted from vmcore.
>> >>>>>>
>> >>>>>> You do have "NUMBER(PHYS_OFFSET)=" information in vmcore.
>> >>>>>>
>> >>>>>> You can probably see makedumpfile code, that how to extract
>> >>>>>> information from "NUMBER".
>> >>>>>
>> >>>>> I 

Re: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel

[Bhupesh Sharma]

end to calculate 'memstart_addr' as:
>
> /*
>  * Select a suitable value for the base of physical memory.
>  */
> memstart_addr = round_down(memblock_start_of_DRAM(),
>ARM64_MEMSTART_ALIGN);
> if (memstart_addr)

Sorry for the typo: I meant if (!memstart_addr) above

Thanks,
Bhupesh

> memstart_addr = memblock_start_of_DRAM();
>
> Let's wait for an update from the ARM64 kernel maintainers, because I
> think this change might be needed in other user-space tools (if we
> decide to make the change in the user-space side) e.g. makedumpfile in
> addition to kexec-tools to correctly handle this unique use-case where
> we have value of memblock_start_of_DRAM() < ARM64_MEMSTART_ALIGN
>
> [1] https://www.spinics.net/lists/arm-kernel/msg655933.html
>
> Thanks,
> Bhupesh
>
>
>>
>>> -Original Message-
>>> From: Bhupesh Sharma [mailto:bhsha...@redhat.com]
>>> Sent: 2018年5月30日 23:56
>>> To: Jin, Yanjiang ; Pratyush Anand
>>> 
>>> Cc: kexec@lists.infradead.org; jinyanji...@gmail.com; ho...@verge.net.au;
>>> Zheng, Joey 
>>> Subject: [此邮件可能存在风险] Re: [PATCH] arm64: update PHYS_OFFSET to
>>> conform to kernel
>>>
>>> On 05/30/2018 03:50 PM, Jin, Yanjiang wrote:
>>> >
>>> >
>>> >> -Original Message-
>>> >> From: Bhupesh Sharma [mailto:bhsha...@redhat.com]
>>> >> Sent: 2018年5月30日 16:39
>>> >> To: Jin, Yanjiang ; Pratyush Anand
>>> >> 
>>> >> Cc: kexec@lists.infradead.org; jinyanji...@gmail.com;
>>> >> ho...@verge.net.au; Zheng, Joey 
>>> >> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
>>> >>
>>> >> Hi Yanjiang,
>>> >>
>>> >> On 05/30/2018 01:09 PM, Jin, Yanjiang wrote:
>>> >>>
>>> >>>
>>> >>>> -Original Message-
>>> >>>> From: Pratyush Anand [mailto:pratyush.an...@gmail.com]
>>> >>>> Sent: 2018年5月30日 12:16
>>> >>>> To: Jin, Yanjiang 
>>> >>>> Cc: kexec@lists.infradead.org; jinyanji...@gmail.com;
>>> >>>> ho...@verge.net.au
>>> >>>> Subject: Re: [PATCH] arm64: update PHYS_OFFSET to conform to kernel
>>> >>>>
>>> >>>> Hi Yanjiang,
>>> >>>>
>>> >>>> On Wed, May 30, 2018 at 8:33 AM, Jin, Yanjiang
>>> >>>> 
>>> >>>> wrote:
>>> >>>>> Hi Pratyush,
>>> >>>>>
>>> >>>>> Thanks for your help! but please see my reply inline.
>>> >>>>>
>>> >>>>
>>> >>>> [...]
>>> >>>>
>>> >>>>>>> If an application, for example, vmcore-dmesg, wants to access
>>> >>>>>>> the kernel symbol which is located in the last 2M address, it
>>> >>>>>>> would fail with the below error:
>>> >>>>>>>
>>> >>>>>>> "No program header covering vaddr 0x8017ffe9 found
>>> >>>>>>> kexec
>>> >> bug?"
>>> >>>>>>
>>> >>>>>> I think, fix might not be correct.
>>> >>>>>>
>>> >>>>>> Problem is in vmcore-dmesg and that should be fixed and not the 
>>> >>>>>> kexec.
>>> >>>>>> See here
>>> >>>>>> (https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-
>>> >>>>>> tools.git/tree/vmcore-dmesg/vmcore-dmesg.c?id=HEAD#n261).
>>> >>>>>
>>> >>>>> Firstly, for my patch, vmcore-dmesg is just an auxiliary
>>> >>>>> application to help to
>>> >>>> reproduce this issue. The function, which is to generate vmcore,
>>> >>>> is the root
>>> >> cause.
>>> >>>>
>>> >>>> ...and the function which generates vmcore is not the kexec rather
>>> >>>> the secondary kernel.
>>> >>>>
>>> >>>>>
>>> >>>>> On the other hand, vmcore-dmesg is under kexec-tools, it has no a
>>> >>>>> standalone
>>> >>>> git repo.  

Fwd: RE: Fwd: Re: makedumpfile security key enhancement using SIAL

[Aravinda Prasad]

Thanks Luc. We will let you know if in case we need any info/help.

I am also forwarding this mail to kexec mailing list.

Regards,
Aravinda


 Original Message 
Subject: RE: Fwd: Re: makedumpfile security key enhancement using SIAL
Date: Wed, 28 Mar 2012 07:07:49 -0400
From: Luc Chouinard 
To: Aravinda Prasad 

 Libsial is meant to be a pluggable entity and as such should not 
require other pieces to be there ( crash or gdb).
I want to create project and associated git for the library soon. For 
now you can extract libsial from the crash tar ball and manage any 
modifications using a simple patch mechanism. When the git is available, 
we can merge any fixes or enhancements you created for support of 
makedumpfile.


Makedumpfile and crash would then feed off of specific branches/versions 
of the git repository.
If you have any suggestions or want to help in setting up a public git / 
project page for sial, please let me know.



   -Luc


-Original Message-
From: Aravinda Prasad [mailto:aravi...@linux.vnet.ibm.com]
Sent: Wednesday, March 28, 2012 1:31 AM
To: Luc Chouinard
Subject: Fwd: Fwd: Re: makedumpfile security key enhancement using SIAL

Forwarding to your s2sys email ID. Details in mail forward.

Regards,
Aravinda


 Original Message 
Subject: Fwd: Re: makedumpfile security key enhancement using SIAL
Date: Tue, 20 Mar 2012 17:28:21 +0530
From: Aravinda Prasad 
To: Luc Chouinard 
CC: Atsushi Kumagai ,  Masaki Tachibana
, Mahesh J Salgaonkar
,  Ananth N Mavinakayanahalli
, Dave Anderson 

Hi Luc,

We are looking for utilising SIAL as a language construct for the makedumpfile
kernel data filtering from vmcore feature. The details of which are in the mail
forward.

The proposed enhancement will require libsial.a and as SIAL is not currently
built/shipped, we are looking for possibilities on how libsial.a can be made
available to makedumpfile. Please let us know your opinion on the same.

Regards,
Aravinda


 Original Message 
Subject: Re: makedumpfile security key enhancement using SIAL
Date: Tue, 13 Mar 2012 10:27:43 -0400 (EDT)
From: Dave Anderson 
To: Aravinda Prasad 
CC: Atsushi Kumagai , Masaki
Tachibana ,Ananth N
Mavinakayanahalli ,Mahesh J Salgaonkar




- Original Message -
> Hi Dave,
>
> Last year, we worked on the makedumpfile security key filtering where
> we added support to filter out kernel data from vmcore. This year, we
> are working on enhancing the framework to provide more flexibility for
> the customers to specify rules to traverse and filter out kernel data
> - for which we are planning to use SIAL.
>
> We are looking into using SIAL as language construct to specify
> rules/commands to erase data in the image file. The makedumpfile would
> interpret the rules provided in SIAL macro using SIAL library (which
> could be dynamically loaded) and erase out suitable data in the vmcore.
> We are planning to reuse SIAL as it provides a C language like
> construct, which is flexible and powerful enough to specify rules to
> erase data in vmcore.
>
> As SIAL is not built and shipped along with crash, we are looking for
> possibilities on how SIAL can be leveraged by makedumpfile and would
> like to know your opinion.

Sorry but I cannot give you any help with SIAL.  Luc Chouinard is the maintainer
of the SIAL extension module adaptation for the crash utility, and he can answer
your questions w/respect to adapting it for makedumpfile.
And ultimately, that's a question for the makedumpfile maintainers.

Dave



___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Re: linux-next: Tree for Dec 1 (riscv, crash_core)

[Baoquan He]

eric_devol...@yahoo.com, ig...@cloudflare.com,
Linux Next Mailing List ,
Linux Kernel Mailing List ,
linux-riscv ,
kexec 
Bcc: b...@redhat.com
Subject: Re: linux-next: Tree for Dec 1 (riscv, crash_core)
Reply-To: 
In-Reply-To: 

On 12/01/23 at 11:53am, Randy Dunlap wrote:
> 
> 
> On 11/30/23 18:37, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20231130:
> > 
> 
> on riscv 32-bit or 64-bit, with
> # CONFIG_MMU is not set

Thanks for providing the kernel config to ease reproduction. In the config,
there are:

CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_CRASH_DUMP=y
..
# CONFIG_MMU is not set

After investigation, I found this happened after Ignat's patch:
commit 1c7a3fa49ef7 ("kexec: drop dependency on ARCH_SUPPORTS_KEXEC from 
CRASH_DUMP")

Copy above commit change here for reference, and also risc-v's
ARCH_SUPPORTS_KEXEC depends on MMU:

diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
index fc38f1ae3a30..946dffa048b7 100644
--- a/kernel/Kconfig.kexec
+++ b/kernel/Kconfig.kexec
@@ -96,7 +96,6 @@ config KEXEC_JUMP
 config CRASH_DUMP
bool "kernel crash dumps"
depends on ARCH_SUPPORTS_CRASH_DUMP
-   depends on ARCH_SUPPORTS_KEXEC
select CRASH_CORE
select KEXEC_CORE
help

arch/riscv/Kconfig
-
config ARCH_SUPPORTS_KEXEC
def_bool MMU

Before Ignat's patch, once CONFIG_MMU is unset, CONFIG_CRASH_DUMP,
CONFIG_KEXEC_CORE, CONFIG_CRASH_CORE are all unset automatically. The
crash_core codes are not compiled. That's why no compiling error is
seen.

After Ignat's patch applied, we can enable CONFIG_CRASH_DUMP,
CONFIG_KEXEC_CORE, CONFIG_CRASH_CORE independently. However, there are
several macro definitions, such as VA_BITS, VMEMMAP_START, VMEMMAP_END,
MODULES_VADDR, MODULES_END are only available when CONFIG_MMU=y.

I made two patches to decouple the kexec/crash code with CONFIG_MMU. Not
sure if risc-v wants that.

Or we can simply add dependency on MMU for ARCH_SUPPORTS_CRASH_DUMP.
Then when CONFIG_MMU=n, CONFIG_CRASH_DUMP, CONFIG_KEXEC_CORE,
CONFIG_CRASH_CORE will be unset too. Please help check which one need be
taken.


diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 24c1799e2ec4..03d290da7262 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -708,6 +708,7 @@ config ARCH_SUPPORTS_KEXEC_PURGATORY
 
 config ARCH_SUPPORTS_CRASH_DUMP
def_bool y
+   depends on MMU=y
 
 config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
def_bool CRASH_CORE

> 
> In file included from ../arch/riscv/kernel/crash_core.c:3:
> ../arch/riscv/kernel/crash_core.c: In function 'arch_crash_save_vmcoreinfo':
> ../arch/riscv/kernel/crash_core.c:8:27: error: 'VA_BITS' undeclared (first 
> use in this function)
> 8 | VMCOREINFO_NUMBER(VA_BITS);
>   |   ^~~
> ../include/linux/crash_core.h:78:64: note: in definition of macro 
> 'VMCOREINFO_NUMBER'
>78 | vmcoreinfo_append_str("NUMBER(%s)=%ld\n", #name, (long)name)
>   |^~~~
> ../arch/riscv/kernel/crash_core.c:8:27: note: each undeclared identifier is 
> reported only once for each function it appears in
> 8 | VMCOREINFO_NUMBER(VA_BITS);
>   |   ^~~
> ../include/linux/crash_core.h:78:64: note: in definition of macro 
> 'VMCOREINFO_NUMBER'
>78 | vmcoreinfo_append_str("NUMBER(%s)=%ld\n", #name, (long)name)
>   |^~~~
> ../arch/riscv/kernel/crash_core.c:12:58: warning: format '%lx' expects 
> argument of type 'long unsigned int', but argument 2 has type 'int' 
> [-Wformat=]
>12 | vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", 
> VMALLOC_START);
>   |~~^
>   |  |
>   |  long 
> unsigned int
>   |%x
> ../arch/riscv/kernel/crash_core.c:14:64: error: 'VMEMMAP_START' undeclared 
> (first use in this function)
>14 | vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", 
> VMEMMAP_START);
>   |
> ^
> ../arch/riscv/kernel/crash_core.c:15:62: error: 'VMEMMAP_END' undeclared 
> (first use in this function); did you mean 'MEMREMAP_ENC'?
>15 | vmcoreinfo_append

Re: [Crash-utility] Re: handle x86_64 xen code/data relocation

[Dave Anderson]

Simon Horman wrote:
> On Tue, Apr 22, 2008 at 05:32:03PM +0900, Itsuro ODA wrote:
>> Hi all,
>>
>> Recent version of xen (ex. RHEL5.2, 3.2.0) on the x86_64
>> moves the physical(machine) address of xen code/data area after 
>> the system started up. The start address of this is stored in
>> 'xen_phys_start'. Thus to get a machine address of a xen text symbol
>> from its virtual address, calculate 
>> "va - __XEN_VIRT_START +  xen_phys_start".
>>
>> crash and makedumpfile command need the value of xen_phys_start.
>> They know the virtual address of 'xen_phys_start' symbol but
>> no way to extract the value of xen_phys_start.
>>
>> I think adding the xen_phys_start value to the CRASHINFO ElfNote
>> section at first. (Plan A: patch for xen hypervisor code attaced)
>> It is smallest modification necessary over all.
>>
>> On the other hand there is a opinion that it is better to upgrade
>> a user-package than a hypervisor or kernel package.
>> The xen_phys_start value can be got from /proc/iomem.
>> ---
>> # cat /proc/iomem
>> ...
>>   7e60-7f5f : Hypervisor code and data  *** this line
>> ...
>> ---
>> So the kexec-tools can handle it theoretically.
>>
>> The Plan B is that kexec-tools adds another ElfNote section which
>> holds the xen_phys_start value. The attached patch works well
>> though I am concern about it is a bit tricky.
>>
>> Which plan is better ?  Or more good implementation ?
>> Please comment.
>>
>> (note that crash and makedumpfile modification is same degree
>> for both plan.)
> 
> Hi Oda-san,
> 
> I think that in terms of simplicity plan A is a clear
> winner. That is assuming tha the changes to crash
> and makedumpfile are more or less the same for both
> plan A and plan B.
> 
> However, if there is a reason that it makes sense to include
> the change in kexec-tools and make a fresh release, I'm happy to do so.

I was the one who suggested a user-space alternative, but reconsidering it,
I also agree that plan A is preferable, primarily for simplicity's sake in
both kexec-tools (no changes) and in the crash utility (a couple lines that
have already been added in the latest version).

My original concern was the need to upgrade the hypervisor, but since that
time, we've put in a workaround for the crash utility to allow the
xen_phys_start value to be passed in as a command line argument.

Dave

> 
>> === Plan A (modify the xen hypervisor. It is for RHEL5.2 but almost same for 
>> other version) ===
>> --- include/xen/elfcore.h.org2008-04-17 14:11:41.0 +0900
>> +++ include/xen/elfcore.h2008-04-17 14:11:57.0 +0900
>> @@ -66,6 +66,7 @@
>>  unsigned long xen_compile_time;
>>  unsigned long tainted;
>>  #ifdef CONFIG_X86
>> +unsigned long xen_phys_start;
>>  unsigned long dom0_pfn_to_mfn_frame_list_list;
>>  #endif
>>  } crash_xen_info_t;
>> --- arch/x86/crash.c.org 2008-04-17 14:12:51.0 +0900
>> +++ arch/x86/crash.c 2008-04-17 14:13:13.0 +0900
>> @@ -102,6 +102,7 @@
>>  hvm_disable();
>>  
>>  info = kexec_crash_save_info();
>> +info->xen_phys_start = xen_phys_start;
>>  info->dom0_pfn_to_mfn_frame_list_list =
>>  arch_get_pfn_to_mfn_frame_list_list(dom0);
>>  }
>> 
>>
>> === Plan B (modify the kexec-tools. proof of concept version) ===
>> diff -ru 
>> kexec-tools-testing-20080324.org/kexec/arch/x86_64/crashdump-x86_64.c 
>> kexec-tools-testing-20080324/kexec/arch/x86_64/crashdump-x86_64.c
>> --- kexec-tools-testing-20080324.org/kexec/arch/x86_64/crashdump-x86_64.c
>> 2008-03-21 13:16:28.0 +0900
>> +++ kexec-tools-testing-20080324/kexec/arch/x86_64/crashdump-x86_64.c
>> 2008-04-22 15:15:08.0 +0900
>> @@ -73,6 +73,25 @@
>>  return -1;
>>  }
>>  
>> +static int get_hypervisor_paddr(struct kexec_info *info)
>> +{
>> +uint64_t start;
>> +
>> +if (!xen_present())
>> +return 0;
>> +
>> +if (parse_iomem_single("Hypervisor code and data\n", &start, NULL) == 
>> 0) {
>> +info->hypervisor_paddr_start = start;
>> +#ifdef DEBUG
>> +printf("kernel load physical addr start = 0x%016Lx\n", start);
>> +#endif
>> +return 0;
>> +}
>> +
>> +fprintf(stderr, "Cannot determine hypervisor physical load addr\n");
>> +return -1;
>> +}
>> +
>>  /* Retrieve info regarding virtual address kernel has been compiled for and
>>   * size of the kernel from /proc/kcore. Current /proc/kcore parsing from
>>   * from kexec-tools fails because of malformed elf notes. A kernel patch has
>> @@ -581,6 +600,9 @@
>>  if (get_kernel_paddr(info))
>>  return -1;
>>  
>> +if (get_hypervisor_paddr(info))
>> +return -1;
>> +
>>  if (get_kernel_vaddr_and_size(info))
>>  return -1;
>>  
>> @@ -620,6 +642,9 @@
>>

RE: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[河合英宏 / KAWAI，HIDEHIRO]

Hi,

> From: linux-kernel-ow...@vger.kernel.org 
> [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro Kawai
> (2015/07/27 23:34), Michal Hocko wrote:
> > On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
[...]
> > The check could be also relaxed a bit and nmi_panic would
> > return only if the ongoing panic is the current cpu when we really have
> > to return and allow the preempted panic to finish.
> 
> It's reasonable.  I'll do that in the next version.

I noticed atomic_read() is insufficient.  Please consider the following
scenario.

CPU 1: call panic() in the normal context
CPU 0: call nmi_panic(), check the value of panic_cpu, then call panic()
CPU 1: set 1 to panic_cpu
CPU 0: fail to set 0 to panic_cpu, then do an infinite loop
CPU 1: call crash_kexec(), then call kdump_nmi_shootdown_cpus()

At this point, since CPU 0 loops in NMI context, it never executes
the NMI handler registered by kdump_nmi_shootdown_cpus().  This means
that no register states are saved and no cleanups for VMX/SVM are
performed.  So, we should still use atomic_cmpxchg() in nmi_panic() to
prevent other cpus from running panic routines.

> > +void nmi_panic(const char *fmt, ...)
> > +{
> > +   /*
> > +* We have to back off if the NMI has preempted an ongoing panic and
> > +* allow it to finish
> > +*/
> > +   if (atomic_read(&panic_cpu) == raw_smp_processor_id())
> > +   return;
> > +
> > +   panic();
> > +}
> > +EXPORT_SYMBOL(nmi_panic);


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[Michal Hocko]

On Wed 29-07-15 05:48:47, 河合英宏 / KAWAI，HIDEHIRO wrote:
> Hi,
> 
> > From: linux-kernel-ow...@vger.kernel.org 
> > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro Kawai
> > (2015/07/27 23:34), Michal Hocko wrote:
> > > On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
> [...]
> > > The check could be also relaxed a bit and nmi_panic would
> > > return only if the ongoing panic is the current cpu when we really have
> > > to return and allow the preempted panic to finish.
> > 
> > It's reasonable.  I'll do that in the next version.
> 
> I noticed atomic_read() is insufficient.  Please consider the following
> scenario.
> 
> CPU 1: call panic() in the normal context
> CPU 0: call nmi_panic(), check the value of panic_cpu, then call panic()
> CPU 1: set 1 to panic_cpu
> CPU 0: fail to set 0 to panic_cpu, then do an infinite loop
> CPU 1: call crash_kexec(), then call kdump_nmi_shootdown_cpus()
> 
> At this point, since CPU 0 loops in NMI context, it never executes
> the NMI handler registered by kdump_nmi_shootdown_cpus().  This means
> that no register states are saved and no cleanups for VMX/SVM are
> performed.

Yes this is true but it is no different from the current state, isn't
it? So if you want to handle that then it deserves a separate patch.
It is certainly not harmful wrt. panic behavior.

> So, we should still use atomic_cmpxchg() in nmi_panic() to
> prevent other cpus from running panic routines.

Not sure what you mean by that.

-- 
Michal Hocko
SUSE Labs

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[河合英宏 / KAWAI，HIDEHIRO]

> From: Michal Hocko [mailto:mho...@kernel.org]
> On Wed 29-07-15 05:48:47, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Hi,
> >
> > > From: linux-kernel-ow...@vger.kernel.org 
> > > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro Kawai
> > > (2015/07/27 23:34), Michal Hocko wrote:
> > > > On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
> > [...]
> > > > The check could be also relaxed a bit and nmi_panic would
> > > > return only if the ongoing panic is the current cpu when we really have
> > > > to return and allow the preempted panic to finish.
> > >
> > > It's reasonable.  I'll do that in the next version.
> >
> > I noticed atomic_read() is insufficient.  Please consider the following
> > scenario.
> >
> > CPU 1: call panic() in the normal context
> > CPU 0: call nmi_panic(), check the value of panic_cpu, then call panic()
> > CPU 1: set 1 to panic_cpu
> > CPU 0: fail to set 0 to panic_cpu, then do an infinite loop
> > CPU 1: call crash_kexec(), then call kdump_nmi_shootdown_cpus()
> >
> > At this point, since CPU 0 loops in NMI context, it never executes
> > the NMI handler registered by kdump_nmi_shootdown_cpus().  This means
> > that no register states are saved and no cleanups for VMX/SVM are
> > performed.
> 
> Yes this is true but it is no different from the current state, isn't
> it? So if you want to handle that then it deserves a separate patch.
> It is certainly not harmful wrt. panic behavior.
> 
> > So, we should still use atomic_cmpxchg() in nmi_panic() to
> > prevent other cpus from running panic routines.
> 
> Not sure what you mean by that.

I mean that we should use the same logic as my V2 patch like this:

#define nmi_panic(fmt, ...)\
   do {\
   if (atomic_cmpxchg(&panic_cpu, -1, raw_smp_processor_id()) \
   == -1)  \
   panic(fmt, ##__VA_ARGS__);  \
   } while (0)

By using atomic_cmpxchg here, we can ensure that only this cpu
runs panic routines.  It is important to prevent a NMI-context cpu
from calling panic_smp_self_stop(). 

void panic(const char *fmt, ...)
{
...
* `old_cpu == -1' means we are the first comer.
* `old_cpu == this_cpu' means we came here due to panic on NMI.
*/
   this_cpu = raw_smp_processor_id();
   old_cpu = atomic_cmpxchg(&panic_cpu, -1, this_cpu);
   if (old_cpu != -1 && old_cpu != this_cpu)
panic_smp_self_stop();

Please assume that CPU 0 calls nmi_panic() in NMI context
and CPU 1 calls panic() in normal context at tha same time.

If CPU 1 set panic_cpu before CPU 0 does, CPU 1 runs panic routines
and CPU 0 return from the nmi handler.  Eventually CPU 0 is stopped
by nmi_shootdown_cpus().

If CPU 0 set panic_cpu before CPU 1 does, CPU 0 runs panic routines.
CPU 1 calls panic_smp_self_stop(), and wait for NMI by
nmi_shootdown_cpus().

Anyway, I tested my approach and it worked fine.

Regards,
Kawai

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[Michal Hocko]

On Wed 29-07-15 09:09:18, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > From: Michal Hocko [mailto:mho...@kernel.org]
> > On Wed 29-07-15 05:48:47, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > Hi,
> > >
> > > > From: linux-kernel-ow...@vger.kernel.org 
> > > > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro Kawai
> > > > (2015/07/27 23:34), Michal Hocko wrote:
> > > > > On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
> > > [...]
> > > > > The check could be also relaxed a bit and nmi_panic would
> > > > > return only if the ongoing panic is the current cpu when we really 
> > > > > have
> > > > > to return and allow the preempted panic to finish.
> > > >
> > > > It's reasonable.  I'll do that in the next version.
> > >
> > > I noticed atomic_read() is insufficient.  Please consider the following
> > > scenario.
> > >
> > > CPU 1: call panic() in the normal context
> > > CPU 0: call nmi_panic(), check the value of panic_cpu, then call panic()
> > > CPU 1: set 1 to panic_cpu
> > > CPU 0: fail to set 0 to panic_cpu, then do an infinite loop
> > > CPU 1: call crash_kexec(), then call kdump_nmi_shootdown_cpus()
> > >
> > > At this point, since CPU 0 loops in NMI context, it never executes
> > > the NMI handler registered by kdump_nmi_shootdown_cpus().  This means
> > > that no register states are saved and no cleanups for VMX/SVM are
> > > performed.
> > 
> > Yes this is true but it is no different from the current state, isn't
> > it? So if you want to handle that then it deserves a separate patch.
> > It is certainly not harmful wrt. panic behavior.
> > 
> > > So, we should still use atomic_cmpxchg() in nmi_panic() to
> > > prevent other cpus from running panic routines.
> > 
> > Not sure what you mean by that.
> 
> I mean that we should use the same logic as my V2 patch like this:
> 
> #define nmi_panic(fmt, ...)\
>do {\
>if (atomic_cmpxchg(&panic_cpu, -1, raw_smp_processor_id()) \
>== -1)  \
>panic(fmt, ##__VA_ARGS__);  \
>} while (0)

This would allow to return from NMI too eagerly. When I was testing my
previous approach (on 3.0 based kernel) I had basically the same thing
(one NMI to process panic) and others to return. This led to a strange
behavior when the NMI button triggered NMI on all (hundreds) CPUs. The
crash kernel booted eventually but the log contained lockups when a
CPU waited for an IPI to the CPU which was handling the NMI panic.

Anyway, I do not thing this is really necessary to solve the panic
reentrancy issue. If the missing saved state is a real problem then it
should be handled separately - maybe it can be achieved without an IPI
and directly from the panic context if we are in NMI.
-- 
Michal Hocko
SUSE Labs

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[河合英宏 / KAWAI，HIDEHIRO]

Hi,

> From: Michal Hocko [mailto:mho...@kernel.org]
> 
> On Wed 29-07-15 09:09:18, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > From: Michal Hocko [mailto:mho...@kernel.org]
> > > On Wed 29-07-15 05:48:47, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > Hi,
> > > >
> > > > > From: linux-kernel-ow...@vger.kernel.org 
> > > > > [mailto:linux-kernel-ow...@vger.kernel.org] On Behalf Of Hidehiro 
> > > > > Kawai
> > > > > (2015/07/27 23:34), Michal Hocko wrote:
> > > > > > On Mon 27-07-15 10:58:50, Hidehiro Kawai wrote:
> > > > [...]
> > > > > > The check could be also relaxed a bit and nmi_panic would
> > > > > > return only if the ongoing panic is the current cpu when we really 
> > > > > > have
> > > > > > to return and allow the preempted panic to finish.
> > > > >
> > > > > It's reasonable.  I'll do that in the next version.
> > > >
> > > > I noticed atomic_read() is insufficient.  Please consider the following
> > > > scenario.
> > > >
> > > > CPU 1: call panic() in the normal context
> > > > CPU 0: call nmi_panic(), check the value of panic_cpu, then call panic()
> > > > CPU 1: set 1 to panic_cpu
> > > > CPU 0: fail to set 0 to panic_cpu, then do an infinite loop
> > > > CPU 1: call crash_kexec(), then call kdump_nmi_shootdown_cpus()
> > > >
> > > > At this point, since CPU 0 loops in NMI context, it never executes
> > > > the NMI handler registered by kdump_nmi_shootdown_cpus().  This means
> > > > that no register states are saved and no cleanups for VMX/SVM are
> > > > performed.
> > >
> > > Yes this is true but it is no different from the current state, isn't
> > > it? So if you want to handle that then it deserves a separate patch.
> > > It is certainly not harmful wrt. panic behavior.
> > >
> > > > So, we should still use atomic_cmpxchg() in nmi_panic() to
> > > > prevent other cpus from running panic routines.
> > >
> > > Not sure what you mean by that.
> >
> > I mean that we should use the same logic as my V2 patch like this:
> >
> > #define nmi_panic(fmt, ...)\
> >do {\
> >if (atomic_cmpxchg(&panic_cpu, -1, raw_smp_processor_id()) \
> >== -1)  \
> >panic(fmt, ##__VA_ARGS__);  \
> >} while (0)
> 
> This would allow to return from NMI too eagerly.

Yes, but what's the problem?
The root cause of your case hasn't been clarified yet.
I can't fix for an unclear issue because I don't know what's the right
solution.

> When I was testing my
> previous approach (on 3.0 based kernel) I had basically the same thing
> (one NMI to process panic) and others to return. This led to a strange
> behavior when the NMI button triggered NMI on all (hundreds) CPUs.

It's strange.  Usually, NMI caused by NMI button is routed to only CPU 0
as an external NMI.  External NMI for CPUs other than CPU 0 are masked
at boot time.  Does it really happen?  Does the problem still happen on
the latest kernel?  What kind of NMI is deliverd to each CPU?

Traditionally, we should have assumed that NMI for crash dumping is
delivered to only one cpu.  Otherwise, we should often fail to take
a proper crash dump.  It seems that your case is another problem to be
solved separately.

> The
> crash kernel booted eventually but the log contained lockups when a
> CPU waited for an IPI to the CPU which was handling the NMI panic.

Could you explain more precisely?

> Anyway, I do not thing this is really necessary to solve the panic
> reentrancy issue.
> If the missing saved state is a real problem then it
> should be handled separately - maybe it can be achieved without an IPI
> and directly from the panic context if we are in NMI.

What I would like to do via this patchse is to solve race issues
among NMI, panic() and crash_kexec().  So, I don't think we should fix
that separately, although I would need to reword some descriptions
and titles.

Anyway, I'm going to sent out my revised version once in order to
tidy up.  I also would like to hear kexec/kdump guys' opinions.

Regards,
Kawai

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[河合英宏 / KAWAI，HIDEHIRO]

Hi Michal,

> From: 河合英宏 / KAWAI，HIDEHIRO [mailto:hidehiro.kawai...@hitachi.com]
> > When I was testing my
> > previous approach (on 3.0 based kernel) I had basically the same thing
> > (one NMI to process panic) and others to return. This led to a strange
> > behavior when the NMI button triggered NMI on all (hundreds) CPUs.
> 
> It's strange.  Usually, NMI caused by NMI button is routed to only CPU 0
> as an external NMI.  External NMI for CPUs other than CPU 0 are masked
> at boot time.  Does it really happen?  Does the problem still happen on
> the latest kernel?  What kind of NMI is deliverd to each CPU?

Are you using SGI UV?  On that platform, NMIs may be delivered to
all cpus because LVT1 of all cpus are not masked as follows:

void uv_nmi_init(void)
{
unsigned int value;

/*
 * Unmask NMI on all cpus
 */
value = apic_read(APIC_LVT1) | APIC_DM_NMI;
value &= ~APIC_LVT_MASKED;
apic_write(APIC_LVT1, value);
}

> 
> Traditionally, we should have assumed that NMI for crash dumping is
> delivered to only one cpu.  Otherwise, we should often fail to take
> a proper crash dump.  It seems that your case is another problem to be
> solved separately.
> 
> > The
> > crash kernel booted eventually but the log contained lockups when a
> > CPU waited for an IPI to the CPU which was handling the NMI panic.
> 
> Could you explain more precisely?
> 
> > Anyway, I do not thing this is really necessary to solve the panic
> > reentrancy issue.
> > If the missing saved state is a real problem then it
> > should be handled separately - maybe it can be achieved without an IPI
> > and directly from the panic context if we are in NMI.
> 
> What I would like to do via this patchse is to solve race issues
> among NMI, panic() and crash_kexec().  So, I don't think we should fix
> that separately, although I would need to reword some descriptions
> and titles.
> 
> Anyway, I'm going to sent out my revised version once in order to
> tidy up.  I also would like to hear kexec/kdump guys' opinions.
> 
> Regards,
> Kawai

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[Michal Hocko]

On Thu 30-07-15 01:45:35, 河合英宏 / KAWAI，HIDEHIRO wrote:
> Hi,
> 
> > From: Michal Hocko [mailto:mho...@kernel.org]
> > 
> > On Wed 29-07-15 09:09:18, 河合英宏 / KAWAI，HIDEHIRO wrote:
[...]
> > > #define nmi_panic(fmt, ...)\
> > >do {\
> > >if (atomic_cmpxchg(&panic_cpu, -1, raw_smp_processor_id()) 
> > > \
> > >== -1)  \
> > >panic(fmt, ##__VA_ARGS__);  \
> > >} while (0)
> > 
> > This would allow to return from NMI too eagerly.
> 
> Yes, but what's the problem?

I believe that panic should be noreturn as much as possible and return
only when we do not have any other options. Moreover I would ask an
opposite question, what is the problem to loop in NMI on other CPUs than
the one which is performing crash_kexec? We will not save registers, so
what?

> The root cause of your case hasn't been clarified yet.
> I can't fix for an unclear issue because I don't know what's the right
> solution.
> 
> > When I was testing my
> > previous approach (on 3.0 based kernel) I had basically the same thing
> > (one NMI to process panic) and others to return. This led to a strange
> > behavior when the NMI button triggered NMI on all (hundreds) CPUs.
> 
> It's strange.  Usually, NMI caused by NMI button is routed to only CPU 0
> as an external NMI.  External NMI for CPUs other than CPU 0 are masked
> at boot time.  Does it really happen?

Could you point me to the code which does that, please? Maybe we are
missing that in our 3.0 kernel. I was quite surprised to see this
behavior as well.

> Does the problem still happen on the latest kernel?

I do not have machine accessible so I have to rely on the customer to
test and the current vanilla might be an issue.

> What kind of NMI is deliverd to each CPU?

See the log below.

> Traditionally, we should have assumed that NMI for crash dumping is
> delivered to only one cpu.  Otherwise, we should often fail to take
> a proper crash dump.

You might still get a panic on hardlockup which will happen on all CPUs
from the NMI context so we have to be able to handle panic in NMI on
many CPUs.

> It seems that your case is another problem to be solved separately.

I do not think so, quite contrary. If you want to solve the reentrancy
then other CPUs might be spinning in NMI if there is a guarantee that at
least one CPU can progress to finish crash_kexec().

> > The
> > crash kernel booted eventually but the log contained lockups when a
> > CPU waited for an IPI to the CPU which was handling the NMI panic.
> 
> Could you explain more precisely?

[  167.843761] Uhhuh. NMI received for unknown reason 3d on CPU 130.
[  167.843763] Do you have a strange power saving mode enabled?
[... Mangled output ]
[  167.856415] Dazed and confused, but trying to continue
[  167.856428] Dazed and confused, but trying to continue
[  167.856442] Dazed and confused, but trying to continue
[...]
[  193.108440] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:0:4]
[...]
[  193.108586] Call Trace:
[  193.108595]  [] smp_call_function_single+0x15b/0x170
[  193.108600]  [] smp_call_function_any+0x4e/0x110
[  193.108607]  [] get_cur_val+0xbc/0x130 [acpi_cpufreq]
[  193.108630]  [] get_cur_freq_on_cpu+0x77/0xf0 
[acpi_cpufreq]
[  193.108638]  [] cpufreq_update_policy+0x97/0x140
[  193.108646]  [] acpi_processor_notify+0x4b/0x145 
[processor]
[  193.108654]  [] acpi_ev_notify_dispatch+0x61/0x77
[  193.108659]  [] acpi_os_execute_deferred+0x21/0x2c
[  193.108667]  [] process_one_work+0x16c/0x350
[  193.108673]  [] worker_thread+0x17a/0x410
[  193.108679]  [] kthread+0x96/0xa0
[  193.108688]  [] kernel_thread_helper+0x4/0x10
[...]
[  221.068390] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:0:4]
[...]
[  227.991235] INFO: rcu_sched_state detected stalls on CPUs/tasks: { 130} 
(detected by 56, t=15002 jiffies)
[  227.991247] sending NMI to all CPUs:
[  227.991251] NMI backtrace for cpu 0
[  229.074091] INFO: rcu_bh_state detected stalls on CPUs/tasks: { 130} 
(detected by 105, t=15013 jiffies)
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.0.101-0.47.55.9.8853.0.TEST-default 
(geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE 
Linux) ) #1 SMP Thu May 28 08:25:11 UTC 2015 (dc083ee)
[0.00] Command line: root=/dev/system/lvroot resume=/dev/system/lvswap 
intel_idle.max_cstate=0 processor.max_cstate=0 elevator=deadline nmi_watchdog=1 
console=tty0 console=ttyS1,115200 elevator=deadline sysrq=yes reset_devices 
irqpoll maxcpus=1 disable_cpu_apicid=0 noefi acpi_rsdp=0xba7a4014  
crashkernel=1024M-:512M memmap=exactmap memmap=576K@64K memmap=523684K@393216K 
elfcorehdr=916900K memmap=32768K#3018748K memmap=3736K#3051516K 
memmap=262144K$3145728K

I can provide the ful

Re: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[Michal Hocko]

On Thu 30-07-15 07:33:15, 河合英宏 / KAWAI，HIDEHIRO wrote:
[...]
> Are you using SGI UV?  On that platform, NMIs may be delivered to
> all cpus because LVT1 of all cpus are not masked as follows:

This is Compute Blade 520XB1 from Hitachi with 240 cpus.

-- 
Michal Hocko
SUSE Labs

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[河合英宏 / KAWAI，HIDEHIRO]

Hi,

> -Original Message-
> From: Michal Hocko [mailto:mho...@kernel.org]
> 
> On Thu 30-07-15 07:33:15, 河合英宏 / KAWAI，HIDEHIRO wrote:
> [...]
> > Are you using SGI UV?  On that platform, NMIs may be delivered to
> > all cpus because LVT1 of all cpus are not masked as follows:
> 
> This is Compute Blade 520XB1 from Hitachi with 240 cpus.

Thanks for the information!

I asked my colleague in other department about NMI button behavior
of our server just before receive your mail, and certainly what you
said happens; all cpus say "Uhhuh. NMI received for unknown reason 3d
on CPU N" when NMI button is pusshed.  So, this was also our problem...

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[河合英宏 / KAWAI，HIDEHIRO]

> From: Michal Hocko [mailto:mho...@kernel.org]
> 
> On Thu 30-07-15 01:45:35, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > Hi,
> >
> > > From: Michal Hocko [mailto:mho...@kernel.org]
> > >
> > > On Wed 29-07-15 09:09:18, 河合英宏 / KAWAI，HIDEHIRO wrote:
> [...]
> > > > #define nmi_panic(fmt, ...)\
> > > >do {\
> > > >if (atomic_cmpxchg(&panic_cpu, -1, 
> > > > raw_smp_processor_id()) \
> > > >== -1)  \
> > > >panic(fmt, ##__VA_ARGS__);  \
> > > >} while (0)
> > >
> > > This would allow to return from NMI too eagerly.
> >
> > Yes, but what's the problem?
> 
> I believe that panic should be noreturn as much as possible and return
> only when we do not have any other options.

In my case, external NMI is delivered to only CPU 0.  This means
other CPUs continues to run until receiving NMI IPI.  I think returning
from NMI handler soon doesn't differ from this so much.

> Moreover I would ask an
> opposite question, what is the problem to loop in NMI on other CPUs than
> the one which is performing crash_kexec? We will not save registers, so
> what?

Actually, we have to do at least save registers, clean up VMX/SVM states
and announce that the cpu has stopped.  Just returning from NMI handler
is simpler.

> > The root cause of your case hasn't been clarified yet.
> > I can't fix for an unclear issue because I don't know what's the right
> > solution.
> >
> > > When I was testing my
> > > previous approach (on 3.0 based kernel) I had basically the same thing
> > > (one NMI to process panic) and others to return. This led to a strange
> > > behavior when the NMI button triggered NMI on all (hundreds) CPUs.
> >
> > It's strange.  Usually, NMI caused by NMI button is routed to only CPU 0
> > as an external NMI.  External NMI for CPUs other than CPU 0 are masked
> > at boot time.  Does it really happen?
> 
> Could you point me to the code which does that, please? Maybe we are
> missing that in our 3.0 kernel. I was quite surprised to see this
> behavior as well.

Please see the snippet below.

void setup_local_APIC(void)
{
...
/*
 * only the BP should see the LINT1 NMI signal, obviously.
 */
if (!cpu)
value = APIC_DM_NMI;
else
value = APIC_DM_NMI | APIC_LVT_MASKED;
if (!lapic_is_integrated()) /* 82489DX */
value |= APIC_LVT_LEVEL_TRIGGER;
apic_write(APIC_LVT1, value);


LINT1 pins of cpus other than CPU 0 are masked here.
However, at least on some of Hitachi servers, NMI caused by NMI
button doesn't seem to be delivered through LINT1.  So, my `external NMI'
word may not be correct.

> > Does the problem still happen on the latest kernel?
> 
> I do not have machine accessible so I have to rely on the customer to
> test and the current vanilla might be an issue.

Sure.

> > What kind of NMI is deliverd to each CPU?
> 
> See the log below.
> 
> > Traditionally, we should have assumed that NMI for crash dumping is
> > delivered to only one cpu.  Otherwise, we should often fail to take
> > a proper crash dump.
> 
> You might still get a panic on hardlockup which will happen on all CPUs
> from the NMI context so we have to be able to handle panic in NMI on
> many CPUs.

Do you say about the case of a kerne panic while other cpus locks up
in NMI context?  In that case, there is no way to do things needed by
kdump procedure including saving registeres...

> > It seems that your case is another problem to be solved separately.
> 
> I do not think so, quite contrary. If you want to solve the reentrancy
> then other CPUs might be spinning in NMI if there is a guarantee that at
> least one CPU can progress to finish crash_kexec().
> 
> > > The
> > > crash kernel booted eventually but the log contained lockups when a
> > > CPU waited for an IPI to the CPU which was handling the NMI panic.
> >
> > Could you explain more precisely?
> 
> [  167.843761] Uhhuh. NMI received for unknown reason 3d on CPU 130.
> [  167.843763] Do you have a strange power saving mode enabled?
> [... Mangled output ]
> [  167.856415] Dazed and confused, but trying to continue
> [  167.856428] Dazed and confused, but trying to continue
> [  167.856442] Dazed and confused, but trying to continue
> [...]
> [  193.108440] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/0:0:4]
> [...]
> [  193.108586] Call Trace:
> [  193.108595]  [] smp_call_function_single+0x15b/0x170
> [  193.108600]  [] smp_call_function_any+0x4e/0x110
> [  193.108607]  [] get_cur_val+0xbc/0x130 [acpi_cpufreq]
> [  193.108630]  [] get_cur_freq_on_cpu+0x77/0xf0 
> [acpi_cpufreq]
> [  193.108638]  [] cpufreq_update_policy+0x97/0x140
> [  193.108646]  [] acpi_processor_notify+0x4b/0x145 
> [processor]
> [  193.108654]  [] acpi_ev_notify_dispatch+0x61

Re: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[Michal Hocko]

On Thu 30-07-15 11:55:52, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > From: Michal Hocko [mailto:mho...@kernel.org]
[...]
> > Could you point me to the code which does that, please? Maybe we are
> > missing that in our 3.0 kernel. I was quite surprised to see this
> > behavior as well.
> 
> Please see the snippet below.
> 
> void setup_local_APIC(void)
> {
> ...
> /*
>  * only the BP should see the LINT1 NMI signal, obviously.
>  */
> if (!cpu)
> value = APIC_DM_NMI;
> else
> value = APIC_DM_NMI | APIC_LVT_MASKED;
> if (!lapic_is_integrated()) /* 82489DX */
> value |= APIC_LVT_LEVEL_TRIGGER;
> apic_write(APIC_LVT1, value);
> 
> 
> LINT1 pins of cpus other than CPU 0 are masked here.
> However, at least on some of Hitachi servers, NMI caused by NMI
> button doesn't seem to be delivered through LINT1.  So, my `external NMI'
> word may not be correct.

I am not familiar with details here but I can tell you that this
particular code snippet is the same in our 3.0 based kernel so it seems
that the HW is indeed doing something differently.

> > You might still get a panic on hardlockup which will happen on all CPUs
> > from the NMI context so we have to be able to handle panic in NMI on
> > many CPUs.
> 
> Do you say about the case of a kerne panic while other cpus locks up
> in NMI context?  In that case, there is no way to do things needed by
> kdump procedure including saving registeres...

I am saying that watchdog_overflow_callback might trigger on more CPUs
and panic from NMI context as well. So this is not reduced to the NMI
button sends NMI to more CPUs.

Why cannot the panic() context save all the registers if we are going to
loop in NMI context? This would be imho preferable to returning from
panic IMO.

[...]
> > I can provide the full log but it is quite mangled. I guess the
> > CPU130 was the only one allowed to proceed with the panic while others
> > returned from the unknown NMI handling. It took a lot of time until
> > CPU130 managed to boot the crash kernel with soft lockups and RCU stalls
> > reports. CPU0 is most probably locked up waiting for CPU130 to
> > acknowledge the IPI which will not happen apparently.
> 
> There is a timeout of 1000ms in nmi_shootdown_cpus(), so I don't know
> why CPU 130 waits so long.  I'll try to consider for a while.

Yes, I do not understand the timing here either and the fact that the
log is a complete mess in the important parts doesn't help a wee bit.
 
[...]

-- 
Michal Hocko
SUSE Labs

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[河合英宏 / KAWAI，HIDEHIRO]

> From: Michal Hocko [mailto:mho...@kernel.org]
> 
> On Thu 30-07-15 11:55:52, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > From: Michal Hocko [mailto:mho...@kernel.org]
> [...]
> > > Could you point me to the code which does that, please? Maybe we are
> > > missing that in our 3.0 kernel. I was quite surprised to see this
> > > behavior as well.
> >
> > Please see the snippet below.
> >
> > void setup_local_APIC(void)
> > {
> > ...
> > /*
> >  * only the BP should see the LINT1 NMI signal, obviously.
> >  */
> > if (!cpu)
> > value = APIC_DM_NMI;
> > else
> > value = APIC_DM_NMI | APIC_LVT_MASKED;
> > if (!lapic_is_integrated()) /* 82489DX */
> > value |= APIC_LVT_LEVEL_TRIGGER;
> > apic_write(APIC_LVT1, value);
> >
> >
> > LINT1 pins of cpus other than CPU 0 are masked here.
> > However, at least on some of Hitachi servers, NMI caused by NMI
> > button doesn't seem to be delivered through LINT1.  So, my `external NMI'
> > word may not be correct.
> 
> I am not familiar with details here but I can tell you that this
> particular code snippet is the same in our 3.0 based kernel so it seems
> that the HW is indeed doing something differently.

Yes, and it turned out my PATCH 3/3 doesn't work at all on some
hardware...

> > > You might still get a panic on hardlockup which will happen on all CPUs
> > > from the NMI context so we have to be able to handle panic in NMI on
> > > many CPUs.
> >
> > Do you say about the case of a kerne panic while other cpus locks up
> > in NMI context?  In that case, there is no way to do things needed by
> > kdump procedure including saving registeres...
> 
> I am saying that watchdog_overflow_callback might trigger on more CPUs
> and panic from NMI context as well. So this is not reduced to the NMI
> button sends NMI to more CPUs.

I understand.  So, I have to also modify watchdog_overflow_callback
to call nmi_panic().

> Why cannot the panic() context save all the registers if we are going to
> loop in NMI context? This would be imho preferable to returning from
> panic IMO.

I'm not saying we cannot save registers and do some cleanups in NMI
context.  I fell that it would introduce unneeded complexity.
Since watchdog_overflow_callback is defined as generic code,
we need to implement the preparation for kdump for other architectures.
I haven't checked which architectures support both nmi watchdog and
kdump, though.

Anyway, I came up with a simple solution for x86.  Waiting for the
timing of nmi_shootdown_cpus() in nmi_panic(), then invoke the
callback registered by nmi_shootdown_cpus().

> > > I can provide the full log but it is quite mangled. I guess the
> > > CPU130 was the only one allowed to proceed with the panic while others
> > > returned from the unknown NMI handling. It took a lot of time until
> > > CPU130 managed to boot the crash kernel with soft lockups and RCU stalls
> > > reports. CPU0 is most probably locked up waiting for CPU130 to
> > > acknowledge the IPI which will not happen apparently.
> >
> > There is a timeout of 1000ms in nmi_shootdown_cpus(), so I don't know
> > why CPU 130 waits so long.  I'll try to consider for a while.
> 
> Yes, I do not understand the timing here either and the fact that the
> log is a complete mess in the important parts doesn't help a wee bit.

I'm interested in where "kernel panic -not syncing: " is.
It may give us a clue.


Regards,
Kawai

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[Michal Hocko]

On Fri 31-07-15 11:23:00, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > From: Michal Hocko [mailto:mho...@kernel.org]
[...]
> > I am saying that watchdog_overflow_callback might trigger on more CPUs
> > and panic from NMI context as well. So this is not reduced to the NMI
> > button sends NMI to more CPUs.
> 
> I understand.  So, I have to also modify watchdog_overflow_callback
> to call nmi_panic().

yes.

[...]
> > > There is a timeout of 1000ms in nmi_shootdown_cpus(), so I don't know
> > > why CPU 130 waits so long.  I'll try to consider for a while.
> > 
> > Yes, I do not understand the timing here either and the fact that the
> > log is a complete mess in the important parts doesn't help a wee bit.
> 
> I'm interested in where "kernel panic -not syncing: " is.
> It may give us a clue.

This one is lost in the mangled text:
[  167.843771] U<0>[  167.843771] hhuh. NMI received for unkn<0><0>[  
167.843765] Uh[  16NM843774I own rea reived for unknow<0 r  16n 2d 765] Uhhuh. 
CPU recei11. <0known reason 7. on770] Ker<[ - not rn NMI:nic - not contt sing

<0 >[ : Not con.inu437azed and confused, b] Dtryingaed annue

fu 167.8ut trying>[   to 7.<0377 167.843775] U<0>[  167.843776] ]hhu.ived for 
u3nknown rMason 3 re oived for [nk167.843781]  1.
<. N0>[  167.843781] Uh. NMI recen 3d on CPU 0.i< >[ nowon 3d on] Chhuh.MI
eceived[ or7.843nknoUhhuh.wn rMason e3d ceCPivUd 120.
<0nk>no 167.wn843ason 3na s p120.
o<0er savi d6 e843ab88] Do yeu have a
[ er saving mode e nabl1d?7<4][  167 84hu94]MIuh. NceIived for unknown 
reas vdfor 1no3was0>[ 2d 67.84380on CI rUe 12e.
ive7d8u3800wn rveaseo f2d on CPo3.r< u>k[o 1 rea6s.o2d8 oo you hn aPve <0st>a e 
power 1s7.843816] Do yoauv ng moade enbslra?ng[ e 167.8438p41o]er 
shhuhavi.ngIroenived fbled?nknow
< reaso0> 2d on [PU1626.41]0>   Uh67.h. NM387I] receihed for .nknown reason  
2Nn MC U ceived for .
[son 2d on CPU 6.
<  160>7.8467.84873] Uhhuh. 3MI received 908 o knstra
[ n167.843908] Do ygo pave westrangesa pvnv mode enableng mode ed?
nhttp://lists.infradead.org/mailman/listinfo/kexec

RE: Re: [V2 PATCH 1/3] x86/panic: Fix re-entrance problem due to panic on NMI

[河合英宏 / KAWAI，HIDEHIRO]

Hi,

> From: Michal Hocko [mailto:mho...@kernel.org]
> On Fri 31-07-15 11:23:00, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > From: Michal Hocko [mailto:mho...@kernel.org]
> > > > There is a timeout of 1000ms in nmi_shootdown_cpus(), so I don't know
> > > > why CPU 130 waits so long.  I'll try to consider for a while.
> > >
> > > Yes, I do not understand the timing here either and the fact that the
> > > log is a complete mess in the important parts doesn't help a wee bit.
> >
> > I'm interested in where "kernel panic -not syncing: " is.
> > It may give us a clue.
> 
> This one is lost in the mangled text:
> [  167.843771] U<0>[  167.843771] hhuh. NMI received for unkn<0><0>[  
> 167.843765] Uh[  16NM843774I own rea reived for
> unknow<0 r  16n 2d 765] Uhhuh. CPU recei11. <0known reason 7. on770] Ker<[ - 
> not rn NMI:nic - not contt sing
> 
> <0 >[ : Not con.inu437azed and confused, b] Dtryingaed annue
> 
> fu 167.8ut trying>[   to 7.<0377 167.843775] U<0>[  167.843776] ]hhu.ived for 
> u3nknown rMason 3 re oived for [nk167.843781]

Thanks for the information.

I anticipated that some lock contention on issuing messages (e.g.
locks used by network/netconsole driver) delayed the panic procedure,
but it seems not to be related because the panic message finished to
be issued early.

If I come up with something, I will post a mail.  I think there
may be potential issues.

> 1.
> <. N0>[  167.843781] Uh. NMI recen 3d on CPU 0.i< >[ nowon 3d on] Chhuh.MI
> eceived[ or7.843nknoUhhuh.wn rMason e3d ceCPivUd 120.
> <0nk>no 167.wn843ason 3na s p120.
> o<0er savi d6 e843ab88] Do yeu have a
> [ er saving mode e nabl1d?7<4][  167 84hu94]MIuh. NceIived for 
> unknown reas vdfor 1no3was0>[ 2d 67.84380on CI
> rUe 12e.
> ive7d8u3800wn rveaseo f2d on CPo3.r< u>k[o 1 rea6s.o2d8 oo you hn aPve <0st>a 
> e power 1s7.843816] Do yoauv ng moade
> enbslra?ng[ e 167.8438p41o]er shhuhavi.ngIroenived fbled?nknow
> < reaso0> 2d on [PU1626.41]0>   Uh67.h. NM387I] receihed for .nknown reason  
> 2Nn MC U ceived for .
> [son 2d on CPU 6.
> <  160>7.8467.84873] Uhhuh. 3MI received 908 o knstra
> [ n167.843908] Do ygo pave westrangesa pvnv mode enableng mode ed?
> nhttp://lists.infradead.org/mailman/listinfo/kexec

RE: Re: [V6 PATCH 1/6] panic/x86: Fix re-entrance problem due to panic on NMI

[河合英宏 / KAWAI，HIDEHIRO]

> From: Borislav Petkov [mailto:b...@alien8.de]
[...]
> Looks better.
> 
> Did some comments cleanup and nmi_panic() macro reformatting so that it
> is more readable and ended up applying this:

Thanks a lot!

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

> ---
> From: Hidehiro Kawai 
> Date: Thu, 10 Dec 2015 10:46:26 +0900
> Subject: [PATCH] panic, x86: Fix re-entrance problem due to panic on NMI
> 
> If panic on NMI happens just after panic() on the same CPU, panic() is
> recursively called. Kernel stalls, as a result, after failing to acquire
> panic_lock.
> 
> To avoid this problem, don't call panic() in NMI context if we've
> already entered panic().
> 
> For that, introduce nmi_panic() macro to reduce code duplication. In
> the case of panic on NMI, don't return from NMI handlers if another CPU
> already panicked.
> 
> Signed-off-by: Hidehiro Kawai 
> Acked-by: Michal Hocko 
> Cc: Aaron Tomlin 
> Cc: Andrew Morton 
> Cc: Andy Lutomirski 
> Cc: Baoquan He 
> Cc: Chris Metcalf 
> Cc: David Hildenbrand 
> Cc: Don Zickus 
> Cc: "Eric W. Biederman" 
> Cc: Frederic Weisbecker 
> Cc: Gobinda Charan Maji 
> Cc: HATAYAMA Daisuke 
> Cc: "H. Peter Anvin" 
> Cc: Ingo Molnar 
> Cc: Javi Merino 
> Cc: Jonathan Corbet 
> Cc: kexec@lists.infradead.org
> Cc: linux-...@vger.kernel.org
> Cc: lkml 
> Cc: Masami Hiramatsu 
> Cc: Michal Nazarewicz 
> Cc: Nicolas Iooss 
> Cc: Peter Zijlstra 
> Cc: Prarit Bhargava 
> Cc: Rasmus Villemoes 
> Cc: Rusty Russell 
> Cc: Seth Jennings 
> Cc: Steven Rostedt 
> Cc: Thomas Gleixner 
> Cc: Ulrich Obergfell 
> Cc: Vitaly Kuznetsov 
> Cc: Vivek Goyal 
> Link: http://lkml.kernel.org/r/20151210014626.25437.13302.stgit@softrs
> [ Cleanup comments, fixup formatting. ]
> Signed-off-by: Borislav Petkov 
> ---
>  arch/x86/kernel/nmi.c  | 16 
>  include/linux/kernel.h | 20 
>  kernel/panic.c | 16 +---
>  kernel/watchdog.c  |  2 +-
>  4 files changed, 46 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
> index 697f90db0e37..292a24bd0553 100644
> --- a/arch/x86/kernel/nmi.c
> +++ b/arch/x86/kernel/nmi.c
> @@ -231,7 +231,7 @@ pci_serr_error(unsigned char reason, struct pt_regs *regs)
>  #endif
> 
>   if (panic_on_unrecovered_nmi)
> - panic("NMI: Not continuing");
> + nmi_panic("NMI: Not continuing");
> 
>   pr_emerg("Dazed and confused, but trying to continue\n");
> 
> @@ -255,8 +255,16 @@ io_check_error(unsigned char reason, struct pt_regs 
> *regs)
>reason, smp_processor_id());
>   show_regs(regs);
> 
> - if (panic_on_io_nmi)
> - panic("NMI IOCK error: Not continuing");
> + if (panic_on_io_nmi) {
> + nmi_panic("NMI IOCK error: Not continuing");
> +
> + /*
> +  * If end up here, it means we have received an NMI while
> +  * processing panic(). Simply return without delaying and
> +  * re-enabling NMI.
> +  */
> + return;
> + }
> 
>   /* Re-enable the IOCK line, wait for a few seconds */
>   reason = (reason & NMI_REASON_CLEAR_MASK) | NMI_REASON_CLEAR_IOCHK;
> @@ -297,7 +305,7 @@ unknown_nmi_error(unsigned char reason, struct pt_regs 
> *regs)
> 
>   pr_emerg("Do you have a strange power saving mode enabled?\n");
>   if (unknown_nmi_panic || panic_on_unrecovered_nmi)
> - panic("NMI: Not continuing");
> + nmi_panic("NMI: Not continuing");
> 
>   pr_emerg("Dazed and confused, but trying to continue\n");
>  }
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 350dfb08aee3..750cc5c7c999 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -446,6 +446,26 @@ extern int sysctl_panic_on_stackoverflow;
>  extern bool crash_kexec_post_notifiers;
> 
>  /*
> + * panic_cpu is used for synchronizing panic() and crash_kexec() execution. 
> It
> + * holds a CPU number which is executing panic() currently. A value of
> + * PANIC_CPU_INVALID means no CPU has entered panic() or crash_kexec().
> + */
> +extern atomic_t panic_cpu;
> +#define PANIC_CPU_INVALID-1
> +
> +/*
> + * A variant of panic() called from NMI context. We return if we've already
> + * panicked on this CPU.
> + */
> +#define nmi_panic(fmt, ...)  \
> +do { \
> + in

RE: RE: Re: [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

[河合英宏 / KAWAI，HIDEHIRO]

Here is the revised commit description reflecting Dave's
comment.  Cc list was copied from -mm version.

From: Hidehiro Kawai 
Subject: x86/panic: replace smp_send_stop() with kdump friendly version in 
panic path

This patch fixes a problem reported by Daniel Walker
(https://lkml.org/lkml/2015/6/24/44).

When kernel panics with crash_kexec_post_notifiers kernel parameter
enabled, other CPUs are stopped by smp_send_stop() instead of
machine_crash_shutdown() in __crash_kexec() path.

  panic()
if crash_kexec_post_notifiers == 1
  smp_send_stop()
  atomic_notifier_call_chain()
  kmsg_dump()
__crash_kexec()
  machine_crash_shutdown()

Different from smp_send_stop(), machine_crash_shutdown() stops other
CPUs with extra works for kdump.  So, if smp_send_stop() stops other
CPUs in advance, these extra works won't be done.  For x86, kdump
routines miss to save other CPUs' registers and disable virtualization
extensions.

To fix this problem, call a new kdump friendly function,
crash_smp_send_stop(), instead of the smp_send_stop() when
crash_kexec_post_notifiers is enabled.  crash_smp_send_stop() is a
weak function, and it just call smp_send_stop().  Architecture
codes should override it so that kdump can work appropriately.
This patch only provides x86-specific version.

For Xen's PV kernel, just keep the current behavior.
As for Dom0, it doesn't use crash_kexec routines, and it relies on
panic notifier chain.  At the end of the chain, a hypercall is
issued which requests the hypervisor to execute kdump.  This means
regardless of crash_kexec_post_notifiers setting, smp_send_stop().
For PV HVM, it would work similarly to baremetal kernels with extra
cleanups for hypervisor.  It doesn't need additional care.

Changes in V4:
- Keep to use smp_send_stop if crash_kexec_post_notifiers is not set
- Rename panic_smp_send_stop to crash_smp_send_stop
- Don't change the behavior for Xen's PV kernel

Changes in V3:
- Revise comments, description, and symbol names

Changes in V2:
- Replace smp_send_stop() call with crash_kexec version which
  saves cpu states and cleans up VMX/SVM
- Drop a fix for Problem 1 at this moment

Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
Link: 
http://lkml.kernel.org/r/20160810080948.11028.15344.st...@sysi4-13.yrl.intra.hitachi.co.jp
Signed-off-by: Hidehiro Kawai 
Reported-by: Daniel Walker 
Cc: Dave Young 
Cc: Baoquan He 
Cc: Vivek Goyal 
Cc: Eric Biederman 
Cc: Masami Hiramatsu 
Cc: Daniel Walker 
Cc: Xunlei Pang 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: David Vrabel 
Cc: Toshi Kani 
Cc: Ralf Baechle 
Cc: David Daney 
Cc: Aaro Koskinen 
Cc: "Steven J. Hill" 
Cc: Corey Minyard 
Signed-off-by: Andrew Morton 

> -Original Message-
> From: Hidehiro Kawai
> Hi Xunlei,
> 
> > From: Xunlei Pang [mailto:xp...@redhat.com]
> > Sent: Tuesday, September 20, 2016 4:40 PM
> > On 2016/08/15/ at 19:22, Hidehiro Kawai wrote:
> > > Hi Dave,
> > >
> > > Thank you for the review.
> > >
> > >> From: Dave Young [mailto:dyo...@redhat.com]
> > >> Sent: Friday, August 12, 2016 12:17 PM
> > >>
> > >> Thanks for the update.
> > >> On 08/10/16 at 05:09pm, Hidehiro Kawai wrote:
> > >>> Daniel Walker reported problems which happens when
> > >>> crash_kexec_post_notifiers kernel option is enabled
> > >>> (https://lkml.org/lkml/2015/6/24/44).
> > >>>
> > >>> In that case, smp_send_stop() is called before entering kdump routines
> > >>> which assume other CPUs are still online.  As the result, for x86,
> > >>> kdump routines fail to save other CPUs' registers  and disable
> > >>> virtualization extensions.
> > >> Seems you simplified the changelog, but I think a little more details
> > >> will be helpful to understand the patch. You know sometimes lkml.org
> > >> does not work well.
> > > So, I'll try another archives when I post patch set next time.
> >
> > Hi Hidehiro Kawai,
> >
> > What's the status of this patch set, are you going to send an updated 
> > version?
> 
> Sorry, I misunderstood what Dave said, and I thought I don't
> need to revise the patch set.
> 
> Currently, this patch set is in -mm, then -next tree.
> What I need to fix is only commit descriptions, so I'm going to
> post revised descriptions as replies to this thread, and then
> request to Andrew to replace them if there is no objection.
> (or should I resend the whole patch set?)
> 
> Regards,
> Hidehiro Kawai
> 
> > >>> To fix this problem, call a new kdump friendly function,
> > >>> crash_smp_send_stop(), instead of the smp_send_stop() when
> > >>> crash_kexec_post_notifiers is enabled.  crash_smp_send_stop() is a
> > >>> weak function, and it just call smp_send_stop().  Architecture
> > >>> codes should override it so that kdump can work appropriately.
> > >>> This patch only provides x86-specific version.
> > >>>
> > >>> For Xen's PV kernel, just keep the current behavior.
> > >> Could you explain a bit about above Xen PV kernel behavior?
> > 

Re: Re: [PATCH] kexec: socket not released when error situation occur.

[YoungHyun Yoo]

On 08/26/16 at 11:19 am, Baoquan He wrote:
>On 08/25/16 at 11:15am, YoungHyun Yoo wrote:
>> Fix resourceleek in ifdown function when error occur.
>
>resource leak?

Yes resource leak. Sorry for the typo.

>
>> 
>> Signed-off-by: YoungHyun Yoo 
>> ---
>>  kexec/ifdown.c | 26 +++---
>>  1 file changed, 15 insertions(+), 11 deletions(-)
>> 
>> diff --git a/kexec/ifdown.c b/kexec/ifdown.c
>> index 46b7bef..9679ad7 100644
>> --- a/kexec/ifdown.c
>> +++ b/kexec/ifdown.c
>> @@ -1,6 +1,6 @@
>>  /*
>> - * ifdown.c Find all network interfaces on the system and
>> - *  shut them down.
>> + * ifdown.c Find all network interfaces on the system and
>> + *  shut them down.
>>   *
>>   */
>>  char *v_ifdown = "@(#)ifdown.c  1.11  02-Jun-1998  miqu...@cistron.nl";
>> @@ -20,10 +20,10 @@ char *v_ifdown = "@(#)ifdown.c  1.11  02-Jun-1998  
>> miqu...@cistron.nl";
>>  #include 
>>  
>>  /*
>> - *  First, we find all shaper devices and down them. Then we
>> - *  down all real interfaces. This is because the comment in the
>> - *  shaper driver says "if you down the shaper device before the
>> - *  attached inerface your computer will follow".
>> + *  First, we find all shaper devices and down them. Then we
>> + *  down all real interfaces. This is because the comment in the
>> + *  shaper driver says "if you down the shaper device before the
>> + *  attached inerface your computer will follow".
>>   */
>>  int ifdown(void)
>>  {
>> @@ -34,13 +34,13 @@ int ifdown(void)
>>  if ((fd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
>>  fprintf(stderr, "ifdown: ");
>>  perror("socket");
>> -return -1;
>> +goto error;
>>  }
>>  
>>  if ((ifa = if_nameindex()) == NULL) {
>>  fprintf(stderr, "ifdown: ");
>>  perror("if_nameindex");
>> -return -1;
>> +goto error;
>>  }
>>  
>>  for (shaper = 1; shaper >= 0; shaper--) {
>> @@ -57,18 +57,22 @@ int ifdown(void)
>>  if (ioctl(fd, SIOCGIFFLAGS, &ifr) < 0) {
>>  fprintf(stderr, "ifdown: shutdown ");
>>  perror(ifp->if_name);
>> -return -1;
>> +goto error;
>>  }
>>  ifr.ifr_flags &= ~(IFF_UP);
>>  if (ioctl(fd, SIOCSIFFLAGS, &ifr) < 0) {
>>  fprintf(stderr, "ifdown: shutdown ");
>>  perror(ifp->if_name);
>> -return -1;
>> +goto error;
>>  }
>>  
>>  }
>>  }
>> -close(fd);
>>  
>> +close(fd);
>>  return 0;
>> +
>> +error:
>> +close(fd);
>> +return -1;
>>  }
>> -- 
>> 2.9.0.GIT
>> 
>> 

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec


___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: crashdump: Re: [PATCH 2/2] printk: use the lockless ringbuffer

[John Ogness]

On 2020-02-17, Petr Mladek  wrote:
>>> Should the "prb"(printk tb static) symbol be exported into
>>> vmcoreinfo?  Otherwise, do you happen to know how to walk through
>>> the log_buf and get all kernel logs from vmcore?
>> 
>> You are correct. This will need to be exported as well so that the
>> descriptors can be accessed. (log_buf is only the pure human-readable
>> text.) I am currently hacking the crash tool to see exactly what
>> needs to be made available in order to access all the data of the
>> ringbuffer.
>
> I am not sure which parts you are working on. Are you going to provide
> also patch for makedumpfile, please?

I'm working on crash first. makedumpfile is on my list as well.

> I get the following failure when creating the crashdump using:
>
> echo c >/proc/sysrq-trigger
>
>
> The kernel version is not supported.
> The makedumpfile operation may be incomplete.
> dump_dmesg: Can't find variable-length record symbols
> makedumpfile Failed.
> Running makedumpfile --dump-dmesg /proc/vmcore failed (1).

Yes, the symbols have changed (and some are missing). I will get this
sorted out for v2. And I will provide some heavily hacked code for crash
and makedumpfile to show that the necessary symbols are there and it
works.

John Ogness

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: more barriers: Re: [PATCH 1/2] printk: add lockless buffer

[John Ogness]

On 2020-02-21, Petr Mladek  wrote:
> If I get it correctly, the used cmpxchg_relaxed() variants does not
> provide full barriers. They are just able to prevent parallel
> manipulation of the modified variable.

Correct.

I purposely avoided the full barriers of a successful cmpxchg() so that
we could clearly specify what we needed and why. As Andrea pointed out
[0], we need to understand if/when we require those memory barriers.

Once we've identified these, we may want to fold some of those barriers
back in, going from cmpxchg_relaxed() back to cmpxchg(). In particular
when we see patterns like:

do {

} while (!try_cmpxchg_relaxed());
smp_mb();

or possibly:

smp_mb();
cmpxchg_relaxed(); /* no return value check */

> On Tue 2020-01-28 17:25:47, John Ogness wrote:
>> diff --git a/kernel/printk/printk_ringbuffer.c 
>> b/kernel/printk/printk_ringbuffer.c
>> new file mode 100644
>> index ..796257f226ee
>> --- /dev/null
>> +++ b/kernel/printk/printk_ringbuffer.c
>> +/*
>> + * Take a given descriptor out of the committed state by attempting
>> + * the transition from committed to reusable. Either this task or some
>> + * other task will have been successful.
>> + */
>> +static void desc_make_reusable(struct prb_desc_ring *desc_ring,
>> +   unsigned long id)
>> +{
>> +struct prb_desc *desc = to_desc(desc_ring, id);
>> +atomic_long_t *state_var = &desc->state_var;
>> +unsigned long val_committed = id | DESC_COMMITTED_MASK;
>> +unsigned long val_reusable = val_committed | DESC_REUSE_MASK;
>> +
>> +atomic_long_cmpxchg_relaxed(state_var, val_committed,
>> val_reusable);
>
> IMHO, we should add smp_wmb() here to make sure that the reusable
> state is written before we shuffle the desc_ring->tail_id/head_id.
>
> It would pair with the read part of smp_mb() in desc_reserve()
> before the extra check if the descriptor is really in reusable state.

Yes. Now that we added the extra state checking in desc_reserve(), this
ordering has become important.

However, for this case I would prefer to instead place a full memory
barrier immediately before @tail_id is incremented (in
desc_push_tail()). The tail-incrementing-task must have seen the
reusable state (even if it is not the one that set it) and an
incremented @tail_id must be visible to the task recycling a descriptor.

>> +}
>> +
>> +/*
>> + * For a given data ring (text or dict) and its current tail lpos:
>> + * for each data block up until @lpos, make the associated descriptor
>> + * reusable.
>> + *
>> + * If there is any problem making the associated descriptor reusable,
>> + * either the descriptor has not yet been committed or another writer
>> + * task has already pushed the tail lpos past the problematic data
>> + * block. Regardless, on error the caller can re-load the tail lpos
>> + * to determine the situation.
>> + */
>> +static bool data_make_reusable(struct printk_ringbuffer *rb,
>> +   struct prb_data_ring *data_ring,
>> +   unsigned long tail_lpos, unsigned long lpos,
>> +   unsigned long *lpos_out)
>> +{
>> +struct prb_desc_ring *desc_ring = &rb->desc_ring;
>> +struct prb_data_blk_lpos *blk_lpos;
>> +struct prb_data_block *blk;
>> +enum desc_state d_state;
>> +struct prb_desc desc;
>> +unsigned long id;
>> +
>> +/*
>> + * Using the provided @data_ring, point @blk_lpos to the correct
>> + * blk_lpos within the local copy of the descriptor.
>> + */
>> +if (data_ring == &rb->text_data_ring)
>> +blk_lpos = &desc.text_blk_lpos;
>> +else
>> +blk_lpos = &desc.dict_blk_lpos;
>> +
>> +/* Loop until @tail_lpos has advanced to or beyond @lpos. */
>> +while ((lpos - tail_lpos) - 1 < DATA_SIZE(data_ring)) {
>> +blk = to_block(data_ring, tail_lpos);
>
> IMHO, we need smp_rmb() here to make sure that we read blk->id
> that we written after pushing the tail_lpos.
>
> It would pair with the write barrier in data_alloc() before
> before writing blk->id. It is there after updating head_lpos.
> But head_lpos could be updated only after updating tail_lpos.
> See the comment in data_alloc() below.

I do not understand. @blk->id has a data dependency on the provided
@tail_lpos. A random @tail_lpos value could be passed to this function
and it will only make a descriptor state change if the associated
descriptor is in the committed state and points back to that @tail_lp

Re: misc nits Re: [PATCH 1/2] printk: add lockless buffer

[John Ogness]

On 2020-02-21, Petr Mladek  wrote:
>> diff --git a/kernel/printk/printk_ringbuffer.c 
>> b/kernel/printk/printk_ringbuffer.c
>> new file mode 100644
>> index ..796257f226ee
>> --- /dev/null
>> +++ b/kernel/printk/printk_ringbuffer.c
>> +static struct prb_data_block *to_block(struct prb_data_ring *data_ring,
>> +   unsigned long begin_lpos)
>> +{
>> +char *data = &data_ring->data[DATA_INDEX(data_ring, begin_lpos)];
>> +
>> +return (struct prb_data_block *)data;
>
> Nit: Please, use "blk" instead of "data". I was slightly confused
> because "data" is also one member of struct prb_data_block.

OK.

>> +/* The possible responses of a descriptor state-query. */
>> +enum desc_state {
>> +desc_miss,  /* ID mismatch */
>> +desc_reserved,  /* reserved, but still in use by writer */
>> +desc_committed, /* committed, writer is done */
>> +desc_reusable,  /* free, not used by any writer */
>
> s/not used/not yet used/

OK.

>> +EXPORT_SYMBOL(prb_reserve);
>
> Please, do not export symbols if there are no plans to actually
> use them from modules. It will be easier to rework the code
> in the future. Nobody would need to worry about external
> users.
>
> Please, do so everywhere in the patchset.

You are correct.

The reason I exported them is that I could run my test module. But since
the test module will not be part of the kernel source, I'll just hack
the exports in when doing my testing.

>> +static char *get_data(struct prb_data_ring *data_ring,
>> +  struct prb_data_blk_lpos *blk_lpos,
>> +  unsigned long *data_size)
>> +{
>> +struct prb_data_block *db;
>> +
>> +/* Data-less data block description. */
>> +if (blk_lpos->begin == INVALID_LPOS &&
>> +blk_lpos->next == INVALID_LPOS) {
>> +return NULL;
>
> Nit: There is no need for "else" after return. checkpatch.pl usually
> complains about it ;-)

OK.

>> +/*
>> + * Read the record @id and verify that it is committed and has the sequence
>> + * number @seq. On success, 0 is returned.
>> + *
>> + * Error return values:
>> + * -EINVAL: A committed record @seq does not exist.
>> + * -ENOENT: The record @seq exists, but its data is not available. This is a
>> + *  valid record, so readers should continue with the next seq.
>> + */
>> +static int desc_read_committed(struct prb_desc_ring *desc_ring,
>> +   unsigned long id, u64 seq,
>> +   struct prb_desc *desc)
>> +{
>
> I was few times confused whether this function reads the descriptor
> a safe way or not.
>
> Please, rename it to make it clear that does only a check.
> For example, check_state_commited().

This function _does_ read. It is a helper function of prb_read() to
_read_ the descriptor. It is an extended version of desc_read() that
also performs various checks that the descriptor is committed.

I will update the function description to be more similar to desc_read()
so that it is obvious that it is "getting a copy of a specified
descriptor".

John Ogness

___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec