1. 17 4月, 2009 10 次提交
    • M
      driver core: fix driver_match_device · 5247aecf
      Ming Lei 提交于
      This patch fixes a bug introduced in commit
      49b420a1.
      
      If a instance of bus_type doesn't have  .match method,
      all .probe of drivers in the bus should be called, or else
      the .probe have not a chance to be called.
      Signed-off-by: NMing Lei <tom.leiming@gmail.com>
      Reported-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      5247aecf
    • A
      sysfs: don't use global workqueue in sysfs_schedule_callback() · d110271e
      Alex Chiang 提交于
      A sysfs attribute using sysfs_schedule_callback() to commit suicide
      may end up calling device_unregister(), which will eventually call
      a driver's ->remove function.
      
      Drivers may call flush_scheduled_work() in their shutdown routines,
      in which case lockdep will complain with something like the following:
      
        =============================================
        [ INFO: possible recursive locking detected ]
        2.6.29-rc8-kk #1
        ---------------------------------------------
        events/4/56 is trying to acquire lock:
        (events){--..}, at: [<ffffffff80257fc0>] flush_workqueue+0x0/0xa0
      
        but task is already holding lock:
        (events){--..}, at: [<ffffffff80257648>] run_workqueue+0x108/0x230
      
        other info that might help us debug this:
        3 locks held by events/4/56:
        #0:  (events){--..}, at: [<ffffffff80257648>] run_workqueue+0x108/0x230
        #1:  (&ss->work){--..}, at: [<ffffffff80257648>] run_workqueue+0x108/0x230
        #2:  (pci_remove_rescan_mutex){--..}, at: [<ffffffff803c10d1>] remove_callback+0x21/0x40
      
        stack backtrace:
        Pid: 56, comm: events/4 Not tainted 2.6.29-rc8-kk #1
        Call Trace:
        [<ffffffff8026dfcd>] validate_chain+0xb7d/0x1260
        [<ffffffff8026eade>] __lock_acquire+0x42e/0xa40
        [<ffffffff8026f148>] lock_acquire+0x58/0x80
        [<ffffffff80257fc0>] ? flush_workqueue+0x0/0xa0
        [<ffffffff8025800d>] flush_workqueue+0x4d/0xa0
        [<ffffffff80257fc0>] ? flush_workqueue+0x0/0xa0
        [<ffffffff80258070>] flush_scheduled_work+0x10/0x20
        [<ffffffffa0144065>] e1000_remove+0x55/0xfe [e1000e]
        [<ffffffff8033ee30>] ? sysfs_schedule_callback_work+0x0/0x50
        [<ffffffff803bfeb2>] pci_device_remove+0x32/0x70
        [<ffffffff80441da9>] __device_release_driver+0x59/0x90
        [<ffffffff80441edb>] device_release_driver+0x2b/0x40
        [<ffffffff804419d6>] bus_remove_device+0xa6/0x120
        [<ffffffff8043e46b>] device_del+0x12b/0x190
        [<ffffffff8043e4f6>] device_unregister+0x26/0x70
        [<ffffffff803ba969>] pci_stop_dev+0x49/0x60
        [<ffffffff803baab0>] pci_remove_bus_device+0x40/0xc0
        [<ffffffff803c10d9>] remove_callback+0x29/0x40
        [<ffffffff8033ee4f>] sysfs_schedule_callback_work+0x1f/0x50
        [<ffffffff8025769a>] run_workqueue+0x15a/0x230
        [<ffffffff80257648>] ? run_workqueue+0x108/0x230
        [<ffffffff8025846f>] worker_thread+0x9f/0x100
        [<ffffffff8025bce0>] ? autoremove_wake_function+0x0/0x40
        [<ffffffff802583d0>] ? worker_thread+0x0/0x100
        [<ffffffff8025b89d>] kthread+0x4d/0x80
        [<ffffffff8020d4ba>] child_rip+0xa/0x20
        [<ffffffff8020cebc>] ? restore_args+0x0/0x30
        [<ffffffff8025b850>] ? kthread+0x0/0x80
        [<ffffffff8020d4b0>] ? child_rip+0x0/0x20
      
      Although we know that the device_unregister path will never acquire
      a lock that a driver might try to acquire in its ->remove, in general
      we should never attempt to flush a workqueue from within the same
      workqueue, and lockdep rightly complains.
      
      So as long as sysfs attributes cannot commit suicide directly and we
      are stuck with this callback mechanism, put the sysfs callbacks on
      their own workqueue instead of the global one.
      
      This has the side benefit that if a suicidal sysfs attribute kicks
      off a long chain of ->remove callbacks, we no longer induce a long
      delay on the global queue.
      
      This also fixes a missing module_put in the error path introduced
      by sysfs-only-allow-one-scheduled-removal-callback-per-kobj.patch.
      
      We never destroy the workqueue, but I'm not sure that's a
      problem.
      Reported-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Tested-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d110271e
    • L
      Merge branch 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev · c19f8366
      Linus Torvalds 提交于
      * 'upstream-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev:
        ata: Report 16/32bit PIO as best we can
        libata: use ATA_ID_CFA_*
        pata_legacy: fix no device fail path
        pata_hpt37x: fix HPT370 DMA timeouts
        libata: handle SEMB signature better
      c19f8366
    • H
      mm: pass correct mm when growing stack · 05fa199d
      Hugh Dickins 提交于
      Tetsuo Handa reports seeing the WARN_ON(current->mm == NULL) in
      security_vm_enough_memory(), when do_execve() is touching the
      target mm's stack, to set up its args and environment.
      
      Yes, a UMH_NO_WAIT or UMH_WAIT_PROC call_usermodehelper() spawns
      an mm-less kernel thread to do the exec.  And in any case, that
      vm_enough_memory check when growing stack ought to be done on the
      target mm, not on the execer's mm (though apart from the warning,
      it only makes a slight tweak to OVERCOMMIT_NEVER behaviour).
      Reported-by: NTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      05fa199d
    • H
      Revert "kobject: don't block for each kobject_uevent". · 05f54c13
      Hugh Dickins 提交于
      This reverts commit f520360d.
      
      Tetsuo Handa, running a kernel with CONFIG_DEBUG_PAGEALLOC=y and
      CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug, has been hitting RCU detected
      CPU stalls: it's been spinning in the loop where do_execve() counts up
      the args (but why wasn't fixup_exception working? dunno).
      
      The recent change, switching kobject_uevent_env() from UMH_WAIT_EXEC
      to UMH_NO_WAIT, is broken: the exec uses args on the local stack here,
      and an env which is kfreed as soon as call_usermodehelper() returns.
      It very much needs to wait for the exec to be done.
      
      An alternative would be to keep the UMH_NO_WAIT, and complicate the code
      to allocate and free these resources correctly? but no, as GregKH
      pointed out when making the commit, CONFIG_UEVENT_HELPER_PATH="" is a
      much better optimization - though some distros are still saying
      /sbin/hotplug in their .config, yet with no such binary in their initrd
      or their root.
      Reported-by: NTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: NArjan van de Ven <arjan@linux.intel.com>
      Acked-by: NWill Newton <will.newton@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      05f54c13
    • A
      ata: Report 16/32bit PIO as best we can · e3cf95dd
      Alan Cox 提交于
      The legacy old IDE ioctl API for this is a bit primitive so we try
      and map stuff sensibly onto it.
      
      - Set PIO over DMA devices to report 32bit
      - Add ability to change the PIO32 settings if the controller permits it
      - Add that functionality into the sff drivers
      - Add that functionality into the VLB legacy driver
      - Turn on the 32bit PIO on the ninja32 and add support there
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      e3cf95dd
    • S
      libata: use ATA_ID_CFA_* · 62afe5d7
      Sergei Shtylyov 提交于
      Use ATA_ID_CFA_* constants for CFA specific identify data words 162 and 163.
      Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      62afe5d7
    • T
      pata_legacy: fix no device fail path · 20cbf5f8
      Tejun Heo 提交于
      When pata_legacy can't detect any device, it unregisters the
      platform_device and fails detection.  However, it forgets to detach
      ata host triggering weird failures as the host later gets freed by
      devres while still attached.  Fix it.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      20cbf5f8
    • S
      pata_hpt37x: fix HPT370 DMA timeouts · 265b7215
      Sergei Shtylyov 提交于
      The libata driver has copied the code from the IDE driver which caused a post
      2.4.18 regression on many HPT370[A] chips -- DMA stopped to work completely,
      only causing timeouts.  Now remove hpt370_bmdma_start() for good...
      Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      265b7215
    • T
      libata: handle SEMB signature better · 79b42bab
      Tejun Heo 提交于
      WDC WD1600JS-62MHB5 successfully hits the window between ATA/ATAPI-7
      and Serial ATA II standards and reports 3c/c3 signature which now is
      assigned to SEMB.  Make ata_dev_classify() report ATA_DEV_SEMB on the
      sig and let ata_dev_read_id() work around it by trying IDENTIFY once.
      
      This fixes bko#11579.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Reported-by: NDavid Haun <drhaun88@gmail.com>
      Reported-by: NLars Wirzenius <liw@liw.fi>
      Reported-by: NJuan Manuel <jmcarranza@gmail.com>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      79b42bab
  2. 16 4月, 2009 17 次提交
  3. 15 4月, 2009 13 次提交