From: Chen Gang <gang.chen@asianux.com>
To: Hugh Dickins <hughd@google.com>
Cc: uml-devel <user-mode-linux-devel@lists.sourceforge.net>,
Richard Weinberger <richard@nod.at>,
Jeff Dike <jdike@addtoit.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
uml-user <user-mode-linux-user@lists.sourceforge.net>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [uml-devel] [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte()
Date: Fri, 15 Nov 2013 10:14:36 +0800 [thread overview]
Message-ID: <5285838C.6070508@asianux.com> (raw)
In-Reply-To: <52847CD5.1030105@asianux.com>
On 11/14/2013 03:33 PM, Chen Gang wrote:
> On 11/14/2013 02:48 PM, Chen Gang wrote:
>>> >From the look of it, if an error did occur in init_stub_pte(),
>>>> then the special mapping of STUB_CODE and STUB_DATA would not
>>>> be installed, so this area would be invisible to munmap and exit,
>>>> and with your patch then the pages allocated likely to be leaked.
>>>>
>> It sounds reasonable to me: "although 'pgd' related with 'mm', but they
>> are not installed". But just like you said originally: "better get ACK
>> from some mm guys".
>>
>>
>> Hmm... is it another issue: "after STUB_CODE succeeds, but STUB_DATA
>> fails, the STUB_CODE will be leaked".
>>
>>
>>>> Which is not to say that the existing code is actually correct:
>>>> you're probably right that it's technically wrong. But it would
>>>> be very hard to get init_stub_pte() to fail, and has anyone
>>>> reported a problem with it? My guess is not, and my own
>>>> inclination to dabble here is zero.
>>>>
>> Yeah.
>>
>
> If we can not get ACK from any mm guys, and we have no enough time
> resource to read related source code, for me, I still recommend to
> remove p?d_free() in failure processing.
>
Oh, I am very sorry to Hugh and Richard, I make a mistake in common
sense: I recognized incorrect members (I treated Hugh as Richard), Hugh
is "mm guys".
Next time, I should see the mail carefully, not only for contents, but
also for senders.
Sorry again to both of you.
Thanks.
> In the worst cases, we will leak a little memory, and no any other
> negative effect, it is an executable way which is no any risks.
>
> For current mm implementation, it seems we can not assume any thing,
> although they sounds (or should be) reasonable (include what you said
> about mm).
>
>
> Thanks.
>
--
Chen Gang
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
WARNING: multiple messages have this Message-ID (diff)
From: Chen Gang <gang.chen@asianux.com>
To: Hugh Dickins <hughd@google.com>
Cc: Jeff Dike <jdike@addtoit.com>,
Richard Weinberger <richard@nod.at>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
uml-devel <user-mode-linux-devel@lists.sourceforge.net>,
uml-user <user-mode-linux-user@lists.sourceforge.net>
Subject: Re: [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte()
Date: Fri, 15 Nov 2013 10:14:36 +0800 [thread overview]
Message-ID: <5285838C.6070508@asianux.com> (raw)
In-Reply-To: <52847CD5.1030105@asianux.com>
On 11/14/2013 03:33 PM, Chen Gang wrote:
> On 11/14/2013 02:48 PM, Chen Gang wrote:
>>> >From the look of it, if an error did occur in init_stub_pte(),
>>>> then the special mapping of STUB_CODE and STUB_DATA would not
>>>> be installed, so this area would be invisible to munmap and exit,
>>>> and with your patch then the pages allocated likely to be leaked.
>>>>
>> It sounds reasonable to me: "although 'pgd' related with 'mm', but they
>> are not installed". But just like you said originally: "better get ACK
>> from some mm guys".
>>
>>
>> Hmm... is it another issue: "after STUB_CODE succeeds, but STUB_DATA
>> fails, the STUB_CODE will be leaked".
>>
>>
>>>> Which is not to say that the existing code is actually correct:
>>>> you're probably right that it's technically wrong. But it would
>>>> be very hard to get init_stub_pte() to fail, and has anyone
>>>> reported a problem with it? My guess is not, and my own
>>>> inclination to dabble here is zero.
>>>>
>> Yeah.
>>
>
> If we can not get ACK from any mm guys, and we have no enough time
> resource to read related source code, for me, I still recommend to
> remove p?d_free() in failure processing.
>
Oh, I am very sorry to Hugh and Richard, I make a mistake in common
sense: I recognized incorrect members (I treated Hugh as Richard), Hugh
is "mm guys".
Next time, I should see the mail carefully, not only for contents, but
also for senders.
Sorry again to both of you.
Thanks.
> In the worst cases, we will leak a little memory, and no any other
> negative effect, it is an executable way which is no any risks.
>
> For current mm implementation, it seems we can not assume any thing,
> although they sounds (or should be) reasonable (include what you said
> about mm).
>
>
> Thanks.
>
--
Chen Gang
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Chen Gang <gang.chen@asianux.com>
To: Hugh Dickins <hughd@google.com>
Cc: Jeff Dike <jdike@addtoit.com>,
Richard Weinberger <richard@nod.at>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
uml-devel <user-mode-linux-devel@lists.sourceforge.net>,
uml-user <user-mode-linux-user@lists.sourceforge.net>
Subject: Re: [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte()
Date: Fri, 15 Nov 2013 10:14:36 +0800 [thread overview]
Message-ID: <5285838C.6070508@asianux.com> (raw)
In-Reply-To: <52847CD5.1030105@asianux.com>
On 11/14/2013 03:33 PM, Chen Gang wrote:
> On 11/14/2013 02:48 PM, Chen Gang wrote:
>>> >From the look of it, if an error did occur in init_stub_pte(),
>>>> then the special mapping of STUB_CODE and STUB_DATA would not
>>>> be installed, so this area would be invisible to munmap and exit,
>>>> and with your patch then the pages allocated likely to be leaked.
>>>>
>> It sounds reasonable to me: "although 'pgd' related with 'mm', but they
>> are not installed". But just like you said originally: "better get ACK
>> from some mm guys".
>>
>>
>> Hmm... is it another issue: "after STUB_CODE succeeds, but STUB_DATA
>> fails, the STUB_CODE will be leaked".
>>
>>
>>>> Which is not to say that the existing code is actually correct:
>>>> you're probably right that it's technically wrong. But it would
>>>> be very hard to get init_stub_pte() to fail, and has anyone
>>>> reported a problem with it? My guess is not, and my own
>>>> inclination to dabble here is zero.
>>>>
>> Yeah.
>>
>
> If we can not get ACK from any mm guys, and we have no enough time
> resource to read related source code, for me, I still recommend to
> remove p?d_free() in failure processing.
>
Oh, I am very sorry to Hugh and Richard, I make a mistake in common
sense: I recognized incorrect members (I treated Hugh as Richard), Hugh
is "mm guys".
Next time, I should see the mail carefully, not only for contents, but
also for senders.
Sorry again to both of you.
Thanks.
> In the worst cases, we will leak a little memory, and no any other
> negative effect, it is an executable way which is no any risks.
>
> For current mm implementation, it seems we can not assume any thing,
> although they sounds (or should be) reasonable (include what you said
> about mm).
>
>
> Thanks.
>
--
Chen Gang
next prev parent reply other threads:[~2013-11-15 2:14 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-15 10:34 [PATCH] mm: revert mremap pud_free anti-fix Hugh Dickins
2013-10-15 10:34 ` Hugh Dickins
2013-10-15 11:46 ` Chen Gang
2013-10-15 11:46 ` Chen Gang
2013-11-13 7:15 ` Chen Gang
2013-11-13 7:15 ` Chen Gang
2013-11-13 5:06 ` [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte() Chen Gang
2013-11-13 5:06 ` Chen Gang
2013-11-13 9:07 ` [uml-devel] " Richard Weinberger
2013-11-13 9:07 ` Richard Weinberger
2013-11-13 9:07 ` Richard Weinberger
2013-11-13 9:14 ` [uml-devel] " Chen Gang
2013-11-13 9:14 ` Chen Gang
2013-11-13 9:14 ` Chen Gang
2013-11-14 5:20 ` Hugh Dickins
2013-11-14 5:20 ` Hugh Dickins
2013-11-14 5:20 ` Hugh Dickins
2013-11-14 6:48 ` Chen Gang
2013-11-14 6:48 ` Chen Gang
2013-11-14 6:48 ` Chen Gang
2013-11-14 7:33 ` Chen Gang
2013-11-14 7:33 ` Chen Gang
2013-11-14 7:55 ` Richard Weinberger
2013-11-14 7:55 ` Richard Weinberger
2013-11-14 8:57 ` Chen Gang
2013-11-14 8:57 ` Chen Gang
2013-11-15 2:14 ` Chen Gang [this message]
2013-11-15 2:14 ` Chen Gang
2013-11-15 2:14 ` Chen Gang
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=5285838C.6070508@asianux.com \
--to=gang.chen@asianux.com \
--cc=akpm@linux-foundation.org \
--cc=hughd@google.com \
--cc=jdike@addtoit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=richard@nod.at \
--cc=user-mode-linux-devel@lists.sourceforge.net \
--cc=user-mode-linux-user@lists.sourceforge.net \
/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.