All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 2/2] ext4: add ext4_iget_normal() which is to be used for dir tree lookups
Date: Sun, 5 Oct 2014 23:16:04 -0400	[thread overview]
Message-ID: <20141006031604.GB5755@thunk.org> (raw)
In-Reply-To: <CCC111D5-362C-40B5-B19C-24C4E66BD963@dilger.ca>

On Sun, Oct 05, 2014 at 08:52:38PM -0600, Andreas Dilger wrote:
> On Oct 5, 2014, at 8:48 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> > If there is a corrupted file system which has directory entries that
> > point at reserved, metadata inodes, prohibit them from being used by
> > treating them the same way we treat Boot Loader inodes --- that is,
> > mark them to be bad inodes.  This prohibits them from being opened,
> > deleted, or modified via chmod, chown, utimes, etc.
> > 
> > In particular, this prevents a corrupted file system which has a
> > directory entry which points at the journal inode from being deleted
> > and being released, after which point Much Hilarity Ensues.
> 
> Wouldn't it be safer to change "ext4_iget()" to have these checks, 
> and add an "ext4_iget_special()" or "ext4_iget_reserved()" for use
> in the few places that are opening reserved inodes?  That would
> probably be safer for the future.

There is actually much larger set of places where we iget reserved
inodes -- in fact, double the he number of places where we return
inodes back up to the VFS --- 3 for the latter, and 6 for the former.

As for future additions, it's much more likely that we would be adding
new code paths to read reserved inodes.  New VFS functionality tends
to go through the dcache layer, so I don't see the likelihood of
needing to add a new call to ext4_iget_normal() any time soon.

Cheers,

						- Ted

  reply	other threads:[~2014-10-06  3:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-05  0:12 Intentionally corrupted ext4s causing two different kernel panics at umount Sami Liedes
2014-10-06  2:48 ` [PATCH 1/2] ext4: don't orphan or truncate the boot loader inode Theodore Ts'o
2014-10-06  2:48   ` [PATCH 2/2] ext4: add ext4_iget_normal() which is to be used for dir tree lookups Theodore Ts'o
2014-10-06  2:52     ` Andreas Dilger
2014-10-06  3:16       ` Theodore Ts'o [this message]
2014-10-06 15:09     ` Jan Kara
2014-10-06 18:55       ` Theodore Ts'o
2014-10-06 15:06   ` [PATCH 1/2] ext4: don't orphan or truncate the boot loader inode Jan Kara
2014-10-07 20:56 ` One more corrupted fs crash in ext4_put_super Sami Liedes
2014-10-07 21:57   ` Darrick J. Wong
2014-10-07 22:22     ` Darrick J. Wong
2014-10-09 20:15   ` Sami Liedes
2014-10-09 20:49     ` Darrick J. Wong
2014-10-09 21:28       ` A very similar crash on ext2 Sami Liedes
2014-10-21  0:28         ` Darrick J. Wong

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=20141006031604.GB5755@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    /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.