From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [PATCHV5 3/3] x86, ras: Add __mcsafe_copy() function to recover from machine checks Date: Sun, 27 Dec 2015 14:33:30 +0100 Message-ID: <20151227133330.GA20823@nazgul.tnic> References: <20151226103252.GA21988@pd.tnic> <20151227100919.GA19398@nazgul.tnic> <6c0b3214-f120-47ee-b7fe-677b4f27f039@email.android.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Andy Lutomirski Cc: Tony Luck , linux-nvdimm , X86 ML , "elliott@hpe.com" , "linux-mm@kvack.org" , Andrew Morton , "Williams, Dan J" , Ingo Molnar , "linux-kernel@vger.kernel.org" List-Id: linux-mm.kvack.org On Sun, Dec 27, 2015 at 05:25:45AM -0800, Andy Lutomirski wrote: > That could significantly bloat the kernel image. Yeah, we probably should build an allyesconfig and see how big __ex_table is and compute how much actually that bloat would be, because... > Anyway, the bit 31 game isn't so bad IMO because it's localized to the > extable macros and the extable reader, whereas the bit 63 thing is all > tangled up with the __mcsafe_copy thing, and that's just the first > user of a more general mechanism. > > Did you see this: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=strict_uaccess_fixups/patch_v1&id=16644d9460fc6531456cf510d5efc57f89e5cd34 ... the problem this has is that you have 4 classes, AFAICT. And since we're talking about a generic mechanism, the moment the 4 classes are not enough, this new scheme fails. I'm just saying... 4 classes are probably more than enough but we don't know. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --