1. 22 10月, 2007 1 次提交
  2. 20 10月, 2007 2 次提交
    • K
      [JFFS2] Tidy up fix for ACL/permissions problem. · cfc8dc6f
      KaiGai Kohei 提交于
      [In commit 9ed437c5 we fixed a problem 
      with standard permissions on newly-created inodes, when POSIX ACLs are 
      enabled. This cleans it up...]
      
      The attached patch separate jffs2_init_acl() into two parts.
      
      The one is jffs2_init_acl_pre() called from jffs2_new_inode().
      It compute ACL oriented inode->i_mode bits, and allocate in-memory ACL
      objects associated with the new inode just before when inode meta
      infomation is written to the medium.
      
      The other is jffs2_init_acl_post() called from jffs2_symlink(),
      jffs2_mkdir(), jffs2_mknod() and jffs2_do_create().
      It actually writes in-memory ACL objects into the medium next to
      the success of writing meta-information.
      
      In the current implementation, we have to write a same inode meta
      infomation twice when inode->i_mode is updated by the default ACL.
      However, we can avoid the behavior by putting an updated i_mode
      before it is written at first, as jffs2_init_acl_pre() doing.
      Signed-off-by: NKaiGai Kohei <kaigai@ak.jp.nec.com>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      cfc8dc6f
    • P
      Use helpers to obtain task pid in printks · ba25f9dc
      Pavel Emelyanov 提交于
      The task_struct->pid member is going to be deprecated, so start
      using the helpers (task_pid_nr/task_pid_vnr/task_pid_nr_ns) in
      the kernel.
      
      The first thing to start with is the pid, printed to dmesg - in
      this case we may safely use task_pid_nr(). Besides, printks produce
      more (much more) than a half of all the explicit pid usage.
      
      [akpm@linux-foundation.org: git-drm went and changed lots of stuff]
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Cc: Dave Airlie <airlied@linux.ie>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ba25f9dc
  3. 17 10月, 2007 2 次提交
  4. 13 10月, 2007 6 次提交
  5. 07 10月, 2007 1 次提交
  6. 24 9月, 2007 1 次提交
  7. 03 9月, 2007 1 次提交
    • J
      [JFFS2] fix write deadlock regression · fc0e0197
      Jason Lunz 提交于
      I've bisected the deadlock when many small appends are done on jffs2 down to
      this commit:
      
      commit 6fe6900e
      Author: Nick Piggin <npiggin@suse.de>
      Date:   Sun May 6 14:49:04 2007 -0700
      
          mm: make read_cache_page synchronous
      
          Ensure pages are uptodate after returning from read_cache_page, which allows
          us to cut out most of the filesystem-internal PageUptodate calls.
      
          I didn't have a great look down the call chains, but this appears to fixes 7
          possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in
          ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in
          block2mtd.  All depending on whether the filler is async and/or can return
          with a !uptodate page.
      
      It introduced a wait to read_cache_page, as well as a
      read_cache_page_async function equivalent to the old read_cache_page
      without any callers.
      
      Switching jffs2_gc_fetch_page to read_cache_page_async for the old
      behavior makes the deadlocks go away, but maybe reintroduces the
      use-before-uptodate problem? I don't understand the mm/fs interaction
      well enough to say.
      
      [It's fine. dwmw2.]
      Signed-off-by: NJason Lunz <lunz@falooley.org>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      fc0e0197
  8. 22 8月, 2007 2 次提交
  9. 21 8月, 2007 1 次提交
  10. 09 8月, 2007 1 次提交
  11. 03 8月, 2007 4 次提交
  12. 20 7月, 2007 1 次提交
    • P
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt 提交于
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      either.
      
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      20c2df83
  13. 18 7月, 2007 2 次提交
    • S
      Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check · 3bd858ab
      Satyam Sharma 提交于
      Introduce is_owner_or_cap() macro in fs.h, and convert over relevant
      users to it. This is done because we want to avoid bugs in the future
      where we check for only effective fsuid of the current task against a
      file's owning uid, without simultaneously checking for CAP_FOWNER as
      well, thus violating its semantics.
      [ XFS uses special macros and structures, and in general looked ...
      untouchable, so we leave it alone -- but it has been looked over. ]
      
      The (current->fsuid != inode->i_uid) check in generic_permission() and
      exec_permission_lite() is left alone, because those operations are
      covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. Similarly operations
      falling under the purview of CAP_CHOWN and CAP_LEASE are also left alone.
      Signed-off-by: NSatyam Sharma <ssatyam@cse.iitk.ac.in>
      Cc: Al Viro <viro@ftp.linux.org.uk>
      Acked-by: NSerge E. Hallyn <serge@hallyn.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3bd858ab
    • R
      Freezer: make kernel threads nonfreezable by default · 83144186
      Rafael J. Wysocki 提交于
      Currently, the freezer treats all tasks as freezable, except for the kernel
      threads that explicitly set the PF_NOFREEZE flag for themselves.  This
      approach is problematic, since it requires every kernel thread to either
      set PF_NOFREEZE explicitly, or call try_to_freeze(), even if it doesn't
      care for the freezing of tasks at all.
      
      It seems better to only require the kernel threads that want to or need to
      be frozen to use some freezer-related code and to remove any
      freezer-related code from the other (nonfreezable) kernel threads, which is
      done in this patch.
      
      The patch causes all kernel threads to be nonfreezable by default (ie.  to
      have PF_NOFREEZE set by default) and introduces the set_freezable()
      function that should be called by the freezable kernel threads in order to
      unset PF_NOFREEZE.  It also makes all of the currently freezable kernel
      threads call set_freezable(), so it shouldn't cause any (intentional)
      change of behaviour to appear.  Additionally, it updates documentation to
      describe the freezing of tasks more accurately.
      
      [akpm@linux-foundation.org: build fixes]
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NNigel Cunningham <nigel@nigel.suspend2.net>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Gautham R Shenoy <ego@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      83144186
  14. 11 7月, 2007 4 次提交
  15. 10 7月, 2007 2 次提交
  16. 05 7月, 2007 1 次提交
  17. 04 7月, 2007 2 次提交
  18. 29 6月, 2007 6 次提交