From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752341AbbIOVih (ORCPT ); Tue, 15 Sep 2015 17:38:37 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:34451 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751480AbbIOVif (ORCPT ); Tue, 15 Sep 2015 17:38:35 -0400 X-Helo: d03dlp01.boulder.ibm.com X-MailFrom: paulmck@linux.vnet.ibm.com X-RcptTo: linux-kernel@vger.kernel.org Date: Tue, 15 Sep 2015 14:38:30 -0700 From: "Paul E. McKenney" To: Tejun Heo Cc: Christian Borntraeger , Paolo Bonzini , Peter Zijlstra , Ingo Molnar , "linux-kernel@vger.kernel.org >> Linux Kernel Mailing List" , KVM list , Oleg Nesterov Subject: Re: [4.2] commit d59cfc09c32 (sched, cgroup: replace signal_struct->group_rwsem with a global percpu_rwsem) causes regression for libvirt/kvm Message-ID: <20150915213830.GR4029@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <55F8097A.7000206@de.ibm.com> <20150915130550.GC16853@twins.programming.kicks-ass.net> <55F81EE2.4090708@de.ibm.com> <55F84A6B.1010207@redhat.com> <55F88991.7040406@de.ibm.com> <20150915212622.GC495@htj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150915212622.GC495@htj.duckdns.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15091521-8236-0000-0000-00000FA904B1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 15, 2015 at 05:26:22PM -0400, Tejun Heo wrote: > Hello, > > On Tue, Sep 15, 2015 at 11:11:45PM +0200, Christian Borntraeger wrote: > > > In fact, I would say that any userspace-controlled call to *_expedited() > > > is a bug waiting to happen and a bad idea---because userspace can, with > > > little effort, end up calling it in a loop. > > > > Right. This also implies that we should fix this for 4.2 - I guess. > > Are the percpu_rwsem changes enough? If so, we can try to backport > those. If those are too risky, we can revert the patches which > switched threadgroup lock to percpu_rwsem. I did take a shot at adding the rcu_sync stuff during this past merge window, but it did not converge quickly enough to make it. It looks quite good for the next merge window. There have been changes in most of the relevant areas, so probably best to just try them and see which works best. Thanx, Paul