Received: by 2002:a05:7412:da14:b0:e2:908c:2ebd with SMTP id fe20csp2260069rdb; Mon, 9 Oct 2023 20:06:38 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF4t1R+rmfW8UlJm82T6SbCxFidcK9+U3iji3I0D412rwjcCWp5T1MKZjzBAkgdzgWK+bLW X-Received: by 2002:a05:6808:14c3:b0:3af:cc6f:c691 with SMTP id f3-20020a05680814c300b003afcc6fc691mr13454180oiw.58.1696907198401; Mon, 09 Oct 2023 20:06:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696907198; cv=none; d=google.com; s=arc-20160816; b=Nn42e0tK+YqNPgdEG0icEaKoKR9AifwAMJ4+HXaI3i9uXWd856sP9TBzdminBx1EC9 7gpXXi7ndEHagG4AS78THy+jIMeoHi/jkre/eKlac9YzCSm07P9Gb7ia0iDmxK9UJWvW Mt+qSvyDcgxC+fSQQzDN55+rkerx5P1N86/Q4h4voTz8XOvh0uvbZP3CsKoavhWbtSKb 8Phb6KncTpeKq9jaJ3kMpspnz+/EbhXgvxTJJ/OMzUvYgBa3PHh2yiZK3vOWaWJxoF1u c5X36qGhdU3nrBeiffcjSw7yy5CHShTnG7PATwblhsV6/PAS+dSoUkb19P4HF0XvQ/t2 kTCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=hF6lxVQ6evFyYtVvJFpE2W9il5nQR1vSVTE2wQU1M+E=; fh=nJqzpT+D//fbk+uNxTbLoMivYkuM+awUOyH6du8N3C8=; b=C1qgEPI+3pSYmb09nzic3rB+6R5C0QwKysTz9XC/JZqM8ednCOeG9djNro8AbUNJdO iTYO8e59DtS7uqYirV5guATJ53PoWiLKSFoGOSUtmyfFLgqIt4FA8yDJJruk93KbLtQI E59U61TZ5eHtAEhEkGRUWU1RM2ChliQCbq+9ra7HwsdbapPLqCDjmYseHLyfZQ/AXLr/ w6GUbHLkXgLAYcwvmPcIsAw/VaTEi23plzudJ2RKei9bc4sksuQZJrU173BLWmTa45qr pf+dy3hO3uwIsNAozmbdxMeIiOaFJaL2viflR3iWwZxXPUIz8nfjK5/3nsMlQMSYXUg9 /a+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.org.uk header.s=zeniv-20220401 header.b=sjm4RXMQ; 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=zeniv.linux.org.uk Return-Path: Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id r20-20020a6560d4000000b00563d74b6347si7712100pgv.863.2023.10.09.20.06.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Oct 2023 20:06:38 -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=@linux.org.uk header.s=zeniv-20220401 header.b=sjm4RXMQ; 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=zeniv.linux.org.uk Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 3EC718057945; Mon, 9 Oct 2023 20:06:35 -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 S1379409AbjJJDGY (ORCPT + 99 others); Mon, 9 Oct 2023 23:06:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47326 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379418AbjJJDGX (ORCPT ); Mon, 9 Oct 2023 23:06:23 -0400 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EFA56A7; Mon, 9 Oct 2023 20:06:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=hF6lxVQ6evFyYtVvJFpE2W9il5nQR1vSVTE2wQU1M+E=; b=sjm4RXMQC9BX+t3FrdU+ybykLB hB4kmCwo9bGy1ANj+ODkBbFPUfdViapCTdyJdTGgL298Y9pATXcuwbDEajLydZ8X4otoOSbcYTnyt 4IVYnAmNmP1HL+fSbQqNlWmT8F3W5+1h2LuwUoARQl10vogTHNUsoF3Scq56Pm7bYCGj+GdYEsnl8 tTUNP02hJGBoBMyqEslY2QoQ0soESE0PTTqlGs/IFLlY/yu14rU5uOQzQvaSViMAgmr9CCoza0SkP 3g3tAJI/uyax2g6ICO6jRXRnnD+2dj0AqRek9ed/yXJdREl+8OvDJYSCSDtU8wOMqCkkaNUTdBoL/ Qdi2MXtw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.96 #2 (Red Hat Linux)) id 1qq34Z-00HPj4-2Y; Tue, 10 Oct 2023 03:06:15 +0000 Date: Tue, 10 Oct 2023 04:06:15 +0100 From: Al Viro To: Christian Brauner Cc: Linus Torvalds , Mateusz Guzik , Jann Horn , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2] vfs: shave work on failed file open Message-ID: <20231010030615.GO800259@ZenIV> References: <20230928-themen-dilettanten-16bf329ab370@brauner> <20230929-kerzen-fachjargon-ca17177e9eeb@brauner> <20230929-test-lauf-693fda7ae36b@brauner> <20230930-glitzer-errungenschaft-b86880c177c4@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230930-glitzer-errungenschaft-b86880c177c4@brauner> Sender: Al Viro X-Spam-Status: No, score=2.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_SBL_CSS, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email 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]); Mon, 09 Oct 2023 20:06:35 -0700 (PDT) X-Spam-Level: ** On Sat, Sep 30, 2023 at 11:04:20AM +0200, Christian Brauner wrote: > +On newer kernels rcu based file lookup has been switched to rely on > +SLAB_TYPESAFE_BY_RCU instead of call_rcu(). It isn't sufficient anymore to just > +acquire a reference to the file in question under rcu using > +atomic_long_inc_not_zero() since the file might have already been recycled and > +someone else might have bumped the reference. In other words, the caller might > +see reference count bumps from newer users. For this is reason it is necessary > +to verify that the pointer is the same before and after the reference count > +increment. This pattern can be seen in get_file_rcu() and __files_get_rcu(). > + > +In addition, it isn't possible to access or check fields in struct file without > +first aqcuiring a reference on it. Not doing that was always very dodgy and it > +was only usable for non-pointer data in struct file. With SLAB_TYPESAFE_BY_RCU > +it is necessary that callers first acquire a reference under rcu or they must > +hold the files_lock of the fdtable. Failing to do either one of this is a bug. Trivial correction: the last paragraph applies only to rcu lookups - something like spin_lock(&files->file_lock); fdt = files_fdtable(files); if (close->fd >= fdt->max_fds) { spin_unlock(&files->file_lock); goto err; } file = rcu_dereference_protected(fdt->fd[close->fd], lockdep_is_held(&files->file_lock)); if (!file || io_is_uring_fops(file)) { ^^^^^^^^^^^^^^^^^^^^^ fetches file->f_op spin_unlock(&files->file_lock); goto err; } ... should be still valid. As written, the reference to "rcu based file lookup" is buried in the previous paragraph and it's not obvious that it applies to the last one as well. Incidentally, I would probably turn that fragment (in io_uring/openclose.c:io_close()) into spin_lock(&files->file_lock); file = files_lookup_fd_locked(files, close->fd); if (!file || io_is_uring_fops(file)) { spin_unlock(&files->file_lock); goto err; } ... > diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c b/arch/powerpc/platforms/cell/spufs/coredump.c > index 1a587618015c..5e157f48995e 100644 > --- a/arch/powerpc/platforms/cell/spufs/coredump.c > +++ b/arch/powerpc/platforms/cell/spufs/coredump.c > @@ -74,10 +74,13 @@ static struct spu_context *coredump_next_context(int *fd) > *fd = n - 1; > > rcu_read_lock(); > - file = lookup_fd_rcu(*fd); > - ctx = SPUFS_I(file_inode(file))->i_ctx; > - get_spu_context(ctx); > + file = lookup_fdget_rcu(*fd); > rcu_read_unlock(); > + if (file) { > + ctx = SPUFS_I(file_inode(file))->i_ctx; > + get_spu_context(ctx); > + fput(file); > + } Well... Here we should have descriptor table unshared, and we really do rely upon that - we expect the file we'd found to have been a spufs one *and* to have stayed that way. So if anyone could change the descriptor table behind our back, we'd be FUBAR.