Re: [RFP-V2 0/3] Make mmu_notifier_invalidate_range_start able to sleep.

[Robin Holt <holt@sgi.com>]

On Tue, Feb 02, 2010 at 02:13:41PM +0100, Andrea Arcangeli wrote:
> On Tue, Feb 02, 2010 at 01:59:43PM +0100, Andrea Arcangeli wrote:
> > slowdown the locking even if it leaves holes and corrupts memory when
> > XPMEM can be opened by luser. It really depends if the user having
> > access to XPMEM device is malicious, if we know it's not (assume
> > avatar distributed rendering in closed environment or whatever) this
> > again is an ok hack.
> 
> >From another point of view: if the userland has to be as trusted as
> the kernel for this hack to be ok, I don't get it why it's not ok to
> just schedule unconditionally in the invalidate_range_start without
> altering the API and gracefully deadlock in the i_mmap_lock. If the
> secondary mappings cannot be teardown without scheduling, it means the
> page will be swapped out but the physical pages can be still written
> to despite the page being swapped out and reused by something else
> leading to trivial memory corruption if the user having access to
> xpmem device is malicious.
> 
> Like Andrew already said, we've no clue what the "bool atomic"
> parameter will be used for and so it's next to impossible to judge the
> validity of this hack (because an hack that is). We don't know how
> xpmem will react to that event, all we know is that it won't be able
> to invalidate secondary mappings by the time this call returns leading
> to memory corruption. If it panics or if it ignores the invalidate
> when atomic=1, it's equivalent or worse than just schedule in

The atomic==1 case is only for the truncate case, correct?  XPMEM is
holding reference counts on the pages it exports (get_user_pages) so
they are not freed even when the zap_page_range has completed.  What I
think we are dealing with is an inconsistent appearance to userland.
The one task would SIG_BUS if it touches the memory.  The other would
be able to read/write it just fine until the ascynchronous zap of the
attachment completed.

Robin

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>