1. 25 Feb, 2013 3 commits
  2. 20 Feb, 2013 4 commits
  3. 18 Feb, 2013 13 commits
  4. 14 Feb, 2013 4 commits
    • Alex Elder's avatar
      libceph: don't require r_num_pages for bio requests · 9cbb1d72
      Alex Elder authored
      There is a check in the completion path for osd requests that
      ensures the number of pages allocated is enough to hold the amount
      of incoming data expected.
      
      For bio requests coming from rbd the "number of pages" is not really
      meaningful (although total length would be).  So stop requiring that
      nr_pages be supplied for bio requests.  This is done by checking
      whether the pages pointer is null before checking the value of
      nr_pages.
      
      Note that this value is passed on to the messenger, but there it's
      only used for debugging--it's never used for validation.
      
      While here, change another spot that used r_pages in a debug message
      inappropriately, and also invalidate the r_con_filling_msg pointer
      after dropping a reference to it.
      
      This resolves:
          http://tracker.ceph.com/issues/3875
      
      Signed-off-by: default avatarAlex Elder <elder@inktank.com>
      Reviewed-by: default avatarJosh Durgin <josh.durgin@inktank.com>
      9cbb1d72
    • Alex Elder's avatar
      rbd: don't take extra bio reference for osd client · 1e32d34c
      Alex Elder authored
      Currently, if the OSD client finds an osd request has had a bio list
      attached to it, it drops a reference to it (or rather, to the first
      entry on that list) when the request is released.
      
      The code that added that reference (i.e., the rbd client) is
      therefore required to take an extra reference to that first bio
      structure.
      
      The osd client doesn't really do anything with the bio pointer other
      than transfer it from the osd request structure to outgoing (for
      writes) and ingoing (for reads) messages.  So it really isn't the
      right place to be taking or dropping references.
      
      Furthermore, the rbd client already holds references to all bio
      structures it passes to the osd client, and holds them until the
      request is completed.  So there's no need for this extra reference
      whatsoever.
      
      So remove the bio_put() call in ceph_osdc_release_request(), as
      well as its matching bio_get() call in rbd_osd_req_create().
      
      This change could lead to a crash if old libceph.ko was used with
      new rbd.ko.  Add a compatibility check at rbd initialization time to
      avoid this possibilty.
      
      This resolves:
          http://tracker.ceph.com/issues/3798    and
          http://tracker.ceph.com/issues/3799
      
      Signed-off-by: default avatarAlex Elder <elder@inktank.com>
      Reviewed-by: default avatarJosh Durgin <josh.durgin@inktank.com>
      1e32d34c
    • Alex Elder's avatar
      libceph: add a compatibility check interface · 72fe25e3
      Alex Elder authored
      An upcoming change implements semantic change that could lead to
      a crash if an old version of the libceph kernel module is used with
      a new version of the rbd kernel module.
      
      In order to preclude that possibility, this adds a compatibilty
      check interface.  If this interface doesn't exist, the modules are
      obviously not compatible.  But if it does exist, this provides a way
      of letting the caller know whether it will operate properly with
      this libceph module.
      
      Perhaps confusingly, it returns false right now.  The semantic
      change mentioned above will make it return true.
      
      This resolves:
          http://tracker.ceph.com/issues/3800
      
      Signed-off-by: default avatarAlex Elder <elder@inktank.com>
      Reviewed-by: default avatarJosh Durgin <josh.durgin@inktank.com>
      72fe25e3
    • Alex Elder's avatar
      libceph: fix messenger CONFIG_BLOCK dependencies · 3ebc21f7
      Alex Elder authored
      The ceph messenger has a few spots that are only used when
      bio messages are supported, and that's only when CONFIG_BLOCK
      is defined.  This surrounds a couple of spots with #ifdef's
      that would cause a problem if CONFIG_BLOCK were not present
      in the kernel configuration.
      
      This resolves:
          http://tracker.ceph.com/issues/3976
      
      Signed-off-by: default avatarAlex Elder <elder@inktank.com>
      Reviewed-by: default avatarJosh Durgin <josh.durgin@inktank.com>
      3ebc21f7
  5. 13 Feb, 2013 3 commits
  6. 12 Feb, 2013 2 commits
    • Jiri Pirko's avatar
      htb: fix values in opt dump · 9c10f411
      Jiri Pirko authored
      in htb_change_class() cl->buffer and cl->buffer are stored in ns.
      So in dump, convert them back to psched ticks.
      
      Note this was introduced by:
      commit 56b765b7
      
      
          htb: improved accuracy at high rates
      
      Please consider this for -net/-stable.
      Signed-off-by: default avatarJiri Pirko <jiri@resnulli.us>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9c10f411
    • Eric Dumazet's avatar
      net: fix infinite loop in __skb_recv_datagram() · 77c1090f
      Eric Dumazet authored
      Tommi was fuzzing with trinity and reported the following problem :
      
      commit 3f518bf7 (datagram: Add offset argument to __skb_recv_datagram)
      missed that a raw socket receive queue can contain skbs with no payload.
      
      We can loop in __skb_recv_datagram() with MSG_PEEK mode, because
      wait_for_packet() is not prepared to skip these skbs.
      
      [   83.541011] INFO: rcu_sched detected stalls on CPUs/tasks: {}
      (detected by 0, t=26002 jiffies, g=27673, c=27672, q=75)
      [   83.541011] INFO: Stall ended before state dump start
      [  108.067010] BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child31:2847]
      ...
      [  108.067010] Call Trace:
      [  108.067010]  [<ffffffff818cc103>] __skb_recv_datagram+0x1a3/0x3b0
      [  108.067010]  [<ffffffff818cc33d>] skb_recv_datagram+0x2d/0x30
      [  108.067010]  [<ffffffff819ed43d>] rawv6_recvmsg+0xad/0x240
      [  108.067010]  [<ffffffff818c4b04>] sock_common_recvmsg+0x34/0x50
      [  108.067010]  [<ffffffff818bc8ec>] sock_recvmsg+0xbc/0xf0
      [  108.067010]  [<fffffff...
      77c1090f
  7. 11 Feb, 2013 3 commits
  8. 08 Feb, 2013 4 commits
  9. 07 Feb, 2013 4 commits