Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1633174 > unrolled thread
| Started by | Tejun Heo <tj@kernel.org> |
|---|---|
| First post | 2017-04-29 00:00 +0200 |
| Last post | 2017-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.
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
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2017-04-29 00:00 +0200 |
| Subject | Re: [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]
| From | SF Markus Elfring <elfring@users.sourceforge.net> |
|---|---|
| Date | 2017-04-29 10:40 +0200 |
| Subject | Re: 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]
| From | Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> |
|---|---|
| Date | 2017-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