Showing error 1191

User: Jiri Slaby
Error type: Double Unlock
Error type description: Some lock is unlocked twice unintentionally in a sequence
File location: fs/jffs2/gc.c
Line in file: 354
Project: Linux Kernel
Project version: 2.6.28
Tools: Stanse (1.2)
Entered: 2012-04-30 10:52:00 UTC


 324                        D1(printk(KERN_DEBUG "Ino #%u is absent but node not REF_PRISTINE. Reading.\n",
 325                                  ic->ino));
 326                }
 327                break;
 329        case INO_STATE_PRESENT:
 330                /* It's in-core. GC must iget() it. */
 331                break;
 333        case INO_STATE_UNCHECKED:
 334        case INO_STATE_CHECKING:
 335        case INO_STATE_GC:
 336                /* Should never happen. We should have finished checking
 337                   by the time we actually start doing any GC, and since
 338                   we're holding the alloc_sem, no other garbage collection
 339                   can happen.
 340                */
 341                printk(KERN_CRIT "Inode #%u already in state %d in jffs2_garbage_collect_pass()!\n",
 342                       ic->ino, ic->state);
 343                mutex_unlock(&c->alloc_sem);
 344                spin_unlock(&c->inocache_lock);
 345                BUG();
 347        case INO_STATE_READING:
 348                /* Someone's currently trying to read it. We must wait for
 349                   them to finish and then go through the full iget() route
 350                   to do the GC. However, sometimes read_inode() needs to get
 351                   the alloc_sem() (for marking nodes invalid) so we must
 352                   drop the alloc_sem before sleeping. */
 354                mutex_unlock(&c->alloc_sem);
 355                D1(printk(KERN_DEBUG "jffs2_garbage_collect_pass() waiting for ino #%u in state %d\n",
 356                          ic->ino, ic->state));
 357                sleep_on_spinunlock(&c->inocache_wq, &c->inocache_lock);
 358                /* And because we dropped the alloc_sem we must start again from the
 359                   beginning. Ponder chance of livelock here -- we're returning success
 360                   without actually making any progress.
 362                   Q: What are the chances that the inode is back in INO_STATE_READING
 363                   again by the time we next enter this function? And that this happens
 364                   enough times to cause a real delay?
Show full sources