From: "guominchen(陈国民)" <guominchen@tencent.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
"gchen.guomin@gmail.com" <gchen.guomin@gmail.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jason Wang <jasowang@redhat.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"paulmck@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>
Subject: 答复: [PATCH] Fix mm->owner point to a task that does not exists(Internet mail)
Date: Mon, 10 Dec 2018 03:14:10 +0000 [thread overview]
Message-ID: <0D556C4F8D27C74EB25927291B4B0602A90358@EXMBX-SZ087.tencent.com> (raw)
In-Reply-To: <20181209201309-mutt-send-email-mst@kernel.org>
>> From: guominchen <guominchen@tencent.com>
>>
>> Under normal circumstances,When do_exit exits, mm->owner will
>> be updated, but when the kernel process calls unuse_mm and exits,
>> mm->owner cannot be updated. And will point to a task that has
>> been released.
>>
>> Below is my issue on vhost_net:
>> A, B are two kernel processes(such as vhost_worker),
>> C is a user space process(such as qemu), and all
>> three use the mm of the user process C.
>> Now, because user process C exits abnormally, the owner of this
>> mm becomes A. When A calls unuse_mm and exits, this mm->ower
>> still points to the A that has been released.
>> When B accesses this mm->owner again, A has been released.
>>
>> Process A Process B
>> vhost_worker() vhost_worker()
>> --------- ---------
>> use_mm() use_mm()
>> ...
>> unuse_mm()
>> tsk->mm=NULL
>> do_exit() page fault
>> exit_mm() access mm->owner
>> can't update owner kernel Oops
>>
>> unuse_mm()
>>
>> Cc: <linux-mm@kvack.org>
>> Cc: <linux-kernel@vger.kernel.org>
>> Cc: "Michael S. Tsirkin" <mst@redhat.com>
>> Cc: Jason Wang <jasowang@redhat.com>
>> Cc: <netdev@vger.kernel.org>
>> Signed-off-by: guominchen <guominchen@tencent.com>
>> ---
>> mm/mmu_context.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/mm/mmu_context.c b/mm/mmu_context.c index
>> 3e612ae..185bb23 100644
>> --- a/mm/mmu_context.c
>> +++ b/mm/mmu_context.c
>> @@ -56,7 +56,6 @@ void unuse_mm(struct mm_struct *mm)
>>
>> task_lock(tsk);
>> sync_mm_rss(mm);
>> - tsk->mm = NULL;
>> /* active_mm is still 'mm' */
>> enter_lazy_tlb(mm, tsk);
>> task_unlock(tsk);
>So that will work for vhost because we never drop the mm reference before destroying the task.
>I wonder whether that's true for other users though.
>It would seem cleaner to onvoke some callback so tasks such as vhost can drop the reference.
Yes, I can remove this call in vhost, but I think use_mm(), and unuse_mm() are called in pairs in
order to share mm.
And exit_mm() as a unified mm handler, it doing very well, So we should leave mm to exit_mm()
to handle it.
>And looking at all this code, I don't understand why is mm->owner safe to change like this:
> mm->owner = NULL;
>when users seem to use it under RCU.
I think that mm->owner=NULL just changes the value of the pointer, and the task_struct it points to
is present and not released.
>> --
>> 1.8.3.1
prev parent reply other threads:[~2018-12-10 3:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-09 7:21 [PATCH] Fix mm->owner point to a task that does not exists gchen.guomin
2018-12-10 1:36 ` Michael S. Tsirkin
2018-12-10 3:14 ` guominchen(陈国民) [this message]
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=0D556C4F8D27C74EB25927291B4B0602A90358@EXMBX-SZ087.tencent.com \
--to=guominchen@tencent.com \
--cc=gchen.guomin@gmail.com \
--cc=jasowang@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox