1. 01 11月, 2012 1 次提交
    • B
      NFS: Wait for session recovery to finish before returning · 399f11c3
      Bryan Schumaker 提交于
      Currently, we will schedule session recovery and then return to the
      caller of nfs4_handle_exception.  This works for most cases, but causes
      a hang on the following test case:
      
      	Client				Server
      	------				------
      	Open file over NFS v4.1
      	Write to file
      					Expire client
      	Try to lock file
      
      The server will return NFS4ERR_BADSESSION, prompting the client to
      schedule recovery.  However, the client will continue placing lock
      attempts and the open recovery never seems to be scheduled.  The
      simplest solution is to wait for session recovery to run before retrying
      the lock.
      Signed-off-by: NBryan Schumaker <bjschuma@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Cc: stable@vger.kernel.org
      399f11c3
  2. 31 10月, 2012 8 次提交
    • A
      Return the right error value when dup[23]() newfd argument is too large · 08f05c49
      Al Viro 提交于
      Jack Lin reports that the error return from dup3() for the RLIMIT_NOFILE
      case changed incorrectly after 3.6.
      
      The culprit is commit f33ff992 ("take rlimit check to callers of
      expand_files()") which when it moved the "return -EMFILE" out to the
      caller, didn't notice that the dup3() had special code to turn the
      EMFILE return into EBADF.
      
      The replace_fd() helper that got added later then inherited the bug too.
      Reported-by: NJack Lin <linliangjie@huawei.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      [ Noted more bugs, wrote proper changelog, fixed up typos - Linus ]
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      08f05c49
    • L
      Merge tag 'md-3.7-fixes' of git://neil.brown.name/md · 2df4f261
      Linus Torvalds 提交于
      Pull md fixes from NeilBrown:
       "Some fixes for md in 3.7
         - one recently introduced crash for dm-raid10 with discard
         - one bug in new functionality that has been around for a few
           releases.
         - minor bug in md's 'faulty' personality
      
        and UAPI disintegration for md."
      
      * tag 'md-3.7-fixes' of git://neil.brown.name/md:
        MD RAID10: Fix oops when creating RAID10 arrays via dm-raid.c
        md/raid1: Fix assembling of arrays containing Replacements.
        md faulty: use disk_stack_limits()
        UAPI: (Scripted) Disintegrate include/linux/raid
      2df4f261
    • J
      MD RAID10: Fix oops when creating RAID10 arrays via dm-raid.c · ed30be07
      Jonathan Brassow 提交于
      Commit 2863b9eb didn't take into account the changes to add TRIM support to
      RAID10 (commit 532a2a3f).  That is, when using dm-raid.c to create the
      RAID10 arrays, there is no mddev->gendisk or mddev->queue.  The code added
      to support TRIM simply assumes that mddev->queue is available without
      checking.  The result is an oops any time dm-raid.c attempts to create a
      RAID10 device.
      Signed-off-by: NJonathan Brassow <jbrassow@redhat.com>
      Signed-off-by: NNeilBrown <neilb@suse.de>
      ed30be07
    • N
      md/raid1: Fix assembling of arrays containing Replacements. · 02b898f2
      NeilBrown 提交于
      setup_conf in raid1.c uses conf->raid_disks before assigning
      a value.  It is used when including 'Replacement' devices.
      
      The consequence is that assembling an array which contains a
      replacement will misbehave and either not include the replacement, or
      not include the device being replaced.
      
      Though this doesn't lead directly to data corruption, it could lead to
      reduced data safety.
      
      So use mddev->raid_disks, which is initialised, instead.
      
      Bug was introduced by commit c19d5798
            md/raid1: recognise replacements when assembling arrays.
      
      in 3.3, so fix is suitable for 3.3.y thru 3.6.y.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NNeilBrown <neilb@suse.de>
      02b898f2
    • L
      Merge tag 'gpio-fixes-v3.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio · bc909421
      Linus Torvalds 提交于
      Pull GPIO fixes from Linus Walleij:
       - Fix a potential bit wrap issue in the Timberdale driver
       - Fix up the buffer allocation size in the 74x164 driver
       - Set the value in direction_output() right in the mvebu driver
       - Return proper error codes for invalid GPIOs
       - Fix an off-mode bug for the OMAP
       - Don't initialize the mask_cach on the mvebu driver
      
      * tag 'gpio-fixes-v3.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
        GPIO: mvebu-gpio: Don't initialize the mask_cache
        gpio/omap: fix off-mode bug: clear debounce settings on free/reset
        gpiolib: Don't return -EPROBE_DEFER to sysfs, or for invalid gpios
        gpio: mvebu: correctly set the value in direction_output()
        gpio-74x164: Fix buffer allocation size
        gpio-timberdale: fix a potential wrapping issue
      bc909421
    • L
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · 8c673cbc
      Linus Torvalds 提交于
      Pull ext4 bugfix from Ted Ts'o:
       "This fixes the root cause of the ext4 data corruption bug which raised
        a ruckus on LWN, Phoronix, and Slashdot.
      
        This bug only showed up when non-standard mount options
        (journal_async_commit and/or journal_checksum) were enabled, and when
        the file system was not cleanly unmounted, but the root cause was the
        inode bitmap modifications was not being properly journaled.
      
        This could potentially lead to minor file system corruptions (pass 5
        complaints with the inode allocation bitmap) after an unclean shutdown
        under the wrong/unlucky workloads, but it turned into major failure if
        the journal_checksum and/or jouaral_async_commit was enabled."
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: fix unjournaled inode bitmap modification
      8c673cbc
    • L
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 4476c0ee
      Linus Torvalds 提交于
      Pull block driver update from Jens Axboe:
       "Distilled down variant, the rest will pass over to 3.8.  I pulled it
        into the for-linus branch I had waiting for a pull request as well, in
        case you are wondering why there are new entries in here too.  This
        also got rid of two reverts and the ones of the mtip32xx patches that
        went in later in the 3.6 cycle, so the series looks a bit cleaner."
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        loop: Make explicit loop device destruction lazy
        mtip32xx:Added appropriate timeout value for secure erase
        xen/blkback: Change xen_vbd's flush_support and discard_secure to have type unsigned int, rather than bool
        cciss: select CONFIG_CHECK_SIGNATURE
        cciss: remove unneeded memset()
        xen/blkback: use kmem_cache_zalloc instead of kmem_cache_alloc/memset
        pktcdvd: update MAINTAINERS
        floppy: remove dr, reuse drive on do_floppy_init
        floppy: use common function to check if floppies can be registered
        floppy: properly handle failure on add_disk loop
        floppy: do put_disk on current dr if blk_init_queue fails
        floppy: don't call alloc_ordered_workqueue inside the alloc_disk loop
        xen/blkback: Fix compile warning
        block: Add blk_rq_pos(rq) to sort rq when plushing
        drivers/block: remove CONFIG_EXPERIMENTAL
        block: remove CONFIG_EXPERIMENTAL
        vfs: fix: don't increase bio_slab_max if krealloc() fails
        blkcg: stop iteration early if root_rl is the only request list
        blkcg: Fix use-after-free of q->root_blkg and q->root_rl.blkg
      4476c0ee
    • A
      GPIO: mvebu-gpio: Don't initialize the mask_cache · 8fcff5f1
      Andrew Lunn 提交于
      Due to the SMP nature of some of the chips, which have per CPU
      registers, the driver does not use the generic irq_gc_mask_set_bit() &
      irq_gc_mask_clr_bit() functions, which only support a single register.
      The driver has its own implementation of these functions, which can
      pick the correct register depending on the CPU being used. The
      functions do however use the gc->mask_cache value.
      
      The call to irq_setup_generic_chip() was passing
      IRQ_GC_INIT_MASK_CACHE, which caused the gc->mask_cache to be
      initialized to the contents of some random register. This resulted in
      unexpected interrupts been delivered from random GPIO lines.
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Tested-by: NJamie Lentin <jm@lentin.co.uk>
      Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Tested-by: NMichael Walle <michael@walle.cc>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      8fcff5f1
  3. 30 10月, 2012 13 次提交
  4. 29 10月, 2012 14 次提交
  5. 28 10月, 2012 1 次提交
    • J
      gpio/omap: fix off-mode bug: clear debounce settings on free/reset · c9c55d92
      Jon Hunter 提交于
      This change was originally titled "gpio/omap: fix off-mode bug: clear debounce
      clock enable mask on free/reset". The title has been updated slightly to
      reflect (what should be) the final fix.
      
      When a GPIO is freed or shutdown, we need to ensure that any debounce settings
      are cleared and if the GPIO is the only GPIO in the bank that is currently
      using debounce, then disable the debounce clock as well to save power.
      
      Currently, the debounce settings are not cleared on a GPIO free or shutdown and
      so during a context restore on subsequent off-mode transition, the previous
      debounce values are restored from the shadow copies (bank->context.debounce*)
      leading to mismatch state between driver state and hardware state.
      
      This was discovered when board code was doing
      
        gpio_request_one()
        gpio_set_debounce()
        gpio_free()
      
      which was leaving the GPIO debounce settings in a confused state.  If that GPIO
      bank is subsequently used with off-mode enabled, bogus state would be restored,
      leaving GPIO debounce enabled which then prevented the CORE powerdomain from
      transitioning.
      
      To fix this, introduce a new function called _clear_gpio_debounce() to clear
      any debounce settings when the GPIO is freed or shutdown. If this GPIO is the
      last debounce-enabled GPIO in the bank, the debounce will also be cut.
      
      Please note that we cannot use _gpio_dbck_disable() to disable the debounce
      clock because this has been specifically created for the gpio suspend path
      and is intended to shutdown the debounce clock while debounce is enabled.
      
      Special thanks to Kevin Hilman for root causing the bug. This fix is a
      collaborative effort with inputs from Kevin Hilman, Grazvydas Ignotas and
      Santosh Shilimkar.
      
      Testing:
      - This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
        enabling debounce and then freeing the gpio and checking the register
        contents, the saved register context and the debounce clock state.
      - Kevin Hilman tested on 37xx/EVM board which configures GPIO debounce for the
        ads7846 touchscreen in its board file using the above sequence, and so was
        failing off-mode tests in dynamic idle. Verified that off-mode tests are
        passing with this patch.
      
      V5 changes:
      - Corrected author
      Reported-by: NPaul Walmsley <paul@pwsan.com>
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Cc: Grazvydas Ignotas <notasas@gmail.com>
      Cc: Jon Hunter <jon-hunter@ti.com>
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Reviewed-by: NKevin Hilman <khilman@ti.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      c9c55d92
  6. 27 10月, 2012 3 次提交