lkml.org 
[lkml]   [2015]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 0/4] x86: sigcontext fixes, again
From
Date
On Sat, 2015-10-31 at 14:58 +0300, Stas Sergeev wrote:
> 29.10.2015 01:51, Toshi Kani пишет:
> > On Wed, 2015-10-28 at 13:22 -0600, Toshi Kani wrote:
> > > On Wed, 2015-10-28 at 10:34 -0600, Toshi Kani wrote:

:

> > > I looked at the dosemu code and was able to reproduce the issue with a
> > > test program. This problem happens when mremap() to /dev/mem (or PFNMAP)
> > > is called with MREMAP_FIXED.
> > >
> > > In this case, mremap calls move_vma(), which first calls
> > > move_page_tables() to remap the translation and then calls do_munmap() to
> > > remove the original mapping. Hence, when untrack_pfn() is called from
> > > do_munmap(), the original map is already removed, and follow_phys() fails
> > > with the !pte_present() check.
> > >
> > > I think there are a couple of issues:
> > > - If untrack_pfn() ignores an error from follow_phys() and skips
> > > free_pfn_range(), PAT continues to track the original map that is removed.
> > > - untrack_pfn() calls free_pfn_range() to untrack a given free range.
> > > However, rbt_memtype_erase() requires the free range match exactly to
> > > the tracked range. This does not support mremap, which needs to free up
> > > part of the tracked range.
> > > - PAT does not track a new translation specified by mremap() with
> > > MREMAP_FIXED.
> > Thinking further, I think the 1st and 3rd items are non-issues. mremap
> > remaps virtual address, but keeps the same cache type and pfns. So, PAT
> > does not have to change the tracked pfns in this case. The 2nd item is
> > still a problem, though.
> Hello Toshi, thanks for your analysis.
> Now as you do not seem to be preparing a fix, how
> about attaching your test-case to the bug-report for
> others to re-use? Or maybe you can even make it a
> part of the kernel's test suit - I suppose this will help.

I can work on the fix, but I did not think we needed to rush on it since this
issue exists for a long time. Can we target it to 4.4-rcX and then cc to
stables?

As for the test, it might be tricky to make it run on any platforms since it
needs to mmap/mremap a non-RAM range. It could just map a reserved range
randomly, but I chose a range manually which I know is safe to map & read/write
on my platform in my test.

Thanks,
-Toshi


\
 
 \ /
  Last update: 2015-11-02 18:21    [W:0.219 / U:0.756 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site