linux-kernel - Re: [PATCH] mm: disable preemption in apply_to_pte

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20090212165539.5ce51468.akpm@linux-foundation.org>
Date:	Thu, 12 Feb 2009 16:55:39 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	linux-kernel@...r.kernel.org,
	Nick Piggin <nickpiggin@...oo.com.au>, linux-mm@...ck.org
Subject: Re: [PATCH] mm: disable preemption in apply_to_pte_range

On Thu, 12 Feb 2009 16:35:30 -0800
Jeremy Fitzhardinge <jeremy@...p.org> wrote:

> Jeremy Fitzhardinge wrote:
> > commit 79d9c90453a7bc9e7613ae889a97ff6b44ab8380
> 
> Scratch that.

Whew.  Version 1 did an obvious GFP_KERNEL allocation inside
preempt_disable().

>  This instead.
>     J
> 
>     mm: disable preemption in apply_to_pte_range
>     
>     Lazy mmu mode needs preemption disabled, so if we're apply to
>     init_mm (which doesn't require any pte locks), then explicitly
>     disable preemption.  (Do it unconditionally after checking we've
>     successfully done the allocation to simplify the error handling.)
>     
>     Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
> 
> diff --git a/mm/memory.c b/mm/memory.c
> index baa999e..b80cc31 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1718,6 +1718,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  
>  	BUG_ON(pmd_huge(*pmd));
>  
> +	preempt_disable();
>  	arch_enter_lazy_mmu_mode();
>  
>  	token = pmd_pgtable(*pmd);
> @@ -1729,6 +1730,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t *pmd,
>  	} while (pte++, addr += PAGE_SIZE, addr != end);
>  
>  	arch_leave_lazy_mmu_mode();
> +	preempt_enable();
>  
>  	if (mm != &init_mm)
>  		pte_unmap_unlock(pte-1, ptl);
> 

This weakens the apply_to_page_range() utility by newly requiring that
the callback function be callable under preempt_disable() if the target
mm is init_mm.  I guess we can live with that.

It's OK for the two present in-tree callers.  There might of course be
out-of-tree callers which break, but it is unlikely.

The patch should include a comment explaining why there is a random
preempt_disable() in this function.

Why is apply_to_page_range() exported to modules, btw?  I can find no
modules which need it.  Unexporting that function would make the
proposed weakening even less serious.

The patch assumes that
arch_enter_lazy_mmu_mode()/arch_leave_lazy_mmu_mode() must have
preemption disabled for all architectures.  Is this a sensible
assumption?

If so, should we do the preempt_disable/enable within those functions? 
Probably not worth the cost, I guess..

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/