From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: breaking leases on metadata changes Date: Wed, 21 Sep 2011 10:58:11 -0400 Message-ID: <1316617097-21384-1-git-send-email-bfields@redhat.com> Cc: linux-nfs@vger.kernel.org, samba-technical@lists.samba.org, Christoph Hellwig , Al Viro , Mimi Zohar To: linux-fsdevel@vger.kernel.org Return-path: Received: from fieldses.org ([174.143.236.118]:59097 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751764Ab1IUO62 (ORCPT ); Wed, 21 Sep 2011 10:58:28 -0400 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: So there's this longstanding problem that read leases should really be broken on anything that changes an inode's metadata or any change to the set of links pointing to the inode. (Cc'ing samba-technical for confirmation of that statement from Samba's point of view....) So we need mutual exclusion between read leases and link, unlink, rename, etc. After contemplating increasingly complicated solutions for much too long, I realized that the i_mutex is taken by all of those operations except for rename--and it looks to me like rename could take i_mutex on a renamed file as well. So, here's my attempt. It passes some simple tests. Is it sane? I tried updating Documentation/filesystems/directory-locking to reflect the rename change, but without thinking it through as carefully as I'd like to. Also, the one thing I *know* is wrong: lockdep doesn't like the rename change, and I haven't tried to figure out how to fix it. (Help?) These patches assume some previous lease fixes already committed to git://linux-nfs.org/~bfields/linux.git for-3.2 --b.