From patchwork Mon Jun 26 23:08:38 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?0L3QsNCx?= X-Patchwork-Id: 13293592 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DC2EAEB64D7 for ; Mon, 26 Jun 2023 23:08:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229828AbjFZXIp (ORCPT ); Mon, 26 Jun 2023 19:08:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229750AbjFZXIo (ORCPT ); Mon, 26 Jun 2023 19:08:44 -0400 Received: from tarta.nabijaczleweli.xyz (unknown [139.28.40.42]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EF82610FB; Mon, 26 Jun 2023 16:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nabijaczleweli.xyz; s=202305; t=1687820919; bh=iASaIQSREKLq2OFVu4k4J+TAbxohSrL+yjCExkMJmeY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bk6TKlHsfUUcFxuVbDcSAjmmsUMXwKgcojyjXMlinXZS4Q45RXGFagnjSa2Y5MRXb U/chkw+pv6FTegKkZVDpN389XaGF6+VudrsW6Z3tsbr/BQD9LRGdkxdMrrS7Em+TbS HmZ1L2pYudBMIKl6lpDQxDgG/Em/HbwUh8HneMsja0jzSo6I5ov+E5ZTM9PEmjKIAo 8TrD4E/bYehXw0LS3wzH5y82JDbZHkI2BlqWwZ+YZYBW4wOjzwDfaL4MhaozxyW/p/ n+xywt0inXLQb3nA9S+/2d5xtHxK8fiVuwOAcaq8DjPL9XnBR14SB+aCi11VSni8Bp Uu6ogLMbwAweA== Received: from tarta.nabijaczleweli.xyz (unknown [192.168.1.250]) by tarta.nabijaczleweli.xyz (Postfix) with ESMTPSA id A6EC9CFC; Tue, 27 Jun 2023 01:08:39 +0200 (CEST) Date: Tue, 27 Jun 2023 01:08:38 +0200 From: =?utf-8?b?0L3QsNCx?= To: Amir Goldstein Cc: Alexander Viro , Christian Brauner , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jan Kara , Chung-Chiang Cheng Subject: [PATCH v2 0/3] fanotify accounting for fs/splice.c Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20230517 Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org "people just forget to add inotify hooks to their I/O routines as a rule"? Guess what I did, fully knowing that some are missing in this file :) ==> te.c <== #define _GNU_SOURCE #include #include int main() { ssize_t rd, acc = 0; while ((rd = tee(0, 1, 128 * 1024 * 1024, 0)) > 0) acc += rd; fprintf(stderr, "te=%zd: %m\n", acc); } ==> vm.c <== #define _GNU_SOURCE #include #include #include static char sb[1024 * 1024]; int main() { memcpy(sb, "żupan", sizeof("żupan")); ssize_t rd = vmsplice(1, &(struct iovec){.iov_base = sb, .iov_len = sizeof(sb)}, 1, SPLICE_F_GIFT); fprintf(stderr, "vm=%zd: %m\n", rd); } echo zupa | ./te > fifo tees a few times and then blocks when the pipe fills, at which point we get into the broken state. Similarly, ./vm > fifo (with the default 64k F_GETPIPE_SZ) enters that same state instantly. With 2/3 and 3/3, they instead do 1: mask=2, cook=0, len=0, name= rd=80 1: mask=2, cook=0, len=0, name= rd=80 ... in a loop, as-expected, and # ./vm > fifo vm=65200: Success 1: mask=2, cook=0, len=0, name= rd=65200 I took the liberty of marking 2/3 and 3/3 as Fixes: of the original fanotify-in-splice commit as well, I think they fit the bill. Ahelenia Ziemiańska (3): splice: always fsnotify_access(in), fsnotify_modify(out) on success splice: fsnotify_modify(fd) in vmsplice splice: fsnotify_access(in), fsnotify_modify(out) on success in tee fs/splice.c | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-)