linux-kernel - Re: Removal of dump_stack()s from /fs/ubifs/io.c

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1060037520.60545.1557995273554.JavaMail.zimbra@nod.at>
Date:   Thu, 16 May 2019 10:27:53 +0200 (CEST)
From:   Richard Weinberger <richard@....at>
To:     "Shreya Gangan (shgangan)" <shgangan@...co.com>
Cc:     linux-mtd <linux-mtd@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Removal of dump_stack()s from /fs/ubifs/io.c

----- Ursprüngliche Mail -----
>> They are not required, but they are just useful. While you are right that the
>> locations within UBIFS are unique,
>> they are not for the whole kernel context.
>> Filesystem functions can get called via many different paths from VFS...
> 
> Isn't that true for any kernel error though.
> Want to understand why it would be essential for ubifs to have these over the
> other kernel modules?
> Can't the developer add the dump_stack later for debugging reasons?

In UBIFS the dump_stack() calls are more or less a WARN_ON().
Such situations should not happen. If they do, we want the details.

So, in the long rung we could replace most of them by a WARN_ON().
Maybe even WARN_ON_ONCE().

>> Why do you want to remove them, what is the benefit?
> 
> The way our system is using the ubifs, for a device which is 'no longer there'
> could be frequent
> 'no such device' errors when
> 1. there might be multiple write accesses to the filesystem before the
> responsible process is terminated
> 2. the filesystem is unmounted after this
> The result would be flooding of the console or message logs with both the error
> messages and the dump_stack,
> making it really ugly.
> Is there a specific way a 'no such device' issue is handled to avoid the
> messages from flooding with the dump_stacks?

I don't follow, sorry.

If your system too noisy, fix the log level. But usually when UBIFS prints
an error followed by a stack trace, it is something serious you should address
and not trying to make the error message look less scary.

Thanks,
//richard