From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757545AbbCPPtf (ORCPT ); Mon, 16 Mar 2015 11:49:35 -0400 Received: from mail.efficios.com ([78.47.125.74]:48464 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756613AbbCPPtc (ORCPT ); Mon, 16 Mar 2015 11:49:32 -0400 Date: Mon, 16 Mar 2015 15:49:25 +0000 (UTC) From: Mathieu Desnoyers To: Steven Rostedt Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, KOSAKI Motohiro , "Paul E. McKenney" , Nicholas Miell , Linus Torvalds , Ingo Molnar , Alan Cox , Lai Jiangshan , Stephen Hemminger , Andrew Morton , Josh Triplett , Thomas Gleixner , David Howells , Nick Piggin Message-ID: <632443866.9505.1426520965530.JavaMail.zimbra@efficios.com> In-Reply-To: <20150316102430.186f4919@gandalf.local.home> References: <1426447459-28620-1-git-send-email-mathieu.desnoyers@efficios.com> <20150316141939.GE21418@twins.programming.kicks-ass.net> <20150316102430.186f4919@gandalf.local.home> Subject: Re: [RFC PATCH] sys_membarrier(): system/process-wide memory barrier (x86) (v12) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [173.246.22.116] X-Mailer: Zimbra 8.0.7_GA_6021 (ZimbraWebClient - FF36 (Linux)/8.0.7_GA_6021) Thread-Topic: sys_membarrier(): system/process-wide memory barrier (x86) (v12) Thread-Index: 0pj5JrLFUqdEVBFKQUbl/xGQhwoEOQ== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- Original Message ----- > From: "Steven Rostedt" > To: "Peter Zijlstra" > Cc: "Mathieu Desnoyers" , linux-kernel@vger.kernel.org, "KOSAKI Motohiro" > , "Paul E. McKenney" , "Nicholas Miell" > , "Linus Torvalds" , "Ingo Molnar" , "Alan Cox" > , "Lai Jiangshan" , "Stephen Hemminger" > , "Andrew Morton" , "Josh Triplett" , > "Thomas Gleixner" , "David Howells" , "Nick Piggin" > Sent: Monday, March 16, 2015 10:24:30 AM > Subject: Re: [RFC PATCH] sys_membarrier(): system/process-wide memory barrier (x86) (v12) > > On Mon, 16 Mar 2015 15:19:39 +0100 > Peter Zijlstra wrote: > > > > > I suppose this is an unprivileged syscall; so what do we do about: > > > > for (;;) > > sys_membar(EXPEDITED); > > > > Which would spray the entire system with IPIs at break neck speed. > > Perhaps it should be rate limited. Have parameters (controlled via > sysctl) that will only allow so many of these per ms. If it exceeds it, > then the call will end up being a schedule_timeout() till it is allowed > to continue. Thus, the above will spit out a few hundred IPIs, then > sleep for a millisecond, and then spit out another hundred IPIs and > sleep again. > > That would prevent any DoS attacks. As I pointed out in my other email, EXPEDITED | ~PRIVATE currently returns -EINVAL. The only way to do a system-wide barrier with this membarrier implementation is to use synchronize_sched() (~EXPEDITED), which I strongly doubt would perform a DoS. If we eventually care about a EXPEDITED | ~PRIVATE implementation, then I agree that rate limiting might be a good way to do it. I would be a bit uncomfortable sending IPIs to _all_ CPUs though, even with rate limiting. But perhaps it's a non-issue ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com