From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752540AbcFVMZi (ORCPT ); Wed, 22 Jun 2016 08:25:38 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:7211 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752102AbcFVMZf (ORCPT ); Wed, 22 Jun 2016 08:25:35 -0400 X-IBM-Helo: d01dlp01.pok.ibm.com X-IBM-MailFrom: groug@kaod.org Subject: [PATCH 0/3] fs/9p: fix setattr/getattr issues with open files From: Greg Kurz To: Eric Van Hensbergen Cc: Latchesar Ionkov , Dominique Martinet , linux-kernel@vger.kernel.org, qemu-devel@nongnu.org, v9fs-developer@lists.sourceforge.net, Ron Minnich , "David S. Miller" Date: Wed, 22 Jun 2016 14:25:25 +0200 User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16062212-0040-0000-0000-000000A13F1A X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16062212-0041-0000-0000-0000047B2B46 Message-Id: <146659832556.15781.17414806975641516683.stgit@bahia.lan> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-06-22_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606220132 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The 9p filesystem has some serious issues with all syscalls that deal with file attributes out of a file descriptor instead of a path name (aka. fstat, ftruncate, fchmod and friends). If the file is opened and then unlinked, any subsequent call to the above syscalls will fail with EACCES. The same will happen to ftruncate() if the file is no longer writable. The root cause to this is that the VFS layer does not pass the struct file to the filesystem when it is about file attributes. This is legitimate: when we reach setattr/getattr, we don't need anything to be dereferenced from the struct file. But the current lookup code is based on the list of fids hanging off the dentry: it is okay for path name based syscalls, but not relialable in the case of file descriptors because we cannot find an open fid this way. Eric sent a patch last year to address the case when the file gets unlinked: https://patchwork.kernel.org/patch/6252761/ The general idea is to try to find an open fid, starting from the inode. The patch does this by browsing the 9p client list of all fids when we know the file was unlinked: if we find a fid, it is necessarily an open fid. I could find a newer version of this patch with some minor changes, here: https://github.com/ericvh/linux/commits/v9fs-devel Since the patch also fixes a few other things, I re-post it first in this series. Eric, I hope it is okay for you ? As suggested in the changelog, the lookup of open fid can be optimized if we link open fids to the inode. This is addressed by the second patch. The third patch addresses a related issue with ftruncate() on unwriteable files. This series can be tested with a custom QEMU, available here: https://github.com/gkurz/qemu/commits/9p-attr-fixes I could have most f*() syscalls working in the guest, with the notable exception of xattr related ones because more code is needed in QEMU. Please comment. Test reports will also be appreciated :) --- Eric Van Hensbergen (1): fs/9p: fix create-unlink-getattr idiom Greg Kurz (2): fs/9p: track open fids fs/9p: search open fids first fs/9p/fid.c | 46 +++++++++++++++++++++++++++++++++++++++++++++- fs/9p/fid.h | 1 + fs/9p/vfs_dir.c | 5 +++++ fs/9p/vfs_file.c | 1 + fs/9p/vfs_inode.c | 10 +++++++++- fs/9p/vfs_inode_dotl.c | 1 + include/net/9p/client.h | 3 +++ net/9p/client.c | 5 ++++- 8 files changed, 69 insertions(+), 3 deletions(-) -- Greg