All of lore.kernel.org
 help / color / mirror / Atom feed
From: axie <axie@amd.com>
To: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Alex Deucher <alexander.deucher@amd.com>,
	"Writer, Tim" <Tim.Writer@amd.com>,
	linux-mm@kvack.org, "Xie, AlexBin" <AlexBin.Xie@amd.com>
Subject: Re: A possible bug: Calling mutex_lock while holding spinlock
Date: Tue, 8 Aug 2017 12:51:15 -0400	[thread overview]
Message-ID: <fc466bf4-a658-f343-43f1-7e2f7ecb5d63@amd.com> (raw)
In-Reply-To: <6027ba44-d3ca-9b0b-acdf-f2ec39f01929@amd.com>

[-- Attachment #1: Type: text/plain, Size: 5085 bytes --]

Hi Kirill,

Here is the result from the user:"This patch does appear fix the issue."

Thanks,

Alex (Bin) Xie


On 2017-08-04 10:03 AM, axie wrote:
> Hi Kirill,
>
>
> Thanks for the patch. I have sent the patch to the user asking whether 
> he can give it a try.
>
>
> Regards,
>
> Alex (Bin) Xie
>
>
>
> On 2017-08-04 09:49 AM, Kirill A. Shutemov wrote:
>> On Thu, Aug 03, 2017 at 03:39:02PM -0700, Andrew Morton wrote:
>>> (cc Kirill)
>>>
>>> On Thu, 3 Aug 2017 12:35:28 -0400 axie <axie@amd.com> wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>>
>>>> I got a report yesterday with "BUG: sleeping function called from
>>>> invalid context at kernel/locking/mutex.c"
>>>>
>>>> I checked the relevant functions for the issue. Function
>>>> page_vma_mapped_walk did acquire spinlock. Later, in MMU notifier,
>>>> amdgpu_mn_invalidate_page called function mutex_lock, which triggered
>>>> the "bug".
>>>>
>>>> Function page_vma_mapped_walk was introduced recently by you in commit
>>>> c7ab0d2fdc840266b39db94538f74207ec2afbf6 and
>>>> ace71a19cec5eb430207c3269d8a2683f0574306.
>>>>
>>>> Would you advise how to proceed with this bug? Change
>>>> page_vma_mapped_walk not to use spinlock? Or change
>>>> amdgpu_mn_invalidate_page to use spinlock to meet the change, or
>>>> something else?
>>>>
>>> hm, as far as I can tell this was an unintended side-effect of
>>> c7ab0d2fd ("mm: convert try_to_unmap_one() to use
>>> page_vma_mapped_walk()").  Before that patch,
>>> mmu_notifier_invalidate_page() was not called under page_table_lock.
>>> After that patch, mmu_notifier_invalidate_page() is called under
>>> page_table_lock.
>>>
>>> Perhaps Kirill can suggest a fix?
>> Sorry for this.
>>
>> What about the patch below?
>>
>>  From f48dbcdd0ed83dee9a157062b7ca1e2915172678 Mon Sep 17 00:00:00 2001
>> From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
>> Date: Fri, 4 Aug 2017 16:37:26 +0300
>> Subject: [PATCH] rmap: do not call mmu_notifier_invalidate_page() 
>> under ptl
>>
>> MMU notifiers can sleep, but in page_mkclean_one() we call
>> mmu_notifier_invalidate_page() under page table lock.
>>
>> Let's instead use mmu_notifier_invalidate_range() outside
>> page_vma_mapped_walk() loop.
>>
>> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>> Fixes: c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use 
>> page_vma_mapped_walk()")
>> ---
>>   mm/rmap.c | 21 +++++++++++++--------
>>   1 file changed, 13 insertions(+), 8 deletions(-)
>>
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index ced14f1af6dc..b4b711a82c01 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -852,10 +852,10 @@ static bool page_mkclean_one(struct page *page, 
>> struct vm_area_struct *vma,
>>           .flags = PVMW_SYNC,
>>       };
>>       int *cleaned = arg;
>> +    bool invalidation_needed = false;
>>         while (page_vma_mapped_walk(&pvmw)) {
>>           int ret = 0;
>> -        address = pvmw.address;
>>           if (pvmw.pte) {
>>               pte_t entry;
>>               pte_t *pte = pvmw.pte;
>> @@ -863,11 +863,11 @@ static bool page_mkclean_one(struct page *page, 
>> struct vm_area_struct *vma,
>>               if (!pte_dirty(*pte) && !pte_write(*pte))
>>                   continue;
>>   -            flush_cache_page(vma, address, pte_pfn(*pte));
>> -            entry = ptep_clear_flush(vma, address, pte);
>> +            flush_cache_page(vma, pvmw.address, pte_pfn(*pte));
>> +            entry = ptep_clear_flush(vma, pvmw.address, pte);
>>               entry = pte_wrprotect(entry);
>>               entry = pte_mkclean(entry);
>> -            set_pte_at(vma->vm_mm, address, pte, entry);
>> +            set_pte_at(vma->vm_mm, pvmw.address, pte, entry);
>>               ret = 1;
>>           } else {
>>   #ifdef CONFIG_TRANSPARENT_HUGE_PAGECACHE
>> @@ -877,11 +877,11 @@ static bool page_mkclean_one(struct page *page, 
>> struct vm_area_struct *vma,
>>               if (!pmd_dirty(*pmd) && !pmd_write(*pmd))
>>                   continue;
>>   -            flush_cache_page(vma, address, page_to_pfn(page));
>> -            entry = pmdp_huge_clear_flush(vma, address, pmd);
>> +            flush_cache_page(vma, pvmw.address, page_to_pfn(page));
>> +            entry = pmdp_huge_clear_flush(vma, pvmw.address, pmd);
>>               entry = pmd_wrprotect(entry);
>>               entry = pmd_mkclean(entry);
>> -            set_pmd_at(vma->vm_mm, address, pmd, entry);
>> +            set_pmd_at(vma->vm_mm, pvmw.address, pmd, entry);
>>               ret = 1;
>>   #else
>>               /* unexpected pmd-mapped page? */
>> @@ -890,11 +890,16 @@ static bool page_mkclean_one(struct page *page, 
>> struct vm_area_struct *vma,
>>           }
>>             if (ret) {
>> -            mmu_notifier_invalidate_page(vma->vm_mm, address);
>>               (*cleaned)++;
>> +            invalidation_needed = true;
>>           }
>>       }
>>   +    if (invalidation_needed) {
>> +        mmu_notifier_invalidate_range(vma->vm_mm, address,
>> +                address + (1UL << compound_order(page)));
>> +    }
>> +
>>       return true;
>>   }
>


[-- Attachment #2: Type: text/html, Size: 8922 bytes --]

  reply	other threads:[~2017-08-08 16:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2d442de2-c5d4-ecce-2345-4f8f34314247@amd.com>
     [not found] ` <20170803153902.71ceaa3b435083fc2e112631@linux-foundation.org>
2017-08-04 13:49   ` A possible bug: Calling mutex_lock while holding spinlock Kirill A. Shutemov
2017-08-04 14:03     ` axie
2017-08-08 16:51       ` axie [this message]
2017-08-08 17:01         ` Kirill A. Shutemov
2017-08-08 20:29           ` Kirill A. Shutemov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fc466bf4-a658-f343-43f1-7e2f7ecb5d63@amd.com \
    --to=axie@amd.com \
    --cc=AlexBin.Xie@amd.com \
    --cc=Tim.Writer@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.deucher@amd.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.