Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754499AbbLKWRP (ORCPT ); Fri, 11 Dec 2015 17:17:15 -0500 Received: from mga01.intel.com ([192.55.52.88]:52727 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754000AbbLKWRN (ORCPT ); Fri, 11 Dec 2015 17:17:13 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,415,1444719600"; d="scan'208";a="859083441" From: "Luck, Tony" To: Andy Lutomirski CC: Ingo Molnar , Borislav Petkov , "Andrew Morton" , Andy Lutomirski , "Williams, Dan J" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , linux-nvdimm , X86 ML Subject: RE: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks Thread-Topic: [PATCHV2 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks Thread-Index: AQHRNE/aOhVlt+R/OUCiyPbQy9P3LZ7GRdgwgACTpgD//34voA== Date: Fri, 11 Dec 2015 22:17:10 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F39F82EEF@ORSMSX114.amr.corp.intel.com> References: <23b2515da9d06b198044ad83ca0a15ba38c24e6e.1449861203.git.tony.luck@intel.com> <3908561D78D1C84285E8C5FCA982C28F39F82D87@ORSMSX114.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsIiwiaWQiOiJhYzM0OTAyOS1lNWI0LTRiZTAtODlhMS01NWEzYmNjMzE4NDYiLCJwcm9wcyI6W3sibiI6IkludGVsRGF0YUNsYXNzaWZpY2F0aW9uIiwidmFscyI6W3sidmFsdWUiOiJDVFBfSUMifV19XX0sIlN1YmplY3RMYWJlbHMiOltdLCJUTUNWZXJzaW9uIjoiMTUuNC4xMC4xOSIsIlRydXN0ZWRMYWJlbEhhc2giOiJEU3RSVEU0NFRLUEM0R1J6cCtyWlExd2R2clBneW5Lc3NIdm5XUG1jRHpNPSJ9 x-inteldataclassification: CTP_IC x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tBBMHKfN013980 Content-Length: 1637 Lines: 50 > I'm missing something, though. The normal fixup_exception path > doesn't touch rax at all. The memory_failure path does. But couldn't > you distinguish them by just pointing the exception handlers at > different landing pads? Perhaps I'm just trying to take a short cut to avoid writing some clever fixup code for the target ip that goes into the exception table. For __copy_user_nocache() we have four possible targets for fixup depending on where we were in the function. .section .fixup,"ax" 30: shll $6,%ecx addl %ecx,%edx jmp 60f 40: lea (%rdx,%rcx,8),%rdx jmp 60f 50: movl %ecx,%edx 60: sfence jmp copy_user_handle_tail .previous Note that this code also takes a shortcut by jumping to copy_user_handle_tail() to finish up the copy a byte at a time ... and running back into the same page fault a 2nd time to make sure the byte count is exactly right. I really, really, don't want to run back into the poison again. It would probably work, but because current generation Intel cpus broadcast machine checks to every logical cpu, it is a lot of overhead, and potentially risky. > Also, would it be more straightforward if the mcexception landing pad > looked up the va -> pa mapping by itself? Or is that somehow not > reliable? If we did get all the above right, then we could have target use virt_to_phys() to convert to physical ... I don't see that this part would be a problem. -Tony ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?