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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6D80C38A2A for ; Fri, 8 May 2020 17:05:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8665E2083B for ; Fri, 8 May 2020 17:05:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=rath.org header.i=@rath.org header.b="JqXbJZec"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="MYfiYdVK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726767AbgEHRFu (ORCPT ); Fri, 8 May 2020 13:05:50 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:51445 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726750AbgEHRFu (ORCPT ); Fri, 8 May 2020 13:05:50 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 6C5F55C01F3; Fri, 8 May 2020 13:05:49 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 08 May 2020 13:05:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rath.org; h=from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type:content-transfer-encoding; s=fm2; bh= jDHydD+6BCPSvhs8uR+ChWtBD5nHPXar/DRi9kzp9Rc=; b=JqXbJZecDueHIIzA mDcuJMevKU5F09ZTl3LD7AwzJ5l9J4lOQ5pYWkHZSvoSom08RAz3xRYRmDUeAUMS keAbcXIk32CJi6rO7+HtT22m7FTlhHW6HMHjIdiOQMJAzcGRDjxufytovWJ2cZZU MzFpUShXpSnocQ4aNS62z+oSCCUm6PCtGcuM68IX83SGXOt9tUBCT3BNjEAZv5RI HWiHbBVn7YePRDB+aZuDS7FV56LkgAM/f6s46kIyndg5JIJhzPyBl8rVscFCkSXh mtNKX11QB1NT1cS2Cmhc4aKdYiAh8Q8DH21497AyYQjVB36PiBgmmCo8uec4q9qz rmZIkA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=jDHydD+6BCPSvhs8uR+ChWtBD5nHPXar/DRi9kzp9 Rc=; b=MYfiYdVKFHdisWsV65Sdw73Oglc63scG0xTQs2ON49SyRZekoW0m5qj3d 0FrsYv5yxHX03zfPUS3sosE0GqfF4MGC4N+cE5ga+pfElIG0WAWL7hbBwB2QQu9B xigVJUEOVWST5D9WHh4tJF87ekqoI0sv7boUU+KYpdUj1UWGVL+aeoS0FivWoCAE lI3XrlInznx0SG5pvd0EX7lyv0A3XPHDyCIAWF9yb6xCp9o0TSRM0FVgmAZbRuM8 KzeXq0d5tYCJPsGvq75Ca84D/njSZ4poFMaLngfmXC9UVIm3v/UunauONsLXVxEk VlJVJxY6G9N2OL7/IOznE9qI9ImCw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeefgdegvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufhffjgfkfgggtgfgsehtqhdttddtreejnecuhfhrohhmpefpihhkohhl rghushcutfgrthhhuceopfhikhholhgruhhssehrrghthhdrohhrgheqnecuggftrfgrth htvghrnhephfetueeghedutdefteegudfgjefhfedthfehgeegkeejueevieeljedtfeef ffehnecukfhppedukeehrdefrdelgedrudelgeenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpefpihhkohhlrghushesrhgrthhhrdhorhhg X-ME-Proxy: Received: from ebox.rath.org (ebox.rath.org [185.3.94.194]) by mail.messagingengine.com (Postfix) with ESMTPA id 4D913328005D; Fri, 8 May 2020 13:05:48 -0400 (EDT) Received: from vostro.rath.org (vostro [192.168.12.4]) by ebox.rath.org (Postfix) with ESMTPS id 1DEE549; Fri, 8 May 2020 17:05:47 +0000 (UTC) Received: by vostro.rath.org (Postfix, from userid 1000) id 3AE30E33CD; Fri, 8 May 2020 18:04:34 +0100 (BST) From: Nikolaus Rath To: Miklos Szeredi Cc: linux-fsdevel@vger.kernel.org, fuse-devel Subject: Re: [fuse-devel] [fuse] Getting visibility into reads from page cache References: <87k123h4vr.fsf@vostro.rath.org> <874ksq4fa9.fsf@vostro.rath.org> Mail-Copies-To: never Mail-Followup-To: Miklos Szeredi , linux-fsdevel@vger.kernel.org, fuse-devel Date: Fri, 08 May 2020 18:04:34 +0100 In-Reply-To: <874ksq4fa9.fsf@vostro.rath.org> (Nikolaus Rath's message of "Fri, 08 May 2020 16:28:30 +0100") Message-ID: <871rnu4au5.fsf@vostro.rath.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On May 08 2020, Nikolaus Rath wrote: >> >> sudo bpftrace -e 'kretprobe:fuse_file_read_iter { printf ("fuse >> read: %d\n", retval); }' > > > - I believe that (struct kiocb*)arg0)->ki_pos will give me the offset > within the file, but where can I see how much data is being read? Looking at the code in fuse_file_read_iter, it seems the length is in ((struct iov_iter*)arg1)->count, but I do not really understand why. The definiton of this parameter is: struct iov_iter { int type; const struct iovec *iov; unsigned long nr_segs; size_t iov_offset; size_t count; }; ..so I would think that *count* is the number of `iovec` elements hiding behind the `iov` pointer, not some total number of bytes. Furthermore, there is a function iov_length() that is documented to return the "total number of bytes covered by an iovec" and doesn't look at `count` at all. Can someone elucidate why the number of bytes to be read from the file is in iov_iter.count? Best, -Nikolaus --=20 GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F =C2=BBTime flies like an arrow, fruit flies like a Banana.=C2= =AB