Re: XFS Lock debugging noise or real problem?

[Linda Walsh <xfs@tlinx.org>]

Dave Chinner wrote:
> Once again,
> "a problem with the generic code inverting the normal lock order".
>
> This one cannot deadlock, though, because by definition
> any inode on the unused list is, well, unused and hence we can't be
> holding a reference to it...
----

	This is great, maybe...but what do you mean by "generic"?

	Is this generic in the FS layer such that we'd see
this with all FS types?  Or is it generic "XFS" code that only
happens with various, "application", (user) coded applications that
use locking in a correct, but non-standard order?  Some of these
messages come out of utilities that I wouldn't think would be using
kernel-locking, 'explicitly', at all (gnu-sort).

	If the generic code didn't invert lock orders from the "norm",
could these errors be deleted?  Is it code that all resides in the
kernel and could be made consistent or is it also user-level (or glibc)
apps that are using locks in strange, but correct ways?

I'd *like* to keep lock provability 'on' -- but I don't want
to waste people's time chasing after non-problems and so far I've
seen at least 3 different locking sequences that all appear to be
harmless.

	The problem with false positives is that it will either force
the user to ignore (or turn off) the validation code, or generate
periodic noise when these things arise...

	Isn't it generally considered pretty 'bad' to generate so many
false positives -- or is lock-proving only for for "lock debugging" --
and not to be used except on development or test systems?