Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751585AbdIQQeF (ORCPT ); Sun, 17 Sep 2017 12:34:05 -0400 Received: from mail-io0-f194.google.com ([209.85.223.194]:33775 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751407AbdIQQeD (ORCPT ); Sun, 17 Sep 2017 12:34:03 -0400 X-Google-Smtp-Source: AOwi7QArwLEicLVK3oRDWpOUQqZwoxSWy8br+KrVN0tng3VXTu3tHBXaRcHbObImeyQyJ9DMfod3U5Bx4LBtvCZN86M= MIME-Version: 1.0 In-Reply-To: <1505664935.4200.191.camel@linux.vnet.ibm.com> References: <1505451494-30228-1-git-send-email-zohar@linux.vnet.ibm.com> <1505451494-30228-4-git-send-email-zohar@linux.vnet.ibm.com> <1505507142.4200.103.camel@linux.vnet.ibm.com> <20170917151757.GA14262@infradead.org> <1505664935.4200.191.camel@linux.vnet.ibm.com> From: Linus Torvalds Date: Sun, 17 Sep 2017 09:34:01 -0700 X-Google-Sender-Auth: 9jVGO05rYqOVfWEkAjS7lxwaYT0 Message-ID: Subject: Re: [PATCH 3/3] ima: use fs method to read integrity data (updated patch description) To: Mimi Zohar Cc: Christoph Hellwig , LSM List , Christoph Hellwig , linux-ima-devel@lists.sourceforge.net, James Morris , Linux Kernel Mailing List , Matthew Garrett , Jan Kara , "Theodore Ts'o" , Andreas Dilger , Jaegeuk Kim , Chao Yu , Steven Whitehouse , Bob Peterson , David Woodhouse , Dave Kleikamp , Ryusuke Konishi , Mark Fasheh , Joel Becker , Richard Weinberger , "Darrick J. Wong" , Hugh Dickins , Chris Mason Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1540 Lines: 35 On Sun, Sep 17, 2017 at 9:15 AM, Mimi Zohar wrote: > > Unless I'm missing something, that would only be possible with an IMA > policy rule that permits direct IO (eg. permit_directio). Otherwise > the direct IO is denied. Note that the "XFS and directio" was only an example. There is absolutely nothing that says that a filesystem has to use i_rwsem for IO serialization at all. Even for the regular write path. Now, I suspect most (all?) do, but that's a historical artifact rather than "design". In particular, the VFS layer used to do the locking for the filesystems, to guarantee the POSIX requirements (POSIX requires that writes be seen atomically). But that lock was pushed down into the filesystems, since some filesystems really wanted to have parallel writes (particularly for direct IO, where that POSIX serialization requirement doesn't exist). That's all many years ago, though. New filesystems are likely to have copied the pattern from old ones, but even then.. Also, it's worth noting that "inode->i_rwlock" isn't even well-defined as a lock. You can have the question of *which* inode gets talked about when you have things like eoverlayfs etc. Normally it would be obvious, but sometimes you'd use "file->f_mapping->host" (which is the same thing in the simple cases), and sometimes it really wouldn't be obvious at all.. So... I'm really not at all convinced that i_rwsem is sensible. It's one of those things that are "mostly right for the simple cases", but... Linus