----- On Apr 13, 2018, at 12:37 PM, Linus Torvalds torvalds@xxxxxxxxxxxxxxxxxxxx wrote: > On Fri, Apr 13, 2018 at 5:16 AM, Mathieu Desnoyers > <mathieu.desnoyers@xxxxxxxxxxxx> wrote: >> The vmalloc space needed by cpu_opv is bound by the number of pages >> a cpu_opv call can touch. > > No it's not. > > You can have a thousand different processes doing cpu_opv at the same time. > > A *single* cpu_opv may me limited toi "only" a megabyte, but I'm not > seeing any global limit anywhere. > > In short, this looks like a guaranteed DoS approach to me. Right, so one simple approach to solve this is to limit to the number of concurrent cpu_opv executed at any given time. Considering that cpu_opv is a slow path, we can limit the number of concurrent cpu_opv executions by protecting this with a global mutex, or a semaphore if we want the number of concurrent executions to be greater than 1. Another approach if we want to be fancier is to keep track of the amount of vma address space currently used by all in-flight cpu_opv. Beyond a given threshold, further execution of additional cpu_opv instances would block, awaiting to be woken up when vmalloc address space is freed when in-flight cpu_opv complete. What global vmalloc address-space budget should we aim for ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
