Skip to content
  1. Aug 08, 2009
    • Phillip Lougher's avatar
      bzip2/lzma/gzip: fix comments describing decompressor API · daeb6b6f
      Phillip Lougher authored
      
      
      Fix and improve comments in decompress/generic.h that describe the
      decompressor API.  Also remove an unused definition, and rename INBUF_LEN
      in lib/decompress_inflate.c to conform to bzip2/lzma naming.
      
      Signed-off-by: default avatarPhillip Lougher <phillip@lougher.demon.co.uk>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      daeb6b6f
    • Eric Dumazet's avatar
      execve: must clear current->clear_child_tid · 9c8a8228
      Eric Dumazet authored
      While looking at Jens Rosenboom bug report
      (http://lkml.org/lkml/2009/7/27/35
      
      ) about strange sys_futex call done from
      a dying "ps" program, we found following problem.
      
      clone() syscall has special support for TID of created threads.  This
      support includes two features.
      
      One (CLONE_CHILD_SETTID) is to set an integer into user memory with the
      TID value.
      
      One (CLONE_CHILD_CLEARTID) is to clear this same integer once the created
      thread dies.
      
      The integer location is a user provided pointer, provided at clone()
      time.
      
      kernel keeps this pointer value into current->clear_child_tid.
      
      At execve() time, we should make sure kernel doesnt keep this user
      provided pointer, as full user memory is replaced by a new one.
      
      As glibc fork() actually uses clone() syscall with CLONE_CHILD_SETTID and
      CLONE_CHILD_CLEARTID set, chances are high that we might corrupt user
      memory in forked processes.
      
      Following sequence could happen:
      
      1) bash (or any program) starts a new process, by a fork() call that
         glibc maps to a clone( ...  CLONE_CHILD_SETTID | CLONE_CHILD_CLEARTID
         ...) syscall
      
      2) When new process starts, its current->clear_child_tid is set to a
         location that has a meaning only in bash (or initial program) context
         (&THREAD_SELF->tid)
      
      3) This new process does the execve() syscall to start a new program.
         current->clear_child_tid is left unchanged (a non NULL value)
      
      4) If this new program creates some threads, and initial thread exits,
         kernel will attempt to clear the integer pointed by
         current->clear_child_tid from mm_release() :
      
              if (tsk->clear_child_tid
                  && !(tsk->flags & PF_SIGNALED)
                  && atomic_read(&mm->mm_users) > 1) {
                      u32 __user * tidptr = tsk->clear_child_tid;
                      tsk->clear_child_tid = NULL;
      
                      /*
                       * We don't check the error code - if userspace has
                       * not set up a proper pointer then tough luck.
                       */
      << here >>      put_user(0, tidptr);
                      sys_futex(tidptr, FUTEX_WAKE, 1, NULL, NULL, 0);
              }
      
      5) OR : if new program is not multi-threaded, but spied by /proc/pid
         users (ps command for example), mm_users > 1, and the exiting program
         could corrupt 4 bytes in a persistent memory area (shm or memory mapped
         file)
      
      If current->clear_child_tid points to a writeable portion of memory of the
      new program, kernel happily and silently corrupts 4 bytes of memory, with
      unexpected effects.
      
      Fix is straightforward and should not break any sane program.
      
      Reported-by: default avatarJens Rosenboom <jens@mcbone.net>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sonny Rao <sonnyrao@us.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ulrich Drepper <drepper@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9c8a8228
    • Julia Lawall's avatar
      drivers/mmc: correct error-handling code · 2198a64a
      Julia Lawall authored
      sdhci_alloc_host returns an ERR_PTR value in an error case instead of NULL.
      
      A simplified version of the semantic match that finds this problem is as
      follows: (http://coccinelle.lip6.fr/
      
      )
      
      // <smpl>
      @match exists@
      expression x, E;
      statement S1, S2;
      @@
      
      x = sdhci_alloc_host(...)
      ... when != x = E
      (
      *  if (x == NULL || ...) S1 else S2
      |
      *  if (x == NULL && ...) S1 else S2
      )
      // </smpl>
      
      Signed-off-by: default avatarJulia Lawall <julia@diku.dk>
      Acked-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Cc: Matt Fleming <matt@console-pimps.org>
      Cc: Ian Molton <ian@mnementh.co.uk>
      Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
      Cc: Philip Langdale <philipl@overt.org>
      Cc: Pierre Ossman <pierre@ossman.eu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2198a64a
    • Guennadi Liakhovetski's avatar
      i.MX31: fix framebuffer locking regressions · 20de03da
      Guennadi Liakhovetski authored
      
      
      Recent framebuffer locking patches first made affected systems unbootable,
      then the dead-lock has been fixed but as of 2.6.31-rc4 the framebuffer on
      mx3 machines doesn't work. Fix this.
      
      Signed-off-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      20de03da
    • OGAWA Hirofumi's avatar
      vfs: mnt_want_write_file(): fix special file handling · 2d8dd38a
      OGAWA Hirofumi authored
      
      
      I suspect that mnt_want_write_file() may have wrong assumption.  I think
      mnt_want_write_file() is assuming it increments ->mnt_writers if
      (file->f_mode & FMODE_WRITE).  But, if it's special_file(), it is false?
      
      Signed-off-by: default avatarOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Acked-by: default avatarDave Hansen <dave@linux.vnet.ibm.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2d8dd38a
    • Eric Sandeen's avatar
      compat_ioctl: hook up compat handler for FIEMAP ioctl · 69130c7c
      Eric Sandeen authored
      
      
      The FIEMAP_IOC_FIEMAP mapping ioctl was missing a 32-bit compat handler,
      which means that 32-bit suerspace on 64-bit kernels cannot use this ioctl
      command.
      
      The structure is nicely aligned, padded, and sized, so it is just this
      simple.
      
      Tested w/ 32-bit ioctl tester (from Josef) on a 64-bit kernel on ext4.
      
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Cc: <linux-ext4@vger.kernel.org>
      Cc: Mark Lord <lkml@rtr.ca>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Josef Bacik <josef@redhat.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      69130c7c
    • Johannes Weiner's avatar
      fbcon: don't use vc_resize() on initialization · 0035fe00
      Johannes Weiner authored
      
      
      Catalin and kmemleak spotted a leak of a VC screen buffer in
      vc_allocate() due to the following chain of events:
      
      	vc_allocate()
      	  visual_init(init=1)
      	    vc->vc_sw->con_init(init=1)
                    fbcon_init()
      	        vc_resize()
      	          vc->screen_buf = kmalloc()
      	  vc->screen_buf = kmalloc()
      
      The common way for the VC drivers is to set the screen dimension
      parameters manually in the init case and only call vc_resize() for
      !init - which allocates a screen buffer according to the new
      dimensions.
      
      fbcon instead would do vc_resize() unconditionally and afterwards set
      the dimensions manually (again) for !init - i.e. completely upside
      down.  The vc_resize() allocated buffer would then get lost by
      vc_allocate() allocating a fresh one.
      
      Use vc_resize() only for actual resizing to close the leak.
      
      Set the dimensions manually only in initialization mode to remove the
      redundant setting in resize mode.
      
      The kmemleak trace from Catalin:
      
      unreferenced object 0xde158000 (size 12288):
        comm "Xorg", pid 1439, jiffies 4294961016
        hex dump (first 32 bytes):
          20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00   . . . . . . . .
          20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00   . . . . . . . .
        backtrace:
          [<c006f74b>] __save_stack_trace+0x17/0x1c
          [<c006f81d>] create_object+0xcd/0x188
          [<c01f5457>] kmemleak_alloc+0x1b/0x3c
          [<c006e303>] __kmalloc+0xdb/0xe8
          [<c012cc4b>] vc_do_resize+0x73/0x1e0
          [<c012cdf1>] vc_resize+0x15/0x18
          [<c011afc1>] fbcon_init+0x1f9/0x2b8
          [<c0129e87>] visual_init+0x9f/0xdc
          [<c012aff3>] vc_allocate+0x7f/0xfc
          [<c012b087>] con_open+0x17/0x80
          [<c0120e43>] tty_open+0x1f7/0x2e4
          [<c0072fa1>] chrdev_open+0x101/0x118
          [<c006ffad>] __dentry_open+0x105/0x1cc
          [<c00700fd>] nameidata_to_filp+0x2d/0x38
          [<c00788cd>] do_filp_open+0x2c1/0x54c
          [<c006fdff>] do_sys_open+0x3b/0xb4
      
      Reported-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Tested-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Tested-by: default avatarDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      0035fe00
    • Florian Tobias Schandinat's avatar
      viafb: fix rmmod bug · 52159444
      Florian Tobias Schandinat authored
      
      
      This fixes a bug caused by changing pointers (viafb_mode, viafb_mode1)
      assigned by module_param.  It reduces driver complexity by not needlessly
      changing these vars as they are only read once and removing now
      superfluous code.
      
      On unpatched kernels loading viafb with viafb_mode or viafb_mode1 option
      used and afterwards unloading it results in:
      
      kernel BUG at mm/slub.c:2926!
      invalid opcode: 0000 [#1] PREEMPT
      last sysfs file: /sys/devices/virtual/block/loop0/removable
      Modules linked in: snd_hda_codec_realtek snd_hda_intel snd_hda_codec
      snd_hwdep snd_pcm rtl8187 snd_timer eeprom_93cx6 mmc_block snd soundcore
      via_sdmmc fb snd_page_alloc i2c_algo_bit i2c_viapro ehci_hcd uhci_hcd
      cfbcopyarea mmc_core cfbimgblt cfbfillrect video output [last unloaded:
      viafb]
      
        Pid: 3355, comm: rmmod Not tainted (2.6.31-rc1 #0)
        EIP: 0060:[<c106a759>] EFLAGS: 00010246 CPU: 0
        EIP is at kfree+0x80/0xda
        EAX: c17c2da0 EBX: dc7edbdc ECX: 0000010f EDX: 00000000
        ESI: c102c700 EDI: dc7ed8fa EBP: d703ff2c ESP: d703ff20
         DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
        Process rmmod (pid: 3355, ti=d703e000 task=db1412c0 task.ti=d703e000)
        Stack:
         dc7edbdc 00000014 00000016 d703ff40 c102c700 dc7f45d4 dc7f45d4 00000880
         d703ff4c c103e571 00000000 d703ffac c103e751 66616976 da140062 db89ba80
         00000328 d702edf8 db89ba80 d703ff9c c105d0f0 00000200 da14f898 00000014
        Call Trace:
         [<c102c700>] ? destroy_params+0x1e/0x2b
         [<c103e571>] ? free_module+0xa2/0xd7
         [<c103e751>] ? sys_delete_module+0x1ab/0x1da
         [<c105d0f0>] ? do_munmap+0x20a/0x225
         [<c10029b4>] ? sysenter_do_call+0x12/0x26
        Code: 10 76 7a 8d 87 00 00 00 40 c1 e8 0c c1 e0 05 03 05 1c 87 41 c1 66 83 38 00 79 03 8b 40 0c 8b 10 84 d2 78 12 66 f7 c2 00 c0 75 04 <0f> 0b eb fe e8 6f 5a fe ff eb 47 8b 55 04 8b 58 0c 9c 5e fa 3b
        EIP: [<c106a759>] kfree+0x80/0xda SS:ESP 0068:d703ff20
      
      This is caused by the current code changing the pointers assigned by
      module_param.  During unload it tries to free the memory the pointers
      point at which is now part of an internal structure.
      
      The patch simply avoids changing the pointers.  This is okay as they are
      read only once during the initialization process.
      
      Signed-off-by: default avatarFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Scott Fang <ScottFang@viatech.com.cn>
      Cc: Joseph Chan <JosephChan@via.com.tw>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      52159444
    • KAMEZAWA Hiroyuki's avatar
      mm: make set_mempolicy(MPOL_INTERLEAV) N_HIGH_MEMORY aware · 4bfc4495
      KAMEZAWA Hiroyuki authored
      At first, init_task's mems_allowed is initialized as this.
       init_task->mems_allowed == node_state[N_POSSIBLE]
      
      And cpuset's top_cpuset mask is initialized as this
       top_cpuset->mems_allowed = node_state[N_HIGH_MEMORY]
      
      Before 2.6.29:
      policy's mems_allowed is initialized as this.
      
        1. update tasks->mems_allowed by its cpuset->mems_allowed.
        2. policy->mems_allowed = nodes_and(tasks->mems_allowed, user's mask)
      
      Updating task's mems_allowed in reference to top_cpuset's one.
      cpuset's mems_allowed is aware of N_HIGH_MEMORY, always.
      
      In 2.6.30: After commit 58568d2a
      
      
      ("cpuset,mm: update tasks' mems_allowed in time"), policy's mems_allowed
      is initialized as this.
      
        1. policy->mems_allowd = nodes_and(task->mems_allowed, user's mask)
      
      Here, if task is in top_cpuset, task->mems_allowed is not updated from
      init's one.  Assume user excutes command as #numactrl --interleave=all
      ,....
      
        policy->mems_allowd = nodes_and(N_POSSIBLE, ALL_SET_MASK)
      
      Then, policy's mems_allowd can includes a possible node, which has no pgdat.
      
      MPOL's INTERLEAVE just scans nodemask of task->mems_allowd and access this
      directly.
      
        NODE_DATA(nid)->zonelist even if NODE_DATA(nid)==NULL
      
      Then, what's we need is making policy->mems_allowed be aware of
      N_HIGH_MEMORY.  This patch does that.  But to do so, extra nodemask will
      be on statck.  Because I know cpumask has a new interface of
      CPUMASK_ALLOC(), I added it to node.
      
      This patch stands on old behavior.  But I feel this fix itself is just a
      Band-Aid.  But to do fundametal fix, we have to take care of memory
      hotplug and it takes time.  (task->mems_allowd should be N_HIGH_MEMORY, I
      think.)
      
      mpol_set_nodemask() should be aware of N_HIGH_MEMORY and policy's nodemask
      should be includes only online nodes.
      
      In old behavior, this is guaranteed by frequent reference to cpuset's
      code.  Now, most of them are removed and mempolicy has to check it by
      itself.
      
      To do check, a few nodemask_t will be used for calculating nodemask.  But,
      size of nodemask_t can be big and it's not good to allocate them on stack.
      
      Now, cpumask_t has CPUMASK_ALLOC/FREE an easy code for get scratch area.
      NODEMASK_ALLOC/FREE shoudl be there.
      
      [akpm@linux-foundation.org: cleanups & tweaks]
      Tested-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Miao Xie <miaox@cn.fujitsu.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Paul Menage <menage@google.com>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Lee Schermerhorn <lee.schermerhorn@hp.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4bfc4495
    • Stefani Seibold's avatar
      fbcon: fix rotate upside down crash · 93274e4d
      Stefani Seibold authored
      
      
      Fix the rotate_ud() function not to crash in case of a font which has not
      a width of multiple by 8: The inner loop of the font pixel copy should not
      access a bit outside the font memory area.  Subtract the shift offset from
      the font width will prevent this.
      
      Signed-off-by: default avatarStefani Seibold <stefani@seibold.net>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      93274e4d
    • Xiao Guangrong's avatar
      generic-ipi: fix hotplug_cfd() · 69dd647f
      Xiao Guangrong authored
      Use CONFIG_HOTPLUG_CPU, not CONFIG_CPU_HOTPLUG
      
      When hot-unpluging a cpu, it will leak memory allocated at cpu hotplug,
      but only if CPUMASK_OFFSTACK=y, which is default to n.
      
      The bug was introduced by 8969a5ed
      
      
      ("generic-ipi: remove kmalloc()").
      
      Signed-off-by: default avatarXiao Guangrong <xiaoguangrong@cn.fujitsu.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jens Axboe <jens.axboe@oracle.com>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      69dd647f
    • Stoyan Gaydarov's avatar
      drivers/w1/masters/omap_hdq.c: fix missing mutex unlock · 2020002a
      Stoyan Gaydarov authored
      This was found using a semantic patch, more info can be found at:
      http://www.emn.fr/x-info/coccinelle/
      
      
      
      Signed-off-by: default avatarStoyan Gaydarov <sgayda2@uiuc.edu>
      Acked-by: default avatarEvgeniy Polyakov <johnpol@2ka.mipt.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2020002a
  2. Aug 05, 2009