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 31429D3ABCF for ; Mon, 11 Nov 2024 22:46:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9EE526B00D7; Mon, 11 Nov 2024 17:46:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 99E656B00D8; Mon, 11 Nov 2024 17:46:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 817616B00D9; Mon, 11 Nov 2024 17:46:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5EAFB6B00D7 for ; Mon, 11 Nov 2024 17:46:36 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BE270160194 for ; Mon, 11 Nov 2024 22:46:35 +0000 (UTC) X-FDA: 82775299236.11.A08A771 Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by imf05.hostedemail.com (Postfix) with ESMTP id 66EC1100014 for ; Mon, 11 Nov 2024 22:45:16 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=toxicpanda-com.20230601.gappssmtp.com header.s=20230601 header.b=ghpgo9LB; spf=none (imf05.hostedemail.com: domain of josef@toxicpanda.com has no SPF policy when checking 209.85.215.182) smtp.mailfrom=josef@toxicpanda.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731365002; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+VRvtvNdmLIp8XU4kQFCBc6R99fU2D6h//Mc4Pu+ikI=; b=PqOjZ9iRt5cLESNgAWaC4K5S3CM+5M7uor4bJT2v6Wjb21IuYyP/d58m9Y1Bq3c16jLvdh oaubDC07ONHOyEjmrM677wVd/Zy84iRPP0j5jOji8w+ErecIBJPGizi4cJaKJEJQrTXtLt 7HxD8Z6r1MM6yyvoALHQ779QlvbF/qM= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=toxicpanda-com.20230601.gappssmtp.com header.s=20230601 header.b=ghpgo9LB; spf=none (imf05.hostedemail.com: domain of josef@toxicpanda.com has no SPF policy when checking 209.85.215.182) smtp.mailfrom=josef@toxicpanda.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731365002; a=rsa-sha256; cv=none; b=BuzDK1U9kTFqzStPhbj5G3Z1U2fSZNoNNLzIlefdDSFGk9t35lnOlV67KXGKeJHUg6+Y0J gOb0aYoEyC8d1xKfFWVqHbHZQXGzGIBzI3Fti0ZNRkfYcTpwZZ5MsKzRlptANiFfvNCnHQ Rr20SRjDfDyPi7+TTWGfZ78yr4eJzzc= Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-7f450f7f11dso1264233a12.2 for ; Mon, 11 Nov 2024 14:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20230601.gappssmtp.com; s=20230601; t=1731365192; x=1731969992; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=+VRvtvNdmLIp8XU4kQFCBc6R99fU2D6h//Mc4Pu+ikI=; b=ghpgo9LBg6Hs/C14WiD2x9hlDfC9xSwuB2VxIfTFlJLyDDOycXQxUuOHVIIJk9mZPL slnMXsF0NfEBpCvbKT9q7h2ZavXEslOWB03m8+3eGBfYIwFwnGGwBsKTwpHk1AfontfG e0HfsT0uOZkTfeBVnKMyUevAHXWLwjxTd5mhFkCRkWOxpvHlubUfCHrn1OE/zFHEyzbr t9nxfM2SI7pQmOh3h5G3BnjHcCUnR9VyG1XlgB1pZpN1eprd/tPfyxpCTbfwKvwYUakl uG5JhJZoCOPJHrmc8wqTlnXLU/z1z8AbjJYJyjvnPYoaUGEBaxLXdT9I/YNdKyAWQLMc O+9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731365192; x=1731969992; h=content-transfer-encoding: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=+VRvtvNdmLIp8XU4kQFCBc6R99fU2D6h//Mc4Pu+ikI=; b=lvkUnwdG8F+0mHJVM2C+GiKwWElTRick0IFTbthRQ6EbDWocxIyu/mzf0HrqqYmS8J JJ7IqrjXb0LvmR+SQs5598oQs8I7S7OO2W5545cl0B/aHF93h2bXbJixKVYHcNsZNDnE 8prqem+VD6Si+64jHsTZHFzJR8f7qstvEz5clEF71ouHhdZss3SgO4MgcVTpty8HW7/r 9Pp5RjSLd8xBltTtOjNYxtcrnPKR49kH1X7sqd/cCm2ZDLFr3oW8gn8h8pOG9euDJEb8 ALhcPUYMZSFMTqzYbISZHAju65FU/3CpuVZg+ykruZr03jAPl7KEeB6nyqA8sKhyulR0 By/g== X-Forwarded-Encrypted: i=1; AJvYcCVZ8TDtxuyFRppWJ2PxB3FHleeCZ5rfDcJLHoTY8ygKjVwhIedSgyM0YKjZS+PNA8ywVjDsjr2unA==@kvack.org X-Gm-Message-State: AOJu0YxtihZ6wVOtXIjzd6QsXYVtFvUszGIuN+Layqcq8YqnireM3Ld6 i1/2WxHqcU+Ko9ipqEa6+yoz2doHOMK0JVVRYvA7mSm/GazgAsnlvD6A9T5rMTmZIAyR0BhjPWZ qfrd22RIpGXHR7naR7Lmoytf9fZ7i8nQC35OZWw== X-Google-Smtp-Source: AGHT+IHlj8WrQJzuiGSkH3xRWL0oTsnn36a3+WxBSXTkf5/O40cJQXUinPav2r015Kam+qXJ0AB1o31VjfZfu7yIvkU= X-Received: by 2002:a17:90b:4b84:b0:2cf:c9ab:e747 with SMTP id 98e67ed59e1d1-2e9b16e26b2mr21506952a91.1.1731365192344; Mon, 11 Nov 2024 14:46:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Josef Bacik Date: Mon, 11 Nov 2024 17:46:21 -0500 Message-ID: Subject: Re: [PATCH v6 06/17] fsnotify: generate pre-content permission event on open To: Linus Torvalds Cc: kernel-team@fb.com, linux-fsdevel@vger.kernel.org, jack@suse.cz, amir73il@gmail.com, 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" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 66EC1100014 X-Stat-Signature: uxjrzy33qch9hc3pdaucsig7soxfq66n X-Rspam-User: X-HE-Tag: 1731365116-292461 X-HE-Meta: U2FsdGVkX1+xNm5V4k4FjFmGKbe5UlwcdcWCWgCESKBv+SayKFo9Ht8DApMwaSNAyTl+CR1Oey5Kj8AYK4KRwHACtgkLfAaqR+ucT1BQfvCLIGErTuXwA64vbID1J9vwUqC12OWpyataUuws02bhON5K5w6Q+3ElWU9nK7Fw2c2XghtmvY5hSsokOrArqVHU0psNoZVotUr95hqysvFP4eBQOiCWond1VM916jSN1l6qixoZrnLGPziCY3F/yzZQLRKNKMtgSlRSOgKzAHPM6zG8yls1SANc/tBdLIh7jbZ9QucaJhtKHegm29/SW+ZrsXkNqpaHraNOsIBASJDSmiQRY63/NYCTA0L4ItJ/yCEXCwnKIVk8kjsVmyPCNehN6Q32XozVUVD1lKBCn+FTyv4rdzul8a005IYiukcv7rL612lr2mlQmLIYryNztfA2FeG5hxd114bmDqGFXnnRabTDD+67XZb+6bBfQ1+/ifmdUodwCOT97U2QxiFVwplZ3OEqZgfcgwKqvYIcdnYktV0Cp7boMB5TNLxbLHlklwyFfYGMtbKWHcbjCu3GWNwKN2qZyVJb4x0gx/PuCDpOE21Z5VXEHvebVmUUe3xWB1/QPZ7o0cmBVCFxJgFAcrKgahZEIt4YVqF7wuMGK9iTDBREIxZpCOHznWwzrsO0HjkILt3+B3W8YlfjjCkijFnDuaf7NV6b3gRV4CZ0HG3YJ6WFlKbi9Chh/VXv34A+q8eWkLpEAjDcXK8ea5VIrW+AScpvb4NApvd86Jo4PxR4NHEWh9byV43UNqZfhM737DnimGtxQt74rBp1E8aqNOM2itBnG7AwvrslmYe+0C6EyRakkPK7d6nHFpEkgu95dW/MCxeZCJ+S16Plz8oHWhnPzeJT487l9evYyssma1l9K8Naky4Yf6Lt1VLSf4sLkh4zAu8Jz/msQiA+UQSeWiB7T1pfG+/f2BnU6gLbXjA q10uepxq xig3V52G50U09l1/0lSCm7/jJGzUWC2qtLTakpW7zXlgl62yW3t6A3mceSln3TFBI5i+gU/eCPZDvvxOcHc7+oShuzlZQjdnZbCYEmbZ2z9IvY2TQLlgOe2kz0FBVo6EWG+eZkNf4o+QQyJ+gneyo9kK6CF1X7e+z3owxWt67qcsYQJDMSz3ENAArmXdEuHQV3fL93PPihinCW3t3OcF2PwWPsCvAvyCkOiIz7W684SzVt6ghDvDT11etCdsIogqFWyqItFmutUuzeHi1ZAJF6PC0G3cmT0cPfrBZgB7WleXb0RJiMZ+LzSR3dk7j8ThsxZ7Xd74IkfOFiJOn7mWhjdqnFu4YpUFWy8Jd X-Bogosity: Ham, tests=bogofilter, spamicity=0.007700, 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 Mon, Nov 11, 2024 at 4:52=E2=80=AFPM Linus Torvalds wrote: > > On Mon, 11 Nov 2024 at 12:19, Josef Bacik wrote: > > > > --- a/fs/namei.c > > +++ b/fs/namei.c > > @@ -3782,7 +3782,15 @@ static int do_open(struct nameidata *nd, > > + /* > > + * This permission hook is different than fsnotify_open_perm() = hook. > > + * This is a pre-content hook that is called without sb_writers= held > > + * and after the file was truncated. > > + */ > > + return fsnotify_file_area_perm(file, MAY_OPEN, &file->f_pos, 0)= ; > > } > > Stop adding sh*t like this to the VFS layer. > > Seriously. I spend time and effort looking at profiles, and then > people who do *not* seem to spend the time and effort just willy nilly > add fsnotify and security events and show down basic paths. > > I'm going to NAK any new fsnotify and permission hooks unless people > show that they don't add any overhead. > > Because I'm really really tired of having to wade through various > permission hooks in the profiles that I can not fix or optimize, > because those hoosk have no sane defined semantics, just "let user > space know". > > Yes, right now it's mostly just the security layer. But this really > looks to me like now fsnotify will be the same kind of pain. > > And that location is STUPID. Dammit, it is even *documented* to be > stupid. It's a "pre-content" hook that happens after the contents have > already been truncated. WTF? That's no "pre". > > I tried to follow the deep chain of inlines to see what actually ends > up happening, and it looks like if the *whole* filesystem has no > notify events at all, the fsnotify_sb_has_watchers() check will make > this mostly go away, except for all the D$ accesses needed just to > check for it. > > But even *one* entirely unrelated event will now force every single > open to typically call __fsnotify_parent() (or possibly "just" > fsnotify), because there's no sane "nobody cares about this dentry" > kind of thing. > > So effectively this is a new hook that gets called on every single > open call that nobody else cares about than you, and that people have > lived without for three decades. > > Stop it, or at least add the code to not do this all completely pointless= ly. > > Because otherwise I will not take this kind of stuff any more. I just > spent time trying to figure out how to avoid the pointless cache > misses we did for every path component traversal. > > So I *really* don't want to see another pointless stupid fsnotify hook > in my profiles. Did you see the patch that added the fsnotify_file_has_pre_content_watches() thing? It'll look at the inode/sb/mnt to see if there are any watches and carry on if there's nothing. This will be the cheapest thing open/write/whatever does. If there's no watches, nothing happens. I'm not entirely sure what else you want me to do here, other than not add the feature, which I suppose is a position to take. The overhead here is purely for people who use HSM. I'm telling you that in production, with real world workloads, the overhead is far outweighed by having to copy bytes around we'll never use. Your argument is similar to the argument against adding compression to btrfs, "but it costs CPU!?", sure, but the benefit of writing significantly less waaaaay outweighed the CPU cost and was a huge net positive. This is going to cost something if it's on, it costs nothing if it's off. If you want performance numbers that's reasonable, I'll run fsperf tomorrow and get you a side by side comparison. Thanks, Josef