Re: [PATCH 1/1] btrfs: tests: remove unnecessary oom message

[David Sterba <dsterba@suse.cz>]

On Fri, Jun 18, 2021 at 02:05:59PM +0800, Qu Wenruo wrote:
> On 2021/6/18 下午1:58, Qu Wenruo wrote:
> > On 2021/6/18 上午10:33, Leizhen (ThunderTown) wrote:
> >> On 2021/6/18 4:35, David Sterba wrote:
> >>> On Thu, Jun 17, 2021 at 04:30:53PM +0800, Zhen Lei wrote:
> >>>> Fixes scripts/checkpatch.pl warning:
> >>>> WARNING: Possible unnecessary 'out of memory' message
> >>>>
> >>>> Remove it can help us save a bit of memory.
> >>>
> >>> Well, we have a few more messages in tests regarding failed memory
> >>> allocations.  Though I've never seen one in practice, I think it's not
> >>> a big deal to have that one here as well. The failures in the testsuite
> >>> are intentionally verbose and saving a few bytes in optional development
> >>> feature hardly bothers anyone.
> >>
> >> The calltrace of the OOM message contains all the information printed by
> >> test_err() here. I don't think anyone wants to see a bunch of
> >> unhelpful tips
> >> when locating an OOM problem.
> >
> > This only get enabled for btrfs developers, in production environment
> > would enable CONFIG_BTRFS_FS_RUN_SANITY_TESTS=y.
> >
> > Thus this error message are only for btrfs developers.
> >
> > And I'm 100% sure you won't need to investigate such OOM problem, nor
> > even see it.
> >
> >>> Where bytes can be saved are error messages for the same type of error,
> >>
> >> It also saves a dozen bytes of binary code.
> >
> > It won't make any different as you won't enable that config.
> >
> >>> that I've implemented in the past, see file fs/btrfs/tests/btrfs-tests.c
> >>> array test_error that maps enums to strings.
> >>
> >> As mentioned above, I don't think these "no memory" strings are
> >> necessary,
> >> unless the rest of the test can continue to run healthy. Otherwise, no
> >> one trusts
> >> the test results in the OOM situation. They're going to locate the OOM
> >> problem
> >> first, and these information are pointless. >
> 
> And nope, it's not only OOM can cause the selftest to fail, but also
> error injection.
> 
> I guess you never ran error injection tests for filesystems.
> 
> Under most case, we inject error with specific call chain, but sometimes
> without any call chain specification, error injection may find some
> corner cases we're unaware of.
> 
> If by chance the injected memory allocation failure happens during
> selftest, there will be *NO* OOM dump at all.

Yeah, a hard OOM won't probably happen and the allocations can fail for
other valid reasons.  The error message in the logs, with the ERROR
message level is clear and helpful. Saving a few bytes here does not
make much sense.