FAILED: patch "[PATCH] arm64: Update PTE_RDONLY in set_pte_at() for PROT_NONE" failed to apply to 4.4-stable tree
Subsystems (2)
[email protected]
maintainerThe patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
Quoted 1 line
From
fdc69e7df3cb24f18a93192641786e5b7ecd1dfeMon Sep 17 00:00:00 2001
From: Catalin Marinas <[email protected]>
Date: Wed, 9 Mar 2016 16:31:29 +0000
Subject: [PATCH] arm64: Update PTE_RDONLY in set_pte_at() for PROT_NONE
permission
The set_pte_at() function must update the hardware PTE_RDONLY bit depending on the state of the PTE_WRITE and PTE_DIRTY bits of the given entry value. However, it currently only performs this for pte_valid() entries, ignoring PTE_PROT_NONE. The side-effect is that PROT_NONE mappings would not have the PTE_RDONLY bit set. Without CONFIG_ARM64_HW_AFDBM, this is not an issue since such PROT_NONE pages are not accessible anyway.
With commit 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits"), the ptep_set_wrprotect() function was re-written to cope with automatic hardware updates of the dirty state. As an optimisation, only PTE_RDONLY is checked to assess the "dirty" status. Since set_pte_at() does not set this bit for PROT_NONE mappings, such pages may be considered "dirty" as a result of ptep_set_wrprotect().
This patch updates the pte_valid() check to pte_present() in set_pte_at(). It also adds PTE_PROT_NONE to the swap entry bits comment.
arch/arm64/include/asm/pgtable.h +2 -1
@@ -201,7 +201,7 @@ extern void __sync_icache_dcache(pte_t pteval, unsigned long addr);static inline void set_pte_at (struct mm_struct *mm,unsigned long addr,pte_t *ptep,pte_t pte) { -if (pte_valid (pte)) { +if (pte_present (pte)) {if (pte_sw_dirty (pte) &&pte_write (pte))pte_val (pte) &= ~PTE_RDONLY ;else
@@ -626,6 +626,7 @@ extern pgd_t idmap_pg_dir[PTRS_PER_PGD];* bits 0-1: present (must be zero) * bits 2-7: swap type * bits 8-57: swap offset +* bit 58: PTE_PROT_NONE (must be zero) */ #define __SWP_TYPE_SHIFT 2#define __SWP_TYPE_BITS 6
Catalin Marinas
maintainerHi Greg,
Quoted 33 lines · On Sun, Apr 10, 2016 at 01:53:35AM +0100, [email protected] wrote:
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From
fdc69e7df3cb24f18a93192641786e5b7ecd1dfeMon Sep 17 00:00:00 2001
From: Catalin Marinas <[email protected]>
Date: Wed, 9 Mar 2016 16:31:29 +0000
Subject: [PATCH] arm64: UpdatePTE_RDONLYinset_pte_at()forPROT_NONE
permissionThe
set_pte_at()function must update the hardwarePTE_RDONLYbit depending on the state of thePTE_WRITEandPTE_DIRTYbits of the given entry value. However, it currently only performs this forpte_valid()entries, ignoringPTE_PROT_NONE. The side-effect is thatPROT_NONEmappings would not have thePTE_RDONLYbit set. WithoutCONFIG_ARM64_HW_AFDBM, this is not an issue since suchPROT_NONEpages are not accessible anyway.With commit
2f4b829c625e("arm64: Add support for hardware updates of the access and dirty pte bits"), theptep_set_wrprotect()function was re-written to cope with automatic hardware updates of the dirty state. As an optimisation, onlyPTE_RDONLYis checked to assess the "dirty" status. Sinceset_pte_at()does not set this bit forPROT_NONEmappings, such pages may be considered "dirty" as a result ofptep_set_wrprotect().
Quoted 8 lines
This patch updates the
pte_valid()check topte_present()inset_pte_at(). It also addsPTE_PROT_NONEto the swap entry bits comment.Fixes 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits")Signed-off-by Catalin Marinas <[email protected]>Reported-by Ganapatrao Kulkarni <[email protected]>Tested-by Ganapatrao Kulkarni <[email protected]>Cc <[email protected]>
This patch requires another commit that was merged in 4.5. The actual "Cc: stable" line above should have been:
Shall I re-send commit fdc69e7df3cb ("arm64: Update PTE_RDONLY in set_pte_at() for PROT_NONE permission") with the amended "Cc: stable" line or you're OK to cherry-pick the dependency?
Thanks.
Signature · 1 line
Catalin
[email protected]
maintainerQuoted 45 lines · Catalin Marinas
Hi Greg,
Quoted 33 lines · On Sun, Apr 10, 2016 at 01:53:35AM +0100, [email protected] wrote:
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From
fdc69e7df3cb24f18a93192641786e5b7ecd1dfeMon Sep 17 00:00:00 2001
From: Catalin Marinas <[email protected]>
Date: Wed, 9 Mar 2016 16:31:29 +0000
Subject: [PATCH] arm64: UpdatePTE_RDONLYinset_pte_at()forPROT_NONE
permissionThe
set_pte_at()function must update the hardwarePTE_RDONLYbit depending on the state of thePTE_WRITEandPTE_DIRTYbits of the given entry value. However, it currently only performs this forpte_valid()entries, ignoringPTE_PROT_NONE. The side-effect is thatPROT_NONEmappings would not have thePTE_RDONLYbit set. WithoutCONFIG_ARM64_HW_AFDBM, this is not an issue since suchPROT_NONEpages are not accessible anyway.With commit
2f4b829c625e("arm64: Add support for hardware updates of the access and dirty pte bits"), theptep_set_wrprotect()function was re-written to cope with automatic hardware updates of the dirty state. As an optimisation, onlyPTE_RDONLYis checked to assess the "dirty" status. Sinceset_pte_at()does not set this bit forPROT_NONEmappings, such pages may be considered "dirty" as a result ofptep_set_wrprotect().Quoted 8 lines
This patch updates the
pte_valid()check topte_present()inset_pte_at(). It also addsPTE_PROT_NONEto the swap entry bits comment.Fixes 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits")Signed-off-by Catalin Marinas <[email protected]>Reported-by Ganapatrao Kulkarni <[email protected]>Tested-by Ganapatrao Kulkarni <[email protected]>Cc <[email protected]>
Quoted 8 lines
This patch requires another commit that was merged in 4.5. The actual "Cc: stable" line above should have been:
Cc <[email protected]> # 4.4.x: ac15bd63bbb2: arm64: Honour !PTE_WRITE in set_pte_at() for kernel mappingsShall I re-send commit
fdc69e7df3cb("arm64: UpdatePTE_RDONLYinset_pte_at()forPROT_NONEpermission") with the amended "Cc: stable" line or you're OK to cherry-pick the dependency?
I can cherry-pick, thanks.
greg k-h
[email protected]
maintainerQuoted 49 lines · On Mon, Apr 11, 2016 at 10:46:07AM -0700, [email protected] wrote:
Quoted 48 lines · Catalin Marinas
Hi Greg,
Quoted 33 lines · On Sun, Apr 10, 2016 at 01:53:35AM +0100, [email protected] wrote:
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From
fdc69e7df3cb24f18a93192641786e5b7ecd1dfeMon Sep 17 00:00:00 2001
From: Catalin Marinas <[email protected]>
Date: Wed, 9 Mar 2016 16:31:29 +0000
Subject: [PATCH] arm64: UpdatePTE_RDONLYinset_pte_at()forPROT_NONE
permissionThe
set_pte_at()function must update the hardwarePTE_RDONLYbit depending on the state of thePTE_WRITEandPTE_DIRTYbits of the given entry value. However, it currently only performs this forpte_valid()entries, ignoringPTE_PROT_NONE. The side-effect is thatPROT_NONEmappings would not have thePTE_RDONLYbit set. WithoutCONFIG_ARM64_HW_AFDBM, this is not an issue since suchPROT_NONEpages are not accessible anyway.With commit
2f4b829c625e("arm64: Add support for hardware updates of the access and dirty pte bits"), theptep_set_wrprotect()function was re-written to cope with automatic hardware updates of the dirty state. As an optimisation, onlyPTE_RDONLYis checked to assess the "dirty" status. Sinceset_pte_at()does not set this bit forPROT_NONEmappings, such pages may be considered "dirty" as a result ofptep_set_wrprotect().Quoted 8 lines
This patch updates the
pte_valid()check topte_present()inset_pte_at(). It also addsPTE_PROT_NONEto the swap entry bits comment.Fixes 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits")Signed-off-by Catalin Marinas <[email protected]>Reported-by Ganapatrao Kulkarni <[email protected]>Tested-by Ganapatrao Kulkarni <[email protected]>Cc <[email protected]>This patch requires another commit that was merged in 4.5. The actual "Cc: stable" line above should have been:
Quoted 7 lines
Quoted 5 lines
Cc <[email protected]> # 4.4.x: ac15bd63bbb2: arm64: Honour !PTE_WRITE in set_pte_at() for kernel mappingsShall I re-send commit
fdc69e7df3cb("arm64: UpdatePTE_RDONLYinset_pte_at()forPROT_NONEpermission") with the amended "Cc: stable" line or you're OK to cherry-pick the dependency?I can cherry-pick, thanks.
Ok, I take it back, I need a backported version of fdc69e7df3cb for 4.4-stable as it didn't apply cleanly and I don't know the code at all to be able to do it myself by hand.
Can you provide that backport?
thanks,
greg k-h
Catalin Marinas
maintainerHi Greg,
Quoted 11 lines · On Mon, Apr 18, 2016 at 10:23:28AM +0900, [email protected] wrote:
Quoted 10 lines · On Mon, Apr 11, 2016 at 10:46:07AM -0700, [email protected] wrote:
Quoted 8 lines · Catalin Marinas
This patch requires another commit that was merged in 4.5. The actual "Cc: stable" line above should have been:
Cc <[email protected]> # 4.4.x: ac15bd63bbb2: arm64: Honour !PTE_WRITE in set_pte_at() for kernel mappingsShall I re-send commit
fdc69e7df3cb("arm64: UpdatePTE_RDONLYinset_pte_at()forPROT_NONEpermission") with the amended "Cc: stable" line or you're OK to cherry-pick the dependency?
Quoted 7 lines
Quoted 1 line
I can cherry-pick, thanks.
Ok, I take it back, I need a backported version of
fdc69e7df3cbfor 4.4-stable as it didn't apply cleanly and I don't know the code at all to be able to do it myself by hand.Can you provide that backport?
As I mentioned in above, it applies cleanly once commit ac15bd63bbb2 ("arm64: Honour !PTE_WRITE in set_pte_at() for kernel mappings") is cherry-picked.
I'll send both commit ac15bd63bbb2 and fdc69e7df3cb as patches to [email protected].
Thanks.
Signature · 1 line
Catalin