Original Message -
> >
> > [root linux]$ crash vmlinux
> > /var/crash/127.0.0.1-2019-09-19-08\:31\:27/vmcore
> > WARNING: kernel relocated [240MB]: patching 97110 gdb minimal_symbol values
> >
> > KERNEL: /var/crash/127.0.0.1-2019-09-19-08:31:27/vmlinux
> > DUMPFILE: /var/cr
- Original Message -
> On Mon, Jan 14, 2019 at 03:26:32PM -0500, Dave Anderson wrote:
> > No. It needs *both* the vmlinux file and the vmcore file in order to read
> > kernel
> > virtual memory, so just having a kernel virtual address is insufficient.
> >
&g
- Original Message -
> On Mon, Jan 14, 2019 at 03:07:33PM -0500, Dave Anderson wrote:
> > That's what it *does* utilize -- it takes a standalone vmcore dumpfile, and
> > pulls out the OSRELEASE string from it, so that a user can determine what
> > vmlinux fil
- Original Message -
> On Mon, Jan 14, 2019 at 02:36:47PM -0500, Dave Anderson wrote:
> > There's no reading of the dumpfile's memory involved, and that being the
> > case,
> > the vmlinux file is not utilized. That's the whole point of the crash
&
- Original Message -
> On Mon, Jan 14, 2019 at 01:58:32PM -0500, Dave Anderson wrote:
> > Preferably it would be left as-is. The crash utility has a "crash
> > --osrelease vmcore"
> > option that only looks at the dumpfile header, and just dump the
- Original Message -
> On Mon, Jan 14, 2019 at 05:48:48PM +, Kazuhito Hagio wrote:
> > As for makedumpfile, it will be not impossible to remove the
> > init_uts_ns.name.relase (OSRELEASE), but some fixes are needed.
> > Because historically OSRELEASE has been a kind of a mandatory en
- Original Message -
>
>
> - Original Message -
> > On 04/26/2018 02:16 PM, Kees Cook wrote:
> > > On Thu, Apr 26, 2018 at 12:31 PM, Dave Anderson
> > > wrote:
> > >>
> > >> While testing /proc/kcore as the live memor
- Original Message -
> On 04/26/2018 02:16 PM, Kees Cook wrote:
> > On Thu, Apr 26, 2018 at 12:31 PM, Dave Anderson
> > wrote:
> >>
> >> While testing /proc/kcore as the live memory source for the crash utility,
> >> it fails on arm64. Th
the ones whose __va() is not a simple
addition of the physical address with PAGE_OFFSET.
Anyway, I don't know what the best approach for an architecture-neutral
fix would be in this case. So I figured I'd throw it out to you guys for
some ideas.
Dave Anderson
- Original Message -
> On Wed, Dec 7, 2016 at 11:56 PM, Baoquan He wrote:
> > Dave Anderson ever told in Crash utility he makes judgement whether it's
> > a kaslr kernel by size of KERNEL_IMAGE_SIZE. As long as it's 1G, it's
> > recognized as kaslr.
- Original Message -
> Hi Dave,
>
> On 11/01/16 at 10:13am, Dave Anderson wrote:
> >
> >
> > > > But we have this in mainline which also introduced the VMCOREINFO
> > > > numbers, can you send a patch to revert them?
>
>
> > > }
> > >
> > > /* arch-dependent functionality related to kexec file-based syscall */
> > > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > > index 5616755..8ad3a29e 100644
> > > --- a/kernel/kexec_core.c
> >
l-file command
behind the scenes. Your discrete "add-symbol-file" command is both
unnecessary and incorrect -- 0xffffa01d1240 is the address
of the nvme module's module data structure and not the starting
text address.
Dave Anderson
--
To unsubscribe from this list: send the l
- Original Message -
> Hi
>
> On Tue, Oct 8, 2013 at 5:40 AM, Dave Anderson wrote:
> >
> >
> > - Original Message -
> >> Hi Anatol,
> >>
> >> On Mon, Oct 07, 2013 at 10:53:32AM -0700, Anatol Pomozov wrote:
> >
- Original Message -
> (2013/10/07 22:21), Dave Anderson wrote:
>
> > - Original Message -
> >> (2013/10/03 22:47), Dave Anderson wrote:
>
> >>> - Original Message -
> >>>> (2013/10/02 18:13), HATAYAMA Daisuke
- Original Message -
> Hi Anatol,
>
> On Mon, Oct 07, 2013 at 10:53:32AM -0700, Anatol Pomozov wrote:
> > Hi Wu
> >
> > I have a request wrt your old commit 718a38211.
> >
> > I think it makes sense to export array pageflag_names so kernel dump
> > debug tools (like 'crash') can use it
- Original Message -
> (2013/10/03 22:47), Dave Anderson wrote:
> >
> >
> > - Original Message -
> >> (2013/10/02 18:13), HATAYAMA Daisuke wrote:
> >>> (2013/10/02 16:48), Kees Cook wrote
- Original Message -
> (2013/10/02 18:13), HATAYAMA Daisuke wrote:
> > (2013/10/02 16:48), Kees Cook wrote:
>
> +
> + return 0;
> +}
> +
> +/*
> * Determine if we were loaded by an EFI loader. If so, then we have
> also been
> * passe
- Original Message -
> On Mon, Dec 10, 2012 at 11:40:47PM +0900, JoonSoo Kim wrote:
>
> [..]
> > > So without knowing details of both the data structures, I think if vmlist
> > > is going away, then user space tools should be able to traverse
> > > vmap_area_root
> > > rb tree. I am ass
s next field, they have no method for traversing.
> So, IMHO, assigning dummy vm_struct to vmlist which is implemented by [7/8] is
> a safe way to maintain a compatibility of userspace tool. :)
Why bother keeping vmlist around? kdump's makedumpfile command would not
even need to traverse the v
The 2.6.25 ptrace_bts_config structure in asm-x86/ptrace-abi.h
is defined with u32 types:
#include
/* configuration/status structure used in PTRACE_BTS_CONFIG and
PTRACE_BTS_STATUS commands.
*/
struct ptrace_bts_config {
/* requested or actual size of BTS buffer in bytes
ected. Interesting to note that the test binary couldn't
be compiled with i386 gcc, but it could be built with x86_64
gcc -m32.
Dave
Always use O_LARGEFILE for opening executables
This allows to use executables >2GB.
Based on a patch by Dave Anderson
Signed-off-by: Andi Kleen <
Andi Kleen wrote:
I agree in theory. We've only seen instances on 64-bitters...
I think that's because gcc does not support the medium/large code models
for i386. Although in theory someone could create an executable with
a large enough .data.
-Andi
Or perhaps huge debuginfo section(s)? T
Andi Kleen wrote:
Dave Anderson <[EMAIL PROTECTED]> writes:
When a executable that is greater than 2GB in size is attempted on a 64-bit
system on a file system that calls, or uses generic_file_open() as its
open handler, it fails with an EOVERFLOW erro. This patch adds a c
When a executable that is greater than 2GB in size is attempted on a 64-bit
system on a file system that calls, or uses generic_file_open() as its
open handler, it fails with an EOVERFLOW erro. This patch adds a call
to force_o_largefile() call in open_exec(), as done in sys_open() and
sys_openat
"Eric W. Biederman" wrote:
> Dave Anderson <[EMAIL PROTECTED]> writes:
>
> > vivek goyal wrote:
> >
> > > Hi,
> > >
> > > Kdump (A kexec based crash dumping mechanism) is going to export the
> > > kernel core image in ELF for
_vaddr values for the higher
memory segments? FWIW, with the single-PT_LOAD segment currently
supported by crash, there's only one p_vaddr, but in any case, crash doesn't
use it, so PAE is not a problem.
Dave Anderson
>
> Any thoughts or suggestions on this?
>
> Th
27 matches
Mail list logo
