1. 05 Oct, 2003 18 commits
    • Andrew Morton's avatar
      [PATCH] fix pte_chain leak in do_no_page() · 11d3c5ea
      Andrew Morton authored
      From: "V. Rajesh" <vrajesh@eecs.umich.edu>
      
      Fix a rare pte_chain memory leak in do_no_page()
      11d3c5ea
    • Andrew Morton's avatar
      [PATCH] fix "compat ioctl consolidation" for "move job · 3479607f
      Andrew Morton authored
      A little fix which is needed if both the "compat ioctl consolidation" and
      "move job control fields from task_struct to signal_struct" patches are
      applied.
      3479607f
    • Andrew Morton's avatar
      [PATCH] move job control fields from task_struct to · 1bd563fd
      Andrew Morton authored
      From: Roland McGrath <roland@redhat.com>
      
      This patch completes what was started with the `process_group' accessor
      function, moving all the job control-related fields from task_struct into
      signal_struct and using process_foo accessor functions to read them.  All
      these things are per-process in POSIX, none per-thread.  Off hand it's hard
      to come up with the hairy MT scenarios in which the existing code would do
      insane things, but trust me, they're there.  At any rate, all the uses
      being done via inline accessor functions now has got to be all good.
      
      I did a "make allyesconfig" build and caught the few random drivers and
      whatnot that referred to these fields.  I was surprised to find how few
      references to ->tty there really were to fix up.  I'm sure there will be a
      few more fixups needed in non-x86 code.  The only actual testing of a
      running kernel with these patches I've done is on my normal minimal x86
      config.  Everything works fine as it did before as far as I can tell.
      
      One issue that may be of concern is the lack of any locking on multiple
      threads diddling these fields.  I don't think it really matters, though
      there might be some obscure races that could produce inconsistent job
      control results.  Nothing shattering, I'm sure; probably only something
      like a multi-threaded program calling setsid while its other threads do tty
      i/o, which never happens in reality.  This is the same situation we get by
      using ->group_leader->foo without other synchronization, which seemed to be
      the trend and noone was worried about it.
      1bd563fd
    • Andrew Morton's avatar
      [PATCH] cpufreq sysfs oops fix · 9697ce4c
      Andrew Morton authored
      From: Dominik Brodowski <linux@brodo.de>
      
      Fix an ordering problem whcih was causing cpufreq oopses in sysfs.
      9697ce4c
    • Andrew Morton's avatar
      [PATCH] dscc4 driver fixes · 86b7683a
      Andrew Morton authored
      From: Francois Romieu <romieu@fr.zoreil.com>
      
      - dscc4_release_ring() must not appear in dscc4_{open/close} as the rings
        are allocated/freed in dscc4_{found1/free1};
      
      - more elegant handling of return status in dscc4_found1().
      86b7683a
    • Andrew Morton's avatar
      [PATCH] ext3 block allocator locking fix · 3101501b
      Andrew Morton authored
      When the BKL was removed from ext3 we lost locking coverage for
      get_block()-versus-get_block().  Nobody seems to have hit the race because
      get_block() almost always runs under i_sem: only memory pressure-based
      writeout over a file hole runs outside i_sem.
      
      ext2 uses the dedicated i_meta_lock spinlock in the inode to provide the
      needed locking.  But ext3 already has an rwsem around all the get_block()
      activity to protect it from truncate-related races.
      
      So this patch just converts that rwsem into a semaphore, so concurrent
      get_block() can never occur.  This will be more efficient than adding the new
      spinlock.
      
      We lose the ability to have two threads run get_block() against the same file
      at the same time but again, that only happens during pageout over a hole
      anyway.
      
      (Kudos Alex Tomas for noticing the bug)
      3101501b
    • Andrew Morton's avatar
      [PATCH] EISA_bus cleanup · 9626f94d
      Andrew Morton authored
      From: Marc Zyngier <mzyngier@freesurf.fr>, Christoph Hellwig
      
      I'd like to kill willy's CONFIG_EISA_ALWAYS kludge.  So make EISA_bus a
      variable always when CONFIG_EISA is set and initialize it to 1 for alpha.
      We probably want to do that only if the system actually supports eisa, but
      I keep the old behaviour for now.
      9626f94d
    • Andrew Morton's avatar
      [PATCH] kernel documentation fixes · 1820a80d
      Andrew Morton authored
      From: Michael Still <mikal@stillhq.com>
      
      The patch squelches build errors in the kernel-doc make targets by adding
      documentation to arguements previously not documented, and updating the
      argument names where they have changed.
      1820a80d
    • Andrew Morton's avatar
      [PATCH] /proc/sys/auxv · 9ff547bd
      Andrew Morton authored
      From: Roland McGrath <roland@redhat.com>
      
      This was supposed to be part of the recent mm_struct.saved_auxv[] patch.
      
      The /proc addition is half the reason for the patch, and the more important
      one (letting you debug live processes, while NT_AUXV in core dumps lets you
      debug dead ones).  The patch below was supposed to be part of the original.
      9ff547bd
    • Andrew Morton's avatar
      [PATCH] document the macro for translating PROT_ to VM_ bits · 62f75b29
      Andrew Morton authored
      From: Muli Ben-Yehuda <mulix@mulix.org>
      
      Shed some much-needed light.
      62f75b29
    • Andrew Morton's avatar
      [PATCH] compat ioctl consolidation · f7719648
      Andrew Morton authored
      From: Arun Sharma <arun.sharma@intel.com>, kevin.tian@intel.com
      
      Move a whole bunch of filesystem ioctl conversion functions out of per-arch
      files and into fs/compat_ioctl.c
      
      It moves linux32_dirent to compat.h and renames it as compat_dirent. 
      linux32_dirent has been eliminated from ia64.  Other archs should do the
      same.
      
      We'll leave old_linux_dirent32 as is, since it seems to be arch specific
      (ia64 doesn't use it for example).
      f7719648
    • Andrew Morton's avatar
      [PATCH] node enumeration fixes · ca887863
      Andrew Morton authored
      From: Matthew Dobson <colpatch@us.ibm.com>
      
      Here's a small update to the numnodes fix that went into -mm3.  The biggest
      changes are:
      
      1) move the actual NODES_SHIFT and MAX_NUMNODES definitions into
         linux/numa.h and include this in linux/mmzone.h, instead of being
         directly in linux/mmzone.h.  This allows other files to include *just*
         the NUMNODES stuff w/out grabbing all of mmzone.h.
      
      2) pull NODE_SHIFT out of linux/mm.h.  This isn't used anywhere in the
         kernel, and it will only get confused with NODES_SHIFT.
      
      3) Fix the IA64 patch.  The original patch I had sent out hadn't been
         tested on IA64.  It was mostly right, but there were circular
         dependencies.  All better now, and acked by Jesse.
      
      4) In linux/mmzone.h, insert code to define MAX_NODES_SHIFT based on the
         size of unsigned long.  For 64-bit arches, we can have a much larger
         value.  This allows IA64 to have 100's or 1000's of nodes.
         MAX_NODES_SHIFT is defined as 10 (ie: 1024 nodes) for 64-bit for now,
         although it could likely be much larger.  For 32-bit it is 6 (ie: 64
         nodes).
      
      5) Small cleanup in include/asm-arm/memory.h.  Mostly the result of the
         new linux/numa.h file.  Much cleaner and more readable now.
      ca887863
    • Andrew Morton's avatar
      [PATCH] Clean up MAX_NR_NODES/NUMNODES/etc. [5/5] · d5135580
      Andrew Morton authored
      From: Matthew Dobson <colpatch@us.ibm.com>
      
      Fix up the ia64 arch.
      d5135580
    • Andrew Morton's avatar
      [PATCH] Clean up MAX_NR_NODES/NUMNODES/etc. [4/5] · b9fa8456
      Andrew Morton authored
      From: Matthew Dobson <colpatch@us.ibm.com>
      
      Fix up the arm arch.  This needs to be reviewed.  Relatively
      straightforward replacement of NR_NODES with standard MAX_NUMNODES.
      b9fa8456
    • Andrew Morton's avatar
      [PATCH] Clean up MAX_NR_NODES/NUMNODES/etc. [3/5] · dbe97702
      Andrew Morton authored
      From: Matthew Dobson <colpatch@us.ibm.com>
      
      Fix up the sh arch.  sh defined NR_NODES, change sh to use standard
      MAX_NUMNODES instead.
      dbe97702
    • Andrew Morton's avatar
      [PATCH] Clean up MAX_NR_NODES/NUMNODES/etc. [2/5] · 5bdcf4f8
      Andrew Morton authored
      From: Matthew Dobson <colpatch@us.ibm.com>
      
      Remove MAX_NR_NODES.  This value is only used in a couple of places, and
      it's incorrectly used in all those places as far as I can tell.  Replace
      with MAX_NUMNODES.  Create MAX_NODES_SHIFT and use this value to check
      NODES_SHIFT is appropriate.  A possible future patch should make
      MAX_NODES_SHIFT vary based on 32 vs.  64 bit archs.
      5bdcf4f8
    • Andrew Morton's avatar
      [PATCH] Clean up MAX_NR_NODES/NUMNODES/etc. [1/5] · c72da22f
      Andrew Morton authored
      From: Matthew Dobson <colpatch@us.ibm.com>
      
      This starts a series of cleanups against the way in which the various
      architectures specify the number of nodes and memory zones.  We end up
      supporting up to 1024 memory zones on ia64, which is a recent requirement.
      
      Has been tested on ia32, ia64 (UMA), ppa64 (UMA) and NUMAQ.
      
      
      Make sure MAX_NUMNODES is defined in one and only one place.  Remove
      superfluous definitions.  Instead of defining MAX_NUMNODES in
      asm/numnodes.h, we define NODES_SHIFT there.  Then in linux/mmzone.h we
      turn that NODES_SHIFT value into MAX_NUMNODES.
      c72da22f
    • Andrew Morton's avatar
      [PATCH] boot-time selectable log buffer size · 96fcef0a
      Andrew Morton authored
      From: Andrea Arcangeli <andrea@suse.de>
      
      Allow the printk log buffer size to be selected with a __setup parameter,
      `log_buf_len=N', where N must be a power-of-two.
      
      The default, initial statically allocated buffer size is still determined via
      kernel config.
      96fcef0a
  2. 04 Oct, 2003 22 commits