From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [PATCHv10 1/3] rdmacg: Added rdma cgroup controller Date: Tue, 5 Apr 2016 10:46:08 -0400 Message-ID: <20160405144608.GD7822@mtj.duckdns.org> References: <1458850962-16057-1-git-send-email-pandit.parav@gmail.com> <1458850962-16057-2-git-send-email-pandit.parav@gmail.com> <20160404193640.GA7822@mtj.duckdns.org> <20160405012504.GG24661@htj.duckdns.org> <20160405140107.GB7822@mtj.duckdns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Parav Pandit Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org, Johannes Weiner , Doug Ledford , Liran Liss , "Hefty, Sean" , Jason Gunthorpe , Haggai Eran , Jonathan Corbet , james.l.morris-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org, serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org, Or Gerlitz , Matan Barak , akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org, linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-rdma@vger.kernel.org Hello, Parav. On Tue, Apr 05, 2016 at 07:25:11AM -0700, Parav Pandit wrote: > > As it is a fairly isolated domain, to certain extent, it could be okay > > to let it go. At the same time, I know that these enterprise things > > tend to go completely wayward and am worried about individual drivers > > going crazy with custom attributes in a non-sensical way. > > If its crazy at driver level, I am sure it will be equally crazy for > any end-user too. Therefore no user would use those crazy resources > either. So, the above paragraph simply isn't true. It's not difficult to twist things bit so that things work in a hackish and often horrible way and we know this happens quite a bit, especially in enterprise settings. > Intent is certainly not for the individual drivers as we agreed in > past. You and I agreeing to that doesn't really matter all that much. > IB stack maintainers would be reviewing new enum addition > anyway, whether its verb or hw resource (unlikely). Well, if the additions are unlikely... > > In the original review message, I mentioned creating an interface > > which creates the hierarchy of objects as necessary and returns the > > target pool with lock held, can you please give it a shot? Something > > like the following. > > o.k. I will attempt. Looks doable. > I am on travel so it will take few more days for me to turn around > with below approach with tested code. So, if you go with single mutex, you don't really need get_and_lock semantics, you can just call the get function with mutex held. Please do whichever looks best. Thanks. -- tejun