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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D91B2D6392B for ; Wed, 20 Nov 2024 11:10:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 562966B007B; Wed, 20 Nov 2024 06:10:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 513A56B0083; Wed, 20 Nov 2024 06:10:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DA6C6B0085; Wed, 20 Nov 2024 06:10:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 1C1E86B007B for ; Wed, 20 Nov 2024 06:10:06 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B0B37401E1 for ; Wed, 20 Nov 2024 11:10:05 +0000 (UTC) X-FDA: 82806202752.15.BDFF1A8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id 09A7F140019 for ; Wed, 20 Nov 2024 11:09:24 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=t5QnYvOs; spf=pass (imf26.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732100821; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mqjRH0ywr5Bz9UJlM9N/egOVKVC0BRampyKxJb3oFXI=; b=1R1QGfou02Uart/y3oLecSTsxizMjVdsXzijBfN/9GIDdvROohZWkWYygjXS5UOe2hdyJd POkgMAc3pHEYHhya7jlBIWIu/0NOck0fbSWgWgo2EncKV8IZcqWycuAUh4mXk9qpu+RYMH 2TbuJ/wmRZkTfbuvlNzXx/khU2aTfZw= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=t5QnYvOs; spf=pass (imf26.hostedemail.com: domain of brauner@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732100821; a=rsa-sha256; cv=none; b=YSfYb2/qG968AqFA09KcAKmDZ6zdmmmgiNc1AM+2zCHFHIOcSpDAA3Js9E6td/2krr8tep 7ndHPgE5ER/Kx+7PAMR4wxx64dgHkA9QCzfrC2MQkFcwbu1Euzq0SUwaUdY0rTXHelAKqt t7KUl6tU9x0vW4aUfYcdGCnMgrVXjVI= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 305CE5C5621; Wed, 20 Nov 2024 11:09:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51E8FC4CECD; Wed, 20 Nov 2024 11:10:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1732101002; bh=FATPL58fF9smkslXlfFSmLHtTXJdJAoN6rcIHdBGZWk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t5QnYvOs4Ytu34Xv3MRDUqQniGnlfAI+gZPSpGKB4l86otbSHY8R5+B0lVxpLS86+ nnlDtPUPEEaYS48QwnOsF9G6pjMFyZ3FQh3Mn2wna/CFRq0HahKRUnzT2jjz4MLtJh t5qtr30A4IgOasp/SrCufN1BiyXHCRAs3uJ/YtE7SBHWynFnzfmUQn++NQ4NpY7ux3 qYvxbltLxUKnsibFHSoBsccyaH/lEDUQrpJu0O0kJUdDw934Ih5YkvS4UojJq9FJq9 IWoIS4pvobC+q3QSXwYfe07r8HOkZc2FBXGaZoGnSYvR7tRoxpABwcy71kmZATDoBB +fLKe6QuqkoIg== Date: Wed, 20 Nov 2024 12:09:57 +0100 From: Christian Brauner To: Linus Torvalds Cc: Amir Goldstein , Josef Bacik , kernel-team@fb.com, linux-fsdevel@vger.kernel.org, jack@suse.cz, linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-ext4@vger.kernel.org Subject: Re: [PATCH v7 05/18] fsnotify: introduce pre-content permission events Message-ID: <20241120-banditen-nimmersatt-e53c268d893a@brauner> References: <141e2cc2dfac8b2f49c1c8d219dd7c20925b2cef.1731433903.git.josef@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 09A7F140019 X-Stat-Signature: nxzj8y4tt9hspkx9rmx7skk4jsye4y65 X-Rspam-User: X-HE-Tag: 1732100964-388188 X-HE-Meta: U2FsdGVkX1/csuQ5R8RW5OdnHLSyiMkVF52VG1GHQEfqYffS83PkXp0lt+lmf4rGJdpkaJq2E7UlcYMy9xsEzzeqSlG3w+LmoogdkZOO9UMsmbtKFP+bhZKze80BqT0SyJLzBQ3a/Kb19FlT55nHw281E/7XxbSVACFTkEVmne/yq/AXIv1OCm/QYqM62jkqAWd8kvi+fpWPGdOiGAduO8f9lLYQEjkJwGyYYrzH0OFxSLH+B5YQLJnPjtlIp0TwXzv0vzE1NXTvF420z68a0TrocKQ7j3ziXVEKJ8G0avoaVUDEWL+TNqlVBAPj3ovnbvmCSGLx5NnXvi4VOs3k9HX804bG2VCMbTtH6ak29J+ezipPxmJjkfsU+JvfaMDcxpyLyDXkyepS0nAzQWKCtqTUjkGbzks2HIvfRlx2veoS8RTcSi3V0/RPcRNxvXDABkHN9/P+bDjRpJc4CrfJ9iDh0FVg7r6OCCiL93b/otq7bzqOziNms5tDwORRyG/RFgAkVuhhu2m7RU+Uv/7htU8N7lFRQ4oWx/18Z5Tgs0uNkYoRqjUVe0lqMnEGod7Yn7x/Mq8GjAbIp/5kCrRG2FDnf4cJAYrV5OiEhTjdntIU8cXn28WM9u2oqPHGJ+L+u/Eu5GrnVP24VJvBcuyCa5DiQTkkpjqQybGBzJ4h9JfC86antEqb7ao1HP8T/UcEy8z8M+BGIDjeDHYcoogfAI+aG+OC9E9VBp+imkzXQpeHlDT30FLCqP5gFtJO0haDEGammRo1YHhgVkwfuk6CCD0Ssx9qmcrpvhOi7NLq5uMKCrZ76FXMFy3Cvedtehc99Jf4WA1u7+C97J88NDZHiKOtJGkIklCYgoFc2kGDyLxm3aOwulCevSKMr/ns2exLrPBUURud61n6WX9B9FxFTPeiaGYK8SSEUj5H5JOGOY+0uznf0hBmQzVIlA48NaE+s6Ad9xgzFb8Cr9hm/I1 fcJf6JPv 7iSnlqTLAp6ui69HS5n41e/i6UyvXZFqEfH7/TLUxy+aqRe7C4rjUmoH+3l5I8e29pk2pgYAYkErffoZy7gpZvC1i5ZpTv2XP4OcB3rjw3xvvaIqVEMAlVxMTMImkqmY1dMSITd64JsJ+C4LAGKwAZ4RXW/N2L33K0182uNx0vKmhG8TtdFUGyUmN85yD+ZKgbExsiCzvCaeqOP11mNRHX6pA4cMzljIx9JRI66NfiiSxygHM1m+gZjz/mS/QZ4NpNFHEQx2wB/HNw7RrUNsid3DiasphG01IJThYZldHlSboM60= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > But if anybody is really worried about running out of f_mode bits, we > could almost certainly turn the existing > > unsigned int f_flags; > > into a bitfield, and make it be something like > > unsigned int f_flags:26, f_special:6; I just saw this now. Two points I would like to keep you to keep mind. I've already mentiond that I've freed up 5 fmode bits so it's not that we're in immediate danger of running out. Especially since I added f_ops_flags which contains all flags that are static, i.e., never change and can simply live in the file operations struct and aren't that performance sensitive. I shrunk struct file to three cachelines. And in fact, we have 8 bytes to use left since I removed f_version. So it really wouldn't be a problem to simply add a separate u32 f_special member into struct file without growing it and still leaving a 4 byte hole if it ever comes to that.