User: | Jiri Slaby |
Error type: | Leaving function in locked state |
Error type description: | Some lock is not unlocked on all paths of a function, so it is leaked |
File location: | mm/swap.c |
Line in file: | 379 |
Project: | Linux Kernel |
Project version: | 2.6.28 |
Tools: |
Stanse
(1.2)
|
Entered: | 2012-05-21 20:30:05 UTC |
349 continue; 350 351 if (PageLRU(page)) { 352 struct zone *pagezone = page_zone(page); 353 354 if (pagezone != zone) { 355 if (zone) 356 spin_unlock_irqrestore(&zone->lru_lock, 357 flags); 358 zone = pagezone; 359 spin_lock_irqsave(&zone->lru_lock, flags); 360 } 361 VM_BUG_ON(!PageLRU(page)); 362 __ClearPageLRU(page); 363 del_page_from_lru(zone, page); 364 } 365 366 if (!pagevec_add(&pages_to_free, page)) { 367 if (zone) { 368 spin_unlock_irqrestore(&zone->lru_lock, flags); 369 zone = NULL; 370 } 371 __pagevec_free(&pages_to_free); 372 pagevec_reinit(&pages_to_free); 373 } 374 } 375 if (zone) 376 spin_unlock_irqrestore(&zone->lru_lock, flags); 377 378 pagevec_free(&pages_to_free); 379} 380 381/* 382 * The pages which we're about to release may be in the deferred lru-addition 383 * queues. That would prevent them from really being freed right now. That's 384 * OK from a correctness point of view but is inefficient - those pages may be 385 * cache-warm and we want to give them back to the page allocator ASAP. 386 * 387 * So __pagevec_release() will drain those queues here. __pagevec_lru_add() 388 * and __pagevec_lru_add_active() call release_pages() directly to avoid 389 * mutual recursion.