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

["Shreya Gangan (shgangan)" <shgangan@xxxxxxxxx>]

Hi Richard,

On 5/15/19, 2:01 PM, "Richard Weinberger" <richard.weinberger@xxxxxxxxx> wrote:

> On Wed, May 15, 2019 at 10:45 PM Shreya Gangan (shgangan) <shgangan@xxxxxxxxx> wrote:
> >
> > Hi,
> >
> >  /fs/ubifs/io.c has dump_stack() in multiple functions upon errors and sometimes warnings.
> > Since the error and warning messages seem to be unique, the functional value of these dump_stacks is not apparent.
> > Why are these dump_stacks required and what issues might occur upon the removal of these?

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

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

Regards,
Shreya

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/