[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f9ee08f81b3c114b015643e1fca5b7a9@suse.de>
Date: Thu, 10 Jan 2019 11:08:52 +0100
From: Roman Penyaev <rpenyaev@...e.de>
To: Matthew Wilcox <willy@...radead.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Michal Hocko <mhocko@...e.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Joe Perches <joe@...ches.com>,
"Luis R. Rodriguez" <mcgrof@...nel.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 03/15] mm/vmalloc: introduce new vrealloc() call and
its subsidiary reach analog
On 2019-01-09 17:50, Matthew Wilcox wrote:
> On Wed, Jan 09, 2019 at 05:40:13PM +0100, Roman Penyaev wrote:
>> Basically vrealloc() repeats glibc realloc() with only one big
>> difference:
>> old area is not freed, i.e. caller is responsible for calling vfree()
>> in
>> case of successfull reallocation.
>
> Ouch. Don't call it the same thing when you're providing such
> different
> semantics. I agree with you that the new semantics are useful ones,
> I just want it called something else. Maybe vcopy()? vclone()?
vclone(). I like vclone(). But Linus does not like this reallocation
under the hood for epoll (where this vrealloc() should have been used),
so seems that won't be needed at all.
>
>> + * Do not forget to call vfree() passing old address. But careful,
>> + * calling vfree() from interrupt will cause vfree_deferred() call,
>> + * which in its turn uses freed address as a temporal pointer for a
>
> "temporary", not temporal.
Ha! Now I got the difference. Thanks, Mathew :)
>
>> + * llist element, i.e. memory will be corrupted.
--
Roman
Powered by blists - more mailing lists