All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mark Hamilton" <mhamilton@alliantnetworks.com>
To: <linux-mtd@lists.infradead.org>
Subject: GC patch for eCos port
Date: Fri, 8 Oct 2004 12:37:07 -0700	[thread overview]
Message-ID: <019301c4ad6e$33e3c730$0400a8c0@mark> (raw)

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

There looks to be a bug with the eCos port on how garbage collection is
done. I sent a notice about this bug before but I didn't get a resolution.
Another fellow came across the same bug and verified my fix. The bug seems
specific to eCos because of how jffs2_gc_fetch_page was ported but the
proposed fix is applied to gc.c. Since the gc.c is a JFFS2 core file, I
guess this is the appropriate mailing list for posting the patch. The patch
is attached.

Here is the problem.
ffs2_gc_fetch_page reads 4K of data into a static buffer. The static buffer
is hidden in the jffs2_gc_fetch_page function. The problem is when the
writebuf pointer is calculated. The offset is used again to reference into
the pg_ptr. You can image when start is equal to 4K that writebuf will
extend beyond the end of the pg_ptr valid memory. Offset is set to start
just before the while loop.

I made a comment below with what I think the fix should be.
Am I missing something?

            pg_ptr = jffs2_gc_fetch_page(c, f, start, &pg);
            if (IS_ERR(pg_ptr)) {
                printk(KERN_WARNING "read_cache_page() returned error:
%ld\n",
                PTR_ERR(pg_ptr));
                return PTR_ERR(pg_ptr);
            }
            offset = start;
            while(offset < orig_end) {
                        uint32_t datalen;
                        uint32_t cdatalen;
                        char comprtype = JFFS2_COMPR_NONE;
                        ret = jffs2_reserve_space_gc(c, sizeof(ri) +
JFFS2_MIN_DATA_LEN, &phys_ofs, &alloclen);
                        if (ret) {
                            printk(KERN_WARNING "jffs2_reserve_space_gc of
%zd bytes for
                                       garbage_collect_dnode failed: %d\n",
                                         sizeof(ri)+ JFFS2_MIN_DATA_LEN,
ret);
                                    break;
                        }
                        cdatalen = min_t(uint32_t, alloclen - sizeof(ri),
end - offset);
                        datalen = end - offset;
                        // This looks to be wrong.
                        writebuf = pg_ptr + (offset & PAGE_CACHE_SIZE -1));
                        // I think it should be.
                        writebuf = pg_ptr + ((offset -start) &
(PAGE_CACHE_SIZE -1));

The patch uses a define(__ECOS) to fix this problem.

[-- Attachment #2: gc.patch --]
[-- Type: application/octet-stream, Size: 766 bytes --]

Index: gc.c
===================================================================
RCS file: /home/cvs/ecos_artisan/packages/fs/jffs2/current/src/gc.c,v
retrieving revision 1.5
diff -u -F^f -r1.5 gc.c
--- gc.c	22 Jul 2004 21:35:32 -0000	1.5
+++ gc.c	6 Oct 2004 15:09:18 -0000
@@ -1188,7 +1188,15 @@
 		cdatalen = min_t(uint32_t, alloclen - sizeof(ri), end - offset);
 		datalen = end - offset;
 
+#if defined(__ECOS)
+    /* 
+       For the eCos port, jffs2_gc_fetch_page above reads 4K into a static 
+       buffer. 
+    */
+		writebuf = pg_ptr + ((offset-start) & (PAGE_CACHE_SIZE -1));
+#else
 		writebuf = pg_ptr + (offset & (PAGE_CACHE_SIZE -1));
+#endif
 
 		comprtype = jffs2_compress(c, f, writebuf, &comprbuf, &datalen, &cdatalen);
 

             reply	other threads:[~2004-10-08 19:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-08 19:37 Mark Hamilton [this message]
2004-10-11  8:49 ` [JFFS2] GC patch for eCos port Estelle HAMMACHE
2004-10-11 12:18   ` Estelle HAMMACHE
2004-11-09 21:26     ` Mark Hamilton
2004-11-11 11:27     ` David Woodhouse
2004-11-11 13:19       ` Per Hedblom
2004-11-11 13:58         ` David Woodhouse
2004-11-11 15:50           ` Per Hedblom
2004-11-11 16:02             ` David Woodhouse

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='019301c4ad6e$33e3c730$0400a8c0@mark' \
    --to=mhamilton@alliantnetworks.com \
    --cc=linux-mtd@lists.infradead.org \
    /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.