Copied linux-fsdevel, as it touches the core fs code.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.613 -> 1.614
# fs/inode.c 1.69 -> 1.70
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/09/26 sds@tislabs.com 1.614
# [PATCH] LSM: inode.c init modification
#
# On Thu, 19 Sep 2002, Greg KH wrote:
#
# > Yes, and explaining the fine points of inode_init() and
# > inode_alloc_security() and why they are different, might be a bit tough.
# >
# > {sigh}, well if there's no other way (and I can't think of one right
# > now), but I really don't like it...
#
# Here's a patch that attempt to support the same functionality without
# inserting hooks into filesystem-specific code. This patch permits the
# security module to perform initialization of the inode security state
# based on the superblock information, enabling SELinux to initialize
# pipe, devpts, and shm inodes without relying on inode_precondition to
# catch them on first use.
#
# This is achieved simply by moving the initialization of inode->i_sb
# before the call to inode_alloc_security, enabling the
# inode_alloc_security hook function to perform the allocation and
# initialization for such inodes. No new hooks are required.
# --------------------------------------------
#
diff -Nru a/fs/inode.c b/fs/inode.c
--- a/fs/inode.c Thu Sep 26 13:23:52 2002
+++ b/fs/inode.c Thu Sep 26 13:23:52 2002
@@ -101,6 +101,7 @@
if (inode) {
struct address_space * const mapping = &inode->i_data;
+ inode->i_sb = sb;
inode->i_security = NULL;
if (security_ops->inode_alloc_security(inode)) {
if (inode->i_sb->s_op->destroy_inode)
@@ -109,7 +110,6 @@
kmem_cache_free(inode_cachep, (inode));
return NULL;
}
- inode->i_sb = sb;
inode->i_dev = sb->s_dev;
inode->i_blkbits = sb->s_blocksize_bits;
inode->i_flags = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 30 2002 - 22:00:28 EST