1. 12 Dec, 2016 11 commits
    • Ilya Dryomov's avatar
      libceph: stop allocating a new cipher on every crypto request · 7af3ea18
      Ilya Dryomov authored
      This is useless and more importantly not allowed on the writeback path,
      because crypto_alloc_skcipher() allocates memory with GFP_KERNEL, which
      can recurse back into the filesystem:
      
          kworker/9:3     D ffff92303f318180     0 20732      2 0x00000080
          Workqueue: ceph-msgr ceph_con_workfn [libceph]
           ffff923035dd4480 ffff923038f8a0c0 0000000000000001 000000009eb27318
           ffff92269eb28000 ffff92269eb27338 ffff923036b145ac ffff923035dd4480
           00000000ffffffff ffff923036b145b0 ffffffff951eb4e1 ffff923036b145a8
          Call Trace:
           [<ffffffff951eb4e1>] ? schedule+0x31/0x80
           [<ffffffff951eb77a>] ? schedule_preempt_disabled+0xa/0x10
           [<ffffffff951ed1f4>] ? __mutex_lock_slowpath+0xb4/0x130
           [<ffffffff951ed28b>] ? mutex_lock+0x1b/0x30
           [<ffffffffc0a974b3>] ? xfs_reclaim_inodes_ag+0x233/0x2d0 [xfs]
           [<ffffffff94d92ba5>] ? move_active_pages_to_lru+0x125/0x270
           [<ffffffff94f2b985>] ? radix_tree_gang_lookup_tag+0xc5/0x1c0
           [<ffffffff94dad0f3>] ? __list_lru_walk_one.isra.3+0x33/0x120
           [<ffffffffc0a98331>] ? xfs_reclaim_inodes_nr+0x31/0x40 [xfs]
           [<ffffffff94e05bfe>] ? super_cache_scan+0x17e/0x190
           [<ffffffff94d919f3>] ? shrink_slab.part.38+0x1e3/0x3d0
           [<ffffffff94d9616a>] ? shrink_node+0x10a/0x320
           [<ffffffff94d96474>] ? do_try_to_free_pages+0xf4/0x350
           [<ffffffff94d967ba>] ? try_to_free_pages+0xea/0x1b0
           [<ffffffff94d863bd>] ? __alloc_pages_nodemask+0x61d/0xe60
           [<ffffffff94ddf42d>] ? cache_grow_begin+0x9d/0x560
           [<ffffffff94ddfb88>] ? fallback_alloc+0x148/0x1c0
           [<ffffffff94ed84e7>] ? __crypto_alloc_tfm+0x37/0x130
           [<ffffffff94de09db>] ? __kmalloc+0x1eb/0x580
           [<ffffffffc09fe2db>] ? crush_choose_firstn+0x3eb/0x470 [libceph]
           [<ffffffff94ed84e7>] ? __crypto_alloc_tfm+0x37/0x130
           [<ffffffff94ed9c19>] ? crypto_spawn_tfm+0x39/0x60
           [<ffffffffc08b30a3>] ? crypto_cbc_init_tfm+0x23/0x40 [cbc]
           [<ffffffff94ed857c>] ? __crypto_alloc_tfm+0xcc/0x130
           [<ffffffff94edcc23>] ? crypto_skcipher_init_tfm+0x113/0x180
           [<ffffffff94ed7cc3>] ? crypto_create_tfm+0x43/0xb0
           [<ffffffff94ed83b0>] ? crypto_larval_lookup+0x150/0x150
           [<ffffffff94ed7da2>] ? crypto_alloc_tfm+0x72/0x120
           [<ffffffffc0a01dd7>] ? ceph_aes_encrypt2+0x67/0x400 [libceph]
           [<ffffffffc09fd264>] ? ceph_pg_to_up_acting_osds+0x84/0x5b0 [libceph]
           [<ffffffff950d40a0>] ? release_sock+0x40/0x90
           [<ffffffff95139f94>] ? tcp_recvmsg+0x4b4/0xae0
           [<ffffffffc0a02714>] ? ceph_encrypt2+0x54/0xc0 [libceph]
           [<ffffffffc0a02b4d>] ? ceph_x_encrypt+0x5d/0x90 [libceph]
           [<ffffffffc0a02bdf>] ? calcu_signature+0x5f/0x90 [libceph]
           [<ffffffffc0a02ef5>] ? ceph_x_sign_message+0x35/0x50 [libceph]
           [<ffffffffc09e948c>] ? prepare_write_message_footer+0x5c/0xa0 [libceph]
           [<ffffffffc09ecd18>] ? ceph_con_workfn+0x2258/0x2dd0 [libceph]
           [<ffffffffc09e9903>] ? queue_con_delay+0x33/0xd0 [libceph]
           [<ffffffffc09f68ed>] ? __submit_request+0x20d/0x2f0 [libceph]
           [<ffffffffc09f6ef8>] ? ceph_osdc_start_request+0x28/0x30 [libceph]
           [<ffffffffc0b52603>] ? rbd_queue_workfn+0x2f3/0x350 [rbd]
           [<ffffffff94c94ec0>] ? process_one_work+0x160/0x410
           [<ffffffff94c951bd>] ? worker_thread+0x4d/0x480
           [<ffffffff94c95170>] ? process_one_work+0x410/0x410
           [<ffffffff94c9af8d>] ? kthread+0xcd/0xf0
           [<ffffffff951efb2f>] ? ret_from_fork+0x1f/0x40
           [<ffffffff94c9aec0>] ? kthread_create_on_node+0x190/0x190
      
      Allocating the cipher along with the key fixes the issue - as long the
      key doesn't change, a single cipher context can be used concurrently in
      multiple requests.
      
      We still can't take that GFP_KERNEL allocation though.  Both
      ceph_crypto_key_clone() and ceph_crypto_key_decode() are called from
      GFP_NOFS context, so resort to memalloc_noio_{save,restore}() here.
      Reported-by: default avatarLucas Stach <l.stach@pengutronix.de>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      7af3ea18
    • Ilya Dryomov's avatar
      libceph: uninline ceph_crypto_key_destroy() · 6db2304a
      Ilya Dryomov authored
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      6db2304a
    • Ilya Dryomov's avatar
    • Ilya Dryomov's avatar
      e15fd0a1
    • Ilya Dryomov's avatar
      d03857c6
    • Ilya Dryomov's avatar
      libceph: tweak calcu_signature() a little · 4eb4517c
      Ilya Dryomov authored
      - replace an ad-hoc array with a struct
      - rename to calc_signature() for consistency
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      4eb4517c
    • Ilya Dryomov's avatar
      libceph: rename and align ceph_x_authorizer::reply_buf · 7882a26d
      Ilya Dryomov authored
      It's going to be used as a temporary buffer for in-place en/decryption
      with ceph_crypt() instead of on-stack buffers, so rename to enc_buf.
      Ensure alignment to avoid GFP_ATOMIC allocations in the crypto stack.
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      7882a26d
    • Ilya Dryomov's avatar
      libceph: introduce ceph_crypt() for in-place en/decryption · a45f795c
      Ilya Dryomov authored
      Starting with 4.9, kernel stacks may be vmalloced and therefore not
      guaranteed to be physically contiguous; the new CONFIG_VMAP_STACK
      option is enabled by default on x86.  This makes it invalid to use
      on-stack buffers with the crypto scatterlist API, as sg_set_buf()
      expects a logical address and won't work with vmalloced addresses.
      
      There isn't a different (e.g. kvec-based) crypto API we could switch
      net/ceph/crypto.c to and the current scatterlist.h API isn't getting
      updated to accommodate this use case.  Allocating a new header and
      padding for each operation is a non-starter, so do the en/decryption
      in-place on a single pre-assembled (header + data + padding) heap
      buffer.  This is explicitly supported by the crypto API:
      
          "... the caller may provide the same scatter/gather list for the
           plaintext and cipher text. After the completion of the cipher
           operation, the plaintext data is replaced with the ciphertext data
           in case of an encryption and vice versa for a decryption."
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      a45f795c
    • Ilya Dryomov's avatar
      libceph: introduce ceph_x_encrypt_offset() · 55d9cc83
      Ilya Dryomov authored
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      55d9cc83
    • Ilya Dryomov's avatar
      libceph: old_key in process_one_ticket() is redundant · 462e6504
      Ilya Dryomov authored
      Since commit 0a990e70 ("ceph: clean up service ticket decoding"),
      th->session_key isn't assigned until everything is decoded.
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      462e6504
    • Ilya Dryomov's avatar
      libceph: ceph_x_encrypt_buflen() takes in_len · 36721ece
      Ilya Dryomov authored
      Pass what's going to be encrypted - that's msg_b, not ticket_blob.
      ceph_x_encrypt_buflen() returns the upper bound, so this doesn't change
      the maxlen calculation, but makes it a bit clearer.
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      36721ece
  2. 11 Dec, 2016 4 commits
  3. 10 Dec, 2016 5 commits
    • Linus Torvalds's avatar
      Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 · 04516981
      Linus Torvalds authored
      Pull crypto fixes from Herbert Xu:
       "This fixes the following issues:
      
         - Fix pointer size when caam is used with AArch64 boot loader on
           AArch32 kernel.
      
         - Fix ahash state corruption in marvell driver.
      
         - Fix buggy algif_aed tag handling.
      
         - Prevent mcryptd from being used with incompatible algorithms which
           can cause crashes"
      
      * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
        crypto: algif_aead - fix uninitialized variable warning
        crypto: mcryptd - Check mcryptd algorithm compatibility
        crypto: algif_aead - fix AEAD tag memory handling
        crypto: caam - fix pointer size for AArch64 boot loader, AArch32 kernel
        crypto: marvell - Don't corrupt state of an STD req for re-stepped ahash
        crypto: marvell - Don't copy hash operation twice into the SRAM
      04516981
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · cd662895
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Limit the number of can filters to avoid > MAX_ORDER allocations.
          Fix from Marc Kleine-Budde.
      
       2) Limit GSO max size in netvsc driver to avoid problems with NVGRE
          configurations. From Stephen Hemminger.
      
       3) Return proper error when memory allocation fails in
          ser_gigaset_init(), from Dan Carpenter.
      
       4) Missing linkage undo in error paths of ipvlan_link_new(), from Gao
          Feng.
      
       5) Missing necessayr SET_NETDEV_DEV in lantiq and cpmac drivers, from
          Florian Fainelli.
      
       6) Handle probe deferral properly in smsc911x driver.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
        net: mlx5: Fix Kconfig help text
        net: smsc911x: back out silently on probe deferrals
        ibmveth: set correct gso_size and gso_type
        net: ethernet: cpmac: Call SET_NETDEV_DEV()
        net: ethernet: lantiq_etop: Call SET_NETDEV_DEV()
        vhost-vsock: fix orphan connection reset
        cxgb4/cxgb4vf: Assign netdev->dev_port with port ID
        driver: ipvlan: Unlink the upper dev when ipvlan_link_new failed
        ser_gigaset: return -ENOMEM on error instead of success
        NET: usb: cdc_mbim: add quirk for supporting Telit LE922A
        can: peak: fix bad memory access and free sequence
        phy: Don't increment MDIO bus refcount unless it's a different owner
        netvsc: reduce maximum GSO size
        drivers: net: cpsw-phy-sel: Clear RGMII_IDMODE on "rgmii" links
        can: raw: raw_setsockopt: limit number of can_filter that can be set
      cd662895
    • Christopher Covington's avatar
      net: mlx5: Fix Kconfig help text · d33695fb
      Christopher Covington authored
      Since the following commit, Infiniband and Ethernet have not been
      mutually exclusive.
      
      Fixes: 4aa17b28 mlx5: Enable mutual support for IB and Ethernet
      Signed-off-by: default avatarChristopher Covington <cov@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d33695fb
    • Linus Walleij's avatar
      net: smsc911x: back out silently on probe deferrals · ab4e4c07
      Linus Walleij authored
      When trying to get a regulator we may get deferred and we see
      this noise:
      
      smsc911x 1b800000.ethernet-ebi2 (unnamed net_device) (uninitialized):
         couldn't get regulators -517
      
      Then the driver continues anyway. Which means that the regulator
      may not be properly retrieved and reference counted, and may be
      switched off in case noone else is using it.
      
      Fix this by returning silently on deferred probe and let the
      system work it out.
      
      Cc: Jeremy Linton <jeremy.linton@arm.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ab4e4c07
    • Thomas Falcon's avatar
      ibmveth: set correct gso_size and gso_type · 7b596738
      Thomas Falcon authored
      This patch is based on an earlier one submitted
      by Jon Maxwell with the following commit message:
      
      "We recently encountered a bug where a few customers using ibmveth on the
      same LPAR hit an issue where a TCP session hung when large receive was
      enabled. Closer analysis revealed that the session was stuck because the
      one side was advertising a zero window repeatedly.
      
      We narrowed this down to the fact the ibmveth driver did not set gso_size
      which is translated by TCP into the MSS later up the stack. The MSS is
      used to calculate the TCP window size and as that was abnormally large,
      it was calculating a zero window, even although the sockets receive buffer
      was completely empty."
      
      We rely on the Virtual I/O Server partition in a pseries
      environment to provide the MSS through the TCP header checksum
      field. The stipulation is that users should not disable checksum
      offloading if rx packet aggregation is enabled through VIOS.
      
      Some firmware offerings provide the MSS in the RX buffer.
      This is signalled by a bit in the RX queue descriptor.
      Reviewed-by: default avatarBrian King <brking@linux.vnet.ibm.com>
      Reviewed-by: default avatarPradeep Satyanarayana <pradeeps@linux.vnet.ibm.com>
      Reviewed-by: default avatarMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Reviewed-by: default avatarJonathan Maxwell <jmaxwell37@gmail.com>
      Reviewed-by: default avatarDavid Dai <zdai@us.ibm.com>
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7b596738
  4. 09 Dec, 2016 11 commits
  5. 08 Dec, 2016 9 commits