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 F325FD711BE for ; Wed, 20 Nov 2024 15:57:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 892196B008C; Wed, 20 Nov 2024 10:57:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8426D6B0092; Wed, 20 Nov 2024 10:57:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70B046B0099; Wed, 20 Nov 2024 10:57:46 -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 4F4AE6B008C for ; Wed, 20 Nov 2024 10:57:46 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E8AB11C76ED for ; Wed, 20 Nov 2024 15:57:45 +0000 (UTC) X-FDA: 82806927378.22.548D2B4 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf18.hostedemail.com (Postfix) with ESMTP id 1298C1C001A for ; Wed, 20 Nov 2024 15:57:20 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Bbpc/aIr"; spf=pass (imf18.hostedemail.com: domain of amir73il@gmail.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732118172; 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=WRGyncbrrXIdlAfsQ6zZKXRnlgyQmZYvHV4189k1IoA=; b=MMLvOIvcOcfErAHE40YlMkD+MSg86Q+PeDaRx+jP4h/WEEKC4qOLz4kzyn2Rg/XgBnsNvE Cm2hj3HVgLRCRZcakm9PwMWHLshqBijyhNQyIHxnl+5n4Is7wzsh7dsKsODZ10Cs41ZklR lvn5wYulpQEAnF1h4MKaSCgpUd1aLdk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732118172; a=rsa-sha256; cv=none; b=w3WyYZEhcMCaOXzVy5zlk9r/D34KetJlQyUh7jNdDXA6syerEuZVA2YMpPB+lMAQewL7Pr /HY1tUXaoB+zahBgqEXxqXcrb1WX430G99NBvt8IpQMyOWlpMkjwX+Jjvd+EIk/Z6E+/v8 KN8t1mj3JLWQDcyiQm4mkKaJkIZ3xmU= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Bbpc/aIr"; spf=pass (imf18.hostedemail.com: domain of amir73il@gmail.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-5cecbddb574so2785893a12.1 for ; Wed, 20 Nov 2024 07:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732118263; x=1732723063; 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=WRGyncbrrXIdlAfsQ6zZKXRnlgyQmZYvHV4189k1IoA=; b=Bbpc/aIruC7PZ+gFlUUXzLFxiS/4I9LMPCTah4q/yORdd4To94W3PhlAZu+YAhLf0s Uph238aXkphTNMU208GA+s7kX85MHGPxOBGawt7GmoJCGynoCShxKlRARP/z7T1ChGOc Qtvnh6VtpH4wcC4X0eXDdoHVlgU+bOoscdCbjfIO/Bw8LZ3zkmFUj8SPrZFF/was11fu BDBCFtmwIydu8OpRGobs2EwcijPZINt5hQs14KDED+StajczvAEBhNrjcAztw6rFW17X kjqkAuXcVcE5mc4lXnYn2m7qxgQzPnDHT1F1VjkeUAMRNyldCeVYcTvcijy5um0SA0KD XqHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732118263; x=1732723063; 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=WRGyncbrrXIdlAfsQ6zZKXRnlgyQmZYvHV4189k1IoA=; b=eArnfWtjWeFlXOD1PoyUdIfbf9+xqPu4TaPW5JmYhQmttBdiygCkJ4cvzTQMrTcApT fYSOQlFsPqqSpboeBp6LihZdo+Ux/mMw2tRMehmaNKPCj/qN6I+3fV9Afp13NZSKkn73 XlX49wzn352ewEvLrK+vEIB9VNhqFhXu7fv0wy+mjJU9olXbrz9BDq1JiLWU7Y76mKOO 5B8VNCe0lb2qth4pJd3IBx1yS9pjf0H89SogJCnS/Bc/gDJDDZfjScdP7sEOusHIJXHZ YqOUmZTf4N3U9bBdWukcIaaNt5i5+yKv0/hRtLnd1O4iISovaNr1h2zO5i6+/jBpDOc+ qIQw== X-Forwarded-Encrypted: i=1; AJvYcCWp0o/qtk15v760xWjBUlqjkEaqkJpFl9/6bFVHGPSoTBhdHX6I7pI5vyU0c0kDlD3vpVYxuNxZgQ==@kvack.org X-Gm-Message-State: AOJu0YxmY+IhNbgWyYJfO903sEoPskt6N6HdIUOehW2n4XhVPGb4n/zB sAst48nzTCMWz79CLJcmy0RKhFts+QNSx48dH9BXKhNcnR8BHc+0GgLzQ5rMKjQjyOVaYpN/91r Sj1LRe5+3NXNjchOsmI4l8AzHezA= X-Google-Smtp-Source: AGHT+IETTaFGIGc118mum/twHaBKzMangpXAjhXpkJ0HKu8j2KHFNfZ78kJMQvPrrL5BxWEBj0d7O0zBog2tCKNlcyo= X-Received: by 2002:a17:907:3687:b0:a99:f972:7544 with SMTP id a640c23a62f3a-aa4dd70b6c4mr310564366b.38.1732118262269; Wed, 20 Nov 2024 07:57:42 -0800 (PST) MIME-Version: 1.0 References: <23af8201db6ac2efdea94f09ab067d81ba5de7a7.1731684329.git.josef@toxicpanda.com> <20241120152340.gu7edmtm2j3lmxoy@quack3> In-Reply-To: <20241120152340.gu7edmtm2j3lmxoy@quack3> From: Amir Goldstein Date: Wed, 20 Nov 2024 16:57:30 +0100 Message-ID: Subject: Re: [PATCH v8 09/19] fsnotify: generate pre-content permission event on truncate To: Jan Kara Cc: Josef Bacik , kernel-team@fb.com, linux-fsdevel@vger.kernel.org, brauner@kernel.org, torvalds@linux-foundation.org, viro@zeniv.linux.org.uk, 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: rspam10 X-Stat-Signature: e15u53nipbz9x4nbrkfmmharnysjwra6 X-Rspamd-Queue-Id: 1298C1C001A X-Rspam-User: X-HE-Tag: 1732118240-440678 X-HE-Meta: U2FsdGVkX19B4WeTiqrJNlRbS30RKWgGGNn3m3Vk/JHsnKpvz2Rclgv/ucelGtY8EL3xJQk1bC7sNwd8TbcEFdD6fO73WGOM7AkltIm1Bh5cspH7iT2Eqd2ErLen6Lac6cX7fAADyLoo17MMBkrJaGeFShAS6B7V/xQDV6PwIang6+TqQDxVfSiaemt6W3CDSHsCrtpRW0U0c5PnXgHs/Km58DCGxiizF8EbTU1rRSbNa4mDsRNcSgxEIdNNVCMOVFoF70KZNRv2HwLCozJFbFRgpLyct9f1ujYa+RHu/I6K0xkF33pPTVjFhZ30W5VVJWfarXmKrmGbo+mw6ep9t/FqO9jQYpylGrkQqkIzNXfCkv0yuVWtAAQk8RWDsOI7UCPtoJ/mAJu2HzRNNbdBFXi6VdHeMMeRYOAe9jVU1ypi850ODGsFM5M2Ntz4iIbBextIuplIu4JJ3MZokW5XYojXG/0A3KnYkWgXXm1BCY2tf4ki3x5tSpDrlfI/ldBkr42HvzEK3mqLAQ4z29fozc9UUWxFlu0KfK33sMW15Nm10sNUFXuyUfGlNMrKWoDi2O+nX0k+dnIhRKv4a/J49+bDs9Pg/zxLH5GQ7vRzfSbHTlkfRtrN1q/yHn6vuef6NjorSdb5YuYs73RSopxY4hSXHTHe7cfUZLJ5ihvhKjCDHbTFpspNLFCqfl8lePrlr/Bqn4DSCsgGh/kLPF+7uIk8Lwxg3yiMncQCNeALkQxDsesYwdfElhsI4MTgjV7dXkVqYopv2JVrz8fPm9ZexyiMeZdk3ARb14rAJLEVLw7pFC/siC0keSmzKpeCvsofpYcRPZmkXLGh10xmneldYUqQncLwW1bz/pWMpIkOvifqMrZsIrwAL4IPt8O9GiKOaRbI+pT60H7LEYs/r5MB9wNDO/Ti0hV6pXJH0F6jQQ7T7SSk/slcRFH6nlz37eLnNQBHmExFCdbYI00D82d ig1K/ySl VzRvviMVPS6DyiNc+PxAlZ8mH6KklCwKn2JMzymqt/yNxVnQloz2Snr+4YMvpGbOge9Xs07QZ8O8S1LKcV018BRPRJ1DL62lrBA8+z03qbeHIna5Ophreazvmb/C7phECCFVpV4KO5TyaR9LvZUsFHtXSL0Z83a5sYfEuYhnTRn6apQJRkSff4T9GlmRvK3NEVklLKhLcIiofB9ADf8JKkAkBT6zFeq15t46zfZ0fVWSl/DEF/AF6n1859xxRsfcHbsrZmHxPSbtfmW/Vas/fDM7LRtvpumXHfX5O15rKc1Rt63s52TPuc3s01JtNW3oU/b6UKHzvCty/uzRwunFAL7G4yw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000342, 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, Nov 20, 2024 at 4:23=E2=80=AFPM Jan Kara wrote: > > On Fri 15-11-24 10:30:22, Josef Bacik wrote: > > From: Amir Goldstein > > > > Generate FS_PRE_ACCESS event before truncate, without sb_writers held. > > > > Move the security hooks also before sb_start_write() to conform with > > other security hooks (e.g. in write, fallocate). > > > > The event will have a range info of the page surrounding the new size > > to provide an opportunity to fill the conetnt at the end of file before > > truncating to non-page aligned size. > > > > Signed-off-by: Amir Goldstein > > I was thinking about this. One small issue is that similarly as the > filesystems may do RMW of tail page during truncate, they will do RMW of > head & tail pages on hole punch or zero range so we should have some > strategically sprinkled fsnotify_truncate_perm() calls there as well. > That's easy enough to fix. fallocate already has fsnotify_file_area_perm() hook. What is missing? > > But there's another problem which I'm more worried about: If we have > a file 64k large, user punches 12k..20k and then does read for 0..64k, th= en > how does HSM daemon in userspace know what data to fill in? When we'll ha= ve > modify pre-content event, daemon can watch it and since punch will send m= odify > for 12k-20k, the daemon knows the local (empty) page cache is the source = of > truth. But without modify event this is just a recipe for data corruption > AFAICT. > > So it seems the current setting with access pre-content event has only ch= ance > to work reliably in read-only mode? So we should probably refuse writeabl= e > open if file is being watched for pre-content events and similarly refuse > truncate? I am confused. not sure I understand the problem. In the events that you specific, punch hole WILL generate a FS_PRE_ACCESS event for 12k-20k. When HSM gets a FS_PRE_ACCESS event for 12k-20k it MUST fill the content and keep to itself that 12k-20k is the source of truth from now on. The extra FS_PRE_ACCESS event on 0..64k absolutely does not change that. IOW, a FS_PRE_ACCESS event on 0..64k definitely does NOT mean that HSM NEEDS to fill content in 0..64k, it just means that it MAY needs to fill content if it hasn't done that for a range before the event. To reiterate this important point, it is HSM responsibility to maintain the "content filled map" per file is its own way, under no circumstances it is assumed that fiemap or page cache state has anything to do with the "content filled map". The *only* thing that HSM can assume if that if its "content filled map" is empty for some range, then page cache is NOT yet populated in that range and that also relies on how HSM and mount are being initialized and exposed to users. Did I misunderstand your concern? Thanks, Amir.