Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp2093029pxb; Sun, 17 Oct 2021 05:47:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz2i8O7aTk9hr7vnOMMYTPhZPGh7aN4n6bwByf9OAQSwp05RubLsd6Rx/klT6+AB3pEVc7c X-Received: by 2002:a50:e004:: with SMTP id e4mr36003532edl.246.1634474866301; Sun, 17 Oct 2021 05:47:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634474866; cv=none; d=google.com; s=arc-20160816; b=EmUatyHjKA1iWzk/igs5fkZJLCyL5QiVsxkfrOBgQ+dZWpXXZRMzRlM4ME91IrcaAg ZknikU4b328ih9tfX/w3d/xmfudAGkJyNp4nDJ8VXijar/WNnaNXJJtFjygtnLJcJ726 IXrXxzgwjxMfbCaxoND28mBuK7Bn9IXKUt5G/vC0e3h1sAcH4/z1rdx4nNIe05Gd4pu0 nxAC9U2Jk2OLUehKbhb4iAS5zK/xTmg1hHOyMuTT1JcSI50uogfGwThuv3x6uSa0sW13 U/9Hig8XqHnlyiDoehuHTEQhc6GjezwNlz/GiggIC3KVTj5PgF9Zo/uNPcCvvbZeiSLU KgAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=B8OVo/q2M/eo6jYyxOymFITXCWpgSOR7Fi9RX8ZDSCQ=; b=dDV5WnZSsQPLRGAePWtWeLHKzeIfdFLxFYtWfkxm+PKAFeUNyawn4roaAoLt2YnvzX t0Ed/zs1hBl91DWUf/tvlozSyI348NAfoyjLioa2LcYyYMAb7+cvj8T6n5NOwNBP+iTw s0C6EPzUKhXsB3/OeeEQlOOcw73uOfaVGztAI3oL65efiFwSzVgtjac8LCw30QfXV7pl h3EE9fWsPjOeBRCJZs19tgSsUmfA1WQs88l0r6kJ8w6kR/NfrX2ne5bAIvGTBbfpOyKB Y9HmQ2qK4EQeyiSeJS5OcfvNR8jlW/PRYkIyUjCevpoSHXdViWCNFRMYth+uLrcgPwSW Ahyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=DJ1sk2gG; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e6si14831181ejl.722.2021.10.17.05.47.16; Sun, 17 Oct 2021 05:47:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=DJ1sk2gG; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242235AbhJORwM (ORCPT + 99 others); Fri, 15 Oct 2021 13:52:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237670AbhJORwM (ORCPT ); Fri, 15 Oct 2021 13:52:12 -0400 Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1EA8C061570; Fri, 15 Oct 2021 10:50:05 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id y17so7983839ilb.9; Fri, 15 Oct 2021 10:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B8OVo/q2M/eo6jYyxOymFITXCWpgSOR7Fi9RX8ZDSCQ=; b=DJ1sk2gGlDWB2tTltEB7zC+lsOFWCgzmvUAZTSKtZuZCjHsXHBOLug2T9AGz+watrn aTbsx5Yeq9INmRckY2X03bN2018otdF2iH8lkpGdN0+j1U8DbbZs1TNW5WDL7TIvgEM2 rgipKChjHaKBsAlLOW0UGD6gUKfzTEVsJc2jNuBREK9DIOW1IOC7AyDDUstpd6IinTr3 yc0YNCWXXYW0PiqC+VMvOH2s73CccNzoZedSHx9yrgDjzLTtuNTWLaKZVBLduFkeMjqE MpTzxnlEC4jsgP5JTcWAFn8P9jGwzGotIhST43wvZBY9BL8RruruYpWVaEOxsPW5jmX3 Wt4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B8OVo/q2M/eo6jYyxOymFITXCWpgSOR7Fi9RX8ZDSCQ=; b=5W/5eMXAOA7W5uhJmnIkwmbGp66ApztD2Xn9GoM5uFsUtgvm7Kttii3q12zUOY9aZz bXntcrcXghkEIU2Mi8heTlEJkdMQYM7WNW5wB4pmCb8Yact2RA2SIXiDych9Gfqbe1cD 759MxCnazNef2GtrJq2EX08LfhlTR7QzS0IjMo/UCdYVjkhwLBKgVgNznQl4YmOGhBAZ oEukuwI2i5ZzfL/ICOsfU6LumKa7jyM2IAyo2eY47HOzn+mX1EPCStNX5N/3K6/K5Ow2 7Nt4TaV1qjp1qVsIIOFFTJkJ3sq8aXwET8KEFdwjPvol+Kz3ej06r7pJAWdR/DkMKgQh cdwg== X-Gm-Message-State: AOAM5302ThEV3wvKckBrRFxle5azFWnVR+y+Ju1fIhCK90mWIR7SHyOJ nPSQm0Hcpy7yLOdr0Gmej1RSxqSv3NU2b2Dr1iQ= X-Received: by 2002:a05:6e02:1be8:: with SMTP id y8mr4814921ilv.24.1634320205195; Fri, 15 Oct 2021 10:50:05 -0700 (PDT) MIME-Version: 1.0 References: <20211014213646.1139469-1-krisman@collabora.com> <20211014213646.1139469-20-krisman@collabora.com> <87tuhip6v7.fsf@collabora.com> In-Reply-To: <87tuhip6v7.fsf@collabora.com> From: Amir Goldstein Date: Fri, 15 Oct 2021 20:49:54 +0300 Message-ID: Subject: Re: [PATCH v7 19/28] fanotify: Limit number of marks with FAN_FS_ERROR per group To: Gabriel Krisman Bertazi Cc: Jan Kara , "Darrick J. Wong" , Theodore Tso , David Howells , Khazhismel Kumykov , linux-fsdevel , Ext4 , Linux API , Matthew Bobrowski , kernel@collabora.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Fri, Oct 15, 2021 at 7:53 PM Gabriel Krisman Bertazi wrote: > > Amir Goldstein writes: > > > On Fri, Oct 15, 2021 at 12:39 AM Gabriel Krisman Bertazi > > wrote: > >> > >> Since FAN_FS_ERROR memory must be pre-allocated, limit a single group > >> from watching too many file systems at once. The current scheme > >> guarantees 1 slot per filesystem, so limit the number of marks with > >> FAN_FS_ERROR per group. > >> > >> Signed-off-by: Gabriel Krisman Bertazi > >> --- > >> fs/notify/fanotify/fanotify_user.c | 10 ++++++++++ > >> include/linux/fsnotify_backend.h | 1 + > >> 2 files changed, 11 insertions(+) > >> > >> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c > >> index f1cf863d6f9f..5324890500fc 100644 > >> --- a/fs/notify/fanotify/fanotify_user.c > >> +++ b/fs/notify/fanotify/fanotify_user.c > >> @@ -959,6 +959,10 @@ static int fanotify_remove_mark(struct fsnotify_group *group, > >> > >> removed = fanotify_mark_remove_from_mask(fsn_mark, mask, flags, > >> umask, &destroy_mark); > >> + > >> + if (removed & FAN_FS_ERROR) > >> + group->fanotify_data.error_event_marks--; > >> + > >> if (removed & fsnotify_conn_mask(fsn_mark->connector)) > >> fsnotify_recalc_mask(fsn_mark->connector); > >> if (destroy_mark) > >> @@ -1057,6 +1061,9 @@ static struct fsnotify_mark *fanotify_add_new_mark(struct fsnotify_group *group, > >> > >> static int fanotify_group_init_error_pool(struct fsnotify_group *group) > >> { > >> + if (group->fanotify_data.error_event_marks >= FANOTIFY_DEFAULT_FEE_POOL) > >> + return -ENOMEM; > > > > Why not try to mempool_resize()? > > Jan suggested we might not need to bother with it, but I can do that for > the next version. > > > Also, I did not read the rest of the patches yet, but don't we need two > > slots per mark? one for alloc-pre-enqueue and one for free-post-dequeue? > > I don't understand what you mean by two slots for alloc-pre-enqueue and > free-post-dequeue. I suspect it is no longer necessary now that > FAN_FS_ERROR is handled like any other event on enqueue/dequeue, but can > you confirm or clarify? > What I meant was, your code is counting error_event_marks. Every mark accounts for either 1 or 0 queued events, because more errors from the same fs would merge with the single queued event. I thought we could have one more event per fs being copied to user but really we could potentially have many events allocated, before being "merged", so my calculation was wrong. Anyway, as Jan explained, the limited size of mempool does not doom allocations to fail, so we probably have nothing to worry about and there is no need to mempool_resize(). Thanks, Amir.