Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp580489rwb; Fri, 18 Nov 2022 05:42:30 -0800 (PST) X-Google-Smtp-Source: AA0mqf45VC9dnOzfXQBC1tHtThtMhXpPba/I7hOuWEQedUL/JkyLWoKnZ54psiQPs/QyQHcdqOya X-Received: by 2002:a17:90a:2e16:b0:20a:bb1f:44a with SMTP id q22-20020a17090a2e1600b0020abb1f044amr14182616pjd.160.1668778950520; Fri, 18 Nov 2022 05:42:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668778950; cv=none; d=google.com; s=arc-20160816; b=bhS3cjPdK7prcdIGIGW7/EzORyvuVeoX3PlU/AsUIJ5OXdHmX6AHF/SwKDXVuUwSf0 t5lWw034mk5BX26RWlYIxePoazQeAqrLjwtkLE/nGqEAVbhlrIL9hi9noBf65RYsbYJT tIk2P+l0tdZ/WPVNcFR4il+b1YjKtmfnAevoc1Ruo+HCAy5hrhRSVFCCbN1EzPQkVvOe Zxt7JkFtppbdnS6DC1cxpDgtwYBo6w7izAoVNdHeawmJ3Rtqoe4+8n9ytNdei0f5hquL GFI7fWWswBO7MmJrJDSvnb0BKHQwD66wxUrBdIjLoSZ50xMP8lpUvraYE4Xcyx4g0cZg dkOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=DwgnOjsBwuRm3KvaCsNzS6B7/KxJyL7ZVpx0OHwNOwA=; b=oeSMbPpBk98gQlJyA8GtFXXAY/YcK1giHgIum2KoUQm34l85OrGYfgedW6HsS6Go0v lI552zk6wW4Fun0K4RpHK3MRj9rX+KnPQPmbfPo7HqdA+dtsMM6p7F8VzHroTTMluPNQ avjQcoaUg+GWG+su03dMj40AEsTM3/swf+EO0dEibveigPVcv2AFVGY++slFadhdwSfY m8Xm7fMgliwA3CHDJYrGytPs42uJv5Vqzho4tCi4W4mGcFrUO2TXHHWszce7KQQaXyKU z+h1nClbk8EfTvnWH33ZbOAh6WtM6aj2PFPh92usKSfyEsfCmabvc2XmD2YVIoSUnZ+Z NQmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=R4lvEJUw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b4-20020a656684000000b004700f0c1aa0si4002951pgw.139.2022.11.18.05.42.18; Fri, 18 Nov 2022 05:42:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=R4lvEJUw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241312AbiKRNPO (ORCPT + 92 others); Fri, 18 Nov 2022 08:15:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241473AbiKRNPM (ORCPT ); Fri, 18 Nov 2022 08:15:12 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5D2E05801D for ; Fri, 18 Nov 2022 05:14:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1668777248; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DwgnOjsBwuRm3KvaCsNzS6B7/KxJyL7ZVpx0OHwNOwA=; b=R4lvEJUwYZibNnazRzwH66GuBgnzt97h+bYWQtRMJ2i3zS232kwfZRp1U7Hf6Wtlchdqya E132DDLTNl2zW3WE7b+1GMDlZ99NnwuBAySagLU3ZwBcy8D92+rg0fFxpmYYJOzX6v3dcK 2Rv+CzmuHMxJxyAvghYXVXF+EYJZRpE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-154-gGjGeDE0NEeha0WFuDPt1Q-1; Fri, 18 Nov 2022 08:14:02 -0500 X-MC-Unique: gGjGeDE0NEeha0WFuDPt1Q-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AD4F1811E75; Fri, 18 Nov 2022 13:14:01 +0000 (UTC) Received: from localhost (unknown [10.39.208.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 65BF640C83EC; Fri, 18 Nov 2022 13:14:01 +0000 (UTC) Date: Fri, 18 Nov 2022 14:13:58 +0100 From: Niels de Vos To: Christoph Hellwig Cc: Theodore Ts'o , linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Xiubo Li , Marcel Lauhoff Subject: Re: [RFC 0/4] fs: provide per-filesystem options to disable fscrypt Message-ID: References: <20221110141225.2308856-1-ndevos@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 13, 2022 at 10:02:37PM -0800, Christoph Hellwig wrote: > On Thu, Nov 10, 2022 at 05:47:10PM +0100, Niels de Vos wrote: > > And, there actually are options like CONFIG_EXT4_FS_POSIX_ACL and > > CONFIG_EXT4_FS_SECURITY. Because these exist already, I did not expect > > too much concerns with proposing a CONFIG_EXT4_FS_ENCRYPTION... > > ext4 is a little weird there as most file systems don't do that. > So I think these should go away for ext4 as well. Yeah, I understand that there is a preference for reducing the number of Kconfig options for filesystems. That indeed would make it a little easier for users, so I am supportive of that as well. > > Note that even with the additional options, enabling only > > CONFIG_FS_ENCRYPTION causes all the filesystems that support fscrypt to > > have it enabled. For users there is no change, except that they now have > > an option to disable fscrypt support per filesystem. > > But why would you do that anyay? An other mail in this thread contains a description about that. It is more about being able to provide a kernel build that is fully tested, and enabling more options (or being unable to disable features) increases the testing efforts that are needed. However, as Ted pointed out, there are other features that can not be disabled or limited per filesystem, so there will always be a gap in what can practically be tested. Thanks, Niels