1. 11 9月, 2007 2 次提交
    • N
      [NETFILTER]: Fix/improve deadlock condition on module removal netfilter · 16fcec35
      Neil Horman 提交于
      So I've had a deadlock reported to me.  I've found that the sequence of
      events goes like this:
      
      1) process A (modprobe) runs to remove ip_tables.ko
      
      2) process B (iptables-restore) runs and calls setsockopt on a netfilter socket,
      increasing the ip_tables socket_ops use count
      
      3) process A acquires a file lock on the file ip_tables.ko, calls remove_module
      in the kernel, which in turn executes the ip_tables module cleanup routine,
      which calls nf_unregister_sockopt
      
      4) nf_unregister_sockopt, seeing that the use count is non-zero, puts the
      calling process into uninterruptible sleep, expecting the process using the
      socket option code to wake it up when it exits the kernel
      
      4) the user of the socket option code (process B) in do_ipt_get_ctl, calls
      ipt_find_table_lock, which in this case calls request_module to load
      ip_tables_nat.ko
      
      5) request_module forks a copy of modprobe (process C) to load the module and
      blocks until modprobe exits.
      
      6) Process C. forked by request_module process the dependencies of
      ip_tables_nat.ko, of which ip_tables.ko is one.
      
      7) Process C attempts to lock the request module and all its dependencies, it
      blocks when it attempts to lock ip_tables.ko (which was previously locked in
      step 3)
      
      Theres not really any great permanent solution to this that I can see, but I've
      developed a two part solution that corrects the problem
      
      Part 1) Modifies the nf_sockopt registration code so that, instead of using a
      use counter internal to the nf_sockopt_ops structure, we instead use a pointer
      to the registering modules owner to do module reference counting when nf_sockopt
      calls a modules set/get routine.  This prevents the deadlock by preventing set 4
      from happening.
      
      Part 2) Enhances the modprobe utilty so that by default it preforms non-blocking
      remove operations (the same way rmmod does), and add an option to explicity
      request blocking operation.  So if you select blocking operation in modprobe you
      can still cause the above deadlock, but only if you explicity try (and since
      root can do any old stupid thing it would like....  :)  ).
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      16fcec35
    • J
      b311ec4a
  2. 01 9月, 2007 1 次提交
    • T
      NFS: Fix a write request leak in nfs_invalidate_page() · 1b3b4a1a
      Trond Myklebust 提交于
      Ryusuke Konishi says:
      
      The recent truncate_complete_page() clears the dirty flag from a page
      before calling a_ops->invalidatepage(),
      ^^^^^^
      static void
      truncate_complete_page(struct address_space *mapping, struct page *page)
      {
              ...
              cancel_dirty_page(page, PAGE_CACHE_SIZE);  <--- Inserted here at
      kernel 2.6.20
      
              if (PagePrivate(page))
                      do_invalidatepage(page, 0);   ---> will call
      a_ops->invalidatepage()
              ...
      }
      
      and this is disturbing nfs_wb_page_priority() from calling 
      nfs_writepage_locked() that is expected to handle the pending
      request (=nfs_page) associated with the page.
      
      int nfs_wb_page_priority(struct inode *inode, struct page *page, int how)
      {
              ...
              if (clear_page_dirty_for_io(page)) {
                      ret = nfs_writepage_locked(page, &wbc);
                      if (ret < 0)
                              goto out;
              }
              ...
      }
      
      Since truncate_complete_page() will get rid of the page after
      a_ops->invalidatepage() returns, the request (=nfs_page) associated
      with the page becomes a garbage in nfs_inode->nfs_page_tree.
      ------------------------
      
      Fix this by ensuring that nfs_wb_page_priority() recognises that it may
      also need to clear out non-dirty pages that have an nfs_page associated
      with them.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      1b3b4a1a
  3. 31 8月, 2007 7 次提交
  4. 28 8月, 2007 1 次提交
    • I
      sched: make the scheduler converge to the ideal latency · f6cf891c
      Ingo Molnar 提交于
      de-HZ-ification of the granularity defaults unearthed a pre-existing
      property of CFS: while it correctly converges to the granularity goal,
      it does not prevent run-time fluctuations in the range of
      [-gran ... 0 ... +gran].
      
      With the increase of the granularity due to the removal of HZ
      dependencies, this becomes visible in chew-max output (with 5 tasks
      running):
      
       out:  28 . 27. 32 | flu:  0 .  0 | ran:    9 .   13 | per:   37 .   40
       out:  27 . 27. 32 | flu:  0 .  0 | ran:   17 .   13 | per:   44 .   40
       out:  27 . 27. 32 | flu:  0 .  0 | ran:    9 .   13 | per:   36 .   40
       out:  29 . 27. 32 | flu:  2 .  0 | ran:   17 .   13 | per:   46 .   40
       out:  28 . 27. 32 | flu:  0 .  0 | ran:    9 .   13 | per:   37 .   40
       out:  29 . 27. 32 | flu:  0 .  0 | ran:   18 .   13 | per:   47 .   40
       out:  28 . 27. 32 | flu:  0 .  0 | ran:    9 .   13 | per:   37 .   40
      
      average slice is the ideal 13 msecs and the period is picture-perfect 40
      msecs. But the 'ran' field fluctuates around 13.33 msecs and there's no
      mechanism in CFS to keep that from happening: it's a perfectly valid
      solution that CFS finds.
      
      to fix this we add a granularity/preemption rule that knows about
      the "target latency", which makes tasks that run longer than the ideal
      latency run a bit less. The simplest approach is to simply decrease the
      preemption granularity when a task overruns its ideal latency. For this
      we have to track how much the task executed since its last preemption.
      
      ( this adds a new field to task_struct, but we can eliminate that
        overhead in 2.6.24 by putting all the scheduler timestamps into an
        anonymous union. )
      
      with this change in place, chew-max output is fluctuation-less all
      around:
      
       out:  28 . 27. 39 | flu:  0 .  2 | ran:   13 .   13 | per:   41 .   40
       out:  28 . 27. 39 | flu:  0 .  2 | ran:   13 .   13 | per:   41 .   40
       out:  28 . 27. 39 | flu:  0 .  2 | ran:   13 .   13 | per:   41 .   40
       out:  28 . 27. 39 | flu:  0 .  2 | ran:   13 .   13 | per:   41 .   40
       out:  28 . 27. 39 | flu:  0 .  1 | ran:   13 .   13 | per:   41 .   40
       out:  28 . 27. 39 | flu:  0 .  1 | ran:   13 .   13 | per:   41 .   40
      
      this patch has no impact on any fastpath or on any globally observable
      scheduling property. (unless you have sharp enough eyes to see
      millisecond-level ruckles in glxgears smoothness :-)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NMike Galbraith <efault@gmx.de>
      f6cf891c
  5. 27 8月, 2007 2 次提交
  6. 26 8月, 2007 2 次提交
  7. 25 8月, 2007 2 次提交
    • X
      agp: Add device id for P4M900 to via-agp module · 32ddef98
      Xavier Bachelot 提交于
      Signed-off-by: NDave Airlie <airlied@linux.ie>
      32ddef98
    • O
      [POWERPC] Fix undefined reference to device_power_up/resume · e120e8d0
      Olaf Hering 提交于
      Current Linus tree fails to link on pmac32:
      
      drivers/built-in.o: In function `pmac_wakeup_devices':
      via-pmu.c:(.text+0x5bab4): undefined reference to `device_power_up'
      via-pmu.c:(.text+0x5bb08): undefined reference to `device_resume'
      drivers/built-in.o: In function `pmac_suspend_devices':
      via-pmu.c:(.text+0x5c260): undefined reference to `device_power_down'
      via-pmu.c:(.text+0x5c27c): undefined reference to `device_resume'
      make[1]: *** [.tmp_vmlinux1] Error 1
      
      changing CONFIG_PM > CONFIG_PM_SLEEP leads to:
      
      drivers/built-in.o: In function `pmu_led_set':
      via-pmu-led.c:(.text+0x5cdca): undefined reference to `pmu_sys_suspended'
      via-pmu-led.c:(.text+0x5cdce): undefined reference to `pmu_sys_suspended'
      drivers/built-in.o: In function `pmu_req_done':
      via-pmu-led.c:(.text+0x5ce3e): undefined reference to `pmu_sys_suspended'
      via-pmu-led.c:(.text+0x5ce42): undefined reference to `pmu_sys_suspended'
      drivers/built-in.o: In function `adb_init':
      (.init.text+0x4c5c): undefined reference to `pmu_register_sleep_notifier'
      make[1]: *** [.tmp_vmlinux1] Error 1
      
      So change even more places from PM to PM_SLEEP to allow linking.
      Signed-off-by: NOlaf Hering <olaf@aepfle.de>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e120e8d0
  8. 24 8月, 2007 2 次提交
  9. 23 8月, 2007 12 次提交
  10. 22 8月, 2007 1 次提交
  11. 21 8月, 2007 2 次提交
    • B
      ide: add cable detection for early UDMA66 devices (take 3) · a5b7e70d
      Bartlomiej Zolnierkiewicz 提交于
      * Move ide_in_drive_list() from ide-dma.c to ide-iops.c.
      
      * Add ivb_list[] table for listening early UDMA66 devices which don't conform
        to ATA4 standard wrt cable detection (bit14 is zero, only bit13 is valid)
        and use only device side cable detection for them since host side cable
        detection may be unreliable.
      
      * Add model "QUANTUM FIREBALLlct10 05" with firwmare "A03.0900" to the list
        (from Craig's bugreport).
      
      v2:
      * Improve kernel message basing on suggestion from Sergei.
      
      v3:
      * Don't print kernel message when no device side cable detection is done,
        plus some minor fixes.  (Noticed by Sergei)
      
      Thanks to Craig for testing this patch.
      
      Cc: Craig Block <chblock3@yahoo.com>
      Acked-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      a5b7e70d
    • B
      ide: config_drive_for_dma() fixes · 1116fae5
      Bartlomiej Zolnierkiewicz 提交于
      * Add DMA blacklist checking (->ide_dma_on check probably can go now).
      
      * Add ->atapi_dma flag checking and remove no longer needed
        ns87415_ide_dma_check() from ns87415 host driver.
      
      * Remove now needless __ide_dma_check() wrapper and symbol export.
      
      * Check drive->autodma instead of hwif->autodma (there should be no changes in
        behavior as all users of config_drive_for_dma() set both ->autodma flags).
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      1116fae5
  12. 20 8月, 2007 1 次提交
  13. 18 8月, 2007 1 次提交
  14. 14 8月, 2007 1 次提交
  15. 13 8月, 2007 1 次提交
  16. 12 8月, 2007 2 次提交