All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] fs/fs.c - error handling needed?
Date: Mon, 7 Oct 2013 10:23:25 -0400	[thread overview]
Message-ID: <5252C3DD.7060505@ti.com> (raw)
In-Reply-To: <20131007135555.0922B380A63@gemini.denx.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/07/2013 09:55 AM, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20131007121252.GS15917@bill-the-cat> you wrote:
>> 
>>> 331         filename = argv[3]; 332         addr =
>>> simple_strtoul(argv[4], NULL, cmdline_base); 333         bytes
>>> = simple_strtoul(argv[5], NULL, cmdline_base); 334         if
>>> (argc >= 7) 335                 pos = simple_strtoul(argv[6],
>>> NULL, cmdline_base); 336         else 337                 pos =
>>> 0;
>>> 
>>> 
>>> Should we not perform at least minimal error checking, i. e.
>>> verify that no garbage arguments have been passed to that
>>> function?
>> 
>> Yes, we ought to.  If you don't pass fatwrite the right number
>> of arguments we get data aborts, for example.
> 
> Well, this is not a problem here, in do_save():
> 
> ... 325         if (argc < 6 || argc > 7) 326
> return CMD_RET_USAGE; ...
> 
> And are you sure of "fatwrite"?  This calls do_fat_fswrite(). and
> here I also see some test:
> 
> ... 98         if (argc < 5) 99                 return
> cmd_usage(cmdtp); ...

Off-by-one error somewhere? 'mmc' 'part' 'ddr-addr' 'filename' will
blowup as we use an insane value for size.  I suspect we aren't eating
'fatwrite' somewhere along the line.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSUsPdAAoJENk4IS6UOR1W6kEP/ijUEElKWLxsfJKLR1y0BbJ6
NaovYZ2Pz2UiOIEbk186hqEnpyaMU+2WlTavs61nufZ7fiteWkHS+536pgg/7GlG
pA9Uiq0DzI5RVG0EuaBJ62lt55JV9RWavdYlnGBEcgaD7ESLBTtizGbdKW30vW4S
FLfBXvEZVnYzTcIGT0kj8zEOLlg05QN6Asik8sv9GbwjX4wxVKwD0lpLYMmP/hy1
d/H6ql2a682HSAQw/6C+QxK89bSYbFay5+VhmFCZESM97tI1vWYIFC6hQsg8q+jl
/1asD1hquvv5Of7O2xIMyvmExPD25mbeflyTYnXoMFb8SL1VKNBfSdljcBPeTe8G
TBJMdURCf6zptmR+qUt8fRmWImhYZhalq+oyEImA4uKxu9zSBIBFcILKCJQ9LCXI
Hp0oaRaBUZVfD2Dno2g7fYgNwuOkXv/IpK/pWY0F6a2jNXGZooni9TdvkLeqX0sB
Bdgk1gz2EDeXIxvG/H4vTTWF5lVDh7Y5NHnqPW+HJ0fhaSqqxsklaXIU4np7EjIB
hfmwhi25fJZrGlUVgDG6YTkjTE8FOKfCaYVlFtIbrGZo14U27JucUBbLOeVxtEU0
VcdVcJx/pzi9377DbpWd8dF6XryMAMR3/de58ady6/TsoWZ90axIMykz3xE1TgAF
cppQkXNHHtao0PDxeWcV
=ntyL
-----END PGP SIGNATURE-----

  reply	other threads:[~2013-10-07 14:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-05 19:49 [U-Boot] fs/fs.c - error handling needed? Wolfgang Denk
2013-10-07 12:12 ` Tom Rini
2013-10-07 13:55   ` Wolfgang Denk
2013-10-07 14:23     ` Tom Rini [this message]
2013-10-08 16:58 ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5252C3DD.7060505@ti.com \
    --to=trini@ti.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.