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
| ||
|
Date: Thu, 1 Sep 2016 10:25:40 +0300 From: Matan Barak <matanb@...lanox.com> To: Tejun Heo <tj@...nel.org> CC: Parav Pandit <pandit.parav@...il.com>, <cgroups@...r.kernel.org>, <linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <linux-rdma@...r.kernel.org>, <lizefan@...wei.com>, <hannes@...xchg.org>, <dledford@...hat.com>, <hch@....de>, <liranl@...lanox.com>, <sean.hefty@...el.com>, <jgunthorpe@...idianresearch.com>, <haggaie@...lanox.com>, <corbet@....net>, <james.l.morris@...cle.com>, <serge@...lyn.com>, <ogerlitz@...lanox.com>, <akpm@...ux-foundation.org>, <linux-security-module@...r.kernel.org> Subject: Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller On 01/09/2016 00:16, Tejun Heo wrote: > Hello, > > On Wed, Aug 31, 2016 at 06:07:30PM +0300, Matan Barak wrote: >> Currently, there are some discussions regarding the RDMA ABI. The current >> proposed approach (after a lot of discussions in the OFVWG) is to have >> driver dependent object types rather than the fixed set of IB object types >> we have today. >> AFAIK, some vendors might want to use the RDMA subsystem for a different >> fabrics which has a different set of objects. >> You could see RFCs for such concepts both from Mellanox and Intel on the >> linux-rdma mailing list. >> >> Saying that, maybe we need to make the resource types a bit more flexible >> and dynamic. > > That'd be back to square one and Christoph was dead against it too, > so... > Well, if I recall, the reason doing so last time was in order to allow flexible updating of ib_core independently, which is obviously not a good reason (to say the least). Since the new ABI will probably define new object types (all recent proposals go this way), the current approach could lead to either trying to map new objects to existing cgroup resource types, which could lead to some weird non 1:1 mapping, or having a split definitions - such that each driver will declare its objects both in the cgroups mechanism and in its driver dispatch table. Even worse than that, drivers could simply ignore the cgroups support while implementing their own resource types and get a very broken containers support. > Thanks. > Matan
Powered by blists - more mailing lists