1. 29 Jun, 2010 6 commits
    • Andres Salomon's avatar
      gxfb: fix incorrect __init annotation · 500ebb82
      Andres Salomon authored
      WARNING: vmlinux.o(.data+0x195d8): Section mismatch in reference from the
      variable gxfb_driver to the function .init.text:gxfb_probe() The variable
      gxfb_driver references the function __init gxfb_probe()
      
      This changes gxfb_probe and friends to use __devinit, and also adds
      __devexit to gxfb_remove.
      Signed-off-by: default avatarAndres Salomon <dilinger@queued.net>
      Cc: Jordan Crouse <jordan.crouse@amd.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      500ebb82
    • KAMEZAWA Hiroyuki's avatar
      memcg: fix wake up in oom wait queue · 4d845ebf
      KAMEZAWA Hiroyuki authored
      OOM-waitqueue should be waken up when oom_disable is canceled.  This is a
      fix for 3c11ecf4 ("memcg: oom kill disable and oom status").
      
      How to test:
       Create a cgroup A...
       1. set memory.limit and memory.memsw.limit to be small value
       2. echo 1 > /cgroup/A/memory.oom_control, this disables oom-kill.
       3. run a program which must cause OOM.
      
      A program executed in 3 will sleep by oom_waiqueue in memcg.  Then, how to
      wake it up is problem.
      
       1. echo 0 > /cgroup/A/memory.oom_control (enable OOM-killer)
       2. echo big mem > /cgroup/A/memory.memsw.limit_in_bytes(allow more swap)
      
      etc..
      
      Without the patch, a task in slept can not be waken up.
      Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: default avatarDaisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4d845ebf
    • Mike Frysinger's avatar
      nommu: add '[stack]' label to /proc/pid/maps output · 3c26c9d9
      Mike Frysinger authored
      Add support to the NOMMU /proc/pid/maps file to show which mapping is the stack
      of the original thread after execve.  This is largely based on the MMU code.
      Subsidiary thread stacks are not indicated.
      
      For FDPIC, we now get:
      
      	root:/> cat /proc/self/maps
      	02064000-02067ccc rw-p 0004d000 00:01 22         /bin/busybox
      	0206e000-0206f35c rw-p 00006000 00:01 295        /lib/ld-uClibc.so.0
      	025f0000-025f6f0c r-xs 00000000 00:01 295        /lib/ld-uClibc.so.0
      	02680000-026ba6b0 r-xs 00000000 00:01 297        /lib/libc.so.0
      	02700000-0274d384 r-xs 00000000 00:01 22         /bin/busybox
      	02816000-02817000 rw-p 00000000 00:00 0
      	02848000-0284c0d8 rw-p 00000000 00:00 0
      	02860000-02880000 rw-p 00000000 00:00 0          [stack]
      
      The semi-downside here is that for FLAT, we get:
      
      	root:/> cat /proc/155/maps
      	029f0000-029f9000 rwxp 00000000 00:00 0          [stack]
      
      The reason being that FLAT combines a whole lot of stuff into one map
      (including the stack).  But this isn't any worse than the current output
      (which is nothing), so screw it.
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Greg Ungerer <gerg@snapgear.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3c26c9d9
    • Imre Deak's avatar
      genalloc: fix allocation from end of pool · e621ba99
      Imre Deak authored
      bitmap_find_next_zero_area requires the size of the bitmap, we instead
      passed the last suitable position.  This made it impossible to allocate
      from the end of the pool.
      
      Fixes a regression introduced by 243797f5
      ("genalloc: use bitmap_find_next_zero_area").
      Signed-off-by: default avatarImre Deak <imre.deak@nokia.com>
      Cc: Zygo Blaxell <zygo.blaxell@xandros.com>
      Cc: Tejun Heo <tj@kernel.org>
      Acked-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e621ba99
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-2.6-block · 984bc960
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.dk/linux-2.6-block:
        block: Don't count_vm_events for discard bio in submit_bio.
        cfq: fix recursive call in cfq_blkiocg_update_completion_stats()
        cfq-iosched: Fixed boot warning with BLK_CGROUP=y and CFQ_GROUP_IOSCHED=n
        cfq: Don't allow queue merges for queues that have no process references
        block: fix DISCARD_BARRIER requests
        cciss: set SCSI max cmd len to 16, as default is wrong
        cpqarray: fix two more wrong section type
        cpqarray: fix wrong __init type on pci probe function
        drbd: Fixed a race between disk-attach and unexpected state changes
        writeback: fix pin_sb_for_writeback
        writeback: add missing requeue_io in writeback_inodes_wb
        writeback: simplify and split bdi_start_writeback
        writeback: simplify wakeup_flusher_threads
        writeback: fix writeback_inodes_wb from writeback_inodes_sb
        writeback: enforce s_umount locking in writeback_inodes_sb
        writeback: queue work on stack in writeback_inodes_sb
        writeback: fix writeback completion notifications
      984bc960
    • npiggin@suse.de's avatar
      fs: fix superblock iteration race · 57439f87
      npiggin@suse.de authored
      list_for_each_entry_safe is not suitable to protect against concurrent
      modification of the list. 6754af64 introduced a race in sb walking.
      
      list_for_each_entry can use the trick of pinning the current entry in
      the list before we drop and retake the lock because it subsequently
      follows cur->next. However list_for_each_entry_safe saves n=cur->next
      for following before entering the loop body, so when the lock is
      dropped, n may be deleted.
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: John Stultz <johnstul@us.ibm.com>
      Cc: Frank Mayhar <fmayhar@google.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      57439f87
  2. 28 Jun, 2010 13 commits
  3. 27 Jun, 2010 21 commits