---

yaml
---
r: 112857
b: refs/heads/master
c: 730616b
h: refs/heads/master
i:
  112855: 069a380
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: ead9d23d803ea3a73766c3cb27bf7563ac8d7266
+refs/heads/master: 730616b2026838c4535c1daf9b91b118fd7caecf

trunk/Documentation/DocBook/kernel-api.tmpl

@@ -283,7 +283,6 @@ X!Earch/x86/kernel/mca_32.c
   <chapter id="security">
      <title>Security Framework</title>
 !Isecurity/security.c
-!Esecurity/inode.c
   </chapter>
 
   <chapter id="audit">

trunk/Documentation/DocBook/mac80211.tmpl

@@ -145,6 +145,7 @@ usage should require reading the full document.
         this though and the recommendation to allow only a single
         interface in STA mode at first!
       </para>
+!Finclude/net/mac80211.h ieee80211_if_types
 !Finclude/net/mac80211.h ieee80211_if_init_conf
 !Finclude/net/mac80211.h ieee80211_if_conf
     </chapter>
@@ -176,7 +177,8 @@ usage should require reading the full document.
         <title>functions/definitions</title>
 !Finclude/net/mac80211.h ieee80211_rx_status
 !Finclude/net/mac80211.h mac80211_rx_flags
-!Finclude/net/mac80211.h ieee80211_tx_info
+!Finclude/net/mac80211.h ieee80211_tx_control
+!Finclude/net/mac80211.h ieee80211_tx_status_flags
 !Finclude/net/mac80211.h ieee80211_rx
 !Finclude/net/mac80211.h ieee80211_rx_irqsafe
 !Finclude/net/mac80211.h ieee80211_tx_status
@@ -187,11 +189,12 @@ usage should require reading the full document.
 !Finclude/net/mac80211.h ieee80211_ctstoself_duration
 !Finclude/net/mac80211.h ieee80211_generic_frame_duration
 !Finclude/net/mac80211.h ieee80211_get_hdrlen_from_skb
-!Finclude/net/mac80211.h ieee80211_hdrlen
+!Finclude/net/mac80211.h ieee80211_get_hdrlen
 !Finclude/net/mac80211.h ieee80211_wake_queue
 !Finclude/net/mac80211.h ieee80211_stop_queue
-!Finclude/net/mac80211.h ieee80211_wake_queues
+!Finclude/net/mac80211.h ieee80211_start_queues
 !Finclude/net/mac80211.h ieee80211_stop_queues
+!Finclude/net/mac80211.h ieee80211_wake_queues
       </sect1>
     </chapter>
 
@@ -227,7 +230,8 @@ usage should require reading the full document.
       <title>Multiple queues and QoS support</title>
       <para>TBD</para>
 !Finclude/net/mac80211.h ieee80211_tx_queue_params
-!Finclude/net/mac80211.h ieee80211_tx_queue_stats
+!Finclude/net/mac80211.h ieee80211_tx_queue_stats_data
+!Finclude/net/mac80211.h ieee80211_tx_queue
     </chapter>
 
     <chapter id="AP">

trunk/Documentation/RCU/checklist.txt

@@ -210,7 +210,7 @@ over a rather long period of time, but improvements are always welcome!
 		number of updates per grace period.
 
 9.	All RCU list-traversal primitives, which include
-	rcu_dereference(), list_for_each_entry_rcu(),
+	rcu_dereference(), list_for_each_rcu(), list_for_each_entry_rcu(),
 	list_for_each_continue_rcu(), and list_for_each_safe_rcu(),
 	must be either within an RCU read-side critical section or
 	must be protected by appropriate update-side locks.  RCU

trunk/Documentation/RCU/rcuref.txt

@@ -29,9 +29,9 @@ release_referenced()			delete()
 					}
 
 If this list/array is made lock free using RCU as in changing the
-write_lock() in add() and delete() to spin_lock() and changing read_lock()
-in search_and_reference() to rcu_read_lock(), the atomic_inc() in
-search_and_reference() could potentially hold reference to an element which
+write_lock() in add() and delete() to spin_lock and changing read_lock
+in search_and_reference to rcu_read_lock(), the atomic_get in
+search_and_reference could potentially hold reference to an element which
 has already been deleted from the list/array.  Use atomic_inc_not_zero()
 in this scenario as follows:
 
@@ -40,20 +40,20 @@ add()					search_and_reference()
 {					{
     alloc_object			    rcu_read_lock();
     ...					    search_for_element
-    atomic_set(&el->rc, 1);		    if (!atomic_inc_not_zero(&el->rc)) {
-    spin_lock(&list_lock);		        rcu_read_unlock();
+    atomic_set(&el->rc, 1);		    if (atomic_inc_not_zero(&el->rc)) {
+    write_lock(&list_lock);		        rcu_read_unlock();
 					        return FAIL;
     add_element				    }
     ...					    ...
-    spin_unlock(&list_lock);		    rcu_read_unlock();
+    write_unlock(&list_lock);		    rcu_read_unlock();
 }					}
 3.					4.
 release_referenced()			delete()
 {					{
-    ...					    spin_lock(&list_lock);
+    ...					    write_lock(&list_lock);
     if (atomic_dec_and_test(&el->rc))       ...
         call_rcu(&el->head, el_free);       delete_element
-    ...                                     spin_unlock(&list_lock);
+    ...                                     write_unlock(&list_lock);
 } 					    ...
 					    if (atomic_dec_and_test(&el->rc))
 					        call_rcu(&el->head, el_free);

trunk/Documentation/RCU/whatisRCU.txt

@@ -786,6 +786,8 @@ RCU pointer/list traversal:
 	list_for_each_entry_rcu
 	hlist_for_each_entry_rcu
 
+	list_for_each_rcu		(to be deprecated in favor of
+					 list_for_each_entry_rcu)
 	list_for_each_continue_rcu	(to be deprecated in favor of new
 					 list_for_each_entry_continue_rcu)
 

trunk/Documentation/feature-removal-schedule.txt

@@ -6,24 +6,6 @@ be removed from this file.
 
 ---------------------------
 
-What:	old static regulatory information and ieee80211_regdom module parameter
-When:	2.6.29
-Why:	The old regulatory infrastructure has been replaced with a new one
-	which does not require statically defined regulatory domains. We do
-	not want to keep static regulatory domains in the kernel due to the
-	the dynamic nature of regulatory law and localization. We kept around
-	the old static definitions for the regulatory domains of:
-		* US
-		* JP
-		* EU
-	and used by default the US when CONFIG_WIRELESS_OLD_REGULATORY was
-	set. We also kept around the ieee80211_regdom module parameter in case
-	some applications were relying on it. Changing regulatory domains
-	can now be done instead by using nl80211, as is done with iw.
-Who:	Luis R. Rodriguez <lrodriguez@atheros.com>
-
----------------------------
-
 What:	dev->power.power_state
 When:	July 2007
 Why:	Broken design for runtime control over driver power states, confusing
@@ -250,9 +232,6 @@ What (Why):
 	- xt_mark match revision 0
 	  (superseded by xt_mark match revision 1)
 
-	- xt_recent: the old ipt_recent proc dir
-	  (superseded by /proc/net/xt_recent)
-
 When:	January 2009 or Linux 2.7.0, whichever comes first
 Why:	Superseded by newer revisions or modules
 Who:	Jan Engelhardt <jengelh@computergmbh.de>

trunk/Documentation/kernel-doc-nano-HOWTO.txt

@@ -168,10 +168,10 @@ if ($#ARGV < 0) {
 mkdir $ARGV[0],0777;
 $state = 0;
 while (<STDIN>) {
-    if (/^\.TH \"[^\"]*\" 9 \"([^\"]*)\"/) {
+    if (/^\.TH \"[^\"]*\" 4 \"([^\"]*)\"/) {
 	if ($state == 1) { close OUT }
 	$state = 1;
-	$fn = "$ARGV[0]/$1.9";
+	$fn = "$ARGV[0]/$1.4";
 	print STDERR "Creating $fn\n";
 	open OUT, ">$fn" or die "can't open $fn: $!\n";
 	print OUT $_;

trunk/Documentation/kernel-parameters.txt

@@ -284,11 +284,6 @@ and is between 256 and 4096 characters. It is defined in the file
 			isolate - enable device isolation (each device, as far
 			          as possible, will get its own protection
 			          domain)
-			fullflush - enable flushing of IO/TLB entries when
-				    they are unmapped. Otherwise they are
-				    flushed before they will be reused, which
-				    is a lot of faster
-
 	amd_iommu_size= [HW,X86-64]
 			Define the size of the aperture for the AMD IOMMU
 			driver. Possible values are:
@@ -1019,10 +1014,6 @@ and is between 256 and 4096 characters. It is defined in the file
 			(only serial suported for now)
 			Format: <serial_device>[,baud]
 
-	kmac=		[MIPS] korina ethernet MAC address.
-			Configure the RouterBoard 532 series on-chip
-			Ethernet adapter MAC address.
-
 	l2cr=		[PPC]
 
 	l3cr=		[PPC]
@@ -1428,12 +1419,6 @@ and is between 256 and 4096 characters. It is defined in the file
 
 	nolapic_timer	[X86-32,APIC] Do not use the local APIC timer.
 
-	nox2apic	[X86-64,APIC] Do not enable x2APIC mode.
-
-	x2apic_phys	[X86-64,APIC] Use x2apic physical mode instead of
-			default x2apic cluster mode on platforms
-			supporting x2apic.
-
 	noltlbs		[PPC] Do not use large page/tlb entries for kernel
 			lowmem mapping on PPC40x.
 

trunk/Documentation/networking/can.txt

@@ -35,9 +35,8 @@ This file contains
     6.1 general settings
     6.2 local loopback of sent frames
     6.3 CAN controller hardware filters
-    6.4 The virtual CAN driver (vcan)
-    6.5 currently supported CAN hardware
-    6.6 todo
+    6.4 currently supported CAN hardware
+    6.5 todo
 
   7 Credits
 
@@ -585,42 +584,7 @@ solution for a couple of reasons:
   @133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
   load without any problems ...
 
-  6.4 The virtual CAN driver (vcan)
-
-  Similar to the network loopback devices, vcan offers a virtual local
-  CAN interface. A full qualified address on CAN consists of
-
-  - a unique CAN Identifier (CAN ID)
-  - the CAN bus this CAN ID is transmitted on (e.g. can0)
-
-  so in common use cases more than one virtual CAN interface is needed.
-
-  The virtual CAN interfaces allow the transmission and reception of CAN
-  frames without real CAN controller hardware. Virtual CAN network
-  devices are usually named 'vcanX', like vcan0 vcan1 vcan2 ...
-  When compiled as a module the virtual CAN driver module is called vcan.ko
-
-  Since Linux Kernel version 2.6.24 the vcan driver supports the Kernel
-  netlink interface to create vcan network devices. The creation and
-  removal of vcan network devices can be managed with the ip(8) tool:
-
-  - Create a virtual CAN network interface:
-       ip link add type vcan
-
-  - Create a virtual CAN network interface with a specific name 'vcan42':
-       ip link add dev vcan42 type vcan
-
-  - Remove a (virtual CAN) network interface 'vcan42':
-       ip link del vcan42
-
-  The tool 'vcan' from the SocketCAN SVN repository on BerliOS is obsolete.
-
-  Virtual CAN network device creation in older Kernels:
-  In Linux Kernel versions < 2.6.24 the vcan driver creates 4 vcan
-  netdevices at module load time by default. This value can be changed
-  with the module parameter 'numdev'. E.g. 'modprobe vcan numdev=8'
-
-  6.5 currently supported CAN hardware
+  6.4 currently supported CAN hardware (September 2007)
 
   On the project website http://developer.berlios.de/projects/socketcan
   there are different drivers available:
@@ -639,7 +603,7 @@ solution for a couple of reasons:
 
   Please check the Mailing Lists on the berlios OSS project website.
 
-  6.6 todo
+  6.5 todo (September 2007)
 
   The configuration interface for CAN network drivers is still an open
   issue that has not been finalized in the socketcan project. Also the

trunk/Documentation/networking/multiqueue.txt

@@ -24,56 +24,4 @@ netif_{start|stop|wake}_subqueue() functions to manage each queue while the
 device is still operational.  netdev->queue_lock is still used when the device
 comes online or when it's completely shut down (unregister_netdev(), etc.).
 
-
-Section 2: Qdisc support for multiqueue devices
-
------------------------------------------------
-
-Currently two qdiscs are optimized for multiqueue devices.  The first is the
-default pfifo_fast qdisc.  This qdisc supports one qdisc per hardware queue.
-A new round-robin qdisc, sch_multiq also supports multiple hardware queues. The
-qdisc is responsible for classifying the skb's and then directing the skb's to
-bands and queues based on the value in skb->queue_mapping.  Use this field in
-the base driver to determine which queue to send the skb to.
-
-sch_multiq has been added for hardware that wishes to avoid head-of-line
-blocking.  It will cycle though the bands and verify that the hardware queue
-associated with the band is not stopped prior to dequeuing a packet.
-
-On qdisc load, the number of bands is based on the number of queues on the
-hardware.  Once the association is made, any skb with skb->queue_mapping set,
-will be queued to the band associated with the hardware queue.
-
-
-Section 3: Brief howto using MULTIQ for multiqueue devices
----------------------------------------------------------------
-
-The userspace command 'tc,' part of the iproute2 package, is used to configure
-qdiscs.  To add the MULTIQ qdisc to your network device, assuming the device
-is called eth0, run the following command:
-
-# tc qdisc add dev eth0 root handle 1: multiq
-
-The qdisc will allocate the number of bands to equal the number of queues that
-the device reports, and bring the qdisc online.  Assuming eth0 has 4 Tx
-queues, the band mapping would look like:
-
-band 0 => queue 0
-band 1 => queue 1
-band 2 => queue 2
-band 3 => queue 3
-
-Traffic will begin flowing through each queue based on either the simple_tx_hash
-function or based on netdev->select_queue() if you have it defined.
-
-The behavior of tc filters remains the same.  However a new tc action,
-skbedit, has been added.  Assuming you wanted to route all traffic to a
-specific host, for example 192.168.0.3, through a specific queue you could use
-this action and establish a filter such as:
-
-tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
-	match ip dst 192.168.0.3 \
-	action skbedit queue_mapping 3
-
-Author: Alexander Duyck <alexander.h.duyck@intel.com>
-Original Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com>
+Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com>