[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1II7JR-0005BN-00@dorka.pomaz.szeredi.hu>
Date: Mon, 06 Aug 2007 20:28:17 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: jlayton@...hat.com
CC: miklos@...redi.hu, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, codalist@...emann.coda.cs.cmu.edu,
cluster-devel@...hat.com, jfs-discussion@...ts.sourceforge.net,
mikulas@...ax.karlin.mff.cuni.cz, zippel@...ux-m68k.org,
xfs@....sgi.com, joel.becker@...cle.com, wli@...omorphy.com,
reiserfs-devel@...r.kernel.org, dhowells@...hat.com,
fuse-devel@...ts.sourceforge.net, jffs-dev@...s.com,
user-mode-linux-user@...ts.sourceforge.net,
v9fs-developer@...ts.sourceforge.net, linux-ext4@...r.kernel.org,
linux-cifs-client@...ts.samba.org, ocfs2-devel@....oracle.com,
bfennema@...con.csc.calpoly.edu
Subject: Re: [fuse-devel] [PATCH 01/25] VFS: move attr_kill logic from
notify_change into helper function
> > I agree with this change and fuse will make use of it as well.
> >
> > Maybe instead of unconditionally moving attr_kill_to_mode() inside
> > ->setattr() it could be made conditional based on an inode flag
> > similarly to S_NOCMTIME. Advantages:
> >
> > - no need to modify a lot of in-tree filesystems
> > - no silent breakage of out-of-tree fs
> >
> > Actually I think the new flag would be used by exacly the same
> > filesystems as S_NOCMTIME, so maybe it would make sense to rename
> > S_NOCMTIME to something more generic (S_NOATTRUPDATE or whatever) and
> > use that.
> >
> > But that could still break out-of-tree fs, so a separate flag is
> > probably better.
> >
>
> In the past I've been told that adding new flags is something of a
> "last resort". Since it's not strictly necessary to fix this then
> it may be best to avoid that.
>
> That said, if the concensus is that we need a transition mechanism,
> then I'd be open to such a suggestion.
I think there's really no other choice here.
Your patch is changing the API in a very unsafe way, since there will
be no error or warning on an unconverted fs. And that could lead to
security holes.
If we would rename the setattr method to setattr_new as well as
changing it's behavior, that would be fine. But I guess we do not
want to do that.
Miklos
-
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/
Powered by blists - more mailing lists