1. 20 11月, 2008 1 次提交
  2. 14 11月, 2008 1 次提交
  3. 23 10月, 2008 8 次提交
  4. 01 8月, 2008 2 次提交
  5. 27 7月, 2008 14 次提交
  6. 23 6月, 2008 2 次提交
  7. 17 5月, 2008 1 次提交
    • A
      [PATCH] return to old errno choice in mkdir() et.al. · e9baf6e5
      Al Viro 提交于
      	In case when both EEXIST and EROFS would apply we used to
      return the former in mkdir(2) and friends.  Lest anyone suspects
      us of being consistent, in the same situation knfsd gave clients
      nfs_erofs...
      
      	ro-bind series had switched the syscall side of things to
      returning -EROFS and immediately broke an application - namely,
      mkdir -p.  Patch restores the original behaviour...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      e9baf6e5
  8. 29 4月, 2008 1 次提交
    • S
      cgroups: implement device whitelist · 08ce5f16
      Serge E. Hallyn 提交于
      Implement a cgroup to track and enforce open and mknod restrictions on device
      files.  A device cgroup associates a device access whitelist with each cgroup.
       A whitelist entry has 4 fields.  'type' is a (all), c (char), or b (block).
      'all' means it applies to all types and all major and minor numbers.  Major
      and minor are either an integer or * for all.  Access is a composition of r
      (read), w (write), and m (mknod).
      
      The root device cgroup starts with rwm to 'all'.  A child devcg gets a copy of
      the parent.  Admins can then remove devices from the whitelist or add new
      entries.  A child cgroup can never receive a device access which is denied its
      parent.  However when a device access is removed from a parent it will not
      also be removed from the child(ren).
      
      An entry is added using devices.allow, and removed using
      devices.deny.  For instance
      
      	echo 'c 1:3 mr' > /cgroups/1/devices.allow
      
      allows cgroup 1 to read and mknod the device usually known as
      /dev/null.  Doing
      
      	echo a > /cgroups/1/devices.deny
      
      will remove the default 'a *:* mrw' entry.
      
      CAP_SYS_ADMIN is needed to change permissions or move another task to a new
      cgroup.  A cgroup may not be granted more permissions than the cgroup's parent
      has.  Any task can move itself between cgroups.  This won't be sufficient, but
      we can decide the best way to adequately restrict movement later.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix may-be-used-uninitialized warning]
      Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
      Acked-by: NJames Morris <jmorris@namei.org>
      Looks-good-to: Pavel Emelyanov <xemul@openvz.org>
      Cc: Daniel Hokka Zakrisson <daniel@hozac.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Paul Menage <menage@google.com>
      Cc: Balbir Singh <balbir@in.ibm.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      08ce5f16
  9. 19 4月, 2008 7 次提交
  10. 20 3月, 2008 1 次提交
    • R
      fs: fix kernel-doc notation warnings · a6b91919
      Randy Dunlap 提交于
      Fix kernel-doc notation warnings in fs/.
      
      Warning(mmotm-2008-0314-1449//fs/super.c:560): missing initial short description on line:
       *	mark_files_ro
      Warning(mmotm-2008-0314-1449//fs/locks.c:1277): missing initial short description on line:
       *	lease_get_mtime
      Warning(mmotm-2008-0314-1449//fs/locks.c:1277): missing initial short description on line:
       *	lease_get_mtime
      Warning(mmotm-2008-0314-1449//fs/namei.c:1368): missing initial short description on line:
       * lookup_one_len:  filesystem helper to lookup single pathname component
      Warning(mmotm-2008-0314-1449//fs/buffer.c:3221): missing initial short description on line:
       * bh_uptodate_or_lock: Test whether the buffer is uptodate
      Warning(mmotm-2008-0314-1449//fs/buffer.c:3240): missing initial short description on line:
       * bh_submit_read: Submit a locked buffer for reading
      Warning(mmotm-2008-0314-1449//fs/fs-writeback.c:30): missing initial short description on line:
       * writeback_acquire: attempt to get exclusive writeback access to a device
      Warning(mmotm-2008-0314-1449//fs/fs-writeback.c:47): missing initial short description on line:
       * writeback_in_progress: determine whether there is writeback in progress
      Warning(mmotm-2008-0314-1449//fs/fs-writeback.c:58): missing initial short description on line:
       * writeback_release: relinquish exclusive writeback access against a device.
      Warning(mmotm-2008-0314-1449//include/linux/jbd.h:351): contents before sections
      Warning(mmotm-2008-0314-1449//include/linux/jbd.h:561): contents before sections
      Warning(mmotm-2008-0314-1449//fs/jbd/transaction.c:1935): missing initial short description on line:
       * void journal_invalidatepage()
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a6b91919
  11. 19 3月, 2008 1 次提交
    • A
      [PATCH] get stack footprint of pathname resolution back to relative sanity · a02f76c3
      Al Viro 提交于
      Somebody had put struct nameidata in stack frame of link_path_walk().
      Unfortunately, there are certain realities to deal with:
      	* It's in the middle of recursion.  Depth is equal to the nesting
      depth of symlinks, i.e. up to 8.
      	* struct namiedata is, even if one discards the intent junk,
      at least 12 pointers + 5 ints.
      	* moreover, adding a stack frame is not free in that situation.
      	* there are fs methods called on top of that, and they also have
      stack footprint.
      	* kernel stack is not infinite.
      
      The thing is, even if one chooses to deal with -ESTALE that way (and it's
      one hell of an overkill), the only thing that needs to be preserved is
      vfsmount + dentry, not the entire struct nameidata.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      a02f76c3
  12. 15 2月, 2008 1 次提交