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]
Date:	Mon, 08 Feb 2010 13:02:32 -0600
From:	Eric Sandeen <sandeen@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	tytso@....edu, Jan Kara <jack@...e.cz>,
	Christoph Egger <siccegge@...d.informatik.uni-erlangen.de>,
	linux-kernel@...r.kernel.org, Kazuo Moriwaka <moriwaka@...hat.com>,
	H Hartley Sweeten <hsweeten@...ionengravers.com>,
	Joel Becker <joel.becker@...cle.com>,
	linux-ext4@...r.kernel.org, vamos@...informatik.uni-erlangen.de
Subject: Re: [PATCH] obsolete config in kernel source (BUFFER_DEBUG)

Andrew Morton wrote:
> On Mon, 8 Feb 2010 10:50:31 -0500 tytso@....edu wrote:
> 
>> I don't have an objection with removing this, but does anyone have the
>> latest version of akpm's buffer debugging patches?
> 
> My version is datestamped four years ago :( It normally forward-ports
> fairly easily.
> 
>> I *think* what happened is that akpm forward ported the removed buffer
>> debugging patches, or maybe rewrote it from scratch, but for whatever
>> reason they never made back into mainline.  Maybe they were too ugly
>> to live in mainline, but they have been really handy on occasion.
> 
> I think Eric Sandeen might have a fresher version. 

If "fresh" means 2.6.18, I might ;)

But yes they sure have come in handy from time to time.

> Nowadays it should
> be done with the tracing infrastructure, I guess.

that's kind of what I was thinking, too.

-Eric

>  Although that
> infrastructure may not be able to do this - the ext3 debug patch
> recorded an LRU array of the below structs within every buffer_head. 
> The various BUFFER_TRACE macros would emit a new record into the tail of the
> target bh's b[] ring.
> 
> struct buffer_history {
> 	struct buffer_history_item {
> 		char *function;
> 		char *info;
> 		unsigned long b_state;
> 		unsigned b_list:3;
> 		unsigned b_jlist:4;
> 		unsigned pg_dirty:1;
> 		unsigned cpu:3;
> 		unsigned b_count:8;
> 		unsigned long b_blocknr;	/* For src != dest */
> #if defined(CONFIG_JBD) || defined(CONFIG_JBD_MODULE)
> 		unsigned b_jcount:4;
> 		unsigned b_jbd:1;
> 		unsigned b_transaction:1;
> 		unsigned b_next_transaction:1;
> 		unsigned b_cp_transaction:1;
> 		unsigned b_trans_is_running:1;
> 		unsigned b_trans_is_committing:1;
> 		void *b_frozen_data;
> 		void *b_committed_data;
> #endif
> 	} b[BUFFER_HISTORY_SIZE];
> 	unsigned long b_history_head;	/* Next place to write */
> 	unsigned long b_history_tail;	/* Oldest valid entry */
> };
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
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