From: Andrew Morton <akpm@linux-foundation.org>
To: Kentaro Takeda <takedakn@nttdata.co.jp>
Cc: haradats@nttdata.co.jp, linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, penguin-kernel@I-love.SAKURA.ne.jp
Subject: Re: [TOMOYO #12 (2.6.28-rc2-mm1) 05/11] Memory and pathname management functions.
Date: Mon, 10 Nov 2008 21:04:05 -0800 [thread overview]
Message-ID: <20081110210405.d43458f3.akpm@linux-foundation.org> (raw)
In-Reply-To: <49180E29.2060004@nttdata.co.jp>
On Mon, 10 Nov 2008 19:34:17 +0900 Kentaro Takeda <takedakn@nttdata.co.jp> wrote:
>
> ...
>
> > > +/**
> > > + * tmy_alloc - Allocate memory for temporal purpose.
> > > + *
> > > + * @size: Size in bytes.
> > > + *
> > > + * Returns pointer to allocated memory on success, NULL otherwise.
> > > + */
> > > +void *tmy_alloc(const size_t size)
> > > +{
> > > + void *p = kzalloc(size, GFP_KERNEL);
> > > + if (p)
> > > + atomic_add(ksize(p), &dynamic_memory_size);
> > > + return p;
> > > +}
> >
> > Note that I said "kmalloc", not "kzalloc". This function zeroes
> > everything all the time, and surely that is not necessary. It's just a
> > waste of CPU time.
> >
> Callers of tmy_alloc assume that allocated memory is zeroed.
That isn't the point. For programmer convenience we could make
__alloc_pages() and kmalloc() zero all the memory too. But we don't
because it is slow.
> > > +/**
> > > + * tmy_read_memory_counter - Check for memory usage.
> > > + *
> > > + * @head: Pointer to "struct tmy_io_buffer".
> > > + *
> > > + * Returns memory usage.
> >
> > In what units? Megabytes?
> >
> In bytes.
Let me rephrase:
The comment over tmy_read_memory_counter() fails to tell the reader
what units are used for the return value. It should do so.
> > Again, we would like to see a complete decription of the proposed
> > userspace ABI. This one looks fairly ugly. Do I really have to write
> > 'S' 'h' 'a' 'r' 'e' 'd' ':' ' ' into some pseudo file?
> >
> > A better interface would be two suitably-named pseudo files each of
> > which takes a bare integer string. None of this funny colon-based
> > prefixing stuff.
> >
> Creating pseudo files for each variables is fine, though I don't see
> advantage by changing from
> "echo Shared: 16777216 > /sys/kernel/security/tomoyo/meminfo" to
> "echo 16777216 > /sys/kernel/security/tomoyo/quota/shared_memory".
Well for starters, the existing interface is ugly as sin and will make
kernel developers unhappy.
There is a pretty strict one-value-per-file rule in sysfs files, and
"multiple tagged values in one file" violates that a lot.
next prev parent reply other threads:[~2008-11-11 5:04 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-04 6:08 [TOMOYO #12 (2.6.28-rc2-mm1) 00/11] TOMOYO Linux Kentaro Takeda
2008-11-04 6:08 ` [TOMOYO #12 (2.6.28-rc2-mm1) 01/11] Introduce security_path_clear() hook Kentaro Takeda
2008-11-04 6:08 ` [TOMOYO #12 (2.6.28-rc2-mm1) 02/11] Add in_execve flag into task_struct Kentaro Takeda
2008-11-05 23:12 ` Andrew Morton
2008-11-04 6:08 ` [TOMOYO #12 (2.6.28-rc2-mm1) 03/11] Singly linked list implementation Kentaro Takeda
2008-11-05 23:12 ` Andrew Morton
2008-11-04 6:08 ` [TOMOYO #12 (2.6.28-rc2-mm1) 04/11] Introduce d_realpath() Kentaro Takeda
2008-11-05 23:12 ` Andrew Morton
2008-11-17 6:52 ` Kentaro Takeda
2008-11-04 6:08 ` [TOMOYO #12 (2.6.28-rc2-mm1) 05/11] Memory and pathname management functions Kentaro Takeda
2008-11-05 23:12 ` Andrew Morton
2008-11-10 10:34 ` Kentaro Takeda
2008-11-11 5:04 ` Andrew Morton [this message]
2008-11-11 6:34 ` Kentaro Takeda
2008-11-11 6:46 ` Andrew Morton
2008-11-11 7:32 ` Kentaro Takeda
2008-11-04 6:08 ` [TOMOYO #12 (2.6.28-rc2-mm1) 06/11] Common functions for TOMOYO Linux Kentaro Takeda
2008-11-05 23:12 ` Andrew Morton
2008-11-06 21:46 ` [TOMOYO #12 (2.6.28-rc2-mm1) 06/11] Common functions for TOMOYOLinux Tetsuo Handa
2008-11-08 16:38 ` Tetsuo Handa
2008-11-10 0:41 ` Serge E. Hallyn
2008-11-10 2:24 ` Tetsuo Handa
2008-11-10 2:52 ` Serge E. Hallyn
2008-11-10 3:30 ` Tetsuo Handa
2008-11-10 14:00 ` Serge E. Hallyn
2008-11-10 10:35 ` [TOMOYO #12 (2.6.28-rc2-mm1) 06/11] Common functions for TOMOYO Linux Kentaro Takeda
2008-11-14 9:22 ` Kentaro Takeda
2008-11-04 6:08 ` [TOMOYO #12 (2.6.28-rc2-mm1) 07/11] File operation restriction part Kentaro Takeda
2008-11-04 6:08 ` [TOMOYO #12 (2.6.28-rc2-mm1) 08/11] Domain transition handler Kentaro Takeda
2008-11-04 6:08 ` [TOMOYO #12 (2.6.28-rc2-mm1) 09/11] LSM adapter functions Kentaro Takeda
2008-11-04 6:08 ` [TOMOYO #12 (2.6.28-rc2-mm1) 10/11] Kconfig and Makefile Kentaro Takeda
2008-11-04 6:08 ` [TOMOYO #12 (2.6.28-rc2-mm1) 11/11] MAINTAINERS info 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=20081110210405.d43458f3.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=haradats@nttdata.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=takedakn@nttdata.co.jp \
/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