1. 08 8月, 2009 7 次提交
    • E
      compat_ioctl: hook up compat handler for FIEMAP ioctl · 69130c7c
      Eric Sandeen 提交于
      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: NEric 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      69130c7c
    • J
      fbcon: don't use vc_resize() on initialization · 0035fe00
      Johannes Weiner 提交于
      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: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
      Tested-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Tested-by: NDave Young <hidave.darkstar@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0035fe00
    • F
      viafb: fix rmmod bug · 52159444
      Florian Tobias Schandinat 提交于
      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: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: Scott Fang <ScottFang@viatech.com.cn>
      Cc: Joseph Chan <JosephChan@via.com.tw>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      52159444
    • K
      mm: make set_mempolicy(MPOL_INTERLEAV) N_HIGH_MEMORY aware · 4bfc4495
      KAMEZAWA Hiroyuki 提交于
      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: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: NKAMEZAWA 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4bfc4495
    • S
      fbcon: fix rotate upside down crash · 93274e4d
      Stefani Seibold 提交于
      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: NStefani Seibold <stefani@seibold.net>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      93274e4d
    • X
      generic-ipi: fix hotplug_cfd() · 69dd647f
      Xiao Guangrong 提交于
      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: NXiao 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      69dd647f
    • S
      drivers/w1/masters/omap_hdq.c: fix missing mutex unlock · 2020002a
      Stoyan Gaydarov 提交于
      This was found using a semantic patch, more info can be found at:
      http://www.emn.fr/x-info/coccinelle/Signed-off-by: NStoyan Gaydarov <sgayda2@uiuc.edu>
      Acked-by: NEvgeniy Polyakov <johnpol@2ka.mipt.ru>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2020002a
  2. 05 8月, 2009 32 次提交
  3. 04 8月, 2009 1 次提交
    • S
      x86: Work around compilation warning in arch/x86/kernel/apm_32.c · dc731fbb
      Subrata Modak 提交于
      The following fix was initially inspired by David Howells fix
      few days back:
      
        http://lkml.org/lkml/2009/7/9/109
      
      However, Ingo disapproves such fixes as it's dangerous (it can
      hide future, relevant warnings) - in something as
      performance-uncritical.
      
      So, initialize 'err' to '0' to work around a GCC false positive
      warning:
      
        http://lkml.org/lkml/2009/7/18/89
      
      Signed-off-by: Subrata Modak<subrata@linux.vnet.ibm.com>
      Cc: Sachin P Sant <sachinp@linux.vnet.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Balbir Singh <balbir@linux.vnet.ibm.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      LKML-Reference: <20090721023226.31855.67236.sendpatchset@subratamodak.linux.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dc731fbb