Received: by 2002:a05:7412:8d06:b0:f9:332d:97f1 with SMTP id bj6csp45723rdb; Mon, 18 Dec 2023 08:30:55 -0800 (PST) X-Google-Smtp-Source: AGHT+IG5DDOVBExZfulp7/TOyURxtcjDXvT+18MqEXv/Z0Dkb9WaTfyiPiCwSL/BYC/jP7dSrFaN X-Received: by 2002:a9d:6d13:0:b0:6d9:e2fc:c9f4 with SMTP id o19-20020a9d6d13000000b006d9e2fcc9f4mr9542129otp.66.1702917055364; Mon, 18 Dec 2023 08:30:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702917055; cv=none; d=google.com; s=arc-20160816; b=QQb9CGgOSiPqDX/mmaSaW73KT2MMPalorBEe4Q9bzk1WViS5kPLUVsOB5DcecsPoLg M2T7nLeS4dKlza9TiM3a/L4ti9ULWyWlcbSvyvjwUy9HyjFgdUbOe3fjvUqAkPG//IZ5 IWM+CyWHfEakjZxaeTA3smeNyxJ6q3YWGm8A5fJakjBaLjGAvlayoc52n6yerduqgsI0 CdC1KPhRqaACOr75AdDJQ7J+tGPdVYhMK3qSF5L9w3mtMrqtqTCmYmEWaRSndtBhJFMS vQmMON5WVFX/4L818USmtdEYRPK93NmRwYBd8YIeHrdu584SfL53V3L4GoGgeJCP3i1o jL0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=9GYHNEmmlKt0JAUp5FlgfvC6f4p8u7XGE0A/fAOlFw4=; fh=ibVJpobukDw8tJASpQd/Nvhrkpz9AlWNWEzsKIRPJEA=; b=ncsmyEUzkll0/LxU+ekf3wZBG7KChCQ7Gz1mM1+iicjaASOXDb//LU1zsaaxJNFb8I lPRa7VJvkuLAYhUHDwVB8Zs+5r71WVdtEiC92gOFJDhywoIEP7W20zzlq7uNHhcZnpML e4t3Uwn79dwoPpBCt/XPIhXmiHUnXaIbHD6pIYMv9iXgHEENMONMHDBZSZF2Hojw9+x5 rX4BDsuZlUJIPbNR06eJzNST/bCAIBvawDICcgM+UayaudJY/IuNXuQCya/gLxbCNqhj w90QxIMF3/GLj9/GJukRMHEN87210GuLwP1y6pxJsX+rO8IlBrHiQagpaQ12du03gbb8 njQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=eE4tIxcM; spf=pass (google.com: domain of linux-kernel+bounces-4066-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4066-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id fg10-20020a05622a580a00b0042581e4d6f6si25877095qtb.547.2023.12.18.08.30.54 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Dec 2023 08:30:55 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-4066-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=eE4tIxcM; spf=pass (google.com: domain of linux-kernel+bounces-4066-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4066-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id CDA2A1C23A4B for ; Mon, 18 Dec 2023 16:30:54 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 731FA49894; Mon, 18 Dec 2023 16:30:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eE4tIxcM" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A2E9423D7; Mon, 18 Dec 2023 16:30:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8E9CC433C7; Mon, 18 Dec 2023 16:30:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702917043; bh=vzJT46XWAVR+AYyo+bbvE2VcoW5+6hnEFuhEHPUf3Xg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=eE4tIxcMGFAtSKGwxbvZXUWQQVXG25HLFk+23hKD4QEh478DYEcoxuBtITIQ80JBv u748CUw6imyf5u9biVlTwpp7vMSI33GzO07N2Oabx5VE+cPomvTyooCfsNov3lt+3Y 1GJ2B1PC0Zec/q+39Xy+hMNeFeNqkloRnxT50fQH5+GHxBP1M34aQHZBTkGIzSY4rX DapjFUR4dGx+q65ccAmWNXwp1UmCbDOwtRVV4GcoryyuKFyhVHoBGMwvE+ItHxDqgb cfaYsZU/JCfkk4y+FAfdouXbXfYaTmMQXT5L8q4/1iI8RerVtqjq2KRyz0nbpNsSMe 3TGVinTNMlfag== Date: Mon, 18 Dec 2023 17:30:37 +0100 From: Christian Brauner To: Amir Goldstein Cc: Vinicius Costa Gomes , hu1.chen@intel.com, miklos@szeredi.hu, malini.bhandaru@intel.com, tim.c.chen@intel.com, mikko.ylinen@intel.com, lizhen.you@intel.com, linux-unionfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-fsdevel , Linus Torvalds , David Howells , Seth Forshee Subject: Re: [RFC] HACK: overlayfs: Optimize overlay/restore creds Message-ID: <20231218-intim-lehrstellen-dbe053d6c3a8@brauner> References: <20231214220222.348101-1-vinicius.gomes@intel.com> <87v88zp76v.fsf@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: > > Yes, the important thing is that an object cannot change > > its non_refcount property during its lifetime - > > ... which means that put_creds_ref() should assert that > there is only a single refcount - the one handed out by > prepare_creds_ref() before removing non_refcount or > directly freeing the cred object. > > I must say that the semantics of making a non-refcounted copy > to an object whose lifetime is managed by the caller sounds a lot > less confusing to me. So can't we do an override_creds() variant that is effectively just: /* caller guarantees lifetime of @new */ const struct cred *foo_override_cred(const struct cred *new) { const struct cred *old = current->cred; rcu_assign_pointer(current->cred, new); return old; } /* caller guarantees lifetime of @old */ void foo_revert_creds(const struct cred *old) { const struct cred *override = current->cred; rcu_assign_pointer(current->cred, old); } Maybe I really fail to understand this problem or the proposed solution: the single reference that overlayfs keeps in ovl->creator_cred is tied to the lifetime of the overlayfs superblock, no? And anyone who needs a long term cred reference e.g, file->f_cred will take it's own reference anyway. So it should be safe to just keep that reference alive until overlayfs is unmounted, no? I'm sure it's something quite obvious why that doesn't work but I'm just not seeing it currently.