Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756765AbbLWTbH (ORCPT ); Wed, 23 Dec 2015 14:31:07 -0500 Received: from mail-ob0-f169.google.com ([209.85.214.169]:35089 "EHLO mail-ob0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756583AbbLWTbB (ORCPT ); Wed, 23 Dec 2015 14:31:01 -0500 MIME-Version: 1.0 In-Reply-To: <20151223125853.GF30213@pd.tnic> References: <20151222111349.GB3728@pd.tnic> <20151223125853.GF30213@pd.tnic> Date: Wed, 23 Dec 2015 11:31:00 -0800 Message-ID: Subject: Re: [PATCHV3 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks From: Dan Williams To: Borislav Petkov Cc: Tony Luck , Ingo Molnar , Andrew Morton , Andy Lutomirski , Elliott@pd.tnic, Robert , Linux Kernel Mailing List , "linux-mm@kvack.org" , linux-nvdimm , X86-ML Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2258 Lines: 52 On Wed, Dec 23, 2015 at 4:58 AM, Borislav Petkov wrote: > On Tue, Dec 22, 2015 at 11:38:07AM -0800, Tony Luck wrote: >> I interpreted that comment as "stop playing with %rax in the fault >> handler ... just change the IP to point the the .fixup location" ... >> the target of the fixup being the "landing pad". >> >> Right now this function has only one set of fault fixups (for machine >> checks). When I tackle copy_from_user() it will sprout a second >> set for page faults, and then will look a bit more like Andy's dual >> landing pad example. >> >> I still need an indicator to the caller which type of fault happened >> since their actions will be different. So BIT(63) lives on ... but is >> now set in the .fixup section rather than in the machine check >> code. > > You mean this previous example of yours: > > int copy_from_user(void *to, void *from, unsigned long n) > { > u64 ret = mcsafe_memcpy(to, from, n); > > if (COPY_HAD_MCHECK(r)) { > if (memory_failure(COPY_MCHECK_PADDR(ret) >> PAGE_SIZE, ...)) > force_sig(SIGBUS, current); > return something; > } else > return ret; > } > > ? > > So what's wrong with mcsafe_memcpy() returning a proper retval which > says what type of fault happened? > > I know, memcpy returns the ptr to @dest like a parrot but your version > mcsafe_memcpy() will be different. It can even be called __mcsafe_memcpy > and have a wrapper around it which fiddles out the proper retvals and > returns @dest after all. It would still be cleaner this way IMHO. We might leave this to the consumer. It's already the case that mcsafe_memcpy() is arch specific so I'm having to wrap its return value into a generic value. My current thinking is make memcpy_from_pmem() return a pmem_cookie_t, and then have an arch specific pmem_copy_error(pmem_cookit_t cookie) helper that interprets the value. This is similar to the situation we have with dma_mapping_error(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/