[lkml]   [2008]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: XFS Lock debugging noise or real problem?
    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

    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?

     \ /
      Last update: 2008-08-14 00:09    [W:0.019 / U:3.176 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site