| Message ID | 20190630014501.16027-2-andre.przywara@arm.com |
|---|---|
| State | Accepted |
| Commit | 40e7b3ce74e32798e742725d743e484f11766ba4 |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | tools: mkenvimage: Fixes for reading from pipes | expand |
Hello Andre, Am Sonntag, 30. Juni 2019, 02:45:00 CEST schrieb Andre Przywara: > It is perfectly fine for the read(2) syscall to return with less than > the requested number of bytes read (short read, see the "RETURN VALUE" > section of the man page). This typically happens with slow input > (keyboard, network) or with complex pipes. > > So far mkenvimage expects the exact number of requested bytes to be > read, assuming an end-of-file condition otherwise. This wrong behaviour > can be easily shown with: > $ (echo "foo=bar"; sleep 1; echo "bar=baz") | mkenvimage -s 256 -o out - > The second line will be missing from the output. > > Correct this by checking for any positive, non-zero return value. > > This fixes a problem with a complex pipe in one of my scripts, where > the environment consist of two parts. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> From reading the code and 'man 2 read' again, not tested locally: Acked-by: Alexander Dahl <ada@thorsis.com> Greets Alex
On Sun, Jun 30, 2019 at 02:45:00AM +0100, Andre Przywara wrote: > It is perfectly fine for the read(2) syscall to return with less than > the requested number of bytes read (short read, see the "RETURN VALUE" > section of the man page). This typically happens with slow input > (keyboard, network) or with complex pipes. > > So far mkenvimage expects the exact number of requested bytes to be > read, assuming an end-of-file condition otherwise. This wrong behaviour > can be easily shown with: > $ (echo "foo=bar"; sleep 1; echo "bar=baz") | mkenvimage -s 256 -o out - > The second line will be missing from the output. > > Correct this by checking for any positive, non-zero return value. > > This fixes a problem with a complex pipe in one of my scripts, where > the environment consist of two parts. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > Acked-by: Alexander Dahl <ada@thorsis.com> Applied to u-boot/master, thanks!
diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c index 75967d0c2d..ffaebd5565 100644 --- a/tools/mkenvimage.c +++ b/tools/mkenvimage.c @@ -173,8 +173,7 @@ int main(int argc, char **argv) return EXIT_FAILURE; } filesize += readbytes; - } while (readbytes == readlen); - + } while (readbytes > 0); } else { txt_filename = argv[optind]; txt_fd = open(txt_filename, O_RDONLY);
It is perfectly fine for the read(2) syscall to return with less than the requested number of bytes read (short read, see the "RETURN VALUE" section of the man page). This typically happens with slow input (keyboard, network) or with complex pipes. So far mkenvimage expects the exact number of requested bytes to be read, assuming an end-of-file condition otherwise. This wrong behaviour can be easily shown with: $ (echo "foo=bar"; sleep 1; echo "bar=baz") | mkenvimage -s 256 -o out - The second line will be missing from the output. Correct this by checking for any positive, non-zero return value. This fixes a problem with a complex pipe in one of my scripts, where the environment consist of two parts. Signed-off-by: Andre Przywara <andre.przywara@arm.com> --- tools/mkenvimage.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)