User: | Jiri Slaby |
Error type: | Double Lock |
Error type description: | Some lock is locked twice unintentionally in a sequence |
File location: | mm/swapfile.c |
Line in file: | 905 |
Project: | Linux Kernel |
Project version: | 2.6.28 |
Tools: |
Stanse
(1.2)
|
Entered: | 2012-04-29 14:49:11 UTC |
875 mmput(start_mm); 876 start_mm = new_start_mm; 877 } 878 if (shmem) { 879 /* page has already been unlocked and released */ 880 if (shmem > 0) 881 continue; 882 retval = shmem; 883 break; 884 } 885 if (retval) { 886 unlock_page(page); 887 page_cache_release(page); 888 break; 889 } 890 891 /* 892 * How could swap count reach 0x7fff when the maximum 893 * pid is 0x7fff, and there's no way to repeat a swap 894 * page within an mm (except in shmem, where it's the 895 * shared object which takes the reference count)? 896 * We believe SWAP_MAP_MAX cannot occur in Linux 2.4. 897 * 898 * If that's wrong, then we should worry more about 899 * exit_mmap() and do_munmap() cases described above: 900 * we might be resetting SWAP_MAP_MAX too early here. 901 * We know "Undead"s can happen, they're okay, so don't 902 * report them; but do report if we reset SWAP_MAP_MAX. 903 */ 904 if (*swap_map == SWAP_MAP_MAX) { 905 spin_lock(&swap_lock); 906 *swap_map = 1; 907 spin_unlock(&swap_lock); 908 reset_overflow = 1; 909 } 910 911 /* 912 * If a reference remains (rare), we would like to leave 913 * the page in the swap cache; but try_to_unmap could 914 * then re-duplicate the entry once we drop page lock, 915 * so we might loop indefinitely; also, that page could