Am 13.11.2013 06:06, schrieb Chen Gang:
> Unfortunately, p?d_alloc() and p?d_free() are not pair!! If p?d_alloc()
> succeed, they may be used, so in the next failure, we have to skip them
> to let exit_mmap() or do_munmap() to process it.
>
> According to "Documentation/vm/locking", 'mm->page_tabl
On 11/13/2013 05:07 PM, Richard Weinberger wrote:
> Am 13.11.2013 06:06, schrieb Chen Gang:
>> Unfortunately, p?d_alloc() and p?d_free() are not pair!! If p?d_alloc()
>> succeed, they may be used, so in the next failure, we have to skip them
>> to let exit_mmap() or do_munmap() to process it.
>>
>>
Firstly, thank you for spending your time resources to reply so many
details.
On 11/14/2013 01:20 PM, Hugh Dickins wrote:
> On Wed, 13 Nov 2013, Chen Gang wrote:
>
>> Unfortunately, p?d_alloc() and p?d_free() are not pair!! If p?d_alloc()
>> succeed, they may be used, so in the next failure, we
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 lik
Am 14.11.2013 08:33, schrieb Chen Gang:
> 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 w
