Re: [PATCH 1/3] mm/mincore: make mincore() more conservative

2019-03-06 Thread Jiri Kosina
On Thu, 7 Mar 2019, Dominique Martinet wrote: > > > > > > addr = 4095 > > > vma->vm_end = 4096 > > > pages = 1000 > > > > > > then `end' is 4096 and `(end - addr) << PAGE_SHIFT' is zero, but it > > > should have been 1. > > > > Good catch! It should rather be something like > > > >

Re: [PATCH 1/3] mm/mincore: make mincore() more conservative

2019-03-06 Thread Dominique Martinet
Jiri Kosina wrote on Thu, Mar 07, 2019: > > I'm not sure this is correct in all cases. If > > > > addr = 4095 > > vma->vm_end = 4096 > > pages = 1000 > > > > then `end' is 4096 and `(end - addr) << PAGE_SHIFT' is zero, but it > > should have been 1. > > Good catch! It should

Re: [PATCH 1/3] mm/mincore: make mincore() more conservative

2019-03-06 Thread Jiri Kosina
On Wed, 6 Mar 2019, Andrew Morton wrote: > > The semantics of what mincore() considers to be resident is not completely > > clear, but Linux has always (since 2.3.52, which is when mincore() was > > initially done) treated it as "page is available in page cache". > > > > That's potentially a

Re: [PATCH 1/3] mm/mincore: make mincore() more conservative

2019-03-06 Thread Andrew Morton
On Wed, 30 Jan 2019 13:44:18 +0100 Vlastimil Babka wrote: > From: Jiri Kosina > > The semantics of what mincore() considers to be resident is not completely > clear, but Linux has always (since 2.3.52, which is when mincore() was > initially done) treated it as "page is available in page

Re: [PATCH 1/3] mm/mincore: make mincore() more conservative

2019-02-01 Thread Vlastimil Babka
Here's updated version with Michal's suggestion, and acks: I think this patch is fine to go, less sure about 2/3 and 3/3. 8< >From 49f17d9f6a42ecc2a508125b0c880ff0402a6f49 Mon Sep 17 00:00:00 2001 From: Jiri Kosina Date: Wed, 16 Jan 2019 20:53:17 +0100 Subject: [PATCH v2] mm/mincore:

Re: [PATCH 1/3] mm/mincore: make mincore() more conservative

2019-01-31 Thread Josh Snyder
On Thu, Jan 31, 2019 at 1:44 AM Michal Hocko wrote: > One thing is still not clear to me though. Is the new owner/writeable > check OK for the Netflix-like usecases? I mean does happycache have > appropriate access to the cache data? I have tried to re-read the > original thread but couldn't find

Re: [PATCH 1/3] mm/mincore: make mincore() more conservative

2019-01-31 Thread Dominique Martinet
Michal Hocko wrote on Thu, Jan 31, 2019: > > Change the semantics of mincore() so that it only reveals pagecache > > information > > for non-anonymous mappings that belog to files that the calling process > > could > > (if it tried to) successfully open for writing. > > I agree that this is a

Re: [PATCH 1/3] mm/mincore: make mincore() more conservative

2019-01-31 Thread Michal Hocko
On Wed 30-01-19 13:44:18, Vlastimil Babka wrote: > From: Jiri Kosina > > The semantics of what mincore() considers to be resident is not completely > clear, but Linux has always (since 2.3.52, which is when mincore() was > initially done) treated it as "page is available in page cache". > >

[PATCH 1/3] mm/mincore: make mincore() more conservative

2019-01-30 Thread Vlastimil Babka
From: Jiri Kosina The semantics of what mincore() considers to be resident is not completely clear, but Linux has always (since 2.3.52, which is when mincore() was initially done) treated it as "page is available in page cache". That's potentially a problem, as that [in]directly exposes