From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com ([66.111.4.28]:56471 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965120AbcHaREY (ORCPT ); Wed, 31 Aug 2016 13:04:24 -0400 From: Nikolaus Rath To: Ashish Sangwan Cc: Miklos Szeredi , fuse-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] Fuse: Add mount option to cache presence of security related xattr References: <1472625363-4850-1-git-send-email-ashishsangwan2@gmail.com> Date: Wed, 31 Aug 2016 10:04:16 -0700 In-Reply-To: <1472625363-4850-1-git-send-email-ashishsangwan2@gmail.com> (Ashish Sangwan's message of "Wed, 31 Aug 2016 12:06:03 +0530") Message-ID: <87twe0ooof.fsf@thinkpad.rath.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Aug 31 2016, Ashish Sangwan 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 netwo= rk > 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 --=20 GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F =C2=BBTime flies like an arrow, fruit flies like a Banana.=C2= =AB