[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6dd844f7-d43b-c744-f295-9f14c68d3928@redhat.com>
Date: Tue, 21 Mar 2023 15:19:18 +0100
From: David Hildenbrand <david@...hat.com>
To: mawupeng <mawupeng1@...wei.com>, akpm@...ux-foundation.org
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
kuleshovmail@...il.com, aneesh.kumar@...ux.ibm.com
Subject: Re: [PATCH v4 1/4] mm/mlock: return EINVAL if len overflows for
mlock/munlock
On 21.03.23 08:44, mawupeng wrote:
>
>
> On 2023/3/20 18:54, David Hildenbrand wrote:
>> On 20.03.23 03:47, Wupeng Ma wrote:
>>> From: Ma Wupeng <mawupeng1@...wei.com>
>>>
>>> While testing mlock, we have a problem if the len of mlock is ULONG_MAX.
>>> The return value of mlock is zero. But nothing will be locked since the
>>> len in do_mlock overflows to zero due to the following code in mlock:
>>>
>>> len = PAGE_ALIGN(len + (offset_in_page(start)));
>>>
>>> The same problem happens in munlock.
>>>
>>> Add new check and return -EINVAL to fix this overflowing scenarios since
>>> they are absolutely wrong.
>>
>> Thinking again, wouldn't we reject mlock(0, ULONG_MAX) now as well?
>
> mlock will return 0 if len is zero which is the same w/o this patchset.
> Here is the calltrace if len is zero.
>
> mlock(len == 0)
> do_mlock(len == 0)
> if (!len)
> return 0
>
I was asking about addr=0, len=ULONG_MAX.
IIUC, that used to work but could now fail? I haven't played with it,
though.
--
Thanks,
David / dhildenb
Powered by blists - more mailing lists