[lkml]   [2019]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


 \ /
  Last update: 2019-05-16 10:28    [W:0.034 / U:45.648 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site