Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1633174 > unrolled thread

Re: [PATCH 0/3] SATA: Fine-tuning for two function implementations

Started byTejun Heo <tj@kernel.org>
First post2017-04-29 00:00 +0200
Last post2017-05-11 17:10 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 0/3] SATA: Fine-tuning for two function implementations Tejun Heo <tj@kernel.org> - 2017-04-29 00:00 +0200
    Re: SATA: Fine-tuning for two function implementations SF Markus Elfring <elfring@users.sourceforge.net> - 2017-04-29 10:40 +0200
    Re: [PATCH 0/3] SATA: Fine-tuning for two function implementations Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> - 2017-05-11 17:10 +0200

#1633174 — Re: [PATCH 0/3] SATA: Fine-tuning for two function implementations

FromTejun Heo <tj@kernel.org>
Date2017-04-29 00:00 +0200
SubjectRe: [PATCH 0/3] SATA: Fine-tuning for two function implementations
Message-ID<tBm5H-55J-1@gated-at.bofh.it>
Hello,

On Tue, Apr 18, 2017 at 10:00:37PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Tue, 18 Apr 2017 21:54:32 +0200
> 
> A few update suggestions were taken into account
> from static source code analysis.

Hmmm, allocs -> callocs.  Are these actually beneficial?  If so, why?
Because one multiplication is rolled into the call?

Thanks.

-- 
tejun

[toc] | [next] | [standalone]


#1633279 — Re: SATA: Fine-tuning for two function implementations

FromSF Markus Elfring <elfring@users.sourceforge.net>
Date2017-04-29 10:40 +0200
SubjectRe: SATA: Fine-tuning for two function implementations
Message-ID<tBw54-3X5-7@gated-at.bofh.it>
In reply to#1633174
> Hmmm, allocs -> callocs.  Are these actually beneficial?  If so, why?
> Because one multiplication is rolled into the call?

Did the previous size calculations contain the general possibility for
integer overflows?
https://cwe.mitre.org/data/definitions/190.html

* Will the computed values usually stay within the limits of the used
  data types so far?

* How much do you care for corresponding checks and source code annotations
  by functions like “devm_kcalloc”?

Regards,
Markus

[toc] | [prev] | [next] | [standalone]


#1639661

FromBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date2017-05-11 17:10 +0200
Message-ID<tFXT3-7X6-15@gated-at.bofh.it>
In reply to#1633174
Hi,

On Friday, April 28, 2017 05:53:34 PM Tejun Heo wrote:
> Hello,
> 
> On Tue, Apr 18, 2017 at 10:00:37PM +0200, SF Markus Elfring wrote:
> > From: Markus Elfring <elfring@users.sourceforge.net>
> > Date: Tue, 18 Apr 2017 21:54:32 +0200
> > 
> > A few update suggestions were taken into account
> > from static source code analysis.
> 
> Hmmm, allocs -> callocs.  Are these actually beneficial?  If so, why?
> Because one multiplication is rolled into the call?

Each conversion (i.e. I tried the one from patch #1) seems to add
an extra 24 bytes to the resulting code size (using gcc 4.8.4 for
ARM32 cross-compilation) so I don't see much point in the automatic
conversions. Only instances containing size calculations with
real possibility for integer overflows should be converted and
the patchset under discussion contains no such instances.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web