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 D0D17C3DA6E for ; Wed, 3 Jan 2024 13:10:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5D19A8D006A; Wed, 3 Jan 2024 08:10:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 581368D0061; Wed, 3 Jan 2024 08:10:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3FB138D006A; Wed, 3 Jan 2024 08:10:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 29E838D0061 for ; Wed, 3 Jan 2024 08:10:44 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 07097A1BF7 for ; Wed, 3 Jan 2024 13:10:44 +0000 (UTC) X-FDA: 81638034408.07.55BAF94 Received: from nautica.notk.org (nautica.notk.org [91.121.71.147]) by imf23.hostedemail.com (Postfix) with ESMTP id BFCF1140009 for ; Wed, 3 Jan 2024 13:10:40 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=codewreck.org header.s=2 header.b=DSU2cI4s; dkim=pass header.d=codewreck.org header.s=2 header.b=alfUp47L; dmarc=pass (policy=none) header.from=codewreck.org; spf=pass (imf23.hostedemail.com: domain of asmadeus@codewreck.org designates 91.121.71.147 as permitted sender) smtp.mailfrom=asmadeus@codewreck.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1704287441; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=nNLSz3IQyDfOhUPqR/BsW6lP6xUFuUzC9P2KcyoDIGM=; b=L2hQFXSHcz5o3LhGQ3qbOukIXoZwgwSe/jktQdqtEZh3raAyzmRtXVXNJUFhk+glIWELj2 14EV/qnm/CT9ciO4kkTcSzVLmVuD2/sdRgT41DpTtEdBrm9ON4cHQWAx9OxkMe76S3PCsx Pp8yCM2S99FJ0rMHLoT66l8K9SyD4ak= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=codewreck.org header.s=2 header.b=DSU2cI4s; dkim=pass header.d=codewreck.org header.s=2 header.b=alfUp47L; dmarc=pass (policy=none) header.from=codewreck.org; spf=pass (imf23.hostedemail.com: domain of asmadeus@codewreck.org designates 91.121.71.147 as permitted sender) smtp.mailfrom=asmadeus@codewreck.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1704287441; a=rsa-sha256; cv=none; b=EsEZzDQz4aDYj0aFHhWP9UOnaInE1EiX8ofSV+us8qAIJZOg2TaBFrQJfTh3iaN/6DReYZ ttpqTAbebCMxk2zjbsCKODJL8UxNEGTGMeyiVnknsJtbLDATkYZ2QAH7k9Wuet1xn3jw37 gt1hUT00dgPUVHnBo7uLst0kDO5Bbd4= Received: by nautica.notk.org (Postfix, from userid 108) id 01D6DC01B; Wed, 3 Jan 2024 14:10:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1704287439; bh=nNLSz3IQyDfOhUPqR/BsW6lP6xUFuUzC9P2KcyoDIGM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DSU2cI4sZf90qwRfnaXnznL7jIlbzmSuznoRXPqYlvafbrPQAEpuqVf2EctFivLL6 EqQN+rDFO5kMoPHxJsvZDTAz+FJnuG+NOehkLZUbpCJ0tUKQkB28Zcwxm9l8ssujoS fcA25Qoqq4QAUxL+lAcgNB9Sx3uClqJlcs8e3viPQhl3m7Dq4oc/c1qVCCzJ0KfxLs ZqQs6Cabvh5jwJE20Pl5v9/8uuZxvuSewqEme5RfqMfM0x7Ec3a29K9sH3O92lMCvt /X30sNmyGkn+YL/BiQ2P2XJBodDL6HyR4c3vIyS+H7XbWYfYTW2Ni9mPC9/JdzWIbv qNaDmmKbdA6bQ== Received: from gaia (localhost [127.0.0.1]) by nautica.notk.org (Postfix) with ESMTPS id A1D64C009; Wed, 3 Jan 2024 14:10:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1704287438; bh=nNLSz3IQyDfOhUPqR/BsW6lP6xUFuUzC9P2KcyoDIGM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=alfUp47LcXS8Qn3+pM3575baz2IlmljGvcJijYZ9Gud9tjALEz1+mys8tps/nOpEs 3l1lyYmuJdM0qPObSIEky+UOMT/TorZQ56huXodWvki8aQnQXO7yZ0uBLQSa7pOD1t 5SyVGBURpK+D8S7dKO9j2yjtif7k4yrKlPi7+9WDUwkil5dcygJciP5lVbS/leQz6d Lg/0Ri3BlT4O7FYFqnkqSzJ6nN8gMb65wTuW8kwop7fUFl3eXZM/I4SkkKSKowIeJB a9FdxA4xJ9MPVFG92oNtP53beEe2cJg9l6m92bTZnVgUcigZLYpFkHAU6WrBAXePZb 04dlr6Z5i13vw== Received: from localhost (gaia [local]) by gaia (OpenSMTPD) with ESMTPA id 861cbe98; Wed, 3 Jan 2024 13:10:29 +0000 (UTC) Date: Wed, 3 Jan 2024 22:10:14 +0900 From: Dominique Martinet To: David Howells Cc: Eric Van Hensbergen , Latchesar Ionkov , Jeff Layton , Steve French , Matthew Wilcox , Marc Dionne , Paulo Alcantara , Shyam Prasad N , Tom Talpey , Ilya Dryomov , Christian Brauner , linux-cachefs@redhat.com, linux-afs@lists.infradead.org, linux-cifs@vger.kernel.org, linux-nfs@vger.kernel.org, ceph-devel@vger.kernel.org, v9fs@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Christian Schoenebeck Subject: Re: [PATCH] 9p: Fix initialisation of netfs_inode for 9p Message-ID: References: <20231221132400.1601991-41-dhowells@redhat.com> <20231221132400.1601991-1-dhowells@redhat.com> <292837.1704232179@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <292837.1704232179@warthog.procyon.org.uk> X-Rspamd-Queue-Id: BFCF1140009 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: z5ok8ctn8gogobtpbzwfahy1ncdn4eop X-HE-Tag: 1704287440-103132 X-HE-Meta: U2FsdGVkX1+TKpXYub8SUDaTHbeV861XAV9bsUsllDffds5FkZXVn57kT/x4MGE1Jaj0FCmOQYq/j9ZxSQidDngcEftimSq1KKGEDHQFyoWwYL0gEWJlJf67tmd6V1VP1e30nzkcxEk1seH0LaL17O0+Jdy5ZLT6W2uzrZa4URbRXehW9smX0ZR3HSlQVPWjFUTmbOHIuIaLZujwhd2t0ko8O4ufEu0nczNUmVlh63MtOuRMfGe84ZHgyYe1Cwbz7AgTM4shmbdH2hC4BnW5nrM73s2/WJUTBtNwCv8LcLW6dSKjkzclaG3k2Q/j8bgqkSny0oF0eHUO3j6qkIVCmcJVJ2ks+jDrjNyaFG15hG6Vaar5kRHQnR40IOuH+dw57uSPY7BuHRwgcYODgPxsvivGiOK/iknF6joTKqYD+66d+eO1x6cYlNj6ZWhvZ9/QLiJd53g5NO1m8AGPbq4HwQqR+0k+xtDvP6EnPQ7feDdJhdsza5XlLtygPCZE9xOO6u9J37X/k9ffa3Quy4R4XhXWO7m7w4ix8NimX6tgVcAUy07rLFiomxXj/jaavYVA5Mn1tut2A7M7G+QRwwU5VmyZPssSkczLry2oLtBmOBJw4UNElWtP2RtLfu8uNga/CevxGpFkeI2fK4fgk70GNsb6m4MR/3Z/gLzO/RjtMtFbBHPJad6ciX60h/WOSXIywP8xPCbuENX1uBiuWIoC8QC63AGvtD1iGqZMrB11sIrI94eKm+LHs8hluyvV+qAJQeMqnuECW3sq+Ytu/QPkXcT8XmMaBd9XWrSRQZz2QgOpVqiVHbdgH8cbiNlpqKtZ4ChRYtfuqdMvuGaF+X38V9H1yDqAFcwUfV8D2rlD+6fIMjzzKCiGKY/dgBNTe+uQ0YoMsSsZrLaaUJMQV/PX4LbqOSFRjuOeUW7XsljHXA2cdRVnRPAT6ceaB8ZN7NJSpbqHJ61OXBnZUZv4Wm9 gFLIJaEC 5gfFyXA4N48+C+9NvwWQ1oNtjWlO4jJRswFWYKv2ahaC0dd2m6woYPdxoc4wXYXWLxM4JQbQMl3qNJEtZqtJ8+EeqOh+SB+VawDMEqsV8G1TSNJrzmUAwIqgEGoEYSnowzfz05X/RoVA4PNWbiKosKpmK2boKpn6zwish7Qx8G5wdwIOV5WaAwCNLDtPLu0pN/RWe65k+QfnA7ESEJq5MtlOxQIJTx09ks9oDADt7BFZvINEaFG1AqYoK9RfI+sPgAv2O/A5SpCH9uJr6bOFHc3ukMBB6tIXsMCdKirNkzBvz9Xbrk0wvmiURl4yAD76QJIQCayR+61xWDh9METvrEQ2UdE9kWv65AlD5G2Clzn0Jf2s/IjlTjFREAL1v1PtzEZrxflIDC0GMueHHZi7EZbd9G3cLgGuX+BkBSjW7oohADNNa2I3Z51PzPp6zUQP5IE0qXBRHaojDOPZdmA4TbtGj+cjqH2SS7fnq 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: David Howells wrote on Tue, Jan 02, 2024 at 09:49:39PM +0000: > This needs a fix that I would fold in. Somehow it gets through xfstests > without it, but it seems problems can be caused with executables. Looking at a file without that patch we seem to be reading just zeroes off pre-existing files; I'm surprised xfstest doesn't have a write something/umount/mount/check content is identical test... (You're probably aware of this, but note for others this breaks with the rest of the patch series even if the big 9p patch isn't applied -- this is the main reason I'd rather just get the patch in this cycle, as the new patches got more tests with the full series than with the 9p writes patch dropped.) > 9p: Fix initialisation of netfs_inode for 9p > > The 9p filesystem is calling netfs_inode_init() in v9fs_init_inode() - > before the struct inode fields have been initialised from the obtained file > stats (ie. after v9fs_stat2inode*() has been called), but netfslib wants to > set a couple of its fields from i_size. Would it make sense to just always update netfs's ctx->remote_i_size in the various stat2inode calls instead? We don't have any cache coherency so if a file changes beneath us through an edit on the server (or through another client) hell will break loose anyway, but stat would update the inode's i_size so it'll likely be weird that the remote_i_size doesn't get updated. > Reported-by: Marc Dionne > Signed-off-by: David Howells > Tested-by: Marc Dionne > cc: Eric Van Hensbergen > cc: Latchesar Ionkov > cc: Dominique Martinet With that being said, it seems to do the immediate job: Acked-by: Dominique Martinet -- Dominique Martinet | Asmadeus