Skip to content

L
linux
Switch branch/tag
  1. 09 Jun, 2015 32 commits
  3. 23 May, 2015 8 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
    • Boris Ostrovsky's avatar
      xen/console: Update console event channel on resume · 0120beac
      Boris Ostrovsky authored 
      [ Upstream commit b9d934f2 ]

After a resume the hypervisor/tools may change console event
channel number. We should re-query it.
Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@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>
      0120beac
    • Boris Ostrovsky's avatar
      xen/xenbus: Update xenbus event channel on resume · df39fed6
      Boris Ostrovsky authored 
      [ Upstream commit 16f1cf3b ]

After a resume the hypervisor/tools may change xenbus event
channel number. We should re-query it.
Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@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>
      df39fed6
    • Boris Ostrovsky's avatar
      xen/events: Clear cpu_evtchn_mask before resuming · 5ea5c920
      Boris Ostrovsky authored 
      [ Upstream commit 5cec9883 ]

When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt to be claimed by wrong VCPU since
cpu_evtchn_mask bits may be stale. This can happen even though
evtchn_2l_bind_to_cpu() attempts to clear old bits: irq_info that
is passed in is not necessarily the original one (from pre-migration
times) but instead is freshly allocated during resume and so any
information about which CPU the channel was bound to is lost.

Thus we should clear the mask during resume.

We also need to make sure that bits for xenstore and console channels
are set when these two subsystems are resumed. While rebind_evtchn_irq()
(which is invoked for both of them on a resume) calls irq_set_affinity(),
the latter will in fact postpone setting affinity until handling the
interrupt. But because cpu_evtchn_mask will have bits for these two
cleared we won't be able to take the interrupt.

With that in mind, we need to bind those two channels explicitly in
rebind_evtchn_irq(). We will keep irq_set_affinity() so that we have a
pass through generic irq affinity code later, in case something needs
to be updated there as well.

(Also replace cpumask_of(0) with cpumask_of(info->cpu) in
rebind_evtchn_irq(): it should be set to zero in preceding
xen_irq_info_evtchn_setup().)
Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
Reported-by: default avatarAnnie Li <annie.li@oracle.com>
Cc: <stable@vger.kernel.org> # 3.14+
Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      5ea5c920
    • Naoya Horiguchi's avatar
      mm: soft-offline: fix num_poisoned_pages counting on concurrent events · 881241e8
      Naoya Horiguchi authored 
      [ Upstream commit 602498f9 ]

If multiple soft offline events hit one free page/hugepage concurrently,
soft_offline_page() can handle the free page/hugepage multiple times,
which makes num_poisoned_pages counter increased more than once.  This
patch fixes this wrong counting by checking TestSetPageHWPoison for normal
papes and by checking the return value of dequeue_hwpoisoned_huge_page()
for hugepages.
Signed-off-by: default avatarNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Acked-by: default avatarDean Nelson <dnelson@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: <stable@vger.kernel.org>	[3.14+]
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      881241e8
    • Tejun Heo's avatar
      writeback: use |1 instead of +1 to protect against div by zero · 4e258a15
      Tejun Heo authored 
      [ Upstream commit 464d1387 ]

mm/page-writeback.c has several places where 1 is added to the divisor
to prevent division by zero exceptions; however, if the original
divisor is equivalent to -1, adding 1 leads to division by zero.

There are three places where +1 is used for this purpose - one in
pos_ratio_polynom() and two in bdi_position_ratio().  The second one
in bdi_position_ratio() actually triggered div-by-zero oops on a
machine running a 3.10 kernel.  The divisor is

  x_intercept - bdi_setpoint + 1 == span + 1

span is confirmed to be (u32)-1.  It isn't clear how it ended up that
but it could be from write bandwidth calculation underflow fixed by
c72efb65 ("writeback: fix possible underflow in write bandwidth
calculation").

At any rate, +1 isn't a proper protection against div-by-zero.  This
patch converts all +1 protections to |1.  Note that
bdi_update_dirty_ratelimit() was already using |1 before this patch.
Signed-off-by: default avatarTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
Reviewed-by: default avatarJan Kara <jack@suse.cz>
Signed-off-by: default avatarJens Axboe <axboe@fb.com>
Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4e258a15
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7