On Thu, Jul 26, 2012 at 05:00:28PM -0400, Rik van Riel wrote:
> On 07/20/2012 09:49 AM, Mel Gorman wrote:
> >This V2 is still the mmap_sem approach that fixes a potential deadlock
> >problem pointed out by Michal.
>
> Larry and I were looking around the hugetlb code some
> more, and found what
On Thu, Jul 26, 2012 at 12:01:04PM -0400, Larry Woodman wrote:
> On 07/20/2012 09:49 AM, Mel Gorman wrote:
> >+retry:
> > mutex_lock(>i_mmap_mutex);
> > vma_prio_tree_foreach(svma,,>i_mmap, idx, idx) {
> > if (svma == vma)
> > continue;
> >+if
On Thu, Jul 26, 2012 at 12:01:04PM -0400, Larry Woodman wrote:
On 07/20/2012 09:49 AM, Mel Gorman wrote:
+retry:
mutex_lock(mapping-i_mmap_mutex);
vma_prio_tree_foreach(svma,iter,mapping-i_mmap, idx, idx) {
if (svma == vma)
continue;
+
On Thu, Jul 26, 2012 at 05:00:28PM -0400, Rik van Riel wrote:
On 07/20/2012 09:49 AM, Mel Gorman wrote:
This V2 is still the mmap_sem approach that fixes a potential deadlock
problem pointed out by Michal.
Larry and I were looking around the hugetlb code some
more, and found what looks like
On Thu, 26 Jul 2012, Rik van Riel wrote:
> On 07/20/2012 09:49 AM, Mel Gorman wrote:
> > This V2 is still the mmap_sem approach that fixes a potential deadlock
> > problem pointed out by Michal.
>
> Larry and I were looking around the hugetlb code some
> more, and found what looks like yet
On 07/20/2012 09:49 AM, Mel Gorman wrote:
This V2 is still the mmap_sem approach that fixes a potential deadlock
problem pointed out by Michal.
Larry and I were looking around the hugetlb code some
more, and found what looks like yet another race.
In hugetlb_no_page, we have the following
On 07/20/2012 09:49 AM, Mel Gorman wrote:
+retry:
mutex_lock(>i_mmap_mutex);
vma_prio_tree_foreach(svma,,>i_mmap, idx, idx) {
if (svma == vma)
continue;
+ if (svma->vm_mm == vma->vm_mm)
+ continue;
+
+
On 07/20/2012 09:49 AM, Mel Gorman wrote:
+retry:
mutex_lock(mapping-i_mmap_mutex);
vma_prio_tree_foreach(svma,iter,mapping-i_mmap, idx, idx) {
if (svma == vma)
continue;
+ if (svma-vm_mm == vma-vm_mm)
+
On 07/20/2012 09:49 AM, Mel Gorman wrote:
This V2 is still the mmap_sem approach that fixes a potential deadlock
problem pointed out by Michal.
Larry and I were looking around the hugetlb code some
more, and found what looks like yet another race.
In hugetlb_no_page, we have the following
On Thu, 26 Jul 2012, Rik van Riel wrote:
On 07/20/2012 09:49 AM, Mel Gorman wrote:
This V2 is still the mmap_sem approach that fixes a potential deadlock
problem pointed out by Michal.
Larry and I were looking around the hugetlb code some
more, and found what looks like yet another race.
On Fri 20-07-12 15:37:53, Mel Gorman wrote:
> On Fri, Jul 20, 2012 at 04:29:20PM +0200, Michal Hocko wrote:
> > >
> > >
> > > Signed-off-by: Mel Gorman
> >
> > Yes this looks correct. mmap_sem will make sure that unmap_vmas and
> > free_pgtables are executed atomicaly wrt. huge_pmd_share so it
On Fri, Jul 20, 2012 at 04:29:20PM +0200, Michal Hocko wrote:
> >
> >
> > Signed-off-by: Mel Gorman
>
> Yes this looks correct. mmap_sem will make sure that unmap_vmas and
> free_pgtables are executed atomicaly wrt. huge_pmd_share so it doesn't
> see non-NULL spte on the way out.
Yes.
> I am
On Fri 20-07-12 15:11:08, Mel Gorman wrote:
> Sorry for the resend, I did not properly refresh Cong Wang's suggested
> fix. This V2 is still the mmap_sem approach that fixes a potential deadlock
> problem pointed out by Michal.
>
> Changelog since V1
> o Correct cut error in race description
Sorry for the resend, I did not properly refresh Cong Wang's suggested
fix. This V2 is still the mmap_sem approach that fixes a potential deadlock
problem pointed out by Michal.
Changelog since V1
o Correct cut error in race description (hugh)
o Handle potential deadlock during
This V2 is still the mmap_sem approach that fixes a potential deadlock
problem pointed out by Michal.
Changelog since V1
o Correct cut error in race description (hugh)
o Handle potential deadlock during fork(mhocko)
o Reorder unlocking
This V2 is still the mmap_sem approach that fixes a potential deadlock
problem pointed out by Michal.
Changelog since V1
o Correct cutpaste error in race description (hugh)
o Handle potential deadlock during fork(mhocko)
o Reorder unlocking
Sorry for the resend, I did not properly refresh Cong Wang's suggested
fix. This V2 is still the mmap_sem approach that fixes a potential deadlock
problem pointed out by Michal.
Changelog since V1
o Correct cutpaste error in race description (hugh)
o Handle potential deadlock
On Fri 20-07-12 15:11:08, Mel Gorman wrote:
Sorry for the resend, I did not properly refresh Cong Wang's suggested
fix. This V2 is still the mmap_sem approach that fixes a potential deadlock
problem pointed out by Michal.
Changelog since V1
o Correct cutpaste error in race description
On Fri, Jul 20, 2012 at 04:29:20PM +0200, Michal Hocko wrote:
SNIP
Signed-off-by: Mel Gorman mgor...@suse.de
Yes this looks correct. mmap_sem will make sure that unmap_vmas and
free_pgtables are executed atomicaly wrt. huge_pmd_share so it doesn't
see non-NULL spte on the way out.
On Fri 20-07-12 15:37:53, Mel Gorman wrote:
On Fri, Jul 20, 2012 at 04:29:20PM +0200, Michal Hocko wrote:
SNIP
Signed-off-by: Mel Gorman mgor...@suse.de
Yes this looks correct. mmap_sem will make sure that unmap_vmas and
free_pgtables are executed atomicaly wrt. huge_pmd_share so
20 matches
Mail list logo
