From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753520AbbFIG3x (ORCPT ); Tue, 9 Jun 2015 02:29:53 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:49184 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752542AbbFIG3o (ORCPT ); Tue, 9 Jun 2015 02:29:44 -0400 Date: Mon, 8 Jun 2015 23:29:43 -0700 From: Christoph Hellwig To: Ming Lei Cc: Christoph Hellwig , Linux Kernel Mailing List , Dave Kleikamp , Jens Axboe , Zach Brown , Maxim Patlasov , Andrew Morton , Alexander Viro , Tejun Heo , Dave Chinner Subject: Re: [PATCH v4 1/5] fs: kiocb: introduce IOCB_DONT_DIRTY_PAGE flag for direct IO Message-ID: <20150609062943.GA32395@infradead.org> References: <1432881338-898-1-git-send-email-ming.lei@canonical.com> <1432881338-898-2-git-send-email-ming.lei@canonical.com> <20150605150348.GA6835@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jun 06, 2015 at 08:42:33AM +0800, Ming Lei wrote: > Both ITER_KVEC and ITER_BVEC doesn't mean the pages are kernel > page, for example of loop and swap. That is why this patch is more flexiable, > and won't cause regression since the users may have different dirtying > rules as you mentioned last time. > > http://marc.info/?t=143093223200001&r=1&w=2 Again, we never dirty pages for the caller when doing general purpose kernel I/O. For loop we either don't need it (totally in-kernel block I/O) or the caller takes care of it (direct I/O on the loop device). The swap code currently only uses ->direct_IO and thus isn't affected by this flag. If we use it for write the low-level I/O code should not dirty the page either. So to repeat myself: for the current state of affairs adding a flag that every sensible user has to set is a horrible interface. If for some unforseen reason we'll need the flag later on it should have reverse polarity, and only be added when needed.