linux-ext4 - Re: [PATCH] ext4: printk stack trace on ext4_error, ext4_abort and ext4

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

Date:	Thu, 15 May 2008 09:55:29 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	cmm@...ibm.com, tytso@....edu, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: printk stack trace on ext4_error, ext4_abort and
	ext4_warning.

On Wed, May 14, 2008 at 02:07:14PM -0500, Eric Sandeen wrote:
> Aneesh Kumar K.V wrote:
> > This helps in better debugging of the problem reported.
> 
> ext4_error happens potentially often in some scenarios, and if I chose
> errors=continue I'm not sure I'd want to dump this much.
> 
> Would it be worth limiting how often this goes off (maybe just once per fs?)
> 

I actually thought of doing that. But won't rate limiting hide different
scenarios in which we can hit the error ? What we would like to know is
what system call actually caused the file system error. So that we can
try to reproduce the same. Rate limiting would prevent multiple possible
errors.

As Ted mentioned the right fix would be audit all the
ext4_error/warning/abort call sites and add a WARN_ON or WARN_ON_ONCE
where ever we find it useful.

-aneesh

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