Re: filemap.c SMP bug in 2.4.0-test* (fwd)

Re: filemap.c SMP bug in 2.4.0-test* (fwd)

[Rik van Riel]

Hi,

it seems that Roger has done some deep puzzling today...
I'm not sure if he found something or not, could somebody
else with a more intimate knowledge of the source take a
look at Roger's idea?

thanks,

Rik
---------- Forwarded message ----------
Date: Fri, 18 Aug 2000 00:25:03 +0200
From: Roger Larsson <roger.larsson@norran.net>
To: Rik van Riel <riel@conectiva.com.br>
Subject: Re: filemap.c SMP bug in 2.4.0-test*

Rik van Riel wrote:
> 
> On Fri, 18 Aug 2000, Roger Larsson wrote:
> 
> > One question to ask is what will happen if
> > there are two threads both requesting the
> > same swap page at almost the same time?
> > (a process forking, both threads continue to run
> >  on both processors, both ends up in page fault...)
> >
> > there might then be a possibility for a race with
> > the indicated code and the lookup_swap_cache call
> > chain (first fails, second lookup_swap_cache runs
> > before page is fully added...)
> 
> The adding happens completely under the pagecache_lock,
> so either it is added or it is not, intermediate states
> are not visible to the other cpus...
> 

But I am considering the possibility that __find_page_nolock
is run before the page is actually added. Page gets added
slightly after.

Proc A                                Proc B
page faults
...
read_swap_cache_async
  lookup_swap_cache fails twice       page faults (same page)
                                      ...
                                      read_swap_cache_async
  init of page info (insert in
  hash tables...)

                                      lookup_swap_cache
	                                 __find_page_nolock
                                         (succeeds, page not active
                                          activate)

  lru_cache_add (OUCH)


Is this scenario possible?
I will check tomorrow...


/RogerL


> add_to_page_cache_unique should handle this situation
> just fine ... should and probably does, but I'm still
> not 100% sure ;)
> 
> regards,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>        -- Miguel de Icaza, UKUUG 2000
> 
> http://www.conectiva.com/               http://www.surriel.com/

--
Home page:
  http://www.norran.net/nra02596/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: filemap.c SMP bug in 2.4.0-test* (fwd)

[Stephen C. Tweedie]

Hi,

On Thu, Aug 17, 2000 at 08:18:39PM -0300, Rik van Riel wrote:
> 
> it seems that Roger has done some deep puzzling today...
> I'm not sure if he found something or not, could somebody
> else with a more intimate knowledge of the source take a
> look at Roger's idea?

Yes, it looks correct --- read_swap_cache_async() should be using
__find_page_nolock, I think.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: filemap.c SMP bug in 2.4.0-test* (fwd)

[Andrea Arcangeli]

>Proc A                                Proc B
>page faults
>...
>read_swap_cache_async
>  lookup_swap_cache fails twice       page faults (same page)
>                                      ...
>                                      read_swap_cache_async
>  init of page info (insert in
>  hash tables...)

as first on proc B read_swap_cache_async can't be started in between the
second fail of the lookup and the init of the page info and insert
hashtables on proc A, because of the big kernel lock.

>                                      lookup_swap_cache
>	                                 __find_page_nolock
>                                         (succeeds, page not active
>                                          activate)
>

The page is inserted locked into the hashtable and lookup_swap_cache uses
find_lock_page so it can't race.

Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/