LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Eric Paris <eparis@redhat.com>,
	linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: general protection fault:  from release_blocks_on_commit
Date: Mon, 27 Oct 2008 19:28:43 -0400	[thread overview]
Message-ID: <20081027232843.GA9797@mit.edu> (raw)
In-Reply-To: <49064027.9010509@redhat.com>

On Mon, Oct 27, 2008 at 05:26:47PM -0500, Eric Sandeen wrote:
> Ted, you probably need some slab debugging on to hit it.

I had slab debugging enabled, but haven't been able to replicate it
yet.  I'll do some more work to try to replicate it.

> I think the problem is that jbd2_journal_commit_transaction may call
> __jbd2_journal_drop_transaction(journal, commit_transaction) if the
> checkpoint lists are NULL, and this frees the commit_transaction.

I think you're right.  I would probably change the patch around so
that after calling __jbd2_jurnal_drop_transaction(), we set
commit_transaction to NULL, and then adding an "if
(commit_transaction)" to the lines in questions; that way we keep the
commit callback outside of the j_list_lock() spinlock.

> Also, I'm not certain that it matters, but the loop in 
> release_blocks_on_commit() is kfreeing list entries w/o taking
> them off the list; I suppose maybe this is safe if the whole thing
> is getting discarded when we're done, but just to keep things sane,
> would this make sense

There are plenty of other loops in the kernel where we go through the
linked list and free all of the items on the list that don't bother to
call list_del().  That was one of the things I checked when I created
the patch.

> (also, I think we need to double-check use of
> s_md_lock; it's taken when adding things to the list, but not when
> freeing/removing ... if it's needed, isn't it needed on both ends...):

No, because the linked list is hanging off the transaction structure.
While the transaction is active, multiple CPU's can be adding elements
to the linked list.  But once the transaction has been committed, we
don't have to worry about any one else trying to modify the linked list.

      	      	    	      	       	      - Ted

  reply	other threads:[~2008-10-27 23:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-21 18:03 Eric Paris
2008-10-27 18:19 ` Theodore Tso
2008-10-27 22:26   ` Eric Sandeen
2008-10-27 23:28     ` Theodore Tso [this message]
2008-10-28  0:08       ` Eric Sandeen
2008-10-28  1:52         ` Theodore Tso
2008-10-28  2:15           ` Eric Sandeen
2008-10-28  2:28           ` [PATCH, RFC] jbd2: Call the commit callback before the transaction could get dropped Theodore Tso
2008-10-28  2:41             ` Eric Sandeen
2008-10-28 13:46               ` Eric Paris

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081027232843.GA9797@mit.edu \
    --to=tytso@mit.edu \
    --cc=eparis@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --subject='Re: general protection fault:  from release_blocks_on_commit' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).