public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robin Holt <holt@sgi.com>
To: Tim Hockin <thockin@sun.com>
Cc: Linux Kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: NGROUPS 2.6.2rc2
Date: Wed, 28 Jan 2004 05:31:37 -0600	[thread overview]
Message-ID: <20040128113137.GA23445@lnx-holt> (raw)
In-Reply-To: <20040127225311.GA9155@sun.com>

On Tue, Jan 27, 2004 at 02:53:11PM -0800, Tim Hockin wrote:

For the every declaration of struct group_info *info, is there a
more descriptive name than info available.  This will make
searchs simpler in the long run.


+#define NGROUPS_SMALL          32
+#define NGROUPS_BLOCK          ((int)(EXEC_PAGESIZE / sizeof(gid_t)))

Can this be changed to NGROUPS_PER_EPAGE.  NGROUPS_BLOCK seems to
indicate a location of a block or the block or some block given an offset.
NGROUPS_PER_EPAGE is very explicit.

+void groups_free(struct group_info *info)
 {
+       if (info->ngroups > NGROUPS_SMALL) {

Why not use info->nblocks > 0.  These are more clearly tied to each
other than ngroups and NGROUPS_SMALL.


+                       while (left >= 0 && GROUP_AT(info, left) > tmp) {
+                               GROUP_AT(info, right) = GROUP_AT(info, left);
+                               left -= stride;
+                               right = left + stride;

For the above in groups_sort, why not just have
                                right = stride;
                                left -= stride;



@@ -1102,54 +1256,43 @@

        if (gidsetsize < 0)
                return -EINVAL;
-       i = current->ngroups;
+       i = current->group_info->ngroups;
        if (gidsetsize) {
                if (i > gidsetsize)
                        return -EINVAL;
-               if (copy_to_user(grouplist, current->groups, sizeof(gid_t)*i))
+               if (groups_to_user(grouplist, current->group_info))
                        return -EFAULT;
        }

Shouldn't there be a get/put pair around this.  Especially with the
copy_to_user call buried in groups_to_user, we could spend quite some time
waiting for the page fault and another thread could free our structure.
Or maybe I am missing something...


+       if (info->ngroups > TASK_SIZE/sizeof(group))
+               return -EFAULT;

I don't understand the TASK_SIZE usage.  Maybe this is a difference
between ia64 and i386, but these checks don't make any sense to
me.  Consider them not looked at.


 asmlinkage long sys_getgroups16(int gidsetsize, old_gid_t __user *grouplist)
 {
-       old_gid_t groups[NGROUPS];
-       int i,j;
+       int i = 0;

        if (gidsetsize < 0)
                return -EINVAL;
-       i = current->ngroups;
+       i = current->group_info->ngroups;
        if (gidsetsize) {
                if (i > gidsetsize)
                        return -EINVAL;
-               for(j=0;j<i;j++)
-                       groups[j] = current->groups[j];
-               if (copy_to_user(grouplist, groups, sizeof(old_gid_t)*i))
+               if (groups16_to_user(grouplist, current->group_info))

Again with the get/put.

===== fs/proc/array.c 1.55 vs edited =====
--- 1.55/fs/proc/array.c        Tue Oct 14 14:00:09 2003
+++ edited/fs/proc/array.c      Tue Jan 27 12:40:02 2004
@@ -176,8 +176,8 @@
                p->files ? p->files->max_fds : 0);
        task_unlock(p);

-       for (g = 0; g < p->ngroups; g++)
-               buffer += sprintf(buffer, "%d ", p->groups[g]);
+       for (g = 0; g < min(p->group_info->ngroups,NGROUPS_SMALL); g++)
+               buffer += sprintf(buffer, "%d ", GROUP_AT(p->group_info,g));

        buffer += sprintf(buffer, "\n");
        return buffer;


Again with the get/put.

All of the sunrpc mods appear to need get/put.


      parent reply	other threads:[~2004-01-28 11:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-27 22:53 NGROUPS 2.6.2rc2 Tim Hockin
2004-01-27 23:25 ` Dax Kelson
2004-01-27 23:55 ` Chris Wright
2004-01-28  0:41 ` Chris Wright
2004-01-28  0:46 ` Andrew Morton
2004-01-28  0:52   ` Christoph Hellwig
2004-01-28  1:02   ` Tim Hockin
2004-01-28 17:08     ` Hugh Dickins
2004-01-28 18:04       ` Hugh Dickins
2004-01-28 18:10         ` Linus Torvalds
2004-01-28 22:22           ` Tim Hockin
2004-02-03 22:17             ` Pavel Machek
2004-02-04 22:11               ` Panu Matilainen
2004-01-28  1:12 ` Rusty Russell
2004-01-28 11:31 ` Robin Holt [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=20040128113137.GA23445@lnx-holt \
    --to=holt@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thockin@sun.com \
    /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