[lkml]   [2000]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread

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:
> 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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.059 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site