1. 17 4月, 2009 13 次提交
    • K
      proc: mounts_poll() make consistent to mdstat_poll · 31b07093
      KOSAKI Motohiro 提交于
      In recently sysfs_poll discussion, Neil Brown pointed out /proc/mounts
      also should be fixed.
      
      SUSv3 says "Regular files shall always poll TRUE for reading and
      writing".  see
      http://www.opengroup.org/onlinepubs/009695399/functions/poll.html
      
      Then, mounts_poll()'s default should be "POLLIN | POLLRDNORM".  it mean
      always readable.
      
      In addition, event trigger should use "POLLERR | POLLPRI" instead
      POLLERR.  it makes consistent to mdstat_poll() and sysfs_poll(). and,
      select(2) can handle POLLPRI easily.
      Reported-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Ram Pai <linuxram@us.ibm.com>
      Cc: Miklos Szeredi <mszeredi@suse.cz>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      31b07093
    • K
      sysfs: sysfs poll keep the poll rule of regular file. · 1af3557a
      KOSAKI Motohiro 提交于
      Currently, following test programs don't finished.
      
      % ruby -e '
      Thread.new { sleep }
      File.read("/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies")
      '
      
      strace expose the reason.
      
      ...
      open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies", O_RDONLY|O_LARGEFILE) = 3
      ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbf9fa6b8) = -1 ENOTTY (Inappropriate ioctl for device)
      fstat64(3, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
      _llseek(3, 0, [0], SEEK_CUR)            = 0
      select(4, [3], NULL, NULL, NULL)        = 1 (in [3])
      read(3, "1400000 1300000 1200000 1100000 1"..., 4096) = 62
      select(4, [3], NULL, NULL, NULL
      
      
      Because Ruby (the scripting language) VM assume select system-call
      against regular file don't block.  it because SUSv3 says "Regular files
      shall always poll TRUE for reading and writing".  see
      http://www.opengroup.org/onlinepubs/009695399/functions/poll.html it
      seems valid assumption.
      
      But sysfs_poll() don't keep this rule although sysfs file can read and
      write always.
      
      This patch restore proper poll behavior to sysfs.
      /sys/block/md*/md/sync_action polling application and another sysfs
      updating sensitive application still can use POLLERR and POLLPRI.
      
      Cc: Neil Brown <neilb@suse.de>
      Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1af3557a
    • K
      driver core: allow non-root users to listen to uevents · d094cbe9
      Kay Sievers 提交于
      Users can read sysfs files, there is no reason they should not be
      allowed to listen to uevents.  This lets xorg and other userspace
      programs properly get these messages without having to be root.
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      d094cbe9
    • 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 10 次提交
    • T
      Merge branch 'topic/hda' into for-linus · 9dd175f7
      Takashi Iwai 提交于
      * topic/hda:
        ALSA: hda - Fix the cmd cache keys for amp verbs
        ALSA: add missing definitions(letters) to HD-Audio.txt
      9dd175f7
    • T
      ALSA: hda - Fix the cmd cache keys for amp verbs · fcad94a4
      Takashi Iwai 提交于
      Fix the key value generation for get/set amp verbs.  The upper bits of
      the parameter have to be combined with the verb value to be unique for
      each direction/index of amp access.
      
      This fixes the resume problem on some hardwares like Macbook after
      the channel mode is changed.
      Tested-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: <stable@kernel.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      fcad94a4
    • L
      Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc · a23c218b
      Linus Torvalds 提交于
      * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
        powerpc: pseries/dtl.c should include asm/firmware.h
        powerpc: Fix data-corrupting bug in __futex_atomic_op
        powerpc/pseries: Set error_state to pci_channel_io_normal in eeh_report_reset()
        powerpc: Allow 256kB pages with SHMEM
        powerpc: Document new FSL I2C bindings and cleanup
        powerpc/mm: Fix compile warning
        powerpc/85xx: TQM8548: update defconfig
        powerpc/85xx: TQM8548: use proper phy-handles for enet2 and enet3
        powerpc/85xx: TQM85xx: correct address of LM75 I2C device nodes
        powerpc: Add support for early tlbilx opcode
        powerpc: Fix tlbilx opcode
      a23c218b
    • L
      acpi-cpufreq: fix 'smp_call_function_many()' confusion · ea34f43a
      Linus Torvalds 提交于
      It turns out that 'smp_call_function_many()' doesn't work at all like
      'smp_call_function_single()', and my change to Andrew's patch to use it
      rather than a loop over all CPU's acpi-cpufreq doesn't work.
      
      My bad.
      
      'smp_call_function_many()' has two "features" (aka "documented bugs"):
      
       (a) it needs to be called with preemption disabled, because it uses
           smp_processor_id() without guarding the CPU lookup with 'get_cpu()'
           and 'put_cpu()' like the 'single' variant does.
      
       (b) even if the current CPU is part of the CPU mask, it won't do the
           call on that CPU.
      
      Still, we're better off trying to use 'smp_call_function_many()' than
      looping over CPU's, since it at least in theory allows us to use a
      broadcast IPI and do it all in parallel.  So let's just work around the
      silly semantic bugs in that function.
      Reported-and-tested-by: NAli Gholami Rudi <ali@rudi.ir>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andrew Morton <akpm@linux-foundation.org>,
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Dave Jones <davej@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ea34f43a
    • E
      packet: avoid warnings when high-order page allocation fails · 719bfeaa
      Eric Dumazet 提交于
      Latest tcpdump/libpcap triggers annoying messages because of high order page
      allocation failures (when lowmem exhausted or fragmented)
      
      These allocation errors are correctly handled so could be silent.
      
      [22660.208901] tcpdump: page allocation failure. order:5, mode:0xc0d0
      [22660.208921] Pid: 13866, comm: tcpdump Not tainted 2.6.30-rc2 #170
      [22660.208936] Call Trace:
      [22660.208950]  [<c04e2b46>] ? printk+0x18/0x1a
      [22660.208965]  [<c02760f7>] __alloc_pages_internal+0x357/0x460
      [22660.208980]  [<c0276251>] __get_free_pages+0x21/0x40
      [22660.208995]  [<c04cc835>] packet_set_ring+0x105/0x3d0
      [22660.209009]  [<c04ccd1d>] packet_setsockopt+0x21d/0x4d0
      [22660.209025]  [<c0270400>] ? filemap_fault+0x0/0x450
      [22660.209040]  [<c0449e34>] sys_setsockopt+0x54/0xa0
      [22660.209053]  [<c044b97f>] sys_socketcall+0xef/0x270
      [22660.209067]  [<c0202e34>] sysenter_do_call+0x12/0x26
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      719bfeaa
    • J
      cfq-iosched: add close cooperator code · a36e71f9
      Jens Axboe 提交于
      If we have processes that are working in close proximity to each
      other on disk, we don't want to idle wait. Instead allow the close
      process to issue a request, getting better aggregate bandwidth.
      The anticipatory scheduler has similar checks, noop and deadline do
      not need it since they don't care about process <-> io mappings.
      
      The code for CFQ is a little more involved though, since we split
      request queues into per-process contexts.
      
      This fixes a performance problem with eg dump(8), since it uses
      several processes in some silly attempt to speed IO up. Even if
      dump(8) isn't really a valid case (it should be fixed by using
      CLONE_IO), there are other cases where we see close processes
      and where idling ends up hurting performance.
      
      Credit goes to Jeff Moyer <jmoyer@redhat.com> for writing the
      initial implementation.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      a36e71f9
    • J
      cfq-iosched: log responsible 'cfqq' in idle timer arm · 9481ffdc
      Jens Axboe 提交于
      Makes it easier to read the traces.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      9481ffdc
    • J
      cfq-iosched: tweak kick logic a bit more · 2d870722
      Jens Axboe 提交于
      We only kick the dispatch for an idling queue, if we think it's a
      (somewhat) fully merged request. Also allow a kick if we have other
      busy queues in the system, since we don't want to risk waiting for
      a potential merge in that case. It's better to get some work done and
      proceed.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      2d870722
    • J
      cfq-iosched: no need to save interrupts in cfq_kick_queue() · 40bb54d1
      Jens Axboe 提交于
      It's called from the workqueue handlers from process context, so
      we always have irqs enabled when entered.
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      40bb54d1
    • N
      brd: fix cacheflushing · c2572f2b
      Nick Piggin 提交于
      brd is missing a flush_dcache_page. On 2nd thoughts, perhaps it is the
      pagecache's responsibility to flush user virtual aliases (the driver of
      course should flush kernel virtual mappings)... but anyway, there
      already exists cache flushing for one direction of transfer, so we
      should add the other.
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      c2572f2b