linux-ext4 - Re: [PATCH 2/5] jbd2: optimize jbd2_journal_force

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: <20130423085140.GB4596@quack.suse.cz>
Date:	Tue, 23 Apr 2013 10:51:40 +0200
From:	Jan Kara <jack@...e.cz>
To:	Dmitry Monakhov <dmonakhov@...nvz.org>
Cc:	Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org
Subject: Re: [PATCH 2/5] jbd2: optimize jbd2_journal_force_commit

On Mon 22-04-13 12:11:11, Dmitry Monakhov wrote:
> On Thu, 18 Apr 2013 20:07:27 +0200, Jan Kara <jack@...e.cz> wrote:
> > On Wed 17-04-13 11:39:27, Dmitry Monakhov wrote:
> > > On Mon, 15 Apr 2013 14:29:13 +0200, Jan Kara <jack@...e.cz> wrote:
> > > > On Sun 14-04-13 23:01:34, Dmitry Monakhov wrote:
> > > > > Current implementation of jbd2_journal_force_commit() is suboptimal because
> > > > > result in empty and useless commits. But callers just want to force and wait
> > > > > any unfinished commits. We already has jbd2_journal_force_commit_nested()
> > > > > which does exactly what we want, except we are guaranteed that we do not hold
> > > > > journal transaction open.
> > > >   Umm, I have a questions regarding this patch:
> > > > Grep shows there are just two places in the code which use
> > > > ext4_force_commit() (and thus jbd2_journal_force_commit()). These are
> > > > ext4_write_inode() and ext4_sync_file() (in data=journal mode). The first
> > > > callsite can use _nested() variant immediately as we even assert there's
> > > > no handle started. The second call site can use the _nested variant as well
> > > > because if we had the transaction started when entering ext4_sync_file() we
> > > > would have serious problems (lock inversion, deadlocks in !data=journal
> > > > modes) anyway. So IMO there's no need for !nested variant at all (at least
> > > > in ext4, ocfs2 uses it as well, IMHO it can be converted as well but that's
> > > > a different topic). Thoughts?
> > > I'm not sure that I completely understand what you meant, but it seems
> > > incorrect to use jbd2_journal_force_commit_nested() in 
> > > ext4_write_inode() and ext4_sync_file(). Because nested variant has
> > > probabilistic behavior, It may skip real transaction commit if we hold
> > > a transaction running.  ext4_write_inode() and ext4_sync_file() 
> > > are the functions where we demand deterministic behavior. If we silently
> > > miss real transaction commit because current->journal_info != NULL (due
> > > to some bugs) this breaks data integrity assumptions and it is better to
> > > make it loud and trigger a BUGON.
> >   I see. I was confused by the fact that 'nested' argument got used only in
> > the assertion but now I see why that is.
> Do you give me your ACK/Reviewed  signature?
  Looking at it with a fresh mind I think there's still one bug:
 	read_unlock(&journal->j_state_lock);
 	if (need_to_start)
-		jbd2_log_start_commit(journal, tid);
-	jbd2_log_wait_commit(journal, tid);
-	return 1;
+		ret = jbd2_log_start_commit(journal, tid);
+	if (!ret)
+		ret = jbd2_log_wait_commit(journal, tid);
  jbd2_log_start_commit() will return 0 if it didn't wake jbd2 thread and 1
if it did. In either case we should call jbd2_log_wait_commit()...

+	if (!ret && progress)
+		*progress = 1;

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
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