On Wed, May 27, 2020 at 05:37:07PM +0000, Sargun Dhillon wrote: > On Wed, May 27, 2020 at 01:19:01PM +0200, Christian Brauner wrote: > > +void seccomp_filter_notify(const struct task_struct *tsk) > > +{ > > + struct seccomp_filter *orig = tsk->seccomp.filter; > > + > > + while (orig && refcount_dec_and_test(&orig->live)) { > > + if (waitqueue_active(&orig->wqh)) > > + wake_up_poll(&orig->wqh, EPOLLHUP); > > + orig = orig->prev; > > + } > > +} > > + > Any reason not to write this as: > for (orig = tsk->seccomp.filter; refcount_dec_and_test(&orig->live); orig = orig->prev)? Mainly to follow coding style if you look at: static void __put_seccomp_filter(struct seccomp_filter *orig) { /* Clean up single-reference branches iteratively. */ while (orig && refcount_dec_and_test(&orig->usage)) { struct seccomp_filter *freeme = orig; orig = orig->prev; seccomp_filter_free(freeme); } } seemed easier to just have a visual correspondence between those two codepaths. > > Also, for those of us who are plumbing in the likes of Go code into the > listener, where we don't have direct access to the epoll interface (at > least not out of the box), what do you think about exposing this on the RECV I think requiring users to import golang.org/x/sys/unix is reasonable. You'll need to special case this to linux builds anyway even if you have a client or some such that build on on-unixes. And even if you don't want to import there's always the possibility to use cgo. :) > ioctl? Or, do you think we should lump that into the "v2" receive API? I'm confused how you want to plumb this into the ioctl. That seems unpleasant and against usual poll/wait semantics. I'm now also wondering how you're using this whole interface without poll. The idea is to wait until you're notified you can receive. > > Either way, this seems useful, as right now, we're intertwining process > tree lifetime with manager lifetime. This seems cleaner. Cool. Christian _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers