1. 24 12月, 2016 9 次提交
  2. 12 12月, 2016 2 次提交
  3. 11 12月, 2016 4 次提交
  4. 10 12月, 2016 10 次提交
  5. 09 12月, 2016 13 次提交
  6. 08 12月, 2016 2 次提交
    • can: peak: fix bad memory access and free sequence · b67d0dd7
      추지호 提交于
      Fix for bad memory access while disconnecting. netdev is freed before
      private data free, and dev is accessed after freeing netdev.
      
      This makes a slub problem, and it raise kernel oops with slub debugger
      config.
      Signed-off-by: NJiho Chu <jiho.chu@samsung.com>
      Cc: linux-stable <stable@vger.kernel.org>
      Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
      b67d0dd7
    • J
      ceph: don't set req->r_locked_dir in ceph_d_revalidate · c3f4688a
      Jeff Layton 提交于
      This function sets req->r_locked_dir which is supposed to indicate to
      ceph_fill_trace that the parent's i_rwsem is locked for write.
      Unfortunately, there is no guarantee that the dir will be locked when
      d_revalidate is called, so we really don't want ceph_fill_trace to do
      any dcache manipulation from this context. Clear req->r_locked_dir since
      it's clearly not safe to do that.
      
      What we really want to know with d_revalidate is whether the dentry
      still points to the same inode. ceph_fill_trace installs a pointer to
      the inode in req->r_target_inode, so we can just compare that to
      d_inode(dentry) to see if it's the same one after the lookup.
      
      Also, since we aren't generally interested in the parent here, we can
      switch to using a GETATTR to hint that to the MDS, which also means that
      we only need to reserve one cap.
      
      Finally, just remove the d_unhashed check. That's really outside the
      purview of a filesystem's d_revalidate. If the thing became unhashed
      while we're checking it, then that's up to the VFS to handle anyway.
      
      Fixes: 200fd27c ("ceph: use lookup request to revalidate dentry")
      Link: http://tracker.ceph.com/issues/18041Reported-by: NDonatas Abraitis <donatas.abraitis@gmail.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: N"Yan, Zheng" <zyan@redhat.com>
      Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
      c3f4688a