lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20080119000119.3524B26F9FD@magilla.localdomain>
Date:	Fri, 18 Jan 2008 16:01:19 -0800 (PST)
From:	Roland McGrath <roland@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Hiroshi Shimamoto <h-shimamoto@...jp.nec.com>, tglx@...utronix.de,
	hpa@...or.com, linux-kernel@...r.kernel.org
Subject: Re: x86: kdump failure

Oops, I overlooked the use of elf_core_copy_regs in kernel/kexec.c.  It
is certainly safe and fine to reintroduce the old macro.  Everything
removed in the "x86 user_regset cleanup" patch is purely removing code
and it doesn't hurt to have it back (it's just all unused except for this
kexec nit).

Unfortunately it really doesn't fit to have kexec call into the new
user_regset code that replaced this macro for user core dump purposes.
Those new interfaces are really purely for user-mode state, derived only
from task_struct (i.e. uses task_pt_regs), not from a struct pt_regs
pointer passed in.  (There is the minority case where it really is using
user-mode state.  That part could be done via the user_regset interface,
if that saved any trouble.)

Things like crash_fixup_ss_esp point to the poor fit of the code intended
for user core dumps with what kexec needs.  IMHO it would be cleaner for
kexec's arch interfaces to fill in elf_gregset_t directly, replacing some
of the places a struct pt_regs is passed around now.
crash_setup_regs already has to know the name of every register anyway.
A particular arch's definition can share code with its core dump or
user_regset code when that fits.


Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ