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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <5B190BFA-DF2A-4469-85E2-14A7347B7A8E@cisco.com>
Date:   Wed, 15 May 2019 23:27:44 +0000
From:   "Shreya Gangan (shgangan)" <shgangan@...co.com>
To:     Richard Weinberger <richard.weinberger@...il.com>
CC:     "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Removal of dump_stack()s from /fs/ubifs/io.c

Hi Richard,

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

> On Wed, May 15, 2019 at 10:45 PM Shreya Gangan (shgangan) <shgangan@...co.com> 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