lkml.org 
[lkml]   [2015]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)
Am 03.02.2015 um 07:05 schrieb Al Viro:
> 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?

Sorry, but I first had to make breakfast after I've got angry about the
usual arrogance of most Linux kernel maintainers.

I've already answered the first question.

Now to the second. That still might be a problem. But that's why this is
a RFC, why there is a WIP (Work In Progress) before the patch, why I've
written I've never looked at those sources before, why I've written they
are imperfect and why I've written I have not spend much time on these
patches. I've posted them to show how I think the problem might be
solved. These patches evolved out of desperation that otherwise users
have to wait another 30 years until they will be offered a way to really
delete files.

If the removal is somehow scheduled then, of course, the secure flag has
to be scheduled too.

Alexander Holler


\
 
 \ /
  Last update: 2015-02-03 09:01    [W:0.102 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site