| title: | Re MMU notifiers review and some proposals |
|
On Sat, Jul 26, 2008 at 03:10:15PM +0200, Nick Piggin wrote:
I am talking about a number of threads starving another thread of the
same process, but that isnt shooting themselves in the foot because
they might be doing simple normal operations that dont expect the
kernel to cause starvation.
I thought you worried about security issues sorry.
Note that each user is free to implement the locks as it wants. Given
what you describe is a feature and not a bug for KVM, we use readonly
locks and that cant lead to security issues either as you agreed
above.
But nothing prevents you to use a spinlock or rwlock and take the read
side of it from the page fault and the write side of it from the
range_start/end. Careful with the rwlock though because that is a
read-starved lock so it wont buy you anything, it was just to make an
example ;). Surely you can build a fair rwlock if that is what your
app requires. For KVM we want to go unfair and purely readonly in the
kvm page fault because we know the address space is almost never
mangled and that makes it a perfect fit as itll never starve for all
remotely useful cases, and it cant be exploited either.
So youre actually commenting on the kvm implementation of the
lowlevel methods, but were not forcing that implementation to all
users. You surely can use the mmu notifiers in -mm, to have the
secondary mmu page fault block and takeover from the range_start/end
and take range_start/end out of the game.
So really this isnt a valid complaint... infact the same issue exists
for invalidate_page or your invalidate_range. Its up to each user to
decide if to make the page fault slower but 100% fair and higher
priority than the munmap flood coming from the other threads of the
same mm.
Whats the problem with patching asm-*/tlb.h? Theyre just other files,
but they all form part os the same tlb flushing design.
Nothing fundamental, but at least for the last half an year apparently
moving mmu notifier invalidate calls into arch pte/tlb flushing code
was considered a negative in layering terms (I did that initially with
ptep_clear_flush).
I suggest you make another patch that actually works so weve a better
picture of how the changes to tlb-gather looks like. I think the idea
of calling invalidate_page before every tlb_remove_page should be
rejected.
Hope also this shows how those discussions are endless and pointless
if theres nothing we can deploy to the KVM users in the first place.
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at rel="nofollow" vger.kernel.org/majordomo-info.html vger.kernel.org/majordomo-info.html
|
