Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1667237pxy; Thu, 29 Apr 2021 11:41:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxsI30MoAloMhJzwXxVmC9pVTuQtgo3Mo11HsJwDp49c8Xf/P9B4D+aT7CuUi9rYUN2Ka8s X-Received: by 2002:a17:90a:f285:: with SMTP id fs5mr866045pjb.7.1619721678763; Thu, 29 Apr 2021 11:41:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619721678; cv=none; d=google.com; s=arc-20160816; b=hz4x8D6oKH3EVQzhqKCa9cI8aHcjxfo7nutYVnY+MaPVqUIifwCLefxUf3bmY0OMv3 rEtI1QOP/JXBMRZBdVKuXQGPHLavw9DvTYGgOZl+7aojRhphezFxoA9o4haBCceU/hga JrlAqHIGIaWwgR+n/PBLPuPf5XfzXPICADNe6rm7gUzbWiQryqwjz/uVa4oTQMJH44cn /1xhSbzPp1sM9GnTVWw72WhRoN+qWI0GzTtIo/dRZM2SInknuuj76CQJKITalQ6Ati5c 9Dbk5KUL7fc5wr9zFHaXct1kNtdmounzQTpcsnp+N9AGKmBPiGxiAD7F46X3BprvoE15 lcNw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:in-reply-to :date:references:organization:subject:cc:to:from; bh=WTonoUnYBfuoUz6hSVyqKFhL5v4up+viB0LqOEecGic=; b=hWKqVLJXYRZeoZ+vNmIjf0wpduLmVIgNCeYjXaLas7p/+qNHuGl4B0ItAquTg2Ckx6 tZdHmfkSfQ2B8WcJXTvIQz/8PNzq1clt1SKU3kKLOHSexZJDpgCGk9YW+hBn0Qe5Qi3h 6h76WTZV9Nfe03U8dXDt/Lvul1FyxrL9JpQmFAowJPTmxh0igT600pTfCU8sHOxaCf8T 7KHiP6hcI5fA6/xyI//hrgA4Xaa/WTYPrl1TmxAKcJSNTCa9knlVSRP7ZjWRTRSUZK20 bAy2uPFWwngeVTvdWAEPRQcGNsz5A18EiMjCjjkNpDiOR0Mdxy86OM21afZQqQGvxQxN o81w== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w7si15435373pjl.7.2021.04.29.11.41.05; Thu, 29 Apr 2021 11:41:18 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241057AbhD2Sl3 (ORCPT + 99 others); Thu, 29 Apr 2021 14:41:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233902AbhD2Sl3 (ORCPT ); Thu, 29 Apr 2021 14:41:29 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A080C06138B; Thu, 29 Apr 2021 11:40:42 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: krisman) with ESMTPSA id 15E9B1F4366D From: Gabriel Krisman Bertazi To: Amir Goldstein Cc: Theodore Tso , "Darrick J. Wong" , Dave Chinner , Jan Kara , David Howells , Khazhismel Kumykov , linux-fsdevel , Ext4 , kernel@collabora.com Subject: Re: [PATCH RFC 10/15] fanotify: Introduce code location record Organization: Collabora References: <20210426184201.4177978-1-krisman@collabora.com> <20210426184201.4177978-11-krisman@collabora.com> Date: Thu, 29 Apr 2021 14:40:37 -0400 In-Reply-To: (Amir Goldstein's message of "Tue, 27 Apr 2021 10:11:12 +0300") Message-ID: <87lf9153yy.fsf@collabora.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Amir Goldstein writes: > On Mon, Apr 26, 2021 at 9:43 PM Gabriel Krisman Bertazi > wrote: >> >> This patch introduces an optional info record that describes the >> source (as in the region of the source-code where an event was >> initiated). This record is not produced for other type of existing >> notification, but it is optionally enabled for FAN_ERROR notifications. >> > > I find this functionality controversial, because think that the fs provided > s_last_error*, s_first_error* is more reliable and more powerful than this > functionality. > > Let's leave it for a future extending proposal, should fanotify event reporting > proposal pass muster, shall we? > Or do you think that without this optional extension fanotify event reporting > will not be valuable enough? I think it is valuable enough without this bit, at least on a first moment. I understand it would be useful for ext4 to analyse information through this interface, but the main priority is to have a way to push out the information that an error occured, as you mentioned. Also, this might be more powerful if we stick to the ring buffer instead of single stlot, as it would allow more data to be collected than just first/last. > > Thanks, > Amir. -- Gabriel Krisman Bertazi