Re: [PATCH] mm: fix potential pte_unmap_unlock pte error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2020-10-15 14:15, Shijie Luo wrote:
When flags don't have MPOL_MF_MOVE or MPOL_MF_MOVE_ALL bits, code breaks and passing origin pte - 1 to pte_unmap_unlock seems like not a good idea.

Signed-off-by: Shijie Luo <luoshijie1@xxxxxxxxxx>
Signed-off-by: linmiaohe <linmiaohe@xxxxxxxxxx>
---
 mm/mempolicy.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 3fde772ef5ef..01f088630d1d 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -571,7 +571,11 @@ static int queue_pages_pte_range(pmd_t *pmd,
unsigned long addr,
 		} else
 			break;
 	}
-	pte_unmap_unlock(pte - 1, ptl);
+
+	if (addr >= end)
+		pte = pte - 1;
+
+	pte_unmap_unlock(pte, ptl);

But this is still wrong, isn't it?
Unless I am missing something, this is "only" important under CONFIG_HIGHPTE.

We have:

pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl);

which under CONFIG_HIGHPTE does a kmap_atomoc.

Now, we either break the loop in the first pass because of !(MPOL_MF_MOVE | MPOL_MF_MOVE_ALL),
or we keep incrementing pte by every pass.
Either way is wrong, because the pointer kunmap_atomic gets will not be the same (since we incremented pte).

Or is the loop meant to be running only once, so pte - 1 will bring us back to the original pte?






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux