From: Michal Hocko <mhocko@kernel.org>
To: Chen Gang <gang.chen.5i5j@qq.com>
Cc: Chen Gang <xili_gchen_5257@hotmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
"kirill.shutemov@linux.intel.com"
<kirill.shutemov@linux.intel.com>,
"riel@redhat.com" <riel@redhat.com>,
"sasha.levin@oracle.com" <sasha.levin@oracle.com>,
"gang.chen.5i5j@gmail.com" <gang.chen.5i5j@gmail.com>,
Linux Memory <linux-mm@kvack.org>,
kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: mmap: Check all failures before set values
Date: Tue, 25 Aug 2015 13:35:21 +0200 [thread overview]
Message-ID: <20150825113521.GA6285@dhcp22.suse.cz> (raw)
In-Reply-To: <55DB9278.2020603@qq.com>
On Tue 25-08-15 05:54:00, Chen Gang wrote:
> On 8/24/15 21:57, Michal Hocko wrote:
> > On Mon 24-08-15 21:34:25, Chen Gang wrote:
>
> [...]
>
>
> >> It is always a little better to let the external function suppose fewer
> >> callers' behalf.
> >
> > I am sorry but I do not understand what you are saying here.
> >
>
> Execuse me, my English maybe be still not quite well, my meaning is:
>
> - For the external functions (e.g. insert_vm_struct in our case), as a
> callee, it may have to supose something from the caller.
>
> - If we can keep callee's functional contents no touch, a little fewer
> supposing will let callee a little more independent from caller.
>
> - If can keep functional contens no touch, the lower dependency between
> caller and callee is always better.
OK, I guess I understand what you mean. You are certainly right that a
partial initialization for the failure case is not nice in general. I
was just objecting that the callers are supposed to free the vma in
the failure case so any partial initialization doesn't matter in this
particular case.
Your patch would be more sensible if the failure case was more
likely. But this function is used for special mappings (vdso, temporary
vdso stack) which are created early in the process life time so both
failure paths are highly unlikely. If this was a part of a larger
changes where the function would be used elsewhere I wouldn't object at
all.
The reason I am skeptical about such changes in general is that
the effect is very marginal while it increases chances of the code
conflicts.
But as I've said, if others feel this is worthwhile I will not object.
--
Michal Hocko
SUSE Labs
--
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>
next prev parent reply other threads:[~2015-08-25 11:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-23 16:59 [PATCH] mm: mmap: Check all failures before set values gang.chen.5i5j
2015-08-24 11:32 ` Michal Hocko
[not found] ` <55DB1D94.3050404@hotmail.com>
2015-08-24 13:34 ` Chen Gang
2015-08-24 13:57 ` Michal Hocko
2015-08-24 21:54 ` Chen Gang
2015-08-25 11:35 ` Michal Hocko [this message]
[not found] ` <55DCDF7E.6080402@hotmail.com>
2015-08-25 21:33 ` Chen Gang
2015-08-24 21:25 ` Andrew Morton
[not found] ` <55DB93B2.9010705@hotmail.com>
2015-08-24 21:58 ` Chen Gang
-- strict thread matches above, loose matches on Subject: below --
2015-08-23 16:57 gang.chen.5i5j
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=20150825113521.GA6285@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=gang.chen.5i5j@gmail.com \
--cc=gang.chen.5i5j@qq.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
--cc=sasha.levin@oracle.com \
--cc=xili_gchen_5257@hotmail.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;
as well as URLs for NNTP newsgroup(s).