Received: by 2002:a05:7412:251c:b0:e2:908c:2ebd with SMTP id w28csp1720750rda; Tue, 24 Oct 2023 00:45:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFYu3A+NSjTluJNRv0fNrPvlAZ9zwfgV8FdmCF5+ci5xzyWZnBkGD7E+7Is10YLEfvTXd8/ X-Received: by 2002:a05:6870:10d4:b0:1e9:cdad:4903 with SMTP id 20-20020a05687010d400b001e9cdad4903mr10705013oar.50.1698133550951; Tue, 24 Oct 2023 00:45:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698133550; cv=none; d=google.com; s=arc-20160816; b=zvpidetGe/yPBt4R27yiP4nwPF3IB+BYwUdzKFvJ8RD1qChrJuq0BF68Wd78VpUXOy 6QJ51ZUGhDeXpG/GjoT6ZwBdCM5JLc9ScoiynjCjT4t1hFmuwfUjW1avGTR0lKHNo3jX 7FSQWMzUVoLPPRGXuh9g5UHh5GPAs5vObYFZQ2ziOd3C0SDViCvXrVTt/+iUrAZ0KEtQ 1ZZ0DzuCrwXwwFqwYRBMR+bHxpCYSLFw/Rt25HNus8WBxUc/RUiZoQFmFtxjyunDPLhk e70U/lKINB2HJyH1Ul5gVloLJK7CPnmEHwfYOr6xvkcrR9CNwnWHW4H+gteUxxwioCvo xxeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=k4l5me87UyJdn/SX3+43Lrzcu2MLLMcAwllwxSbsoL0=; fh=sdBEOM3OJNenMRZzpN8Cgk8SCZZsLv9GFgBogi1hdJ8=; b=e2mOvgIKvvn90TBqGStLiFdxvZHVs36QpTZmOVaKKFNpluwmeGBJmiU2/sod/FtK5S O/v2VjISnHmdaAJDrYQthJZLQzRRrAHu6HrG/IbW+c4Clvlm5EUQQVtoLBShlIdQuilJ cUwDmgx+XisXBu8Joj8UHN+W9vp6Q8sdKybc/lfGVB5S+rbT56AgpZ6pb3C+MsfOGmWz lPkJCcOkBBJiI8oKdiLsqAD+6zP4oUsfgBZRczWMb8CsoKGEogDhfJfVb2rxb+LUeoBN Zrx7hbHFrO8MnLP9nGXZhLDBHiYcaAGGk1LvFZC2GwvYjmTzL14rxDASgAEevgNVT0wp xeMg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codewreck.org header.s=2 header.b=FRMXYCL1; dkim=pass header.i=@codewreck.org header.s=2 header.b=mhie8GGa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=codewreck.org Return-Path: Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id bf20-20020a656d14000000b00578e0ff59bbsi8086771pgb.865.2023.10.24.00.45.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Oct 2023 00:45:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@codewreck.org header.s=2 header.b=FRMXYCL1; dkim=pass header.i=@codewreck.org header.s=2 header.b=mhie8GGa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=codewreck.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 21653807C6F8; Tue, 24 Oct 2023 00:45:07 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232834AbjJXHo6 (ORCPT + 99 others); Tue, 24 Oct 2023 03:44:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59306 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232399AbjJXHo5 (ORCPT ); Tue, 24 Oct 2023 03:44:57 -0400 Received: from nautica.notk.org (ipv6.notk.org [IPv6:2001:41d0:1:7a93::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C7F390 for ; Tue, 24 Oct 2023 00:44:54 -0700 (PDT) Received: by nautica.notk.org (Postfix, from userid 108) id 1EF4DC01A; Tue, 24 Oct 2023 09:44:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1698133493; bh=k4l5me87UyJdn/SX3+43Lrzcu2MLLMcAwllwxSbsoL0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FRMXYCL1ONRet6xf1S6S/t0zwHlnGOaCPs4CYFx5kB0LoazOW4F6REOQl8l2fB616 r2bwacwcgypStortzUEdhXjaY6XhGO+8DkL9IqKDeeNEeUNli5bj658KNoFlvA+pCi obzVRS/t631F6wp32LPljZylSpTtjhwu20H3eBEfs1qLLxCKX7G3rH6KeqJPlBI9hJ SCQzXS7OJvHvpDfmqeQadY9U8fGha3AL3+zE0/DZoEwzxKOtmqtY692874+EdvpvIi MHNW1o3jkLW+73Mkw/DPGKHirca8nzCCque+dirUwLivgqsKLgaB+nJeM83Ar/L4RZ ROWLE9HHJB6TQ== X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 Received: from gaia (localhost [127.0.0.1]) by nautica.notk.org (Postfix) with ESMTPS id 4627DC009; Tue, 24 Oct 2023 09:44:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1698133489; bh=k4l5me87UyJdn/SX3+43Lrzcu2MLLMcAwllwxSbsoL0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mhie8GGazbK3MRGH2L88sLZ6+aAAOdoS3Rf+xMuEdA8oWKJhSY+3TWN5rIb+haARI Z2sG67rpjvZdKg3p4qsCIYX5Gn3IQx1Uu4rLnxhN2EiekdveDjKrk1R76BDyefPAjG DdN7AREO8nPtb5J88i+BMEjZUgI981s12mMixYVReh1GEaPyGQvezaNg1UE4Mqo32+ Ef0RaAOj13naAxrogh7oUpVzkJtM83opsU9rG6jxnXfwmJWtC82aQPWFUR0XJ0P12w f+MO1DO/W/MmLcrvvc+dScpIHSrN0O8G5sHGI/YFf9DQlkuLqOsgqYGzL6SYO0HdqP NQL/v4zICGoSA== Received: from localhost (gaia [local]) by gaia (OpenSMTPD) with ESMTPA id 8d12950e; Tue, 24 Oct 2023 07:44:44 +0000 (UTC) Date: Tue, 24 Oct 2023 16:44:28 +0900 From: Dominique Martinet To: Marco Elver Cc: v9fs@lists.linux.dev, ericvh@kernel.org, linux_oss@crudebyte.com, lucho@ionkov.net, linux-kernel@vger.kernel.org, syzbot+e441aeeb422763cc5511@syzkaller.appspotmail.com Subject: Re: [PATCH 1/3] 9p: Annotate data-racy writes to file::f_flags on fd mount Message-ID: References: <20231023233704.1185154-1-asmadeus@codewreck.org> <20231023233704.1185154-2-asmadeus@codewreck.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 24 Oct 2023 00:45:07 -0700 (PDT) Marco Elver wrote on Tue, Oct 24, 2023 at 09:12:56AM +0200: > > diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c > > index f226953577b2..d89c88986950 100644 > > --- a/net/9p/trans_fd.c > > +++ b/net/9p/trans_fd.c > > @@ -836,14 +836,16 @@ static int p9_fd_open(struct p9_client *client, int rfd, int wfd) > > goto out_free_ts; > > if (!(ts->rd->f_mode & FMODE_READ)) > > goto out_put_rd; > > - /* prevent workers from hanging on IO when fd is a pipe */ > > - ts->rd->f_flags |= O_NONBLOCK; > > + /* Prevent workers from hanging on IO when fd is a pipe > > Add '.' at end of sentence(s)? I don't think we have any rule about this in the 9p part of the tree, looking around there seem to be more comments without '.' than with, but it's never too late to start... I'll add some in a v2 after we've agreed with the rest. > > > + * We don't support userspace messing with the fd after passing it > > + * to mount, so flag possible data race for KCSAN */ > > The comment should explain why the data race is safe, independent of > KCSAN. I still don't quite get why it's safe. I guess it depends on what we call 'safe' here: if we agree the worst thing that can happen is weird flags being set when we didn't request them and socket operations behaving oddly (of the level of block when they shouldn't), we don't care because there's no way to make concurrent usage of the fd work anyway. If it's possible to get an invalid value there such that a socket operation ends up executing user-controlled code somewhere, then we've got a bigger problem and we should take some lock (presumably the same lock fcntl(F_SETFD) is taking, as that's got more potential for breakage than another mount in my opinon) > The case that syzbot found was 2 concurrent mount. Is that also disallowed? Yes, there's no way you'll get a working filesystem out of two mounts using the same fd as the protocol has no muxing > Maybe something like: "We don't support userspace messing with the fd > after passing it to the first mount. While it's not officially > supported, concurrent modification of flags is unlikely to break this > code. So that tooling (like KCSAN) knows about it, mark them as > intentional data races." I'd word this as much likely to break, how about something like this? /* Prevent workers from hanging on IO when fd is a pipe. * It's technically possible for userspace or concurrent mounts to * modify this flag concurrently, which will likely result in a * broken filesystem. However, just having bad flags here should * not crash the kernel or cause any other sort of bug, so mark this * particular data race as intentional so that tooling (like KCSAN) * can allow it and detect further problems. */ Thanks, -- Dominique Martinet | Asmadeus