Have any influence on set_memory_** about below patch ??

Hi,

Quoted 7 lines · zhong jiang

http://www.spinics.net/lists/arm-kernel/msg472090.html

Hi, Can I ask you a question? Say, This patch tells that the section spilting and merging wiil produce confilct in the liner mapping area. Based on the situation, Assume that set up page table in 4kb page table way in the liner mapping area, Does the set_memroy_** will work without any conplict??

I'm not sure I understand the question.

I'm also not a fan of responding to off-list queries as information gets lost.

Please ask your question on the mailing list. I am more than happy to respond there.

Thanks,
Mark.

.

Quoted 13 lines · Mark Rutland

Hi,

Quoted 7 lines · zhong jiang

http://www.spinics.net/lists/arm-kernel/msg472090.html

Hi, Can I ask you a question? Say, This patch tells that the section spilting and merging wiil produce confilct in the liner mapping area. Based on the situation, Assume that set up page table in 4kb page table way in the liner mapping area, Does the set_memroy_** will work without any conplict??

I'm not sure I understand the question.

Quoted 9 lines

I'm also not a fan of responding to off-list queries as information gets lost.

Please ask your question on the mailing list. I am more than happy to respond there.

Thanks,
Mark.

Hi Mark,

In your patch it said "The presence of conflicting TLB entries may result in a variety of behaviours detrimental to the system " and "but this(break-before-make approach) cannot work for modifications to the swapper page tables that cover the kernel text and data."

I'm not quite understand this, why the direct mapping can't work?

flush tlb can't resolve it?

I find x86 does not have this limit. e.g. set_memory_r*.

Quoted 25 lines · Xishi Qiu

Quoted 13 lines · Mark Rutland

Hi,

Quoted 7 lines · zhong jiang

http://www.spinics.net/lists/arm-kernel/msg472090.html

Hi, Can I ask you a question? Say, This patch tells that the section spilting and merging wiil produce confilct in the liner mapping area. Based on the situation, Assume that set up page table in 4kb page table way in the liner mapping area, Does the set_memroy_** will work without any conplict??

I'm not sure I understand the question.

Quoted 9 lines

I'm also not a fan of responding to off-list queries as information gets lost.

Please ask your question on the mailing list. I am more than happy to respond there.

Thanks,
Mark.

Quoted 8 lines

Hi Mark,

In your patch it said "The presence of conflicting TLB entries may result in a variety of behaviours detrimental to the system " and "but this(break-before-make approach) cannot work for modifications to the swapper page tables that cover the kernel text and data."

I'm not quite understand this, why the direct mapping can't work?

The problem is that the TLB hardware can operate asynchronously to the rest of the CPU. At any point in time, for any reason, it can decide to destroy TLB entries, to allocate new ones, or to perform a walk based on the existing contents of the TLB.

When the TLB contains conflicting entries, TLB lookups may result in TLB conflict aborts, or may return an "amalgamation" of the conflicting entries (e.g. you could get an erroneous output address).

The direct mapping is in active use (and hence live in TLBs). Modifying it without break-before-make (BBM) risks the allocation of conflicting TLB entries. Modifying it with BBM risks unmapping the portion of the kernel performing the modification, resulting in an unrecoverable abort.

Quoted 1 line

flush tlb can't resolve it?

Flushing the TLB doesn't help because the page table update, TLB invalidate, and corresponding barrier(s) are separate operations. The TLB can allocate or destroy entries at any point during the sequence.

For example, without BBM a page table update would look something like:

1) str <newpte>, [<*pte>]
2) dsb ish
3) tlbi vmalle1is
4) dsb ish
5) isb

After step 1, the new pte value may become visible to the TLBs, and the TLBs may allocate a new entry for it. Until step 4 completes, this entry may remain active in the TLB, and may conflict with an existing entry.

If that entry covers the kernel text for steps 2-5, executing the sequence may result in an unrecoverable TLB conflict abort, or some other behaviour resulting from an amalgamated TLB, e.g. the I-cache might fetch instructions from the wrong address such that steps 2-5 cannot be executed.

If the kernel doesn't explicitly access the address covered by that pte, there may still be a problem. The TLB may perform an internal lookup when performing a page table walk, and could then use an erroneous result to continue the walk, resulting in a variety of potential issues (e.g. reading from an MMIO peripheral register).

BBM avoids the conflict, but as that would mean kernel text and/or data would be unmapped, you can't execute the code to finish the update.

Quoted 1 line

I find x86 does not have this limit. e.g. set_memory_r*.

I don't know much about x86; it's probably worth asking the x86 guys about that. It may be that the x86 architecture requires that a conflict or amalgamation is never visible to software, or it could be that contemporary implementations happen to provide that property.

Thanks,
Mark.

.

Quoted 25 lines · Xishi Qiu

Quoted 13 lines · Mark Rutland

Hi,

Quoted 7 lines · zhong jiang

http://www.spinics.net/lists/arm-kernel/msg472090.html

Hi, Can I ask you a question? Say, This patch tells that the section spilting and merging wiil produce confilct in the liner mapping area. Based on the situation, Assume that set up page table in 4kb page table way in the liner mapping area, Does the set_memroy_** will work without any conplict??

I'm not sure I understand the question.

Quoted 9 lines

I'm also not a fan of responding to off-list queries as information gets lost.

Please ask your question on the mailing list. I am more than happy to respond there.

Thanks,
Mark.

Quoted 8 lines

Hi Mark,

In your patch it said "The presence of conflicting TLB entries may result in a variety of behaviours detrimental to the system " and "but this(break-before-make approach) cannot work for modifications to the swapper page tables that cover the kernel text and data."

I'm not quite understand this, why the direct mapping can't work?

The problem is that the TLB hardware can operate asynchronously to the rest of the CPU. At any point in time, for any reason, it can decide to destroy TLB entries, to allocate new ones, or to perform a walk based on the existing contents of the TLB.

When the TLB contains conflicting entries, TLB lookups may result in TLB conflict aborts, or may return an "amalgamation" of the conflicting entries (e.g. you could get an erroneous output address).

The direct mapping is in active use (and hence live in TLBs). Modifying it without break-before-make (BBM) risks the allocation of conflicting TLB entries. Modifying it with BBM risks unmapping the portion of the kernel performing the modification, resulting in an unrecoverable abort.

Quoted 1 line

flush tlb can't resolve it?

Flushing the TLB doesn't help because the page table update, TLB invalidate, and corresponding barrier(s) are separate operations. The TLB can allocate or destroy entries at any point during the sequence.

For example, without BBM a page table update would look something like:

1) str <newpte>, [<*pte>]
2) dsb ish
3) tlbi vmalle1is
4) dsb ish
5) isb

After step 1, the new pte value may become visible to the TLBs, and the TLBs may allocate a new entry for it. Until step 4 completes, this entry may remain active in the TLB, and may conflict with an existing entry.

If that entry covers the kernel text for steps 2-5, executing the sequence may result in an unrecoverable TLB conflict abort, or some other behaviour resulting from an amalgamated TLB, e.g. the I-cache might fetch instructions from the wrong address such that steps 2-5 cannot be executed.

If the kernel doesn't explicitly access the address covered by that pte, there may still be a problem. The TLB may perform an internal lookup when performing a page table walk, and could then use an erroneous result to continue the walk, resulting in a variety of potential issues (e.g. reading from an MMIO peripheral register).

BBM avoids the conflict, but as that would mean kernel text and/or data would be unmapped, you can't execute the code to finish the update.

Quoted 1 line

I find x86 does not have this limit. e.g. set_memory_r*.

I don't know much about x86; it's probably worth asking the x86 guys about that. It may be that the x86 architecture requires that a conflict or amalgamation is never visible to software, or it could be that contemporary implementations happen to provide that property.

Thanks,
Mark.

.

Quoted 84 lines · Mark Rutland

Quoted 25 lines · Xishi Qiu

Quoted 13 lines · Mark Rutland

Hi,

Quoted 7 lines · zhong jiang

http://www.spinics.net/lists/arm-kernel/msg472090.html

Hi, Can I ask you a question? Say, This patch tells that the section spilting and merging wiil produce confilct in the liner mapping area. Based on the situation, Assume that set up page table in 4kb page table way in the liner mapping area, Does the set_memroy_** will work without any conplict??

I'm not sure I understand the question.

Quoted 9 lines

I'm also not a fan of responding to off-list queries as information gets lost.

Please ask your question on the mailing list. I am more than happy to respond there.

Thanks,
Mark.

Quoted 8 lines

Hi Mark,

In your patch it said "The presence of conflicting TLB entries may result in a variety of behaviours detrimental to the system " and "but this(break-before-make approach) cannot work for modifications to the swapper page tables that cover the kernel text and data."

I'm not quite understand this, why the direct mapping can't work?

The problem is that the TLB hardware can operate asynchronously to the rest of the CPU. At any point in time, for any reason, it can decide to destroy TLB entries, to allocate new ones, or to perform a walk based on the existing contents of the TLB.

When the TLB contains conflicting entries, TLB lookups may result in TLB conflict aborts, or may return an "amalgamation" of the conflicting entries (e.g. you could get an erroneous output address).

The direct mapping is in active use (and hence live in TLBs). Modifying it without break-before-make (BBM) risks the allocation of conflicting TLB entries. Modifying it with BBM risks unmapping the portion of the kernel performing the modification, resulting in an unrecoverable abort.

Quoted 1 line

flush tlb can't resolve it?

Flushing the TLB doesn't help because the page table update, TLB invalidate, and corresponding barrier(s) are separate operations. The TLB can allocate or destroy entries at any point during the sequence.

For example, without BBM a page table update would look something like:

1) str <newpte>, [<*pte>]
2) dsb ish
3) tlbi vmalle1is
4) dsb ish
5) isb

After step 1, the new pte value may become visible to the TLBs, and the TLBs may allocate a new entry for it. Until step 4 completes, this entry may remain active in the TLB, and may conflict with an existing entry.

If that entry covers the kernel text for steps 2-5, executing the sequence may result in an unrecoverable TLB conflict abort, or some other behaviour resulting from an amalgamated TLB, e.g. the I-cache might fetch instructions from the wrong address such that steps 2-5 cannot be executed.

If the kernel doesn't explicitly access the address covered by that pte, there may still be a problem. The TLB may perform an internal lookup when performing a page table walk, and could then use an erroneous result to continue the walk, resulting in a variety of potential issues (e.g. reading from an MMIO peripheral register).

BBM avoids the conflict, but as that would mean kernel text and/or data would be unmapped, you can't execute the code to finish the update.

Quoted 1 line

I find x86 does not have this limit. e.g. set_memory_r*.

Quoted 8 lines

I don't know much about x86; it's probably worth asking the x86 guys about that. It may be that the x86 architecture requires that a conflict or amalgamation is never visible to software, or it could be that contemporary implementations happen to provide that property.

Thanks,
Mark.

Hi Mark,

If I do like this, does it have the problem too?

kmalloc a size

no access
flush tlb
call set_memory_ro to change the page table flag
flush tlb
start access

Thanks,
Xishi Qiu

Quoted 2 lines

.

Quoted 25 lines · Xishi Qiu

Quoted 13 lines · Mark Rutland

Hi,

Quoted 7 lines · zhong jiang

http://www.spinics.net/lists/arm-kernel/msg472090.html

Hi, Can I ask you a question? Say, This patch tells that the section spilting and merging wiil produce confilct in the liner mapping area. Based on the situation, Assume that set up page table in 4kb page table way in the liner mapping area, Does the set_memroy_** will work without any conplict??

I'm not sure I understand the question.

Quoted 9 lines

I'm also not a fan of responding to off-list queries as information gets lost.

Please ask your question on the mailing list. I am more than happy to respond there.

Thanks,
Mark.

Quoted 8 lines

Hi Mark,

In your patch it said "The presence of conflicting TLB entries may result in a variety of behaviours detrimental to the system " and "but this(break-before-make approach) cannot work for modifications to the swapper page tables that cover the kernel text and data."

I'm not quite understand this, why the direct mapping can't work?

The problem is that the TLB hardware can operate asynchronously to the rest of the CPU. At any point in time, for any reason, it can decide to destroy TLB entries, to allocate new ones, or to perform a walk based on the existing contents of the TLB.

When the TLB contains conflicting entries, TLB lookups may result in TLB conflict aborts, or may return an "amalgamation" of the conflicting entries (e.g. you could get an erroneous output address).

The direct mapping is in active use (and hence live in TLBs). Modifying it without break-before-make (BBM) risks the allocation of conflicting TLB entries. Modifying it with BBM risks unmapping the portion of the kernel performing the modification, resulting in an unrecoverable abort.

Quoted 1 line

flush tlb can't resolve it?

Flushing the TLB doesn't help because the page table update, TLB invalidate, and corresponding barrier(s) are separate operations. The TLB can allocate or destroy entries at any point during the sequence.

For example, without BBM a page table update would look something like:

1) str <newpte>, [<*pte>]
2) dsb ish
3) tlbi vmalle1is
4) dsb ish
5) isb

After step 1, the new pte value may become visible to the TLBs, and the TLBs may allocate a new entry for it. Until step 4 completes, this entry may remain active in the TLB, and may conflict with an existing entry.

If that entry covers the kernel text for steps 2-5, executing the sequence may result in an unrecoverable TLB conflict abort, or some other behaviour resulting from an amalgamated TLB, e.g. the I-cache might fetch instructions from the wrong address such that steps 2-5 cannot be executed.

If the kernel doesn't explicitly access the address covered by that pte, there may still be a problem. The TLB may perform an internal lookup when performing a page table walk, and could then use an erroneous result to continue the walk, resulting in a variety of potential issues (e.g. reading from an MMIO peripheral register).

BBM avoids the conflict, but as that would mean kernel text and/or data would be unmapped, you can't execute the code to finish the update.

Quoted 1 line

I find x86 does not have this limit. e.g. set_memory_r*.

I don't know much about x86; it's probably worth asking the x86 guys about that. It may be that the x86 architecture requires that a conflict or amalgamation is never visible to software, or it could be that contemporary implementations happen to provide that property.

Thanks,
Mark.

.

Hi Mark,

If I create swapper page tables by 4kb, not large page, then I use set_memory_ro() to change the pate table flag, does it have the problem too?

From a previous discussion [1], we figured out alternative approaches

Quoted 89 lines · Mark Rutland

Quoted 25 lines · Xishi Qiu

Quoted 13 lines · Mark Rutland

Hi,

Quoted 7 lines · zhong jiang

http://www.spinics.net/lists/arm-kernel/msg472090.html

Hi, Can I ask you a question? Say, This patch tells that the section spilting and merging wiil produce confilct in the liner mapping area. Based on the situation, Assume that set up page table in 4kb page table way in the liner mapping area, Does the set_memroy_** will work without any conplict??

I'm not sure I understand the question.

Quoted 9 lines

I'm also not a fan of responding to off-list queries as information gets lost.

Please ask your question on the mailing list. I am more than happy to respond there.

Thanks,
Mark.

Quoted 8 lines

Hi Mark,

In your patch it said "The presence of conflicting TLB entries may result in a variety of behaviours detrimental to the system " and "but this(break-before-make approach) cannot work for modifications to the swapper page tables that cover the kernel text and data."

I'm not quite understand this, why the direct mapping can't work?

The problem is that the TLB hardware can operate asynchronously to the rest of the CPU. At any point in time, for any reason, it can decide to destroy TLB entries, to allocate new ones, or to perform a walk based on the existing contents of the TLB.

When the TLB contains conflicting entries, TLB lookups may result in TLB conflict aborts, or may return an "amalgamation" of the conflicting entries (e.g. you could get an erroneous output address).

The direct mapping is in active use (and hence live in TLBs). Modifying it without break-before-make (BBM) risks the allocation of conflicting TLB entries. Modifying it with BBM risks unmapping the portion of the kernel performing the modification, resulting in an unrecoverable abort.

Quoted 1 line

flush tlb can't resolve it?

Flushing the TLB doesn't help because the page table update, TLB invalidate, and corresponding barrier(s) are separate operations. The TLB can allocate or destroy entries at any point during the sequence.

For example, without BBM a page table update would look something like:

1) str <newpte>, [<*pte>]
2) dsb ish
3) tlbi vmalle1is
4) dsb ish
5) isb

After step 1, the new pte value may become visible to the TLBs, and the TLBs may allocate a new entry for it. Until step 4 completes, this entry may remain active in the TLB, and may conflict with an existing entry.

If that entry covers the kernel text for steps 2-5, executing the sequence may result in an unrecoverable TLB conflict abort, or some other behaviour resulting from an amalgamated TLB, e.g. the I-cache might fetch instructions from the wrong address such that steps 2-5 cannot be executed.

If the kernel doesn't explicitly access the address covered by that pte, there may still be a problem. The TLB may perform an internal lookup when performing a page table walk, and could then use an erroneous result to continue the walk, resulting in a variety of potential issues (e.g. reading from an MMIO peripheral register).

BBM avoids the conflict, but as that would mean kernel text and/or data would be unmapped, you can't execute the code to finish the update.

Quoted 1 line

I find x86 does not have this limit. e.g. set_memory_r*.

I don't know much about x86; it's probably worth asking the x86 guys about that. It may be that the x86 architecture requires that a conflict or amalgamation is never visible to software, or it could be that contemporary implementations happen to provide that property.

Quoted 3 lines

Thanks,
Mark.

Hi Mark,

Thank you for your reply, I find this code in /arch/arm64/mm/mmu.c

...
#ifdef CONFIG_DEBUG_RODATA
void mark_rodata_ro(void)
{
create_mapping_late(__pa(_stext), (unsigned long)_stext,
(unsigned long)_etext - (unsigned long)_stext, PAGE_KERNEL_EXEC | PTE_RDONLY);

}
#endif
...

So does it also have this problem?

Hi Mark,

If I do like this, does it have the problem too?

kmalloc a size
no access
flush tlb
call set_memory_ro to change the page table flag
flush tlb
start access

Quoted 5 lines · Xishi Qiu

Hi Mark,

If I create swapper page tables by 4kb, not large page, then I use set_memory_ro() to change the pate table flag, does it have the problem too?

The splitting/merging problem would not apply.

However, you're going to waste a reasonable amount of memory by not using section mappings in the swapper, and we gain additional complexity in the page table setup code (which is shared with others things that want section mappings).

What are you exactly actually trying to achieve?

What memory do you want to mark RO, and why?

Quoted 1 line

From a previous discussion [1], we figured out alternative approaches

for common cases. Do none of those work for your case?

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/397320.html

.

Quoted 7 lines · Mark Rutland

Quoted 5 lines · Xishi Qiu

Hi Mark,

If I create swapper page tables by 4kb, not large page, then I use set_memory_ro() to change the pate table flag, does it have the problem too?

Quoted 9 lines

The splitting/merging problem would not apply.

However, you're going to waste a reasonable amount of memory by not using section mappings in the swapper, and we gain additional complexity in the page table setup code (which is shared with others things that want section mappings).

What are you exactly actually trying to achieve?

If module allocates some pages and save data on them, and the data will not be changed during the module running. So we want to use set_memory_ro() to increase the security. If the data is changed, we can catch someone.

Quoted 2 lines

What memory do you want to mark RO, and why?

The key data, and it will not be changed during the running time.

Quoted 3 lines

Quoted 1 line

From a previous discussion [1], we figured out alternative approaches

for common cases. Do none of those work for your case?

I have not read the patchset carefully, could you tell me the general meaning of the approaches?

Thanks,
Xishi Qiu

Quoted 7 lines

Thanks,
Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/397320.html

.

Quoted 26 lines · Xishi Qiu

Quoted 7 lines · Mark Rutland

Quoted 5 lines · Xishi Qiu

Hi Mark,

If I create swapper page tables by 4kb, not large page, then I use set_memory_ro() to change the pate table flag, does it have the problem too?

Quoted 9 lines

The splitting/merging problem would not apply.

However, you're going to waste a reasonable amount of memory by not using section mappings in the swapper, and we gain additional complexity in the page table setup code (which is shared with others things that want section mappings).

What are you exactly actually trying to achieve?

If module allocates some pages and save data on them, and the data will not be changed during the module running. So we want to use set_memory_ro() to increase the security. If the data is changed, we can catch someone.

Quoted 2 lines

What memory do you want to mark RO, and why?

Quoted 9 lines

The key data, and it will not be changed during the running time.

Quoted 3 lines

Quoted 1 line

From a previous discussion [1], we figured out alternative approaches

for common cases. Do none of those work for your case?

I have not read the patchset carefully, could you tell me the general meaning of the approaches?

Hi Mark,

Is the two approaches like following?
1. use create_mapping to map the data in read only, then use fixmap to create a temp page table, and change the data when necessary.

2. use vmalloc, then we can use set_memory_ro to change the page table prot.

Quoted 1 line

Quoted 1 line

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/397320.html

Quoted 84 lines · Mark Rutland

Quoted 25 lines · Xishi Qiu

Quoted 13 lines · Mark Rutland

Hi,

Quoted 7 lines · zhong jiang

http://www.spinics.net/lists/arm-kernel/msg472090.html

Hi, Can I ask you a question? Say, This patch tells that the section spilting and merging wiil produce confilct in the liner mapping area. Based on the situation, Assume that set up page table in 4kb page table way in the liner mapping area, Does the set_memroy_** will work without any conplict??

I'm not sure I understand the question.

Quoted 9 lines

I'm also not a fan of responding to off-list queries as information gets lost.

Please ask your question on the mailing list. I am more than happy to respond there.

Thanks,
Mark.

Quoted 8 lines

Hi Mark,

In your patch it said "The presence of conflicting TLB entries may result in a variety of behaviours detrimental to the system " and "but this(break-before-make approach) cannot work for modifications to the swapper page tables that cover the kernel text and data."

I'm not quite understand this, why the direct mapping can't work?

The problem is that the TLB hardware can operate asynchronously to the rest of the CPU. At any point in time, for any reason, it can decide to destroy TLB entries, to allocate new ones, or to perform a walk based on the existing contents of the TLB.

When the TLB contains conflicting entries, TLB lookups may result in TLB conflict aborts, or may return an "amalgamation" of the conflicting entries (e.g. you could get an erroneous output address).

The direct mapping is in active use (and hence live in TLBs). Modifying it without break-before-make (BBM) risks the allocation of conflicting TLB entries. Modifying it with BBM risks unmapping the portion of the kernel performing the modification, resulting in an unrecoverable abort.

Quoted 1 line

flush tlb can't resolve it?

Flushing the TLB doesn't help because the page table update, TLB invalidate, and corresponding barrier(s) are separate operations. The TLB can allocate or destroy entries at any point during the sequence.

For example, without BBM a page table update would look something like:

1) str <newpte>, [<*pte>]
2) dsb ish
3) tlbi vmalle1is
4) dsb ish
5) isb

After step 1, the new pte value may become visible to the TLBs, and the TLBs may allocate a new entry for it. Until step 4 completes, this entry may remain active in the TLB, and may conflict with an existing entry.

If that entry covers the kernel text for steps 2-5, executing the sequence may result in an unrecoverable TLB conflict abort, or some other behaviour resulting from an amalgamated TLB, e.g. the I-cache might fetch instructions from the wrong address such that steps 2-5 cannot be executed.

If the kernel doesn't explicitly access the address covered by that pte, there may still be a problem. The TLB may perform an internal lookup when performing a page table walk, and could then use an erroneous result to continue the walk, resulting in a variety of potential issues (e.g. reading from an MMIO peripheral register).

BBM avoids the conflict, but as that would mean kernel text and/or data would be unmapped, you can't execute the code to finish the update.

Quoted 1 line

I find x86 does not have this limit. e.g. set_memory_r*.

Quoted 8 lines

I don't know much about x86; it's probably worth asking the x86 guys about that. It may be that the x86 architecture requires that a conflict or amalgamation is never visible to software, or it could be that contemporary implementations happen to provide that property.

Thanks,
Mark.

Hi Mark,

If I do like this, does it have the problem too?

kmalloc a size
no access
flush tlb
call set_memory_ro to change the page table flag
flush tlb
start access

Thanks,
Xishi Qiu

Hi, Mark,

I have some confuse about the tlb conflict when split from 2M block to 4K pages. I think if core A starts to split page table from 2M to 4K pages, with the operation __sync_icache_dcache to make sure flush the pte to PoU.

Other core will have three kinds of situation:

1. have the old pmd cached in tlb, so it will see the old physical address.

2. have no old pmd cached in tlb, it will see the new entry when __sync_icache_dcache is over.

3. have no old pmd cached in tlb, it maybe see the old entry before __sync_icache_dcache is over. But, if the core A finish tlbi and dsb sy, all the tlbs will see the new pte.

In my opinion, It seems that the below example will only trigger tlb conflict when merging to huge page.

For example, without BBM a page table update would look something like:
1) str <newpte>, [<*pte>]
2) dsb ish
3) tlbi vmalle1is
4) dsb ish
5) isb

So I have no idea about how to trigger conflict when tlb conflict. Can you give some advice and example ?

Quoted 10 lines · Xishi Qiu

Hi Mark,

If I do like this, does it have the problem too?

kmalloc a size
no access
flush tlb
call set_memory_ro to change the page table flag
flush tlb
start access

This is broken.

The kmalloc will give you memory form the linear mapping. Even if you allocate a page, that page could have been mapped with a section at the PMD/PUD/PGD level.

Other data could fall within that section (e.g. a kernel stack, perhaps).

Additional TLB flushees do not help. There's still a race against the asynchronous TLB logic. The TLB can allocate or destroy entries at any tim. If there were no page table changes prior to the invalidate, the TLB could re-allocate all existing entries immediately after the TLB invalidate, leaving you in the same state as before.

Thanks,
Mark.

.

Quoted 18 lines · Mark Rutland

Quoted 10 lines · Xishi Qiu

Hi Mark,

If I do like this, does it have the problem too?

kmalloc a size
no access
flush tlb
call set_memory_ro to change the page table flag
flush tlb
start access

This is broken.

The kmalloc will give you memory form the linear mapping. Even if you allocate a page, that page could have been mapped with a section at the PMD/PUD/PGD level.

Quoted 2 lines

Other data could fall within that section (e.g. a kernel stack, perhaps).

Hi Mark,

If nobody use that whole section before(however it is almost impossible), flush tlb is safe, right?

Quoted 5 lines

Additional TLB flushees do not help. There's still a race against the asynchronous TLB logic. The TLB can allocate or destroy entries at any tim. If there were no page table changes prior to the invalidate, the TLB could re-allocate all existing entries immediately after the TLB invalidate, leaving you in the same state as before.