Merge branch 'master' of /home/trondmy/kernel/linux-2.6/

		for most of the implementations. These functions can be replaced by the

		board driver if neccecary. Those functions are called via pointers in the

		NAND chip description structure. The board driver can set the functions which

		should be replaced by board dependend functions before calling nand_scan().

		should be replaced by board dependent functions before calling nand_scan().

		If the function pointer is NULL on entry to nand_scan() then the pointer

		is set to the default function which is suitable for the detected chip type.

		</para></listitem>

	  	[REPLACEABLE]</para><para>

		Replaceable members hold hardware related functions which can be 

		provided by the board driver. The board driver can set the functions which

		should be replaced by board dependend functions before calling nand_scan().

		should be replaced by board dependent functions before calling nand_scan().

		If the function pointer is NULL on entry to nand_scan() then the pointer

		is set to the default function which is suitable for the detected chip type.

		</para></listitem>

     	<title>Basic board driver</title>

	<para>

		For most boards it will be sufficient to provide just the

		basic functions and fill out some really board dependend

		basic functions and fill out some really board dependent

		members in the nand chip description structure.

		See drivers/mtd/nand/skeleton for reference.

	</para>

	<sect1>

		<title>Basic defines</title>

     </para>

!Idrivers/mtd/nand/nand_base.c

!Idrivers/mtd/nand/nand_bbt.c

!Idrivers/mtd/nand/nand_ecc.c

<!-- No internal functions for kernel-doc:

X!Idrivers/mtd/nand/nand_ecc.c

-->

  </chapter>

  <chapter id="credits">

IRQ-flags state tracing

started by Ingo Molnar <mingo@redhat.com>

the "irq-flags tracing" feature "traces" hardirq and softirq state, in

that it gives interested subsystems an opportunity to be notified of

every hardirqs-off/hardirqs-on, softirqs-off/softirqs-on event that

happens in the kernel.

CONFIG_TRACE_IRQFLAGS_SUPPORT is needed for CONFIG_PROVE_SPIN_LOCKING

and CONFIG_PROVE_RW_LOCKING to be offered by the generic lock debugging

code. Otherwise only CONFIG_PROVE_MUTEX_LOCKING and

CONFIG_PROVE_RWSEM_LOCKING will be offered on an architecture - these

are locking APIs that are not used in IRQ context. (the one exception

for rwsems is worked around)

architecture support for this is certainly not in the "trivial"

category, because lots of lowlevel assembly code deal with irq-flags

state changes. But an architecture can be irq-flags-tracing enabled in a

rather straightforward and risk-free manner.

Architectures that want to support this need to do a couple of

code-organizational changes first:

- move their irq-flags manipulation code from their asm/system.h header

  to asm/irqflags.h

- rename local_irq_disable()/etc to raw_local_irq_disable()/etc. so that

  the linux/irqflags.h code can inject callbacks and can construct the

  real local_irq_disable()/etc APIs.

- add and enable TRACE_IRQFLAGS_SUPPORT in their arch level Kconfig file

and then a couple of functional changes are needed as well to implement

irq-flags-tracing support:

- in lowlevel entry code add (build-conditional) calls to the

  trace_hardirqs_off()/trace_hardirqs_on() functions. The lock validator

  closely guards whether the 'real' irq-flags matches the 'virtual'

  irq-flags state, and complains loudly (and turns itself off) if the

  two do not match. Usually most of the time for arch support for

  irq-flags-tracing is spent in this state: look at the lockdep

  complaint, try to figure out the assembly code we did not cover yet,

  fix and repeat. Once the system has booted up and works without a

  lockdep complaint in the irq-flags-tracing functions arch support is

  complete.

- if the architecture has non-maskable interrupts then those need to be

  excluded from the irq-tracing [and lock validation] mechanism via

  lockdep_off()/lockdep_on().

in general there is no risk from having an incomplete irq-flags-tracing

implementation in an architecture: lockdep will detect that and will

turn itself off. I.e. the lock validator will still be reliable. There

should be no crashes due to irq-tracing bugs. (except if the assembly

changes break other code by modifying conditions or registers that

shouldnt be)

	debug		[KNL] Enable kernel debugging (events log level).

	debug_locks_verbose=

			[KNL] verbose self-tests

			Format=<0|1>

			Print debugging info while doing the locking API

			self-tests.

			We default to 0 (no extra messages), setting it to

			1 will print _a lot_ more information - normally

			only useful to kernel developers.

	decnet=		[HW,NET]

			Format: <area>[,<node>]

			See also Documentation/networking/decnet.txt.

Runtime locking correctness validator

=====================================

started by Ingo Molnar <mingo@redhat.com>

additions by Arjan van de Ven <arjan@linux.intel.com>

Lock-class

----------

The basic object the validator operates upon is a 'class' of locks.

A class of locks is a group of locks that are logically the same with

respect to locking rules, even if the locks may have multiple (possibly

tens of thousands of) instantiations. For example a lock in the inode

struct is one class, while each inode has its own instantiation of that

lock class.

The validator tracks the 'state' of lock-classes, and it tracks

dependencies between different lock-classes. The validator maintains a

rolling proof that the state and the dependencies are correct.

Unlike an lock instantiation, the lock-class itself never goes away: when

a lock-class is used for the first time after bootup it gets registered,

and all subsequent uses of that lock-class will be attached to this

lock-class.

State

-----

The validator tracks lock-class usage history into 5 separate state bits:

- 'ever held in hardirq context'                    [ == hardirq-safe   ]

- 'ever held in softirq context'                    [ == softirq-safe   ]

- 'ever held with hardirqs enabled'                 [ == hardirq-unsafe ]

- 'ever held with softirqs and hardirqs enabled'    [ == softirq-unsafe ]

- 'ever used'                                       [ == !unused        ]

Single-lock state rules:

------------------------

A softirq-unsafe lock-class is automatically hardirq-unsafe as well. The

following states are exclusive, and only one of them is allowed to be

set for any lock-class:

 <hardirq-safe> and <hardirq-unsafe>

 <softirq-safe> and <softirq-unsafe>

The validator detects and reports lock usage that violate these

single-lock state rules.

Multi-lock dependency rules:

----------------------------

The same lock-class must not be acquired twice, because this could lead

to lock recursion deadlocks.

Furthermore, two locks may not be taken in different order:

 <L1> -> <L2>

 <L2> -> <L1>

because this could lead to lock inversion deadlocks. (The validator

finds such dependencies in arbitrary complexity, i.e. there can be any

other locking sequence between the acquire-lock operations, the

validator will still track all dependencies between locks.)

Furthermore, the following usage based lock dependencies are not allowed

between any two lock-classes:

   <hardirq-safe>   ->  <hardirq-unsafe>

   <softirq-safe>   ->  <softirq-unsafe>

The first rule comes from the fact the a hardirq-safe lock could be

taken by a hardirq context, interrupting a hardirq-unsafe lock - and

thus could result in a lock inversion deadlock. Likewise, a softirq-safe

lock could be taken by an softirq context, interrupting a softirq-unsafe

lock.

The above rules are enforced for any locking sequence that occurs in the

kernel: when acquiring a new lock, the validator checks whether there is

any rule violation between the new lock and any of the held locks.

When a lock-class changes its state, the following aspects of the above

dependency rules are enforced:

- if a new hardirq-safe lock is discovered, we check whether it

  took any hardirq-unsafe lock in the past.

- if a new softirq-safe lock is discovered, we check whether it took

  any softirq-unsafe lock in the past.

- if a new hardirq-unsafe lock is discovered, we check whether any

  hardirq-safe lock took it in the past.

- if a new softirq-unsafe lock is discovered, we check whether any

  softirq-safe lock took it in the past.

(Again, we do these checks too on the basis that an interrupt context

could interrupt _any_ of the irq-unsafe or hardirq-unsafe locks, which

could lead to a lock inversion deadlock - even if that lock scenario did

not trigger in practice yet.)

Exception: Nested data dependencies leading to nested locking

-------------------------------------------------------------

There are a few cases where the Linux kernel acquires more than one

instance of the same lock-class. Such cases typically happen when there

is some sort of hierarchy within objects of the same type. In these

cases there is an inherent "natural" ordering between the two objects

(defined by the properties of the hierarchy), and the kernel grabs the

locks in this fixed order on each of the objects.

An example of such an object hieararchy that results in "nested locking"

is that of a "whole disk" block-dev object and a "partition" block-dev

object; the partition is "part of" the whole device and as long as one

always takes the whole disk lock as a higher lock than the partition

lock, the lock ordering is fully correct. The validator does not

automatically detect this natural ordering, as the locking rule behind

the ordering is not static.

In order to teach the validator about this correct usage model, new

versions of the various locking primitives were added that allow you to

specify a "nesting level". An example call, for the block device mutex,

looks like this:

enum bdev_bd_mutex_lock_class

{

       BD_MUTEX_NORMAL,

       BD_MUTEX_WHOLE,

       BD_MUTEX_PARTITION

};

 mutex_lock_nested(&bdev->bd_contains->bd_mutex, BD_MUTEX_PARTITION);

In this case the locking is done on a bdev object that is known to be a

partition.

The validator treats a lock that is taken in such a nested fasion as a

separate (sub)class for the purposes of validation.

Note: When changing code to use the _nested() primitives, be careful and

check really thoroughly that the hiearchy is correctly mapped; otherwise

you can get false positives or false negatives.

Proof of 100% correctness:

--------------------------

The validator achieves perfect, mathematical 'closure' (proof of locking

correctness) in the sense that for every simple, standalone single-task

locking sequence that occured at least once during the lifetime of the

kernel, the validator proves it with a 100% certainty that no

combination and timing of these locking sequences can cause any class of

lock related deadlock. [*]

I.e. complex multi-CPU and multi-task locking scenarios do not have to

occur in practice to prove a deadlock: only the simple 'component'

locking chains have to occur at least once (anytime, in any

task/context) for the validator to be able to prove correctness. (For

example, complex deadlocks that would normally need more than 3 CPUs and

a very unlikely constellation of tasks, irq-contexts and timings to

occur, can be detected on a plain, lightly loaded single-CPU system as

well!)

This radically decreases the complexity of locking related QA of the

kernel: what has to be done during QA is to trigger as many "simple"

single-task locking dependencies in the kernel as possible, at least

once, to prove locking correctness - instead of having to trigger every

possible combination of locking interaction between CPUs, combined with

every possible hardirq and softirq nesting scenario (which is impossible

to do in practice).

[*] assuming that the validator itself is 100% correct, and no other

    part of the system corrupts the state of the validator in any way.

    We also assume that all NMI/SMM paths [which could interrupt

    even hardirq-disabled codepaths] are correct and do not interfere

    with the validator. We also assume that the 64-bit 'chain hash'

    value is unique for every lock-chain in the system. Also, lock

    recursion must not be higher than 20.

Performance:

------------

The above rules require _massive_ amounts of runtime checking. If we did

that for every lock taken and for every irqs-enable event, it would

render the system practically unusably slow. The complexity of checking

is O(N^2), so even with just a few hundred lock-classes we'd have to do

tens of thousands of checks for every event.

This problem is solved by checking any given 'locking scenario' (unique

sequence of locks taken after each other) only once. A simple stack of

held locks is maintained, and a lightweight 64-bit hash value is

calculated, which hash is unique for every lock chain. The hash value,

when the chain is validated for the first time, is then put into a hash

table, which hash-table can be checked in a lockfree manner. If the

locking chain occurs again later on, the hash table tells us that we

dont have to validate the chain again.

/proc/sys/net/ipv4/vs/* Variables:

am_droprate - INTEGER

        default 10

        It sets the always mode drop rate, which is used in the mode 3

        of the drop_rate defense.

amemthresh - INTEGER

        default 1024

        It sets the available memory threshold (in pages), which is

        used in the automatic modes of defense. When there is no

        enough available memory, the respective strategy will be

        enabled and the variable is automatically set to 2, otherwise

        the strategy is disabled and the variable is  set  to 1.

cache_bypass - BOOLEAN

        0 - disabled (default)

        not 0 - enabled

        If it is enabled, forward packets to the original destination

        directly when no cache server is available and destination

        address is not local (iph->daddr is RTN_UNICAST). It is mostly

        used in transparent web cache cluster.

debug_level - INTEGER

	0          - transmission error messages (default)

	1          - non-fatal error messages

	2          - configuration

	3          - destination trash

	4          - drop entry

	5          - service lookup

	6          - scheduling

	7          - connection new/expire, lookup and synchronization

	8          - state transition

	9          - binding destination, template checks and applications

	10         - IPVS packet transmission

	11         - IPVS packet handling (ip_vs_in/ip_vs_out)

	12 or more - packet traversal

	Only available when IPVS is compiled with the CONFIG_IPVS_DEBUG

	Higher debugging levels include the messages for lower debugging

	levels, so setting debug level 2, includes level 0, 1 and 2

	messages. Thus, logging becomes more and more verbose the higher

	the level.

drop_entry - INTEGER

        0  - disabled (default)

        The drop_entry defense is to randomly drop entries in the

        connection hash table, just in order to collect back some

        memory for new connections. In the current code, the

        drop_entry procedure can be activated every second, then it

        randomly scans 1/32 of the whole and drops entries that are in

        the SYN-RECV/SYNACK state, which should be effective against

        syn-flooding attack.

        The valid values of drop_entry are from 0 to 3, where 0 means

        that this strategy is always disabled, 1 and 2 mean automatic

        modes (when there is no enough available memory, the strategy

        is enabled and the variable is automatically set to 2,

        otherwise the strategy is disabled and the variable is set to

        1), and 3 means that that the strategy is always enabled.

drop_packet - INTEGER

        0  - disabled (default)

        The drop_packet defense is designed to drop 1/rate packets

        before forwarding them to real servers. If the rate is 1, then

        drop all the incoming packets.

        The value definition is the same as that of the drop_entry. In

        the automatic mode, the rate is determined by the follow

        formula: rate = amemthresh / (amemthresh - available_memory)

        when available memory is less than the available memory

        threshold. When the mode 3 is set, the always mode drop rate

        is controlled by the /proc/sys/net/ipv4/vs/am_droprate.

expire_nodest_conn - BOOLEAN

        0 - disabled (default)

        not 0 - enabled

        The default value is 0, the load balancer will silently drop

        packets when its destination server is not available. It may

        be useful, when user-space monitoring program deletes the

        destination server (because of server overload or wrong

        detection) and add back the server later, and the connections

        to the server can continue.

        If this feature is enabled, the load balancer will expire the

        connection immediately when a packet arrives and its

        destination server is not available, then the client program

        will be notified that the connection is closed. This is

        equivalent to the feature some people requires to flush

        connections when its destination is not available.

expire_quiescent_template - BOOLEAN

	0 - disabled (default)

	not 0 - enabled

	When set to a non-zero value, the load balancer will expire

	persistent templates when the destination server is quiescent.

	This may be useful, when a user makes a destination server

	quiescent by setting its weight to 0 and it is desired that

	subsequent otherwise persistent connections are sent to a

	different destination server.  By default new persistent

	connections are allowed to quiescent destination servers.

	If this feature is enabled, the load balancer will expire the

	persistence template if it is to be used to schedule a new

	connection and the destination server is quiescent.

nat_icmp_send - BOOLEAN

        0 - disabled (default)

        not 0 - enabled

        It controls sending icmp error messages (ICMP_DEST_UNREACH)

        for VS/NAT when the load balancer receives packets from real

        servers but the connection entries don't exist.

secure_tcp - INTEGER

        0  - disabled (default)

        The secure_tcp defense is to use a more complicated state

        transition table and some possible short timeouts of each

        state. In the VS/NAT, it delays the entering the ESTABLISHED

        until the real server starts to send data and ACK packet

        (after 3-way handshake).

        The value definition is the same as that of drop_entry or

        drop_packet.

sync_threshold - INTEGER

        default 3

        It sets synchronization threshold, which is the minimum number

        of incoming packets that a connection needs to receive before

        the connection will be synchronized. A connection will be

        synchronized, every time the number of its incoming packets

        modulus 50 equals the threshold. The range of the threshold is

        from 0 to 49.