From: Theodore Ts'o <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: "Dr. Tilmann Bubeck" <t.bubeck@reinform.de>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH -v3] ext4: implementation of a new ioctl called EXT4_IOC_SWAP_BOOT
Date: Sun, 7 Apr 2013 15:48:55 -0400 [thread overview]
Message-ID: <20130407194855.GA5292@thunk.org> (raw)
In-Reply-To: <45E0D5C6-50E8-4F2E-83DC-3E24A31D7573@dilger.ca>
On Sun, Apr 07, 2013 at 11:09:58AM -0600, Andreas Dilger wrote:
> > + filemap_flush(inode_bl->i_mapping);
>
> Technically, it shouldn't be possible to have dirty pages on the
> bootloader inode, since any inode swapped there will itself have
> been flushed, and should not be directly accessible after that
> point. That said, I guess this ioctl() won't be called too often so
> the empty flush is mostly harmless.
Yes, technically there should be no mappings for the inode boot
loader. (Well, unless someone had one of the unofficial open-by-inode
number patches).
> > + if (inode_bl->i_nlink == 0) {
> > + /* this inode has never been used as a BOOT_LOADER */
> > + set_nlink(inode_bl, 1);
> > + i_uid_write(inode_bl, 0);
> > + i_gid_write(inode_bl, 0);
> > + inode_bl->i_flags = 0;
> > + ei_bl->i_flags = 0;
> > + inode_bl->i_version = 1;
> > + i_size_write(inode_bl, 0);
> > + inode_bl->i_mode = S_IFREG;
> > + if (EXT4_HAS_INCOMPAT_FEATURE(sb,
> > + EXT4_FEATURE_INCOMPAT_EXTENTS)) {
> > + ext4_set_inode_flag(inode_bl, EXT4_INODE_EXTENTS);
> > + ext4_ext_tree_init(handle, inode_bl);
> > + } else
> > + memset(ei_bl->i_data, 0, sizeof(ei_bl->i_data));
>
> I don't understand this. Wouldn't this clobber the block pointers if
> an existing boot inode and cause them to leak? This seems broken to me.
If i_nlink is zero, then there is no existing boot loader inode. In
theory the rest of the inode is zero, but this is to make sure the
inode is initialized to something sane before we swap it into the
user-visible inode.
I'll fix up the rest of the minor errors and typos which you pointed
out, thanks!
- Ted
next prev parent reply other threads:[~2013-04-07 19:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-25 8:18 Use EXT4_BOOT_LOADER_INO for boot loader GRUB? Dr. Tilmann Bubeck
2013-01-26 18:49 ` Theodore Ts'o
2013-02-06 2:15 ` Phillip Susi
2013-02-19 21:15 ` Dr. Tilmann Bubeck
2013-03-18 13:26 ` Dr. Tilmann Bubeck
2013-03-18 13:51 ` Theodore Ts'o
2013-04-07 2:47 ` [PATCH -v3] ext4: implementation of a new ioctl called EXT4_IOC_SWAP_BOOT Theodore Ts'o
2013-04-07 17:09 ` Andreas Dilger
2013-04-07 19:48 ` Theodore Ts'o [this message]
2013-04-07 21:29 ` Andreas Dilger
2013-04-07 18:43 ` Dr. Tilmann Bubeck
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=20130407194855.GA5292@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=t.bubeck@reinform.de \
/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 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).