From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 68049623; Sat, 16 Nov 2024 07:36:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.89.141.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731742590; cv=none; b=DQ3GRTMUUudbON/1qImU41EuSQ3Qqqo7a5qui4yYOOJ9eY+pfqL8pmJ3nfJloLGHoUZTHZtPMiN5t8zsGD47lNlXW8iDUwjRcctG8XRHv4Y0UmsUCBDwspnCtp0xFTchl2sCEURMuso6bmebqwyGO+M9HeBV5daPiQlrUsTjTFc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1731742590; c=relaxed/simple; bh=eSIBqLw5ITZcBVih8LlOKK0kL6QSdZ6ENa98r9EuKvs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uEcvrINjAx5U1k//RdC4fn+4ubfA9Fs6jzaVP2UNv47ESwotaQEIOyNVJOdlHko2IS6nn3pP7Gh1scmd5U5js3prsqLKdJuD/jkFB4TK5n9LoXsu4XMprSoqRaHsO7EGyzG5JdgffmqW1CIiZ6qohWKfZ4YnChxkV0qcYk6qtkQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; spf=none smtp.mailfrom=ftp.linux.org.uk; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b=wiCkDQN8; arc=none smtp.client-ip=62.89.141.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="wiCkDQN8" 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=/lKdD+J6EbfQ0em/GnQ6M9gqMoAuoEq5muwgPpFMxgE=; b=wiCkDQN8+jBDIjY/HpSYr4fXHe AYi1PcXbr+GOKRyee1bG8G/PHMKqGcVtMg0KeSv348pWip6R+mGMyB9VD5NQRetvGyTZpokvhK4pl HNyHrH8yvTXldeMMofO/a0yeLT3pjEK9k5cZmXT6Sn2S1+qdHYzD+xIVXOn2Hehwsh98GQpI2OtuT 9bXol3i04Ss9YF+Er6awjyeBE+a6YmvM+aaKvMg5pGgWNaSAaOAGA/vufenvRoVnjmgTbVpB2UEQa 96oJ2ihHQu84NS/I8YaSwTpAgC2KEnHJEaioBWLa3aQD9SyObUVO/Zm/Dt2MOuH8WwjtJcCk1kBWx SvIfII8g==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.98 #2 (Red Hat Linux)) id 1tCDM2-0000000FhK2-1nvZ; Sat, 16 Nov 2024 07:36:26 +0000 Date: Sat, 16 Nov 2024 07:36:26 +0000 From: Al Viro To: Mateusz Guzik Cc: brauner@kernel.org, jack@suse.cz, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] fs: delay sysctl_nr_open check in expand_files() Message-ID: <20241116073626.GB3387508@ZenIV> References: <20241116064128.280870-1-mjguzik@gmail.com> Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241116064128.280870-1-mjguzik@gmail.com> Sender: Al Viro On Sat, Nov 16, 2024 at 07:41:28AM +0100, Mateusz Guzik wrote: > Suppose a thread sharing the table started a resize, while > sysctl_nr_open got lowered to a value which prohibits it. This is still > going to go through with and without the patch, which is fine. > > Further suppose another thread shows up to do a matching expansion while > resize_in_progress == true. It is going to error out since it performs > the sysctl_nr_open check *before* finding out if there is an expansion > in progress. But the aformentioned thread is going to succeded, so the > error is spurious (and it would not happen if the thread showed up a > little bit later). > > Checking the sysctl *after* we know there are no pending updates sorts > it out. What for? No, seriously - what's the point? What could possibly observe an inconsistent situation? How would that look like?