lkml.org 
[lkml]   [2001]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Deadlock on the mm->mmap_sem
Date
>
> I also don't think the hack is that bad. All it's doing is taking a
> copy of the process's VM decription so that it knows that
> nobody is going to modify it whilst a coredump is in progress.

You break the locking scheme of the mm structure.
Right now the rules are

1 get a mm_struct pointer by whatever means (walk the process list and
read task->mm, walk the mm_list)
2 increase mm_users
3 release the spinlock you acquired for 1
4 you can do with the result what you want.

With your patch applied, we would have to restrict rule 4 - at least
modifying the vma list is not possible anymore, probably further
changes.
AFAIK right now no external mm_struct user modifies the vma list, but it
could be a problem in the future.

>
> However, if you don't like that, how about just changing the lock on
> mm_struct to a special mm_struct-only type lock that has a
> recursive lock operation for use by the pagefault handler (and
> _only_ the pagefault handler)? I've attached a patch to do just that.
> This introduces five operations:

Does that solve the latency problem? That problem is pagefaults vs.
another operation.

--
Manfred


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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