linux-ext4 - Re: [RFC] Journal credits debugging (Was: Re: Bug#615998: ...)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANf+_kJnFyTEVvPJj261rTzW+iD1c0D+SuJAn=Runufkt30J5Q@mail.gmail.com>
Date:	Sat, 2 Jul 2011 19:12:12 +0800
From:	Ding Dinghua <dingdinghua85@...il.com>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [RFC] Journal credits debugging (Was: Re: Bug#615998: ...)

2011/6/29 Andreas Dilger <adilger@...ger.ca>
>
> On 2011-06-29, at 1:10 AM, Amir Goldstein wrote:
> > I would like to suggest an approach that may help us track down these
> > sort of bugs more easily.
> >
> > Add a new class_id argument to ext4_handle_dirty_metadata() and collect
> > statistics of used credits per class_id.
> >
> > There are only so many types of journaled objects:
> > SUPER, GDT, BB, IB, ITB, IND, EXT, DATA, XATTR, QUOT...
> > So it shouldn't be a problem to save the statistics per handle.
> >
> > If you look at struct jbd2_journal_handle, you will find a bunch of h_cow_XXX
> > fields intended as COW debugging counters.
> > We may as well turn these fields into a generic counters array, which can
> > be used by either COW debugging or credits debugging code.
> >
> > This should be simple enough to implement and should provide
> > a more detailed report when buffer credits have run out.
> >
> > However, if we are going to modify all call sites of
> > ext4_handle_dirty_metadata(), it would be wise to also add an object_id
> > (or a better name) argument that will provide the group no. or inode no.
> > or quota type, or any other id relevant for classification.
> >
> > We can use this information, along with where, line, handle, ino,
> > block_nr, buffer_credits and create a stable trace point in
> > __ext4_handle_dirty_metadata().
>
> One of the things I like about the ZFS/DMU transaction API is that instead
> of the caller having to "just know" how many credits are needed to modify
> the filesystem, the caller specifies the inodes/directories that will be
> modified, and if new inodes are allocated in a "declaration" step before
> starting the transaction.  This allows the internal code to account for the
> metadata will be modified, and avoids the knowledge of journal credits for
> different update types all over the code.

Would you please give more details about this? I don't think it's
different from Jbd/Jbd2
at first glance

>
> Cheers, Andreas
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
Ding Dinghua
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html