On Mon, 2006-02-20 at 21:51 -0800, Andrew Morton wrote:
> Oleg Drokin <[email protected]> wrote:
> >
> > Hello!
> >
> > We are working on a lustre client that would not require any patches
> > to linux kernel. And there are few things that would be nice to have
> > that I'd like your input on.
> >
> > One of those is FMODE_EXEC - to correctly detect cross-node situations with
> > executing a file that is opened for write or the other way around, we need
> > something like this extra file mode to be present (and used as a file open
> > mode when opening files for exection, e.g. in fs/exec.c)
> > Do you think there is a chance this can be included into vanilla kernel,
> > or is there a better solution I oversee?
> > I am just thinking about something as simple as this
> > (with some suitable FMODE_EXEC define, of course):
> >
> > --- linux/fs/exec.c.orig 2006-02-21 00:11:47.000000000 +0200
> > +++ linux/fs/exec.c 2006-02-21 00:12:24.000000000 +0200
> > @@ -127,7 +127,7 @@ asmlinkage long sys_uselib(const char __
> > struct nameidata nd;
> > int error;
> >
> > - error = __user_path_lookup_open(library, LOOKUP_FOLLOW, &nd, FMODE_READ);
> > + error = __user_path_lookup_open(library, LOOKUP_FOLLOW, &nd, FMODE_READ|FMODE_EXEC);
> > if (error)
> > goto out;
> >
> > @@ -477,7 +477,7 @@ struct file *open_exec(const char *name)
> > int err;
> > struct file *file;
> >
> > - err = path_lookup_open(name, LOOKUP_FOLLOW, &nd, FMODE_READ);
> > + err = path_lookup_open(name, LOOKUP_FOLLOW, &nd, FMODE_READ|FMODE_EXEC);
> > file = ERR_PTR(err);
> >
> > if (!err) {
> >
>
> Such a patch would have zero runtime cost. I'd have no problem carrying
> that if it makes things easier for lustre, personally.
>
> We would need to understand whether this is needed by other distributed
> filesystems and if so, whether the proposed implementation is suitable and
> sufficient.
Hmm.... We might possibly want to use that for NFSv4 at some point in
order to deny write access to the file to other clients while it is in
use.
Cheers
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
