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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160405124252.GA4348@infradead.org>
Date:	Tue, 5 Apr 2016 05:42:52 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	Parav Pandit <pandit.parav@...il.com>
Cc:	Christoph Hellwig <hch@...radead.org>, Tejun Heo <tj@...nel.org>,
	cgroups@...r.kernel.org, linux-doc@...r.kernel.org,
	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

On Tue, Apr 05, 2016 at 05:39:21AM -0700, Parav Pandit wrote:
> I am not really trying to address OFED issues here. I am sure you
> understand that if ib_core.ko kernel module is in-kernel module than,
> for all the fixes/enhancements that goes to it would require people to
> upgrade to newer kernel, instead of just modules upgrade. Such heavy
> weight upgrade slows down the adoption which i am trying to avoid here
> by placing knobs in right kernel module's hand.

What a load of rubbish.  The Linux kernel is one program and should be
upgraded together.

> Its like making ib_core.ko from module to in kernel component, if I
> understand correctly nobody wants to do that.

We allow splitting subsystems out where it's easily doable to avoid the
resources consumption if they're all built in.  For cgroups it's not
really practical, but that doesn't mean you can upgrade invidual parts
of a complex program without a lot of precaution.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ