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 have to skip them
to let exit_mmap() or do_munmap() to process it.
According to Documentation/vm/locking, 'mm-page_table_lock'
On 11/14/2013 03:55 PM, Richard Weinberger wrote:
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
On 11/14/2013 03:33 PM, Chen Gang wrote:
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
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_table_lock'
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 likely to be
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 with your patch
