From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8066E422542 for ; Mon, 27 Jul 2026 17:38:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785173900; cv=none; b=BfyqoTEXcHpiDqU91cmOJUY0lkcfXna9YluCeab1pJwIlOOVkjGnTdDnVB8YWyy8akqWfdgjpk6raE0B6/XaO9SkH/SovgpUfJxm0O9JkCaiRjJxObXfX2SfeU1rVBmgedsOtZTFrR5r9yUeChZkflU5X/E2jYUfexGoPQjFd08= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785173900; c=relaxed/simple; bh=VQZ5fYCTvFa/9SbOtkKSyxVz2+Ca7PXXAQlKjpRfnbQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CFP9hK7BWwjolhRGbp3NpCI8nkuX83r+WL+CgrbOdlnNTPb1Bmla0el0Lhrwnue5kNB0D4Jh46IvWJPHxi7Us+t+ChIw8+3QhUTCDk+Mc/T+yAwKxv4UYqk3ZLFixbeI145EnMAui5tmnJnZtKLRxKEYeR+qy10AHygjG3cRRjQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=eeavKU8P; arc=none smtp.client-ip=209.85.160.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="eeavKU8P" Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-51c10ed63c0so16731cf.1 for ; Mon, 27 Jul 2026 10:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1785173898; x=1785778698; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to:content-type; bh=Xc8RNpA5Jhta+/kmas/o+hbP+ADTzC+07ggHCpEs+UA=; b=eeavKU8PKkLA6fzj2S4nXhBeYHQuvgfuYpM8Yc5HgXiKbRMOlu4c3LGXF25XQ6EW3w YgeMbcZRd0Qz46v3pTgTPWJN235g4O55EnCGwIBEvmBldjUtbZ6ME78MnrVyRJdvNPi0 DiU9K1/jvZ1MD5Z2lvb/0JgAtCbl3e1Y4oYiBk9ZscqjYvux0ODq/si2qpa2qIHVAdQf DbxsbadUWR914V3FuYp+EkwhkRR2K2H7enaDa1TkRNckXEae1BNNjLzm7tG6xpOJwFLw 1FlVZKZGmLjPSEDYS1UDiiBPqcvIHbav1l2x9N7sZXwkXhi7nQIHmcVm9PMHesMExezJ qDxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785173898; x=1785778698; h=content-transfer-encoding:content-type:in-reply-to:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Xc8RNpA5Jhta+/kmas/o+hbP+ADTzC+07ggHCpEs+UA=; b=bC1R4CIX378LNr4Yb8IzKjBrwd2D23eFF0xjmACadwYdLYbbw06t//J6yfS2E0duQG zZAvC9OqFfr1XxQfI2DX1OnWLy8bG9On77+8FDG7qW16uW269iwoUl9ryN4kG8dzVMx1 EaHjzRwdxCL+3NoImCzhI5Yd5XZbGvnGfUb5t0xamALvPN9RG5+6eBAmn+csNWhc/q4V 17Tvzdd9QAmNnLJM+BdqImWpflLmngjZzh+dbG/DSXnN4EAFp11C0PYwI0gQOSOMr+G/ 65KhYAxI8dOHjfx0NcXeenTtPRRfOoQ6nXw7qxjDx1jsxWqkIP4tuZW2FwJ0VDbfL4iQ eslA== X-Forwarded-Encrypted: i=1; AHgh+RrBYFVz6/pRGICWvPhjGdANHgwB4S3X5pCE7Pgz11Cgd3tsunJkuUu2IMJHPhA43KMwKDctg6d/pMV8gtA=@vger.kernel.org X-Gm-Message-State: AOJu0YxqRJJpqagMilk1hsCT9dN2GF6J5Bjdv6QKJPbbE9f1V0RbaIrE TCL74ZHtTrd9gLnqhm9c0BvYDOCvaBHwLX8012t1g+2GCdvZvnwSvHZACVKkzOIHYw== X-Gm-Gg: AR+sD13z+VVoXfG6aT2LNAa0JfVQBDg7/33uPIFa4I7R028ZlaAInz3JRUmcVPIkfB0 sRjaVsRpyJ0zUv8rwARS/mE3AeKndYxpU3eKPZEHOUPSFurwzWTwm7EtHdJk+XAnJSpbdmQ66F+ zpmsr6eNYTtwPkis7XQe9CjDoF1IYTRA6qiMzj20in1IMT0XrVkpYqSOOQZYprC0jX34ZbQyLSK bh++6vva19KdsSjVUbaGV5zDArPUQVV/eBQts5TmuSJocBhy53CmaYX+yB2ojYUoq5b5oGjZBbI DZGNCxrw3Q0s1oOMc8JBMbhn85+xjqvCuHjSN8TZ9FZ7F7khRJWt6A6FJV0VLu6q0F1mjIT4Jb/ 8V1QbCpBrBhs1hMWIp5yFOKyxrCCVtb634fjkh+RaWxyezluryYcX7cZXbtPg6Lxi6oCQxAT7 X-Received: by 2002:a05:622a:1308:b0:528:38d6:71b4 with SMTP id d75a77b69052e-529a7705cb6mr40292631cf.11.1785173897654; Mon, 27 Jul 2026 10:38:17 -0700 (PDT) Received: from [192.168.1.31] ([70.8.224.64]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-907e854f462sm70659126d6.18.2026.07.27.10.38.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jul 2026 10:38:17 -0700 (PDT) Message-ID: Date: Mon, 27 Jul 2026 13:38:16 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] 9p: treat read return values of 0 as EOF To: David Howells Cc: Dominique Martinet , Eric Van Hensbergen , Latchesar Ionkov , Christian Schoenebeck , v9fs@lists.linux.dev, linux-kernel@vger.kernel.org References: <20260702090941.1298188-1-brho@google.com> <2237820.1783934942@warthog.procyon.org.uk> From: Barret Rhoden Content-Language: en-US In-Reply-To: <2237820.1783934942@warthog.procyon.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/13/26 5:29 AM, David Howells wrote: > This is kind of a weird situation. We're caching locally the content of files > aren't really regular files and probably shouldn't be cached. I'm not sure > what the best way to deal with that is. I wonder if there's some way to > detect that and mark then non-cacheable. (Assuming the server can be told not > to even serve them). > > Can we detect that the EOF length doesn't match i_size and set a flag to say > "don't cache" in netfs_inode::flags? Possibly, but could you have false positives from this? e.g. if a file's size is changed concurrently with a read returning EOF? As far as detecting EOF in the first place, my patch had the 9p client doing it. Not sure, but Dominique's question might have been whether netfs should have done the detecting instead? From what I can see, the netfs clients were responsible for setting EOF (except in netfs_clear_unread()). Some in response to an ENODATA error, others due to the "did we read past the end of the file size." Not sure whose responsibility it is to detect these cases: netfs or the FSes themselves. Thanks, Barret