[libvirt] [PATCH 20/53] vircgroup: register cgroup v2 backend

Pavel Hrdina phrdina at redhat.com
Fri Oct 5 07:58:21 UTC 2018


On Fri, Oct 05, 2018 at 09:50:57AM +0200, Michal Privoznik wrote:
> On 10/04/2018 06:10 PM, Pavel Hrdina wrote:
> > On Thu, Oct 04, 2018 at 05:26:32PM +0200, Michal Privoznik wrote:
> >> On 10/02/2018 10:44 AM, Pavel Hrdina wrote:
> >>> All mandatory callbacks are implemented for cgroup v2 backend so we
> >>> can register it now.
> >>>
> >>> Signed-off-by: Pavel Hrdina <phrdina at redhat.com>
> >>> ---
> >>>  src/util/vircgroupbackend.c | 1 +
> >>>  1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/src/util/vircgroupbackend.c b/src/util/vircgroupbackend.c
> >>> index 79fe6cb73d..7ee39ac8ca 100644
> >>> --- a/src/util/vircgroupbackend.c
> >>> +++ b/src/util/vircgroupbackend.c
> >>> @@ -52,6 +52,7 @@ virCgroupBackendRegister(virCgroupBackendPtr backend)
> >>>  static void
> >>>  virCgroupBackendOnceInit(void)
> >>>  {
> >>> +    virCgroupV2Register();
> >>>      virCgroupV1Register();
> >>>  }
> >>>  
> >>>
> >>
> >> Well, the callbacks are implemented, but that's about it. No API that
> >> involves reading/setting a value from CGroup will work at this point, oui?
> >>
> >> For instance:
> >>
> >> virsh blkiotune fedora
> >> error: Operation not supported: operation 'getBlkioWeight' not supported
> >>
> >> ACK if you move this to be the very last patch (or somewhere before the
> >> tests - I haven't gotten that far yet, so I don't know how tests are
> >> implemented, whether they need the v2 backend to be registered or not).
> > 
> > This was intentional to register the backend right after all mandatory
> > callbacks are implemented.  Controller specific callbacks are optional
> > because some of the controllers that are available in cgroup v1 will
> > never exist in cgroup v2.
> 
> Sure, but some of them will. Just like I demonstrated above.
> 
> > 
> > I can move this patch after the all controllers in this series are
> > implemented, but there is still devices controller missing and is not
> > even implemented in kernel and most likely will never exist in v2.
> 
> Hold on, so how are we supposed to limit what devices qemu has access to
> if there is no devices cgroup? If not adding new layers of security we
> should not remove them at least.

This will be a followup series.  There is no devices controller in
cgroup v2, there is BPF filter instead.

> > 
> > So technically there is no point of moving it.
> 
> I think there is. Because right now, around these patches none of the
> APIs that involve CGroup work. It's okay to add code for new feature and
> enable it only at the very last moment. I think it's even in our coding
> guidelines.

OK, I'll move it, I personally don't care.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20181005/0f522ad5/attachment-0001.sig>


More information about the libvir-list mailing list