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 3F9A8D637D1 for ; Wed, 13 Nov 2024 23:08:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B46426B0093; Wed, 13 Nov 2024 18:08:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AF60B6B0095; Wed, 13 Nov 2024 18:08:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9BD786B0098; Wed, 13 Nov 2024 18:08:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7F0946B0093 for ; Wed, 13 Nov 2024 18:08:01 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E09AD120AA7 for ; Wed, 13 Nov 2024 23:08:00 +0000 (UTC) X-FDA: 82782611100.28.BAD1AFD Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf10.hostedemail.com (Postfix) with ESMTP id 90E9BC0014 for ; Wed, 13 Nov 2024 23:07:39 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=G4GznODa; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.45 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731539104; 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=3uMAHPF1ytklJO173iJZDrJhJUNgUA50IG0+xtq7Xjg=; b=XaNPcNkIKfyLq/HxskMZfo5gZM/0OuDjt3sHyA+EN/+nWUy8l/MTdO6GZ1yYs5PuYwYqvL nopob8AQ5BDtKtOJC9ny3IVPcUAojlHu5eVzThWoSjo36toIJPGm+krBqtZUCZaGuFzzib zF+mlO7YyPXOHSCFhCkQuLba2CFYyvs= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=G4GznODa; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.45 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731539104; a=rsa-sha256; cv=none; b=3SpjdMB3B+5rPTa1gviZh7uJGgvmlqaXTJXqfmOOzve/BJ1XF1rzLZ/DaoXnw6FzY117QC wLCukB0ctSEyII1xjpmq32ls9O8wKi30nmNCkLaxT2OLEsvmkxS7wn9/ziGjk6iIXhyoqd egC+QXCRR2BudK9zdvmXDY0aRTMp1FY= Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-5ced377447bso10416957a12.1 for ; Wed, 13 Nov 2024 15:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1731539277; x=1732144077; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3uMAHPF1ytklJO173iJZDrJhJUNgUA50IG0+xtq7Xjg=; b=G4GznODaWChJ1AJMGVJe73kkpTrUpPnoTuDTDVWnxm+z1uNdAKsJaLK8aCmiDzQcoa rvATsu9f80vLrVYfsjcBQV8rTNGUFTttPnruAloMHVzJRX7OO11hJPC9p1c4CoM5Hx5q Db7nuVul7/cMpBWPC/Mu61P+3Y2Ug0BWnlsdM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731539277; x=1732144077; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3uMAHPF1ytklJO173iJZDrJhJUNgUA50IG0+xtq7Xjg=; b=SbBwDC3eZVnRWyNdBiVHHJrZjUaWCRKEtCd0Ojqhcgb0rgFUA/2zsxYDkibzE3rZJq +26wsiDnIbsYb5dVIMs9jY91xUDfHx4mOtDirc7XwUd/bZzd8m3zSfTnG1cw0qT/TpVm A4BZHcCvHpX3eLIQjzh2y7RhD0fLRqhJXEXM+C2wFsjYXT/nM7tZ4Y6M4gMwj+hadXtn xMn1MsuwU8NYnn8KyR/J49KB7p1rwcMKygMf6OI+amelfKLMtcMw2kbyNbIsU6H1P1pB V+X4OiAlKCiR//nSJhiCmSHjHUONUUyg/KNqFknQUTwUesogbJ4SzE3pXuCEuyzMgrYU fjCw== X-Forwarded-Encrypted: i=1; AJvYcCXHG/zTBl2whHOl/kgM7pnAhOre4U1ShY8SFcEpMotWi4VyjWcU9Oq7Jt/ClN3ZDrKKK4JCrxU9fg==@kvack.org X-Gm-Message-State: AOJu0Yzw4D42ovfcYD7/DIVaQkKeUAfP4gCDHKaFFG6WANcdYjx7yWOm 0KQTrYRLNQe9TqqHQxF6sVLOw3TcrYXj/HJq8kIAYKcDaz/tTLMrFGNOf0lKpbD7fPfcz/GsyiA W9+4= X-Google-Smtp-Source: AGHT+IGIe47+Ap8EVASnA+Vi1e83yAmv6mydZZUa+r+FDXs2dqz1XHYsObnbCN2UV2q75CerNs54DA== X-Received: by 2002:a05:6402:2351:b0:5cf:4687:b816 with SMTP id 4fb4d7f45d1cf-5cf4f3c08bdmr6681630a12.31.1731539277134; Wed, 13 Nov 2024 15:07:57 -0800 (PST) Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com. [209.85.218.48]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5cf08ca5bdesm6966905a12.11.2024.11.13.15.07.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Nov 2024 15:07:55 -0800 (PST) Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a99f646ff1bso11013466b.2 for ; Wed, 13 Nov 2024 15:07:55 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWZbNSXCxZGzpWq6O/RcWip3QFyYdScDnIirMH/Cw74vu2jr9W+OHO17pymOsnlaGfkq1Fb/re7NA==@kvack.org X-Received: by 2002:a17:907:5ce:b0:a99:5234:c56c with SMTP id a640c23a62f3a-aa1b10a372fmr767667166b.33.1731539274832; Wed, 13 Nov 2024 15:07:54 -0800 (PST) MIME-Version: 1.0 References: <141e2cc2dfac8b2f49c1c8d219dd7c20925b2cef.1731433903.git.josef@toxicpanda.com> In-Reply-To: From: Linus Torvalds Date: Wed, 13 Nov 2024 15:07:38 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 05/18] fsnotify: introduce pre-content permission events To: Amir Goldstein Cc: Josef Bacik , kernel-team@fb.com, linux-fsdevel@vger.kernel.org, jack@suse.cz, brauner@kernel.org, linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-ext4@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 90E9BC0014 X-Stat-Signature: 11bttatnqqee9kcb9cpxne19jcmpugyx X-Rspam-User: X-HE-Tag: 1731539259-422055 X-HE-Meta: U2FsdGVkX19JNEZHiMKUlAXlVlq1vUFYmdUqMc2G77qOrV39jqEQlr1xqASxaqyOfilSW2WIHEKqNLVhSz0KoJUacqmuo7/MqPOjWAlOxRoyOzM+HCF3D3YUua8Dmp4NDK3X1FivYZilYBTzATxl4clKTI70kIX9Hu94ReHo0khXlF4QfxUgfRV4EZxoi53z57u6RRZU7deIXAo0qRbJ7ixnS8JViQlZxmNHckFcV+S/0VEU7l8+u92N4jILXgzmMbdXzxSrKScfiKgYqakti7VPoo8osnPh4wkteiRO0GwTzbtVdwv8Uy0bT0eJtXi+BDSwFs7ojdvN7YxB6aouow1YBmrbh/mwTqZGr0oVNnbJpjFTaUiWZqZLBoL9focSJMJ/KAPe0JTxD4oJtuSuhQ42gRhj6PY337KpFf/etv0EaZG9BQcMjTow6gAcZvveTlWJBYJYJ4v/LAtaPnMUuzcaUhS7EyXHJ2j5lO57eJ7foZ/Wm1xYbjVs28ISxWO6Q7Xveo+KPzHT+Qtk4+EFVEAeqehjN1VBewraRIbNCmO2Hru50fvbdnLpUiNKZJj9JuHp86elxJG+4aMxqP5d+cx0q8XSr5KPJHwXMAISbyjixpt5KQiuvbM5ggClCR3XUHwuVWqj5gK4w+8H+2bSYvsG7MQ9HBOhbnDF/b2Tt9aeW4F2ffsWj78FWi5cOGoXGHbyLmezwppOMY5MIVYSAjj9etVIbi5pf9tobdIWVz5Td7nYFdHYqMGj2Lb7tmZqGX05EaiQwUrBgMX0uswXQWbAkvBPuZcLG3vshjGzxNHSND1zsz6ypQ5Br9UDNVfedle7IBJbtPjnAEJj703Q9LPvPGciX0x+SbwVzL69/lfDNE2osHlwpYjBxv2qYWq1wiImms9foIj3uxQHfpw4uq/GBNL5hULn8e3FS+4sH9J09gjOTrcm4kS9u0n30bZCDo7wo1kAC2BHpaxAcH6 o5SpWovs 220odAROb9Uju5cRwBhyjtzpoPbac2qOJUkVYW8wrgtyMPkP69jIXrZKlx22itLrFLoh1mD4FULLJfsO5Ki6wdgchMrevLXTkfYbzvALdEmbYgE/TiNrmKL9zq+ZGfgoEApSv52sMVGpc6i65r1pCW4T7Z0WJFt5HtEKHVnZ3BX97VYla8/RUp4eHgm3hFr4/IOQZbTZtcxJC88nfDcMzFT9iul4pXNGv1g0Er0dsMLyOVq9BIqBWxYy5TITmZvaN+0DcUWntuCMxmc4p+ZncN3V6NzSnCILSRK1wZBF7xe4B/s6wsXMMnBN5otq5ZF5XdWynMn/pr60sq/mF67s+us/qyDsTRtJmczLfPi24LXkQqPAd9MIaiegRin+myuyXsh8mANHYzyYy1mTiwyzqTiQSmFAtJGJeBcFKB1ifXwDMdDU085dsGSY9hM+eWfIxyC5QSJ6X6/P6R4O3sl8mz0PivGR7G8HNI9uD5sSgEn4HWBGcGOW4mP4MMQ== 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: On Wed, 13 Nov 2024 at 14:35, Amir Goldstein wrote: > > Sure for new hooks with new check-on-open semantics that is > going to be easy to do. The historic reason for the heavy inlining > is trying to optimize out indirect calls when we do not have the > luxury of using the check-on-open semantics. Right. I'm not asking you to fix the old cases - it would be lovely to do, but I think that's a different story. The compiler *does* figure out the oddities, so usually generated code doesn't look horrible, but it's really hard for a human to understand. And honestly, code that "the compiler can figure out, but ordinary humans can't" isn't great code. And hey, we have tons of "isn't great code". Stuff happens. And the fsnotify code in particular has this really odd history of inotify/dnotify/unification and the VFS layer also having been modified under it and becoming much more complex. I really wish we could just throw some of the legacy cases away. Oh well. But because I'm very sensitive to the VFS layer core code, and partly *because* we have this bad history of horridness here (and particularly in the security hooks), I just want to make really sure that the new cases do *not* use the same completely incomprehensible model with random conditionals that make no sense. So that's why I then react so strongly to some of this. Put another way: I'm not expecting the fsnotify_file() and fsnotify_parent() horror to go away. But I *am* expecting new interfaces to not use them, and not write new code like that again. Linus