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. Thanks, //richard
Re: Removal of dump_stack()s from /fs/ubifs/io.c
Hi Richard, On 5/15/19, 2:01 PM, "Richard Weinberger" wrote: > On Wed, May 15, 2019 at 10:45 PM Shreya Gangan (shgangan) > 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
Re: Removal of dump_stack()s from /fs/ubifs/io.c
On Wed, May 15, 2019 at 10:45 PM Shreya Gangan (shgangan) 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... Why do you want to remove them, what is the benefit? -- Thanks, //richard
