1. 26 Mar, 2017 24 commits
    • Anton Blanchard's avatar
      scsi: lpfc: Add shutdown method for kexec · 82bd06ab
      Anton Blanchard authored
      commit 85e8a239 upstream.
      
      We see lpfc devices regularly fail during kexec. Fix this by adding a
      shutdown method which mirrors the remove method.
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Reviewed-by: default avatarMauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
      Tested-by: default avatarMauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      82bd06ab
    • Nicholas Bellinger's avatar
      target/pscsi: Fix TYPE_TAPE + TYPE_MEDIMUM_CHANGER export · 0a621633
      Nicholas Bellinger authored
      commit a04e54f2 upstream.
      
      The following fixes a divide by zero OOPs with TYPE_TAPE
      due to pscsi_tape_read_blocksize() failing causing a zero
      sd->sector_size being propigated up via dev_attrib.hw_block_size.
      
      It also fixes another long-standing bug where TYPE_TAPE and
      TYPE_MEDIMUM_CHANGER where using pscsi_create_type_other(),
      which does not call scsi_device_get() to take the device
      reference.  Instead, rename pscsi_create_type_rom() to
      pscsi_create_type_nondisk() and use it for all cases.
      
      Finally, also drop a dump_stack() in pscsi_get_blocks() for
      non TYPE_DISK, which in modern target-core can get invoked
      via target_sense_desc_format() during CHECK_CONDITION.
      Reported-by: default avatarMalcolm Haak <insanemal@gmail.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a621633
    • Shaohua Li's avatar
      md/raid1/10: fix potential deadlock · 582f5489
      Shaohua Li authored
      commit 61eb2b43 upstream.
      
      Neil Brown pointed out a potential deadlock in raid 10 code with
      bio_split/chain. The raid1 code could have the same issue, but recent
      barrier rework makes it less likely to happen. The deadlock happens in
      below sequence:
      
      1. generic_make_request(bio), this will set current->bio_list
      2. raid10_make_request will split bio to bio1 and bio2
      3. __make_request(bio1), wait_barrer, add underlayer disk bio to
      current->bio_list
      4. __make_request(bio2), wait_barrer
      
      If raise_barrier happens between 3 & 4, since wait_barrier runs at 3,
      raise_barrier waits for IO completion from 3. And since raise_barrier
      sets barrier, 4 waits for raise_barrier. But IO from 3 can't be
      dispatched because raid10_make_request() doesn't finished yet.
      
      The solution is to adjust the IO ordering. Quotes from Neil:
      "
      It is much safer to:
      
          if (need to split) {
              split = bio_split(bio, ...)
              bio_chain(...)
              make_request_fn(split);
              generic_make_request(bio);
         } else
              make_request_fn(mddev, bio);
      
      This way we first process the initial section of the bio (in 'split')
      which will queue some requests to the underlying devices.  These
      requests will be queued in generic_make_request.
      Then we queue the remainder of the bio, which will be added to the end
      of the generic_make_request queue.
      Then we return.
      generic_make_request() will pop the lower-level device requests off the
      queue and handle them first.  Then it will process the remainder
      of the original bio once the first section has been fully processed.
      "
      
      Note, this only happens in read path. In write path, the bio is flushed to
      underlaying disks either by blk flush (from schedule) or offladed to raid1/10d.
      It's queued in current->bio_list.
      
      Cc: Coly Li <colyli@suse.de>
      Suggested-by: default avatarNeilBrown <neilb@suse.com>
      Reviewed-by: default avatarJack Wang <jinpu.wang@profitbricks.com>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      582f5489
    • Michael Ellerman's avatar
      powerpc/boot: Fix zImage TOC alignment · b2447397
      Michael Ellerman authored
      commit 97ee351b upstream.
      
      Recent toolchains force the TOC to be 256 byte aligned. We need to
      enforce this alignment in the zImage linker script, otherwise pointers
      to our TOC variables (__toc_start) could be incorrect. If the actual
      start of the TOC and __toc_start don't have the same value we crash
      early in the zImage wrapper.
      Suggested-by: default avatarAlan Modra <amodra@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2447397
    • Rafael J. Wysocki's avatar
      cpufreq: Fix and clean up show_cpuinfo_cur_freq() · 09875d13
      Rafael J. Wysocki authored
      commit 9b4f603e upstream.
      
      There is a missing newline in show_cpuinfo_cur_freq(), so add it,
      but while at it clean that function up somewhat too.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09875d13
    • Peter Zijlstra's avatar
      perf/core: Fix event inheritance on fork() · f02729f2
      Peter Zijlstra authored
      commit e7cc4865 upstream.
      
      While hunting for clues to a use-after-free, Oleg spotted that
      perf_event_init_context() can loose an error value with the result
      that fork() can succeed even though we did not fully inherit the perf
      event context.
      Spotted-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: oleg@redhat.com
      Fixes: 889ff015 ("perf/core: Split context's event group list into pinned and non-pinned lists")
      Link: http://lkml.kernel.org/r/20170316125823.190342547@infradead.orgSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f02729f2
    • Linus Torvalds's avatar
      give up on gcc ilog2() constant optimizations · 4cb0c0b7
      Linus Torvalds authored
      commit 474c9015 upstream.
      
      gcc-7 has an "optimization" pass that completely screws up, and
      generates the code expansion for the (impossible) case of calling
      ilog2() with a zero constant, even when the code gcc compiles does not
      actually have a zero constant.
      
      And we try to generate a compile-time error for anybody doing ilog2() on
      a constant where that doesn't make sense (be it zero or negative).  So
      now gcc7 will fail the build due to our sanity checking, because it
      created that constant-zero case that didn't actually exist in the source
      code.
      
      There's a whole long discussion on the kernel mailing about how to work
      around this gcc bug.  The gcc people themselevs have discussed their
      "feature" in
      
         https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72785
      
      but it's all water under the bridge, because while it looked at one
      point like it would be solved by the time gcc7 was released, that was
      not to be.
      
      So now we have to deal with this compiler braindamage.
      
      And the only simple approach seems to be to just delete the code that
      tries to warn about bad uses of ilog2().
      
      So now "ilog2()" will just return 0 not just for the value 1, but for
      any non-positive value too.
      
      It's not like I can recall anybody having ever actually tried to use
      this function on any invalid value, but maybe the sanity check just
      meant that such code never made it out in public.
      Reported-by: default avatarLaura Abbott <labbott@redhat.com>
      Cc: John Stultz <john.stultz@linaro.org>,
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4cb0c0b7
    • Andi Kleen's avatar
      kernek/fork.c: allocate idle task for a CPU always on its local node · 6052eb87
      Andi Kleen authored
      commit 725fc629 upstream.
      
      Linux preallocates the task structs of the idle tasks for all possible
      CPUs.  This currently means they all end up on node 0.  This also
      implies that the cache line of MWAIT, which is around the flags field in
      the task struct, are all located in node 0.
      
      We see a noticeable performance improvement on Knights Landing CPUs when
      the cache lines used for MWAIT are located in the local nodes of the
      CPUs using them.  I would expect this to give a (likely slight)
      improvement on other systems too.
      
      The patch implements placing the idle task in the node of its CPUs, by
      passing the right target node to copy_process()
      
      [akpm@linux-foundation.org: use NUMA_NO_NODE, not a bare -1]
      Link: http://lkml.kernel.org/r/1463492694-15833-1-git-send-email-andi@firstfloor.orgSigned-off-by: default avatarAndi Kleen <ak@linux.intel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6052eb87
    • Vitaly Kuznetsov's avatar
      hv_netvsc: use skb_get_hash() instead of a homegrown implementation · 6cc5b73d
      Vitaly Kuznetsov authored
      commit 757647e1 upstream.
      
      Recent changes to 'struct flow_keys' (e.g commit d34af823 ("net: Add
      VLAN ID to flow_keys")) introduced a performance regression in netvsc
      driver. Is problem is, however, not the above mentioned commit but the
      fact that netvsc_set_hash() function did some assumptions on the struct
      flow_keys data layout and this is wrong.
      
      Get rid of netvsc_set_hash() by switching to skb_get_hash(). This change
      will also imply switching to Jenkins hash from the currently used Toeplitz
      but it seems there is no good excuse for Toeplitz to stay.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6cc5b73d
    • Jason Gunthorpe's avatar
      tpm_tis: Use devm_free_irq not free_irq · cea05015
      Jason Gunthorpe authored
      commit 727f28b8 upstream.
      
      The interrupt is always allocated with devm_request_irq so it
      must always be freed with devm_free_irq.
      
      Fixes: 448e9c55 ("tpm_tis: verify interrupt during init")
      Signed-off-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Acked-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Tested-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Tested-by: default avatarMartin Wilck <Martin.Wilck@ts.fujitsu.com>
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Acked-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cea05015
    • Dave Airlie's avatar
      drm/amdgpu: add missing irq.h include · 13a26889
      Dave Airlie authored
      commit e9c5e740 upstream.
      
      this fixes the build on arm.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13a26889
    • Sebastian Ott's avatar
      s390/pci: fix use after free in dma_init · 68ea3948
      Sebastian Ott authored
      commit dba59909 upstream.
      
      After a failure during registration of the dma_table (because of the
      function being in error state) we free its memory but don't reset the
      associated pointer to zero.
      
      When we then receive a notification from firmware (about the function
      being in error state) we'll try to walk and free the dma_table again.
      
      Fix this by resetting the dma_table pointer. In addition to that make
      sure that we free the iommu_bitmap when appropriate.
      Signed-off-by: default avatarSebastian Ott <sebott@linux.vnet.ibm.com>
      Reviewed-by: default avatarGerald Schaefer <gerald.schaefer@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      68ea3948
    • Thomas Huth's avatar
      KVM: PPC: Book3S PR: Fix illegal opcode emulation · 50730d7f
      Thomas Huth authored
      commit 708e75a3 upstream.
      
      If kvmppc_handle_exit_pr() calls kvmppc_emulate_instruction() to emulate
      one instruction (in the BOOK3S_INTERRUPT_H_EMUL_ASSIST case), it calls
      kvmppc_core_queue_program() afterwards if kvmppc_emulate_instruction()
      returned EMULATE_FAIL, so the guest gets an program interrupt for the
      illegal opcode.
      However, the kvmppc_emulate_instruction() also tried to inject a
      program exception for this already, so the program interrupt gets
      injected twice and the return address in srr0 gets destroyed.
      All other callers of kvmppc_emulate_instruction() are also injecting
      a program interrupt, and since the callers have the right knowledge
      about the srr1 flags that should be used, it is the function
      kvmppc_emulate_instruction() that should _not_ inject program
      interrupts, so remove the kvmppc_core_queue_program() here.
      
      This fixes the issue discovered by Laurent Vivier with kvm-unit-tests
      where the logs are filled with these messages when the test tries
      to execute an illegal instruction:
      
           Couldn't emulate instruction 0x00000000 (op 0 xop 0)
           kvmppc_handle_exit_pr: emulation at 700 failed (00000000)
      Signed-off-by: default avatarThomas Huth <thuth@redhat.com>
      Reviewed-by: default avatarAlexander Graf <agraf@suse.de>
      Tested-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: default avatarPaul Mackerras <paulus@ozlabs.org>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50730d7f
    • Ross Lagerwall's avatar
      xen/qspinlock: Don't kick CPU if IRQ is not initialized · e2d95778
      Ross Lagerwall authored
      commit 707e59ba upstream.
      
      The following commit:
      
        1fb3a8b2 ("xen/spinlock: Fix locking path engaging too soon under PVHVM.")
      
      ... moved the initalization of the kicker interrupt until after
      native_cpu_up() is called.
      
      However, when using qspinlocks, a CPU may try to kick another CPU that is
      spinning (because it has not yet initialized its kicker interrupt), resulting
      in the following crash during boot:
      
        kernel BUG at /build/linux-Ay7j_C/linux-4.4.0/drivers/xen/events/events_base.c:1210!
        invalid opcode: 0000 [#1] SMP
        ...
        RIP: 0010:[<ffffffff814c97c9>]  [<ffffffff814c97c9>] xen_send_IPI_one+0x59/0x60
        ...
        Call Trace:
         [<ffffffff8102be9e>] xen_qlock_kick+0xe/0x10
         [<ffffffff810cabc2>] __pv_queued_spin_unlock+0xb2/0xf0
         [<ffffffff810ca6d1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20
         [<ffffffff81052936>] ? check_tsc_warp+0x76/0x150
         [<ffffffff81052aa6>] check_tsc_sync_source+0x96/0x160
         [<ffffffff81051e28>] native_cpu_up+0x3d8/0x9f0
         [<ffffffff8102b315>] xen_hvm_cpu_up+0x35/0x80
         [<ffffffff8108198c>] _cpu_up+0x13c/0x180
         [<ffffffff81081a4a>] cpu_up+0x7a/0xa0
         [<ffffffff81f80dfc>] smp_init+0x7f/0x81
         [<ffffffff81f5a121>] kernel_init_freeable+0xef/0x212
         [<ffffffff81817f30>] ? rest_init+0x80/0x80
         [<ffffffff81817f3e>] kernel_init+0xe/0xe0
         [<ffffffff8182488f>] ret_from_fork+0x3f/0x70
         [<ffffffff81817f30>] ? rest_init+0x80/0x80
      
      To fix this, only send the kick if the target CPU's interrupt has been
      initialized. This check isn't racy, because the target is waiting for
      the spinlock, so it won't have initialized the interrupt in the
      meantime.
      Signed-off-by: default avatarRoss Lagerwall <ross.lagerwall@citrix.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Cc: xen-devel@lists.xenproject.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e2d95778
    • Vitaly Kuznetsov's avatar
      Drivers: hv: avoid vfree() on crash · b1a0f744
      Vitaly Kuznetsov authored
      commit a9f61ca7 upstream.
      
      When we crash from NMI context (e.g. after NMI injection from host when
      'sysctl -w kernel.unknown_nmi_panic=1' is set) we hit
      
          kernel BUG at mm/vmalloc.c:1530!
      
      as vfree() is denied. While the issue could be solved with in_nmi() check
      instead I opted for skipping vfree on all sorts of crashes to reduce the
      amount of work which can cause consequent crashes. We don't really need to
      free anything on crash.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b1a0f744
    • Vitaly Kuznetsov's avatar
      Drivers: hv: balloon: don't crash when memory is added in non-sorted order · 0a251276
      Vitaly Kuznetsov authored
      commit 77c0c973 upstream.
      
      When we iterate through all HA regions in handle_pg_range() we have an
      assumption that all these regions are sorted in the list and the
      'start_pfn >= has->end_pfn' check is enough to find the proper region.
      Unfortunately it's not the case with WS2016 where host can hot-add regions
      in a different order. We end up modifying the wrong HA region and crashing
      later on pages online. Modify the check to make sure we found the region
      we were searching for while iterating. Fix the same check in pfn_covered()
      as well.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0a251276
    • Mika Westerberg's avatar
      pinctrl: cherryview: Do not mask all interrupts in probe · 3787a071
      Mika Westerberg authored
      commit bcb48cca upstream.
      
      The Cherryview GPIO controller has 8 or 16 wires connected to the I/O-APIC
      which can be used directly by the platform/BIOS or drivers. One such wire
      is used as SCI (System Control Interrupt) which ACPI depends on to be able
      to trigger GPEs (General Purpose Events).
      
      The pinctrl driver itself uses another IRQ resource which is wire OR of all
      the 8 (or 16) wires and follows what BIOS has programmed to the IntSel
      register of each pin.
      
      Currently the driver masks all interrupts at probe time and this prevents
      these direct interrupts from working as expected. The reason for this is
      that some early stage prototypes had some pins misconfigured causing lots
      of spurious interrupts.
      
      We fix this by leaving the interrupt mask untouched. This allows SCI and
      other direct interrupts work properly. What comes to the possible spurious
      interrupts we switch the default handler to be handle_bad_irq() instead of
      handle_simple_irq() (which was not correct anyway).
      Reported-by: default avatarYu C Chen <yu.c.chen@intel.com>
      Reported-by: default avatarAnisse Astier <anisse@astier.eu>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3787a071
    • Alex Hung's avatar
      ACPI / video: skip evaluating _DOD when it does not exist · 962c66c7
      Alex Hung authored
      commit e34fbbac upstream.
      
      Some system supports hybrid graphics and its discrete VGA
      does not have any connectors and therefore has no _DOD method.
      Signed-off-by: default avatarAlex Hung <alex.hung@canonical.com>
      Reviewed-by: default avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      962c66c7
    • Manoj N. Kumar's avatar
      cxlflash: Increase cmd_per_lun for better throughput · 12e1a3cd
      Manoj N. Kumar authored
      commit 83430833 upstream.
      
      With the current value of cmd_per_lun at 16, the throughput
      over a single adapter is limited to around 150kIOPS.
      
      Increase the value of cmd_per_lun to 256 to improve
      throughput. With this change a single adapter is able to
      attain close to the maximum throughput (380kIOPS).
      Also change the number of RRQ entries that can be queued.
      Signed-off-by: default avatarManoj N. Kumar <manoj@linux.vnet.ibm.com>
      Acked-by: default avatarMatthew R. Ochs <mrochs@linux.vnet.ibm.com>
      Reviewed-by: default avatarUma Krishnan <ukrishn@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12e1a3cd
    • Wang, Rui Y's avatar
      crypto: mcryptd - Fix load failure · f8c07cbc
      Wang, Rui Y authored
      commit ddef4824 upstream.
      
      mcryptd_create_hash() fails by returning -EINVAL, causing any
      driver using mcryptd to fail to load. It is because it needs
      to set its statesize properly.
      Signed-off-by: default avatarRui Wang <rui.y.wang@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8c07cbc
    • Wang, Rui Y's avatar
      crypto: cryptd - Assign statesize properly · 10659b8f
      Wang, Rui Y authored
      commit 1a078340 upstream.
      
      cryptd_create_hash() fails by returning -EINVAL.  It is because after
      8996eafd ("crypto: ahash - ensure statesize is non-zero") all ahash
      drivers must have a non-zero statesize.
      
      This patch fixes the problem by properly assigning the statesize.
      Signed-off-by: default avatarRui Wang <rui.y.wang@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      10659b8f
    • Wang, Rui Y's avatar
      crypto: ghash-clmulni - Fix load failure · c78c3376
      Wang, Rui Y authored
      commit 3a020a72 upstream.
      
      ghash_clmulni_intel fails to load on Linux 4.3+ with the following message:
      "modprobe: ERROR: could not insert 'ghash_clmulni_intel': Invalid argument"
      
      After 8996eafd ("crypto: ahash - ensure statesize is non-zero") all ahash
      drivers are required to implement import()/export(), and must have a non-
      zero statesize.
      
      This patch has been tested with the algif_hash interface. The calculated
      digest values, after several rounds of import()s and export()s, match those
      calculated by tcrypt.
      Signed-off-by: default avatarRui Wang <rui.y.wang@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      c78c3376
    • Alan Stern's avatar
      USB: don't free bandwidth_mutex too early · 45d95588
      Alan Stern authored
      commit ab2a4bf8 upstream.
      
      The USB core contains a bug that can show up when a USB-3 host
      controller is removed.  If the primary (USB-2) hcd structure is
      released before the shared (USB-3) hcd, the core will try to do a
      double-free of the common bandwidth_mutex.
      
      The problem was described in graphical form by Chung-Geol Kim, who
      first reported it:
      
      =================================================
           At *remove USB(3.0) Storage
           sequence <1> --> <5> ((Problem Case))
      =================================================
                                        VOLD
      ------------------------------------|------------
                                       (uevent)
                                  ________|_________
                                 |<1>               |
                                 |dwc3_otg_sm_work  |
                                 |usb_put_hcd       |
                                 |peer_hcd(kref=2)|
                                 |__________________|
                                  ________|_________
                                 |<2>               |
                                 |New USB BUS #2    |
                                 |                  |
                                 |peer_hcd(kref=1)  |
                                 |                  |
                               --(Link)-bandXX_mutex|
                               | |__________________|
                               |
          ___________________  |
         |<3>                | |
         |dwc3_otg_sm_work   | |
         |usb_put_hcd        | |
         |primary_hcd(kref=1)| |
         |___________________| |
          _________|_________  |
         |<4>                | |
         |New USB BUS #1     | |
         |hcd_release        | |
         |primary_hcd(kref=0)| |
         |                   | |
         |bandXX_mutex(free) |<-
         |___________________|
                                     (( VOLD ))
                                  ______|___________
                                 |<5>               |
                                 |      SCSI        |
                                 |usb_put_hcd       |
                                 |peer_hcd(kref=0)  |
                                 |*hcd_release      |
                                 |bandXX_mutex(free*)|<- double free
                                 |__________________|
      
      =================================================
      
      This happens because hcd_release() frees the bandwidth_mutex whenever
      it sees a primary hcd being released (which is not a very good idea
      in any case), but in the course of releasing the primary hcd, it
      changes the pointers in the shared hcd in such a way that the shared
      hcd will appear to be primary when it gets released.
      
      This patch fixes the problem by changing hcd_release() so that it
      deallocates the bandwidth_mutex only when the _last_ hcd structure
      referencing it is released.  The patch also removes an unnecessary
      test, so that when an hcd is released, both the shared_hcd and
      primary_hcd pointers in the hcd's peer will be cleared.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarChung-Geol Kim <chunggeol.kim@samsung.com>
      Tested-by: default avatarChung-Geol Kim <chunggeol.kim@samsung.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      45d95588
    • Chris Bainbridge's avatar
      usb: core: hub: hub_port_init lock controller instead of bus · ac1a97d8
      Chris Bainbridge authored
      commit feb26ac3 upstream.
      
      The XHCI controller presents two USB buses to the system - one for USB2
      and one for USB3. The hub init code (hub_port_init) is reentrant but
      only locks one bus per thread, leading to a race condition failure when
      two threads attempt to simultaneously initialise a USB2 and USB3 device:
      
      [    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
      [   13.183701] usb 3-3: device descriptor read/all, error -110
      
      On a test system this failure occurred on 6% of all boots.
      
      The call traces at the point of failure are:
      
      Call Trace:
       [<ffffffff81b9bab7>] schedule+0x37/0x90
       [<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0
       [<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30
       [<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150
       [<ffffffff817db10c>] usb_control_msg+0xbc/0xf0
       [<ffffffff817d07de>] hub_port_init+0x51e/0xb70
       [<ffffffff817d4697>] hub_event+0x817/0x1570
       [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
       [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
       [<ffffffff810f4684>] worker_thread+0x64/0x4b0
       [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
       [<ffffffff810fa7f5>] kthread+0x105/0x120
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
       [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
      
      Call Trace:
       [<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40
       [<ffffffff817fd87e>] xhci_address_device+0xe/0x10
       [<ffffffff817d047f>] hub_port_init+0x1bf/0xb70
       [<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff817d4697>] hub_event+0x817/0x1570
       [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
       [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
       [<ffffffff810f4684>] worker_thread+0x64/0x4b0
       [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
       [<ffffffff810fa7f5>] kthread+0x105/0x120
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
       [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
       [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
      
      Which results from the two call chains:
      
      hub_port_init
       usb_get_device_descriptor
        usb_get_descriptor
         usb_control_msg
          usb_internal_control_msg
           usb_start_wait_urb
            usb_submit_urb / wait_for_completion_timeout / usb_kill_urb
      
      hub_port_init
       hub_set_address
        xhci_address_device
         xhci_setup_device
      
      Mathias Nyman explains the current behaviour violates the XHCI spec:
      
       hub_port_reset() will end up moving the corresponding xhci device slot
       to default state.
      
       As hub_port_reset() is called several times in hub_port_init() it
       sounds reasonable that we could end up with two threads having their
       xhci device slots in default state at the same time, which according to
       xhci 4.5.3 specs still is a big no no:
      
       "Note: Software shall not transition more than one Device Slot to the
        Default State at a time"
      
       So both threads fail at their next task after this.
       One fails to read the descriptor, and the other fails addressing the
       device.
      
      Fix this in hub_port_init by locking the USB controller (instead of an
      individual bus) to prevent simultaneous initialisation of both buses.
      
      Fixes: 638139eb ("usb: hub: allow to process more usb hub events in parallel")
      Link: https://lkml.org/lkml/2016/2/8/312
      Link: https://lkml.org/lkml/2016/2/4/748Signed-off-by: default avatarChris Bainbridge <chris.bainbridge@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
       [sumits: minor merge conflict resolution for linux-4.4.y]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ac1a97d8
  2. 22 Mar, 2017 16 commits