forked from luck/tmp_suning_uos_patched
8620015499
If more than 1024 event channels are bound to a evtchn device then it possible (even with well behaved applications) for the ring to overflow and events to be lost (reported as an -EFBIG error). Dynamically increase the size of the ring so there is always enough space for all bound events. Well behaved applicables that only unmask events after draining them from the ring can thus no longer lose events. However, an application could unmask an event before draining it, allowing multiple entries per port to accumulate in the ring, and a overflow could still occur. So the overflow detection and reporting is retained. The ring size is initially only 64 entries so the common use case of an application only binding a few events will use less memory than before. The ring size may grow to 512 KiB (enough for all 2^17 possible channels). This order 7 kmalloc() may fail due to memory fragmentation, so we fall back to trying vmalloc(). Signed-off-by: David Vrabel <david.vrabel@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> |
||
---|---|---|
.. | ||
events | ||
xen-pciback | ||
xenbus | ||
xenfs | ||
acpi.c | ||
balloon.c | ||
biomerge.c | ||
cpu_hotplug.c | ||
dbgp.c | ||
efi.c | ||
evtchn.c | ||
fallback.c | ||
features.c | ||
gntalloc.c | ||
gntdev.c | ||
grant-table.c | ||
Kconfig | ||
Makefile | ||
manage.c | ||
mcelog.c | ||
pci.c | ||
pcpu.c | ||
platform-pci.c | ||
preempt.c | ||
privcmd.c | ||
privcmd.h | ||
swiotlb-xen.c | ||
sys-hypervisor.c | ||
tmem.c | ||
xen-acpi-cpuhotplug.c | ||
xen-acpi-memhotplug.c | ||
xen-acpi-pad.c | ||
xen-acpi-processor.c | ||
xen-balloon.c | ||
xen-scsiback.c | ||
xen-selfballoon.c | ||
xen-stub.c | ||
xlate_mmu.c |