linux-kernel - Re: [fuse-devel] [PATCH 01/25] VFS: move attr_kill logic from notify

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: <E1IINct-0007Se-00@dorka.pomaz.szeredi.hu>
Date:	Tue, 07 Aug 2007 13:53:27 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	jlayton@...hat.com
CC:	miklos@...redi.hu, trond.myklebust@....uio.no,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	mikulas@...ax.karlin.mff.cuni.cz, zippel@...ux-m68k.org,
	joel.becker@...cle.com, wli@...omorphy.com, dhowells@...hat.com,
	bfennema@...con.csc.calpoly.edu
Subject: Re: [fuse-devel] [PATCH 01/25] VFS: move attr_kill logic from
 notify_change into helper function

> On the other hand, the filesystem writers here are declaring their own
> setattr operation. Is it unreasonable for them to take responsibility
> for handling this too? 

We have about half of all the in-tree filesystems declaring
->setattr(), and out of those only two that we know would use this.
Others haven't commented, which proably means, they just don't care
about this issue.

And even if most of them would make use of this feature, a inode flag
or filesystem flag for a smooth and backward compatible migration is
just so much better than risking to break filesystems.

And yes, I'm thinking about in-tree filesystems as well.  I'm sure you
did a thorough audit of all filesystems, but we are all human and can
make mistakes.  It is _always_ safer to not change an API which could
cause silent breakage.  And IMO, that's far more important than the
beauty of an interface (and ->setattr() is not beautiful with or
without an inode flag).

> Another alternative might be to rename notify_change(). I don't really
> like gratuitously breaking the API, though, and that function is
> referenced in a lot of documentation. Changing it might be confusing...

Oh no.  I'd like less breakage not more.

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/