1. 18 12月, 2009 1 次提交
  2. 16 12月, 2009 1 次提交
  3. 23 9月, 2009 19 次提交
  4. 08 8月, 2009 1 次提交
    • 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
  5. 13 5月, 2009 1 次提交
  6. 31 3月, 2009 1 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      Alexey Dobriyan 提交于
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
      as correctly noted at bug #12454. Someone can lookup entry with NULL
      ->owner, thus not pinning enything, and release it later resulting
      in module refcount underflow.
      
      We can keep ->owner and supply it at registration time like ->proc_fops
      and ->data.
      
      But this leaves ->owner as easy-manipulative field (just one C assignment)
      and somebody will forget to unpin previous/pin current module when
      switching ->owner. ->proc_fops is declared as "const" which should give
      some thoughts.
      
      ->read_proc/->write_proc were just fixed to not require ->owner for
      protection.
      
      rmmod'ed directories will be empty and return "." and ".." -- no harm.
      And directories with tricky enough readdir and lookup shouldn't be modular.
      We definitely don't want such modular code.
      
      Removing ->owner will also make PDE smaller.
      
      So, let's nuke it.
      
      Kudos to Jeff Layton for reminding about this, let's say, oversight.
      
      http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
  7. 07 1月, 2009 1 次提交
  8. 05 1月, 2009 1 次提交
  9. 20 11月, 2008 1 次提交
    • B
      viafb: fix releasing of /proc/viafb/ subtree · c267fd77
      Bruno Prémont 提交于
      When unloading viafb module it does not remove it's /proc/viafb/ subtree
      which causes multiple viafb directories to appear below proc when
      mobprobing viafb and also lets kernel WARN() on duplicate proc entries:
      
      [  145.458387] WARNING: at /usr/src/linux-2.6.28-rc3-git6/fs/proc/generic.c:551 proc_register+0xe6/0x160()
      [  145.458945] proc_dir_entry '/proc/viafb' already registered
      [  145.459278] Modules linked in: viafb(+) i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc sg via_agp agpgart [last unloaded: drm]
      [  145.460647] Pid: 1904, comm: modprobe Tainted: G        W  2.6.28-rc3-git6 #4
      [  145.461064] Call Trace:
      [  145.461248]  [<c01066f1>] ? dump_stack+0x1/0x80
      [  145.461533]  [<c01228a3>] warn_slowpath+0x63/0x80
      [  145.461851]  [<c0253ec9>] ? idr_get_empty_slot+0xe9/0x250
      [  145.462186]  [<c0254120>] ? ida_get_new_above+0xf0/0x150
      [  145.462528]  [<c019fb86>] proc_register+0xe6/0x160
      [  145.462827]  [<c019fdc6>] proc_mkdir_mode+0x36/0x50
      [  145.463135]  [<c019fdef>] proc_mkdir+0xf/0x20
      [  145.463457]  [<f807173c>] viafb_init+0x73c/0xc86 [viafb]
      [  145.463823]  [<f8071000>] ? viafb_init+0x0/0xc86 [viafb]
      [  145.464147]  [<c010111d>] do_one_initcall+0x2d/0x160
      [  145.464460]  [<c01a6543>] ? sysfs_add_file+0x13/0x20
      [  145.464786]  [<c015f031>] ? vfree+0x21/0x30
      [  145.465049]  [<c01433b5>] ? load_module+0x1215/0x1500
      [  145.465381]  [<c014e455>] ? __alloc_pages_internal+0x95/0x400
      [  145.465755]  [<c0143723>] sys_init_module+0x83/0x1a0
      [  145.466065]  [<c016ceed>] ? sys_read+0x3d/0x70
      [  145.466354]  [<c0103bc1>] sysenter_do_call+0x12/0x25
      [  145.466653] ---[ end trace c84b37826e16748c ]---
      Signed-off-by: NBruno Prémont <bonbons@linux-vserver.org>
      Cc: <JosephChan@via.com.tw>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c267fd77
  10. 17 10月, 2008 2 次提交