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.

From: Christoph Hellwig <hch@infradead.org>

Originally by David Mosberger, testing by Roger Luethi.  From the ia64 tree.

Basically, it avoids going to memory all the time.  What this does is make
life a lot easier for gcc, so it can actually do a decent amount of
optimization.  The restructuring clearly is less important for out-of-order
CPUs, but even there it gives some benefits.

More specifically, the loop is now structured to operate one "unsigned long"
at a time, rather than one bit at a time.  Of course, you still need to
process all the bits, but most of the relevant state in the inner loop can be
kept in registers.

Roger Luethi measured the routine on a bunch of different machines (mostly
x86, IIRC: P5, P6, Crusoe, Athlons) and performance improved there, too (and
it should definitely improve performance on any RISC-like architecture).


Roger's benchmarking results (vs number of fd's):

                                       File                   TCP
Numbfer of fd's:                  10   250  500          10   250   500

UP, Pentium MMX 233MHz original	 8.2 108.5 212.8	11.0 180.0 356.5
UP, Pentium MMX 233MHz w/patch	 7.4  87.6 171.1	10.4 163.6 323.4

MP, Pentium MMX 233MHz original	15.7 283.8 562.8	18.9 354.4 705.5
MP, Pentium MMX 233MHz w/patch	14.6 255.6 506.5	17.8 332.8 664.1

UP, Athlon 1394 MHz original	 1.3  13.4  26.1	 1.9  24.7  48.6
UP, Athlon 1394 MHz w/patch	 1.2  11.0  21.5	 1.6  22.3  43.8

MP, Athlon 1394 MHz original	 1.6  22.4  44.6	 1.9  30.9  60.5
MP, Athlon 1394 MHz w/patch	 1.5  21.2  41.7	 1.9  30.2  59.6