[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4dca91c1-488d-120d-bd25-74f400242bd2@users.sourceforge.net>
Date: Mon, 13 Feb 2017 10:32:13 +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: [PATCH 3/5] IB/hfi1: Adjust another size determination in
hfi1_user_sdma_alloc_queues()
>> @@ -443,8 +442,8 @@ int hfi1_user_sdma_alloc_queues(struct hfi1_ctxtdata *uctxt, struct file *fp)
>> if (!cq)
>> goto cq_nomem;
>>
>> - memsize = PAGE_ALIGN(sizeof(*cq->comps) * hfi1_sdma_comp_ring_size);
>> - cq->comps = vmalloc_user(memsize);
>> + cq->comps = vmalloc_user(PAGE_ALIGN(sizeof(*cq->comps)
>> + * hfi1_sdma_comp_ring_size));
>> if (!cq->comps)
>> goto cq_comps_nomem;
>>
>>
>
> IMHO this makes readability worse.
How often does it really make sense to keep such a product in this local variable?
> What's the intention behind this patch?
I suggested just another simple omission of an extra variable.
Regards,
Markus
Powered by blists - more mailing lists