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
| ||
|
Message-ID: <alpine.LFD.2.00.1301280810210.23664@dhcp-1-104.brq.redhat.com> Date: Mon, 28 Jan 2013 08:10:40 +0100 (CET) From: Lukáš Czerner <lczerner@...hat.com> To: Dave Chinner <david@...morbit.com> cc: "Theodore Ts'o" <tytso@....edu>, Lukáš Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org Subject: Re: [PATCH 1/2] ext4: call WARN_ON after the debug message On Sat, 26 Jan 2013, Dave Chinner wrote: > Date: Sat, 26 Jan 2013 12:00:55 +1100 > From: Dave Chinner <david@...morbit.com> > To: Theodore Ts'o <tytso@....edu> > Cc: Lukáš Czerner <lczerner@...hat.com>, linux-ext4@...r.kernel.org > Subject: Re: [PATCH 1/2] ext4: call WARN_ON after the debug message > > On Fri, Jan 25, 2013 at 10:09:48AM -0500, Theodore Ts'o wrote: > > On Fri, Jan 25, 2013 at 10:22:44AM +0100, Lukáš Czerner wrote: > > > > > > 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. > > > > Sure, but in those cases, the file system is corrupt, and we should > > have thrown an ext4_error() in ext4_map_blocks(). The point is that a > > WARN_ON is only useful if there is a potential programming bug. If we > > know for sure that it's caused by a file system corruption, then we > > don't want to throw a WARN_ON. > > FWIW, XFS handles this problem with an error level sysctl. For > situations like this, the default level doesn't throw stack traces > (just the error message), but there are situations where diagnosis > requires emitting the stack trace. > > Hence if it is necessary for bug triage, users can then turn the > sysctl up to 11 and the stack trace will be emitted after the > warning message. CONFIG_XFS_DEBUG sets the default log level to 11, > because developers always want to know where an error came from ;) > > Cheers, > > Dave. > That might actually be very useful. Thanks Dave! -Lukas
Powered by blists - more mailing lists