1. 28 5月, 2016 14 次提交
  2. 27 5月, 2016 7 次提交
  3. 26 5月, 2016 12 次提交
    • D
      hwmon: (emc2103) Fix typo in MODULE_PARM_DESC · 54f0ffc4
      Dan Carpenter 提交于
      "apd" was intended here instead of "init".
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      54f0ffc4
    • W
      Revert "mtd: atmel_nand: Support variable RB_EDGE interrupts" · 53b74ed2
      Wenyou Yang 提交于
      This reverts commit 5ddc7bd4 ("mtd: atmel_nand: Support variable
      RB_EDGE interrupts")
      
      Because for current SoCs, the RB_EDGE3(i.e. bit 27) of HSMC_SR
      register does not exist, the RB_EDGE0 (i.e. bit 24) is the ready/busy
      line edge status bit. It is a datasheet bug.
      
      Cc: <stable@vger.kernel.org>
      Fixes: commit 5ddc7bd4 ("mtd: atmel_nand: Support variable RB_EDGE interrupts")
      Signed-off-by: NWenyou Yang <wenyou.yang@atmel.com>
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      53b74ed2
    • I
      libceph: replace ceph_monc_request_next_osdmap() · 7cca78c9
      Ilya Dryomov 提交于
      ... with a wrapper around maybe_request_map() - no need for two
      osdmap-specific functions.
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      7cca78c9
    • I
      libceph: async MON client generic requests · d0b19705
      Ilya Dryomov 提交于
      For map check, we are going to need to send CEPH_MSG_MON_GET_VERSION
      messages asynchronously and get a callback on completion.  Refactor MON
      client to allow firing off generic requests asynchronously and add an
      async variant of ceph_monc_get_version().  ceph_monc_do_statfs() is
      switched over and remains sync.
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      d0b19705
    • I
      libceph, rbd: ceph_osd_linger_request, watch/notify v2 · 922dab61
      Ilya Dryomov 提交于
      This adds support and switches rbd to a new, more reliable version of
      watch/notify protocol.  As with the OSD client update, this is mostly
      about getting the right structures linked into the right places so that
      reconnects are properly sent when needed.  watch/notify v2 also
      requires sending regular pings to the OSDs - send_linger_ping().
      
      A major change from the old watch/notify implementation is the
      introduction of ceph_osd_linger_request - linger requests no longer
      piggy back on ceph_osd_request.  ceph_osd_event has been merged into
      ceph_osd_linger_request.
      
      All the details are now hidden within libceph, the interface consists
      of a simple pair of watch/unwatch functions and ceph_osdc_notify_ack().
      ceph_osdc_watch() does return ceph_osd_linger_request, but only to keep
      the lifetime management simple.
      
      ceph_osdc_notify_ack() accepts an optional data payload, which is
      relayed back to the notifier.
      
      Portions of this patch are loosely based on work by Douglas Fuller
      <dfuller@redhat.com> and Mike Christie <michaelc@cs.wisc.edu>.
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      922dab61
    • I
      rbd: rbd_dev_header_unwatch_sync() variant · c525f036
      Ilya Dryomov 提交于
      Introduce __rbd_dev_header_unwatch_sync(), which doesn't flush notify
      callbacks.  This is for the new rados_watcherrcb_t, which would be
      called from a notify callback.
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      c525f036
    • I
      libceph: drop msg argument from ceph_osdc_callback_t · 85e084fe
      Ilya Dryomov 提交于
      finish_read(), its only user, uses it to get to hdr.data_len, which is
      what ->r_result is set to on success.  This gains us the ability to
      safely call callbacks from contexts other than reply, e.g. map check.
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      85e084fe
    • I
      libceph: switch to calc_target(), part 2 · bb873b53
      Ilya Dryomov 提交于
      The crux of this is getting rid of ceph_osdc_build_request(), so that
      MOSDOp can be encoded not before but after calc_target() calculates the
      actual target.  Encoding now happens within ceph_osdc_start_request().
      
      Also nuked is the accompanying bunch of pointers into the encoded
      buffer that was used to update fields on each send - instead, the
      entire front is re-encoded.  If we want to support target->name_len !=
      base->name_len in the future, there is no other way, because oid is
      surrounded by other fields in the encoded buffer.
      
      Encoding OSD ops and adding data items to the request message were
      mixed together in osd_req_encode_op().  While we want to re-encode OSD
      ops, we don't want to add duplicate data items to the message when
      resending, so all call to ceph_osdc_msg_data_add() are factored out
      into a new setup_request_data().
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      bb873b53
    • I
      rbd: use header_oid instead of header_name · c41d13a3
      Ilya Dryomov 提交于
      Switch to ceph_object_id and use ceph_oid_aprintf() instead of a bare
      const char *.  This reduces noise in rbd_dev_header_name().
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      c41d13a3
    • I
      libceph: variable-sized ceph_object_id · d30291b9
      Ilya Dryomov 提交于
      Currently ceph_object_id can hold object names of up to 100
      (CEPH_MAX_OID_NAME_LEN) characters.  This is enough for all use cases,
      expect one - long rbd image names:
      
      - a format 1 header is named "<imgname>.rbd"
      - an object that points to a format 2 header is named "rbd_id.<imgname>"
      
      We operate on these potentially long-named objects during rbd map, and,
      for format 1 images, during header refresh.  (A format 2 header name is
      a small system-generated string.)
      
      Lift this 100 character limit by making ceph_object_id be able to point
      to an externally-allocated string.  Apart from being able to work with
      almost arbitrarily-long named objects, this allows us to reduce the
      size of ceph_object_id from >100 bytes to 64 bytes.
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      d30291b9
    • I
      libceph: move message allocation out of ceph_osdc_alloc_request() · 13d1ad16
      Ilya Dryomov 提交于
      The size of ->r_request and ->r_reply messages depends on the size of
      the object name (ceph_object_id), while the size of ceph_osd_request is
      fixed.  Move message allocation into a separate function that would
      have to be called after ceph_object_id and ceph_object_locator (which
      is also going to become variable in size with RADOS namespaces) have
      been filled in:
      
          req = ceph_osdc_alloc_request(...);
          <fill in req->r_base_oid>
          <fill in req->r_base_oloc>
          ceph_osdc_alloc_messages(req);
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      13d1ad16
    • I
      rbd: get/put img_request in rbd_img_request_submit() · 663ae2cc
      Ilya Dryomov 提交于
      By the time we get to checking for_each_obj_request_safe(img_request)
      terminating condition, all obj_requests may be complete and img_request
      ref, that rbd_img_request_submit() takes away from its caller, may be
      put.  Moving the next_obj_request cursor is then a use-after-free on
      img_request.
      
      It's totally benign, as the value that's read is never used, but
      I think it's still worth fixing.
      
      Cc: Alex Elder <elder@linaro.org>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      663ae2cc
  4. 25 5月, 2016 3 次提交
  5. 24 5月, 2016 4 次提交
    • J
      bcache: bch_gc_thread() is not freezable · 29e6c57c
      Jiri Kosina 提交于
      bch_gc_thread() doesn't mark itself freezable, so calling try_to_freeze()
      in its context is just an expensive no-op.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      29e6c57c
    • J
      bcache: bch_allocator_thread() is not freezable · 770b8ce4
      Jiri Kosina 提交于
      bch_allocator_thread() is calling try_to_freeze(), but that's just an
      expensive no-op given the fact that the thread is not marked freezable.
      
      Bucket allocator has to be up and running to the very last stages of the
      suspend, as the bcache I/O that's in flight (think of writing an
      hibernation image to a swap device served by bcache).
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      770b8ce4
    • J
      bcache: bch_writeback_thread() is not freezable · 7c87df9c
      Jiri Kosina 提交于
      bch_writeback_thread() is calling try_to_freeze(), but that's just an
      expensive no-op given the fact that the thread is not marked freezable.
      
      I/O helper kthreads, exactly such as the bcache writeback thread, actually
      shouldn't be freezable, because they are potentially necessary for
      finalizing the image write-out.
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      7c87df9c
    • R
      UBI: Fix static volume checks when Fastmap is used · 1900149c
      Richard Weinberger 提交于
      Ezequiel reported that he's facing UBI going into read-only
      mode after power cut. It turned out that this behavior happens
      only when updating a static volume is interrupted and Fastmap is
      used.
      
      A possible trace can look like:
      ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes
      ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode
      CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4
      Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012
      0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841
      ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6
      ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0
      Call Trace:
      [<ffffffff8140d841>] dump_stack+0x63/0x82
      [<ffffffffa003abf6>] ubi_eba_read_leb+0x486/0x4a0 [ubi]
      [<ffffffffa00453b3>] ubi_check_volume+0x83/0xf0 [ubi]
      [<ffffffffa0039d97>] ubi_open_volume+0x177/0x350 [ubi]
      [<ffffffffa00375d8>] vol_cdev_open+0x58/0xb0 [ubi]
      [<ffffffff8124b08e>] chrdev_open+0xae/0x1d0
      [<ffffffff81243bcf>] do_dentry_open+0x1ff/0x300
      [<ffffffff8124afe0>] ? cdev_put+0x30/0x30
      [<ffffffff81244d36>] vfs_open+0x56/0x60
      [<ffffffff812545f4>] path_openat+0x4f4/0x1190
      [<ffffffff81256621>] do_filp_open+0x91/0x100
      [<ffffffff81263547>] ? __alloc_fd+0xc7/0x190
      [<ffffffff812450df>] do_sys_open+0x13f/0x210
      [<ffffffff812451ce>] SyS_open+0x1e/0x20
      [<ffffffff81a99e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4
      
      UBI checks static volumes for data consistency and reads the
      whole volume upon first open. If the volume is found erroneous
      users of UBI cannot read from it, but another volume update is
      possible to fix it. The check is performed by running
      ubi_eba_read_leb() on every allocated LEB of the volume.
      For static volumes ubi_eba_read_leb() computes the checksum of all
      data stored in a LEB. To verify the computed checksum it has to read
      the LEB's volume header which stores the original checksum.
      If the volume header is not found UBI treats this as fatal internal
      error and switches to RO mode. If the UBI device was attached via a
      full scan the assumption is correct, the volume header has to be
      present as it had to be there while scanning to get known as mapped.
      If the attach operation happened via Fastmap the assumption is no
      longer correct. When attaching via Fastmap UBI learns the mapping
      table from Fastmap's snapshot of the system state and not via a full
      scan. It can happen that a LEB got unmapped after a Fastmap was
      written to the flash. Then UBI can learn the LEB still as mapped and
      accessing it returns only 0xFF bytes. As UBI is not a FTL it is
      allowed to have mappings to empty PEBs, it assumes that the layer
      above takes care of LEB accounting and referencing.
      UBIFS does so using the LEB property tree (LPT).
      For static volumes UBI blindly assumes that all LEBs are present and
      therefore special actions have to be taken.
      
      The described situation can happen when updating a static volume is
      interrupted, either by a user or a power cut.
      The volume update code first unmaps all LEBs of a volume and then
      writes LEB by LEB. If the sequence of operations is interrupted UBI
      detects this either by the absence of LEBs, no volume header present
      at scan time, or corrupted payload, detected via checksum.
      In the Fastmap case the former method won't trigger as no scan
      happened and UBI automatically thinks all LEBs are present.
      Only by reading data from a LEB it detects that the volume header is
      missing and incorrectly treats this as fatal error.
      To deal with the situation ubi_eba_read_leb() from now on checks
      whether we attached via Fastmap and handles the absence of a
      volume header like a data corruption error.
      This way interrupted static volume updates will correctly get detected
      also when Fastmap is used.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
      Tested-by: NEzequiel Garcia <ezequiel@vanguardiasur.com.ar>
      Signed-off-by: NRichard Weinberger <richard@nod.at>
      1900149c