[<prev] [next>] [day] [month] [year] [list]
Message-ID: <COL130-W94C27965E980E171892A4B9610@phx.gbl>
Date: Wed, 26 Aug 2015 05:33:42 +0800
From: Chen Gang <xili_gchen_5257@...mail.com>
To: Michal Hocko <mhocko@...nel.org>, Chen Gang <gang.chen.5i5j@...com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
"riel@...hat.com" <riel@...hat.com>,
"sasha.levin@...cle.com" <sasha.levin@...cle.com>,
"gang.chen.5i5j@...il.com" <gang.chen.5i5j@...il.com>,
Linux Memory <linux-mm@...ck.org>,
kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mm: mmap: Check all failures before set values
On 8/25/15 19:35, Michal Hocko wrote:
>
> 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.
>
OK.
> 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.
>
OK, I can understand.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
Powered by blists - more mailing lists