Hi,
On Sun, Sep 03, 2000 at 05:47:01PM -0300, Rik van Riel wrote:
> On Sun, 3 Sep 2000, Alan Cox wrote:
>
> > Things like random memory corruption from dropping dirty bits,
> > and some of the others are far more serious showstoppers alas
>
> Indeed, there are 4 major issues left in the VM area:
>
[snip]
> 2) dirty bits can get lost, try_to_swap_out() and other
> places have a race with the hardware
>
> [from mm/vmscan.c, line 60 has a race with the /hardware/]
> 55 if (pte_young(pte)) {
> 56 /*
> 57 * Transfer the "accessed" bit from the page
> 58 * tables to the global page map.
> 59 */
> 60 set_pte(page_table, pte_mkold(pte));
> 61 SetPageReferenced(page);
> 62 goto out_failed;
> 63 }
I wonder about software races.
Page table manipulations in mm/memory.c are guarded by page_table_lock
against concurrent kswapd actions, with the following comments:
/*
* This is a long-lived spinlock. That's fine.
* There's no contention, because the page table
* lock only protects against kswapd anyway, and
* even if kswapd happened to be looking at this
* process we _want_ it to get stuck.
*/
and in the other place
*
* Note the "page_table_lock". It is to protect against kswapd removing
* pages from under us. Note that kswapd only ever _removes_ pages, never
* adds them. As such, once we have noticed that the page is not present,
* we can drop the lock early.
Fine. However, I don't see a trace of page_table_lock in swapping-out code!
And I don't see any other lock which may ensure the serialization.
Am I missing something?
Andrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
