Skip to main content

Browse the archive

Revision 8682164a66325cab07620082eb7f413b547f4b4a authored by Evgeniy Dushistov on 29 January 2007, 21:19:55 UTC, committed by Linus Torvalds on 30 January 2007, 16:26:45 UTC 
[PATCH] ufs: truncate negative to unsigned fix
 
During ufs_trunc_direct which is subroutine of ufs::truncate, we try the first
of all free parts of block and then whole blocks.  But we calculate size of
block's part to free in the wrong way.

This may cause bad update of used blocks and fragments statistic, and you can
got report that you have free 32T on 1Gb partition.

Signed-off-by: Evgeniy Dushistov <dushistov@mail.ru>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
1 parent a685e26
Raw File
introduction.txt 
NetLabel Introduction
==============================================================================
Paul Moore, paul.moore@hp.com

August 2, 2006

 * Overview

NetLabel is a mechanism which can be used by kernel security modules to attach
security attributes to outgoing network packets generated from user space
applications and read security attributes from incoming network packets.  It
is composed of three main components, the protocol engines, the communication
layer, and the kernel security module API.

 * Protocol Engines

The protocol engines are responsible for both applying and retrieving the
network packet's security attributes.  If any translation between the network
security attributes and those on the host are required then the protocol
engine will handle those tasks as well.  Other kernel subsystems should
refrain from calling the protocol engines directly, instead they should use
the NetLabel kernel security module API described below.

Detailed information about each NetLabel protocol engine can be found in this
directory, consult '00-INDEX' for filenames.

 * Communication Layer

The communication layer exists to allow NetLabel configuration and monitoring
from user space.  The NetLabel communication layer uses a message based
protocol built on top of the Generic NETLINK transport mechanism.  The exact
formatting of these NetLabel messages as well as the Generic NETLINK family
names can be found in the the 'net/netlabel/' directory as comments in the
header files as well as in 'include/net/netlabel.h'.

 * Security Module API

The purpose of the NetLabel security module API is to provide a protocol
independent interface to the underlying NetLabel protocol engines.  In addition
to protocol independence, the security module API is designed to be completely
LSM independent which should allow multiple LSMs to leverage the same code
base.

Detailed information about the NetLabel security module API can be found in the
'include/net/netlabel.h' header file as well as the 'lsm_interface.txt' file
found in this directory.
back to top