[PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache

2.4.1 has a memory leak (temporary) where anonymous memory pages that have been moved into the swap cache will stick around after their vma has been unmapped by the owning process. These pages are not free'd in free_pte() because they are still referenced by the page cache. In addition, if the p

Bug in 2.4.0-test9 and test10 with sys_shmat()

Sending -1 as the shmid to shmat will cause an oops. 2.2.16 caught this with simple boundry checking, so replace the lines if (!shm_sb || (shmid % SEQ_MULTIPLIER) == zero_id) return -EINVAL; with if (!shm_sb || shmid < 0 || (shmid % SEQ_MULTIPLIER) == zero_id) r

[PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache (updated)

2.4.1 has a memory leak (temporary) where anonymous memory pages that have been moved into the swap cache will stick around after their vma has been unmapped by the owning process. These pages are not free'd in free_pte() because they are still referenced by the page cache. In addition, if the p

Re: [PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache (updated)

> Your idea is nice, but the patch lacks a few things: > > - SMP locking, what if some other process faults in this page > between the atomic_read of the page count and the test later? It can't happen. free_pte is called with the page_table_lock held in addition to having the mmap_sem downed

Re: [PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache (updated)

> fork and exit are very hot paths in the kernel, and this patch can force > a page cache lookup on a large number of pte which wouldn't be looked > up before. True, but I don't know how large of a performance hit the system takes. > Given that the leak is, as you say, temporary, and that the le

Re: [PATCH] mm/memory.c, 2.4.1 : memory leak with swap cache (updated)

> 1. we take an extra reference on the page, how does that >affect the test for if the page is shared or not ? is_page_shared expects us to have our own reference to the page. > 2. we call delete_from_swap_cache with the pagemap_lru_lock >held, since this tries to grab the pagecache_lock