Messages in this thread | | | Date | Tue, 21 Feb 2006 15:15:53 +0100 | From | "Antonio Vargas" <> | Subject | Re: FMODE_EXEC or alike? |
| |
On 2/21/06, Trond Myklebust <trond.myklebust@fys.uio.no> wrote: > On Mon, 2006-02-20 at 21:51 -0800, Andrew Morton wrote: > > Oleg Drokin <green@linuxhacker.ru> 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.
When done with regards to failing a write if anyone has mapped the file for executing it, or failing the execute if it's open/mmaped for write, I can't really see the difference between local, remote and clustered filesystems...
-- Greetz, Antonio Vargas aka winden of network
http://wind.codepixel.com/ windNOenSPAMntw@gmail.com thesameasabove@amigascne.org
Every day, every year you have to work you have to study you have to scene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |