All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roman Gushchin <guro@fb.com>
To: Pavel Hrdina <phrdina@redhat.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Jiri Olsa <jolsa@redhat.com>, Tejun Heo <tj@kernel.org>,
	Li Zefan <lizefan@huawei.com>, Daniel Mack <daniel@zonque.org>,
	"cgroups@vger.kernel.org" <cgroups@vger.kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC] cgroup gets release after long time
Date: Sat, 18 May 2019 00:56:12 +0000	[thread overview]
Message-ID: <20190518005606.GA3431@tower.DHCP.thefacebook.com> (raw)
In-Reply-To: <20190517101222.GF1981@antique-laptop>

On Fri, May 17, 2019 at 12:12:51PM +0200, Pavel Hrdina wrote:
> On Thu, May 16, 2019 at 10:25:50AM -0700, Alexei Starovoitov wrote:
> > On Thu, May 16, 2019 at 10:15 AM Roman Gushchin <guro@fb.com> wrote:
> > >
> > > On Thu, May 16, 2019 at 05:31:44PM +0200, Pavel Hrdina wrote:
> > > > On Thu, May 16, 2019 at 03:22:33PM +0000, Roman Gushchin wrote:
> > > > > On Thu, May 16, 2019 at 12:39:15PM +0200, Jiri Olsa wrote:
> > > > > > hi,
> > > > > > Pavel reported an issue with bpf programs (attached to cgroup)
> > > > > > not being released at the time when the cgroup is removed and
> > > > > > are still visible in 'bpftool prog' list afterwards.
> > > > >
> > > > > Hi Jiri!
> > > > >
> > > > > Can you, please, try the patch from
> > > > > https://github.com/rgushchin/linux/commit/f77afa1952d81a1afa6c4872d342bf6721e148e2 ?
> > > > >
> > > > > It should solve the problem, and I'm about to post it upstream.
> > > >
> > > > Perfect, I'll give it a try with full libvirt setup as well.
> > > >
> > > > Can we have this somehow detectable from user-space so libvirt can
> > > > decide when to use BPF or not?  I would like to avoid using BPF with
> > > > libvirt if this issue is not fixed and we cannot simply workaround it
> > > > as systemd automatically removes cgroups for us.
> > >
> > > Hm, I don't think there is a good way to detect it from userspace.
> > > At least I have no good ideas. Alexei? Daniel?
> > >
> > > If you're interested in a particular stable version, we can probably
> > > treat it as a "fix", and backport.
> > 
> > right.
> > also user space workaround is trivial.
> > Just detach before rmdir.
> 
> Well yes, it's trivial but not if you are using machined from systemd.
> Once libvirt kills QEMU process systemd automatically removes the
> cgroup so we don't have any chance to remove the BPF program.
> 
> Would it be too ugly to put something into
> '/sys/kernel/cgroup/features'?

I thought about it, but it seems that /sys/kernel/cgroup/features is also
relatively new. So if we're not going to backport it (I mean auto-detaching),
than we can simple look at the kernel version, right?

If we're going to backport it, the question is which stable version we're
looking at.

In general, I don't see any reasons why cgroup/features can't be used.

Thanks!

  reply	other threads:[~2019-05-18  0:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 10:39 [RFC] cgroup gets release after long time Jiri Olsa
2019-05-16 15:12 ` Alexei Starovoitov
2019-05-16 15:22 ` Roman Gushchin
2019-05-16 15:26   ` Jiri Olsa
2019-05-16 16:46     ` Roman Gushchin
2019-05-16 15:31   ` Pavel Hrdina
2019-05-16 17:14     ` Roman Gushchin
2019-05-16 17:25       ` Alexei Starovoitov
2019-05-17 10:12         ` Pavel Hrdina
2019-05-18  0:56           ` Roman Gushchin [this message]
2019-05-20  8:41             ` Pavel Hrdina
2019-05-20 19:11               ` Roman Gushchin
2019-05-21  8:00                 ` Pavel Hrdina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190518005606.GA3431@tower.DHCP.thefacebook.com \
    --to=guro@fb.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=daniel@zonque.org \
    --cc=davem@davemloft.net \
    --cc=jolsa@redhat.com \
    --cc=lizefan@huawei.com \
    --cc=phrdina@redhat.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.