linux-kernel - Re: arch_flush_lazy_mmu_mode() in arch/x86/mm/highmem

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: <4923096A.76E4.0078.0@novell.com>
Date:	Tue, 18 Nov 2008 17:28:58 +0000
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Jeremy Fitzhardinge" <jeremy@...p.org>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Zachary Amsden" <zach@...are.com>
Subject: Re: arch_flush_lazy_mmu_mode() in arch/x86/mm/highmem_32.c

>>> Jeremy Fitzhardinge <jeremy@...p.org> 18.11.08 18:01 >>>
>Yes, it disables interrupts while its actually issuing the multicall.  I 
>don't think that matters much, since the multicall itself can't be 
>preempted (can it?) and the rest of the code is very short.  Originally 
>it disabled interrupts for the entire lazy section, which is obviously 
>worse.

If an interrupt (event) comes in, a multicall could of course be 'preempted',
in order to service the event. But of course that works only if event
delivery isn't disabled.

>> There's no reason to do any flush at all if you suppress batching temporarily.
>> And it only needs (would need) explicit suppressing here because you can't
>> easily recognize being in the context of a page fault handler from the
>> batching functions (other than recognizing being in the context of an
>> interrupt handler, which is what would allow removing the flush calls from
>> highmem_32.c).
>
>I'm not sure what your concern is here.  If batching is currently 
>enabled, then the flush will push out anything pending immediately.  If 
>batching is disabled, then the flush will be a noop and return immediately.

Latency, as before. The page fault should have to take longer than it really
needs, and the flushing of a pending batch clearly doesn't belong to the
page fault itself.

Jan

--
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/