All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tao Ma <tm@tao.ma>
To: Theodore Tso <tytso@MIT.EDU>
Cc: Christoph Hellwig <hch@infradead.org>,
	Dave Chinner <david@fromorbit.com>,
	Jiaying Zhang <jiayingz@google.com>,
	linux-ext4@vger.kernel.org
Subject: Re: [URGENT PATCH] ext4: fix potential deadlock in ext4_evict_inode()
Date: Fri, 26 Aug 2011 22:53:03 +0800	[thread overview]
Message-ID: <4E57B34F.6010508@tao.ma> (raw)
In-Reply-To: <22BEE903-4141-4D2A-932B-259DF50F14E1@mit.edu>

On 08/26/2011 07:35 PM, Theodore Tso wrote:
> 
> On Aug 26, 2011, at 5:17 AM, Christoph Hellwig wrote:
> 
>> The thing I have queued up for 3.2 makes it very simple:  we do not
>> track I/O ends any more at all, outside of the workqueue.
>>
>> For buffered I/O we only mark the page uptodate when all unwritten
>> extent conversion and size updates have finished.  All data integrity
>> callers and inode eviction wait for the pages to be update so we are
>> covered.
>>
>> For direct I/O we only call inode_dio_done and aio_complete once all
>> unwritten extent size updates are done.  Inodes can't be evicted until
>> we drop a reference to the inode, which can't happen until the
>> sync or async dio is done and we drop the inode reference the VFS
>> holds for it.  Sync and fsync are only guaranteed to pick up I/O
>> that has returned to userspace, so we are covered for that as well.
> 
> Long term, I definitely want to make ext4 do something similar. 
> What we have now is just way too fragile…
yeah, actually I have done some basic tests about letting
ext4_free_io_end to clear the page writeback flag for us after the
unwritten extent conversion, and it does have several problems with both
ext4 and jbd2. I will try to write up some solution for review.

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

  reply	other threads:[~2011-08-26 14:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-26  3:33 [URGENT PATCH] ext4: fix potential deadlock in ext4_evict_inode() Theodore Ts'o
2011-08-26  3:56 ` Tao Ma
2011-08-26  9:28   ` Tao Ma
2011-08-26  7:35 ` Dave Chinner
2011-08-26  7:42   ` Tao Ma
2011-08-26  8:44   ` Dave Chinner
2011-08-26  8:50     ` Christoph Hellwig
2011-08-26  9:10       ` Tao Ma
2011-08-26  9:17         ` Christoph Hellwig
2011-08-26 11:35           ` Theodore Tso
2011-08-26 14:53             ` Tao Ma [this message]
2011-08-26  9:03     ` Tao Ma
2011-08-26  9:24       ` Dave Chinner
2011-08-26  9:27         ` Tao Ma
2011-08-26 15:52           ` Ted Ts'o
2011-08-26 16:58             ` Jiaying Zhang
2011-08-26 20:22               ` Ted Ts'o
2011-08-27  5:17                 ` Jiaying Zhang
2011-08-31  1:15                   ` Jiaying Zhang

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=4E57B34F.6010508@tao.ma \
    --to=tm@tao.ma \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=jiayingz@google.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@MIT.EDU \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.