into nuts.ninka.net:/home/davem/src/BK/net-2.5

into kernel.bkbits.net:/home/davem/net-2.5

into nuts.ninka.net:/home/davem/src/BK/net-2.5

into nuts.ninka.net:/home/davem/src/BK/sctp-2.5

into nuts.ninka.net:/home/davem/src/BK/net-2.5

Thanks to Al Viro for pointing out these problems.

into kroah.com:/home/linux/linux/BK/gregkh-2.5

From: Grzegorz Jaskiewicz <gj@pointblue.com.pl>

gcc-2.94 fails to compile this code, alleging an invalid lvalue.
An equivalent transformation fixes it up.

From: Stephen Smalley <sds@epoch.ncsc.mil>

This patch against 2.5.69 adds a security_inode_post_setxattr hook so that
security modules can update the inode security structure after a successful
setxattr, and it moves the existing security_inode_setxattr hook call after
the taking the inode semaphore so that atomicity is provided for the
security check and the update to the inode security structure.

From: Stephen Smalley <sds@epoch.ncsc.mil>

This patch against 2.5.68 implements an xattr handler for ext2 to support the
use of extended attributes by security modules for storing file security
labels.  As per the earlier discussion of extended attributes for security
modules, this handler uses a "security." prefix and allows for per-module
attribute names.  Security checking on userspace access to these attributes
can be performed by the security module using the LSM hooks in fs/xattr.c,
and the security module is free to internally use the inode operations
without restriction for managing its security labels.  Unlike the trusted
namespace, these labels are used internally for access control purposes by
the security module, and controls over userspace access to them require finer
granularity than capable() supports.

From: Stephen Smalley <sds@epoch.ncsc.mil>

This patch against 2.5.68 implements an xattr handler for ext3 to support the
use of extended attributes by security modules for storing file security
labels.  As per the earlier discussion of extended attributes for security
modules, this handler uses a "security." prefix and allows for per-module
attribute names.  Security checking for userspace access to these attributes
can be performed by the security module using the LSM hooks in fs/xattr.c,
and the security module is free to internally use the inode operations
without restriction for managing its security labels.  Unlike the trusted
namespace, these labels are used internally for access control purposes by
the security modules, and controls over userspace access to them require
finer granularity than capable() supports.

From: Stephen Smalley <sds@epoch.ncsc.mil>

This patch moves the security_d_instantiate hook calls in d_instantiate and
d_splice_alias after the inode has been attached to the dentry.  This
change is necessary so that security modules can internally call the
getxattr inode operation (which takes a dentry parameter) from this hook to
obtain the inode security label.