Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752247AbdFOBgj (ORCPT ); Wed, 14 Jun 2017 21:36:39 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:36617 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752155AbdFOBgh (ORCPT ); Wed, 14 Jun 2017 21:36:37 -0400 Subject: Re: [HELP-NEEDED, PATCH 0/3] Do not loose dirty bit on THP pages To: Vlastimil Babka , Will Deacon Cc: "Kirill A. Shutemov" , Andrew Morton , Vineet Gupta , Russell King , Catalin Marinas , Ralf Baechle , "David S. Miller" , Heiko Carstens , Martin Schwidefsky , Andrea Arcangeli , linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com References: <20170614135143.25068-1-kirill.shutemov@linux.intel.com> <20170614165513.GD17632@arm.com> From: "Aneesh Kumar K.V" Date: Thu, 15 Jun 2017 07:06:16 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17061501-0024-0000-0000-000016A5E0C0 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007234; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000212; SDB=6.00874904; UDB=6.00435552; IPR=6.00654996; BA=6.00005421; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015830; XFM=3.00000015; UTC=2017-06-15 01:36:33 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17061501-0025-0000-0000-00004B61538C Message-Id: <694d801a-cc15-d871-7951-97a7d33dc285@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-15_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706150025 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1294 Lines: 28 On Wednesday 14 June 2017 10:30 PM, Vlastimil Babka wrote: > On 06/14/2017 06:55 PM, Will Deacon wrote: >>> >>> May be we should relook at pmd PTE udpate interface. We really need an >>> interface that can update pmd entries such that we don't clear it in >>> between. IMHO, we can avoid the pmdp_invalidate() completely, if we can >>> switch from a pmd PTE entry to a pointer to PTE page (pgtable_t). We also >>> need this interface to avoid the madvise race fixed by >> >> There's a good chance I'm not following your suggestion here, but it's >> probably worth me pointing out that swizzling a page table entry from a >> block mapping (e.g. a huge page mapped at the PMD level) to a table entry >> (e.g. a pointer to a page of PTEs) can lead to all sorts of horrible >> problems on ARM, including amalgamation of TLB entries and fatal aborts. > > AFAIK some AMD x86_64 CPU's had the same problem and generated MCE's, > and on Intel there are some restrictions when you can do that. See the > large comment in __split_huge_pmd_locked(). > I was wondering whether we can do pmdp_establish(pgtable); and document all quirks needed for that in the per arch implementation of pmdp_establish(). We could also then switch all the pmdp_clear/set_pmd_at() usage to pmdp_establish(). -aneesh