1. 06 3月, 2012 5 次提交
    • J
      aio: wake up waiters when freeing unused kiocbs · 880641bb
      Jeff Moyer 提交于
      Bart Van Assche reported a hung fio process when either hot-removing
      storage or when interrupting the fio process itself.  The (pruned) call
      trace for the latter looks like so:
      
        fio             D 0000000000000001     0  6849   6848 0x00000004
         ffff880092541b88 0000000000000046 ffff880000000000 ffff88012fa11dc0
         ffff88012404be70 ffff880092541fd8 ffff880092541fd8 ffff880092541fd8
         ffff880128b894d0 ffff88012404be70 ffff880092541b88 000000018106f24d
        Call Trace:
          schedule+0x3f/0x60
          io_schedule+0x8f/0xd0
          wait_for_all_aios+0xc0/0x100
          exit_aio+0x55/0xc0
          mmput+0x2d/0x110
          exit_mm+0x10d/0x130
          do_exit+0x671/0x860
          do_group_exit+0x44/0xb0
          get_signal_to_deliver+0x218/0x5a0
          do_signal+0x65/0x700
          do_notify_resume+0x65/0x80
          int_signal+0x12/0x17
      
      The problem lies with the allocation batching code.  It will
      opportunistically allocate kiocbs, and then trim back the list of iocbs
      when there is not enough room in the completion ring to hold all of the
      events.
      
      In the case above, what happens is that the pruning back of events ends
      up freeing up the last active request and the context is marked as dead,
      so it is thus responsible for waking up waiters.  Unfortunately, the
      code does not check for this condition, so we end up with a hung task.
      Signed-off-by: NJeff Moyer <jmoyer@redhat.com>
      Reported-by: NBart Van Assche <bvanassche@acm.org>
      Tested-by: NBart Van Assche <bvanassche@acm.org>
      Cc: <stable@kernel.org>		[3.2.x only]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      880641bb
    • P
      kprobes: return proper error code from register_kprobe() · f986a499
      Prashanth Nageshappa 提交于
      register_kprobe() aborts if the address of the new request falls in a
      prohibited area (such as ftrace pouch, __kprobes annotated functions,
      non-kernel text addresses, jump label text).  We however don't return the
      right error on this abort, resulting in a silent failure - incorrect
      adding/reporting of kprobes ('perf probe do_fork+18' or 'perf probe
      mcount' for instance).
      
      In V2 we are incorporating Masami Hiramatsu's  feedback.
      
      This patch fixes it by returning -EINVAL upon failure.
      
      While we are here, rename the label used for exit to be more appropriate.
      Signed-off-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NPrashanth K Nageshappa <prashanth@linux.vnet.ibm.com>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f986a499
    • M
      kmsg_dump: don't run on non-error paths by default · c22ab332
      Matthew Garrett 提交于
      Since commit 04c6862c ("kmsg_dump: add kmsg_dump() calls to the
      reboot, halt, poweroff and emergency_restart paths"), kmsg_dump() gets
      run on normal paths including poweroff and reboot.
      
      This is less than ideal given pstore implementations that can only
      represent single backtraces, since a reboot may overwrite a stored oops
      before it's been picked up by userspace.  In addition, some pstore
      backends may have low performance and provide a significant delay in
      reboot as a result.
      
      This patch adds a printk.always_kmsg_dump kernel parameter (which can also
      be changed from userspace).  Without it, the code will only be run on
      failure paths rather than on normal paths.  The option can be enabled in
      environments where there's a desire to attempt to audit whether or not a
      reboot was cleanly requested or not.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Acked-by: NSeiji Aguchi <seiji.aguchi@hds.com>
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Marco Stornelli <marco.stornelli@gmail.com>
      Cc: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c22ab332
    • L
      Merge tag 'mmc-fixes-for-3.3' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc · 550cf00d
      Linus Torvalds 提交于
      MMC fixes from Chris Ball for 3.3:
       - atmel-mci: oops fix against regression introduced in 3.2
       - core: power saving regression fix against 3.3-rc1
       - core: suspend/resume fix for UHS-I cards
       - esdhc-imx: MMC card regression fix against 3.0
       - mmci: oops fix for ARM systems with large (64k) pages
       - MAINTAINERS update for atmel-mci.
      
      * tag 'mmc-fixes-for-3.3' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
        mmc: core: Fixup suspend/resume issues for UHS-I cards
        mmc: mmci: reduce max_blk_count to avoid overflowing max_req_size
        mmc: sdhci-esdhc-imx: fix for mmc cards on i.MX5
        mmc: core: fix regression: set default clock gating delay to 0
        MAINTAINERS: hand over atmel-mci (sd/mmc interface)
        mmc: atmel-mci: don't use dma features when using DMA with no chan available
      550cf00d
    • L
      Merge branch 'upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid · 5d329e24
      Linus Torvalds 提交于
      Pull from Jiri Kosina:
       "Please pull to receive updates for HID layer.  Nikolai's patch is
        rather important and should still go in for 3.3, as it's a regression
        fix for commit b4b583d4."
      
      * 'upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
        HID: hid-input: allow array fields out of range
        HID: usbhid: Add NOGET quirk for the AIREN Slim+ keyboard
      5d329e24
  2. 05 3月, 2012 8 次提交
    • N
      HID: hid-input: allow array fields out of range · 883e0e36
      Nikolai Kondrashov 提交于
      Allow array field values out of range as per HID 1.11 specification,
      section 6.2.25:
      
      	Rather than returning a single bit for each button in the group, an
      	array returns an index in each field that corresponds to the pressed
      	button (like keyboard scan codes). An out-of range value in and array
      	field is considered no controls asserted.
      
      Apparently, "and" above is a typo and should be "an".
      
      This fixes at least Waltop tablet pen clicks - otherwise BTN_TOUCH is never
      released.
      
      The relevant part of Waltop tablet report descriptors is this:
      
      	0x09, 0x42,         /*          Usage (Tip Switch),         */
      	0x09, 0x44,         /*          Usage (Barrel Switch),      */
      	0x09, 0x46,         /*          Usage (Tablet Pick),        */
      	0x15, 0x01,         /*          Logical Minimum (1),        */
      	0x25, 0x03,         /*          Logical Maximum (3),        */
      	0x75, 0x04,         /*          Report Size (4),            */
      	0x95, 0x01,         /*          Report Count (1),           */
      	0x80,               /*          Input,                      */
      
      This is a regression fix for commit b4b583d4 ("HID: be more strict when
      ignoring out-of-range fields").
      Signed-off-by: NNikolai Kondrashov <spbnick@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      883e0e36
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6 · a5939eef
      Linus Torvalds 提交于
      MFD fixes from Samuel Ortiz:
       "This is the pull request for the MFD fixes for 3.3.  We have a few
        NULL pointer dereferences fixes, an ACPI conflict check fix, and a
        couple of wm8994 fixes."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6:
        mfd: Correct readability of WM8994 DC servo 4E register
        mfd: Initialize tps65912 irq platform data properly
        mfd: Fix ACPI conflict check
        mfd: Fix ab8500 error path bug
        mfd: Test for jack detection when deciding if wm8994 should suspend
        mfd: Initialize tps65910 irq platform data properly
        mfd: Fix possible s5m null pointer dereference
        mfd: wm8350 variable dereferenced before check
      a5939eef
    • L
      vfs: move dentry_cmp from <linux/dcache.h> to fs/dcache.c · 5483f18e
      Linus Torvalds 提交于
      It's only used inside fs/dcache.c, and we're going to play games with it
      for the word-at-a-time patches.  This time we really don't even want to
      export it, because it really is an internal function to fs/dcache.c, and
      has been since it was introduced.
      
      Having it in that extremely hot header file (it's included in pretty
      much everything, thanks to <linux/fs.h>) is a disaster for testing
      different versions, and is utterly pointless.
      
      We really should have some kind of header file diet thing, where we
      figure out which parts of header files are really better off private and
      only result in more expensive compiles.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5483f18e
    • U
      mmc: core: Fixup suspend/resume issues for UHS-I cards · e7747475
      Ulf Hansson 提交于
      Even if cards supports 1.8V I/O voltage those should anyway be
      initialized at 3.3V I/O according to (e)MMC, SD and SDIO specs.
      Some eMMC and embedded SDIO devices are able to be initialized
      at 1.8V as well, but it is better to be safe.
      
      Do note that initialization in this context means that the card
      has been completely powered off, otherwise the card will remain
      at the last I/O voltage level that were negotitiated.
      
      Due to the above being taken care of the suspend/resume issues
      for UHS-I SD-cards has been fixed.
      Signed-off-by: NUlf Hansson <ulf.hansson@stericsson.com>
      Acked-by: NPhilip Rakity <prakity@marvell.com>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Tested-by: NSubhash Jadavani <subhashj@codeaurora.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      e7747475
    • W
      mmc: mmci: reduce max_blk_count to avoid overflowing max_req_size · 8f7f6b7e
      Will Deacon 提交于
      On a system with large pages (64k in my case), the following BUG is
      triggered in MMC core:
      
      [    2.338023] BUG: failure at drivers/mmc/core/core.c:221/mmc_start_request()!
      [    2.338102] Kernel panic - not syncing: BUG!
      [    2.338155] Call trace:
      [    2.338228] [<ffffffc00008635c>] dump_backtrace+0x0/0x120
      [    2.338317] [<ffffffc0003365ec>] dump_stack+0x14/0x1c
      [    2.338403] [<ffffffc000336990>] panic+0xbc/0x1f0
      [    2.338498] [<ffffffc00027a494>] mmc_start_request+0x154/0x184
      [    2.338600] [<ffffffc00027abdc>] mmc_start_req+0x110/0x140
      [    2.338701] [<ffffffc00028604c>] mmc_blk_issue_rw_rq+0x7c/0x39c
      [    2.338804] [<ffffffc00028652c>] mmc_blk_issue_rq+0x1c0/0x468
      [    2.338905] [<ffffffc000287564>] mmc_queue_thread+0x68/0x118
      [    2.338995] [<ffffffc0000bc308>] kthread+0x84/0x8c
      
      This is because of a 64k request with a max_req_size of 64k-1 bytes.
      
      The following patch fixes the problem by limiting the max_blk_count
      such that max_blk_count * max_blk_size == max_req_size. I couldn't
      pursuade the compiler to emit a shift instead of a div without encoding
      the shift explicitly.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      8f7f6b7e
    • S
      mmc: sdhci-esdhc-imx: fix for mmc cards on i.MX5 · 5b6b0ad6
      Sascha Hauer 提交于
      On i.MX53 we have to write a special SDHCI_CMD_ABORTCMD to the
      SDHCI_TRANSFER_MODE register during a MMC_STOP_TRANSMISSION
      command. This works for SD cards. However, with MMC cards
      the MMC_SET_BLOCK_COUNT command is used instead, but this
      needs the same handling. Fix MMC cards by testing for the
      MMC_SET_BLOCK_COUNT command aswell. Tested on a custom i.MX53
      board with a Transcend MMC+ card and eMMC.
      
      The kernel started used MMC_SET_BLOCK_COUNT in 3.0, so this
      is a regression for these boards introduced in 3.0; it should
      go to 3.0/3.1/3.2-stable.
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      5b6b0ad6
    • G
      mmc: core: fix regression: set default clock gating delay to 0 · c84f15ae
      Guennadi Liakhovetski 提交于
      A recent commit "mmc: core: Use delayed work in clock gating framework"
      (597dd9d7) introduced a default 200ms delay before clock gating
      actually takes place.  This means that every time an MMC interface
      becomes idle it first stays on for 200ms before gating its clock. This
      leads to increased power consumption and is therefore a clear regression.
      This patch restores the original behaviour by setting the default delay
      to 0. Users prioritising throughput over power efficiency can still
      modify the delay via sysfs.
      Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      c84f15ae
    • N
      MAINTAINERS: hand over atmel-mci (sd/mmc interface) · 24e1511f
      Nicolas Ferre 提交于
      Modify MAINTAINERS entry for Atmel SD/MMC drivers.
      I hand the atmel-mci and at91_mci drivers over to Ludovic.
      Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      24e1511f
  3. 04 3月, 2012 5 次提交
  4. 03 3月, 2012 14 次提交
  5. 02 3月, 2012 8 次提交