From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753214AbbEMGUJ (ORCPT ); Wed, 13 May 2015 02:20:09 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:34775 "EHLO mail-wg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753432AbbEMGUA (ORCPT ); Wed, 13 May 2015 02:20:00 -0400 Date: Wed, 13 May 2015 08:19:55 +0200 From: Ingo Molnar To: Borislav Petkov Cc: "H. Peter Anvin" , Thomas Gleixner , Linus Torvalds , Andy Lutomirski , Denys Vlasenko , lkml Subject: Re: [RFC PATCH] Drop some asm from copy_user_64.S Message-ID: <20150513061954.GA24538@gmail.com> References: <20150512205750.GJ3497@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150512205750.GJ3497@pd.tnic> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Borislav Petkov wrote: > Hi guys, > > this is just an RFC first to sanity-check what I'm trying to do: > > I want to get rid of the asm glue in arch/x86/lib/copy_user_64.S which > prepares the copy_user* alternatives calls. And replace it with nice and > clean C. > > The other intention is to switch to using copy_user_generic() which does > CALL directly instead of as it is now with CALL > _copy_*_user and inside the JMP to the proper , > i.e., to save us that JMP. > > I'm not 100% sure about the equivalence between the addition carry and > segment limit check we're doing in asm in arch/x86/lib/copy_user_64.S > now and with the access_ok() I've replaced it with. > > I mean, it *looks* like access_ok() and __chk_range_not_ok() especially > does the proper checks - addition carry and segment limit with > user_addr_max() but I'd like for someone much more experienced than me > to double-check that. > > So, without much further ado, here is the diff. It looks simple enough... Looks nice. Would be useful to do before/after analysis of the generated asm with a defconfig and document that in the changelog. I'd keep any changes to inlining decisions a separate patch and do vmlinux before/after size analysis as well, so that we don't mix the effects of the various enhancements. Thanks, Ingo