1. 16 4月, 2014 1 次提交
    • J
      block: remove struct request buffer member · b4f42e28
      Jens Axboe 提交于
      This was used in the olden days, back when onions were proper
      yellow. Basically it mapped to the current buffer to be
      transferred. With highmem being added more than a decade ago,
      most drivers map pages out of a bio, and rq->buffer isn't
      pointing at anything valid.
      
      Convert old style drivers to just use bio_data().
      
      For the discard payload use case, just reference the page
      in the bio.
      Signed-off-by: NJens Axboe <axboe@fb.com>
      b4f42e28
  2. 11 4月, 2014 6 次提交
  3. 09 4月, 2014 1 次提交
    • M
      drivers/block/loop.c: ratelimit error messages · 44bd70c3
      Mike Galbraith 提交于
      Metric tons of high speed spew is not helpful when things go pear shaped.
      systemd lost its mind, forgot how to stop services it insists on being
      sole manager of, massive printk() flood ensued, box eventually died.
      
      [16206.684000] loop: Write error at byte offset 11412291584, length 4096.
      [16206.684000] systemd-journald[1758]: /dev/kmsg buffer overrun, some messages lost.
      [16206.684000] loop: Write error at byte offset 13155434496, length 4096.
      [16206.684000] loop: Write error at byte offset 13155438592, length 4096.
      [16206.684000] loop: Write error at byte offset 13155442688, length 4096.
      [16206.684000] loop: Write error at byte offset 13960736768, length 4096.
      [16206.684000] loop: Write error at byte offset 14229172224, length 4096.
      [16206.684000] systemd-journald[1758]: /dev/kmsg buffer overrun, some messages lost.
      [16206.684000] loop: Write error at byte offset 14766043136, length 4096.
      [16206.684000] loop: Write error at byte offset 15034478592, length 4096.
      [16206.684000] systemd-journald[1758]: /dev/kmsg buffer overrun, some messages lost.
      Signed-off-by: NMike Galbraith <bitbucket@online.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      44bd70c3
  4. 08 4月, 2014 21 次提交
  5. 03 4月, 2014 5 次提交
  6. 02 4月, 2014 2 次提交
  7. 30 3月, 2014 1 次提交
    • A
      rbd: drop an unsafe assertion · 638c323c
      Alex Elder 提交于
      Olivier Bonvalet reported having repeated crashes due to a failed
      assertion he was hitting in rbd_img_obj_callback():
      
          Assertion failure in rbd_img_obj_callback() at line 2165:
      	rbd_assert(which >= img_request->next_completion);
      
      With a lot of help from Olivier with reproducing the problem
      we were able to determine the object and image requests had
      already been completed (and often freed) at the point the
      assertion failed.
      
      There was a great deal of discussion on the ceph-devel mailing list
      about this.  The problem only arose when there were two (or more)
      object requests in an image request, and the problem was always
      seen when the second request was being completed.
      
      The problem is due to a race in the window between setting the
      "done" flag on an object request and checking the image request's
      next completion value.  When the first object request completes, it
      checks to see if its successor request is marked "done", and if
      so, that request is also completed.  In the process, the image
      request's next_completion value is updated to reflect that both
      the first and second requests are completed.  By the time the
      second request is able to check the next_completion value, it
      has been set to a value *greater* than its own "which" value,
      which caused an assertion to fail.
      
      Fix this problem by skipping over any completion processing
      unless the completing object request is the next one expected.
      Test only for inequality (not >=), and eliminate the bad
      assertion.
      Tested-by: NOlivier Bonvalet <ob@daevel.fr>
      Signed-off-by: NAlex Elder <elder@linaro.org>
      Reviewed-by: NSage Weil <sage@inktank.com>
      Reviewed-by: NIlya Dryomov <ilya.dryomov@inktank.com>
      638c323c
  8. 24 3月, 2014 3 次提交