[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150203060542.GZ29656@ZenIV.linux.org.uk>
Date: Tue, 3 Feb 2015 06:05:42 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Alexander Holler <holler@...oftware.de>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)
On Mon, Feb 02, 2015 at 06:05:09PM +0100, Alexander Holler wrote:
> + if (inode) {
> + // TODO:
> + // if (inode is file and 's' flag is set)
> + // secure = true;
> + if (!secure)
> + iput(inode); /* truncate the inode here */
> + else {
> + struct super_block *sb = inode->i_sb;
> + if (sb->s_op->set_secure_delete)
> + sb->s_op->set_secure_delete(sb, true);
> + // TODO: We should fail if secure isn't supported,
> + // look up how that's possible here.
> + iput(inode); /* truncate the inode here */
> + // TODO: check if sb is still valid after the inode is gone
> + sync_filesystem(sb);
> + if (sb->s_op->set_secure_delete)
> + sb->s_op->set_secure_delete(sb, false);
> + }
Charming. Now, what exactly happens if two such syscalls overlap in time?
Moroever, what makes you equate unlink() with inode removal? What happens
if you race e.g. with stat(2) on the same thing? Or if there's an opened
file over that sucker, for that matter?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists