From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged Date: Wed, 9 Jan 2019 10:25:43 -0800 Message-ID: References: <20190106001138.GW6310@bombadil.infradead.org> <20190108044336.GB27534@dastard> <20190109022430.GE27534@dastard> <20190109043906.GF27534@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <20190109043906.GF27534@dastard> Sender: linux-kernel-owner@vger.kernel.org To: Dave Chinner Cc: Jiri Kosina , Matthew Wilcox , Jann Horn , Andrew Morton , Greg KH , Peter Zijlstra , Michal Hocko , Linux-MM , kernel list , Linux API List-Id: linux-api@vger.kernel.org On Tue, Jan 8, 2019 at 8:39 PM Dave Chinner wrote: > > FWIW, I just realised that the easiest, most reliable way to > invalidate the page cache over a file range is simply to do a > O_DIRECT read on it. If that's the case, that's actually an O_DIRECT bug. It should only invalidate the caches on write. On reads, it wants to either _flush_ any direct caches before the read, or just take the data from the caches. At no point is "invalidate" a valid model. Of course, I'm not in the least bit shocked if O_DIRECT is buggy like this. But looking at least at the ext4 routine, the read just does ret = filemap_write_and_wait_range(mapping, iocb->ki_pos, and I don't see any invalidation. Having read access to a file absolutely should *not* mean that you can flush caches on it. That's a write op. Any filesystem that invalidates the caches on read is utterly buggy. Can you actually point to such a thing? Let's get that fixed, because it's completely wrong regardless of this whole mincore issue. Linus