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 C643BD75E4A for ; Fri, 22 Nov 2024 13:51:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A7D06B00B9; Fri, 22 Nov 2024 08:51:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 131226B00BA; Fri, 22 Nov 2024 08:51:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EEB2E6B00BD; Fri, 22 Nov 2024 08:51:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C89476B00B9 for ; Fri, 22 Nov 2024 08:51:40 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2B834AF17C for ; Fri, 22 Nov 2024 13:51:40 +0000 (UTC) X-FDA: 82813867752.11.A52CBA2 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf13.hostedemail.com (Postfix) with ESMTP id EB30320013 for ; Fri, 22 Nov 2024 13:50:38 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="U5mQug/W"; spf=pass (imf13.hostedemail.com: domain of amir73il@gmail.com designates 209.85.208.173 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=1732283435; 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=O1M+VNoDV01ttI4ykAkLiT0TH7dIi4lr51PaobubPkY=; b=2tZcWyrGxHLe6Sfh9FrrOpTNby7j9ph8OlBzjAI/UxxcRlOgtafJzkN8A2SPiygoa+VKU6 /FBp6kceRdc+r3kMSmrPd9EKR5QO+PlfZBKkBIC288jRYaBt05fMc98MhEz0gPK8bU3YYG 1OoG05lv+LO3zy8wvWZgnW/zliWKxiI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732283435; a=rsa-sha256; cv=none; b=hmTKPYNHhwjJvPrCqsEBrqyZtPUXwzaCoUlSBHq6oVPD++45LPsu3bVI62RY19WJNHtrzV PwxE7P/ae/8tA1M1HT+ptl8P/dJZx+rOdw8FR4CBcTvdIttxlQbv7yEpFkd+7QVf2ZmHs4 SHL81LQwkoJpjcZwkpRgPItWDb481xw= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="U5mQug/W"; spf=pass (imf13.hostedemail.com: domain of amir73il@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-2fb559b0b00so21194841fa.0 for ; Fri, 22 Nov 2024 05:51:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732283496; x=1732888296; 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=O1M+VNoDV01ttI4ykAkLiT0TH7dIi4lr51PaobubPkY=; b=U5mQug/Wkg4ldVNIvbhmtgM/FGl1DccCpH8EI5Y+P6lBZfG4Y+MOC/AlG69tHCLjpq nMdaGzi/ZMz2SGlv3rXa4RuX8aT7KxSgwsPr7ddBH3ZASfKI/JpR07qNFOyyAaV9TFEh Y7nYp+Y8B7ncR1FhTZu1MhDMr7Lp7VzZSfpYWRyi4ztm4aihKCgZunKBq9nWeFyG7Bjy wH0VN7ubu9leAQ6ju1SvGAPF3Tqft/aE4c+ZQBj3tGQeFcKTejin23JDDLFrbSA6nUgm S20sZoBluEKIqLmMH0z1skCM+0H8PN8CsNlg7zSTv1Cw+XBCTiiaWgzP1JqWvhY8panx vu5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732283496; x=1732888296; 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=O1M+VNoDV01ttI4ykAkLiT0TH7dIi4lr51PaobubPkY=; b=gDpO3NMeW04RU3gUwr13zdPRg7vn+CHN3iyNdrLWf1lLkYtpP6DHrpvdegG/r/R9ap RBkPZC+YRjLOi65ffDdswBFCJdLpM4lasmE2b3MhCjs8dMg/w+lhiSkNv7evdgckYip+ LHi3l+5fSqJtfaOYH4Yuc6/POoZMMw82pRLVfYg74I2xjnYV1aPxcnutjl+P7POdPxWi naqBadZ9Bs+FSSudVePJj5BhQmhnG9mTCcFuJFZYZiaZWFqekU4jafHrcBcOPGCYmggG qX/ZzEphHqOjNalCQybJP6ZovmbnKoSaETDClqVLZMWr8TcjItid1hQiOdWdI1F1q8bA Pjgg== X-Forwarded-Encrypted: i=1; AJvYcCUIC9LOxx5iQSd7AIQycFcjdy6mydULdAPLIuieoCySmiXqovQt9p7/bePEGapY6k62nxenoN5qIg==@kvack.org X-Gm-Message-State: AOJu0YxTxhHF6cXIOQey85TgD92SvpVwyxwnOMQXBeUavKfPq5KIwExJ lXM6aq06qAg8zpneEIRku9qmLULTF2xULbIyAB5ICwNcDnD/ScVinzOXPDg89yf7CoFBnnVxgdP cdTUQi0JdzubhFYaq966+jysHxI8= X-Gm-Gg: ASbGncsiDn8nqeoouskoZn4Yy/OSFyh6Dk3jOPZw+pFO879w337m5ZuCSSoNK8uNNUq x1Q9B9XkVNW7d8AqEU39GwvTFVvOt4Ww= X-Google-Smtp-Source: AGHT+IFksCaFnz5KcROoZ2l24vat56l/bmgqMqDIpj9UInqeXkdyaOzrJLTT+HRXZb32Fn4KXFKnG0FbN2YKckPb6S0= X-Received: by 2002:a05:6512:3d06:b0:539:9645:97ab with SMTP id 2adb3069b0e04-53dd389d83dmr1593356e87.33.1732283495537; Fri, 22 Nov 2024 05:51:35 -0800 (PST) MIME-Version: 1.0 References: <20241121104428.wtlrfhadcvipkjia@quack3> <20241121163618.ubz7zplrnh66aajw@quack3> <20241122124215.3k3udv5o6eys6ffy@quack3> In-Reply-To: <20241122124215.3k3udv5o6eys6ffy@quack3> From: Amir Goldstein Date: Fri, 22 Nov 2024 14:51:23 +0100 Message-ID: Subject: Re: [PATCH v8 10/19] fanotify: introduce FAN_PRE_ACCESS permission event 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-Stat-Signature: yu55ug7d5qas3xzqef7mcfk5fwnu6tun X-Rspam-User: X-Rspamd-Queue-Id: EB30320013 X-Rspamd-Server: rspam02 X-HE-Tag: 1732283438-358575 X-HE-Meta: U2FsdGVkX1/C+9dAPMSHUavxALd+CxjmgPOntbmPfz9eE1KJMx9zpDRuV1nT3dDjdhJgxvPl89VfRsVZhNwdJlx+eVXM0Jvr1eM1bIZmq5ZArkCYzdudy7VbLo2OqiLsl01iw+cuPSSRWzWxnncOGLNW6uGu13o3aKgFdzMm1GYyD1ruSwh1wAw1Q4P8tpG5F/ApWpzz+Wfy4D/Bt7eghGvNGBNlZzCjrx+SRPTT2rH0ivNZuvQwqOisuuDBZVN3UEDR/5rTPu7Np1Mv+0Hjgjg/bVPUPpJuYWiG4zmhYXqpaqJPh4cB5Iy9j5P6NZ7AvvTfJM4QKRftpuE+SzrMf2zhbhRyAB5tKPNMUMegaTU0K8ZR0/L7lJ2gU7rVeJut8/3SXfsy8J8o3E9C48tbJRrinRf0XorSu9TbNeS6V05M50hxtiWJj6lgYGZntds3qWkpMZXYqt2AHIxmsEx01Zsfn1NEOdTcdpUXiIcVW2+WyjsWssi/UezwfNwnYRr9vbpBPhmJNYctDzsz4C+2bI3pDa/nqqcVPXHNq3er0mxS42572GaxDBg5FCOH9RyhclTWuHII1bheQMiyMbim/QlerTR81pbFARcMFZ4zFVa+zvyXUqOgYYM/aBflXw5fbVS6kPiF5KEKfbRdDmCsrsLMEZhvZPfaQYhkpWNXyi2Mrt3bHcIxVyi4Ms0C2Fl17D8NN4Fw7Ih6mxxfb1yS2BmeQRraTqkBQS1GnnnUgRWyBU96UcCEv5IUiwYvzZzryiifAaWhaLJUhRdEd5u+Hx6aTa90+xT1RMMLOL0zabeOleyPQju+hSecDzbYEHObIQkNDXaJHZcDANfdwBetwb29E9WQQjSieqiQSkn9nSuDM83jkVgBIzjMUs1pKmJ06Ck8cF1j+3Ni/H2AkbhPko4gQdx4gN2+aYYopBFEm9jaDvSAHFSgINaVWxGOO9a1t+1U3L7qr1tfLpxpiwE JO9prY8e /78PuKybU9ebzEQlPRIKCWDvO3UexEwpLxrEg/oWin3DLcEQ/t9zwCN/2bt0gmLXC3fSgSKFIMetO7XGvrYf2Xik7A32q8iTYlA7Ca8ge4LiniZV+bgE5Tl1h3tuLVpjTpErsiA0ghi4QAP5hVQtkHsAj3Hj3Z2WNFx7CZbMR2CMP+CT9bKB6s9XhEvlwmc1gE1wIEcp0xoTY1qPwbk7NUodFrVoHOssqMB3l8gmgkF+qrE2jTj4+nlBDSzkr3P5LbKge+BdKSMgd8x0a0DdJlCM4v/OxRWqtCH6RMOIMBa0YSweuVeJxC4U6qYsNiLa26LJTQB/KxnOxr09o4E5o0+048rqXWnR0d+KZaiZyyAMvkU38pgZRuZQxmtDrK3RoyFinSUWXLayUxeM= 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 Fri, Nov 22, 2024 at 1:42=E2=80=AFPM Jan Kara wrote: > > On Thu 21-11-24 19:37:43, Amir Goldstein wrote: > > On Thu, Nov 21, 2024 at 7:31=E2=80=AFPM Amir Goldstein wrote: > > > On Thu, Nov 21, 2024 at 5:36=E2=80=AFPM Jan Kara wrote= : > > > > On Thu 21-11-24 15:18:36, Amir Goldstein wrote: > > > > > On Thu, Nov 21, 2024 at 11:44=E2=80=AFAM Jan Kara = wrote: > > > > > and also always emitted ACCESS_PERM. > > > > > > > > I know that and it's one of those mostly useless events AFAICT. > > > > > > > > > my POC is using that PRE_ACCESS to populate > > > > > directories on-demand, although the functionality is incomplete w= ithout the > > > > > "populate on lookup" event. > > > > > > > > Exactly. Without "populate on lookup" doing "populate on readdir" i= s ok for > > > > a demo but not really usable in practice because you can get spurio= us > > > > ENOENT from a lookup. > > > > > > > > > > avoid the mistake of original fanotify which had some events av= ailable on > > > > > > directories but they did nothing and then you have to ponder ha= rd whether > > > > > > you're going to break userspace if you actually start emitting = them... > > > > > > > > > > But in any case, the FAN_ONDIR built-in filter is applicable to P= RE_ACCESS. > > > > > > > > Well, I'm not so concerned about filtering out uninteresting events= . I'm > > > > more concerned about emitting the event now and figuring out later = that we > > > > need to emit it in different places or with some other info when ac= tual > > > > production users appear. > > > > > > > > But I've realized we must allow pre-content marks to be placed on d= irs so > > > > that such marks can be placed on parents watching children. What we= 'd need > > > > to forbid is a combination of FAN_ONDIR and FAN_PRE_ACCESS, wouldn'= t we? > > > > > > Yes, I think that can work well for now. > > > > > > > Only it does not require only check at API time that both flags are not > > set, because FAN_ONDIR can be set earlier and then FAN_PRE_ACCESS > > can be added later and vice versa, so need to do this in > > fanotify_may_update_existing_mark() AFAICT. > > I have now something like: > > @@ -1356,7 +1356,7 @@ static int fanotify_group_init_error_pool(struct fs= notify_group *group) > } > > static int fanotify_may_update_existing_mark(struct fsnotify_mark *fsn_m= ark, > - unsigned int fan_flags) > + __u32 mask, unsigned int fan= _flags) > { > /* > * Non evictable mark cannot be downgraded to evictable mark. > @@ -1383,6 +1383,11 @@ static int fanotify_may_update_existing_mark(struc= t fsnotify_mark *fsn_mark, > fsn_mark->flags & FSNOTIFY_MARK_FLAG_IGNORED_SURV_MODIFY) > return -EEXIST; > > + /* For now pre-content events are not generated for directories *= / > + mask |=3D fsn_mark->mask; > + if (mask & FANOTIFY_PRE_CONTENT_EVENTS && mask & FAN_ONDIR) > + return -EEXIST; > + EEXIST is going to be confusing if there was never any mark. Either return -EINVAL here or also check this condition on the added mask itself before calling fanotify_add_mark() and return -EINVAL there. I prefer two distinct errors, but probably one is also good enough. Thanks, Amir.