linux-ext4 - Re: [PATCH 1/2] ext4: call WARN

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]

Message-ID: <alpine.LFD.2.00.1301251012200.20753@localhost>
Date:	Fri, 25 Jan 2013 10:22:44 +0100 (CET)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	"Theodore Ts'o" <tytso@....edu>
cc:	Lukas Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 1/2] ext4: call WARN_ON after the debug message

On Thu, 24 Jan 2013, Theodore Ts'o wrote:

> Date: Thu, 24 Jan 2013 14:54:58 -0500
> From: Theodore Ts'o <tytso@....edu>
> To: Lukas Czerner <lczerner@...hat.com>
> Cc: linux-ext4@...r.kernel.org
> Subject: Re: [PATCH 1/2] ext4: call WARN_ON after the debug message
> 
> On Thu, Jan 24, 2013 at 05:30:43PM +0100, Lukas Czerner wrote:
> > In two places we call WARN_ON() before we print out the debug message,
> > however the custom is to print such messages before we call WARN_ON() so
> > change that.
> > 
> > Also use ext4_msg() instead of plain printk().
> > 
> > Signed-off-by: Lukas Czerner <lczerner@...hat.com>
> 
> I was actually thinking about removing the WARN_ON entirely, or at
> least suppressing it when the error begin returned from
> ext4_map_blocks is EIO.  The reason for that is the warning is causing
> noise for automated log scanners, and if the problem is caused by a
> hardware failure, there's no real point in dumping out a stack trace.
> More generally, is there any reason why we need the stack trace at
> all?
> 
> Also maybe we should use ext4_warning() instead of ext4_msg()?
> 
>      	      	     	 		- Ted

Hi Ted,

we can get the EIO error from ext4_map_blocks not only in the case
of hardware error. The extent tree might not be in consistent state,
or we could even ask for blocks outside the file system itself (I
believe I've seen this before) and I think that in those cases it
might be worth to all WARN_ON.

Also people from ABRT are working on kerneloops.org replacement (so
far it only works for Fedora)
https://retrace.fedoraproject.org/faf/problems/hot/ so we can notice
such problems, yes they catch even kernel WARNs because it usually
means that we have bug somewhere else.

I agree that it would be better to use ext4_warning(), so I'll
resend the patch.

Thanks!
-Lukas
--
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