public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Paul Jackson <pj@sgi.com>
Cc: mikpe@csd.uu.se, nickpiggin@yahoo.com.au, rusty@rustcorp.com.au,
	linux-kernel@vger.kernel.org, akpm@osdl.org, ak@muc.de,
	ashok.raj@intel.com, hch@infradead.org, jbarnes@sgi.com,
	joe.korty@ccur.com, manfred@colorfullife.com,
	colpatch@us.ibm.com, Simon.Derr@bull.net
Subject: Re: [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation
Date: Sat, 5 Jun 2004 01:26:47 -0700	[thread overview]
Message-ID: <20040605082647.GQ21007@holomorphy.com> (raw)
In-Reply-To: <20040605010444.6a384e6c.pj@sgi.com>

On Sat, Jun 05, 2004 at 01:04:44AM -0700, Paul Jackson wrote:
> That looks more readable.  Thanks.
> Do you see a sensible way to pass back an odd number of u32's?  If
> NR_CPUS is say 8, then the 32 bit user code might expect to only need
> one compat_ulong_t, not two.  If NR_CPUS is 48, then it should only need
> 3, not 4.   And so forth.
> As I noted in another reply, perhaps your bitmap_to_u32_array() code
> could be modified to handle this.
> And I agree with Andrew's suggestion, that cpumask provide the
> conversion, to and from kernel memory, separately from copying the
> result to user space.

So do it in the caller, e.g..

int copy_cpus_to_user32(const u32 __user *ubuf, cpumask_t cpus)
{
	int i, ret, len = ALIGN(NR_CPUS, 32)/(32/sizeof(u32));
	u32 *ary = kmalloc(sizeof(cpumask_t), GFP_KERNEL);
	if (!ary)
		return -ENOMEM;
	cpus_to_u32_array(ary, cpus);
	ret = copy_to_user(ubuf, ary, len);
	kfree(ary);
	return ret;
}

int copy_cpus_from_user32(cpumask_t *cpus, const u32 __user *ubuf)
{
	int i, ret, len = ALIGN(NR_CPUS, 32)/(32/sizeof(u32));
	u32 *ary = kmalloc(sizeof(cpumask_t), GFP_KERNEL);
	if (!ary)
		return -ENOMEM;
	if (!(ret = copy_from_user(ary, ubuf, len)))
		cpus_from_u32_array(cpus, ary);
	kfree(ary);
	return ret;
}

or some such nonsense, or whatever someone can be arsed to consider a
better idea. One should note such a reformatting, as a user ABI change
in a stable series, would be unfriendly to 64-bit userspace on BE boxen.
i.e. do this only for 32-bit target userspace on 64-bit kernels + boxen.


-- wli

  reply	other threads:[~2004-06-05  8:27 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-03 16:43 [PATCH] Bitmap and Cpumask Cleanup - Overview Paul Jackson
2004-06-03 17:05 ` [PATCH] cpumask 1/10 cpu_present_map real even on non-smp Paul Jackson
2004-06-03 17:09 ` [PATCH] cpumask 2/10 bitmap cleanup preparation for cpumask overhaul Paul Jackson
2004-06-03 17:09 ` [PATCH] cpumask 3/10 bitmap inlining and optimizations Paul Jackson
2004-06-03 17:09 ` [PATCH] cpumask 4/10 uninline find_next_bit on ia64 Paul Jackson
2004-06-03 17:10 ` [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation Paul Jackson
2004-06-04  0:07   ` Andrew Morton
2004-06-04  0:25     ` Andrew Morton
2004-06-04  2:58       ` Paul Jackson
2004-06-04  2:47     ` Paul Jackson
2004-06-04  2:54       ` David S. Miller
2004-06-04  5:02         ` Paul Jackson
2004-06-04  5:01           ` David S. Miller
2004-06-04  1:47   ` Rusty Russell
2004-06-04  2:02     ` Nick Piggin
2004-06-04  2:19       ` Rusty Russell
2004-06-04  5:18       ` Paul Jackson
2004-06-04  5:22         ` David S. Miller
2004-06-04  6:57           ` Paul Jackson
2004-06-04  9:31         ` Mikael Pettersson
2004-06-04  9:37           ` William Lee Irwin III
2004-06-04  9:46             ` Mikael Pettersson
2004-06-04  9:59               ` William Lee Irwin III
2004-06-04 11:16                 ` Mikael Pettersson
2004-06-04 11:27                   ` William Lee Irwin III
2004-06-04 11:32                     ` William Lee Irwin III
2004-06-04 16:23                       ` Paul Jackson
2004-06-04 16:28                         ` William Lee Irwin III
2004-06-04 17:47                           ` Paul Jackson
2004-06-04 18:12                             ` William Lee Irwin III
2004-06-04 18:20                               ` William Lee Irwin III
2004-06-04 18:27                               ` Andrew Morton
2004-06-04 18:38                                 ` William Lee Irwin III
2004-06-05  2:51                                   ` William Lee Irwin III
2004-06-05  3:29                                     ` William Lee Irwin III
2004-06-04 18:42                               ` Paul Jackson
2004-06-04 18:42                                 ` William Lee Irwin III
2004-06-05  6:48                                   ` Paul Jackson
2004-06-06  2:07                               ` Rusty Russell
2004-06-06 12:16                                 ` Paul Jackson
2004-06-06 12:13                                   ` William Lee Irwin III
2004-06-06 12:28                                     ` Paul Jackson
2004-06-06 12:36                                       ` William Lee Irwin III
2004-06-06 13:42                                         ` Paul Jackson
2004-06-06 23:20                                   ` Rusty Russell
2004-06-07  6:44                                     ` Paul Jackson
2004-06-04  9:41           ` Andrew Morton
2004-06-05  7:01             ` Paul Jackson
2004-06-04 16:03           ` Paul Jackson
2004-06-04 16:56             ` William Lee Irwin III
2004-06-04 17:29               ` Paul Jackson
2004-06-04 17:52                 ` William Lee Irwin III
2004-06-04 19:01                   ` Paul Jackson
2004-06-04 19:08               ` Anton Blanchard
2004-06-04 19:17                 ` William Lee Irwin III
2004-06-04 20:28                 ` Andrew Morton
2004-06-07  7:55                   ` Anton Blanchard
2004-06-05  7:28                 ` Paul Jackson
2004-06-06  8:07                   ` Paul Jackson
2004-06-06  8:16                     ` William Lee Irwin III
2004-06-05  0:05               ` Paul Jackson
2004-06-05  1:31                 ` William Lee Irwin III
2004-06-05  8:04                   ` Paul Jackson
2004-06-05  8:26                     ` William Lee Irwin III [this message]
2004-06-06  8:40                       ` Paul Jackson
2004-06-06 12:34                         ` Paul Jackson
2004-06-07 16:54                       ` fix up compat_sched_[get/set]affinity Joe Korty
2004-06-07 17:07                         ` William Lee Irwin III
2004-06-04  5:30       ` [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation Paul Jackson
2004-06-04  5:35         ` Nick Piggin
2004-06-04  5:40           ` Andrew Morton
2004-06-04  5:53             ` Nick Piggin
2004-06-04  6:47             ` Paul Jackson
2004-06-04  4:31     ` Paul Jackson
2004-06-04  8:19   ` William Lee Irwin III
2004-06-04  8:43     ` Keith Owens
2004-06-04  9:54       ` William Lee Irwin III
2004-06-04 17:08         ` Paul Jackson
2004-06-09 16:38         ` William Lee Irwin III
2004-06-04  9:14     ` Paul Jackson
2004-06-03 17:10 ` [PATCH] cpumask 6/10 remove 26 no longer used cpumask*.h files Paul Jackson
2004-06-03 17:10 ` [PATCH] cpumask 7/10 remove obsolete cpumask macro uses - i386 arch Paul Jackson
2004-06-03 17:10 ` [PATCH] cpumask 8/10 remove obsolete cpumask macro uses - other archs Paul Jackson
2004-06-03 17:11 ` [PATCH] cpumask 9/10 Remove no longer used obsolete macro emulation Paul Jackson
2004-06-03 17:11 ` [PATCH] cpumask 10/10 optimize various uses of new cpumasks Paul Jackson
2004-06-04  4:27   ` Rusty Russell
2004-06-04  4:40     ` Nick Piggin
2004-06-04  4:51     ` Paul Jackson
2004-06-09  0:09   ` PATCH] cpumask 11/10 comment, spacing tweaks Paul Jackson
  -- strict thread matches above, loose matches on Subject: below --
2004-06-06 15:07 [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation Mikael Pettersson
2004-06-06 16:44 ` William Lee Irwin III
2004-06-06 17:46   ` Paul Jackson

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=20040605082647.GQ21007@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=Simon.Derr@bull.net \
    --cc=ak@muc.de \
    --cc=akpm@osdl.org \
    --cc=ashok.raj@intel.com \
    --cc=colpatch@us.ibm.com \
    --cc=hch@infradead.org \
    --cc=jbarnes@sgi.com \
    --cc=joe.korty@ccur.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=mikpe@csd.uu.se \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pj@sgi.com \
    --cc=rusty@rustcorp.com.au \
    /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