All of lore.kernel.org
 help / color / mirror / Atom feed
From: arunkann <arunkann@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] jffs2_1pass_build_lists max_totlen question
Date: Mon, 22 Oct 2012 13:36:22 -0700 (PDT)	[thread overview]
Message-ID: <34588781.post@talk.nabble.com> (raw)


Hi,

I see an issue when the u-boot is unable to load (fsload) the kernel or
device tree files from NOR flash to RAM, occasionally. I am using u-boot
version "U-Boot 2011.12 ".
 
The root cause seems to be the size of ?pL->readbuf? malloc?ed in
jffs2_1pass_build_lists () jffs_1pass.c file.
 
The size used for allocation for 'readbuf' is based on max data size among
the fragmented jNodes ?node->totlen? (excluding summary nodes). It looks
like on the occasions when fsload works, the buffer size is alloc?ed 4164
(empty scan size of 4096 + sizeof jNode 68); this seems to be big enough for
every chunk of data read later on in jffs2_1pass_read_inode(). However, on
occasions when fsload fails; the size alloc?ed for readbuf is fairly small
causing memory corruption in jffs2_1pass_read_inode().
 
I found couple of ways to workaround the issue (statically alloc readbuf for
4164 or provide null ptr for external buffer in get_node_mem() call in
jffs2_1pass_read_inode()).

Why is max_totlen calculation is restricted to size of fragmented nodes and
not summary nodes as well?



-- 
View this message in context: http://old.nabble.com/jffs2_1pass_build_lists-max_totlen-question-tp34588781p34588781.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

                 reply	other threads:[~2012-10-22 20:36 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=34588781.post@talk.nabble.com \
    --to=arunkann@gmail.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.