Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S937971AbdD0NKK (ORCPT <rfc822;w@1wt.eu>);
        Thu, 27 Apr 2017 09:10:10 -0400
Received: from mga01.intel.com ([192.55.52.88]:38825 "EHLO mga01.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1754766AbdD0NKC (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 27 Apr 2017 09:10:02 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.37,383,1488873600"; 
   d="scan'208";a="1124060255"
Message-ID: <1493298596.24567.233.camel@linux.intel.com>
Subject: Re: [PATCH v1 8/8] ACPI: Use recently introduced uuid_le_cmp_p{p}()
 helpers
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Borislav Petkov <bp@suse.de>, "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Lukas Wunner <lukas@wunner.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
        Mika Westerberg <mika.westerberg@linux.intel.com>,
        alsa-devel@alsa-project.org, linux-input@vger.kernel.org,
        kvm@vger.kernel.org, devel@linuxdriverproject.org,
        linux-efi@vger.kernel.org, linux-acpi@vger.kernel.org
Date: Thu, 27 Apr 2017 16:09:56 +0300
In-Reply-To: <20170427124631.3fycg2jbs4ffhi45@pd.tnic>
References: <20170421144645.45189-1-andriy.shevchenko@linux.intel.com>
         <20170421144645.45189-8-andriy.shevchenko@linux.intel.com>
         <7721821.2dV0yqi2RQ@aspire.rjw.lan>
         <20170427124631.3fycg2jbs4ffhi45@pd.tnic>
Organization: Intel Finland Oy
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.22.6-1 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3067
Lines: 76

On Thu, 2017-04-27 at 14:46 +0200, Borislav Petkov wrote:
> On Fri, Apr 21, 2017 at 11:22:31PM +0200, Rafael J. Wysocki wrote:
> > >  #ifdef CONFIG_ACPI_APEI_PCIEAER
> > > -		else if (!uuid_le_cmp(*(uuid_le *)gdata-
> > > >section_type,
> > > -				      CPER_SEC_PCIE)) {
> > > +		else if (!uuid_le_cmp_p(sec_type, CPER_SEC_PCIE))
> > > {
> > >  			struct cper_sec_pcie *pcie_err;
> > >  			pcie_err = (struct cper_sec_pcie
> > > *)(gdata+1);
> > >  			if (sev == GHES_SEV_RECOVERABLE &&
> > > 
> > 
> > But this one is for Boris.
> 
> I don't see anything wrong with it upon a brief inspection.

Lukas pointed to this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68725

> 
> What could be improved here, though, is if the whole uuid_* types
> handling be changed so that gcc doesn't generate yucky code. Because
> here's what it does now, regardless of this patch:
> 
>         .file 16 "./include/linux/uuid.h"
>         .loc 16 63 0
>         leaq    16(%rsp), %rsi  #,
>         movl    $16, %edx       #,
>         movq    %r15, %rdi      # gdata,
>         movb    $84, 16(%rsp)   #, MEM[(struct  *)&u2]
>         movb    $-23, 17(%rsp)  #, MEM[(struct  *)&u2 + 1B]
>         movb    $-107, 18(%rsp) #, MEM[(struct  *)&u2 + 2B]
>         movb    $-39, 19(%rsp)  #, MEM[(struct  *)&u2 + 3B]
>         movb    $-63, 20(%rsp)  #, MEM[(struct  *)&u2 + 4B]
>         movb    $-69, 21(%rsp)  #, MEM[(struct  *)&u2 + 5B]
>         movb    $15, 22(%rsp)   #, MEM[(struct  *)&u2 + 6B]
>         movb    $67, 23(%rsp)   #, MEM[(struct  *)&u2 + 7B]
>         movb    $-83, 24(%rsp)  #, MEM[(struct  *)&u2 + 8B]
>         movb    $-111, 25(%rsp) #, MEM[(struct  *)&u2 + 9B]
>         movb    $-76, 26(%rsp)  #, MEM[(struct  *)&u2 + 10B]
>         movb    $77, 27(%rsp)   #, MEM[(struct  *)&u2 + 11B]
>         movb    $-53, 28(%rsp)  #, MEM[(struct  *)&u2 + 12B]
>         movb    $60, 29(%rsp)   #, MEM[(struct  *)&u2 + 13B]
>         movb    $111, 30(%rsp)  #, MEM[(struct  *)&u2 + 14B]
>         movb    $53, 31(%rsp)   #, MEM[(struct  *)&u2 + 15B]
>         call    memcmp  #
> 
> So it is basically building that UUID byte by byte before calling
> memcmp.
> 
> And I'm wondering if those 16-byte arrays could be replaced with
> 
> typedef struct {
>         u64 a, b;
> } u128;
> 
> from the crypto code.
> 
> And whether the code generated by gcc would look much saner. Because
> the
> CPU can handle two qwords much better/faster than 16 u8s.
> 
> Anyway, in case someone feels bored...
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)

-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy