> Really?
>
> static int __emul_lookup_dentry(const char *name, struct nameidata *nd)
> {
> .
> if (path_walk(name, nd) == 0) {
> if (nd->dentry->d_inode) {
> dput(old_dentry);
> mntpu
ty den 09.08.2005 Klokka 22:42 (+0200) skreiv Miklos Szeredi:
> Trond, wake up! __emul_lookup_dentry() does nothing of the sort.
> Neither does anything else. In theory it could, but that's not a
> reason to do a confusing thing like that.
Really?
static int __emul_lookup_dentry(const char *na
> > > There is quite a bit of code out there that assumes it is free to stuff
> > > things into nd->mnt and nd->dentry. Some of it is Al Viro's code, some
> > > of it is from other people.
> > > For instance, the ESTALE handling will just save nd->mnt/nd->dentry
> > > before calling __link_path_wal
ty den 09.08.2005 Klokka 19:44 (+0200) skreiv Miklos Szeredi:
> > There is quite a bit of code out there that assumes it is free to stuff
> > things into nd->mnt and nd->dentry. Some of it is Al Viro's code, some
> > of it is from other people.
> > For instance, the ESTALE handling will just save
> > > > > + nd->intent.open.file = NULL;
> > > >
> > > > Why is this NULL assignment needed? nd will not be used after this.
> > > >
> > > > > + }
> > > > > + path_release(nd);
> > > > > +}
> > > > > +
> > > > >
> > >
> > > It could be dropped. The reason for putting it in
ty den 09.08.2005 Klokka 18:40 (+0200) skreiv Miklos Szeredi:
> > Intents are meant as optimisations, not replacements for existing
> > operations. I'm therefore not really comfortable about having them
> > return errors at all.
>
> In my case they are not an optimization, rather the only way to
>
> Intents are meant as optimisations, not replacements for existing
> operations. I'm therefore not really comfortable about having them
> return errors at all.
In my case they are not an optimization, rather the only way to
correctly perform an open with O_CREAT.
> > > + nd->intent.open.
>Have you looked at how we're dealing with this in NFSv4?
No.
--
Bryan Henderson IBM Almaden Research Center
San Jose CA Filesystems
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
ty den 09.08.2005 Klokka 08:47 (-0700) skreiv Bryan Henderson:
> >Intents are meant as optimisations, not replacements for existing
> >operations. I'm therefore not really comfortable about having them
> >return errors at all.
>
> That's true of normal intents, but not what are called intents here
>Intents are meant as optimisations, not replacements for existing
>operations. I'm therefore not really comfortable about having them
>return errors at all.
That's true of normal intents, but not what are called intents here. A
normal intent merely expresses an intent, and it can be totally ign
ty den 09.08.2005 Klokka 09:46 (+0200) skreiv Miklos Szeredi:
> > We've already got a patch that does this, and that I'm queueing up for
> > inclusion.
>
> Cool!
>
> > http://client.linux-nfs.org/Linux-2.6.x/2.6.12/linux-2.6.12-63-open_file_intents.dif
>
> Comments:
>
> > /*
> > + * Open inten
> We've already got a patch that does this, and that I'm queueing up for
> inclusion.
Cool!
> http://client.linux-nfs.org/Linux-2.6.x/2.6.12/linux-2.6.12-63-open_file_intents.dif
Comments:
> /*
> + * Open intents have to release any file pointer that was allocated
> + * but not used by the VFS
ty den 09.08.2005 Klokka 00:27 (+0200) skreiv Miklos Szeredi:
> I'd like to make my filesystem be able to do file creation and opening
> atomically. This is needed for filesystems which cannot separate
> checking open permission from the actual open operation.
>
> Usually any filesystem served fr
I'd like to make my filesystem be able to do file creation and opening
atomically. This is needed for filesystems which cannot separate
checking open permission from the actual open operation.
Usually any filesystem served from userspace by an unprivileged (no
CAP_DAC_OVERRIDE) process will be su
14 matches
Mail list logo
