Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 02 10月, 2012 1 次提交
    • J
      nfsd4: don't pin clientids to pseudoflavors · 68eb3508
      由 J. Bruce Fields 提交于 
      I added cr_flavor to the data compared in same_creds without any
justification, in d5497fc6 "nfsd4: move
rq_flavor into svc_cred".

Recent client changes then started making

	mount -osec=krb5 server:/export /mnt/
	echo "hello" >/mnt/TMP
	umount /mnt/
	mount -osec=krb5i server:/export /mnt/
	echo "hello" >/mnt/TMP

to fail due to a clid_inuse on the second open.

Mounting sequentially like this with different flavors probably isn't
that common outside artificial tests.  Also, the real bug here may be
that the server isn't just destroying the former clientid in this case
(because it isn't good enough at recognizing when the old state is
gone).  But it prompted some discussion and a look back at the spec, and
I think the check was probably wrong.  Fix and document.

Cc: stable@kernel.org
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      68eb3508
  3. 26 9月, 2012 1 次提交
  5. 11 9月, 2012 5 次提交
  7. 10 9月, 2012 2 次提交
  9. 22 8月, 2012 6 次提交
  11. 21 8月, 2012 7 次提交
  13. 17 8月, 2012 1 次提交
    • I
      autofs4 - fix get_next_positive_subdir() · a45440f0
      由 Ian Kent 提交于 
      Following a report of a crash during an automount expire I found that
the locking in fs/autofs4/expire.c:get_next_positive_subdir() was wrong.
Not only is the locking wrong but the function is more complex than it
needs to be.

The function is meant to calculate (and dget) the next entry in the list
of directories contained in the root of an autofs mount point (an autofs
indirect mount to be precise). The main problem was that the d_lock of
the owner of the list was not being taken when walking the list, which
lead to list corruption under load. The only other lock that needs to
be taken is against the next dentry candidate so it can be checked for
usability.
Signed-off-by: NIan Kent <raven@themaw.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a45440f0
  15. 09 8月, 2012 1 次提交
  17. 07 8月, 2012 1 次提交
    • Z
      fuse: verify all ioctl retry iov elements · fb6ccff6
      由 Zach Brown 提交于 
      Commit 7572777e attempted to verify that
the total iovec from the client doesn't overflow iov_length() but it
only checked the first element.  The iovec could still overflow by
starting with a small element.  The obvious fix is to check all the
elements.

The overflow case doesn't look dangerous to the kernel as the copy is
limited by the length after the overflow.  This fix restores the
intention of returning an error instead of successfully copying less
than the iovec represented.

I found this by code inspection.  I built it but don't have a test case.
I'm cc:ing stable because the initial commit did as well.
Signed-off-by: NZach Brown <zab@redhat.com>
Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
CC: <stable@vger.kernel.org>         [2.6.37+]
      fb6ccff6
  19. 04 8月, 2012 13 次提交
  21. 03 8月, 2012 1 次提交
    • S
      ceph: simplify+fix atomic_open · 5ef50c3b
      由 Sage Weil 提交于 
      The initial ->atomic_open op was carried over from the old intent code,
which was incomplete and didn't really work.  Replace it with a fresh
method.  In particular:

 * always attempt to do an atomic open+lookup, both for the create case
   and for lookups of existing files.
 * fix symlink handling by returning 1 to the VFS so that we can follow
   the link to its destination. This fixes a longstanding ceph bug (#2392).
Signed-off-by: NSage Weil <sage@inktank.com>
      5ef50c3b
  23. 02 8月, 2012 1 次提交
    • B
      ore: Fix out-of-bounds access in _ios_obj() · 9e62bb44
      由 Boaz Harrosh 提交于 
      _ios_obj() is accessed by group_index not device_table index.

The oc->comps array is only a group_full of devices at a time
it is not like ore_comp_dev() which is indexed by a global
device_table index.

This did not BUG until now because exofs only uses a single
COMP for all devices. But with other FSs like PanFS this is
not true.

This bug was only in the write_path, all other users were
using it correctly

[This is a bug since 3.2 Kernel]
CC: Stable Tree <stable@kernel.org>
Signed-off-by: NBoaz Harrosh <bharrosh@panasas.com>
      9e62bb44