1. 31 3月, 2014 16 次提交
  2. 30 3月, 2014 3 次提交
    • D
      Input: mousedev - fix race when creating mixed device · e4dbedc7
      Dmitry Torokhov 提交于
      We should not be using static variable mousedev_mix in methods that can be
      called before that singleton gets assigned. While at it let's add open and
      close methods to mousedev structure so that we do not need to test if we
      are dealing with multiplexor or normal device and simply call appropriate
      method directly.
      
      This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=71551Reported-by: NGiulioDP <depasquale.giulio@gmail.com>
      Tested-by: NGiulioDP <depasquale.giulio@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      e4dbedc7
    • E
      Input: don't modify the id of ioctl-provided ff effect on upload failure · fc7392aa
      Elias Vanderstuyft 提交于
      If a new (id == -1) ff effect was uploaded from userspace,
      ff-core.c::input_ff_upload() will have assigned a positive number to the
      new effect id.  Currently, evdev.c::evdev_do_ioctl() will save this new id
      to userspace, regardless of whether the upload succeeded or not.
      
      On upload failure, this can be confusing because the dev->ff->effects[]
      array will not contain an element at the index of that new effect id.
      
      This patch fixes this by leaving the id unchanged after upload fails.
      
      Note: Unfortunately applications should still expect changed effect id for
      quite some time.
      
      This has been discussed on:
      http://www.mail-archive.com/linux-input@vger.kernel.org/msg08513.html
      ("ff-core effect id handling in case of a failed effect upload")
      Suggested-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NElias Vanderstuyft <elias.vds@gmail.com>
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      fc7392aa
    • 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
  3. 29 3月, 2014 19 次提交
  4. 28 3月, 2014 2 次提交