Re: [PATCH] um: Abandon the _PAGE_NEWPROT bit

2024-10-11 Thread Tiwei Bie
Hi, On 2024/10/11 15:39, Benjamin Berg wrote: > Hi, > > On Fri, 2024-10-11 at 13:38 +0800, Tiwei Bie wrote: >> When a PTE is updated in the page table, the _PAGE_NEWPAGE bit will >> always be set. And the corresponding page will always be mapped or >> unmapped depending on whether the PTE is pres

Re: [PATCH] um: Abandon the _PAGE_NEWPROT bit

2024-10-11 Thread Benjamin Berg
Hi, On Fri, 2024-10-11 at 13:38 +0800, Tiwei Bie wrote: > When a PTE is updated in the page table, the _PAGE_NEWPAGE bit will > always be set. And the corresponding page will always be mapped or > unmapped depending on whether the PTE is present or not. The check > on the _PAGE_NEWPROT bit is not

Re: [PATCH v5 7/8] execmem: add support for cache of large ROX pages

2024-10-11 Thread Christoph Hellwig
On Thu, Oct 10, 2024 at 03:57:33PM +0300, Mike Rapoport wrote: > On Wed, Oct 09, 2024 at 11:58:33PM -0700, Christoph Hellwig wrote: > > On Wed, Oct 09, 2024 at 09:08:15PM +0300, Mike Rapoport wrote: > > > /** > > > * struct execmem_info - architecture parameters for code allocations > > > + * @f

Re: [PATCH] um: Abandon the _PAGE_NEWPROT bit

2024-10-11 Thread Johannes Berg
Hi Tiwei, So kind of a nit, but if the resulting code looks like this: > @@ -184,17 +172,14 @@ static inline pte_t pte_wrprotect(pte_t pte) > { > if (likely(pte_get_bits(pte, _PAGE_RW))) > pte_clear_bits(pte, _PAGE_RW); > return pte; > } then the if really isn't neede

Re: [PATCH] um: Abandon the _PAGE_NEWPROT bit

2024-10-11 Thread Tiwei Bie
Hi Johannes, On 2024/10/11 15:38, Johannes Berg wrote: > Hi Tiwei, > > So kind of a nit, but if the resulting code looks like this: > >> @@ -184,17 +172,14 @@ static inline pte_t pte_wrprotect(pte_t pte) >> { >> if (likely(pte_get_bits(pte, _PAGE_RW))) >> pte_clear_bits(pte, _

[PATCH 2/3] um: vdso: Always reject undefined references in during linking

2024-10-11 Thread Thomas Weißschuh
Instead of using a custom script to detect and fail on undefined references, use --no-undefined for all VDSO linker invocations. Drop the now unused checkundef.sh script. Signed-off-by: Thomas Weißschuh --- arch/x86/um/vdso/Makefile | 5 ++--- arch/x86/um/vdso/checkundef.sh | 11 -

[PATCH 0/3] vdso: Always reject undefined references in during linking

2024-10-11 Thread Thomas Weißschuh
: 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b change-id: 20241011-vdso-checkundef-f6dd0612025b Best regards, -- Thomas Weißschuh

[PATCH 3/3] sparc: vdso: Always reject undefined references in during linking

2024-10-11 Thread Thomas Weißschuh
Instead of using a custom script to detect and fail on undefined references, use --no-undefined for all VDSO linker invocations. Drop the now unused checkundef.sh script. Signed-off-by: Thomas Weißschuh --- arch/sparc/vdso/Makefile | 7 +++ arch/sparc/vdso/checkundef.sh | 10 -

[PATCH 1/3] x86: vdso: Always reject undefined references in during linking

2024-10-11 Thread Thomas Weißschuh
Instead of using a custom script to detect and fail on undefined references, use --no-undefined for all VDSO linker invocations. Drop the now unused checkundef.sh script. Signed-off-by: Thomas Weißschuh --- arch/x86/entry/vdso/Makefile | 7 +++ arch/x86/entry/vdso/checkundef.sh | 10 -

Re: [PATCH v5 6/8] x86/module: perpare module loading for ROX allocations of text

2024-10-11 Thread Mike Rapoport
On Thu, Oct 10, 2024 at 03:54:11PM -0700, Nathan Chancellor wrote: > Hi Mike, > > On Wed, Oct 09, 2024 at 09:08:14PM +0300, Mike Rapoport wrote: > > From: "Mike Rapoport (Microsoft)" > > > > When module text memory will be allocated with ROX permissions, the > > memory at the actual address wher

[PATCH v2 2/2] um: Rename _PAGE_NEWPAGE to _PAGE_NEEDSYNC

2024-10-11 Thread Tiwei Bie
The _PAGE_NEWPAGE bit does not really indicate that this is a new page, but rather whether this entry needs to be synced or not. Renaming it to _PAGE_NEEDSYNC will make it more clear how everything ties together. Suggested-by: Benjamin Berg Signed-off-by: Tiwei Bie --- arch/um/include/asm/page.

[PATCH v2 1/2] um: Abandon the _PAGE_NEWPROT bit

2024-10-11 Thread Tiwei Bie
When a PTE is updated in the page table, the _PAGE_NEWPAGE bit will always be set. And the corresponding page will always be mapped or unmapped depending on whether the PTE is present or not. The check on the _PAGE_NEWPROT bit is not really reachable. Abandoning it will allow us to simplify the cod

[PATCH v2 0/2] um: Some page bit cleanups

2024-10-11 Thread Tiwei Bie
v2: - Remove the unneeded "if" (suggested by Johannes Berg); - Collect the "Reviewed-by" from Benjamin Berg; - Add "um: Rename _PAGE_NEWPAGE to _PAGE_NEEDSYNC" (suggested by Benjamin Berg); - Add a missing comment update in tlbflush.h; v1: https://lore.kernel.org/all/20241011053843.1623089-1-tiwei