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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox