| Message ID | 20200929064828.3606720-1-yanaijie@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/xen: only unlock when USE_SPLIT_PTE_PTLOCKS is true | expand |
On 29.09.2020 08:48, Jason Yan wrote: > When USE_SPLIT_PTE_PTLOCKS is false, xen_pte_lock() actually do nothing > but returns NULL. So xen_pte_unlock() should not actually unlock. > Otherwise a NULL pointer dereference will be triggered. > > Fixes: 74260714c56d ("xen: lock pte pages while pinning/unpinning") I neither see any breakage this commit introduces, nor any NULL deref. Both calls to (or arrangements to call) xen_pte_unlock() are guarded by a check of the pointer to be non-NULL. Therefore if anything this is a cosmetic change, which the description should express, and which should have no Fixes: tag. (I would guess the intention back then was to avoid #ifdef-ary where possible, at the expense of a little bit of dead code.) Jan
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c index eda78144c000..c70cbdf5c0fa 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -656,8 +656,10 @@ static spinlock_t *xen_pte_lock(struct page *page, struct mm_struct *mm) static void xen_pte_unlock(void *v) { +#if USE_SPLIT_PTE_PTLOCKS spinlock_t *ptl = v; spin_unlock(ptl); +#endif } static void xen_do_pin(unsigned level, unsigned long pfn)
When USE_SPLIT_PTE_PTLOCKS is false, xen_pte_lock() actually do nothing but returns NULL. So xen_pte_unlock() should not actually unlock. Otherwise a NULL pointer dereference will be triggered. Fixes: 74260714c56d ("xen: lock pte pages while pinning/unpinning") Signed-off-by: Jason Yan <yanaijie@huawei.com> --- arch/x86/xen/mmu_pv.c | 2 ++ 1 file changed, 2 insertions(+)