1. 01 Mar, 2015 5 commits
    • Emmanuel Grumbach's avatar
      iwlwifi: pcie: disable the SCD_BASE_ADDR when we resume from WoWLAN · ecbc35f5
      Emmanuel Grumbach authored
      commit cd8f4384 upstream.
      
      The base address of the scheduler in the device's memory
      (SRAM) comes from two different sources. The periphery
      register and the alive notification from the firmware.
      We have a check in iwl_pcie_tx_start that ensures that
      they are the same.
      When we resume from WoWLAN, the firmware may have crashed
      for whatever reason. In that case, the whole device may be
      reset which means that the periphery register will hold a
      meaningless value. When we come to compare
      trans_pcie->scd_base_addr (which really holds the value we
      had when we loaded the WoWLAN firmware upon suspend) and
      the current value of the register, we don't see a match
      unsurprisingly.
      Trick the check to avoid a loud yet harmless WARN.
      Note that when the WoWLAN has crashed, we will see that
      in iwl_trans_pcie_d3_resume which will let the op_mode
      know. Once the op_mode is informed that the WowLAN firmware
      has crashed, it can't do much besides resetting the whole
      device.
      Reviewed-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ecbc35f5
    • Jan Kara's avatar
      fsnotify: fix handling of renames in audit · 30858d77
      Jan Kara authored
      commit 6ee8e25f upstream.
      
      Commit e9fd702a ("audit: convert audit watches to use fsnotify
      instead of inotify") broke handling of renames in audit.  Audit code
      wants to update inode number of an inode corresponding to watched name
      in a directory.  When something gets renamed into a directory to a
      watched name, inotify previously passed moved inode to audit code
      however new fsnotify code passes directory inode where the change
      happened.  That confuses audit and it starts watching parent directory
      instead of a file in a directory.
      
      This can be observed for example by doing:
      
        cd /tmp
        touch foo bar
        auditctl -w /tmp/foo
        touch foo
        mv bar foo
        touch foo
      
      In audit log we see events like:
      
        type=CONFIG_CHANGE msg=audit(1423563584.155:90): auid=1000 ses=2 op="updated rules" path="/tmp/foo" key=(null) list=4 res=1
        ...
        type=PATH msg=audit(1423563584.155:91): item=2 name="bar" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
        type=PATH msg=audit(1423563584.155:91): item=3 name="foo" inode=1046842 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=DELETE
        type=PATH msg=audit(1423563584.155:91): item=4 name="foo" inode=1046884 dev=08:0 2 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE
        ...
      
      and that's it - we see event for the first touch after creating the
      audit rule, we see events for rename but we don't see any event for the
      last touch.  However we start seeing events for unrelated stuff
      happening in /tmp.
      
      Fix the problem by passing moved inode as data in the FS_MOVED_FROM and
      FS_MOVED_TO events instead of the directory where the change happens.
      This doesn't introduce any new problems because noone besides
      audit_watch.c cares about the passed value:
      
        fs/notify/fanotify/fanotify.c cares only about FSNOTIFY_EVENT_PATH events.
        fs/notify/dnotify/dnotify.c doesn't care about passed 'data' value at all.
        fs/notify/inotify/inotify_fsnotify.c uses 'data' only for FSNOTIFY_EVENT_PATH.
        kernel/audit_tree.c doesn't care about passed 'data' at all.
        kernel/audit_watch.c expects moved inode as 'data'.
      
      Fixes: e9fd702a ("audit: convert audit watches to use fsnotify instead of inotify")
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Cc: Paul Moore <paul@paul-moore.com>
      Cc: Eric Paris <eparis@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      30858d77
    • Dave Chinner's avatar
      xfs: set superblock buffer type correctly · 33699d35
      Dave Chinner authored
      commit 3443a3bc upstream.
      
      When the superblock is modified in a transaction, the commonly
      modified fields are not actually copied to the superblock buffer to
      avoid the buffer lock becoming a serialisation point. However, there
      are some other operations that modify the superblock fields within
      the transaction that don't directly log to the superblock but rely
      on the changes to be applied during the transaction commit (to
      minimise the buffer lock hold time).
      
      When we do this, we fail to mark the buffer log item as being a
      superblock buffer and that can lead to the buffer not being marked
      with the corect type in the log and hence causing recovery issues.
      Fix it by setting the type correctly, similar to xfs_mod_sb()...
      Tested-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      33699d35
    • Dave Chinner's avatar
      xfs: inode unlink does not set AGI buffer type · 7baee9ce
      Dave Chinner authored
      commit f19b872b upstream.
      
      This leads to log recovery throwing errors like:
      
      XFS (md0): Mounting V5 Filesystem
      XFS (md0): Starting recovery (logdev: internal)
      XFS (md0): Unknown buffer type 0!
      XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1
      ffff8800ffc53800: 58 41 47 49 .....
      
      Which is the AGI buffer magic number.
      
      Ensure that we set the type appropriately in both unlink list
      addition and removal.
      Tested-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      7baee9ce
    • Dave Chinner's avatar
      xfs: ensure buffer types are set correctly · a48f1a6b
      Dave Chinner authored
      commit 0d612fb5 upstream.
      
      Jan Kara reported that log recovery was finding buffers with invalid
      types in them. This should not happen, and indicates a bug in the
      logging of buffers. To catch this, add asserts to the buffer
      formatting code to ensure that the buffer type is in range when the
      transaction is committed.
      
      We don't set a type on buffers being marked stale - they are not
      going to get replayed, the format item exists only for recovery to
      be able to prevent replay of the buffer, so the type does not
      matter. Hence that needs special casing here.
      Reported-by: default avatarJan Kara <jack@suse.cz>
      Tested-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Signed-off-by: default avatarDave Chinner <david@fromorbit.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      a48f1a6b
  2. 16 Feb, 2015 30 commits
  3. 13 Feb, 2015 2 commits
    • Austin Lund's avatar
      [media] media/rc: Send sync space information on the lirc device · 1d8d26c7
      Austin Lund authored
      commit a8f29e89 upstream.
      
      Userspace expects to see a long space before the first pulse is sent on
      the lirc device.  Currently, if a long time has passed and a new packet
      is started, the lirc codec just returns and doesn't send anything.  This
      makes lircd ignore many perfectly valid signals unless they are sent in
      quick sucession.  When a reset event is delivered, we cannot know
      anything about the duration of the space.  But it should be safe to
      assume it has been a long time and we just set the duration to maximum.
      Signed-off-by: default avatarAustin Lund <austin.lund@gmail.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      1d8d26c7
    • Alex Elder's avatar
      rbd: drop an unsafe assertion · 15c029a9
      Alex Elder authored
      commit 638c323c upstream.
      
      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: default avatarOlivier Bonvalet <ob@daevel.fr>
      Signed-off-by: default avatarAlex Elder <elder@linaro.org>
      Reviewed-by: default avatarSage Weil <sage@inktank.com>
      Reviewed-by: default avatarIlya Dryomov <ilya.dryomov@inktank.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      15c029a9
  4. 10 Feb, 2015 3 commits