Re: [PATCH v2] xfs: make fatal assert failures conditional in debug mode

[Brian Foster <bfoster@redhat.com>]

On Wed, May 10, 2017 at 08:54:32PM +1000, Dave Chinner wrote:
> On Tue, May 09, 2017 at 01:00:50PM -0400, Brian Foster wrote:
> > I rarely, if ever, have a need for assert failures to bug the kernel.
> 
> I absolutely rely on it to debug problems with the system in the
> state that the problem was detected.
> 
> IOWs, what works for one person does not work for everyone.
> 

That's been the premise from the start. The current default assert
behavior does not change.

> > I'd like to be able to just turn it off in my default configs (without
> > disrupting the cases where it is useful).
> 
> So, as Darrick suggested, make the sysctl value kconfig selectable.
> you get what you want and it's runtime selectable...
> 

v3 will probably do something like define a
/sys/fs/xfs/debug/bug_on_assert flag that is used to toggle assert
behavior from a combined variant of ass[warn|fail](). The FATAL_ASSERT
config option basically just controls the default value of the flag.

Brian

> > > > As mentioned previously, we can be more granular than the current binary
> > > > toggle for debug mode. E.g., we could separate diagnostic mechanisms
> > > > from test coverage mechanisms and enable the latter at a higher debug
> > > > level or with a separate option entirely, if desired. IOW, I don't think
> > > > that's a difficult problem to solve.
> > > 
> > > Agreed.
> 
> Please don't. It took us years to get rid of all the stale special
> snowflake conditional debug code we inherited from Irix that
> bitrotted and broke because nobody ever set, say, XFS_TRANS_DEBUG in
> their build, let alone tried to run a kernel with it.  We took what
> was useful and put it under XFS_DEBUG so that it was always run, and
> the XFS code has been so much better for it....
> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> david@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html