Skip to contentSkip to conversation

ext2load: increase read speed

PATCH In review Jason Cooper 7 participants 20 messages Mar 28, 2012 – Jul 24, 2012 ext2 file system

lore
Share & tools
lore

Jason Cooper

author
#0 lore raw

PATCH 1/1 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 <[email protected]>
---
 fs/ext2/ext2fs.c |   26 ++++++++++++++++++++++++--
 1 files changed, 24 insertions(+), 2 deletions(-)
fs/ext2/ext2fs.c +24 -2
index e119e13..8531db5 100644
@@ -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);
 }
Signature · 1 line
1.7.3.4
#1 lore raw

PATCH 1/1 ext2load: increase read speed

Quoted 11 lines · Jason Cooper

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<[email protected]>
Tested-by Eric Nelson <[email protected]>

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
author
#2 lore raw

PATCH 1/1 ext2load: increase read speed

Quoted 7 lines · Eric Nelson
Quoted 6 lines · Jason Cooper

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.

Quoted 7 lines
Quoted 5 lines

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<[email protected]>
Tested-by Eric Nelson <[email protected]>

Thanks for testing! I've copied your results into the commit and will be doing a pull request shortly.

thx,

Jason.

Quoted 21 lines

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
#3 lore raw

PATCH 1/1 ext2load: increase read speed

Hi Jason,

Quoted 12 lines · Jason Cooper
Quoted 11 lines · Eric Nelson
Quoted 10 lines · Jason Cooper

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.

Quoted 7 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Jason Cooper<[email protected]>
Tested-by Eric Nelson<[email protected]>

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

#4 lore raw

PATCH 1/1 ext2load: increase read speed

In reply to Jason Cooper
Quoted 11 lines · Jason Cooper

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 <[email protected]>

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 <[email protected]>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120426/7e136327/attachment.pgp>

author
#5 lore raw

PATCH 1/1 ext2load: increase read speed

Quoted 33 lines · Thierry Reding
Quoted 11 lines · Jason Cooper

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 <[email protected]>

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
Quoted 3 lines

I can also successfully load the loaded uImage to a prompt, so:

Tested-by Thierry Reding <[email protected]>

Thanks for testing! I've added your results to the commit message and will be doing a pull request shortly.

thx,

Jason.

author
#6 lore raw

[U-Boot] [GIT PULL] ext2load speedup

In reply to Jason Cooper

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(-)
author
#7 lore raw

[U-Boot] [GIT PULL RESEND] ext2load speedup

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(-)
#8 lore raw

[U-Boot] [GIT PULL RESEND] ext2load speedup

Dear Jason Cooper,

Quoted 5 lines · In message <[email protected]> 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.

Quoted 1 line

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

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is impractical for  the  standard  to  attempt  to  constrain  the
behavior  of code that does not obey the constraints of the standard.
                                                          - Doug Gwyn
author
#9 lore raw

[U-Boot] [GIT PULL RESEND] ext2load speedup

In reply to Jason Cooper

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.

Quoted 30 lines · Jason Cooper

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 at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

author
#10 lore raw

PATCH v2 1/1 ext2load: increase read speed

In reply to Jason Cooper

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 <[email protected]>
Tested-by Eric Nelson <[email protected]>
Tested-by Thierry Reding <[email protected]>

---
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(-)
fs/ext2/ext2fs.c +24 -2
index f621741..f1fce48 100644
@@ -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);
 }
Signature · 1 line
1.7.3.4
Applied
#11 lore raw

PATCH v2 1/1 ext2load: increase read speed

Dear Jason Cooper,

Quoted 69 lines · In message <[email protected]> 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 ==> 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 <[email protected]>
Tested-by Eric Nelson <[email protected]>
Tested-by Thierry Reding <[email protected]>

---
Changes since v1:
- updated commit entry to include test results from Eric Nelson and Thierry Reding

Quoted 4 lines

Based against tag 2012.04.01

 fs/ext2/ext2fs.c |   26 ++++++++++++++++++++++++--
 1 files changed, 24 insertions(+), 2 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

Signature · 5 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When it is incorrect, it is, at least *authoritatively* incorrect.
                                    - Hitchiker's Guide To The Galaxy
#12 lore raw

PATCH 1/1 ext2fs: fix warning: 'blocknxt' may be used uninitialized

ext2fs.c: In function 'ext2fs_read_file':
ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function [-Wuninitialized]

Cc Jason Cooper <[email protected]>
Signed-off-by Kim Phillips <[email protected]>

---
is this right?

 fs/ext2/ext2fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext2/ext2fs.c +1 -1
index f1fce48..c6c950e 100644
@@ -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)) {
Signature · 1 line
1.7.11.1
#13 lore raw

PATCH 1/1 ext2fs: fix warning: 'blocknxt' may be used uninitialized

Dear Kim Philips,

Quoted 17 lines · Kim Phillips

ext2fs.c: In function 'ext2fs_read_file':
ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this function [-Wuninitialized]

Cc Jason Cooper <[email protected]>
Signed-off-by Kim Phillips <[email protected]>

---
is this right?

 fs/ext2/ext2fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext2/ext2fs.c +0 -0
index f1fce48..c6c950e 100644

fs/ext2/ext2fs.c int ext2fs_read_file · line 446

Quoted 8 lines
fs/ext2/ext2fs.c +1 -1
@@ -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

#14 lore raw

PATCH v2 1/1 ext2fs: fix warning: 'blocknxt' may be used uninitialized

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 <[email protected]>
Cc Thierry Reding <[email protected]>
Cc Jason Cooper <[email protected]>
Cc Andreas Bie?mann <[email protected]>
Cc Reinhard Arlt <[email protected]>
Signed-off-by Kim Phillips <[email protected]>

---
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(-)
fs/ext2/ext2fs.c +1 -1
index f1fce48..182f0ac 100644
@@ -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) {
Signature · 1 line
1.7.11.1
#15 lore raw

PATCH v2 1/1 ext2fs: fix warning: 'blocknxt' may be used uninitialized

Quoted 14 lines · Kim Phillips

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 <[email protected]>
Cc Thierry Reding <[email protected]>
Cc Jason Cooper <[email protected]>
Cc Andreas Bie?mann <[email protected]>
Cc Reinhard Arlt <[email protected]>
Signed-off-by Kim Phillips <[email protected]>
Quoted 6 lines

---
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 <[email protected]>

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120704/8ba15969/attachment.pgp>

author
#16 lore raw

PATCH v2 1/1 ext2fs: fix warning: 'blocknxt' may be used uninitialized

In reply to Kim Phillips
Quoted 6 lines · Kim Phillips

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]

Quoted 8 lines

this change makes it go away.

Cc Eric Nelson <[email protected]>
Cc Thierry Reding <[email protected]>
Cc Jason Cooper <[email protected]>
Cc Andreas Bie?mann <[email protected]>
Cc Reinhard Arlt <[email protected]>
Signed-off-by Kim Phillips <[email protected]>
Acked-by Jason Cooper <[email protected]>

thx,

Jason.

Quoted 27 lines

---
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(-)
fs/ext2/ext2fs.c +1 -1
index f1fce48..182f0ac 100644
@@ -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) {
Signature · 1 line
1.7.11.1
Applied
#17 lore raw

PATCH v2 1/1 ext2fs: fix warning: 'blocknxt' may be used uninitialized

In reply to Kim Phillips

Dear Kim Phillips,

Quoted 18 lines · In message <[email protected]> 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 <[email protected]>
Cc Thierry Reding <[email protected]>
Cc Jason Cooper <[email protected]>
Cc Andreas Bie=DFmann <[email protected]>
Cc Reinhard Arlt <[email protected]>
Signed-off-by Kim Phillips <[email protected]>

---
v2: changed to Thierry's recommendation in:

Quoted 6 lines

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

Signature · 6 lines
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
... not meant for the weak-at-heart: /^(?=.*one)(?=.*two)/
If you can follow that, you can use it.
          - Randal L. Schwartz in <[email protected]>
#18 lore raw

PATCH v2 1/1 ext2fs: fix warning: 'blocknxt' may be used uninitialized

Quoted 21 lines · Wolfgang Denk

Dear Kim Phillips,

Quoted 18 lines · In message <[email protected]> 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 <[email protected]>
Cc Thierry Reding <[email protected]>
Cc Jason Cooper <[email protected]>
Cc Andreas Bie=DFmann <[email protected]>
Cc Reinhard Arlt <[email protected]>
Signed-off-by Kim Phillips <[email protected]>

---
v2: changed to Thierry's recommendation in:

Quoted 8 lines
Quoted 6 lines

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

Signature · 1 line
Tom
#19 lore raw

PATCH v2 1/1 ext2fs: fix warning: 'blocknxt' may be used uninitialized

Quoted 29 lines · Tom Rini
Quoted 28 lines · Wolfgang Denk

Dear Kim Phillips,

Quoted 24 lines · In message <[email protected]> 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 <[email protected]>
Cc Thierry Reding <[email protected]>
Cc Jason Cooper <[email protected]>
Cc Andreas Bie=DFmann <[email protected]>
Cc Reinhard Arlt <[email protected]>
Signed-off-by Kim Phillips <[email protected]>

---
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(-)
Quoted 6 lines
Quoted 1 line

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120724/895638f5/attachment.pgp>