bug in Documentation/vm/locking?

DISCUSSION Ed L Cashin 2 participants 2 messages Aug 19, 2003 – Aug 20, 2003 Memory management

Share & tools

Ed L Cashin

author

2003-08-19 13:44 UTC #0 lore raw

Hi. There is a strange sentence in Documentation/vm/locking, a very helpful summary of locking in the VM subsystem.

Rule number five of the rules for using page_table_lock and mmap_sem says "page_table_lock or page_table_lock". That's a funny thing to say, leading me to suspect that either it really should say "page_table_lock or mmap_sem" or just "page_table_lock" alone.

Here is the list of five rules. Rule number five is the one I'm talking about:

The rules are:
1. To scan the vmlist (look but don't touch) you must hold the

     mmap_sem with read bias, i.e. down_read(&mm->mmap_sem)

2. To modify the vmlist you need to hold the mmap_sem with read&write bias, i.e. down_write(&mm->mmap_sem) *AND* you need to take the page_table_lock.
3. The swapper takes _just_ the page_table_lock, this is done because the mmap_sem can be an extremely long lived lock and the swapper just cannot sleep on that.
4. The exception to this rule is expand_stack, which just takes the read lock and the page_table_lock, this is ok because it doesn't really modify fields anybody relies on.
5. You must be able to guarantee that while holding page_table_lock or page_table_lock of mm A, you will not try to get either lock for mm B.

So what should the rule say? If you hold A->mm->mmap_sem is it OK to take B->mm->mmap_sem and B->mm->mmap_sem as long as you can guarantee that B won't try to get either of those locks in A?

Signature · 8 lines

--Ed L Cashin            |   PGP public key:
  [email protected]        |   http://noserose.net/e/pgp/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to [email protected].  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Kanoj Sarcar

2003-08-20 08:05 UTC #1 lore raw

Quoted 35 lines · --- Ed L Cashin

Hi. There is a strange sentence in
Documentation/vm/locking, a very
helpful summary of locking in the VM subsystem.
Rule number five of the rules for using page_table_lock and mmap_sem
says "page_table_lock or page_table_lock". That's a funny thing to
say, leading me to suspect that either it really should say
"page_table_lock or mmap_sem" or just "page_table_lock" alone.
Here is the list of five rules. Rule number five is the one I'm
talking about:
The rules are:
1. To scan the vmlist (look but don't touch) you
must hold the
mmap_sem with read bias, i.e.
down_read(&mm->mmap_sem)
2. To modify the vmlist you need to hold the
mmap_sem with
     read&write bias, i.e. down_write(&mm->mmap_sem)
*AND*
you need to take the page_table_lock.
3. The swapper takes _just_ the page_table_lock,
this is done
because the mmap_sem can be an extremely long
lived lock
and the swapper just cannot sleep on that.
4. The exception to this rule is expand_stack,
which just
takes the read lock and the page_table_lock,

Quoted 8 lines

this is ok
because it doesn't really modify fields anybody
relies on.
5. You must be able to guarantee that while
holding page_table_lock
or page_table_lock of mm A, you will not try to
get either lock
for mm B.

Hi,

I can tell you that when I had sent the patch to add this "locking" writeup to Linus, rule 5 used to read:

5. You must be able to guarantee that while holding vmlist_modify_lock or vmlist_access_lock of mm A, you will not try to get either lock for mm B.

This was probably updated later on, as the kernel was changed. Hopefully, whoever updated it will fix the typo.

Quoted 6 lines

So what should the rule say? If you hold A->mm->mmap_sem is it OK to
take B->mm->mmap_sem and B->mm->mmap_sem as long as you can guarantee
that B won't try to get either of those locks in A?

The problem is in making that guarantee. At some point in the past, it used to be that A or B or any process could execute page stealer code, so there was a chance that deadlocks could happen; unless that has changed, or you can smartly determine that A is holding B's lock, so B should not try to get A's, this rule probably still applies to the relevant locks.

THanks.

Kanoj

Quoted 14 lines

Signature · 13 lines

-- 
--Ed L Cashin            |   PGP public key:
  [email protected]        |  
http://noserose.net/e/pgp/

--
To unsubscribe, send a message with 'unsubscribe
linux-mm' in
the body to [email protected].  For more info on
Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]">
[email protected] </a>

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>