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.
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)
--
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
