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 42e4089
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 privileg
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 is
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 unchan
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
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 to pte_unmap_unlock.
Fixes: 42e4089c789 ("x86/speculation/l1tf: Dis
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
th
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
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 fla
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?
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
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 checki
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 MPOL_MF_MOVE,
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
---
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 ins
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 insertions(+), 1 deletion(-)
diff --git a/mm/
16 matches
Mail list logo
