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  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]
Date:   Thu, 16 May 2019 10:27:53 +0200 (CEST)
From:   Richard Weinberger <>
To:     "Shreya Gangan (shgangan)" <>
Cc:     linux-mtd <>,
        linux-kernel <>
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.


Powered by blists - more mailing lists