All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daeho Jeong <daeho.jeong@samsung.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: jack@suse.cz,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	이기태 <kitae87.lee@samsung.com>
Subject: Re: [PATCH] ext4: guarantee already started handles to successfully finish while ro remounting
Date: Fri, 06 May 2016 06:01:12 +0000 (GMT)	[thread overview]
Message-ID: <593570881.453531462514471895.JavaMail.weblogic@ep2mlwas08c> (raw)

> Hmm, I'm not really comfortable with putting this hack in, since this
> is papering over the real problem, which is that Android is trying to
> use the emergency remount read-only sysrq option and this is
> fundamentally unsafe.  I'm not sure what else could break if it is
> situation normal that there is active processes busily writing to the
> file system and sysrq-u followed by reboot is the normal way the
> Android kernel does a reboot.

> A much better solution would be to change the Android userspace to
> call the FIFREEZE ioctl on each mounted file system, and then call for
> a reboot.

I agree with you. I know that current Android shutdown procedure is
not a safe way. But, without this patch, "even not in Android system",
when we trigger the emergency read-only remount while evicting inodes,
i_size of the inode becomes zero and the inode is not in orphan list,
but blocks of the inode are still allocated to the inode, because
ext4_truncate() will fail while stating the handle which was already started
by ext4_evict_inode(). This causes the filesystem inconsistency and
we will encounter an ext4 kernel panic in the next boot by this problem.

I think that this kind of filesystem crash can occur anywhere that
the same journal handle is repeatly used. During an atomic filesystem
operation, a part of the operation will succeed and the other one will fail.

             reply	other threads:[~2016-05-06  6:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-06  6:01 Daeho Jeong [this message]
2016-05-06 13:00 ` [PATCH] ext4: guarantee already started handles to successfully finish while ro remounting Theodore Ts'o
2016-05-06 20:01   ` Andreas Dilger
2016-05-06 23:36     ` tytso
2016-05-09  8:40       ` Jan Kara
  -- strict thread matches above, loose matches on Subject: below --
2016-05-07 13:05 Daeho Jeong
2016-05-07 17:47 ` Theodore Ts'o
2016-05-06  5:35 Daeho Jeong
2016-05-02  0:50 Daeho Jeong
2016-05-05 13:45 ` Jan Kara
2016-05-05 15:44 ` Theodore Ts'o

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=593570881.453531462514471895.JavaMail.weblogic@ep2mlwas08c \
    --to=daeho.jeong@samsung.com \
    --cc=jack@suse.cz \
    --cc=kitae87.lee@samsung.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.