1. 12 Dec, 2016 18 commits
    • Zhi Zhang's avatar
      ceph: fix printing wrong return variable in ceph_direct_read_write() · a380a031
      Zhi Zhang authored
      Fix printing wrong return variable for invalidate_inode_pages2_range in
      ceph_direct_read_write().
      Signed-off-by: default avatarZhi Zhang <zhang.david2011@gmail.com>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      a380a031
    • Tobias Klauser's avatar
      crush: include mapper.h in mapper.c · f6c0d1a3
      Tobias Klauser authored
      Include linux/crush/mapper.h in crush/mapper.c to get the prototypes of
      crush_find_rule and crush_do_rule which are defined there. This fixes
      the following GCC warnings when building with 'W=1':
      
        net/ceph/crush/mapper.c:40:5: warning: no previous prototype for ‘crush_find_rule’ [-Wmissing-prototypes]
        net/ceph/crush/mapper.c:793:5: warning: no previous prototype for ‘crush_do_rule’ [-Wmissing-prototypes]
      Signed-off-by: default avatarTobias Klauser <tklauser@distanz.ch>
      [idryomov@gmail.com: corresponding !__KERNEL__ include]
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      f6c0d1a3
    • Ilya Dryomov's avatar
      rbd: silence bogus -Wmaybe-uninitialized warning · d4c2269b
      Ilya Dryomov authored
      drivers/block/rbd.c: In function ‘rbd_watch_cb’:
      drivers/block/rbd.c:3690:5: error: ‘struct_v’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
      drivers/block/rbd.c:3759:5: note: ‘struct_v’ was declared here
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      d4c2269b
    • Ilya Dryomov's avatar
      libceph: no need to drop con->mutex for ->get_authorizer() · b3bbd3f2
      Ilya Dryomov authored
      ->get_authorizer(), ->verify_authorizer_reply(), ->sign_message() and
      ->check_message_signature() shouldn't be doing anything with or on the
      connection (like closing it or sending messages).
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      b3bbd3f2
    • Ilya Dryomov's avatar
      libceph: drop len argument of *verify_authorizer_reply() · 0dde5848
      Ilya Dryomov authored
      The length of the reply is protocol-dependent - for cephx it's
      ceph_x_authorize_reply.  Nothing sensible can be passed from the
      messenger layer anyway.
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      0dde5848
    • Ilya Dryomov's avatar
      libceph: verify authorize reply on connect · 5c056fdc
      Ilya Dryomov authored
      After sending an authorizer (ceph_x_authorize_a + ceph_x_authorize_b),
      the client gets back a ceph_x_authorize_reply, which it is supposed to
      verify to ensure the authenticity and protect against replay attacks.
      The code for doing this is there (ceph_x_verify_authorizer_reply(),
      ceph_auth_verify_authorizer_reply() + plumbing), but it is never
      invoked by the the messenger.
      
      AFAICT this goes back to 2009, when ceph authentication protocols
      support was added to the kernel client in 4e7a5dcd ("ceph:
      negotiate authentication protocol; implement AUTH_NONE protocol").
      
      The second param of ceph_connection_operations::verify_authorizer_reply
      is unused all the way down.  Pass 0 to facilitate backporting, and kill
      it in the next commit.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      5c056fdc
    • Ilya Dryomov's avatar
      libceph: no need for GFP_NOFS in ceph_monc_init() · 5418d0a2
      Ilya Dryomov authored
      It's called during inital setup, when everything should be allocated
      with GFP_KERNEL.
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarSage Weil <sage@redhat.com>
      5418d0a2
    • 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 2 commits