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

[Richard Weinberger <richard@nod.at>]

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