cgroups.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Aristeu Rozanski <aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	Serge Hallyn
	<serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Subject: Re: [PATCH] device_cgroup: do not use rule acceptance function to validate access
Date: Tue, 15 Apr 2014 12:53:55 -0400	[thread overview]
Message-ID: <20140415165355.GB29214@redhat.com> (raw)
In-Reply-To: <20140415155752.GC5184@sergelap>

Hi Serge,

On Tue, Apr 15, 2014 at 10:57:52AM -0500, Serge Hallyn wrote:
> Quoting Aristeu Rozanski (aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
> > may_access() is currently used to validate both new exceptions from children
> > groups and to check if an access is allowed. This not only makes it hard to
> > understand and maintain, but it's also incorrect.
> 
> Heh, well one might argue that may_access() was more approriate at
> __devcgroup_check_permission(), should remain simpler, and parent_has_perm()
> should be the wrapper doing the extra bits.  That would be easier to
> read imo.
> 
> In what you have here, you end up duplicating the
> list_for_each_entry_rcu.  I think you should at least have a common
> fn for that.
> 
> I don't want to sound pedantic, but since the point of this patch is
> that simplicity/ease-of-reading would have prevented the bug ... :)

Yes, trying to get this right this time. The problem itself isn't
simple, comparing ranges when adding new rules on the child and the
possible difference between the meaning of the exception (is it to
disallow access in that range or to allow?) makes things complicated.

> I *think* it's ok, and I appreciate you finding and fixing the bug, but
> I don't think the result is as easy to read as it could be, so if you
> don't mind I'd like to wait for a new version to ack.  If you disagree
> with me, let me know and I'll re-read and (presumably) ack.

Yes, don't worry about it, I'm working on a v2 that will makes things
easier to read. If not, I'll keep working on it until it looks simple
enough.

-- 
Aristeu

      reply	other threads:[~2014-04-15 16:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-14 14:47 [PATCH] device_cgroup: do not use rule acceptance function to validate access Aristeu Rozanski
     [not found] ` <20140414144736.GS29214-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-04-14 18:03   ` Tejun Heo
     [not found]     ` <20140414180323.GC15249-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2014-04-14 18:16       ` Aristeu Rozanski
     [not found]         ` <20140414181611.GU29214-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2014-04-14 19:07           ` Tejun Heo
2014-04-15 15:57   ` Serge Hallyn
2014-04-15 16:53     ` Aristeu Rozanski [this message]

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=20140415165355.GB29214@redhat.com \
    --to=aris-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
    --cc=serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org \
    --cc=serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).