| 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; 328 329 case INO_STATE_PRESENT: 330 /* It's in-core. GC must iget() it. */ 331 break; 332 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(); 346 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. */ 353 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. 361 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?