From: Al Viro <v...@zeniv.linux.org.uk>
schedule_delayed_work() happening when the work is already pending is
a cheap no-op. Don't bother with ->wbuf_queued logics - it's both
broken (cancelling ->wbuf_dwork leaves it set, as spotted by Jeff Harris)
and pointless. It's cheaper to let schedule_delayed_work() handle that
case.
Reported-by: Jeff Harris <jeffthar...@gmail.com>
Tested-by: Jeff Harris <jeffthar...@gmail.com>
Cc: sta...@vger.kernel.org
Signed-off-by: Al Viro <v...@zeniv.linux.org.uk>
0 2 cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h
diff --git a/cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h
b/cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h
index 413ef89c2d..046fee8b6e 100644
--- a/cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h
+++ b/cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h
@@ -134,8 +134,6 @@ struct jffs2_sb_info {
struct rw_semaphore wbuf_sem; /* Protects the write buffer */
struct delayed_work wbuf_dwork; /* write-buffer write-out work */
- int wbuf_queued; /* non-zero delayed work is queued */
- spinlock_t wbuf_dwork_lock; /* protects wbuf_dwork and and
wbuf_queued */
unsigned char *oobbuf;
int oobavail; /* How many bytes are available for JFFS2 in OOB */
--
2.13.7
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
