linux-kernel - [patch 0/8] Series to improve the x86 backtracing code

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-next>] [day] [month] [year] [list]

Date:	Fri, 11 Jan 2008 21:26:23 -0800
From:	Arjan van de Ven <arjan@...radead.org>
To:	linux-kernel@...r.kernel.org
Cc:	mingo@...e.hu, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org, tglx@...x.de, hpa@...or.com
Subject: [patch 0/8] Series to improve the x86 backtracing code

Hi,

this patch series improves the x86 backtracing code in the following ways:
1) Fix a bad bug in x86 (32 bit) FRAME_POINTER backtracing (2.6.24 material)
2) Add the capability to mark a backtrace entry as reliable / unreliable
3) Change the x86 (32 bit) FRAME_POINTER backtracing to use the normal backtrace but use the frames
   as guidance to the reliability of the backtrace entries
4) Patch to capture the EBP register earlier in the backtrace callchain to get a better FRAME_POINTER
   based backtrace
5) Split the x86 (64 bit) backtrace code up similar to the 32 bit code by turning a macro into a function
6) Enable FRAME_POINTER backtracing on 64 bit similar to the 32 bit patch in number 3
7) Add a simple self-test module for backtraces (will move to tests/ later when that gets merged)
8) Add the feature to x86 64bit to print a set of bytes prior to the current EIP in the Code: line
   (already present in 32 bit)

I have not yet implemented 2 requested items
1) To give dump_stack() and co a parameter towards the KERN_ log level; this is a patch that touches 125 files
   and while I like the idea I'm not sure it's worth THAT.
2) Linus' request to only print the first 5 entries of a backtrace with a important loglevel, and do the rest
   as KERN_WARNING  or so. This realistically wants 1) and I've not gotten to it yet (and it's independent functionality
   anyway)


Andrew:  You already have patch 1 in your tree, and it's not modified since that, so no need to refresh

-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/