linux-kernel - Re: [PATCH 00/25] vfs: atomic open RFC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87y5r49362.fsf@tucsk.pomaz.szeredi.hu>
Date:	Tue, 13 Mar 2012 12:00:05 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	viro@...IV.linux.org.uk, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, Trond.Myklebust@...app.com,
	sfrench@...ba.org, sage@...dream.net, ericvh@...il.com
Subject: Re: [PATCH 00/25] vfs: atomic open RFC

Christoph Hellwig <hch@...radead.org> writes:

> Do we really need the opendata structure?
>
> It seems like we could just pass a struct path instead of the dentry
> passed directly and the vfsmount in it.  There should be no need to
> preallocate the file before calling into ->atomic_open, as it's only
> used to pass around f_flags - but we already pass that one to
> ->atomic_open directly and might as well pass it on to finish_open and
> allocate the file there.

We really don't want to get into the situation where the open fails
after a successful create(*).  Which means the file needs to be allocated
prior to calling ->atomic_open and needs to be passed to finish_open()
toghether with the vfsmount and dentry.

In the first version of the patch I set filp->f_path.mnt to nd->path.mnt
and passed the half initialized filp to ->atomic_open.  But then decided
that it's confusing for the filesystem code to deal with a half baked
filp (does it need to be fput on error?  etc...)

Doing it with an opaque opendata makes this cleaner I think.

Thanks,
Miklos


(*)
commit a1a5b3d93ca45613ec1d920fdb131b69b6553882
Author: Peter Staubach <staubach@...hat.com>
Date:   Tue Sep 13 01:25:12 2005 -0700

    [PATCH] open returns ENFILE but creates file anyway
    
    When open(O_CREAT) is called and the error, ENFILE, is returned, the file
    may be created anyway.  This is counter intuitive, against the SUS V3
    specification, and may cause applications to misbehave if they are not
    coded correctly to handle this semantic.  The SUS V3 specification
    explicitly states "No files shall be created or modified if the function
    returns -1.".
    
    The error, ENFILE, is used to indicate the system wide open file table is
    full and no more file structs can be allocated.
    
    This is due to an ordering problem.  The entry in the directory is created
    before the file struct is allocated.  If the allocation for the file struct
    fails, then the system call must return an error, but the directory entry
    was already created and can not be safely removed.
    
    The solution to this situation is relatively easy.  The file struct should
    be allocated before the directory entry is created.  If the allocation
    fails, then the error can be returned directly.  If the creation of the
    directory entry fails, then the file struct can be easily freed.
--
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/