From: Borislav Petkov <bp@alien8.de> To: Tony Luck <tony.luck@gmail.com> Cc: Ingo Molnar <mingo@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Andy Lutomirski <luto@kernel.org>, Dan Williams <dan.j.williams@intel.com>, Elliott@pd.tnic, Robert <elliott@hpe.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, linux-nvdimm@ml01.01.org, X86-ML <x86@kernel.org> Subject: Re: [PATCHV3 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks Date: Wed, 23 Dec 2015 13:58:53 +0100 [thread overview] Message-ID: <20151223125853.GF30213@pd.tnic> (raw) In-Reply-To: <CA+8MBbJ+T0Bkea48rivWEZRn8_iPiSvrPm5p22RfbS7V0_KyEA@mail.gmail.com> 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. > I'll move the function and #defines as you suggest - we don't need > new files for these. Also will fix the assembly code. > [In my defense that load immediate 0x8000000000000000 and 'or' > was what gcc -O2 generates from a simple bit of C code to set > bit 63 ... perhaps it is faster, or perhaps gcc is on drugs. In this > case code compactness wins over possible speed difference]. Well, upon a second thought, the reason why gcc would use that huge immediate could be because by using BTS, it clobbers the carry flag in rFLAGS. And I guess we don't want that. Although any Jcc or other conditional instructions touching rFLAGS following will overwrite that bit so it won't really matter. I've asked a gcc person, we'll see what interesting explanation comes back. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply.
WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@alien8.de> To: Tony Luck <tony.luck@gmail.com> Cc: Ingo Molnar <mingo@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Andy Lutomirski <luto@kernel.org>, Dan Williams <dan.j.williams@intel.com>, Elliott@pd.tnic, Robert <elliott@hpe.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "linux-mm@kvack.org" <linux-mm@kvack.org>, linux-nvdimm@ml01.01.org, X86-ML <x86@kernel.org> Subject: Re: [PATCHV3 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks Date: Wed, 23 Dec 2015 13:58:53 +0100 [thread overview] Message-ID: <20151223125853.GF30213@pd.tnic> (raw) In-Reply-To: <CA+8MBbJ+T0Bkea48rivWEZRn8_iPiSvrPm5p22RfbS7V0_KyEA@mail.gmail.com> 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. > I'll move the function and #defines as you suggest - we don't need > new files for these. Also will fix the assembly code. > [In my defense that load immediate 0x8000000000000000 and 'or' > was what gcc -O2 generates from a simple bit of C code to set > bit 63 ... perhaps it is faster, or perhaps gcc is on drugs. In this > case code compactness wins over possible speed difference]. Well, upon a second thought, the reason why gcc would use that huge immediate could be because by using BTS, it clobbers the carry flag in rFLAGS. And I guess we don't want that. Although any Jcc or other conditional instructions touching rFLAGS following will overwrite that bit so it won't really matter. I've asked a gcc person, we'll see what interesting explanation comes back. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2015-12-23 12:59 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-12-16 16:39 [PATCHV3 0/3] Machine check recovery when kernel accesses poison Tony Luck 2015-12-16 16:39 ` Tony Luck 2015-12-16 1:29 ` [PATCHV3 1/3] x86, ras: Add new infrastructure for machine check fixup tables Tony Luck 2015-12-16 1:29 ` Tony Luck 2015-12-16 17:55 ` Andy Lutomirski 2015-12-16 17:55 ` Andy Lutomirski 2015-12-16 22:51 ` Luck, Tony 2015-12-16 22:51 ` Luck, Tony 2015-12-17 16:22 ` Andy Lutomirski 2015-12-17 16:22 ` Andy Lutomirski 2015-12-21 18:18 ` Borislav Petkov 2015-12-21 18:18 ` Borislav Petkov 2015-12-21 19:16 ` Dan Williams 2015-12-21 19:16 ` Dan Williams 2015-12-21 20:15 ` Borislav Petkov 2015-12-21 20:15 ` Borislav Petkov 2015-12-22 11:13 ` Borislav Petkov 2015-12-22 11:13 ` Borislav Petkov 2015-12-16 1:29 ` [PATCHV3 2/3] x86, ras: Extend machine check recovery code to annotated ring0 areas Tony Luck 2015-12-16 1:29 ` Tony Luck 2015-12-22 11:14 ` Borislav Petkov 2015-12-22 11:14 ` Borislav Petkov 2015-12-16 1:30 ` [PATCHV3 3/3] x86, ras: Add mcsafe_memcpy() function to recover from machine checks Tony Luck 2015-12-16 1:30 ` Tony Luck 2015-12-22 11:13 ` Borislav Petkov 2015-12-22 11:13 ` Borislav Petkov 2015-12-22 19:38 ` Tony Luck 2015-12-22 19:38 ` Tony Luck 2015-12-23 12:58 ` Borislav Petkov [this message] 2015-12-23 12:58 ` Borislav Petkov 2015-12-23 19:31 ` Dan Williams 2015-12-23 19:31 ` Dan Williams 2015-12-23 20:46 ` Tony Luck 2015-12-23 20:46 ` Tony Luck 2015-12-24 13:37 ` Borislav Petkov 2015-12-24 13:37 ` Borislav Petkov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20151223125853.GF30213@pd.tnic \ --to=bp@alien8.de \ --cc=Elliott@pd.tnic \ --cc=akpm@linux-foundation.org \ --cc=dan.j.williams@intel.com \ --cc=elliott@hpe.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-nvdimm@ml01.01.org \ --cc=luto@kernel.org \ --cc=mingo@kernel.org \ --cc=tony.luck@gmail.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.