Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751815AbdHBV2p (ORCPT ); Wed, 2 Aug 2017 17:28:45 -0400 Received: from hurricane.elijah.cs.cmu.edu ([128.2.209.191]:50607 "EHLO hurricane.elijah.cs.cmu.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750850AbdHBV2n (ORCPT ); Wed, 2 Aug 2017 17:28:43 -0400 X-Greylist: delayed 2698 seconds by postgrey-1.27 at vger.kernel.org; Wed, 02 Aug 2017 17:28:43 EDT Date: Wed, 2 Aug 2017 16:43:43 -0400 From: Jan Harkes To: Jeff Layton Cc: linux-fsdevel , open list , David Howells , Al Viro Subject: Re: coda's use of file->f_mapping and inode->i_mapping Message-ID: <20170802204343.GH7542@cs.cmu.edu> Mail-Followup-To: Jeff Layton , linux-fsdevel , open list , David Howells , Al Viro References: <1501686331.4654.6.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1501686331.4654.6.camel@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1345 Lines: 30 On Wed, Aug 02, 2017 at 11:05:31AM -0400, Jeff Layton wrote: > The weird bit is that in coda_file_mmap, we then do this: > > coda_file->f_mapping = host_file->f_mapping; > if (coda_inode->i_mapping == &coda_inode->i_data) > coda_inode->i_mapping = host_inode->i_mapping; > > > What is the significance of mmap on coda files? If you want to monkey > around with the i_mapping and f_mapping, wouldn't it make more sense to > do so at open() time? Normal read and write calls go through the Coda kernel module and are passed along to the underlying 'host / container' file. However with mmap you only get told that the mapping is created and the following page faults are handled directly by following the file's f_mapping/i_mapping pointer. We don't need to set up this pointer if the user never calls mmap. It is possible that when different users open the same file object they are given a different container file. Although Coda's userspace as far as I know doesn't actually do this, this case was 'anticipated' as a possibility. By delaying the monkeying around to the point of mmap, open/read/write for files works reliably and only if a second mmap is attempted where the second coda_file handle for the same coda_inode happens to have a different host_file associated with it do we return EBUSY. Jan