1. 09 Jun, 2015 37 commits
  2. 23 May, 2015 3 commits
    • Rabin Vincent's avatar
      Revert "dm crypt: fix deadlock when async crypto algorithm returns -EBUSY" · 90cdd181
      Rabin Vincent authored
      [ Upstream commit c0403ec0 ]
      
      This reverts Linux 4.1-rc1 commit 0618764c.
      
      The problem which that commit attempts to fix actually lies in the
      Freescale CAAM crypto driver not dm-crypt.
      
      dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG.  This means the the crypto
      driver should internally backlog requests which arrive when the queue is
      full and process them later.  Until the crypto hw's queue becomes full,
      the driver returns -EINPROGRESS.  When the crypto hw's queue if full,
      the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is
      expected to backlog the request and process it when the hardware has
      queue space.  At the point when the driver takes the request from the
      backlog and starts processing it, it calls the completion function with
      a status of -EINPROGRESS.  The completion function is called (for a
      second time, in the case of backlogged requests) with a status/err of 0
      when a request is done.
      
      Crypto drivers for hardware without hardware queueing use the helpers,
      crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request()
      and crypto_get_backlog() helpers to implement this behaviour correctly,
      while others implement this behaviour without these helpers (ccp, for
      example).
      
      dm-crypt (before the patch that needs reverting) uses this API
      correctly.  It queues up as many requests as the hw queues will allow
      (i.e. as long as it gets back -EINPROGRESS from the request function).
      Then, when it sees at least one backlogged request (gets -EBUSY), it
      waits till that backlogged request is handled (completion gets called
      with -EINPROGRESS), and then continues.  The references to
      af_alg_wait_for_completion() and af_alg_complete() in that commit's
      commit message are irrelevant because those functions only handle one
      request at a time, unlink dm-crypt.
      
      The problem is that the Freescale CAAM driver, which that commit
      describes as having being tested with, fails to implement the
      backlogging behaviour correctly.  In cam_jr_enqueue(), if the hardware
      queue is full, it simply returns -EBUSY without backlogging the request.
      What the observed deadlock was is not described in the commit message
      but it is obviously the wait_for_completion() in crypto_convert() where
      dm-crypto would wait for the completion being called with -EINPROGRESS
      in the case of backlogged requests.  This completion will never be
      completed due to the bug in the CAAM driver.
      
      Commit 0618764c incorrectly made dm-crypt wait for every request,
      even when the driver/hardware queues are not full, which means that
      dm-crypt will never see -EBUSY.  This means that that commit will cause
      a performance regression on all crypto drivers which implement the API
      correctly.
      
      Revert it.  Correct backlog handling should be implemented in the CAAM
      driver instead.
      
      Cc'ing stable purely because commit 0618764c did.  If for some reason
      a stable@ kernel did pick up commit 0618764c it should get reverted.
      Signed-off-by: default avatarRabin Vincent <rabin.vincent@axis.com>
      Reviewed-by: default avatarHoria Geanta <horia.geanta@freescale.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      90cdd181
    • Ben Hutchings's avatar
      xen-pciback: Add name prefix to global 'permissive' variable · 8d102e1d
      Ben Hutchings authored
      [ Upstream commit 8014bcc8 ]
      
      The variable for the 'permissive' module parameter used to be static
      but was recently changed to be extern.  This puts it in the kernel
      global namespace if the driver is built-in, so its name should begin
      with a prefix identifying the driver.
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Fixes: af6fc858 ("xen-pciback: limit guest control of command register")
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      8d102e1d
    • Boris Ostrovsky's avatar
      xen/events: Set irq_info->evtchn before binding the channel to CPU in __startup_pirq() · 3b2ec381
      Boris Ostrovsky authored
      [ Upstream commit 16e6bd59 ]
      
      .. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
      'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Tested-by: default avatarAnnie Li <annie.li@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      3b2ec381