[U-Boot] [PATCH] ext2load: increase read speed
This patch dramatically drops the amount of time u-boot needs to read a file from an ext2 partition. On a typical 2 to 5 MB file (kernels and initrds) it goes from tens of seconds to a couple seconds.
All we are doing here is grouping contiguous blocks into one read.
Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC) with three different files. sha1sums were calculated in Linux userspace, and then confirmed after ext2load.
Signed-off-by: Jason Cooper u-boot@lakedaemon.net --- fs/ext2/ext2fs.c | 26 ++++++++++++++++++++++++-- 1 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c index e119e13..8531db5 100644 --- a/fs/ext2/ext2fs.c +++ b/fs/ext2/ext2fs.c @@ -414,7 +414,6 @@ int ext2fs_read_file if (blknr < 0) { return (-1); } - blknr = blknr << log2blocksize;
/* Last block. */ if (i == blockcnt - 1) { @@ -432,6 +431,29 @@ int ext2fs_read_file blockend -= skipfirst; }
+ /* grab middle blocks in one go */ + if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) { + int oldblk = blknr; + int blocknxt; + while (i < blockcnt - 1) { + blocknxt = ext2fs_read_block(node, i + 1); + if (blocknxt == (oldblk + 1)) { + oldblk = blocknxt; + i++; + } else { + blocknxt = ext2fs_read_block(node, i); + break; + } + } + + if (oldblk == blknr) + blockend = blocksize; + else + blockend = (1 + blocknxt - blknr) * blocksize; + } + + blknr = blknr << log2blocksize; + /* If the block number is 0 this block is not stored on disk but is zero filled instead. */ if (blknr) { @@ -444,7 +466,7 @@ int ext2fs_read_file } else { memset (buf, 0, blocksize - skipfirst); } - buf += blocksize - skipfirst; + buf += blockend - skipfirst; } return (len); }
On 03/28/2012 07:37 AM, Jason Cooper wrote:
This patch dramatically drops the amount of time u-boot needs to read a file from an ext2 partition. On a typical 2 to 5 MB file (kernels and initrds) it goes from tens of seconds to a couple seconds.
All we are doing here is grouping contiguous blocks into one read.
Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC) with three different files. sha1sums were calculated in Linux userspace, and then confirmed after ext2load.
Signed-off-by: Jason Cooperu-boot@lakedaemon.net
Tested-by: Eric Nelson eric.nelson@boundarydevices.com
Tested on i.MX6 Sabre Lite board loading a file of ~900k:
Without patch:
MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000 /usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1) 958032 bytes read time: 0.414 seconds, 414 ticks CRC32 for 12000000 ... 120e9e4f ==> 550deec9 With patch: MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000 /usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1) 958032 bytes read
time: 0.205 seconds, 205 ticks CRC32 for 12000000 ... 120e9e4f ==> 550deec9
On Wed, Apr 25, 2012 at 06:17:48PM -0700, Eric Nelson wrote:
On 03/28/2012 07:37 AM, Jason Cooper wrote:
This patch dramatically drops the amount of time u-boot needs to read a file from an ext2 partition. On a typical 2 to 5 MB file (kernels and initrds) it goes from tens of seconds to a couple seconds.
All we are doing here is grouping contiguous blocks into one read.
Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC) with three different files. sha1sums were calculated in Linux userspace, and then confirmed after ext2load.
Signed-off-by: Jason Cooperu-boot@lakedaemon.net
Tested-by: Eric Nelson eric.nelson@boundarydevices.com
Thanks for testing! I've copied your results into the commit and will be doing a pull request shortly.
thx,
Jason.
Tested on i.MX6 Sabre Lite board loading a file of ~900k:
Without patch:
MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000 /usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1) 958032 bytes read
time: 0.414 seconds, 414 ticks CRC32 for 12000000 ... 120e9e4f ==> 550deec9
With patch: MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000 /usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1) 958032 bytes read
time: 0.205 seconds, 205 ticks CRC32 for 12000000 ... 120e9e4f ==> 550deec9
Hi Jason,
On 05/08/2012 08:43 AM, Jason Cooper wrote:
On Wed, Apr 25, 2012 at 06:17:48PM -0700, Eric Nelson wrote:
On 03/28/2012 07:37 AM, Jason Cooper wrote:
This patch dramatically drops the amount of time u-boot needs to read a file from an ext2 partition. On a typical 2 to 5 MB file (kernels and initrds) it goes from tens of seconds to a couple seconds.
All we are doing here is grouping contiguous blocks into one read.
Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC) with three different files. sha1sums were calculated in Linux userspace, and then confirmed after ext2load.
Signed-off-by: Jason Cooperu-boot@lakedaemon.net
Tested-by: Eric Nelsoneric.nelson@boundarydevices.com
Thanks for testing! I've copied your results into the commit and will be doing a pull request shortly.
No problem.
Ironically, I'm working with an image this morning that loads the kernel from ext2 and I keep thinking my board is locked up because reads take so long.
Regards,
Eric
* Jason Cooper wrote:
This patch dramatically drops the amount of time u-boot needs to read a file from an ext2 partition. On a typical 2 to 5 MB file (kernels and initrds) it goes from tens of seconds to a couple seconds.
All we are doing here is grouping contiguous blocks into one read.
Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC) with three different files. sha1sums were calculated in Linux userspace, and then confirmed after ext2load.
Signed-off-by: Jason Cooper u-boot@lakedaemon.net
Before:
Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage Loading file "/boot/uImage" from mmc device 0:1 (xxa1) 5609104 bytes read
time: 4.638 seconds, 4638 ticks Tegra2 (Medcom) # crc32 0x17000000 559690 CRC32 for 17000000 ... 1755968f ==> 158788be
After:
Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage Loading file "/boot/uImage" from mmc device 0:1 (xxa1) 5609104 bytes read
time: 0.317 seconds, 317 ticks Tegra2 (Medcom) # crc32 0x17000000 559690 CRC32 for 17000000 ... 1755968f ==> 158788be
I can also successfully load the loaded uImage to a prompt, so:
Tested-by: Thierry Reding thierry.reding@avionic-design.de
On Thu, Apr 26, 2012 at 02:54:51PM +0200, Thierry Reding wrote:
- Jason Cooper wrote:
This patch dramatically drops the amount of time u-boot needs to read a file from an ext2 partition. On a typical 2 to 5 MB file (kernels and initrds) it goes from tens of seconds to a couple seconds.
All we are doing here is grouping contiguous blocks into one read.
Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC) with three different files. sha1sums were calculated in Linux userspace, and then confirmed after ext2load.
Signed-off-by: Jason Cooper u-boot@lakedaemon.net
Before:
Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage Loading file "/boot/uImage" from mmc device 0:1 (xxa1) 5609104 bytes read
time: 4.638 seconds, 4638 ticks Tegra2 (Medcom) # crc32 0x17000000 559690 CRC32 for 17000000 ... 1755968f ==> 158788be
After:
Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage Loading file "/boot/uImage" from mmc device 0:1 (xxa1) 5609104 bytes read
time: 0.317 seconds, 317 ticks Tegra2 (Medcom) # crc32 0x17000000 559690 CRC32 for 17000000 ... 1755968f ==> 158788be
I can also successfully load the loaded uImage to a prompt, so:
Tested-by: Thierry Reding thierry.reding@avionic-design.de
Thanks for testing! I've added your results to the commit message and will be doing a pull request shortly.
thx,
Jason.
The following changes since commit 415d386877df49eb051b85ef74fa59a16dc17c7d:
Prepare v2012.04.01 (2012-04-25 15:22:50 +0200)
are available in the git repository at: git://git.infradead.org/users/jcooper/u-boot.git ext2load_speedup
Jason Cooper (1): ext2load: increase read speed
fs/ext2/ext2fs.c | 26 ++++++++++++++++++++++++-- 1 files changed, 24 insertions(+), 2 deletions(-)
Wolfgang,
I saw you were handling some pull requests and thought this might have slipped through the cracks. This patch sat on the list for quite a while and has two independent testers reporting substantial success (included in the commit).
To my knowledge, there is no fs maintainer...
thx,
Jason.
The following changes since commit 415d386877df49eb051b85ef74fa59a16dc17c7d:
Prepare v2012.04.01 (2012-04-25 15:22:50 +0200)
are available in the git repository at: git://git.infradead.org/users/jcooper/u-boot.git ext2load_speedup
Jason Cooper (1): ext2load: increase read speed
fs/ext2/ext2fs.c | 26 ++++++++++++++++++++++++-- 1 files changed, 24 insertions(+), 2 deletions(-)
Dear Jason Cooper,
In message 20120521013540.GM24238@titan.lakedaemon.net you wrote:
I saw you were handling some pull requests and thought this might have slipped through the cracks. This patch sat on the list for quite a while and has two independent testers reporting substantial success (included in the commit).
I accept only pull requests from the U-Boot custodians, who in turn accept only patches posted on the mailing list.
You wrote before that you had updated the commit message, so I am still waiting for you to re-post your patch. A pull request from some external repository is not sufficient - we cannot easily review and comment the code then, and it does not get logged in patchwork.
To my knowledge, there is no fs maintainer...
True. Stuff like this has to be handled by me, unless some other maintainer picks it up through the staging tree.
Best regards,
Wolfgang Denk
Wolfgang,
My apologies. I pulled up the patchwork and saw that you had responded to this email. However, I never received it. Time to go review my procmailrc. At any rate, I'll post v2 shortly as requested.
thx,
Jason.
On Sun, May 20, 2012 at 09:35:40PM -0400, Jason Cooper wrote:
Wolfgang,
I saw you were handling some pull requests and thought this might have slipped through the cracks. This patch sat on the list for quite a while and has two independent testers reporting substantial success (included in the commit).
To my knowledge, there is no fs maintainer...
thx,
Jason.
The following changes since commit 415d386877df49eb051b85ef74fa59a16dc17c7d:
Prepare v2012.04.01 (2012-04-25 15:22:50 +0200)
are available in the git repository at: git://git.infradead.org/users/jcooper/u-boot.git ext2load_speedup
Jason Cooper (1): ext2load: increase read speed
fs/ext2/ext2fs.c | 26 ++++++++++++++++++++++++-- 1 files changed, 24 insertions(+), 2 deletions(-)
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
This patch dramatically drops the amount of time u-boot needs to read a file from an ext2 partition. On a typical 2 to 5 MB file (kernels and initrds) it goes from tens of seconds to a couple seconds.
All we are doing here is grouping contiguous blocks into one read.
Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC) with three different files. sha1sums were calculated in Linux userspace, and then confirmed after ext2load.
The following test results were provided by Eric Nelson:
Tested on i.MX6 Sabre Lite board loading a file of ~900k:
Without patch:
MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000 /usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1) 958032 bytes read
time: 0.414 seconds, 414 ticks CRC32 for 12000000 ... 120e9e4f ==> 550deec9
With patch: MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000 /usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1) 958032 bytes read
time: 0.205 seconds, 205 ticks CRC32 for 12000000 ... 120e9e4f ==> 550deec9
And, the following results were reported by Thierry Reding:
Before:
Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage Loading file "/boot/uImage" from mmc device 0:1 (xxa1) 5609104 bytes read
time: 4.638 seconds, 4638 ticks Tegra2 (Medcom) # crc32 0x17000000 559690 CRC32 for 17000000 ... 1755968f ==> 158788be
After:
Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage Loading file "/boot/uImage" from mmc device 0:1 (xxa1) 5609104 bytes read
time: 0.317 seconds, 317 ticks Tegra2 (Medcom) # crc32 0x17000000 559690 CRC32 for 17000000 ... 1755968f ==> 158788be
I can also successfully load the loaded uImage to a prompt
End results.
Signed-off-by: Jason Cooper u-boot@lakedaemon.net Tested-by: Eric Nelson eric.nelson@boundarydevices.com Tested-by: Thierry Reding thierry.reding@avionic-design.de --- Changes since v1: - updated commit entry to include test results from Eric Nelson and Thierry Reding
Based against tag 2012.04.01
fs/ext2/ext2fs.c | 26 ++++++++++++++++++++++++-- 1 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c index f621741..f1fce48 100644 --- a/fs/ext2/ext2fs.c +++ b/fs/ext2/ext2fs.c @@ -420,7 +420,6 @@ int ext2fs_read_file if (blknr < 0) { return (-1); } - blknr = blknr << log2blocksize;
/* Last block. */ if (i == blockcnt - 1) { @@ -438,6 +437,29 @@ int ext2fs_read_file blockend -= skipfirst; }
+ /* grab middle blocks in one go */ + if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) { + int oldblk = blknr; + int blocknxt; + while (i < blockcnt - 1) { + blocknxt = ext2fs_read_block(node, i + 1); + if (blocknxt == (oldblk + 1)) { + oldblk = blocknxt; + i++; + } else { + blocknxt = ext2fs_read_block(node, i); + break; + } + } + + if (oldblk == blknr) + blockend = blocksize; + else + blockend = (1 + blocknxt - blknr) * blocksize; + } + + blknr = blknr << log2blocksize; + /* If the block number is 0 this block is not stored on disk but is zero filled instead. */ if (blknr) { @@ -450,7 +472,7 @@ int ext2fs_read_file } else { memset (buf, 0, blocksize - skipfirst); } - buf += blocksize - skipfirst; + buf += blockend - skipfirst; } return (len); }
Dear Jason Cooper,
In message 1338566090-15008-1-git-send-email-u-boot@lakedaemon.net you wrote:
This patch dramatically drops the amount of time u-boot needs to read a file from an ext2 partition. On a typical 2 to 5 MB file (kernels and initrds) it goes from tens of seconds to a couple seconds.
All we are doing here is grouping contiguous blocks into one read.
Boot tested on Globalscale Technologies Dreamplug (Kirkwood ARM SoC) with three different files. sha1sums were calculated in Linux userspace, and then confirmed after ext2load.
The following test results were provided by Eric Nelson:
Tested on i.MX6 Sabre Lite board loading a file of ~900k:
Without patch:
MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000/usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1) 958032 bytes read
time: 0.414 seconds, 414 ticks CRC32 for 12000000 ... 120e9e4f ==> 550deec9With patch: MX6QSABRELITE U-Boot > time ext2load sata 0:1 12000000 /usr/lib/libperl.so.5.12.4 && crc32 12000000 $filesize Loading file "/usr/lib/libperl.so.5.12.4" from sata device 0:1 (hda1) 958032 bytes read
time: 0.205 seconds, 205 ticks CRC32 for 12000000 ... 120e9e4f ==> 550deec9And, the following results were reported by Thierry Reding:
Before:
Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage Loading file "/boot/uImage" from mmc device 0:1 (xxa1) 5609104 bytes read time: 4.638 seconds, 4638 ticks Tegra2 (Medcom) # crc32 0x17000000 559690 CRC32 for 17000000 ... 1755968f ==> 158788beAfter:
Tegra2 (Medcom) # time ext2load mmc 0 0x17000000 /boot/uImage Loading file "/boot/uImage" from mmc device 0:1 (xxa1) 5609104 bytes read time: 0.317 seconds, 317 ticks Tegra2 (Medcom) # crc32 0x17000000 559690 CRC32 for 17000000 ... 1755968f ==> 158788beI can also successfully load the loaded uImage to a prompt
End results.
Signed-off-by: Jason Cooper u-boot@lakedaemon.net Tested-by: Eric Nelson eric.nelson@boundarydevices.com Tested-by: Thierry Reding thierry.reding@avionic-design.de
Changes since v1:
- updated commit entry to include test results from Eric Nelson and Thierry Reding
Based against tag 2012.04.01
fs/ext2/ext2fs.c | 26 ++++++++++++++++++++++++-- 1 files changed, 24 insertions(+), 2 deletions(-)
Applied, thanks.
Best regards,
Wolfgang Denk
ext2fs.c: In function 'ext2fs_read_file': ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function [-Wuninitialized]
Cc: Jason Cooper u-boot@lakedaemon.net Signed-off-by: Kim Phillips kim.phillips@freescale.com --- is this right?
fs/ext2/ext2fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c index f1fce48..c6c950e 100644 --- a/fs/ext2/ext2fs.c +++ b/fs/ext2/ext2fs.c @@ -440,7 +440,7 @@ int ext2fs_read_file /* grab middle blocks in one go */ if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) { int oldblk = blknr; - int blocknxt; + int blocknxt = 0; while (i < blockcnt - 1) { blocknxt = ext2fs_read_block(node, i + 1); if (blocknxt == (oldblk + 1)) {
Dear Kim Philips,
On 03.07.12 18:05, Kim Phillips wrote:
ext2fs.c: In function 'ext2fs_read_file': ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function [-Wuninitialized]
Cc: Jason Cooper u-boot@lakedaemon.net Signed-off-by: Kim Phillips kim.phillips@freescale.com
is this right?
fs/ext2/ext2fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c index f1fce48..c6c950e 100644 --- a/fs/ext2/ext2fs.c +++ b/fs/ext2/ext2fs.c @@ -440,7 +440,7 @@ int ext2fs_read_file /* grab middle blocks in one go */ if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) { int oldblk = blknr;
int blocknxt;
int blocknxt = 0; while (i < blockcnt - 1) { blocknxt = ext2fs_read_block(node, i + 1); if (blocknxt == (oldblk + 1)) {
there are two other solutions. I dunno which should we use but Thierry Reding suggested another working one which I think its cleaner. Please read http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
Best regards
Andreas Bießmann
This warning was introduced in 436da3c "ext2load: increase read speed":
ext2fs.c: In function 'ext2fs_read_file': ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function [-Wuninitialized]
this change makes it go away.
Cc: Eric Nelson eric.nelson@boundarydevices.com Cc: Thierry Reding thierry.reding@avionic-design.de Cc: Jason Cooper u-boot@lakedaemon.net Cc: Andreas Bießmann andreas.devel@googlemail.com Cc: Reinhard Arlt reinhard.arlt@esd-electronics.com Signed-off-by: Kim Phillips kim.phillips@freescale.com --- v2: changed to Thierry's recommendation in:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
build-tested only - please ack
fs/ext2/ext2fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c index f1fce48..182f0ac 100644 --- a/fs/ext2/ext2fs.c +++ b/fs/ext2/ext2fs.c @@ -438,7 +438,7 @@ int ext2fs_read_file }
/* grab middle blocks in one go */ - if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) { + if (i != pos / blocksize && i < blockcnt - 1 && blockcnt > 3) { int oldblk = blknr; int blocknxt; while (i < blockcnt - 1) {
On Tue, Jul 03, 2012 at 05:41:56PM -0500, Kim Phillips wrote:
This warning was introduced in 436da3c "ext2load: increase read speed":
ext2fs.c: In function 'ext2fs_read_file': ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function [-Wuninitialized]
this change makes it go away.
Cc: Eric Nelson eric.nelson@boundarydevices.com Cc: Thierry Reding thierry.reding@avionic-design.de Cc: Jason Cooper u-boot@lakedaemon.net Cc: Andreas Bießmann andreas.devel@googlemail.com Cc: Reinhard Arlt reinhard.arlt@esd-electronics.com Signed-off-by: Kim Phillips kim.phillips@freescale.com
v2: changed to Thierry's recommendation in:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
build-tested only - please ack
Tested on TEC, seems to behave the same as before:
Tested-by: Thierry Reding thierry.reding@avionic-design.de
Thierry
On Tue, Jul 03, 2012 at 05:41:56PM -0500, Kim Phillips wrote:
This warning was introduced in 436da3c "ext2load: increase read speed":
ext2fs.c: In function 'ext2fs_read_file': ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function [-Wuninitialized]
this change makes it go away.
Cc: Eric Nelson eric.nelson@boundarydevices.com Cc: Thierry Reding thierry.reding@avionic-design.de Cc: Jason Cooper u-boot@lakedaemon.net Cc: Andreas Bießmann andreas.devel@googlemail.com Cc: Reinhard Arlt reinhard.arlt@esd-electronics.com Signed-off-by: Kim Phillips kim.phillips@freescale.com
Acked-By: Jason Cooper u-boot@lakedaemon.net
thx,
Jason.
v2: changed to Thierry's recommendation in:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
build-tested only - please ack
fs/ext2/ext2fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext2/ext2fs.c b/fs/ext2/ext2fs.c index f1fce48..182f0ac 100644 --- a/fs/ext2/ext2fs.c +++ b/fs/ext2/ext2fs.c @@ -438,7 +438,7 @@ int ext2fs_read_file }
/* grab middle blocks in one go */
if (i != pos / blocksize && i != blockcnt - 1 && blockcnt > 3) {
if (i != pos / blocksize && i < blockcnt - 1 && blockcnt > 3) { int oldblk = blknr; int blocknxt; while (i < blockcnt - 1) {-- 1.7.11.1
Dear Kim Phillips,
In message 20120703174156.a1082309c2b205216606a004@freescale.com you wrote:
This warning was introduced in 436da3c "ext2load: increase read speed":
ext2fs.c: In function 'ext2fs_read_file': ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this func= tion [-Wuninitialized]
this change makes it go away.
Cc: Eric Nelson eric.nelson@boundarydevices.com Cc: Thierry Reding thierry.reding@avionic-design.de Cc: Jason Cooper u-boot@lakedaemon.net Cc: Andreas Bie=DFmann andreas.devel@googlemail.com Cc: Reinhard Arlt reinhard.arlt@esd-electronics.com Signed-off-by: Kim Phillips kim.phillips@freescale.com
v2: changed to Thierry's recommendation in:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
build-tested only - please ack
fs/ext2/ext2fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
Best regards,
Wolfgang Denk
On Sun, Jul 08, 2012 at 10:55:16PM +0200, Wolfgang Denk wrote:
Dear Kim Phillips,
In message 20120703174156.a1082309c2b205216606a004@freescale.com you wrote:
This warning was introduced in 436da3c "ext2load: increase read speed":
ext2fs.c: In function 'ext2fs_read_file': ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this func= tion [-Wuninitialized]
this change makes it go away.
Cc: Eric Nelson eric.nelson@boundarydevices.com Cc: Thierry Reding thierry.reding@avionic-design.de Cc: Jason Cooper u-boot@lakedaemon.net Cc: Andreas Bie=DFmann andreas.devel@googlemail.com Cc: Reinhard Arlt reinhard.arlt@esd-electronics.com Signed-off-by: Kim Phillips kim.phillips@freescale.com
v2: changed to Thierry's recommendation in:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
build-tested only - please ack
fs/ext2/ext2fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
This doesn't fix the warning for ELDK 4.2 toolchains (gcc 4.2.2): ext2fs.c: In function 'ext2fs_read_file': ext2fs.c:443: warning: 'blocknxt' may be used uninitialized in this function
On Mon, Jul 23, 2012 at 11:56:00AM -0700, Tom Rini wrote:
On Sun, Jul 08, 2012 at 10:55:16PM +0200, Wolfgang Denk wrote:
Dear Kim Phillips,
In message 20120703174156.a1082309c2b205216606a004@freescale.com you wrote:
This warning was introduced in 436da3c "ext2load: increase read speed":
ext2fs.c: In function 'ext2fs_read_file': ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this func= tion [-Wuninitialized]
this change makes it go away.
Cc: Eric Nelson eric.nelson@boundarydevices.com Cc: Thierry Reding thierry.reding@avionic-design.de Cc: Jason Cooper u-boot@lakedaemon.net Cc: Andreas Bie=DFmann andreas.devel@googlemail.com Cc: Reinhard Arlt reinhard.arlt@esd-electronics.com Signed-off-by: Kim Phillips kim.phillips@freescale.com
v2: changed to Thierry's recommendation in:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
build-tested only - please ack
fs/ext2/ext2fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
This doesn't fix the warning for ELDK 4.2 toolchains (gcc 4.2.2): ext2fs.c: In function 'ext2fs_read_file': ext2fs.c:443: warning: 'blocknxt' may be used uninitialized in this function
I've seen older toolchains fail a lot at detecting situations like this. I think starting with 4.5 things got a lot better.
Thierry
participants (7)
-
Andreas Bießmann -
Eric Nelson -
Jason Cooper -
Kim Phillips -
Thierry Reding -
Tom Rini -
Wolfgang Denk