linux-ext4 - Re: [RFC PATCH 0/4] ext4/jbd2: several possible mainline fixes

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20130610233850.GA21795@thunk.org>
Date:	Mon, 10 Jun 2013 19:38:51 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Paul Gortmaker <paul.gortmaker@...driver.com>
Cc:	linux-ext4@...r.kernel.org, linux-rt-users@...r.kernel.org
Subject: Re: [RFC PATCH 0/4] ext4/jbd2: several possible mainline fixes

On Mon, Jun 10, 2013 at 03:31:59PM -0400, Paul Gortmaker wrote:
> Using jbd_debug() it seems that I end up with jbd2_log_do_checkpoint
> and jbd2_journal_commit_transaction running into each other.  In one of
> my attached patches, I show they overlap to the point of interrupting
> each others jbd_debug messages.  Maybe that doesn't matter?  

That should be OK.  We do allow a new transactions while we are
committing an older transaction, and if this requires more space, a
checkpoint could start.  I'm not sure why you're apparently seeing a
deadlock under RT-linux, though.

> Stuck waiting/spinning somewhere in jbd2_journal_commit_transaction.
> As near as I can tell, it never got to phase 3 of commit_transaction.
> 
> Since jbd2_journal_commit_transaction is such a large function,
> I'm tempted to break it up some, just to ease my debugging (compare
> 0x1c20 to the smaller numbers around it).  Perhaps there would be
> interest in such kinds of patches for mainline?

Instead of breaking it up, can you just use addr2line, i.e.:

% addr2line -a ffffffff8046a067 -i -e vmlinux  
0xffffffff8046a067
./include/linux/buffer_head.h:287
./fs/ext4/inode.c:5585
./fs/ext4/inode.c:5963

I find this to be incredibly useful, since with the -i option it will
handle inline functions correctly.  In the above example there are two
levels of inlining, one explicitly marked inline in
include/linux/buffer.h, and one implicit inlining taking place because
we had a static function in fs/ext4/inode.c that was only called by
one caller.

Because of gcc's implicit inlining, just breaking up the function by
itself wouldn't be enough, unless you explicitly marked the new static
functions with noinline; but that introduces inefficiencies.  If the
only reason you want to do this is to make it easier to figure out a
stack trace, addr2line really is your friend....

Cheers,

					- Ted
--
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