Re: [PATCH v1 1/3] crashdump/x86: dump any kind of "System RAM"

2021-03-31 Thread Dave Hansen 
On 3/23/21 3:01 AM, David Hildenbrand wrote:
> Traditionally, we had "System RAM" only on the top level of in the
> kernel resource tree (-> /proc/iomem). Nowadays, we can also have
> "System RAM" on lower levels of the tree -- driver-managed device memory
> that is always detected and added via drivers. Current examples are
> memory added via dax/kmem -- ("System RAM (kmem)") and virtio-mem ("System
> RAM (virtio_mem)"). Note that in some kernel versions "System RAM
> (kmem)" was exposed as "System RAM", but similarly, on lower levels of
> the resource tree.
> 
> Let's add anything that contains "System RAM" to the elf core header, so
> it will be dumped for kexec_load(). Handling kexec_file_load() in the
> kernel is similarly getting fixed [1].

Although I don't do a lot of hacking in the crashdump code, this seems
sane to me.  As the perpetrator of the "System RAM (kmem)" trick:

Acked-by: Dave Hansen 


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

Re: kexec does not work for kernel version with patch level >= 256

2021-03-31 Thread Eric W. Biederman 
Greg KH  writes:

> On Wed, Mar 31, 2021 at 04:03:24PM +0800, Baoquan He wrote:
>> Add Sasha and Greg to the CC list.
>> 
>> On 03/31/21 at 11:48am, Baoquan He wrote:
>> > On 03/31/21 at 11:04am, Patrick Sung wrote:
>> > > On Wed, Mar 31, 2021 at 10:47 AM Baoquan He  wrote:
>> > > >
>> > > > On 03/24/21 at 12:28pm, Patrick Sung wrote:
>> > > > > Hello all,
>> > > > >
>> > > > > I am using the 4.9 long term kernel which is currently at 4.9.262.
>> > > > > When using this kernel with kexec-tools it prints out this error
>> > > > >
>> > > > >   Unsupported utsname.release: 4.9.262
>> > > > >   Cannot load 
>> > > > >
>> > > > > A quick search in the code shows that kexec/kernel_version.c doing 
>> > > > > this check:
>> > > > >
>> > > > >   if (major >= 256 || minor >= 256 || patch >= 256) {
>> > > > >
>> > > > > and also in kexec/kexec.h
>> > > > >   #define KERNEL_VERSION(major, minor, patch) \
>> > > > > (((major) << 16) | ((minor) << 8) | patch)
>> > > >
>> > > > Yeah, this seems to be a good catch. The existing longterm kenrel 
>> > > > 4.9.262
>> > > > does cause the problem. I am not very sure about the longterm kernel
>> > > > version numbering, maybe we can leave 16 bits for for patch number to
>> > > > avoid the longterm kernel issue?
>> > > >
>> > > > Is there document telling the longterm kernel version numbering, or any
>> > > > pointer?
>> > > >
>> > > Actually I found that the mainline kernel clamp the "patch" version to 
>> > > 255
>> > > 
>> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0
>> > 
>> > Yeah, mainline kernel use below formula to construct kernel version.
>> > Seems longterm kernel takes a different way. While it's understandable
>> > that Longterm kernel using a larger patch number since it will evolve
>> > evolve for a longer time to get in bug fixes. Maybe we should enlarge
>> > patch number to 16 bits?
>> > 
>> > echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) +  \ 
>> >
>> > ((c) > 255 ? 255 : (c)))';
>> 
>> Should we also need to do the the same thing in kexec-tools utility, to
>> clamp the sub-level to 255? And the sub-level number is not so important
>> that we can do the clamping and won't cause any issue?
>
> If you can enlarge your "c" number to be 16bits, please do so.  We
> couldn't do that in the kernel source as it would break an existing
> user/kernel api :(

The code in kexec certainly can.  The function kernel_version() returns
a long.

However.  I think the code in kexec can do better.

There are only 4 uses of KERNEL_VERSION in the tree and only one of them
is testing for a case that would apply to kernel versions that are being
maintained.

AKA  I think checks for 3.15 and 2.6.27 we can just delete.

The checks for 3.15 are about command line size and are actively wrong.
As checking the running kernel to find the version of the kernel that
is being loaded is not reliable.

Which leaves only one check and I think the information needed is
X86_64_PAGE_OFFSET.  I think that can be obtained directly by
reading /proc/kcore instead of guessing it from the kernel version.

Does anyone want to try that?  I admit it is a bit more work than
changing the macro to just add more bits to the patch level
but it is would be more robust long term.

Eric

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

Re: kexec does not work for kernel version with patch level >= 256

2021-03-31 Thread Greg KH 
On Wed, Mar 31, 2021 at 04:03:24PM +0800, Baoquan He wrote:
> Add Sasha and Greg to the CC list.
> 
> On 03/31/21 at 11:48am, Baoquan He wrote:
> > On 03/31/21 at 11:04am, Patrick Sung wrote:
> > > On Wed, Mar 31, 2021 at 10:47 AM Baoquan He  wrote:
> > > >
> > > > On 03/24/21 at 12:28pm, Patrick Sung wrote:
> > > > > Hello all,
> > > > >
> > > > > I am using the 4.9 long term kernel which is currently at 4.9.262.
> > > > > When using this kernel with kexec-tools it prints out this error
> > > > >
> > > > >   Unsupported utsname.release: 4.9.262
> > > > >   Cannot load 
> > > > >
> > > > > A quick search in the code shows that kexec/kernel_version.c doing 
> > > > > this check:
> > > > >
> > > > >   if (major >= 256 || minor >= 256 || patch >= 256) {
> > > > >
> > > > > and also in kexec/kexec.h
> > > > >   #define KERNEL_VERSION(major, minor, patch) \
> > > > > (((major) << 16) | ((minor) << 8) | patch)
> > > >
> > > > Yeah, this seems to be a good catch. The existing longterm kenrel 
> > > > 4.9.262
> > > > does cause the problem. I am not very sure about the longterm kernel
> > > > version numbering, maybe we can leave 16 bits for for patch number to
> > > > avoid the longterm kernel issue?
> > > >
> > > > Is there document telling the longterm kernel version numbering, or any
> > > > pointer?
> > > >
> > > Actually I found that the mainline kernel clamp the "patch" version to 255
> > > 
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0
> > 
> > Yeah, mainline kernel use below formula to construct kernel version.
> > Seems longterm kernel takes a different way. While it's understandable
> > that Longterm kernel using a larger patch number since it will evolve
> > evolve for a longer time to get in bug fixes. Maybe we should enlarge
> > patch number to 16 bits?
> > 
> > echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) +  \  
> >   
> > ((c) > 255 ? 255 : (c)))';
> 
> Should we also need to do the the same thing in kexec-tools utility, to
> clamp the sub-level to 255? And the sub-level number is not so important
> that we can do the clamping and won't cause any issue?

If you can enlarge your "c" number to be 16bits, please do so.  We
couldn't do that in the kernel source as it would break an existing
user/kernel api :(

thanks,

greg k-h

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

Re: kexec does not work for kernel version with patch level >= 256

2021-03-31 Thread Baoquan He 
Add Sasha and Greg to the CC list.

On 03/31/21 at 11:48am, Baoquan He wrote:
> On 03/31/21 at 11:04am, Patrick Sung wrote:
> > On Wed, Mar 31, 2021 at 10:47 AM Baoquan He  wrote:
> > >
> > > On 03/24/21 at 12:28pm, Patrick Sung wrote:
> > > > Hello all,
> > > >
> > > > I am using the 4.9 long term kernel which is currently at 4.9.262.
> > > > When using this kernel with kexec-tools it prints out this error
> > > >
> > > >   Unsupported utsname.release: 4.9.262
> > > >   Cannot load 
> > > >
> > > > A quick search in the code shows that kexec/kernel_version.c doing this 
> > > > check:
> > > >
> > > >   if (major >= 256 || minor >= 256 || patch >= 256) {
> > > >
> > > > and also in kexec/kexec.h
> > > >   #define KERNEL_VERSION(major, minor, patch) \
> > > > (((major) << 16) | ((minor) << 8) | patch)
> > >
> > > Yeah, this seems to be a good catch. The existing longterm kenrel 4.9.262
> > > does cause the problem. I am not very sure about the longterm kernel
> > > version numbering, maybe we can leave 16 bits for for patch number to
> > > avoid the longterm kernel issue?
> > >
> > > Is there document telling the longterm kernel version numbering, or any
> > > pointer?
> > >
> > Actually I found that the mainline kernel clamp the "patch" version to 255
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/Makefile?id=9b82f13e7ef316cdc0a8858f1349f4defce3f9e0
> 
> Yeah, mainline kernel use below formula to construct kernel version.
> Seems longterm kernel takes a different way. While it's understandable
> that Longterm kernel using a larger patch number since it will evolve
> evolve for a longer time to get in bug fixes. Maybe we should enlarge
> patch number to 16 bits?
> 
> echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) +  \
> 
> ((c) > 255 ? 255 : (c)))';

Should we also need to do the the same thing in kexec-tools utility, to
clamp the sub-level to 255? And the sub-level number is not so important
that we can do the clamping and won't cause any issue?

Thanks
Baoquan

> 
> By the way, it calls 'a' version number, 'b' patch level, 'c' sub-level
> in Makefile of kernel?
> 
> > 
> > > Thanks
> > > Baoquan
> > >
> > > >
> > > > which explains the reason for the range check in kernel_version.c
> > > >
> > > > Increasing the number of bits allowed in "patch" seems to fix the issue.
> > > >
> > > > Thanks,
> > > > Patrick
> > > >
> > > > ___
> > > > 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
> 


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

Re: [PATCH printk v2 2/5] printk: remove safe buffers

2021-03-31 Thread John Ogness 
On 2021-03-30, John Ogness  wrote:
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index e971c0a9ec9e..f090d6a1b39e 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1772,16 +1759,21 @@ static struct task_struct *console_owner;
>  static bool console_waiter;
>  
>  /**
> - * console_lock_spinning_enable - mark beginning of code where another
> + * console_lock_spinning_enable_irqsave - mark beginning of code where 
> another
>   *   thread might safely busy wait
>   *
>   * This basically converts console_lock into a spinlock. This marks
>   * the section where the console_lock owner can not sleep, because
>   * there may be a waiter spinning (like a spinlock). Also it must be
>   * ready to hand over the lock at the end of the section.
> + *
> + * This disables interrupts because the hand over to a waiter must not be
> + * interrupted until the hand over is completed (@console_waiter is cleared).
>   */
> -static void console_lock_spinning_enable(void)
> +static void console_lock_spinning_enable_irqsave(unsigned long *flags)

I missed the prototype change for the !CONFIG_PRINTK case, resulting in:

linux/kernel/printk/printk.c:2707:3: error: implicit declaration of function 
‘console_lock_spinning_enable_irqsave’; did you mean 
‘console_lock_spinning_enable’? [-Werror=implicit-function-declaration]
   console_lock_spinning_enable_irqsave(&flags);
   ^~~~
   console_lock_spinning_enable

Will be fixed for v3.

(I have now officially added !CONFIG_PRINTK to my CI tests.)

John Ogness

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

Bidding invitation

2021-03-31 Thread Albert Bourla 
Good Day Sir/Ms,

We are please to invite you or your company to quote the 
following item listed below:
 
Product/Model No: A702TH FYNE PRESSURE REGULATOR
Model Number: A702TH
Qty. 30 units


Compulsory,Kindly send your quotation to: 
quotat...@pfizerbvsupply.com 
for immediate approval.

Kind Regards,
Albert Bourla
PFIZER B.V Supply Chain Manager
Tel: +31(0)208080 880
ADDRESS: Rivium Westlaan 142, 2909 LD
Capelle aan den IJssel, Netherlands

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