Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp3538861pxb; Mon, 24 Jan 2022 11:44:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJxPlg4LPKBf6982cd71ZEPmCtprvrH0FkS4WwlKd9J9fPVbOE7hXf8UaVx2XHZW1ebL7hIo X-Received: by 2002:a17:90b:4b8c:: with SMTP id lr12mr3393963pjb.212.1643053447215; Mon, 24 Jan 2022 11:44:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643053447; cv=none; d=google.com; s=arc-20160816; b=LVDMRprTpJoFQnuS2PhseY3T89R74LMF1czpLGu8LIyaOlUVIg7p5CdFjhPpD6x607 Od9Ty5n+3jR+E5v+fUIYoRfm5gTTskMiQKJcoWARJ/syRsmeLg379RKDbKjM6FgiB07Z hH4zxhfZ7gwTBUyRcYZW3/UXV4UGm/Lf0NlDr0W2ksKVT0I+bwDKQD+bVq6S8GiC5OFD OKxXsouPI905o82dyU3juhBcaK6419MT+rNf+5rSQwnrmkd/Pf5J+rxCBJHZcAjxnM5c gVY3eKOWSeQPYDBCbYc4lNnc93+cmKfQVeTK/xPfK2/T0092vHxX7bvHQmryWGGG8hkg itrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:subject :from:references:cc:to:content-language:user-agent:mime-version:date :message-id:dkim-signature; bh=p6k5U3jrt72YGEycMV95RQOWtIlE6Lzqr/C/r+DHzdY=; b=zURZ5UBvRDi57movJ10StSb+04qJND/PIdnOUO/Xdx9YOnq0Np7Ld357qH18zZtKn+ lD+6+O6LMAm61npVtEwTF+UFR4sjevKRwYYF/N0ufIZrGVkYyj6WRZEabuP3C4BUoRBe jhYEztyE9R8deSr6TxMkYlVMKkBYBXekh70DCNdaXXrY0yU3CDOJ8hhTfbGHdbkAaRWQ tnJ8WduTiZ6sKL/IxkhiJBx1NSKYgBIrE/5Li97jLp0eoRi8p5L6bA0gQdBdvb10iBal 4gixL3ww5Elb4n4JubFfoxcux+BqdA/j3JwGQVYa39jB+prKUNyyoY7M8Sm6UayplhM2 a/Wg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="R4zib/Al"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g33si14147761pgl.416.2022.01.24.11.43.55; Mon, 24 Jan 2022 11:44:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="R4zib/Al"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244723AbiAXRip (ORCPT + 99 others); Mon, 24 Jan 2022 12:38:45 -0500 Received: from mga02.intel.com ([134.134.136.20]:37041 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235570AbiAXRio (ORCPT ); Mon, 24 Jan 2022 12:38:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1643045924; x=1674581924; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=vPNTBoYL3mQlTowJCIE+opIrXBijwuuIm5WDA377RCk=; b=R4zib/AlAhy4TyBArxkCdrSh/eUrWFAhZg9H9D4DtsqXfj2WQjEW1BFw b8mOiwvmpaGgYG23OSmVFxxBAC0moecJ9myns3vNUX/dNjz7LujbXKXVV aXNo3VS33PrqWRy2uEutH94gTILgLCboUEVkqSPHx8WKHkjstemDQd38Q 7O9Cu3ssf/P2/X5uGtmRbJDsFeOs+VoeI8TGRQqtlPYxQ013NRslLTQCs IJvhNAF0r5ez0Pu5O84cUtpAgN5N9wWEw8k/Kv3V1H5R9wAGe45NOU4hR ha0/e5AZt5PV6QuhZImZ2CeuPPAwnvBDxuP7uUZ0WNjYaODdNQpxbYlTF g==; X-IronPort-AV: E=McAfee;i="6200,9189,10236"; a="233465149" X-IronPort-AV: E=Sophos;i="5.88,311,1635231600"; d="scan'208";a="233465149" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2022 09:38:44 -0800 X-IronPort-AV: E=Sophos;i="5.88,311,1635231600"; d="scan'208";a="580464712" Received: from jncomo-mobl.amr.corp.intel.com (HELO [10.251.27.220]) ([10.251.27.220]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jan 2022 09:38:43 -0800 Message-ID: Date: Mon, 24 Jan 2022 09:38:40 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Kuniyuki Iwashima , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen Cc: Benjamin Herrenschmidt , Kuniyuki Iwashima , x86@kernel.org, linux-kernel@vger.kernel.org References: <20220123015807.45005-1-kuniyu@amazon.co.jp> From: Dave Hansen Subject: Re: [PATCH] x86/boot: Avoid redundant address overlap tests in memcpy(). In-Reply-To: <20220123015807.45005-1-kuniyu@amazon.co.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/22/22 17:58, Kuniyuki Iwashima wrote: > -void *memmove(void *dest, const void *src, size_t n) > +void *____memmove(void *dest, const void *src, size_t n) > { > unsigned char *d = dest; > const unsigned char *s = src; > > - if (d <= s || d - s >= n) > - return ____memcpy(dest, src, n); > - > while (n-- > 0) > d[n] = s[n]; > > return dest; > } The ___ naming is pretty cruel. Could we call it memmove_no_overlap() or memmove_unsafe()? Surely we can put some *useful* bytes in the name rather than padding it out with _'s. No need to perpetuate the ____memcpy() naming. Also, is this worth the churn? It probably saves less than 10 instructions, all of which are ridiculously cheap. Is there a *reason* for this other than being a pure cleanup?