From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE8E6FC6194 for ; Thu, 7 Nov 2019 02:49:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 80FE421882 for ; Thu, 7 Nov 2019 02:49:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728134AbfKGCtj (ORCPT ); Wed, 6 Nov 2019 21:49:39 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:56989 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727443AbfKGCtj (ORCPT ); Wed, 6 Nov 2019 21:49:39 -0500 Received: from callcc.thunk.org (ip-12-2-52-196.nyc.us.northamericancoax.com [196.52.2.12]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA72nLni011638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Nov 2019 21:49:22 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 799C4420311; Wed, 6 Nov 2019 21:49:19 -0500 (EST) Date: Wed, 6 Nov 2019 21:49:19 -0500 From: "Theodore Y. Ts'o" To: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, Satya Tangirala , Paul Crowley , Paul Lawrence , Jaegeuk Kim Subject: Re: [PATCH v2 1/3] fscrypt: add support for IV_INO_LBLK_64 policies Message-ID: <20191107024919.GH26959@mit.edu> References: <20191024215438.138489-1-ebiggers@kernel.org> <20191024215438.138489-2-ebiggers@kernel.org> <20191106033544.GG26959@mit.edu> <20191106040519.GA705@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191106040519.GA705@sol.localdomain> User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Nov 05, 2019 at 08:05:19PM -0800, Eric Biggers wrote: > If we really wanted to optimize fscrypt_get_encryption_info(), I think we > probably shouldn't try to microoptimize fscrypt_supported_policy(), but rather > take advantage of the fact that fscrypt_has_permitted_context() already ran. > E.g., we could cache the xattr, or skip both the keyring lookup and > fscrypt_supported_policy() by grabbing them from the parent directory. Yes, good point. Certainly, if the parent is encrypted, given that we force files to have the same policy as the containing directory, there's no point calling fscrypt_supported_policy. And if we're using a policy which isn't using per-inode keys, then we can certainly just grab the key from the parent directory. - Ted From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30418FA372C for ; Thu, 7 Nov 2019 02:49:39 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C297B217D7; Thu, 7 Nov 2019 02:49:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="H7+4UxY3"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="cnzjSlJ3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C297B217D7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1iSXrd-0000VX-Pv; Thu, 07 Nov 2019 02:49:37 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1iSXrb-0000VG-Tc for linux-f2fs-devel@lists.sourceforge.net; Thu, 07 Nov 2019 02:49:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=lvOc3mHpCw0OMRDiJ3FGdQqEeZNVl81FbmsoO/XI/Zs=; b=H7+4UxY38vWwePcSOddrIQK9g3 2a3VjKFAYrzK5x2P+Q7Zx/brIiRUl5Ih9AuQYdHRfAWr/0+dvKt3ZX7RXOCLHhnPnkxgDuU/Gvu97 kqy28SagZ5l5WP3tkuuFburEaiWT7479nwMpNfeS6mBjehVwYh2nRDQmJz3wIs2ac8Uc=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To: From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=lvOc3mHpCw0OMRDiJ3FGdQqEeZNVl81FbmsoO/XI/Zs=; b=cnzjSlJ3DTSLKume9y40K5XsE4 PAOO1ONwLwWEzvDC8nWaB5cbj/Oy7K68G8WkdXhx0ku8aJ6Hcz0TGWbqdrO33p7HD6TygsUSDhiuC XMsHY2CXQvRIR83WVq5Wj140hAVoPyox/kt4X0HZ64C4HBW53LLFroIq7P/YqfrcZ1P0=; Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1iSXrZ-0031n6-Sl for linux-f2fs-devel@lists.sourceforge.net; Thu, 07 Nov 2019 02:49:35 +0000 Received: from callcc.thunk.org (ip-12-2-52-196.nyc.us.northamericancoax.com [196.52.2.12]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA72nLni011638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 6 Nov 2019 21:49:22 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 799C4420311; Wed, 6 Nov 2019 21:49:19 -0500 (EST) Date: Wed, 6 Nov 2019 21:49:19 -0500 From: "Theodore Y. Ts'o" To: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, Satya Tangirala , Paul Crowley , Paul Lawrence , Jaegeuk Kim Message-ID: <20191107024919.GH26959@mit.edu> References: <20191024215438.138489-1-ebiggers@kernel.org> <20191024215438.138489-2-ebiggers@kernel.org> <20191106033544.GG26959@mit.edu> <20191106040519.GA705@sol.localdomain> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20191106040519.GA705@sol.localdomain> User-Agent: Mutt/1.12.2 (2019-09-21) X-Headers-End: 1iSXrZ-0031n6-Sl Subject: Re: [f2fs-dev] [PATCH v2 1/3] fscrypt: add support for IV_INO_LBLK_64 policies X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Tue, Nov 05, 2019 at 08:05:19PM -0800, Eric Biggers wrote: > If we really wanted to optimize fscrypt_get_encryption_info(), I think we > probably shouldn't try to microoptimize fscrypt_supported_policy(), but rather > take advantage of the fact that fscrypt_has_permitted_context() already ran. > E.g., we could cache the xattr, or skip both the keyring lookup and > fscrypt_supported_policy() by grabbing them from the parent directory. Yes, good point. Certainly, if the parent is encrypted, given that we force files to have the same policy as the containing directory, there's no point calling fscrypt_supported_policy. And if we're using a policy which isn't using per-inode keys, then we can certainly just grab the key from the parent directory. - Ted _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel