From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from submarine.notk.org (submarine.notk.org [62.210.214.84]) (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 0894333E36E for ; Fri, 5 Dec 2025 13:03:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.210.214.84 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764939818; cv=none; b=XwkOMEyUNugWUdVoyXHrksfdNL4v6S+LHhMaOWOcUSaEk2Kt6Z2gkRxjHkalqA6Kd6R8GlM2GQbKOBr9ET3zQKZZ53HWVq8TANOpArviUMxSjfxqQJhPF2Oe+BV0wCiyWUEjwBr2elEy50P7W9Wl8eOzwkg4zHh3lZ4wZtxTAfI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764939818; c=relaxed/simple; bh=XtuWdz8AHuFkQx1/GXeHM6qh27DbdwcY9adlxXdyGWU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ebg86U7revDO4Nm6uDJA/cG9LJFrmVhxzBSNFCa2oXXKivITUMckVSEwkCtV2zUcgqEzgnz3nQik2opNZda8nQvyXdfw0JoAvWzLKYfSQDqvpMu4k0rY6/pyAKu3NM8XxHD2xOvxnnt3rgLPVA74X4fHxQL7Tx0brsRRalcBPZU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codewreck.org; spf=pass smtp.mailfrom=codewreck.org; dkim=pass (2048-bit key) header.d=codewreck.org header.i=@codewreck.org header.b=gStmT76y; arc=none smtp.client-ip=62.210.214.84 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codewreck.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=codewreck.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=codewreck.org header.i=@codewreck.org header.b="gStmT76y" Received: from gaia.codewreck.org (localhost [127.0.0.1]) by submarine.notk.org (Postfix) with ESMTPS id 0DE1314C2D6; Fri, 5 Dec 2025 14:03:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1764939811; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TUNVS0bls4aKtIYkswtFnDfA4LZUtSduPNksf9xgN7c=; b=gStmT76yQzNqHO05tyVvcERDCuE1QR4zX8QSV0msqXAfp2/tKBFOOyoZcQiVlDgVpxqYE4 j3cWfD26jH+OgThJhiY89ajcu/NWQnnB4kCf7Iu3Htv1xSstoOO+0rezj0+HWq45uroKg/ hJ3ZhfFT/q2te1c2wbRos3dIkMJF4010DB6YuAZRPIPE6iJdmPmmINDOWgJJ6rqphNrY9Z LC9i/DPz1qNLRhOlCjJvEG01eED2ERT9noD1gDrVST378vb0/YFAteFihzu3gVLJps4NNT QrRz1TvCYGeI5VJ3Pp6tgs9lt3S2xjxN2fnFI5TOpRCxzuTRF42R7fWu/E9pVQ== Received: from localhost (gaia.codewreck.org [local]) by gaia.codewreck.org (OpenSMTPD) with ESMTPA id 980155cd; Fri, 5 Dec 2025 13:03:27 +0000 (UTC) Date: Fri, 5 Dec 2025 22:03:12 +0900 From: Dominique Martinet To: Christian Schoenebeck Cc: Matthew Wilcox , Chris Arges , David Howells , ericvh@kernel.org, lucho@ionkov.net, v9fs@lists.linux.dev, linux-kernel@vger.kernel.org, kernel-team@cloudflare.com Subject: Re: kernel BUG when mounting large block xfs backed by 9p (folio ref count bug) Message-ID: References: <5945634.DvuYhMxLoT@weasel> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5945634.DvuYhMxLoT@weasel> Christian Schoenebeck wrote on Fri, Dec 05, 2025 at 11:47:10AM +0100: > > Oh, hang on. You're passing a kmalloc'ed page to > > iov_iter_get_pages_alloc(). That's not allowed ... > > > > see > > https://lore.kernel.org/all/20250310142750.1209192-1-willy@infradead.org/ > > I'm confused. Looking at p9_get_mapped_pages(), iov_iter_get_pages_alloc2() is > only called for user space iovec data, isn't it? I think that doesn't hold true when mounting a filesystem with -o loop -- afaiu the kernel issues IOs to 9p from the XFS subsystem, so these can come from kmalloc or whatever it is they get memory with. As to what to do with this, given Willy's last reply (thanks!), I'm honestly still not sure... If we can detect the pages are coming from somewhere we don't like I guess we can return EIO instead as a stop-gap measure (better than a crash)? If we check early enough (in client.c generic code) perhaps we could route these to the non-zc path that doesn't require this, so let's start by trying to figure out how to check what kind of page we got...? -- Dominique Martinet | Asmadeus