lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8ec653df-9d73-3c94-9559-7a732417e578@users.sourceforge.net>
Date:   Mon, 13 Feb 2017 11:37:19 +0100
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Johannes Thumshirn <jthumshirn@...e.de>, linux-rdma@...r.kernel.org
Cc:     Dennis Dalessandro <dennis.dalessandro@...el.com>,
        Doug Ledford <dledford@...hat.com>,
        Hal Rosenstock <hal.rosenstock@...il.com>,
        Mike Marciniszyn <mike.marciniszyn@...el.com>,
        Sean Hefty <sean.hefty@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: IB/hfi1: Adjust another size determination in
 hfi1_user_sdma_alloc_queues()

>> How often does it really make sense to keep such a product in this local variable?
> 
> It depends. Lets take it the other way round. If I this in a review I'd
> suggest the submitter to create a local variable for the multiplication
> to get rid of the line break. It's avoidable.

I imagine that there are further possibilities to improve the involved
programming for various arrays.


> And again, the compiler will optimize it away.
> 
> Apart from the fact that you haven't tested your patch at all:

This is true in principle as I could compile the source code adjustment at least.


> jthumshirn@...ux-x5ow:linux (test)$ git am ~/\[PATCH\ 3_5\]\ IB_hfi1\:\
> Adjust\ another\ size\ determination\ in\
> hfi1_user_sdma_alloc_queues\(\).eml
> Applying: IB/hfi1: Adjust another size determination in
> hfi1_user_sdma_alloc_queues()
> jthumshirn@...ux-x5ow:linux (test)$ make
> drivers/infiniband/hw/hfi1/user_sdma.o  CHK
> include/config/kernel.release
>   CHK     include/generated/uapi/linux/version.h
>   CHK     include/generated/utsrelease.h
>   CHK     include/generated/bounds.h
>   CHK     include/generated/timeconst.h
>   CHK     include/generated/asm-offsets.h
>   CALL    scripts/checksyscalls.sh
>   CC      drivers/infiniband/hw/hfi1/user_sdma.o
> drivers/infiniband/hw/hfi1/user_sdma.c: In function
> ‘hfi1_user_sdma_alloc_queues’:
> drivers/infiniband/hw/hfi1/user_sdma.c:402:2: error: ‘memsize’
> undeclared (first use in this function)
>   memsize = sizeof(*pq->reqs) * hfi1_sdma_comp_ring_size;
>   ^

How do you think about to apply also the previous update step like “[PATCH 2/5] IB/hfi1:
Use kcalloc() in hfi1_user_sdma_alloc_queues()”?


> So to sum up: there is no evident improvement in the resulting binary

There might not be a remarkable difference with the default software build parameters.


> and you introduce a stylistic glitch (the new line break in a function call).

There are different opinions about this implementation detail, aren't there?

Regards,
Markus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ