---

yaml
---
r: 333278
b: refs/heads/master
c: c0f72d7
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 49999ab27eab6289a8e4f450e148bdab521361b2
+refs/heads/master: c0f72d7cde7e289f45278c4360ce452556ccb9aa

trunk/Documentation/00-INDEX

@@ -270,6 +270,8 @@ preempt-locking.txt
 	- info on locking under a preemptive kernel.
 printk-formats.txt
 	- how to get printk format specifiers right
+prio_tree.txt
+	- info on radix-priority-search-tree use for indexing vmas.
 ramoops.txt
 	- documentation of the ramoops oops/panic logging module.
 rbtree.txt

trunk/Documentation/ABI/obsolete/proc-pid-oom_adj

@@ -0,0 +1,22 @@
+What:	/proc/<pid>/oom_adj
+When:	August 2012
+Why:	/proc/<pid>/oom_adj allows userspace to influence the oom killer's
+	badness heuristic used to determine which task to kill when the kernel
+	is out of memory.
+
+	The badness heuristic has since been rewritten since the introduction of
+	this tunable such that its meaning is deprecated.  The value was
+	implemented as a bitshift on a score generated by the badness()
+	function that did not have any precise units of measure.  With the
+	rewrite, the score is given as a proportion of available memory to the
+	task allocating pages, so using a bitshift which grows the score
+	exponentially is, thus, impossible to tune with fine granularity.
+
+	A much more powerful interface, /proc/<pid>/oom_score_adj, was
+	introduced with the oom killer rewrite that allows users to increase or
+	decrease the badness score linearly.  This interface will replace
+	/proc/<pid>/oom_adj.
+
+	A warning will be emitted to the kernel log if an application uses this
+	deprecated interface.  After it is printed once, future warnings will be
+	suppressed until the kernel is rebooted.

trunk/Documentation/ABI/testing/sysfs-block

@@ -206,17 +206,3 @@ Description:
 		when a discarded area is read the discard_zeroes_data
 		parameter will be set to one. Otherwise it will be 0 and
 		the result of reading a discarded area is undefined.
-
-What:		/sys/block/<disk>/queue/write_same_max_bytes
-Date:		January 2012
-Contact:	Martin K. Petersen <martin.petersen@oracle.com>
-Description:
-		Some devices support a write same operation in which a
-		single data block can be written to a range of several
-		contiguous blocks on storage. This can be used to wipe
-		areas on disk or to initialize drives in a RAID
-		configuration. write_same_max_bytes indicates how many
-		bytes can be written in a single write same command. If
-		write_same_max_bytes is 0, write same is not supported
-		by the device.
-

trunk/Documentation/ABI/testing/sysfs-bus-rbd

@@ -25,10 +25,6 @@ client_id
 
 	The ceph unique client id that was assigned for this specific session.
 
-features
-
-	A hexadecimal encoding of the feature bits for this image.
-
 major
 
 	The block device major number.
@@ -37,11 +33,6 @@ name
 
 	The name of the rbd image.
 
-image_id
-
-	The unique id for the rbd image.  (For rbd image format 1
-	this is empty.)
-
 pool
 
 	The name of the storage pool where this rbd image resides.
@@ -66,6 +57,12 @@ current_snap
 
 	The current snapshot for which the device is mapped.
 
+create_snap
+
+	Create a snapshot:
+
+	 $ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create
+
 snap_*
 
 	A directory per each snapshot
@@ -82,7 +79,4 @@ snap_size
 
 	The size of the image when this snapshot was taken.
 
-snap_features
-
-	A hexadecimal encoding of the feature bits for this snapshot.
 

trunk/Documentation/ABI/testing/sysfs-fs-ext4

@@ -96,16 +96,3 @@ Contact:	"Theodore Ts'o" <tytso@mit.edu>
 Description:
 		The maximum number of megabytes the writeback code will
 		try to write out before move on to another inode.
-
-What:		/sys/fs/ext4/<disk>/extent_max_zeroout_kb
-Date:		August 2012
-Contact:	"Theodore Ts'o" <tytso@mit.edu>
-Description:
-		The maximum number of kilobytes which will be zeroed
-		out in preference to creating a new uninitialized
-		extent when manipulating an inode's extent tree.  Note
-		that using a larger value will increase the
-		variability of time necessary to complete a random
-		write operation (since a 4k random write might turn
-		into a much larger write due to the zeroout
-		operation).

trunk/Documentation/DocBook/mtdnand.tmpl

@@ -1216,6 +1216,8 @@ in this page</entry>
 #define	NAND_BBT_LASTBLOCK	0x00000010
 /* The bbt is at the given page, else we must scan for the bbt */
 #define NAND_BBT_ABSPAGE	0x00000020
+/* The bbt is at the given page, else we must scan for the bbt */
+#define NAND_BBT_SEARCH		0x00000040
 /* bbt is stored per chip on multichip devices */
 #define NAND_BBT_PERCHIP	0x00000080
 /* bbt has a version counter at offset veroffs */

trunk/Documentation/block/biodoc.txt

@@ -465,6 +465,7 @@ struct bio {
        bio_end_io_t	*bi_end_io;  /* bi_end_io (bio) */
        atomic_t		bi_cnt;	     /* pin count: free when it hits zero */
        void             *bi_private;
+       bio_destructor_t *bi_destructor; /* bi_destructor (bio) */
 };
 
 With this multipage bio design:
@@ -646,6 +647,10 @@ for a non-clone bio. There are the 6 pools setup for different size biovecs,
 so bio_alloc(gfp_mask, nr_iovecs) will allocate a vec_list of the
 given size from these slabs.
 
+The bi_destructor() routine takes into account the possibility of the bio
+having originated from a different source (see later discussions on
+n/w to block transfers and kvec_cb)
+
 The bio_get() routine may be used to hold an extra reference on a bio prior
 to i/o submission, if the bio fields are likely to be accessed after the
 i/o is issued (since the bio may otherwise get freed in case i/o completion