On Aug 31 2016, Ashish Sangwan <ashishsangwan2@xxxxxxxxx> wrote:
> In case of a write call on any file, there is a xattr lookup call for
> security.capablities type of xattr which is a scaling bottleneck.
> In some of our use cases, just enabling the xattr support, we are
> experiencing a performance drop of almost 20% even though the file does
> not have any security xattr.
> Fuse, by default, does not remember the presence of security attributes as
> it clears the MS_NOSEC flag at the time of fill super and hence requires a
> lookup of security xattr at each write. This makes sense in case of network
> filesystems where multiple clients can change the state of xattr.
> This patch adds a new mount option cache_security_xattr_presence
> to avoid clearing MS_NOSEC flag. This could be use by the filesystem
> implementations which supports xattr but are local in nature OR the
> implementations which has its own security policies and
> do not support security.capablities xattr.
If I remember correctly, FUSE does not support LSMs at all, so even if
there is a security.capabilities xattr it won't have the expected
effect. So maybe it makes more sense to unconditionally catch both read
and write of security.capabilites in kernel and never forward it to
userspace?
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
