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

2021-01-24 Thread Miaohe Lin
Hi: On 2021/1/24 10:01, Andrew Morton wrote: > On Fri, 22 Jan 2021 16:27:23 +0800 Miaohe Lin wrote: > >> Hi Andrew: >> On 2021/1/14 10:51, Miaohe Lin wrote: >>> Hi: >>> On 2021/1/11 1:14, Andi Kleen wrote: On Sat, Jan 09, 2021 at 03:01:18AM -0500, Miaohe Lin wrote: > Since commit

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

2021-01-23 Thread Andrew Morton
On Fri, 22 Jan 2021 16:27:23 +0800 Miaohe Lin wrote: > Hi Andrew: > On 2021/1/14 10:51, Miaohe Lin wrote: > > Hi: > > On 2021/1/11 1:14, Andi Kleen wrote: > >> On Sat, Jan 09, 2021 at 03:01:18AM -0500, Miaohe Lin wrote: > >>> Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non

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

2021-01-22 Thread Miaohe Lin
Hi Andrew: On 2021/1/14 10:51, Miaohe Lin wrote: > Hi: > On 2021/1/11 1:14, Andi Kleen wrote: >> On Sat, Jan 09, 2021 at 03:01:18AM -0500, Miaohe Lin wrote: >>> Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged >>> high MMIO PROT_NONE mappings"), when the first pfn modify

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

2021-01-13 Thread Miaohe Lin
Hi: On 2021/1/11 1:14, Andi Kleen wrote: > On Sat, Jan 09, 2021 at 03:01:18AM -0500, Miaohe Lin wrote: >> Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged >> high MMIO PROT_NONE mappings"), when the first pfn modify is not allowed, >> we would break the loop with pte

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

2021-01-10 Thread Andi Kleen
On Sat, Jan 09, 2021 at 03:01:18AM -0500, Miaohe Lin wrote: > Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged > high MMIO PROT_NONE mappings"), when the first pfn modify is not allowed, > we would break the loop with pte unchanged. Then the wrong pte - 1 would > be passed

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

2020-10-16 Thread Shijie Luo
On 2020/10/16 22:05, osalva...@suse.de wrote: On 2020-10-16 15:42, Michal Hocko wrote: OK, I finally managed to convince my friday brain to think and grasped what the code is intended to do. The loop is hairy and we want to prevent from spurious EIO when all the pages are on a proper node. So

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

2020-10-16 Thread osalvador
On 2020-10-16 15:42, Michal Hocko wrote: OK, I finally managed to convince my friday brain to think and grasped what the code is intended to do. The loop is hairy and we want to prevent from spurious EIO when all the pages are on a proper node. So the check has to be done inside the loop. Anyway

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

2020-10-16 Thread Michal Hocko
On Fri 16-10-20 15:15:32, Michal Hocko wrote: > On Fri 16-10-20 15:11:17, Michal Hocko wrote: > > On Fri 16-10-20 14:37:08, osalva...@suse.de wrote: > > > On 2020-10-16 14:31, Michal Hocko wrote: > > > > I do not like the fix though. The code is really confusing. Why should > > > > we check for

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

2020-10-16 Thread Michal Hocko
On Fri 16-10-20 15:11:17, Michal Hocko wrote: > On Fri 16-10-20 14:37:08, osalva...@suse.de wrote: > > On 2020-10-16 14:31, Michal Hocko wrote: > > > I do not like the fix though. The code is really confusing. Why should > > > we check for flags in each iteration of the loop when it cannot change?

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

2020-10-16 Thread Michal Hocko
On Fri 16-10-20 14:37:08, osalva...@suse.de wrote: > On 2020-10-16 14:31, Michal Hocko wrote: > > I do not like the fix though. The code is really confusing. Why should > > we check for flags in each iteration of the loop when it cannot change? > > Also why should we take the ptl lock in the first

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

2020-10-16 Thread osalvador
On 2020-10-16 14:31, Michal Hocko wrote: I do not like the fix though. The code is really confusing. Why should we check for flags in each iteration of the loop when it cannot change? Also why should we take the ptl lock in the first place when the look is broken out immediately? About

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

2020-10-16 Thread Michal Hocko
On Thu 15-10-20 08:15:34, 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. Yes the code is suspicious to say the least. At least mbind can reach to here with both

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

2020-10-15 Thread Shijie Luo
On 2020/10/15 20:58, osalva...@suse.de wrote: 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 Signed-off-by: linmiaohe ---

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

2020-10-15 Thread osalvador
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 Signed-off-by: linmiaohe --- mm/mempolicy.c | 6 +- 1 file changed, 5