On Tue, 22 Dec 2015 19:40:39 +0800 Xunlei Pang wrote:
> > Following functions will be used only in kexec_file. Please wrap them in
> > CONFIG_KEXEC_FILE.
> >
> > int __weak arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
> > unsigned long buf_le
On Wed, 27 Jan 2016 14:48:31 +0300 Dmitry Safonov
wrote:
> For allocation of kimage failure or kexec_prepare or load segments
> errors there is no need to keep crashkernel memory mapped.
> It will affect only s390 as map/unmap hook defined only for it.
> As on unmap s390 also changes os_info str
On Thu, 28 Jan 2016 11:57:22 +0300 Dmitry Safonov
wrote:
> On 01/28/2016 09:29 AM, Minfei Huang wrote:
> > On 01/27/16 at 02:48pm, Dmitry Safonov wrote:
> >> For allocation of kimage failure or kexec_prepare or load segments
> >> errors there is no need to keep crashkernel memory mapped.
> >> It
On Thu, 25 Feb 2016 22:02:40 +0800 Minfei Huang wrote:
> From: Minfei Huang
>
> For some arch, kexec shall map the reserved pages, then use them, when
> we try to start the kdump service.
>
> kexec may return directly, without unmaping the reserved pages, if it
> fails during starting service.
On Tue, 1 Mar 2016 16:02:28 +0800 Minfei Huang wrote:
> For some arch, kexec shall map the reserved pages, then use them, when
> we try to start the kdump service.
Which architectures are these, by the way?
> kexec may return directly, without unmaping the reserved pages, if it
> fails during
cating structs and loading initram, but also for some misc.
To make it more clear, wrap a new function do_kexec_load which is used to
allocate structs and load initram. And the pre-work will be done in
kexec_load.
Signed-off-by: Minfei Huang
Cc: Vivek Goyal
Cc: "Eric W. Biederman"
Signed-of
On Fri, 11 Mar 2016 16:42:48 +0800 Dave Young wrote:
> On i686 PAE enabled machine the contiguous physical area could be large
> and it can cause trimming down variables in below calculation in
> read_vmcore() and mmap_vmcore():
>
> tsz = min_t(size_t, m->offset + m->size - *fpos, buflen);
ec_protect_crashkres() and arch_kexec_unprotect_crashkres().
Signed-off-by: Xunlei Pang
Cc: Eric Biederman
Cc: Dave Young
Cc: Minfei Huang
Cc: Vivek Goyal
Signed-off-by: Andrew Morton
---
include/linux/kexec.h |2 ++
kernel/kexec.c|9 -
kernel/kexec_core.c |6 ++
On Tue, 1 Mar 2016 06:14:32 + Atsushi Kumagai
wrote:
> makedumpfile refers page.lru.next to get the order of compound pages
> for page filtering. However, now the order is stored in page.compound_order,
> hence VMCOREINFO should be updated to export the offset of
> page.compound_order.
>
>
xec_load+0x141/0x600
[] ? vfs_write+0x100/0x180
[] system_call_fastpath+0x16/0x1b
The patch chnages sanity_check_segment_list() to verify that no segment is
larger than half of memory.
Link:
http://lkml.kernel.org/r/1469165782-13193-1-git-send-email-zhongji...@huawei.com
Signed-off-by: zhong jiang
Cc: E
On Sat, 13 Aug 2016 00:18:23 -0300 Thiago Jung Bauermann
wrote:
> kexec_update_segment allows a given segment in kexec_image to have
> its contents updated. This is useful if the current kernel wants to
> send information to the next kernel that is up-to-date at the time of
> reboot.
>
> ...
>
On Thu, 25 Aug 2016 15:18:26 -0300 Thiago Jung Bauermann
wrote:
> Hello,
>
> This patch series implements a mechanism which allows the kernel to pass
> on a buffer to the kernel that will be kexec'd. This buffer is passed
> as a segment which is added to the kimage when it is being prepared
> b
On Tue, 30 Aug 2016 18:40:02 -0400 Mimi Zohar wrote:
> The TPM PCRs are only reset on a hard reboot. In order to validate a
> TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement list
> of the running kernel must be saved and then restored on the subsequent
> boot, possibly of a d
On Wed, 21 Mar 2018 12:27:40 +0100 Philipp Rudo
wrote:
> here is the updated patch set including Dave's comments.
There were some syntactic clashes with the "kexec_file, x86, powerpc:
refactoring for other architecutres" series. Please check (in
linux-next) that I got it all correct and that b
On Thu, 22 Mar 2018 11:37:21 +0800 Baoquan He wrote:
> From: AKASHI Takahiro
>
> This function, being a variant of walk_system_ram_res() introduced in
> commit 8c86e70acead ("resource: provide new functions to walk through
> resources"), walks through a list of all the resources of System RAM
>
On Thu, 22 Mar 2018 11:37:20 +0800 Baoquan He wrote:
> The current kexec_file ignores kexec_buf.top_down value when call
> arch_kexec_walk_mem() to allocate memory for loading kernel/initrd
> stuffs. This is not supposed to be what kexec_buf.top_down is used
> for.
OK, but why is this a problem?
On Fri, 23 Mar 2018 08:58:45 +0800 Baoquan He wrote:
> > erk, this is pretty nasty. Isn't there a better way :(
>
> Yes, this is not efficient.
>
> In struct resource{}, ->sibling list is a singly linked list. I ever
> thought about changing it to doubly linked list, yet not very sure if
> it
On Fri, 23 Mar 2018 11:10:13 +0800 Baoquan He wrote:
> On 03/22/18 at 07:06pm, Andrew Morton wrote:
> > On Fri, 23 Mar 2018 08:58:45 +0800 Baoquan He wrote:
> >
> > > > erk, this is pretty nasty. Isn't there a better way :(
> > >
> > >
On Mon, 21 May 2018 10:53:37 +0800 Dave Young wrote:
> This is a rework of the crashkernel=auto patches back to 2009 although
> I'm not sure if below is the last version of the old effort:
> https://lkml.org/lkml/2009/8/12/61
> https://lwn.net/Articles/345344/
>
> I changed the original design,
On Wed, 18 Jul 2018 10:49:44 +0800 Baoquan He wrote:
> For kexec_file loading, if kexec_buf.top_down is 'true', the memory which
> is used to load kernel/initrd/purgatory is supposed to be allocated from
> top to down. This is what we have been doing all along in the old kexec
> loading interface
On Thu, 19 Jul 2018 23:17:53 +0800 Baoquan He wrote:
> Hi Andrew,
>
> On 07/18/18 at 03:33pm, Andrew Morton wrote:
> > On Wed, 18 Jul 2018 10:49:44 +0800 Baoquan He wrote:
> >
> > > For kexec_file loading, if kexec_buf.top_down is 'true', the memory w
On Wed, 27 Feb 2019 13:32:14 +0800 Dave Young wrote:
> This series have been in -next for some days, could we get this in
> mainline?
It's been in -next for two months?
> Andrew, do you have plan about them, maybe next release?
They're all reviewed except for "xen/balloon: mark inflated pages
On Mon, 20 Jan 2020 08:29:39 +0100 Michal Hocko wrote:
> On Mon 20-01-20 10:33:14, Pingfan Liu wrote:
> > After commit ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug"),
> > when a mem section is fully deactivated, section_mem_map still records the
> > section's start pfn, which is not u
It's unclear (to me) what is the status of this patchset. But it does appear
that
an new version can be expected?
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Mon, 13 Apr 2020 08:15:23 -0500 ebied...@xmission.com (Eric W. Biederman)
wrote:
> > For 3), people can still use kexec_load and develop/fix for it, if no
> > kexec_file_load supported. But 32-bit arm should be a different one,
> > more like i386, we will leave it as is, and fix anything which
On Fri, 8 May 2020 10:42:14 +0200 David Hildenbrand wrote:
> Assume we have kmem configured and loaded:
> [root@localhost ~]# cat /proc/iomem
> ...
> 14000-33fff : Persistent Memory$
> 14000-1481f : namespace0.0
> 15000-33fff : dax0.0
> 15000-33fff
On Thu, 26 Mar 2020 18:07:29 + James Morse wrote:
> Memory added to the system by hotplug has a 'System RAM' resource created
> for it. This is exposed to user-space via /proc/iomem.
>
> This poses problems for kexec on arm64. If kexec decides to place the
> kernel in one of these newly onli
On Tue, 2 Jun 2020 12:59:52 +0800 Lianbo Jiang wrote:
> Signature verification is an important security feature, to protect
> system from being attacked with a kernel of unknown origin. Kexec
> rebooting is a way to replace the running kernel, hence need be
> secured carefully.
I'm finding this
On Wed, 10 Jun 2020 21:27:52 -0700 Vijay Balakrishna
wrote:
> Make kernel GNU build-id available in VMCOREINFO. Having
> build-id in VMCOREINFO facilitates presenting appropriate kernel
> namelist image with debug information file to kernel crash dump
> analysis tools. Currently VMCOREINFO lac
On Fri, 7 Dec 2012 01:09:27 +0900
Joonsoo Kim wrote:
> This patchset remove vm_struct list management after initializing vmalloc.
> Adding and removing an entry to vmlist is linear time complexity, so
> it is inefficient. If we maintain this list, overall time complexity of
> adding and removing
On Fri, 7 Dec 2012 01:09:27 +0900
Joonsoo Kim wrote:
> I'm not sure that "7/8: makes vmlist only for kexec" is fine.
> Because it is related to userspace program.
> As far as I know, makedumpfile use kexec's output information and it only
> need first address of vmalloc layer. So my implementati
On Mon, 10 Dec 2012 10:39:13 +0900
Atsushi Kumagai wrote:
> This patch adds the values related to buddy system to vmcoreinfo data
> so that makedumpfile (dump filtering command) can filter out all free
> pages with the new logic.
> It's faster than the current logic because it can distinguish fre
On Wed, 19 Dec 2012 16:57:03 -0800
ebied...@xmission.com (Eric W. Biederman) wrote:
> Andrew Morton writes:
>
> > Is there any way in which we can move some of this logic into the
> > kernel? In this case, add some kernel code which uses PageBuddy() on
> > behalf of m
On Fri, 22 Feb 2013 12:36:13 +0800
Zhang Yanfei wrote:
> If kimage_normal_alloc() fails to alloc pages for image->swap_page, it
> should call kimage_free_page_list() to free allocated pages in
> image->control_pages list before it frees image.
>
> ...
>
> --- a/kernel/kexec.c
> +++ b/kernel/kexec
On Mon, 25 Feb 2013 09:36:51 +0900
Simon Horman wrote:
> On Sun, Feb 24, 2013 at 10:37:21PM +0800, Zhang Yanfei wrote:
> > From: Zhang Yanfei
> >
> > This is just a tweak: using min_t to simplify logic of variable
> > assignments.
> >
> > v2:
> > - Rewrite patch description as Simon suggested.
On Tue, 26 Feb 2013 16:49:02 +0800 Zhang Yanfei
wrote:
> >> diff --git a/kernel/kexec.c b/kernel/kexec.c
> > []
> >> @@ -822,13 +822,9 @@ static int kimage_load_normal_segment(struct kimage
> >> *image,
> > []
> >> + mchunk = min_t(size_t, mbytes,
> >> + (size_t
On Tue, 26 Feb 2013 16:55:57 +0800
Zhang Yanfei wrote:
> ___ 2013___02___26___ 16:53, Andrew Morton __:
> > On Tue, 26 Feb 2013 16:49:02 +0800 Zhang Yanfei
> > wrote:
> >
> >>>> diff --git a/kernel/kexec.c b/kernel/kexec.c
> >&g
On Sat, 16 Mar 2013 13:00:47 +0900 HATAYAMA Daisuke
wrote:
> Currently, read to /proc/vmcore is done by read_oldmem() that uses
> ioremap/iounmap per a single page. For example, if memory is 1GB,
> ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144
> times. This causes big performance
On Sat, 16 Mar 2013 13:01:26 +0900 HATAYAMA Daisuke
wrote:
> The part of dump target memory is copied into the 2nd kernel if it
> doesn't satisfy mmap()'s page-size boundary requirement. To
> distinguish such copied object from usual old memory, a flag
> MEM_TYPE_CURRENT_KERNEL is introduced. If
On Sat, 16 Mar 2013 13:01:32 +0900 HATAYAMA Daisuke
wrote:
> Due to mmap() requirement, we need to copy pages not starting or
> ending with page-size aligned address in 2nd kernel and to map them to
> user-space.
>
> For example, see the map below:
>
> -0001 : reserved
> 00
On Sat, 16 Mar 2013 13:02:29 +0900 HATAYAMA Daisuke
wrote:
> If there's some vmcore object that doesn't satisfy page-size boundary
> requirement, remap_pfn_range() fails to remap it to user-space.
>
> Objects that posisbly don't satisfy the requirement are ELF note
> segments only. The memory c
acks.
Signed-off-by: Seiji Aguchi
Signed-off-by: Andrew Morton
---
fs/pstore/platform.c |4
include/linux/kmsg_dump.h |1 +
kernel/kexec.c|2 ++
3 files changed, 7 insertions(+)
diff -puN fs/pstore/platform.c~add-kmsg_dump-to-kexec-path fs/pstore/platform.c
--- a
On Tue, 21 May 2013 15:47:41 -0700 "gre...@linuxfoundation.org"
wrote:
> On Tue, May 21, 2013 at 03:41:37PM -0700, Andrew Morton wrote:
> > Guys, can we please get some review attention to this?
>
> I thought it was reviewed, and rejected, already. Did you miss those
On Thu, 23 May 2013 14:25:07 +0900 HATAYAMA Daisuke
wrote:
> Allocate ELF headers on page-size boundary using __get_free_pages()
> instead of kmalloc().
>
> Later patch will merge PT_NOTE entries into a single unique one and
> decrease the buffer size actually used. Keep original buffer size in
On Thu, 23 May 2013 14:25:13 +0900 HATAYAMA Daisuke
wrote:
> Treat memory chunks referenced by PT_LOAD program header entries in
> page-size boundary in vmcore_list. Formally, for each range [start,
> end], we set up the corresponding vmcore object in vmcore_list to
> [rounddown(start, PAGE_SIZE
uaddr = vma->vm_start;
> - unsigned long usize = vma->vm_end - vma->vm_start;
>
> - if ((PAGE_SIZE-1) & (unsigned long)addr)
> + size = PAGE_ALIGN(size);
> +
> + if (((PAGE_SIZE-1) & (unsigned long)uaddr) ||
> + ((PAGE_SIZE-1) & (unsigned lon
r.p_type= PT_NOTE;
> phdr.p_flags = 0;
> note_off = sizeof(Elf64_Ehdr) +
> (ehdr_ptr->e_phnum - nr_ptnote +1) * sizeof(Elf64_Phdr);
> - phdr.p_offset = note_off;
> + phdr.p_offset = roundup(note_off, PAGE_SIZE);
> phdr.p_vadd
pfn, is of 32-bit length on x86-32: unsigned long.
More reviewing and testing, please.
From: Andrew Morton
Subject: vmcore-support-mmap-on-proc-vmcore-fix
use min(), switch to conventional error-unwinding approach
Cc: Atsushi Kumagai
Cc: HATAYAMA Daisuke
Cc: KOSAKI Motohiro
Cc: Lisa Mi
On Tue, 28 May 2013 08:11:34 -0700 "H. Peter Anvin" wrote:
> On 05/28/2013 07:37 AM, Vivek Goyal wrote:
> >
> > Eric,
> >
> > Should we schedule the removal of this interface after 1-2 releases
> > and give a warning once if anybody opens /dev/oldmem and tell them
> > to use /proc/vmcore instea
On Mon, 27 May 2013 09:27:42 +0800 Zhang Yanfei
wrote:
> ___ 2013___05___27___ 09:27, HATAYAMA Daisuke __:
> > (2013/05/26 9:58), Zhang Yanfei wrote:
> >> ___ 2013___05___26___ 07:20, Eric W. Biederman __:
> >>> Zhang Yanfei writes:
> >>>
> From: Zhang Yanfei
> >>>
> >>> Won't we
On Mon, 9 Dec 2013 17:42:13 +0800 Dave Young wrote:
> Here is the V5 patchset for supporting kexec kernel efi runtime.
It's unclear (to me) who's supposed to merge this lot. It's a "kexec"
patch which actually hits on efi and x86.
I grabbed them for some -next testing but won't be offended if
On Thu, 12 Dec 2013 09:32:02 +0800 Zhang Yanfei
wrote:
> Add CCing Andrew Morton
I'm not on kexec@lists.infradead.org. (Well, I am now!).
> On 12/12/2013 08:18 AM, Geoff Levand wrote:
> > Simplify the code around one of the conditionals in the kexec_load
> > syscal
On Tue, 14 Jan 2014 14:33:11 -0500 Vivek Goyal wrote:
> Right now we seem to be exporting the max data size contained inside
> vmcoreinfo note. But this does not include the size of meta data around
> vmcore info data. Like name of the note and starting and ending elf_note.
>
> I think user spac
On Thu, 26 Jun 2014 16:33:29 -0400 Vivek Goyal wrote:
> This patch series does not do kernel signature verification yet. I plan
> to post another patch series for that. Now distributions are already signing
> PE/COFF bzImage with PKCS7 signature I plan to parse and verify those
> signatures.
>
>
On Thu, 26 Jun 2014 16:33:38 -0400 Vivek Goyal wrote:
> Previous patch provided the interface definition and this patch prvides
> implementation of new syscall.
>
> Previously segment list was prepared in user space. Now user space just
> passes kernel fd, initrd fd and command line and kernel w
;
> > + return 0;
> > +}
>
> Could we prefix these with efi_, e.g. efi_get_runtime_map_size() ?
This?
From: Andrew Morton
Subject: kexec-support-kexec-kdump-on-efi-systems-fix
s/get_efi/efi_get/g, per Matt
Cc: Vivek Goyal
Cc: Matt Fleming
Signed-off-by: Andrew Mo
On Thu, 24 Jul 2014 10:16:42 -0400 Vivek Goyal wrote:
> I am wondering how this final kexec patch should be routed. Issue here is that
> this patch depends on David Howells's PKCS7 and PEFILE patches. Which are now
> sitting in security tree. (security/next).
>
> http://git.kernel.org/cgit/linux
On Thu, 23 Oct 2014 08:53:14 -0400 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
it, old versions makedumpfile
doesn't work well.
Signed-off-by: HATAYAMA Daisuke
Cc: Eric W. Biederman
Cc: Vivek Goyal
Cc: Atsushi Kumagai
Cc: Dave Anderson
Signed-off-by: Andrew Morton
---
arch/x86/kernel/machine_kexec_64.c |1 +
include/linux/kexec.h |2 ++
On Mon, 3 Aug 2015 20:50:43 +0800 Baoquan He wrote:
> People reported that crash_notes in /proc/vmcore were corrupted and
> this cause crash kdump failure. With code debugging and log we got
> the root cause. This is because percpu variable crash_notes are
> allocated in 2 vmalloc pages. Current
On Thu, 13 Aug 2015 09:55:25 +0900 Simon Horman wrote:
> On Tue, Jul 28, 2015 at 12:46:42PM +0800, Minfei Huang wrote:
> > Transforming PFN(Page Frame Number) to struct page is never failure, so
> > we can simplify the code logic to do the image->control_page assignment
> > directly in the loop,
On Tue, 29 Sep 2015 20:58:57 +0800 "Lee, Chun-Yi"
wrote:
> This patch modified the code in fill_up_crash_elf_data by using
> walk_system_ram_res instead of walk_system_ram_range to count the max
> number of crash memory ranges. That's because the walk_system_ram_range
> filters out small memory
e event someone disables
> > CONFIG_PRINTK, thats just more code we need to ifdef. With this
> > implementation
> > we just stub out the log_buf_setup function, and let that be that. It seems
> > more consice to me this way.
> >
>
> Makes sense to me.
>
&g
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Thu, 7 May 2009 13:29:41 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13265
>
>Summary: Crashdump feature totally broken with
>
On Wed, 09 Jun 2010 11:57:14 +0530
Pavan Naregundi wrote:
> Resending the patch with fixed style issues.
>
> Signed-off-by: Pavan Naregundi
> Reviewed-by: WANG Cong
> --
>
>
>
>
> [fix-kexec.patch text/x-patch (685B)]
> diff -Naur a/kernel/kexec.c b/kernel/kexec.c
> --- a/kernel/kexec.c
On Thu, 2 Sep 2010 14:20:19 +0200
Arnd Bergmann wrote:
> Commit 73296bc611 "procfs: Use generic_file_llseek in /proc/vmcore" broke
> seeking on /proc/vmcore. This changes it back to use default_llseek
> in order to restore the original behaviour.
"broke" isn't a useful description of a bug :(
A
On Wed, 8 Dec 2010 09:47:48 -0500
Neil Horman wrote:
> I wrote this quirk awhile ago to properly setup MCP55 chips on hypertransport
> busses so that interrupts reached whatever cpu happend to boot the kdump
> kernel.
> while that works well, it was recently shown to me that a a non-hypertransp
On Tue, 3 May 2011 21:08:06 +0200
Olaf Hering wrote:
>
> The balloon driver in a Xen guest frees guest pages and marks them as
> mmio. When the kernel crashes and the crash kernel attempts to read the
> oldmem via /proc/vmcore a read from ballooned pages will generate 100%
> load in dom0 because
On Fri, 6 May 2011 12:55:46 +0200
Olaf Hering wrote:
> Should the called code increase/decrease the modules refcount instead?
> I remember there was some MODULE_INC/MODULE_DEC macro (cant remember the
> exact name) at some point. What needs to be done inside the module to
> prevent an unload whil
On Fri, 6 May 2011 21:39:16 +0200
Olaf Hering wrote:
> On Fri, May 06, Andrew Morton wrote:
>
> > So as your module will have a reference to vmcore.c's register and
> > unregister
> > functions, nothing needs to be done: the presence of the client module alone
>
On Fri, 19 Aug 2011 16:18:57 +0200
Michael Holzheu wrote:
> I had a long discussion with Vivek Goyal on the s390 kdump support (thanks
> Vivek for all the time!). As a result of this, here are two common code
> patches that are required for the s390 port. Could you please integrate them
> upstrea
On Tue, 13 Sep 2011 15:26:37 +0200
Michael Holzheu wrote:
> From: Michael Holzheu
>
> This patch implements the crash_map_pages() function for s390.
> KEXEC_CRASH_MEM_ALIGN is set to HPAGE_SIZE, in order to support
> kernel mappings that use large pages.
>
> Signed-off-by: Michael Holzheu
> -
On Tue, 20 Sep 2011 16:34:01 +0200
Michael Holzheu wrote:
> From: Michael Holzheu
>
> Currently the vmcoreinfo note is only initialized in case of kdump. On s390
> it is possible to create kernel dumps with other dump mechanisms than kdump
> (e.g. via hypervisor dump or stand-alone dump tools).
On Tue, 20 Sep 2011 16:34:00 +0200
Michael Holzheu wrote:
> Hello Andrew,
>
> Another common code patch that we would like to have upstream is the
> vmcoreinfo
> note initialization at Linux startup time. We need that for our traditional
> stand-alone and hypervisor dump tools.
>
> [1] kdump:
On Thu, 27 Oct 2011 11:32:45 +0200
Michael Holzheu wrote:
> From: Michael Holzheu
>
> Currently no udev events for memory hotplug "online" and "offline" are
> generated:
>
> # udevadm monitor
> # echo offline > /sys/devices/system/memory/memory4/state
> ==> No event
>
> When kdump is loaded,
On Thu, 27 Oct 2011 11:32:45 +0200
Michael Holzheu wrote:
> From: Michael Holzheu
>
> Currently no udev events for memory hotplug "online" and "offline" are
> generated:
>
> # udevadm monitor
> # echo offline > /sys/devices/system/memory/memory4/state
> ==> No event
>
> When kdump is loaded,
On Wed, 26 Oct 2011 16:34:09 +0200
Michael Holzheu wrote:
> Hello Andrew,
>
> After the discussion with Eric and Vivek the following patch
> seems to be a good solution to me. Could you accept this patch?
>
> When two CPUs call panic at the same time there is a
> possible race condition that ca
On Mon, 31 Oct 2011 10:57:16 +0100 Michael Holzheu
wrote:
> > Should this be done earlier in the function? As it stands we'll have
> > multiple CPUs scribbling on buf[] at the same time and all trying to
> > print the same thing at the same time, dumping their stacks, etc.
> > Perhaps it would
On Thu, 03 Nov 2011 11:07:24 +0100
Michael Holzheu wrote:
> Hello Andrew,
>
> On Mon, 2011-10-31 at 03:39 -0700, Andrew Morton wrote:
> > On Mon, 31 Oct 2011 10:57:16 +0100 Michael Holzheu
> > wrote:
> >
> > > > Should this be done earlier in
cenario.
[a...@linux-foundation.org: fix powerpc build]
Signed-off-by: WANG Cong
Reported-by: Vivek Goyal
Acked-by: Vivek Goyal
Acked-by: Jarod Wilson
Cc: "Eric W. Biederman"
Cc: KOSAKI Motohiro
Signed-off-by: Andrew Morton
---
arch/powerpc/platforms/pseries/nvram.c |1
ng to add a NULL entry explicitly, but I
> > > > don't
> > > > see what the gains us).
> > >
> > > Hi Will,
> > >
> > > thanks for the clarification. FWIW I am happy with your patch.
> > >
> > > Reviewed-by: Sim
On Tue, 28 Feb 2012 09:19:28 +0900
Simon Horman wrote:
> > > --- a/kernel/kexec.c
> > > +++ b/kernel/kexec.c
> > > @@ -1462,7 +1462,9 @@ static int __init crash_save_vmcoreinfo_init(void)
> > >
> > > VMCOREINFO_SYMBOL(init_uts_ns);
> > > VMCOREINFO_SYMBOL(node_online_map);
> > > +#ifdef CON
On Tue, 28 Feb 2012 09:51:30 +0900 Simon Horman wrote:
> On Mon, Feb 27, 2012 at 04:26:31PM -0800, Andrew Morton wrote:
> > On Tue, 28 Feb 2012 09:19:28 +0900
> > Simon Horman wrote:
> >
> > > > > --- a/kernel/kexec.c
> > > > > +++ b/kernel
On Tue, 28 Feb 2012 09:40:57 +
Will Deacon wrote:
> > > Still, you didn't answer my question! What effect will the absence of
> > > SYMBOL(swapper_pg_dir)= have upon downstream tools? If "none" then
> > > sure, let's remove it. If "explosion" then we should emit a dummy
> > > SYMBOL(swappe
On Thu, 31 Mar 2022 19:32:17 +0800 Baoquan He wrote:
> Hi Andrew,
>
> On 02/23/22 at 07:32pm, Baoquan He wrote:
> > The memory leak is reported by kmemleak detector, has been existing
> > for very long time. It casue much memory loss on large machine
> > with huge memory hotplug which will trigg
On Wed, 18 May 2022 23:48:28 +0530 "Naveen N. Rao"
wrote:
> Since commit d1bcae833b32f1 ("ELF: Don't generate unused section
> symbols") [1], binutils (v2.36+) started dropping section symbols that
> it thought were unused. This isn't an issue in general, but with
> kexec_file.c, gcc is placing
On Thu, 19 May 2022 23:17:48 +0800 kernel test robot wrote:
> Hi "Naveen,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on f993aed406eaf968ba3867a76bb46c95336a33d0]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Naveen-N-Rao/kexec_file-Drop-weak-att
On Fri, 20 May 2022 14:25:05 -0500 "Eric W. Biederman"
wrote:
> > I am not strongly against taking off __weak, just wondering if there's
> > chance to fix it in recordmcount, and the cost comparing with kernel fix;
> > except of this issue, any other weakness of __weak. Noticed Andrew has
> > pi
On Mon, 16 May 2022 17:05:06 -0700 Stephen Brennan
wrote:
> The kernel can be configured to contain a lot of introspection or
> debugging information built-in, such as ORC for unwinding stack traces,
> BTF for type information, and of course kallsyms. Debuggers could use
> this information to na
On Mon, 13 Jun 2022 14:59:44 -0700 Stephen Brennan
wrote:
> >> Related discussion around the BTF side of this:
> >> https://lore.kernel.org/bpf/586a6288-704a-f7a7-b256-e18a67592...@oracle.com/T/#u
> >>
> >> Some work-in-progress branches using this feature:
> >> https://github.com/brenns10/dwar
On Tue, 12 Jul 2022 12:13:03 +0100 Valentin Schneider
wrote:
> On 12/07/22 10:47, Baoquan He wrote:
> > Hi,
> >
> > On 06/30/22 at 11:32pm, Valentin Schneider wrote:
> >> Hi folks,
> >>
> >> Here's ~v3~ v4 where we now completely get rid of kexec_mutex.
> >>
> >> o Patch 1 makes sure all kexec_m
On Thu, 25 Aug 2022 10:27:04 -0700 Stephen Brennan
wrote:
> I just wanted to check on the status of this. I got your email about it
> being added to mm-hotfixes-unstable, and I do still see it in the quilt
> patches set:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree
On Mon, 03 Oct 2022 14:20:51 +0100 Valentin Schneider
wrote:
> > I'll stash it away for consideration after -rc1.
>
> I've seen them in linux-next for a while, am I right in assuming they'll be
> part of a 6.1 PR?
yup.
___
kexec mailing list
kexec@l
On Thu, 27 Oct 2022 13:50:08 -0700 Stephen Brennan
wrote:
> Though vmcoreinfo is intended to be small, at just one page, useful
> information is still added to it, so we risk running out of space.
> Currently there is no runtime check to see whether the vmcoreinfo buffer
> has been exhausted. Ad
On Sat, 17 Dec 2022 10:27:14 -0500 Sasha Levin wrote:
> From: Jianglei Nie
>
> [ Upstream commit 12b9d301ff73122aebd78548fa4c04ca69ed78fe ]
>
> Patch series "Some minor cleanup patches resent".
>
> The first three patches trivial clean up patches.
>
> And for the patch "kexec: replace crash_m
On Fri, 10 Feb 2023 17:35:10 -0300 "Guilherme G. Piccoli"
wrote:
> Commit 8d470a45d1a6 ("panic: add option to dump all CPUs backtraces in
> panic_print")
> introduced a setting for the "panic_print" kernel parameter to allow
> users to request a NMI backtrace on panic. Problem is that the panic
On Tue, 14 Mar 2023 17:00:58 -0300 "Guilherme G. Piccoli"
wrote:
> include/trace/events/notifiers.h | 69
> kernel/notifier.c| 6 +++
Perhaps the filenames should match, which means "notifier.h".
___
On Tue, 14 Mar 2023 18:08:37 -0300 "Guilherme G. Piccoli"
wrote:
> On 14/03/2023 17:50, Andrew Morton wrote:
> > On Tue, 14 Mar 2023 17:00:58 -0300 "Guilherme G. Piccoli"
> > wrote:
> >
> >> include/trace/events/notifiers.h | 69 ++
On Thu, 23 Mar 2023 15:49:20 +0800 Baoquan He wrote:
> Hi,
>
> On 03/07/23 at 04:44pm, Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > There are no arch-specific things in arch_kexec_kernel_image_load(), so
> > remove it and just use the generic version.
> >
> > v1 is at:
> > https://lor
On Mon, 14 Aug 2023 17:44:38 -0400 Eric DeVolder
wrote:
> This series is dependent upon "refactor Kconfig to consolidate
> KEXEC and CRASH options".
> https://lore.kernel.org/lkml/20230712161545.87870-1-eric.devol...@oracle.com/
>
> Once the kdump service is loaded, if changes to CPUs or memor
1 - 100 of 198 matches
Mail list logo
