linux-kernel - Re: [PATCH v4 1/5] fs: kiocb: introduce IOCB_DONT_DIRTY

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 9 Jun 2015 17:58:40 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Kleikamp <dave.kleikamp@...cle.com>,
	Jens Axboe <axboe@...nel.dk>, Zach Brown <zab@...bo.net>,
	Maxim Patlasov <mpatlasov@...allels.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Tejun Heo <tj@...nel.org>, Dave Chinner <david@...morbit.com>
Subject: Re: [PATCH v4 1/5] fs: kiocb: introduce IOCB_DONT_DIRTY_PAGE flag for
 direct IO

On Tue, Jun 9, 2015 at 2:29 PM, Christoph Hellwig <hch@...radead.org> wrote:
> 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

There shouldn't be lots of such uses, and the flag still has the
document benifit, that means the caller should think and check
the current dirtying usage.

> some unforseen reason we'll need the flag later on it should have
> reverse polarity, and only be added when needed.

OK, I will remove the flag in v5 since loop dio is the 1st read
->direct_IO via ITER_KVEC/ITER_BVEC inside kernel.

But I am wondering it is good to decide dirtying by
ITER_KVEC and ITER_BVEC, and dirtying pages should better
be checked case by case, at least for loop, the usage is a bit
special(fs over loop is taking care of that)


Thanks,
Ming
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/