1. 26 Mar, 2012 3 commits
  2. 01 Feb, 2011 1 commit
    • Eric Paris's avatar
      fs/vfs/security: pass last path component to LSM on inode creation · 2a7dba39
      Eric Paris authored
      SELinux would like to implement a new labeling behavior of newly created
      inodes.  We currently label new inodes based on the parent and the creating
      process.  This new behavior would also take into account the name of the
      new object when deciding the new label.  This is not the (supposed) full path,
      just the last component of the path.
      
      This is very useful because creating /etc/shadow is different than creating
      /etc/passwd but the kernel hooks are unable to differentiate these
      operations.  We currently require that userspace realize it is doing some
      difficult operation like that and than userspace jumps through SELinux hoops
      to get things set up correctly.  This patch does not implement new
      behavior, that is obviously contained in a seperate SELinux patch, but it
      does pass the needed name down to the correct LSM hook.  If no such name
      exists it is fine to pass NULL.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      2a7dba39
  3. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  4. 01 May, 2008 2 commits
  5. 22 Apr, 2008 2 commits
  6. 07 Feb, 2008 1 commit
  7. 06 Nov, 2007 1 commit
  8. 01 Nov, 2007 1 commit
    • David Woodhouse's avatar
      [JFFS2] Improve getdents vs. f_pos handling on NOR flash. · 15953580
      David Woodhouse authored
      Commit a491486a started obliterating
      dirents directly on the medium, when jffs2_can_mark_obsolete(). Removing
      them immediately from the f->dents list, however, screws up handling of
      f_pos within a directory -- because the offset is equivalent to the
      number of entries through the list we are, and the existence of
      deletion dirents served to provide 'placeholders' for unlinked
      entries. Now, 'rm -r' doesn't even manage to unlink everything in the
      directory.
      
      Revert to keeping 'deletion' dirents in the list, at least in memory
      even though we no longer write anything to the medium.
      
      Spotted, debugged and mostly fixed by Joakim Tjernlund
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      15953580
  9. 20 Oct, 2007 1 commit
    • KaiGai Kohei's avatar
      [JFFS2] Tidy up fix for ACL/permissions problem. · cfc8dc6f
      KaiGai Kohei authored
      [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: default avatarKaiGai Kohei <kaigai@ak.jp.nec.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      cfc8dc6f
  10. 13 Oct, 2007 1 commit
  11. 21 Aug, 2007 1 commit
  12. 02 Aug, 2007 2 commits
  13. 29 Jun, 2007 1 commit
  14. 28 Jun, 2007 1 commit
  15. 25 Apr, 2007 1 commit
    • David Woodhouse's avatar
      [JFFS2] Tidy up licensing/copyright boilerplate. · c00c310e
      David Woodhouse authored
      In particular, remove the bit in the LICENCE file about contacting
      Red Hat for alternative arrangements. Their errant IS department broke
      that arrangement a long time ago -- the policy of collecting copyright
      assignments from contributors came to an end when the plug was pulled on
      the servers hosting the project, without notice or reason.
      
      We do still dual-license it for use with eCos, with the GPL+exception
      licence approved by the FSF as being GPL-compatible. It's just that nobody
      has the right to license it differently.
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      c00c310e
  16. 21 Apr, 2007 1 commit
  17. 24 May, 2006 1 commit
    • David Woodhouse's avatar
      [JFFS2] Reduce visibility of raw_node_ref to upper layers of JFFS2 code. · 2f785402
      David Woodhouse authored
      As the first step towards eliminating the ref->next_phys member and saving
      memory by using an _array_ of struct jffs2_raw_node_ref per eraseblock,
      stop the write functions from allocating their own refs; have them just
      _reserve_ the appropriate number instead. Then jffs2_link_node_ref() can
      just fill them in.
      
      Use a linked list of pre-allocated refs in the superblock, for now. Once
      we switch to an array, it'll just be a case of extending that array.
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      2f785402
  18. 22 May, 2006 2 commits
  19. 21 May, 2006 1 commit
  20. 13 May, 2006 2 commits
    • KaiGai Kohei's avatar
      [JFFS2][XATTR] Remove 'struct list_head ilist' from jffs2_inode_cache. · 8f2b6f49
      KaiGai Kohei authored
      This patch can reduce 4-byte of memory usage per inode_cache.
      
      [4/10] jffs2-xattr-v5.1-04-remove_ilist_from_ic.patch
      Signed-off-by: default avatarKaiGai Kohei <kaigai@ak.jp.nec.com>
      8f2b6f49
    • KaiGai Kohei's avatar
      [JFFS2][XATTR] XATTR support on JFFS2 (version. 5) · aa98d7cf
      KaiGai Kohei authored
      This attached patches provide xattr support including POSIX-ACL and
      SELinux support on JFFS2 (version.5).
      
      There are some significant differences from previous version posted
      at last December.
      The biggest change is addition of EBS(Erase Block Summary) support.
      Currently, both kernel and usermode utility (sumtool) can recognize
      xattr nodes which have JFFS2_NODETYPE_XATTR/_XREF nodetype.
      
      In addition, some bugs are fixed.
      - A potential race condition was fixed.
      - Unexpected fail when updating a xattr by same name/value pair was fixed.
      - A bug when removing xattr name/value pair was fixed.
      
      The fundamental structures (such as using two new nodetypes and exclusion
      mechanism by rwsem) are unchanged. But most of implementation were reviewed
      and updated if necessary.
      Espacially, we had to change several internal implementations related to
      load_xattr_datum() to avoid a potential race condition.
      
      [1/2] xattr_on_jffs2.kernel.version-5.patch
      [2/2] xattr_on_jffs2.utils.version-5.patch
      Signed-off-by: default avatarKaiGai Kohei <kaigai@ak.jp.nec.com>
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      aa98d7cf
  21. 07 Nov, 2005 1 commit
  22. 06 Nov, 2005 4 commits
  23. 23 May, 2005 4 commits
  24. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4