From: "Serge E. Hallyn" <serue@us.ibm.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: paulmck@us.ibm.com, sds@tycho.nsa.gov, jmorris@namei.org,
chrisw@sous-sol.org, dhowells@redhat.com,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, haradats@nttdata.co.jp,
akpm@linux-foundation.org
Subject: Re: [TOMOYO #10 (linux-next) 7/8] File operation restriction part.
Date: Wed, 15 Oct 2008 10:24:11 -0500 [thread overview]
Message-ID: <20081015152411.GA18455@us.ibm.com> (raw)
In-Reply-To: <200810120909.GDF95392.SQOFFFHVtOMOJL@I-love.SAKURA.ne.jp>
Quoting Tetsuo Handa (penguin-kernel@I-love.SAKURA.ne.jp):
> Hello.
>
> Serge E. Hallyn wrote:
> > In a previous patch you mark funtions with 'begin/end critical section'.
> > Please instead put a comment on top listing precisely which locks
> > the fn expects to be held.
> >
> > As for protecting your own data, please
> > 1. explain at the var declaration what lock protects it
> > 2. define the lock next to the list
>
> OK. I added comments and simplified dependencies.
> http://svn.sourceforge.jp/cgi-bin/viewcvs.cgi/trunk/2.2.x/tomoyo-lsm/patches/?root=tomoyo
Cool, thanks.
This, in general, is part of changing your mindset - from that of being
a maintainer of out-of-tree code, to being a part of the core community.
My dcache comment further down is along the same lines.
> Anything else we can do before reposting as #11?
Well I'd like to sit down one day and make sure that your _clean()s in
patch 1 cover all the error cases and there are no leaks.
The pathname walking code doesn't seem to be in any way tomoyo-specific,
so it really ought to be in fs/dcache.c where the relevant maintainers
will see, scrutinize, and update it when necessary. I realize that
means we make it look like we encourage others to use the functions
which we don't want either. But having them in tomoyo-specific code
isn't nice either.
And I haven't really looked at your patches 6-8 yet, and am not sure
when I'll get time.
Anyway I think we're well to the point where the patches should be
tossed into a tree and tested (once you address Paul's feedback).
Actually, one thing which is missing from this patchset is a MAINTAINERS
entry. What I'd particularly be interested in is a mailing list entry
(with a public readable archive), so we can see that there is in fact a
community using this.
-serge
next prev parent reply other threads:[~2008-10-15 16:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-09 4:28 [TOMOYO #10 (linux-next) 0/8] TOMOYO Linux Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 1/8] Introduce new LSM hooks where vfsmount is available Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 2/8] Add in_execve flag into task_struct Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 3/8] LSM adapter functions Kentaro Takeda
2008-10-09 6:10 ` KAMEZAWA Hiroyuki
2008-10-09 6:57 ` Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 4/8] Memory and pathname management functions Kentaro Takeda
2008-10-09 6:18 ` KAMEZAWA Hiroyuki
2008-10-09 7:17 ` Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 5/8] Common functions for TOMOYO Linux Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 6/8] Domain transition handler Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 7/8] File operation restriction part Kentaro Takeda
2008-10-09 16:48 ` Serge E. Hallyn
2008-10-12 0:09 ` Tetsuo Handa
2008-10-15 1:29 ` Paul E. McKenney
2008-10-16 4:05 ` Kentaro Takeda
2008-10-16 15:10 ` Paul E. McKenney
2008-10-17 8:32 ` Kentaro Takeda
2008-10-17 14:56 ` Paul E. McKenney
2008-10-18 14:04 ` Tetsuo Handa
2008-10-18 15:18 ` Paul E. McKenney
2008-10-19 13:10 ` Tetsuo Handa
2008-10-20 4:17 ` Paul E. McKenney
2008-10-15 15:24 ` Serge E. Hallyn [this message]
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 8/8] Kconfig and Makefile Kentaro Takeda
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=20081015152411.GA18455@us.ibm.com \
--to=serue@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=chrisw@sous-sol.org \
--cc=dhowells@redhat.com \
--cc=haradats@nttdata.co.jp \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paulmck@us.ibm.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=sds@tycho.nsa.gov \
/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.