07 Jul, 2014

40 commits

  • Greg Kroah-Hartman
     
  • commit a07187c992be945ab561b370cbb49cfd72064c3c upstream.

    For Intel Haswell/Broadwell display HD-A controller, the 24MHz HD-A link BCLK
    is converted from Core Display Clock (CDCLK): BCLK = CDCLK * M / N
    And there are two registers EM4 and EM5 to program M, N value respectively.
    The EM4/EM5 values will be lost and when the display power well is disabled.

    BIOS programs CDCLK selected by OEM and EM4/EM5, but BIOS has no idea about
    display power well on/off at runtime. So the M/N can be wrong if non-default
    CDCLK is used when the audio controller resumes, which results in an invalid
    BCLK and abnormal audio playback rate. So this patch saves and restores valid
    M/N values on controller suspend/resume.

    And 'struct hda_intel' is defined to contain standard HD-A 'struct azx' and
    Intel specific fields, as Takashi suggested.

    Signed-off-by: Mengdong Lin
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Mengdong Lin
     
  • commit 8b3dfdaf0c25a584cb31d04d2574115cf2d422ab upstream.

    HP Spectre 13 has the IDT 92HD95 codec, and BIOS seems to set the
    default high-pass filter in some "safer" range, which results in the
    very soft tone from the built-in speakers in contrast to Windows.
    Also, the mute LED control is missing, since 92HD95 codec still has no
    HP-specific fixups for GPIO setups.

    This patch adds these missing features: the HPF is adjusted by the
    vendor-specific verb, and the LED is set up from a DMI string (but
    with the default polarity = 0 assumption due to the incomplete BIOS on
    the given machine).

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74841
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit a283368382c50345dff61525f493ea307f21ec9b upstream.

    We need to call the proper init function in case it has been
    overridden, as it might restore things that the generic routing
    doesn't know anything about. E.g. AMD cards have special verbs
    that need resetting.

    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=77901
    Fixes: 5a61358433b1 ('ALSA: hda - hdmi: Add ATI/AMD multi-channel audio support')
    Signed-off-by: Pierre Ossman
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Pierre Ossman
     
  • commit 92a586bdc06de6629dae1b357dac221253f55ff8 upstream.

    When a USB-audio device is disconnected while PCM is still running, we
    still see some race: the disconnect callback calls
    snd_usb_endpoint_free() that calls release_urbs() and then kfree()
    while a PCM stream would be closed at the same time and calls
    stop_endpoints() that leads to wait_clear_urbs(). That is, the EP
    object might be deallocated while a PCM stream is syncing with
    wait_clear_urbs() with the same EP.

    Basically calling multiple wait_clear_urbs() would work fine, also
    calling wait_clear_urbs() and release_urbs() would work, too, as
    wait_clear_urbs() just reads some fields in ep. The problem is the
    succeeding kfree() in snd_pcm_endpoint_free().

    This patch moves out the EP deallocation into the later point, the
    destructor callback. At this stage, all PCMs must have been already
    closed, so it's safe to free the objects.

    Reported-by: Alan Stern
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 4af4206be2bd1933cae20c2b6fb2058dbc887f7c upstream.

    syscall_regfunc() and syscall_unregfunc() should set/clear
    TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race
    with copy_process() and miss the new child which was not added to
    the process/thread lists yet.

    Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT
    under tasklist.

    Link: http://lkml.kernel.org/p/20140413185854.GB20668@redhat.com

    Fixes: a871bd33a6c0 "tracing: Add syscall tracepoints"
    Acked-by: Frederic Weisbecker
    Acked-by: Paul E. McKenney
    Signed-off-by: Oleg Nesterov
    Signed-off-by: Steven Rostedt
    Signed-off-by: Greg Kroah-Hartman

    Oleg Nesterov
     
  • commit 379cfdac37923653c9d4242d10052378b7563005 upstream.

    In order to prevent the saved cmdline cache from being filled when
    tracing is not active, the comms are only recorded after a trace event
    is recorded.

    The problem is, a comm can fail to be recorded if the trace_cmdline_lock
    is held. That lock is taken via a trylock to allow it to happen from
    any context (including NMI). If the lock fails to be taken, the comm
    is skipped. No big deal, as we will try again later.

    But! Because of the code that was added to only record after an event,
    we may not try again later as the recording is made as a oneshot per
    event per CPU.

    Only disable the recording of the comm if the comm is actually recorded.

    Fixes: 7ffbd48d5cab "tracing: Cache comms only after an event occurred"
    Signed-off-by: Steven Rostedt
    Signed-off-by: Greg Kroah-Hartman

    Steven Rostedt (Red Hat)
     
  • commit 8401aa1f59975c03eeebd3ac6d264cbdfe9af5de upstream.

    Update the SubmittingPatches process to include howto about the new
    'Fixes:' tag to be used when a patch fixes an issue in a previous commit
    (found by git-bisect for example).

    Signed-off-by: Jacob Keller
    Tested-by: Aaron Brown
    Signed-off-by: Jeff Kirsher
    Cc: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Jacob Keller
     
  • commit 4a3a99045177369700c60d074c0e525e8093b0fc upstream.

    Jan points out that I forgot to make the needed fixes to the
    lz4_uncompress_unknownoutputsize() function to mirror the changes done
    in lz4_decompress() with regards to potential pointer overflows.

    The only in-kernel user of this function is the zram code, which only
    takes data from a valid compressed buffer that it made itself, so it's
    not a big issue. But due to external kernel modules using this
    function, it's better to be safe here.

    Reported-by: Jan Beulich
    Cc: "Don A. Bailey"
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • commit b9cd18de4db3c9ffa7e17b0dc0ca99ed5aa4d43a upstream.

    The 'sysret' fastpath does not correctly restore even all regular
    registers, much less any segment registers or reflags values. That is
    very much part of why it's faster than 'iret'.

    Normally that isn't a problem, because the normal ptrace() interface
    catches the process using the signal handler infrastructure, which
    always returns with an iret.

    However, some paths can get caught using ptrace_event() instead of the
    signal path, and for those we need to make sure that we aren't going to
    return to user space using 'sysret'. Otherwise the modifications that
    may have been done to the register set by the tracer wouldn't
    necessarily take effect.

    Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from
    arch_ptrace_stop_needed() which is invoked from ptrace_stop().

    Signed-off-by: Tejun Heo
    Reported-by: Andy Lutomirski
    Acked-by: Oleg Nesterov
    Suggested-by: Linus Torvalds
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Tejun Heo
     
  • commit 8c9eb041cf76038eb3b62ee259607eec9b89f48d upstream.

    kvm_arch_vcpu_free() is called in 2 code paths:

    1) kvm_vm_ioctl()
    kvm_vm_ioctl_create_vcpu()
    kvm_arch_vcpu_destroy()
    kvm_arch_vcpu_free()
    2) kvm_put_kvm()
    kvm_destroy_vm()
    kvm_arch_destroy_vm()
    kvm_mips_free_vcpus()
    kvm_arch_vcpu_free()

    Neither of the paths handles VCPU free. We need to do it in
    kvm_arch_vcpu_free() corresponding to the memory allocation in
    kvm_arch_vcpu_create().

    Signed-off-by: Deng-Cheng Zhu
    Reviewed-by: James Hogan
    Signed-off-by: Paolo Bonzini
    Signed-off-by: Greg Kroah-Hartman

    Deng-Cheng Zhu
     
  • commit c6c0a6637f9da54f9472144d44f71cf847f92e20 upstream.

    The kfree() function already NULL checks the parameter so remove the
    redundant NULL checks before kfree() calls in arch/mips/kvm/.

    Signed-off-by: James Hogan
    Cc: Paolo Bonzini
    Cc: Gleb Natapov
    Cc: kvm@vger.kernel.org
    Cc: Ralf Baechle
    Cc: linux-mips@linux-mips.org
    Cc: Sanjay Lal
    Signed-off-by: Paolo Bonzini
    Signed-off-by: Greg Kroah-Hartman

    James Hogan
     
  • commit fefa8ff810c5ab4c4206aed9d159c4d6fe8d4f1c upstream.

    Commit bd0fa9bb455d introduced a failure path to cpufreq_update_policy() if
    cpufreq_driver->get(cpu) returns NULL. However, it jumps to the 'no_policy'
    label, which exits without unlocking any of the locks the function acquired
    earlier. This causes later calls into cpufreq to hang.

    Fix this by creating a new 'unlock' label and jumping to that instead.

    Fixes: bd0fa9bb455d ("cpufreq: Return error if ->get() failed in cpufreq_update_policy()")
    Link: https://devtalk.nvidia.com/default/topic/751903/kernel-3-15-and-nv-drivers-337-340-failed-to-initialize-the-nvidia-kernel-module-gtx-550-ti-/
    Signed-off-by: Aaron Plattner
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Greg Kroah-Hartman

    Aaron Plattner
     
  • commit 906fe033145aab7d65a428bfda2cf19c75720894 upstream.

    Commit 6712d2931933 (cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost
    error) used the remainder from do_div instead of the quotient. Fix that
    and add one to ensure minimum is met.

    Fixes: 6712d2931933 (cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost error)
    Signed-off-by: Ed Swarthout
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Greg Kroah-Hartman

    Ed Swarthout
     
  • commit 22e7478ddbcb670e33fab72d0bbe7c394c3a2c84 upstream.

    Prior to commit 0e4f6a791b1e (Fix reiserfs_file_release()), reiserfs
    truncates serialized on i_mutex. They mostly still do, with the exception
    of reiserfs_file_release. That blocks out other writers via the tailpack
    mutex and the inode openers counter adjusted in reiserfs_file_open.

    However, NFS will call reiserfs_setattr without having called ->open, so
    we end up with a race when nfs is calling ->setattr while another
    process is releasing the file. Ultimately, it triggers the
    BUG_ON(inode->i_size != new_file_size) check in maybe_indirect_to_direct.

    The solution is to pull the lock into reiserfs_setattr to encompass the
    truncate_setsize call as well.

    Signed-off-by: Jeff Mahoney
    Signed-off-by: Jan Kara
    Signed-off-by: Greg Kroah-Hartman

    Jeff Mahoney
     
  • commit 556b8883cfac3d3203557e161ea8005f8b5479b2 upstream.

    Commit daba542 ("xfs: skip verification on initial "guess"
    superblock read") dropped the use of a verifier for the initial
    superblock read so we can probe the sector size of the filesystem
    stored in the superblock. It, however, now fails to validate that
    what was read initially is actually an XFS superblock and hence will
    fail the sector size check and return ENOSYS.

    This causes probe-based mounts to fail because it expects XFS to
    return EINVAL when it doesn't recognise the superblock format.

    Reported-by: Plamen Petrov
    Tested-by: Plamen Petrov
    Signed-off-by: Dave Chinner
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Dave Chinner
    Signed-off-by: Greg Kroah-Hartman

    Dave Chinner
     
  • commit 6663a4fa6711050036562ddfd2086edf735fae21 upstream.

    Commit 59a53afe70fd530040bdc69581f03d880157f15a "powerpc: Don't setup
    CPUs with bad status" broke ePAPR SMP booting. ePAPR says that CPUs
    that aren't presently running shall have status of disabled, with
    enable-method being used to determine whether the CPU can be enabled.

    Fix by checking for spin-table, which is currently the only supported
    enable-method.

    Signed-off-by: Scott Wood
    Cc: Michael Neuling
    Cc: Emil Medve
    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Scott Wood
     
  • commit dd58a092c4202f2bd490adab7285b3ff77f8e467 upstream.

    The Vector Crypto category instructions are supported by current POWER8
    chips, advertise them to userspace using a specific bit to properly
    differentiate with chips of the same architecture level that might not
    have them.

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Benjamin Herrenschmidt
     
  • commit 59a53afe70fd530040bdc69581f03d880157f15a upstream.

    OPAL will mark a CPU that is guarded as "bad" in the status property of the CPU
    node.

    Unfortunatley Linux doesn't check this property and will put the bad CPU in the
    present map. This has caused hangs on booting when we try to unsplit the core.

    This patch checks the CPU is avaliable via this status property before putting
    it in the present map.

    Signed-off-by: Michael Neuling
    Tested-by: Anton Blanchard
    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Michael Neuling
     
  • commit b69a1da94f3d1589d1942b5d1b384d8cfaac4500 upstream.

    Commit cd64d1697cf0 ("powerpc: mtmsrd not defined") added a check for
    CONFIG_PPC_CPU were a check for CONFIG_PPC_FPU was clearly intended.

    Fixes: cd64d1697cf0 ("powerpc: mtmsrd not defined")
    Signed-off-by: Paul Bolle
    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Paul Bolle
     
  • commit 3df48c981d5a9610e02e9270b1bc4274fb536710 upstream.

    In commit 330a1eb "Core EBB support for 64-bit book3s" I messed up
    clear_task_ebb(). It clears some but not all of the task's Event Based
    Branch (EBB) registers when we duplicate a task struct.

    That allows a child task to observe the EBBHR & EBBRR of its parent,
    which it should not be able to do.

    Fix it by clearing EBBHR & EBBRR.

    Signed-off-by: Michael Ellerman
    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Michael Ellerman
     
  • commit 6e0fdf9af216887e0032c19d276889aad41cad00 upstream.

    Commit b0d278b7d3ae ("powerpc/perf_event: Reduce latency of calling
    perf_event_do_pending") added a check for CONFIG_PMAC were a check for
    CONFIG_PPC_PMAC was clearly intended.

    Fixes: b0d278b7d3ae ("powerpc/perf_event: Reduce latency of calling perf_event_do_pending")
    Signed-off-by: Paul Bolle
    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Paul Bolle
     
  • commit 5d73320a96fcce80286f1447864c481b5f0b96fa upstream.

    commit 8f9c0119d7ba (compat: fs: Generic compat_sys_sendfile
    implementation) changed the PowerPC 64bit sendfile call from
    sys_sendile64 to sys_sendfile.

    Unfortunately this broke sendfile of lengths greater than 2G because
    sys_sendfile caps at MAX_NON_LFS. Restore what we had previously which
    fixes the bug.

    Signed-off-by: Anton Blanchard
    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Anton Blanchard
     
  • commit c4cad90f9e9dcb85afc5e75a02ae3522ed077296 upstream.

    We had a mix & match of flags used when creating legacy ports
    depending on where we found them in the device-tree. Among others
    we were missing UPF_SKIP_TEST for some kind of ISA ports which is
    a problem as quite a few UARTs out there don't support the loopback
    test (such as a lot of BMCs).

    Let's pick the set of flags used by the SoC code and generalize it
    which means autoconf, no loopback test, irq maybe shared and fixed
    port.

    Sending to stable as the lack of UPF_SKIP_TEST is breaking
    serial on some machines so I want this back into distros

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Benjamin Herrenschmidt
     
  • commit 09567e7fd44291bfc08accfdd67ad8f467842332 upstream.

    We have a bug in our hugepage handling which exhibits as an infinite
    loop of hash faults. If the fault is being taken in the kernel it will
    typically trigger the softlockup detector, or the RCU stall detector.

    The bug is as follows:

    1. mmap(0xa0000000, ..., MAP_FIXED | MAP_HUGE_TLB | MAP_ANONYMOUS ..)
    2. Slice code converts the slice psize to 16M.
    3. The code on lines 539-540 of slice.c in slice_get_unmapped_area()
    synchronises the mm->context with the paca->context. So the paca slice
    mask is updated to include the 16M slice.
    3. Either:
    * mmap() fails because there are no huge pages available.
    * mmap() succeeds and the mapping is then munmapped.
    In both cases the slice psize remains at 16M in both the paca & mm.
    4. mmap(0xa0000000, ..., MAP_FIXED | MAP_ANONYMOUS ..)
    5. The slice psize is converted back to 64K. Because of the check on line 539
    of slice.c we DO NOT update the paca->context. The paca slice mask is now
    out of sync with the mm slice mask.
    6. User/kernel accesses 0xa0000000.
    7. The SLB miss handler slb_allocate_realmode() **uses the paca slice mask**
    to create an SLB entry and inserts it in the SLB.
    18. With the 16M SLB entry in place the hardware does a hash lookup, no entry
    is found so a data access exception is generated.
    19. The data access handler calls do_page_fault() -> handle_mm_fault().
    10. __handle_mm_fault() creates a THP mapping with do_huge_pmd_anonymous_page().
    11. The hardware retries the access, there is still nothing in the hash table
    so once again a data access exception is generated.
    12. hash_page() calls into __hash_page_thp() and inserts a mapping in the
    hash. Although the THP mapping maps 16M the hashing is done using 64K
    as the segment page size.
    13. hash_page() returns immediately after calling __hash_page_thp(), skipping
    over the code at line 1125. Resulting in the mismatch between the
    paca->context and mm->context not being detected.
    14. The hardware retries the access, the hash it generates using the 16M
    SLB entry does NOT match the hash we inserted.
    15. We take another data access and go into __hash_page_thp().
    16. We see a valid entry in the hpte_slot_array and so we call updatepp()
    which succeeds.
    17. Goto 14.

    We could fix this in two ways. The first would be to remove or modify
    the check on line 539 of slice.c.

    The second option is to cause the check of paca psize in hash_page() on
    line 1125 to also be done for THP pages.

    We prefer the latter, because the check & update of the paca psize is
    not done until we know it's necessary. It's also done only on the
    current cpu, so we don't need to IPI all other cpus.

    Without further rearranging the code, the simplest fix is to pull out
    the code that checks paca psize and call it in two places. Firstly for
    THP/hugetlb, and secondly for other mappings as before.

    Thanks to Dave Jones for trinity, which originally found this bug.

    Signed-off-by: Michael Ellerman
    Reviewed-by: Aneesh Kumar K.V
    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Michael Ellerman
     
  • commit 1bd098903fda069cb96fe8b5cb4595b46c683385 upstream.

    Everyone can write to these files, which is not what we want.

    Signed-off-by: Anton Blanchard
    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Anton Blanchard
     
  • commit 54f112a3837d4e7532bbedbbbf27c0de277be510 upstream.

    In pseries_eeh_get_state(), EEH_STATE_UNAVAILABLE is always
    overwritten by EEH_STATE_NOT_SUPPORT because of the missed
    "break" there. The patch fixes the issue.

    Reported-by: Joe Perches
    Signed-off-by: Gavin Shan
    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Gavin Shan
     
  • commit 18dd78c427513fb0f89365138be66e6ee8700d1b upstream.

    NFS_INO_INVALID_DATA cannot be ignored, even if we have a delegation.

    We're still having some problems with data corruption when multiple
    clients are appending to a file and those clients are being granted
    write delegations on open.

    To reproduce:

    Client A:
    vi /mnt/`hostname -s`
    while :; do echo "XXXXXXXXXXXXXXX" >>/mnt/file; sleep $(( $RANDOM % 5 )); done

    Client B:
    vi /mnt/`hostname -s`
    while :; do echo "YYYYYYYYYYYYYYY" >>/mnt/file; sleep $(( $RANDOM % 5 )); done

    What's happening is that in nfs_update_inode() we're recognizing that
    the file size has changed and we're setting NFS_INO_INVALID_DATA
    accordingly, but then we ignore the cache_validity flags in
    nfs_write_pageuptodate() because we have a delegation. As a result,
    in nfs_updatepage() we're extending the write to cover the full page
    even though we've not read in the data to begin with.

    Signed-off-by: Scott Mayhew
    Signed-off-by: Trond Myklebust
    Signed-off-by: Greg Kroah-Hartman

    Scott Mayhew
     
  • commit a914722f333b3359d2f4f12919380a334176bb89 upstream.

    Otherwise the kernel oopses when remounting with IPv6 server because
    net is dereferenced in dev_get_by_name.

    Use net ns of current thread so that dev_get_by_name does not operate on
    foreign ns. Changing the address is prohibited anyway so this should not
    affect anything.

    Signed-off-by: Mateusz Guzik
    Cc: linux-nfs@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Trond Myklebust
    Signed-off-by: Greg Kroah-Hartman

    Mateusz Guzik
     
  • commit abbec2da13f0e4c5d9b78b7e2c025a3e617228ba upstream.

    The addition of lockdep code to write_seqcount_begin/end has lead to
    a bunch of false positive claims of ABBA deadlocks with the so_lock
    spinlock. Audits show that this simply cannot happen because the
    read side code does not spin while holding so_lock.

    Signed-off-by: Trond Myklebust
    Signed-off-by: Greg Kroah-Hartman

    Trond Myklebust
     
  • commit 43b6535e717d2f656f71d9bd16022136b781c934 upstream.

    Fix a bug, whereby nfs_update_inode() was declaring the inode to be
    up to date despite not having checked all the attributes.
    The bug occurs because the temporary variable in which we cache
    the validity information is 'sanitised' before reapplying to
    nfsi->cache_validity.

    Reported-by: Kinglong Mee
    Signed-off-by: Trond Myklebust
    Signed-off-by: Greg Kroah-Hartman

    Trond Myklebust
     
  • commit 12337901d654415d9f764b5f5ba50052e9700f37 upstream.

    Note nobody's ever noticed because the typical client probably never
    requests FILES_AVAIL without also requesting something else on the list.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: J. Bruce Fields
    Signed-off-by: Greg Kroah-Hartman

    Christoph Hellwig
     
  • commit 48385408b45523d9a432c66292d47ef43efcbb94 upstream.

    27b11428b7de ("nfsd4: remove lockowner when removing lock stateid")
    introduced a memory leak.

    Reported-by: Jeff Layton
    Signed-off-by: J. Bruce Fields
    Signed-off-by: Greg Kroah-Hartman

    J. Bruce Fields
     
  • commit 6df200f5d5191bdde4d2e408215383890f956781 upstream.

    Return the NULL pointer when the allocation fails.

    Reported-by: Fengguang Wu
    Signed-off-by: Trond Myklebust
    Signed-off-by: Greg Kroah-Hartman

    Trond Myklebust
     
  • commit c789102c20bbbdda6831a273e046715be9d6af79 upstream.

    If the accept() call fails, we need to put the module reference.

    Signed-off-by: Trond Myklebust
    Signed-off-by: J. Bruce Fields
    Signed-off-by: Greg Kroah-Hartman

    Trond Myklebust
     
  • commit 60e1751cb52cc6d1ae04b6bd3c2b96e770b5823f upstream.

    Avoid that closing /dev/infiniband/umad or /dev/infiniband/issm
    triggers a use-after-free. __fput() invokes f_op->release() before it
    invokes cdev_put(). Make sure that the ib_umad_device structure is
    freed by the cdev_put() call instead of f_op->release(). This avoids
    that changing the port mode from IB into Ethernet and back to IB
    followed by restarting opensmd triggers the following kernel oops:

    general protection fault: 0000 [#1] PREEMPT SMP
    RIP: 0010:[] [] module_put+0x2c/0x170
    Call Trace:
    [] cdev_put+0x20/0x30
    [] __fput+0x1ae/0x1f0
    [] ____fput+0xe/0x10
    [] task_work_run+0xac/0xe0
    [] do_notify_resume+0x9f/0xc0
    [] int_signal+0x12/0x17

    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=75051
    Signed-off-by: Bart Van Assche
    Reviewed-by: Yann Droneaud
    Signed-off-by: Roland Dreier
    Signed-off-by: Greg Kroah-Hartman

    Bart Van Assche
     
  • commit 8ec0a0e6b58218bdc1db91dd70ebfcd6ad8dd6cd upstream.

    Avoid leaking a kref count in ib_umad_open() if port->ib_dev == NULL
    or if nonseekable_open() fails.

    Avoid leaking a kref count, that sm_sem is kept down and also that the
    IB_PORT_SM capability mask is not cleared in ib_umad_sm_open() if
    nonseekable_open() fails.

    Since container_of() never returns NULL, remove the code that tests
    whether container_of() returns NULL.

    Moving the kref_get() call from the start of ib_umad_*open() to the
    end is safe since it is the responsibility of the caller of these
    functions to ensure that the cdev pointer remains valid until at least
    when these functions return.

    Signed-off-by: Bart Van Assche

    [ydroneaud@opteya.com: rework a bit to reduce the amount of code changed]

    Signed-off-by: Yann Droneaud

    [ nonseekable_open() can't actually fail, but.... - Roland ]

    Signed-off-by: Roland Dreier
    Signed-off-by: Greg Kroah-Hartman

    Bart Van Assche
     
  • commit 024ca90151f5e4296d30f72c13ff9a075e23c9ec upstream.

    Avoid that the loops that iterate over the request ring can encounter
    a pointer to a SCSI command in req->scmnd that is no longer associated
    with that request. If the function srp_unmap_data() is invoked twice
    for a SCSI command that is not in flight then that would cause
    ib_fmr_pool_unmap() to be invoked with an invalid pointer as argument,
    resulting in a kernel oops.

    Reported-by: Sagi Grimberg
    Reference: http://thread.gmane.org/gmane.linux.drivers.rdma/19068/focus=19069
    Signed-off-by: Bart Van Assche
    Reviewed-by: Sagi Grimberg
    Signed-off-by: Roland Dreier
    Signed-off-by: Greg Kroah-Hartman

    Bart Van Assche
     
  • commit 7e6d3e5c70f13874fb06e6b67696ed90ce79bd48 upstream.

    This patch addresses an issue where the legacy diagpacket is sent in
    from the user, but the driver operates on only the extended
    diagpkt. This patch specifically initializes the extended diagpkt
    based on the legacy packet.

    Reported-by: Rickard Strandqvist
    Reviewed-by: Mike Marciniszyn
    Signed-off-by: Dennis Dalessandro
    Signed-off-by: Roland Dreier
    Signed-off-by: Greg Kroah-Hartman

    Dennis Dalessandro
     
  • commit 911eccd284d13d78c92ec4f1f1092c03457d732a upstream.

    The code used a literal 1 in dispatching an IB_EVENT_PKEY_CHANGE.

    As of the dual port qib QDR card, this is not necessarily correct.

    Change to use the port as specified in the call.

    Reported-by: Alex Estrin
    Reviewed-by: Dennis Dalessandro
    Signed-off-by: Mike Marciniszyn
    Signed-off-by: Roland Dreier
    Signed-off-by: Greg Kroah-Hartman

    Mike Marciniszyn