From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [RFC PATCH v3 for 4.15 08/24] Provide cpu_opv system call Date: Mon, 20 Nov 2017 10:49:27 -0800 Message-ID: <20171120184927.GK2482@two.firstfloor.org> References: <20171114200414.2188-1-mathieu.desnoyers@efficios.com> <20171114200414.2188-9-mathieu.desnoyers@efficios.com> <1766414702.18278.1511194398489.JavaMail.zimbra@efficios.com> <204285712.18480.1511203151076.JavaMail.zimbra@efficios.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <204285712.18480.1511203151076.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mathieu Desnoyers Cc: Thomas Gleixner , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Andy Lutomirski , Dave Watson , linux-kernel , linux-api , Paul Turner , Andrew Morton , Russell King , Ingo Molnar , "H. Peter Anvin" , Andrew Hunter , Andi Kleen , Chris Lameter , Ben Maurer , rostedt , Josh Triplett , Linus Torvalds , Catalin Marinas List-Id: linux-api@vger.kernel.org > Having cpu_opv do a 4k memcpy allow it to handle scenarios where > rseq fails to progress. If anybody ever gets that right. It will be really hard to just test such a path. It also seems fairly theoretical to me. Do you even have a test case where the normal path stops making forward progress? -Andi