From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754390AbbKBRF0 (ORCPT ); Mon, 2 Nov 2015 12:05:26 -0500 Received: from g2t4619.austin.hp.com ([15.73.212.82]:34173 "EHLO g2t4619.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752221AbbKBRFY (ORCPT ); Mon, 2 Nov 2015 12:05:24 -0500 Message-ID: <1446483683.20657.189.camel@hpe.com> Subject: Re: [PATCH v2 0/4] x86: sigcontext fixes, again From: Toshi Kani To: Stas Sergeev , Linus Torvalds , Andrew Morton , Toshi Kani , Ingo Molnar Cc: Andy Lutomirski , Andy Lutomirski , X86 ML , "linux-kernel@vger.kernel.org" , Brian Gerst , Denys Vlasenko , Borislav Petkov , Stas Sergeev Date: Mon, 02 Nov 2015 10:01:23 -0700 In-Reply-To: <5634AD00.9000405@list.ru> References: <562E126E.6030300@list.ru> <562F84AE.1030500@list.ru> <1445990693.20657.98.camel@hpe.com> <56309B10.50706@list.ru> <1446050061.20657.106.camel@hpe.com> <1446060162.20657.136.camel@hpe.com> <1446072663.20657.150.camel@hpe.com> <5634AD00.9000405@list.ru> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 (3.16.5-3.fc22) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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