From: Peter Cordes <peter@cordes.ca>
To: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Willy Tarreau <w@1wt.eu>, Christoph Hellwig <hch@infradead.org>,
Bodo Eggert <7eggert@gmx.de>,
David Newall <davidn@davidnewall.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH 2.6.28?] don't unlink an active swapfile
Date: Fri, 14 Nov 2008 00:08:16 -0400 [thread overview]
Message-ID: <20081114040816.GS31127@cordes.ca> (raw)
In-Reply-To: <Pine.LNX.4.64.0811140234300.5027@blonde.site>
On Fri, Nov 14, 2008 at 02:37:22AM +0000, Hugh Dickins wrote:
> Peter Cordes is sorry that he rm'ed his swapfiles while they were in use,
> he then had no pathname to swapoff. It's a curious little oversight, but
> not one worth a lot of hackery.
Yeah, not a lot, but I'd say it's worth some. On the system where I
'rm -rf'ed part of a filesystem before cp -a, mkfs, cp -a, I was left
unable to umount. Plus, when I rebooted, Ubuntu's init scripts failed
to even sync the disks during shutdown. A recently-written file on
the same XFS filesystem as the swap file ended up empty because of the
unclean shutdown. :( I don't know if remount ro would have been
possible on a FS with an active swap file, but Ubuntu should have at
least tried to sync when umount failed.
> Kudos to Willy Tarreau for turning this
> around from a discussion of synthetic pathnames to how to prevent unlink.
Yeah, this is great; as a sysadmin, this produces exactly the right
behaviour, IMHO. It doesn't have any chance of leaving files marked
immutable on disk after an unclean reboot, which was a fatal flaw in
the idea of setting the i bit on swap files, either in swapon(8) or in
the kernel. That would introduce complexity for admins who would
otherwise never have to think about this. The new behaviour this adds
should make sense to most admins; They'll see
rm: swapfile: permission denied
or something, and should quickly realize that there must be something
special about active swap files. So it's discoverable (i.e.
non-mysterious) behaviour.
This prevents running with a deleted swapfile, but I can't think of a
case when that's useful, let alone worth the trouble of writing a new one every
reboot. (e.g. xfs's resvsp ioctl creates extents flagged as unwritten
which can't be swapped on, so a swapfile would have to be actually
written on most filesystems.)
And it doesn't add any size to the kernel binary, unlike my idea of
having a /proc/something/fd link that one could swapoff, having
sys_swapoff() fall back to parsing its argument as an integer index
into a list of swap areas, or other ugly ideas... :P
Thanks everyone for coming up with such a clever solution to the
pitfall I found.
> Mimic immutable: prohibit unlinking an active swapfile in may_delete()
> (and don't worry my little head over the tiny race window).
>
> Signed-off-by: Hugh Dickins <hugh@veritas.com>
> ---
> Perhaps this is too late for 2.6.28: your decision.
>
> fs/namei.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- 2.6.28-rc4/fs/namei.c 2008-10-24 09:28:19.000000000 +0100
> +++ linux/fs/namei.c 2008-11-12 11:52:44.000000000 +0000
> @@ -1378,7 +1378,7 @@ static int may_delete(struct inode *dir,
> if (IS_APPEND(dir))
> return -EPERM;
> if (check_sticky(dir, victim->d_inode)||IS_APPEND(victim->d_inode)||
> - IS_IMMUTABLE(victim->d_inode))
> + IS_IMMUTABLE(victim->d_inode) || IS_SWAPFILE(victim->d_inode))
> return -EPERM;
> if (isdir) {
> if (!S_ISDIR(victim->d_inode->i_mode))
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cor , des.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BC
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-11-14 4:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bnlDw-5vQ-7@gated-at.bofh.it>
[not found] ` <bnwpg-2EA-17@gated-at.bofh.it>
[not found] ` <bnJFK-3bu-7@gated-at.bofh.it>
2008-10-16 23:43 ` no way to swapoff a deleted swap file? Bodo Eggert
2008-10-16 23:43 ` Bodo Eggert
[not found] ` <bnR0A-4kq-1@gated-at.bofh.it>
2008-10-17 8:20 ` Bodo Eggert
2008-10-17 12:17 ` Hugh Dickins
2008-10-17 12:36 ` David Newall
2008-10-17 22:42 ` Bodo Eggert
2008-10-18 0:31 ` Peter Cordes
2008-10-18 5:18 ` Willy Tarreau
2008-10-18 20:45 ` Hugh Dickins
2008-10-18 20:49 ` Christoph Hellwig
2008-10-18 20:56 ` Willy Tarreau
2008-11-14 2:37 ` [PATCH 2.6.28?] don't unlink an active swapfile Hugh Dickins
2008-11-14 4:08 ` Peter Cordes [this message]
2008-11-14 17:34 ` Christoph Hellwig
2008-11-14 18:02 ` Hugh Dickins
2008-10-17 8:20 ` no way to swapoff a deleted swap file? Bodo Eggert
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=20081114040816.GS31127@cordes.ca \
--to=peter@cordes.ca \
--cc=7eggert@gmx.de \
--cc=akpm@linux-foundation.org \
--cc=davidn@davidnewall.com \
--cc=hch@infradead.org \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterz@infradead.org \
--cc=w@1wt.eu \
/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