linux-kernel - Re: [PATCHv10 1/3] rdmacg: Added rdma cgroup controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAG53R5W3v4Jz+LFLFBfCV6kbX-Vy1xCTD1KLJPh3SGkaxitrdQ@mail.gmail.com>
Date:	Fri, 3 Jun 2016 16:26:21 +0530
From:	Parav Pandit <pandit.parav@...il.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Tejun Heo <tj@...nel.org>, cgroups@...r.kernel.org,
	linux-doc@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-rdma@...r.kernel.org, lizefan@...wei.com,
	Johannes Weiner <hannes@...xchg.org>,
	Doug Ledford <dledford@...hat.com>,
	Liran Liss <liranl@...lanox.com>,
	"Hefty, Sean" <sean.hefty@...el.com>,
	Jason Gunthorpe <jgunthorpe@...idianresearch.com>,
	Haggai Eran <haggaie@...lanox.com>,
	Jonathan Corbet <corbet@....net>, james.l.morris@...cle.com,
	serge@...lyn.com, Or Gerlitz <ogerlitz@...lanox.com>,
	Matan Barak <matanb@...lanox.com>, akpm@...ux-foundation.org,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCHv10 1/3] rdmacg: Added rdma cgroup controller

Hi Christoph,

Reopening thread for discussion so that I can proceed to generate next patch.

Recap:
rdma cgroup controller in the patch defines the framework so that RDMA
subsystem can define the resources.
This is similar to at least two functionality provided by core kernel.

(a) Block elevator defining framework and provides way to loadable
kernel modules to define actual IO scheduler (out of the 3 or 4) that
can be plugged-in since last many years.
(b) VFS core defining framework for external loadable modules to load
file system.

None of these core kernel functionality actually filter based on enum
or names - which IO scheduler(s), file system(s) are
allowed/disallowed.
rdma cgroup controller and rdma subsystem follows similar design approach.

Therefore can I go ahead with current approach?

Tejun also mentioned that he likes to see rdma resources to be defined
by rdma cgroup rather than rdma subsystem in below thread primarily to
reduce the complexity.
https://lkml.org/lkml/2016/4/4/507

However submitted patch is fairly small for defining resource in rdma
subsystem (instead of kernel).
This also allows to provide fixes and features done in rdma subsystem
in field at much faster pace and avoids complexity around back-porting
on various OS and their kernel flavors.
Please let me know your views.

Regards,
Parav Pandit

On Tue, Apr 19, 2016 at 2:26 PM, Parav Pandit <pandit.parav@...il.com> wrote:
> Hi Christoph,
>
> I was on travel. Sorry for the late inline response and question.
>
> Parav
>
>
>
> On Tue, Apr 5, 2016 at 10:57 PM, Christoph Hellwig <hch@...radead.org> wrote:
>> On Tue, Apr 05, 2016 at 05:55:26AM -0700, Parav Pandit wrote:
>>> Just because we add one more rdma resource, we need to ask someone to
>>> upgrade kernel?
>>
>> Yes.  Just like when you need any other core kernel resource.
>
> By architecture Linux kernel allows
> (a) plugin of any new block level IO scheduler as kernel module.
> This is much more fundamental resource or functionality than rdma resource.
> (b) plugin of any new file system as kernel module.
>
> Changing both in field and out of box can do be more harmful than
> defining new rdma resource.
>
> RDMA Resource definition by IB core module is very similar to above
> two functionality, where elevator and VFS provides basic support
> framework and so rdma cgroup controller here.
>
> So can you please help me understand - which resource did you compare
> against in your above comment for "core kernel resource"?
> I compared it with similar functionality, flexibility given by (a)
> block IO Scheduler and (b) VFS subsystem to implement them as kernel
> module.