On Wed, Mar 22, 2023 at 4:00 PM Gedare Bloom <ged...@rtems.org> wrote:
> On Mon, Mar 20, 2023 at 6:56 AM Joel Sherrill <j...@rtems.org> wrote:
> >
> > New issue from Coveriry.
> >
> > I vaguely recall that JFFS2 uses dynamic checks for things that static
> would work and Coveriry spots the dead code
> >
> > ---------- Forwarded message ---------
> > From: <scan-ad...@coverity.com>
> > Date: Sun, Mar 19, 2023, 10:59 PM
> > Subject: New Defects reported by Coverity Scan for RTEMS
> > To: <bu...@rtems.org>
> >
> >
> > Hi,
> >
> > Please find the latest report on new defect(s) introduced to RTEMS found
> with Coverity Scan.
> >
> > 4 new defect(s) introduced to RTEMS found with Coverity Scan.
> >
> >
> > New defect(s) Reported-by: Coverity Scan
> > Showing 4 of 4 defect(s)
> >
> >
> > ** CID 1523448: Control flow issues (DEADCODE)
> > /cpukit/libfs/src/jffs2/src/gc.c: 137 in jffs2_garbage_collect_pass()
> >
> >
> >
> ________________________________________________________________________________________________________
> > *** CID 1523448: Control flow issues (DEADCODE)
> > /cpukit/libfs/src/jffs2/src/gc.c: 137 in jffs2_garbage_collect_pass()
> > 131 struct jffs2_raw_node_ref *raw;
> > 132 uint32_t gcblock_dirty;
> > 133 int ret = 0, inum, nlink;
> > 134 int xattr = 0;
> > 135
> > 136 if (mutex_lock_interruptible(&c->alloc_sem))
> > >>> CID 1523448: Control flow issues (DEADCODE)
> > >>> Execution cannot reach this statement: "return -4;".
> > 137 return -EINTR;
> > 138
> > 139
> > 140 for (;;) {
> > 141 /* We can't start doing GC until we've finished
> checking
> > 142 the node CRCs etc. */
> >
>
> This is a bug. It can be fixed by removing the error handling, because
> mutex_lock_interruptible has no return value.
>
> > ** CID 1523447: Null pointer dereferences (FORWARD_NULL)
> > /cpukit/libfs/src/jffs2/src/fs-rtems.c: 1370 in rtems_jffs2_initialize()
> >
> >
> >
> ________________________________________________________________________________________________________
> > *** CID 1523447: Null pointer dereferences (FORWARD_NULL)
> > /cpukit/libfs/src/jffs2/src/fs-rtems.c: 1370 in rtems_jffs2_initialize()
> > 1364 } else {
> > 1365 err = -ENOMEM;
> > 1366 }
> > 1367
> > 1368 sb = &fs_info->sb;
> > 1369 c = JFFS2_SB_INFO(sb);
> > >>> CID 1523447: Null pointer dereferences (FORWARD_NULL)
> > >>> Dereferencing null pointer "c".
> > 1370 c->mtd = NULL;
> > 1371
> > 1372 if (err == 0) {
> > 1373 rtems_recursive_mutex_init(&sb->s_mutex,
> RTEMS_FILESYSTEM_TYPE_JFFS2);
> > 1374 }
> > 1375
> >
> This is a bug, because c == &sb->jffs2_info == &fs_info->sb ==
> fs_info. Protect this dereference with `if (err == 0)`. I think the
> sequence of code starting with `sb = ...` can be moved into the `if`
> block at line 1372.
>
This one is my fault and is in RTEMS-owned code. Patch incoming to fix it.
The rest are in JFFS2-owned code and are either false positives or are
flagged due to the #define implementation of mutex_lock_interruptible
always returning 0.
Kinsey
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
