14 Feb, 2013

24 commits


01 Feb, 2013

6 commits

  • Linus Torvalds
     
  • Pull more device-mapper fixes from Alasdair G Kergon:
    "A fix for stacked dm thin devices and a fix for the new dm WRITE SAME
    support."

    * tag 'dm-3.8-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-dm:
    dm: fix write same requests counting
    dm thin: fix queue limits stacking

    Linus Torvalds
     
  • PullHID fixes from Jiri Kosina:

    - fix i2c-hid and hidraw interaction, by Benjamin Tissoires

    - a quirk to make a particular device (Formosa IR receiver) work
    properly, by Nicholas Santos

    * 'for-3.8/upstream-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
    HID: i2c-hid: fix i2c_hid_output_raw_report
    HID: usbhid: quirk for Formosa IR receiver
    HID: remove x bit from sensor doc

    Linus Torvalds
     
  • Pull NFS client bugfixes from Trond Myklebust:

    - Error reporting in nfs_xdev_mount incorrectly maps all errors to
    ENOMEM

    - Fix an NFSv4 refcounting issue

    - Fix a mount failure when the server reboots during NFSv4 trunking
    discovery

    - NFSv4.1 mounts may need to run the lease recovery thread.

    - Don't silently fail setattr() requests on mountpoints

    - Fix a SUNRPC socket/transport livelock and priority queue issue

    - We must handle NFS4ERR_DELAY when resetting the NFSv4.1 session.

    * tag 'nfs-for-3.8-4' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
    NFSv4.1: Handle NFS4ERR_DELAY when resetting the NFSv4.1 session
    SUNRPC: When changing the queue priority, ensure that we change the owner
    NFS: Don't silently fail setattr() requests on mountpoints
    NFSv4.1: Ensure that nfs41_walk_client_list() does start lease recovery
    NFSv4: Fix NFSv4 trunking discovery
    NFSv4: Fix NFSv4 reference counting for trunked sessions
    NFS: Fix error reporting in nfs_xdev_mount

    Linus Torvalds
     
  • Pull MIPS updates from Ralf Baechle:
    "A number of fixes all across the MIPS tree. No area is particularly
    standing out and things have cooled down quite nicely for a release."

    * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
    MIPS: Function tracer: Fix broken function tracing
    mips: Move __virt_addr_valid() to a place for MIPS 64
    MIPS: Netlogic: Fix UP compilation on XLR
    MIPS: AR71xx: Fix AR71XX_PCI_MEM_SIZE
    MIPS: AR724x: Fix AR724X_PCI_MEM_SIZE
    MIPS: Lantiq: Fix cp0_perfcount_irq mapping
    MIPS: DSP: Fix DSP mask for registers.
    MIPS: Fix build failure by adding definition of pfn_pmd().
    MIPS: Octeon: Fix warning.
    MIPS: delay.c: Check BITS_PER_LONG instead of __SIZEOF_LONG__
    MIPS: PNX833x: Fix comment.
    MIPS: Add struct p_format to union mips_instruction.
    MIPS: Export .
    MIPS: BCM47xx: Enable SSB prerequisite SSB_DRIVER_PCICORE.
    MIPS: BCM47xx: Select GPIOLIB for BCMA on bcm47xx platform
    MIPS: vpe.c: Fix null pointer dereference in print arguments.

    Linus Torvalds
     
  • i2c_hid_output_raw_report is used by hidraw to forward set_report requests.
    The current implementation of i2c_hid_set_report needs to take the
    report_id as an argument. The report_id is stored in the first byte
    of the buffer in argument of i2c_hid_output_raw_report.

    Not removing the report_id from the given buffer adds this byte 2 times
    in the command, leading to a non working command.

    Reported-by: Andrew Duggan
    Signed-off-by: Benjamin Tissoires
    Signed-off-by: Jiri Kosina

    Benjamin Tissoires
     

31 Jan, 2013

10 commits

  • Function tracing is currently broken for all 32 bit MIPS platforms.
    When tracing is enabled, the kernel immediately hangs on boot.
    This is a result of commit b732d439cb43336cd6d7e804ecb2c81193ef63b0
    that changes the kernel/trace/Kconfig file so that is no longer
    forces FRAME_POINTER when FUNCTION_TRACING is enabled.

    MIPS frame pointers are generally considered to be useless because
    they cannot be used to unwind the stack. Unfortunately the MIPS
    function tracing code has bugs that are masked by the use of frame
    pointers. This commit fixes the bugs so that MIPS frame pointers
    don't need to be enabled.

    The bugs are a result of the odd calling sequence used to call the trace
    routine. This calling sequence is inserted into every traceable function
    when the tracing CONFIG option is enabled. This sequence is generated
    for 32bit MIPS platforms by the compiler via the "-pg" flag.

    Part of the sequence is "addiu sp,sp,-8" in the delay slot after every
    call to the trace routine "_mcount" (some legacy thing where 2 arguments
    used to be pushed on the stack). The _mcount routine is expected to
    adjust the sp by +8 before returning. So when not disabled, the original
    jalr and addiu will be there, so _mcount has to adjust sp.

    The problem is that when tracing is disabled for a function, the
    "jalr _mcount" instruction is replaced with a nop, but the
    "addiu sp,sp,-8" is still executed and the stack pointer is left
    trashed. When frame pointers are enabled the problem is masked
    because any access to the stack is done through the frame
    pointer and the stack pointer is restored from the frame pointer when
    the function returns.

    This patch writes two nops starting at the address of the "jalr _mcount"
    instruction whenever tracing is disabled. This means that the
    "addiu sp,sp.-8" will be converted to a nop along with the "jalr". When
    disabled, there will be two nops.

    This is SMP safe because the first time this happens is during
    ftrace_init() which is before any other processor has been started.
    Subsequent calls to enable/disable tracing when other CPUs ARE running
    will still be safe because the enable will only change the first nop
    to a "jalr" and the disable, while writing 2 nops, will only be changing
    the "jalr". This patch also stops using stop_machine() to call the
    tracer enable/disable routines and calls them directly because the
    routines are SMP safe.

    When the kernel first boots we have to be able to handle the gcc
    generated jalr, addui sequence until ftrace_init gets a chance to run
    and change the sequence. At this point mcount just adjusts the stack
    and returns. When ftrace_init runs, we convert the jalr/addui to nops.
    Then whenever tracing is enabled we convert the first nop to a "jalr
    mcount+8". The mcount+8 entry point skips the stack adjust.

    [ralf@linux-mips.org: Folded in Steven Rostedt's build fix.]

    Signed-off-by: Al Cooper
    Cc: rostedt@goodmis.org
    Cc: ddaney.cavm@gmail.com
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Patchwork: https://patchwork.linux-mips.org/patch/4806/
    Patchwork: https://patchwork.linux-mips.org/patch/4841/
    Signed-off-by: Ralf Baechle

    Al Cooper
     
  • When processing write same requests, fix dm to send the configured
    number of WRITE SAME requests to the target rather than the number of
    discards, which is not always the same.

    Device-mapper WRITE SAME support was introduced by commit
    23508a96cd2e857d57044a2ed7d305f2d9daf441 ("dm: add WRITE SAME support").

    Signed-off-by: Alasdair G Kergon
    Acked-by: Mike Snitzer

    Alasdair G Kergon
     
  • Commit d3ce88431892 "MIPS: Fix modpost error in modules attepting to use
    virt_addr_valid()" moved __virt_addr_valid() from a macro in a header
    file to a function in ioremap.c. But ioremap.c is only compiled for MIPS
    32, and not for MIPS 64.

    When compiling for my yeeloong2, which supposedly supports hibernation,
    which compiles kernel/power/snapshot.c which calls virt_addr_valid(), I
    got this error:

    LD init/built-in.o
    kernel/built-in.o: In function `memory_bm_free':
    snapshot.c:(.text+0x4c9c4): undefined reference to `__virt_addr_valid'
    snapshot.c:(.text+0x4ca58): undefined reference to `__virt_addr_valid'
    kernel/built-in.o: In function `snapshot_write_next':
    (.text+0x4e44c): undefined reference to `__virt_addr_valid'
    kernel/built-in.o: In function `snapshot_write_next':
    (.text+0x4e890): undefined reference to `__virt_addr_valid'
    make[1]: *** [vmlinux] Error 1
    make: *** [sub-make] Error 2

    I suspect that __virt_addr_valid() is fine for mips 64. I moved it to
    mmap.c such that it gets compiled for mips 64 and 32.

    Signed-off-by: Steven Rostedt
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-mips@linux-mips.org
    Patchwork: https://patchwork.linux-mips.org/patch/4842/
    Signed-off-by: Ralf Baechle

    Steven Rostedt
     
  • thin_io_hints() is blindly copying the queue limits from the thin-pool
    which can lead to incorrect limits being set. The fix here simply
    deletes the thin_io_hints() hook which leaves the existing stacking
    infrastructure to set the limits correctly.

    When a thin-pool uses an MD device for the data device a thin device
    from the thin-pool must respect MD's constraints about disallowing a bio
    from spanning multiple chunks. Otherwise we can see problems. If the raid0
    chunksize is 1152K and thin-pool chunksize is 256K I see the following
    md/raid0 error (with extra debug tracing added to thin_endio) when
    mkfs.xfs is executed against the thin device:

    md/raid0:md99: make_request bug: can't convert block across chunks or bigger than 1152k 6688 127
    device-mapper: thin: bio sector=2080 err=-5 bi_size=130560 bi_rw=17 bi_vcnt=32 bi_idx=0

    This extra DM debugging shows that the failing bio is spanning across
    the first and second logical 1152K chunk (sector 2080 + 255 takes the
    bio beyond the first chunk's boundary of sector 2304). So the bio
    splitting that DM is doing clearly isn't respecting the MD limits.

    max_hw_sectors_kb is 127 for both the thin-pool and thin device
    (queue_max_hw_sectors returns 255 so we'll excuse sysfs's lack of
    precision). So this explains why bi_size is 130560.

    But the thin device's max_hw_sectors_kb should be 4 (PAGE_SIZE) given
    that it doesn't have a .merge function (for bio_add_page to consult
    indirectly via dm_merge_bvec) yet the thin-pool does sit above an MD
    device that has a compulsory merge_bvec_fn. This scenario is exactly
    why DM must resort to sending single PAGE_SIZE bios to the underlying
    layer. Some additional context for this is available in the header for
    commit 8cbeb67a ("dm: avoid unsupported spanning of md stripe boundaries").

    Long story short, the reason a thin device doesn't properly get
    configured to have a max_hw_sectors_kb of 4 (PAGE_SIZE) is that
    thin_io_hints() is blindly copying the queue limits from the thin-pool
    device directly to the thin device's queue limits.

    Fix this by eliminating thin_io_hints. Doing so is safe because the
    block layer's queue limits stacking already enables the upper level thin
    device to inherit the thin-pool device's discard and minimum_io_size and
    optimal_io_size limits that get set in pool_io_hints. But avoiding the
    queue limits copy allows the thin and thin-pool limits to be different
    where it is important, namely max_hw_sectors_kb.

    Reported-by: Daniel Browning
    Signed-off-by: Mike Snitzer
    Cc: stable@vger.kernel.org
    Signed-off-by: Alasdair G Kergon

    Mike Snitzer
     
  • Pull x86 EFI fixes from Peter Anvin:
    "This is a collection of fixes for the EFI support. The controversial
    bit here is a set of patches which bumps the boot protocol version as
    part of fixing some serious problems with the EFI handover protocol,
    used when booting under EFI using a bootloader as opposed to directly
    from EFI. These changes should also make it a lot saner to support
    cross-mode 32/64-bit EFI booting in the future. Getting these changes
    into 3.8 means we avoid presenting an inconsistent ABI to bootloaders.

    Other changes are display detection and fixing efivarfs."

    * 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    x86, efi: remove attribute check from setup_efi_pci
    x86, build: Dynamically find entry points in compressed startup code
    x86, efi: Fix PCI ROM handing in EFI boot stub, in 32-bit mode
    x86, efi: Fix 32-bit EFI handover protocol entry point
    x86, efi: Fix display detection in EFI boot stub
    x86, boot: Define the 2.12 bzImage boot protocol
    x86/boot: Fix minor fd leakage in tools/relocs.c
    x86, efi: Set runtime_version to the EFI spec revision
    x86, efi: fix 32-bit warnings in setup_efi_pci()
    efivarfs: Delete dentry from dcache in efivarfs_file_write()
    efivarfs: Never return ENOENT from firmware
    efi, x86: Pass a proper identity mapping in efi_call_phys_prelog
    efivarfs: Drop link count of the right inode

    Linus Torvalds
     
  • Pull x86 fixes from Peter Anvin:
    "This is a collection of miscellaneous fixes, the most important one is
    the fix for the Samsung laptop bricking issue (auto-blacklisting the
    samsung-laptop driver); the efi_enabled() changes you see below are
    prerequisites for that fix.

    The other issues fixed are booting on OLPC XO-1.5, an UV fix, NMI
    debugging, and requiring CAP_SYS_RAWIO for MSR references, just as
    with I/O port references."

    * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    samsung-laptop: Disable on EFI hardware
    efi: Make 'efi_enabled' a function to query EFI facilities
    smp: Fix SMP function call empty cpu mask race
    x86/msr: Add capabilities check
    x86/dma-debug: Bump PREALLOC_DMA_DEBUG_ENTRIES
    x86/olpc: Fix olpc-xo1-sci.c build errors
    arch/x86/platform/uv: Fix incorrect tlb flush all issue
    x86-64: Fix unwind annotations in recent NMI changes
    x86-32: Start out cr0 clean, disable paging before modifying cr3/4

    Linus Torvalds
     
  • Pull console lockdep checking revert from Dave Airlie.

    The lockdep splat this showed was interesting, but it's very very old,
    and we won't be fixing it until 3.9. In the meantime, undo the lockdep
    annotation so that we don't generate the (known) console lockdep issue,
    and then possibly hide any potential other (unknown) lockdep problems
    that got disabled by the first one that triggered.

    * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
    Revert "console: implement lockdep support for console_lock"

    Linus Torvalds
     
  • This reverts commit daee779718a319ff9f83e1ba3339334ac650bb22.

    I'll requeue this after the console locking fixes, so lockdep
    is useful again for people until fbcon is fixed.

    Signed-off-by: Dave Airlie

    Dave Airlie
     
  • NFS4ERR_DELAY is a legal reply when we call DESTROY_SESSION. It
    usually means that the server is busy handling an unfinished RPC
    request. Just sleep for a second and then retry.
    We also need to be able to handle the NFS4ERR_BACK_CHAN_BUSY return
    value. If the NFS server has outstanding callbacks, we just want to
    similarly sleep & retry.

    Signed-off-by: Trond Myklebust
    Cc: stable@vger.kernel.org

    Trond Myklebust
     
  • This fixes a livelock in the xprt->sending queue where we end up never
    making progress on lower priority tasks because sleep_on_priority()
    keeps adding new tasks with the same owner to the head of the queue,
    and priority bumps mean that we keep resetting the queue->owner to
    whatever task is at the head of the queue.

    Regression introduced by commit c05eecf636101dd4347b2d8fa457626bf0088e0a
    (SUNRPC: Don't allow low priority tasks to pre-empt higher priority ones).

    Reported-by: Andy Adamson
    Signed-off-by: Trond Myklebust

    Trond Myklebust