vm_unmap_aliases: allow callers to inhibit TLB flush

Hi,

Hm? Why is that? Why wouldn't it matter if some page table page gets written to via a stale TLB?

So... 2.6.28 is deadlocky for you?

Doesn't work, because that's allowing virtual addresses to be reused before they have TLBs flushed.

You could have a xen specific function which goes through the lazy maps and unmaps their page tables, but leaves them in the virtual address allocator (so a subsequent lazy flush will still do the TLB flush before allowing the addresses to be reused).

The whole lazy flush requires the TLB flush because the core vmalloc code needs to flush before reallocating. So it can't really go into the caller.

PAT needs the TLBs flushed, definitely.

I'm surprised that Xen doesn't... but let's hear it :)

OK. Yeah, then the problem is simply that the guest may reuse that virtual memory for another vmap.

OK, good.

OK.

Yes. And flushing on unmap is easier of course, because we know exactly what we've just unmapped.

That would be my preferred approach.

Hi Nick,

In Xen when we're killing the lazy vmalloc aliases, we're only concerned about the pagetable references to the mapped pages, not the TLB entries. For the most part eliminating the TLB flushes would be a performance optimisation, but there's at least one case where we need to shoot down aliases in an interrupt-disabled section, so the TLB shootdown IPIs would potentially deadlock.

I'm wondering what your thoughts are about this approach?

I'm not super-happy with the changes to __purge_vmap_area_lazy(), but given that we need a tri-state policy selection there, adding an enum is clearer than adding another boolean argument.

It also raises the question of how many callers of vm_unmap_aliases() really care about flushing the tlbs. Presumably if we're shooting down some stray vmalloc mappings then nobody is actually using them at the time, and any corresponding TLB entries are residual. Or does leaving them around leave open the possibility of unwanted speculative references which could violate memory type rules? Perhaps callers who care about that could arrange their own tlb flush?

Thanks,
J

===================================================================

@@ -41,6 +41,7 @@

extern void *vm_map_ram(struct page **pages, unsigned int count,

				int node, pgprot_t prot);

extern void vm_unmap_aliases(void);
+extern void __vm_unmap_aliases(int allow_flush);

#ifdef CONFIG_MMU
extern void __init vmalloc_init(void);
===================================================================

@@ -458,18 +458,26 @@
 

static atomic_t vmap_lazy_nr = ATOMIC_INIT(0);

+enum purge_flush {
+ PURGE_FLUSH_NEVER,
+ PURGE_FLUSH_IF_NEEDED,
+ PURGE_FLUSH_FORCE
+};
+
/*
* Purges all lazily-freed vmap areas.
*
* If sync is 0 then don't purge if there is already a purge in progress.
- * If force_flush is 1, then flush kernel TLBs between *start and *end even
- * if we found no lazy vmap areas to unmap (callers can use this to optimise
- * their own TLB flushing).
+ * 'flush' sets the TLB flushing policy between *start and *end:

+ *    PURGE_FLUSH_NEVER     caller doesn't care about TLB state, so don't flush
+ *    PURGE_FLUSH_IF_NEEDED flush if we found a lazy vmap area to unmap
+ *    PURGE_FLUSH_FORCE     always flush, to allow callers to optimise their own flushing

+ *
* Returns with *start = min(*start, lowest purged address)
* *end = max(*end, highest purged address)
*/
static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
- int sync, int force_flush)
+ int sync, enum purge_flush flush)

{
	static DEFINE_SPINLOCK(purge_lock);
	LIST_HEAD(valist);

@@ -481,7 +489,7 @@
* should not expect such behaviour. This just simplifies locking for
* the case that isn't actually used at the moment anyway. */
- if (!sync && !force_flush) {

+	if (!sync && flush != PURGE_FLUSH_FORCE) {
		if (!spin_trylock(&purge_lock))
			return;
	} else
@@ -508,7 +516,7 @@
		atomic_sub(nr, &vmap_lazy_nr);
	}

- if (nr || force_flush)
+ if ((nr && flush == PURGE_FLUSH_IF_NEEDED) || flush == PURGE_FLUSH_FORCE)

		flush_tlb_kernel_range(*start, *end);

	if (nr) {
@@ -528,7 +536,7 @@
{
	unsigned long start = ULONG_MAX, end = 0;

- __purge_vmap_area_lazy(&start, &end, 0, 0);
+ __purge_vmap_area_lazy(&start, &end, 0, PURGE_FLUSH_IF_NEEDED);
}

/*
@@ -538,7 +546,7 @@

{
	unsigned long start = ULONG_MAX, end = 0;

- __purge_vmap_area_lazy(&start, &end, 1, 0);
+ __purge_vmap_area_lazy(&start, &end, 1, PURGE_FLUSH_IF_NEEDED);
}

/*
@@ -847,11 +855,11 @@
* be sure that none of the pages we have control over will have any aliases
* from the vmap layer.
*/
-void vm_unmap_aliases(void)
+void __vm_unmap_aliases(int allow_flush)

{
	unsigned long start = ULONG_MAX, end = 0;
	int cpu;

- int flush = 0;
+ enum purge_flush flush = PURGE_FLUSH_IF_NEEDED;

	if (unlikely(!vmap_initialized))
		return;
@@ -875,7 +883,7 @@
				s = vb->va->va_start + (i << PAGE_SHIFT);
				e = vb->va->va_start + (j << PAGE_SHIFT);
				vunmap_page_range(s, e);

- flush = 1;
+ flush = PURGE_FLUSH_FORCE;

				if (s < start)
					start = s;
@@ -891,7 +899,13 @@
		rcu_read_unlock();
	}

- __purge_vmap_area_lazy(&start, &end, 1, flush);
+ __purge_vmap_area_lazy(&start, &end, 1,
+ allow_flush ? flush : PURGE_FLUSH_NEVER);
+}
+
+void vm_unmap_aliases(void)
+{
+ __vm_unmap_aliases(1);
}
EXPORT_SYMBOL_GPL(vm_unmap_aliases);

No. Well, yes, it would, but Xen itself will do whatever tlb flushes are necessary to keep it safe (it must, since it doesn't trust guest kernels). It's fairly clever about working out which cpus need flushing and if other flushes have already done the job.

No. The deadlock is in the new dom0 code I'm working on. I haven't posted it yet (well, it hasn't been merged).

In this case, I'm swizzling the physical pages underlying a piece of guest pseudo-physical memory so that it is physically contiguous and/or under the device limit, so I can set up DMA buffers, swiotlb memory, etc. This requires removing the mappings to the old pages and replacing them with new mappings, but I need to make sure the old pages have no other aliases before I can release them back to Xen. (This can all happen in dma_alloc_coherent in a device driver with interrupts disabled, so the IPI causes deadlock warnings.)

The TLB is irrelevant because Xen will make sure any stale entries are flushed appropriately before giving those pages out to any other domain.

Right, I see. It's a question of flush on unmap or flush on map.

Yes, that would work.

J

Hm. What you would you think of a "deferred tlb flush" flag (or something) to cause the next vmap to do the tlb flushes, in the case the vunmap happens in a context where the flushes can't be done?

J
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Sorry to get back to you late... I would just prefer to have a flushing mode that clears page tables but leaves the vm entries there that will get picked up and flushed naturally as needed.

I have patches to move the tlb flushing to an asynchronous process context... but all tweaks to that (including flushing at vmap) are just variations on the existing flushing scheme and don't solve your problem, so I don't think we really need to change that for the moment (my patches are mainly for latency improvement and to allow vunmap to be usable from interrupt context).

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Well, that's basically what I want - I want to use vunmap in an interrupts-disabled context. Any other possibility of deferring tlb flushes is pure bonus and not all that important.

But it also occurred to me that Xen doesn't use IPIs for cross-cpu TLB flushes (it goes to hypercall), so it shouldn't be an issue anyway. I haven't had a chance to look at what's really going on there.

J

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Hi Nick,

I'm very interested in being able to call vm_unmap_aliases() from interrupt context. Does the work you mention here encompass that?

For Xen dom0, when someone does something like dma_alloc_coherent, we allocate the memory as normal, and then swizzle the underlying physical pages to be machine physically contiguous (vs contiguous pseudo-physical guest memory), and within the addressable range for the device. In order to do that, we need to make sure the pages are only mapped by the linear mapping, and there are no other aliases.

And since drivers are free to allocate dma memory at interrupt time, this needs to happen at interrupt time too.

(The tlb flush issue that started this read should be a non-issue for Xen, at least, because all cross-cpu tlb flushes should happen via a hypercall rather than kernel-initiated IPIs, so there's no possibility of deadlock. Though I'll happily admit that taking advantage of the implementation properties of a particular implementation is not very pretty...)

Thanks,
J

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

No, and it can't because we can't do the global kernel tlb flush from interrupt context.

There is basically no point in doing the vm_unmap_aliases from interrupt context without doing the global TLB flush as well, because you still cannot reuse the virtual memory, you still have possible aliases to it, and you still need to schedule a TLB flush at some point anyway.

These are just stale aliases that will no longer be operated on unless there is a kernel bug -- so can you just live with them, or is it a security issue of memory access escaping its domain?

If it is really no other way around it, it would be possible to allow arch code to take advantage of this if it knows its TLB flush is interrupt safe.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

But that's only an issue when you actually do want to reuse the virtual address space. Couldn't you set a flag saying "tlb flush needed", so when cpu X is about to use some of that address space, it flushes first? Avoids the need for synchronous cross-cpu tlb flushes. It assumes they're not currently using that address space, but I think that would indicate a bug anyway.

(Xen does something like this internally to either defer or avoid many expensive tlb operations.)

The underlying physical page is being exchanged, so the old page is being returned to Xen's free page pool. It will refuse to do the exchange if the guest still has pagetable references to the page.

It's almost safe. I've got this patch in my tree to tie up the flush_tlb_all loose end, though I won't claim its pretty.

Then what is the point of the vm_unmap_aliases? If you are doing it for security it won't work because other CPUs might still be able to write through dangling TLBs. If you are not doing it for security then it does not need to be done at all.

Unless it is something strange that Xen does with the page table structure and you just need to get rid of those?

But it refuses to do this because it is worried about dangling TLBs? Or some implementation detail that can't handle the page table entries?

Hmm. Let's just try to establish that it is really required first.

Or... what if we just allow a compile and/or boot time flag to direct that it does not want lazy vmap unmapping and it will just revert to synchronous unmapping? If Xen needs lots of flushing anyway it might not be a win anyway.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Xen will make sure any danging tlb entries are flushed before handing the page out to anyone else.

Yeah. A pte pointing at a page holds a reference on it, saying that it belongs to the domain. You can't return it to Xen until the refcount is 0.

Right. The actual pte pointing at the page hold the reference. We need to drop all the references before doing the exchange.

Well, its desireable anyway. The using IPI for any kind of tlb flushing is pretty pessimal under Xen (or any virtual environment); Xen has a much better idea about which real cpus have stale tlb state for which vcpus.

That may be worth considering.

J

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

OK. Then I will remember to find some time to get the interrupt safe patches working. I wonder why you can't just return it to Xen when (or have Xen hold it somewhere until) the refcount reaches 0?

Anyway...

... in the meantime, shall we just do this for Xen? It is probably safer and may end up with no worse performance on Xen anyway. If we get more vmap users and it becomes important, you could look at more sophisticated ways of doing this. Eg. a page could be flagged if it potentially has lazy vmaps.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

It would still need to allocate a page in the meantime, which could fail because the domain has hit its hard memory limit (which will be the common case, because a domain generally starts with its full compliment of memory). The nice thing about the exchange is that there's no accounting to take into account.

OK. Do you want to do the patch, or shall I?

J

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

T24gTW9uZGF5IDIzIEZlYnJ1YXJ5IDIwMDkgMTg6MzA6MTQgSmVyZW15IEZpdHpoYXJkaW5nZSB3 cm90ZToKPiBOaWNrIFBpZ2dpbiB3cm90ZToKPiA+IE9uIEZyaWRheSAyMCBGZWJydWFyeSAyMDA5 IDA2OjExOjMyIEplcmVteSBGaXR6aGFyZGluZ2Ugd3JvdGU6Cj4gPj4gTmljayBQaWdnaW4gd3Jv dGU6Cj4gPj4+IFRoZW4gd2hhdCBpcyB0aGUgcG9pbnQgb2YgdGhlIHZtX3VubWFwX2FsaWFzZXM/ IElmIHlvdSBhcmUgZG9pbmcgaXQKPiA+Pj4gZm9yIHNlY3VyaXR5IGl0IHdvbid0IHdvcmsgYmVj YXVzZSBvdGhlciBDUFVzIG1pZ2h0IHN0aWxsIGJlIGFibGUKPiA+Pj4gdG8gd3JpdGUgdGhyb3Vn aCBkYW5nbGluZyBUTEJzLiBJZiB5b3UgYXJlIG5vdCBkb2luZyBpdCBmb3IKPiA+Pj4gc2VjdXJp dHkgdGhlbiBpdCBkb2VzIG5vdCBuZWVkIHRvIGJlIGRvbmUgYXQgYWxsLgo+ID4+Cj4gPj4gWGVu IHdpbGwgbWFrZSBzdXJlIGFueSBkYW5naW5nIHRsYiBlbnRyaWVzIGFyZSBmbHVzaGVkIGJlZm9y ZSBoYW5kaW5nCj4gPj4gdGhlIHBhZ2Ugb3V0IHRvIGFueW9uZSBlbHNlLgo+ID4+Cj4gPj4+IFVu bGVzcyBpdCBpcyBzb21ldGhpbmcgc3RyYW5nZSB0aGF0IFhlbiBkb2VzIHdpdGggdGhlIHBhZ2Ug dGFibGUKPiA+Pj4gc3RydWN0dXJlIGFuZCB5b3UganVzdCBuZWVkIHRvIGdldCByaWQgb2YgdGhv c2U/Cj4gPj4KPiA+PiBZZWFoLiAgQSBwdGUgcG9pbnRpbmcgYXQgYSBwYWdlIGhvbGRzIGEgcmVm ZXJlbmNlIG9uIGl0LCBzYXlpbmcgdGhhdCBpdAo+ID4+IGJlbG9uZ3MgdG8gdGhlIGRvbWFpbi4g IFlvdSBjYW4ndCByZXR1cm4gaXQgdG8gWGVuIHVudGlsIHRoZSByZWZjb3VudCBpcwo+ID4+IDAu Cj4gPgo+ID4gT0suIFRoZW4gSSB3aWxsIHJlbWVtYmVyIHRvIGZpbmQgc29tZSB0aW1lIHRvIGdl dCB0aGUgaW50ZXJydXB0Cj4gPiBzYWZlIHBhdGNoZXMgd29ya2luZy4gSSB3b25kZXIgd2h5IHlv dSBjYW4ndCBqdXN0IHJldHVybiBpdCB0bwo+ID4gWGVuIHdoZW4gKG9yIGhhdmUgWGVuIGhvbGQg aXQgc29tZXdoZXJlIHVudGlsKSB0aGUgcmVmY291bnQKPiA+IHJlYWNoZXMgMD8KPgo+IEl0IHdv dWxkIHN0aWxsIG5lZWQgdG8gYWxsb2NhdGUgYSBwYWdlIGluIHRoZSBtZWFudGltZSwgd2hpY2gg Y291bGQgZmFpbAo+IGJlY2F1c2UgdGhlIGRvbWFpbiBoYXMgaGl0IGl0cyBoYXJkIG1lbW9yeSBs aW1pdCAod2hpY2ggd2lsbCBiZSB0aGUKPiBjb21tb24gY2FzZSwgYmVjYXVzZSBhIGRvbWFpbiBn ZW5lcmFsbHkgc3RhcnRzIHdpdGggaXRzIGZ1bGwgY29tcGxpbWVudAo+IG9mIG1lbW9yeSkuICAg VGhlIG5pY2UgdGhpbmcgYWJvdXQgdGhlIGV4Y2hhbmdlIGlzIHRoYXQgdGhlcmUncyBubwo+IGFj Y291bnRpbmcgdG8gdGFrZSBpbnRvIGFjY291bnQuCgpPSywgd2VsbCBJIGRvbid0IHJlYWxseSB1 bmRlcnN0YW5kIHRoZSBkZXRhaWxzIGJ1dCBJIHRydXN0IHlvdSBpZgp5b3Ugc2F5IGl0J3MgaGFy ZCA6KQoKCj4gPj4+IE9yLi4uIHdoYXQgaWYgd2UganVzdCBhbGxvdyBhIGNvbXBpbGUgYW5kL29y IGJvb3QgdGltZSBmbGFnIHRvIGRpcmVjdAo+ID4+PiB0aGF0IGl0IGRvZXMgbm90IHdhbnQgbGF6 eSB2bWFwIHVubWFwcGluZyBhbmQgaXQgd2lsbCBqdXN0IHJldmVydCB0bwo+ID4+PiBzeW5jaHJv bm91cyB1bm1hcHBpbmc/IElmIFhlbiBuZWVkcyBsb3RzIG9mIGZsdXNoaW5nIGFueXdheSBpdCBt aWdodAo+ID4+PiBub3QgYmUgYSB3aW4gYW55d2F5Lgo+ID4+Cj4gPj4gVGhhdCBtYXkgYmUgd29y dGggY29uc2lkZXJpbmcuCj4gPgo+ID4gLi4uIGluIHRoZSBtZWFudGltZSwgc2hhbGwgd2UganVz dCBkbyB0aGlzIGZvciBYZW4/IEl0IGlzIHByb2JhYmx5Cj4gPiBzYWZlciBhbmQgbWF5IGVuZCB1 cCB3aXRoIG5vIHdvcnNlIHBlcmZvcm1hbmNlIG9uIFhlbiBhbnl3YXkuIElmCj4gPiB3ZSBnZXQg bW9yZSB2bWFwIHVzZXJzIGFuZCBpdCBiZWNvbWVzIGltcG9ydGFudCwgeW91IGNvdWxkIGxvb2sg YXQKPiA+IG1vcmUgc29waGlzdGljYXRlZCB3YXlzIG9mIGRvaW5nIHRoaXMuIEVnLiBhIHBhZ2Ug Y291bGQgYmUgZmxhZ2dlZAo+ID4gaWYgaXQgcG90ZW50aWFsbHkgaGFzIGxhenkgdm1hcHMuCj4K PiBPSy4gIERvIHlvdSB3YW50IHRvIGRvIHRoZSBwYXRjaCwgb3Igc2hhbGwgST8KCkhlcmUncyBh IHN0YXJ0IGZvciB5b3UuIEkgdGhpbmsgaXQgZ2V0cyByaWQgb2YgYWxsIHRoZSBkZWFkIGNvZGUg YW5kCmRhdGEgd2l0aG91dCBpbnRyb2R1Y2luZyBhbnkgYWN0dWFsIGNvbmRpdGlvbmFsIGNvbXBp bGF0aW9uLi4uCgotLS0KIG1tL3ZtYWxsb2MuYyB8ICAgNjYgKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCA0 OCBpbnNlcnRpb25zKCspLCAxOCBkZWxldGlvbnMoLSkKCkluZGV4OiBsaW51eC0yLjYvbW0vdm1h bGxvYy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIGxpbnV4LTIuNi5vcmlnL21tL3ZtYWxsb2MuYworKysgbGlu dXgtMi42L21tL3ZtYWxsb2MuYwpAQCAtMjksNiArMjksMTEgQEAKICNpbmNsdWRlIDxhc20vdWFj Y2Vzcy5oPgogI2luY2x1ZGUgPGFzbS90bGJmbHVzaC5oPgogCisjaWZkZWYgQ09ORklHX1ZNQVBf Tk9fTEFaWV9GTFVTSAorI2RlZmluZSBWTUFQX0xBWllfRkxVU0hFUyAwCisjZWxzZQorI2RlZmlu ZSBWTUFQX0xBWllfRkxVU0hFUyAxCisjZW5kaWYKIAogLyoqKiBQYWdlIHRhYmxlIG1hbmlwdWxh dGlvbiBmdW5jdGlvbnMgKioqLwogCkBAIC0zNzYsNyArMzgxLDcgQEAgcmV0cnk6CiBmb3VuZDoK IAlpZiAoYWRkciArIHNpemUgPiB2ZW5kKSB7CiAJCXNwaW5fdW5sb2NrKCZ2bWFwX2FyZWFfbG9j ayk7Ci0JCWlmICghcHVyZ2VkKSB7CisJCWlmIChWTUFQX0xBWllfRkxVU0hFUyAmJiAhcHVyZ2Vk KSB7CiAJCQlwdXJnZV92bWFwX2FyZWFfbGF6eSgpOwogCQkJcHVyZ2VkID0gMTsKIAkJCWdvdG8g cmV0cnk7CkBAIC00MTMsNyArNDE4LDEwIEBAIHN0YXRpYyB2b2lkIF9fZnJlZV92bWFwX2FyZWEo c3RydWN0IHZtYXAKIAlSQl9DTEVBUl9OT0RFKCZ2YS0+cmJfbm9kZSk7CiAJbGlzdF9kZWxfcmN1 KCZ2YS0+bGlzdCk7CiAKLQljYWxsX3JjdSgmdmEtPnJjdV9oZWFkLCByY3VfZnJlZV92YSk7CisJ aWYgKFZNQVBfTEFaWV9GTFVTSEVTKQorCQljYWxsX3JjdSgmdmEtPnJjdV9oZWFkLCByY3VfZnJl ZV92YSk7CisJZWxzZQorCQlrZnJlZSh2YSk7CiB9CiAKIC8qCkBAIC00NTAsOCArNDU4LDEwIEBA IHN0YXRpYyB2b2lkIHZtYXBfZGVidWdfZnJlZV9yYW5nZSh1bnNpZ24KIAkgKiBmYXN0ZXIpLgog CSAqLwogI2lmZGVmIENPTkZJR19ERUJVR19QQUdFQUxMT0MKLQl2dW5tYXBfcGFnZV9yYW5nZShz dGFydCwgZW5kKTsKLQlmbHVzaF90bGJfa2VybmVsX3JhbmdlKHN0YXJ0LCBlbmQpOworCWlmIChW TUFQX0xBWllfRkxVU0hFUykgeworCQl2dW5tYXBfcGFnZV9yYW5nZShzdGFydCwgZW5kKTsKKwkJ Zmx1c2hfdGxiX2tlcm5lbF9yYW5nZShzdGFydCwgZW5kKTsKKwl9CiAjZW5kaWYKIH0KIApAQCAt NTcxLDEwICs1ODEsMTYgQEAgc3RhdGljIHZvaWQgcHVyZ2Vfdm1hcF9hcmVhX2xhenkodm9pZCkK ICAqLwogc3RhdGljIHZvaWQgZnJlZV91bm1hcF92bWFwX2FyZWFfbm9mbHVzaChzdHJ1Y3Qgdm1h cF9hcmVhICp2YSkKIHsKLQl2YS0+ZmxhZ3MgfD0gVk1fTEFaWV9GUkVFOwotCWF0b21pY19hZGQo KHZhLT52YV9lbmQgLSB2YS0+dmFfc3RhcnQpID4+IFBBR0VfU0hJRlQsICZ2bWFwX2xhenlfbnIp OwotCWlmICh1bmxpa2VseShhdG9taWNfcmVhZCgmdm1hcF9sYXp5X25yKSA+IGxhenlfbWF4X3Bh Z2VzKCkpKQotCQl0cnlfcHVyZ2Vfdm1hcF9hcmVhX2xhenkoKTsKKwlpZiAoVk1BUF9MQVpZX0ZM VVNIRVMpIHsKKwkJdmEtPmZsYWdzIHw9IFZNX0xBWllfRlJFRTsKKwkJYXRvbWljX2FkZCgodmEt PnZhX2VuZCAtIHZhLT52YV9zdGFydCkgPj4gUEFHRV9TSElGVCwKKwkJCQkJCQkmdm1hcF9sYXp5 X25yKTsKKwkJaWYgKHVubGlrZWx5KGF0b21pY19yZWFkKCZ2bWFwX2xhenlfbnIpID4gbGF6eV9t YXhfcGFnZXMoKSkpCisJCQl0cnlfcHVyZ2Vfdm1hcF9hcmVhX2xhenkoKTsKKwl9IGVsc2Ugewor CQl2dW5tYXBfcGFnZV9yYW5nZSh2YS0+dmFfc3RhcnQsIHZhLT52YV9lbmQpOworCQlmbHVzaF90 bGJfa2VybmVsX3JhbmdlKHZhLT52YV9zdGFydCwgdmEtPnZhX2VuZCk7CisJfQogfQogCiAvKgpA QCAtNjEwLDYgKzYyNiwxNSBAQCBzdGF0aWMgdm9pZCBmcmVlX3VubWFwX3ZtYXBfYXJlYV9hZGRy KHVuCiAvKioqIFBlciBjcHUga3ZhIGFsbG9jYXRvciAqKiovCiAKIC8qCisgKiBUaGlzIGRvZXMg bGF6eSBmbHVzaGluZyBhcyB3ZWxsLCBzbyBkb24ndCBjYWxsIGl0IGlmIHRoZSBhcmNoIGRvZXNu J3Qgd2FudAorICogbGF6eSB2bWFwIGt2YSBmbHVzaGVzLi4uIFRoZSBzY2FsYWJpbGl0eSBhc3Bl Y3Qgc2hvdWxkIGJlIGxlc3MgaW1wb3J0YW50CisgKiBpbiB0aGF0IGNhc2UgYW55d2F5IHNlZWlu ZyBhcyBrZXJuZWwgdGxiIGZsdXNoaW5nIHRlbmRzIG5vdCB0byBiZSBzY2FsYWJsZS4KKyAqIEl0 IHdvdWxkIGJlIHBvc3NpYmxlIHRvIG1ha2UgdGhpcyB3b3JrIHdpdGhvdXQgbGF6eSB0bGIgZmx1 c2hpbmcgaWYgaXQKKyAqIHdhcyByZWFsbHkgYSBiaWcgZGVhbC4KKyAqLworCisKKy8qCiAgKiB2 bWFwIHNwYWNlIGlzIGxpbWl0ZWQgZXNwZWNpYWxseSBvbiAzMiBiaXQgYXJjaGl0ZWN0dXJlcy4g RW5zdXJlIHRoZXJlIGlzCiAgKiByb29tIGZvciBhdCBsZWFzdCAxNiBwZXJjcHUgdm1hcCBibG9j a3MgcGVyIENQVS4KICAqLwpAQCAtODc3LDYgKzkwMiw5IEBAIHZvaWQgdm1fdW5tYXBfYWxpYXNl cyh2b2lkKQogCWludCBjcHU7CiAJaW50IGZsdXNoID0gMDsKIAorCWlmICghVk1BUF9MQVpZX0ZM VVNIRVMpCisJCXJldHVybjsKKwogCWlmICh1bmxpa2VseSghdm1hcF9pbml0aWFsaXplZCkpCiAJ CXJldHVybjsKIApAQCAtOTM3LDcgKzk2NSw3IEBAIHZvaWQgdm1fdW5tYXBfcmFtKGNvbnN0IHZv aWQgKm1lbSwgdW5zaWcKIAlkZWJ1Z19jaGVja19ub19sb2Nrc19mcmVlZChtZW0sIHNpemUpOwog CXZtYXBfZGVidWdfZnJlZV9yYW5nZShhZGRyLCBhZGRyK3NpemUpOwogCi0JaWYgKGxpa2VseShj b3VudCA8PSBWTUFQX01BWF9BTExPQykpCisJaWYgKFZNQVBfTEFaWV9GTFVTSEVTICYmIGxpa2Vs eShjb3VudCA8PSBWTUFQX01BWF9BTExPQykpCiAJCXZiX2ZyZWUobWVtLCBzaXplKTsKIAllbHNl CiAJCWZyZWVfdW5tYXBfdm1hcF9hcmVhX2FkZHIoYWRkcik7CkBAIC05NTksNyArOTg3LDcgQEAg dm9pZCAqdm1fbWFwX3JhbShzdHJ1Y3QgcGFnZSAqKnBhZ2VzLCB1bgogCXVuc2lnbmVkIGxvbmcg YWRkcjsKIAl2b2lkICptZW07CiAKLQlpZiAobGlrZWx5KGNvdW50IDw9IFZNQVBfTUFYX0FMTE9D KSkgeworCWlmIChWTUFQX0xBWllfRkxVU0hFUyAmJiBsaWtlbHkoY291bnQgPD0gVk1BUF9NQVhf QUxMT0MpKSB7CiAJCW1lbSA9IHZiX2FsbG9jKHNpemUsIEdGUF9LRVJORUwpOwogCQlpZiAoSVNf RVJSKG1lbSkpCiAJCQlyZXR1cm4gTlVMTDsKQEAgLTk4OCwxNCArMTAxNiwxNiBAQCB2b2lkIF9f aW5pdCB2bWFsbG9jX2luaXQodm9pZCkKIAlzdHJ1Y3Qgdm1fc3RydWN0ICp0bXA7CiAJaW50IGk7 CiAKLQlmb3JfZWFjaF9wb3NzaWJsZV9jcHUoaSkgewotCQlzdHJ1Y3Qgdm1hcF9ibG9ja19xdWV1 ZSAqdmJxOwotCi0JCXZicSA9ICZwZXJfY3B1KHZtYXBfYmxvY2tfcXVldWUsIGkpOwotCQlzcGlu X2xvY2tfaW5pdCgmdmJxLT5sb2NrKTsKLQkJSU5JVF9MSVNUX0hFQUQoJnZicS0+ZnJlZSk7Ci0J CUlOSVRfTElTVF9IRUFEKCZ2YnEtPmRpcnR5KTsKLQkJdmJxLT5ucl9kaXJ0eSA9IDA7CisJaWYg KFZNQVBfTEFaWV9GTFVTSEVTKSB7CisJCWZvcl9lYWNoX3Bvc3NpYmxlX2NwdShpKSB7CisJCQlz dHJ1Y3Qgdm1hcF9ibG9ja19xdWV1ZSAqdmJxOworCisJCQl2YnEgPSAmcGVyX2NwdSh2bWFwX2Js b2NrX3F1ZXVlLCBpKTsKKwkJCXNwaW5fbG9ja19pbml0KCZ2YnEtPmxvY2spOworCQkJSU5JVF9M SVNUX0hFQUQoJnZicS0+ZnJlZSk7CisJCQlJTklUX0xJU1RfSEVBRCgmdmJxLT5kaXJ0eSk7CisJ CQl2YnEtPm5yX2RpcnR5ID0gMDsKKwkJfQogCX0KIAogCS8qIEltcG9ydCBleGlzdGluZyB2bWxp c3QgZW50cmllcy4gKi8KAAo=

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

OK, I can get started with this, but it will need to be a runtime switch; a Xen kernel running native is just a normal kernel, and I don't think we want to disable lazy flushes in that case.

J

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

That's fine, just make it a constant 1 if !CONFIG_XEN? And otherwise a variable?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>