<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 22, 2023 at 4:00 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Mar 20, 2023 at 6:56 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
><br>
> New issue from Coveriry.<br>
><br>
> I vaguely recall that JFFS2 uses dynamic checks for things that static would work and Coveriry spots the dead code<br>
><br>
> ---------- Forwarded message ---------<br>
> From: <<a href="mailto:scan-admin@coverity.com" target="_blank">scan-admin@coverity.com</a>><br>
> Date: Sun, Mar 19, 2023, 10:59 PM<br>
> Subject: New Defects reported by Coverity Scan for RTEMS<br>
> To: <<a href="mailto:build@rtems.org" target="_blank">build@rtems.org</a>><br>
><br>
><br>
> Hi,<br>
><br>
> Please find the latest report on new defect(s) introduced to RTEMS found with Coverity Scan.<br>
><br>
> 4 new defect(s) introduced to RTEMS found with Coverity Scan.<br>
><br>
><br>
> New defect(s) Reported-by: Coverity Scan<br>
> Showing 4 of 4 defect(s)<br>
><br>
><br>
> ** CID 1523448:  Control flow issues  (DEADCODE)<br>
> /cpukit/libfs/src/jffs2/src/gc.c: 137 in jffs2_garbage_collect_pass()<br>
><br>
><br>
> ________________________________________________________________________________________________________<br>
> *** CID 1523448:  Control flow issues  (DEADCODE)<br>
> /cpukit/libfs/src/jffs2/src/gc.c: 137 in jffs2_garbage_collect_pass()<br>
> 131             struct jffs2_raw_node_ref *raw;<br>
> 132             uint32_t gcblock_dirty;<br>
> 133             int ret = 0, inum, nlink;<br>
> 134             int xattr = 0;<br>
> 135<br>
> 136             if (mutex_lock_interruptible(&c->alloc_sem))<br>
> >>>     CID 1523448:  Control flow issues  (DEADCODE)<br>
> >>>     Execution cannot reach this statement: "return -4;".<br>
> 137                     return -EINTR;<br>
> 138<br>
> 139<br>
> 140             for (;;) {<br>
> 141                     /* We can't start doing GC until we've finished checking<br>
> 142                        the node CRCs etc. */<br>
><br>
<br>
This is a bug. It can be fixed by removing the error handling, because<br>
mutex_lock_interruptible has no return value.<br>
<br>
> ** CID 1523447:  Null pointer dereferences  (FORWARD_NULL)<br>
> /cpukit/libfs/src/jffs2/src/fs-rtems.c: 1370 in rtems_jffs2_initialize()<br>
><br>
><br>
> ________________________________________________________________________________________________________<br>
> *** CID 1523447:  Null pointer dereferences  (FORWARD_NULL)<br>
> /cpukit/libfs/src/jffs2/src/fs-rtems.c: 1370 in rtems_jffs2_initialize()<br>
> 1364            } else {<br>
> 1365                    err = -ENOMEM;<br>
> 1366            }<br>
> 1367<br>
> 1368            sb = &fs_info->sb;<br>
> 1369            c = JFFS2_SB_INFO(sb);<br>
> >>>     CID 1523447:  Null pointer dereferences  (FORWARD_NULL)<br>
> >>>     Dereferencing null pointer "c".<br>
> 1370            c->mtd = NULL;<br>
> 1371<br>
> 1372            if (err == 0) {<br>
> 1373                    rtems_recursive_mutex_init(&sb->s_mutex, RTEMS_FILESYSTEM_TYPE_JFFS2);<br>
> 1374            }<br>
> 1375<br>
><br>
This is a bug, because c == &sb->jffs2_info == &fs_info->sb ==<br>
fs_info. Protect this dereference with `if (err == 0)`. I think the<br>
sequence of code starting with `sb = ...` can be moved into the `if`<br>
block at line 1372.<br></blockquote><div><br></div><div>This one is my fault and is in RTEMS-owned code. Patch incoming to fix it.</div><div><br></div><div>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.</div><div><br></div><div>Kinsey<br></div></div></div>