[Top] [All Lists]

Re: XFS Lock debugging noise or real problem?

To: xfs-oss <xfs@xxxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS Lock debugging noise or real problem?
From: Linda Walsh <xfs@xxxxxxxxx>
Date: Wed, 13 Aug 2008 18:04:16 -0700
In-reply-to: <20080814004101.GE6119@disturbed>
References: <48A093A7.40606@xxxxxxxxx> <48A09CA9.9080705@xxxxxxxxxxx> <48A0F686.2090700@xxxxxxxxx> <48A0F9FC.1070805@xxxxxxxxxxx> <48A20E9E.9090100@xxxxxxxxx> <20080813005852.GW6119@disturbed> <48A35A99.1080300@xxxxxxxxx> <20080814004101.GE6119@disturbed>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Windows/20080708)
Dave Chinner wrote:
I've asked the lockdep ppl to treat stuff like memory reclaim and
the iprune_mutex specially because of this recursive calling nature
of memory reclaim, but so far nothing has happened....
        So it's really a kernel bug, not an XFS bug...(?)

FWIW, I think that recent changes have resulted in the xfs_fsr case
(swap_extents) being annotated properly so that one should go
        If it was limited to xfs_fsr, that'd be tolerable -- but its
cropping up in random user-level-apps (imaps, sort, et al).

Well, any debugging code is really designed for test and dev systems,
not for production systems.....
        The lock-correctness code is described as a feature to provide
"provability".  It's not called "debugging" and I don't regard that as
"debugging" -- but something that any production system that wants
operational integrity over a minor 'speed hit', would "theoretically"

        If it is "debug" code, it should be labeled as such -- but
code that can mathematically guarantee that parts of the kernel operate
correctly seems like a _reliability_ feature, not a debugging feature.

        Thanks for the insight -- very appreciated.


<Prev in Thread] Current Thread [Next in Thread>