1. 21 2月, 2007 1 次提交
  2. 12 10月, 2006 1 次提交
    • R
      [PATCH] bitmap: parse input from kernel and user buffers · 01a3ee2b
      Reinette Chatre 提交于
      lib/bitmap.c:bitmap_parse() is a library function that received as input a
      user buffer.  This seemed to have originated from the way the write_proc
      function of the /proc filesystem operates.
      
      This has been reworked to not use kmalloc and eliminates a lot of
      get_user() overhead by performing one access_ok before using __get_user().
      
      We need to test if we are in kernel or user space (is_user) and access the
      buffer differently.  We cannot use __get_user() to access kernel addresses
      in all cases, for example in architectures with separate address space for
      kernel and user.
      
      This function will be useful for other uses as well; for example, taking
      input for /sysfs instead of /proc, so it was changed to accept kernel
      buffers.  We have this use for the Linux UWB project, as part as the
      upcoming bandwidth allocator code.
      
      Only a few routines used this function and they were changed too.
      Signed-off-by: NReinette Chatre <reinette.chatre@linux.intel.com>
      Signed-off-by: NInaky Perez-Gonzalez <inaky@linux.intel.com>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Joe Korty <joe.korty@ccur.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      01a3ee2b
  3. 26 6月, 2006 2 次提交
  4. 29 3月, 2006 1 次提交
  5. 26 3月, 2006 4 次提交
  6. 11 2月, 2006 1 次提交
    • A
      [PATCH] x86: don't initialise cpu_possible_map to all ones · 7a8ef1cb
      Andrew Morton 提交于
      Initialising cpu_possible_map to all-ones with CONFIG_HOTPLUG_CPU means that
      
      a) All for_each_cpu() loops will iterate across all NR_CPUS CPUs, rather
         than over possible ones.  That can be quite expensive.
      
      b) Soon we'll be allocating per-cpu areas only for possible CPUs.  So with
         CPU_MASK_ALL, we'll be wasting memory.
      
      I also switched voyager over to not use CPU_MASK_ALL in the non-CPU-hotplug
      case.  Should be OK..
      
      I note that parisc is also using CPU_MASK_ALL.  Suggest that it stop doing
      that.
      
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Kyle McMartin <kyle@mcmartin.ca>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Zwane Mwaikambo <zwane@linuxpower.ca>
      Cc: Paul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7a8ef1cb
  7. 08 2月, 2006 1 次提交
  8. 31 10月, 2005 1 次提交
    • P
      [PATCH] cpusets: bitmap and mask remap operators · fb5eeeee
      Paul Jackson 提交于
      In the forthcoming task migration support, a key calculation will be
      mapping cpu and node numbers from the old set to the new set while
      preserving cpuset-relative offset.
      
      For example, if a task and its pages on nodes 8-11 are being migrated to
      nodes 24-27, then pages on node 9 (the 2nd node in the old set) should be
      moved to node 25 (the 2nd node in the new set.)
      
      As with other bitmap operations, the proper way to code this is to provide
      the underlying calculation in lib/bitmap.c, and then to provide the usual
      cpumask and nodemask wrappers.
      
      This patch provides that.  These operations are termed 'remap' operations.
      Both remapping a single bit and a set of bits is supported.
      Signed-off-by: NPaul Jackson <pj@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fb5eeeee
  9. 16 10月, 2005 1 次提交
    • A
      [PATCH]: highest_possible_processor_id() has to be a macro · 688ce17b
      Al Viro 提交于
      	... otherwise, things like alpha and sparc64 break and break
      badly.  They define cpu_possible_map to something else in smp.h
      *AFTER* having included cpumask.h.
      
      	If that puppy is a macro, expansion will happen at the actual
      caller, when we'd already seen #define cpu_possible_map ... and we will
      get the right thing used.
      
      	As an inline helper it will be tokenized before we get to that
      define and that's it; no matter what we define later, it won't affect
      anything.  We get modules with dependency on cpu_possible_map instead
      of the right symbol (phys_cpu_present_map in case of sparc64), or outright
      link errors if they are built-in.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      688ce17b
  10. 14 10月, 2005 1 次提交
  11. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4