Skip to content

cloud-kernel
cloud-kernel

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

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 07 6月, 2011 1 次提交
  3. 30 5月, 2011 1 次提交
  5. 27 5月, 2011 3 次提交
  7. 26 5月, 2011 11 次提交
  9. 21 5月, 2011 1 次提交
  11. 14 5月, 2011 1 次提交
    • L
      vfs: micro-optimize acl_permission_check() · 26cf46be
      由 Linus Torvalds 提交于 
      It's a hot function, and we're better off not mixing types in the mask
calculations.  The compiler just ends up mixing 16-bit and 32-bit
operations, for no good reason.

So do everything in 'unsigned int' rather than mixing 'unsigned int'
masking with a 'umode_t' (16-bit) mode variable.

This, together with the parent commit (47a150ed: "Cache user_ns in
struct cred") makes acl_permission_check() much nicer.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      26cf46be
  13. 16 4月, 2011 1 次提交
  15. 31 3月, 2011 1 次提交
  17. 25 3月, 2011 1 次提交
  19. 24 3月, 2011 2 次提交
  21. 23 3月, 2011 1 次提交
  23. 18 3月, 2011 2 次提交
  25. 16 3月, 2011 8 次提交
  27. 15 3月, 2011 4 次提交
    • A
      Allow O_PATH for symlinks · bcda7652
      由 Al Viro 提交于 
      At that point we can't do almost nothing with them.  They can be opened
with O_PATH, we can manipulate such descriptors with dup(), etc. and
we can see them in /proc/*/{fd,fdinfo}/*.

We can't (and won't be able to) follow /proc/*/fd/* symlinks for those;
there's simply not enough information for pathname resolution to go on
from such point - to resolve a symlink we need to know which directory
does it live in.

We will be able to do useful things with them after the next commit, though -
readlinkat() and fchownat() will be possible to use with dfd being an
O_PATH-opened symlink and empty relative pathname.  Combined with
open_by_handle() it'll give us a way to do realink-by-handle and
lchown-by-handle without messing with more redundant syscalls.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      bcda7652
    • A
      New kind of open files - "location only". · 1abf0c71
      由 Al Viro 提交于 
      New flag for open(2) - O_PATH.  Semantics:
	* pathname is resolved, but the file itself is _NOT_ opened
as far as filesystem is concerned.
	* almost all operations on the resulting descriptors shall
fail with -EBADF.  Exceptions are:
	1) operations on descriptors themselves (i.e.
		close(), dup(), dup2(), dup3(), fcntl(fd, F_DUPFD),
		fcntl(fd, F_DUPFD_CLOEXEC, ...), fcntl(fd, F_GETFD),
		fcntl(fd, F_SETFD, ...))
	2) fcntl(fd, F_GETFL), for a common non-destructive way to
		check if descriptor is open
	3) "dfd" arguments of ...at(2) syscalls, i.e. the starting
		points of pathname resolution
	* closing such descriptor does *NOT* affect dnotify or
posix locks.
	* permissions are checked as usual along the way to file;
no permission checks are applied to the file itself.  Of course,
giving such thing to syscall will result in permission checks (at
the moment it means checking that starting point of ....at() is
a directory and caller has exec permissions on it).

fget() and fget_light() return NULL on such descriptors; use of
fget_raw() and fget_raw_light() is needed to get them.  That protects
existing code from dealing with those things.

There are two things still missing (they come in the next commits):
one is handling of symlinks (right now we refuse to open them that
way; see the next commit for semantics related to those) and another
is descriptor passing via SCM_RIGHTS datagrams.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1abf0c71
    • A
      fs: Don't allow to create hardlink for deleted file · aae8a97d
      由 Aneesh Kumar K.V 提交于 
      Add inode->i_nlink == 0 check in VFS. Some of the file systems
do this internally. A followup patch will remove those instance.
This is needed to ensure that with link by handle we don't allow
to create hardlink of an unlinked file. The check also prevent a race
between unlink and link
Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      aae8a97d
    • A
      New AT_... flag: AT_EMPTY_PATH · f52e0c11
      由 Al Viro 提交于 
      For name_to_handle_at(2) we'll want both ...at()-style syscall that
would be usable for non-directory descriptors (with empty relative
pathname).  Introduce new flag (AT_EMPTY_PATH) to deal with that and
corresponding LOOKUP_EMPTY; teach user_path_at() and path_init() to
deal with the latter.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      f52e0c11
  29. 14 3月, 2011 2 次提交
    • A
      open-style analog of vfs_path_lookup() · 73d049a4
      由 Al Viro 提交于 
      new function: file_open_root(dentry, mnt, name, flags) opens the file
vfs_path_lookup would arrive to.

Note that name can be empty; in that case the usual requirement that
dentry should be a directory is lifted.

open-coded equivalents switched to it, may_open() got down exactly
one caller and became static.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      73d049a4
    • A
      reduce vfs_path_lookup() to do_path_lookup() · 5b6ca027
      由 Al Viro 提交于 
      New lookup flag: LOOKUP_ROOT.  nd->root is set (and held) by caller,
path_init() starts walking from that place and all pathname resolution
machinery never drops nd->root if that flag is set.  That turns
vfs_path_lookup() into a special case of do_path_lookup() *and*
gets us down to 3 callers of link_path_walk(), making it finally
feasible to rip the handling of trailing symlink out of link_path_walk().
That will not only simply the living hell out of it, but make life
much simpler for unionfs merge.  Trailing symlink handling will
become iterative, which is a good thing for stack footprint in
a lot of situations as well.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      5b6ca027