---

yaml
---
r: 190145
b: refs/heads/master
c: 8f4695e
h: refs/heads/master
i:
  190143: e655522
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: a2b297ff56b9bad251d11a476880a5e4614cd92f
+refs/heads/master: 8f4695ed1c9e068772bcce4cd4ff03f88d57a008

trunk/Documentation/RCU/NMI-RCU.txt

@@ -34,7 +34,7 @@ NMI handler.
 		cpu = smp_processor_id();
 		++nmi_count(cpu);
 
-		if (!rcu_dereference_sched(nmi_callback)(regs, cpu))
+		if (!rcu_dereference(nmi_callback)(regs, cpu))
 			default_do_nmi(regs);
 
 		nmi_exit();
@@ -47,13 +47,12 @@ function pointer.  If this handler returns zero, do_nmi() invokes the
 default_do_nmi() function to handle a machine-specific NMI.  Finally,
 preemption is restored.
 
-In theory, rcu_dereference_sched() is not needed, since this code runs
-only on i386, which in theory does not need rcu_dereference_sched()
-anyway.  However, in practice it is a good documentation aid, particularly
-for anyone attempting to do something similar on Alpha or on systems
-with aggressive optimizing compilers.
+Strictly speaking, rcu_dereference() is not needed, since this code runs
+only on i386, which does not need rcu_dereference() anyway.  However,
+it is a good documentation aid, particularly for anyone attempting to
+do something similar on Alpha.
 
-Quick Quiz:  Why might the rcu_dereference_sched() be necessary on Alpha,
+Quick Quiz:  Why might the rcu_dereference() be necessary on Alpha,
 	     given that the code referenced by the pointer is read-only?
 
 
@@ -100,21 +99,17 @@ invoke irq_enter() and irq_exit() on NMI entry and exit, respectively.
 
 Answer to Quick Quiz
 
-	Why might the rcu_dereference_sched() be necessary on Alpha, given
+	Why might the rcu_dereference() be necessary on Alpha, given
 	that the code referenced by the pointer is read-only?
 
 	Answer: The caller to set_nmi_callback() might well have
-		initialized some data that is to be used by the new NMI
-		handler.  In this case, the rcu_dereference_sched() would
-		be needed, because otherwise a CPU that received an NMI
-		just after the new handler was set might see the pointer
-		to the new NMI handler, but the old pre-initialized
-		version of the handler's data.
-
-		This same sad story can happen on other CPUs when using
-		a compiler with aggressive pointer-value speculation
-		optimizations.
-
-		More important, the rcu_dereference_sched() makes it
-		clear to someone reading the code that the pointer is
-		being protected by RCU-sched.
+		initialized some data that is to be used by the
+		new NMI handler.  In this case, the rcu_dereference()
+		would be needed, because otherwise a CPU that received
+		an NMI just after the new handler was set might see
+		the pointer to the new NMI handler, but the old
+		pre-initialized version of the handler's data.
+
+		More important, the rcu_dereference() makes it clear
+		to someone reading the code that the pointer is being
+		protected by RCU.

trunk/Documentation/RCU/checklist.txt

@@ -260,8 +260,7 @@ over a rather long period of time, but improvements are always welcome!
 	The reason that it is permissible to use RCU list-traversal
 	primitives when the update-side lock is held is that doing so
 	can be quite helpful in reducing code bloat when common code is
-	shared between readers and updaters.  Additional primitives
-	are provided for this case, as discussed in lockdep.txt.
+	shared between readers and updaters.
 
 10.	Conversely, if you are in an RCU read-side critical section,
 	and you don't hold the appropriate update-side lock, you -must-
@@ -345,8 +344,8 @@ over a rather long period of time, but improvements are always welcome!
 	requiring SRCU's read-side deadlock immunity or low read-side
 	realtime latency.
 
-	Note that, rcu_assign_pointer() relates to SRCU just as they do
-	to other forms of RCU.
+	Note that, rcu_assign_pointer() and rcu_dereference() relate to
+	SRCU just as they do to other forms of RCU.
 
 15.	The whole point of call_rcu(), synchronize_rcu(), and friends
 	is to wait until all pre-existing readers have finished before

trunk/Documentation/RCU/lockdep.txt

@@ -32,20 +32,9 @@ checking of rcu_dereference() primitives:
 	srcu_dereference(p, sp):
 		Check for SRCU read-side critical section.
 	rcu_dereference_check(p, c):
-		Use explicit check expression "c".  This is useful in
-		code that is invoked by both readers and updaters.
+		Use explicit check expression "c".
 	rcu_dereference_raw(p)
 		Don't check.  (Use sparingly, if at all.)
-	rcu_dereference_protected(p, c):
-		Use explicit check expression "c", and omit all barriers
-		and compiler constraints.  This is useful when the data
-		structure cannot change, for example, in code that is
-		invoked only by updaters.
-	rcu_access_pointer(p):
-		Return the value of the pointer and omit all barriers,
-		but retain the compiler constraints that prevent duplicating
-		or coalescsing.  This is useful when when testing the
-		value of the pointer itself, for example, against NULL.
 
 The rcu_dereference_check() check expression can be any boolean
 expression, but would normally include one of the rcu_read_lock_held()
@@ -70,20 +59,7 @@ In case (1), the pointer is picked up in an RCU-safe manner for vanilla
 RCU read-side critical sections, in case (2) the ->file_lock prevents
 any change from taking place, and finally, in case (3) the current task
 is the only task accessing the file_struct, again preventing any change
-from taking place.  If the above statement was invoked only from updater
-code, it could instead be written as follows:
-
-	file = rcu_dereference_protected(fdt->fd[fd],
-					 lockdep_is_held(&files->file_lock) ||
-					 atomic_read(&files->count) == 1);
-
-This would verify cases #2 and #3 above, and furthermore lockdep would
-complain if this was used in an RCU read-side critical section unless one
-of these two cases held.  Because rcu_dereference_protected() omits all
-barriers and compiler constraints, it generates better code than do the
-other flavors of rcu_dereference().  On the other hand, it is illegal
-to use rcu_dereference_protected() if either the RCU-protected pointer
-or the RCU-protected data that it points to can change concurrently.
+from taking place.
 
 There are currently only "universal" versions of the rcu_assign_pointer()
 and RCU list-/tree-traversal primitives, which do not (yet) check for

trunk/Documentation/RCU/whatisRCU.txt

@@ -840,12 +840,6 @@ SRCU:	Initialization/cleanup
 	init_srcu_struct
 	cleanup_srcu_struct
 
-All:  lockdep-checked RCU-protected pointer access
-
-	rcu_dereference_check
-	rcu_dereference_protected
-	rcu_access_pointer
-
 See the comment headers in the source code (or the docbook generated
 from them) for more information.
 

trunk/MAINTAINERS

@@ -1960,7 +1960,7 @@ F:	lib/kobj*
 
 DRM DRIVERS
 M:	David Airlie <airlied@linux.ie>
-L:	dri-devel@lists.freedesktop.org
+L:	dri-devel@lists.sourceforge.net
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
 S:	Maintained
 F:	drivers/gpu/drm/
@@ -4791,11 +4791,12 @@ F:	drivers/s390/crypto/
 
 S390 ZFCP DRIVER
 M:	Christof Schmitt <christof.schmitt@de.ibm.com>
-M:	Swen Schillig <swen@vnet.ibm.com>
+M:	Martin Peschke <mp3@de.ibm.com>
 M:	linux390@de.ibm.com
 L:	linux-s390@vger.kernel.org
 W:	http://www.ibm.com/developerworks/linux/linux390/
 S:	Supported
+F:	Documentation/s390/zfcpdump.txt
 F:	drivers/s390/scsi/zfcp_*
 
 S390 IUCV NETWORK LAYER

trunk/Makefile

@@ -1,8 +1,8 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 34
-EXTRAVERSION = -rc5
-NAME = Sheep on Meth
+EXTRAVERSION = -rc4
+NAME = Man-Eating Seals of Antiquity
 
 # *DOCUMENTATION*
 # To see a list of typical targets execute "make help"

trunk/arch/arm/include/asm/highmem.h

@@ -11,11 +11,7 @@
 
 #define kmap_prot		PAGE_KERNEL
 
-#define flush_cache_kmaps() \
-	do { \
-		if (cache_is_vivt()) \
-			flush_cache_all(); \
-	} while (0)
+#define flush_cache_kmaps()	flush_cache_all()
 
 extern pte_t *pkmap_page_table;
 
@@ -25,20 +21,11 @@ extern void *kmap_high(struct page *page);
 extern void *kmap_high_get(struct page *page);
 extern void kunmap_high(struct page *page);
 
-extern void *kmap_high_l1_vipt(struct page *page, pte_t *saved_pte);
-extern void kunmap_high_l1_vipt(struct page *page, pte_t saved_pte);
-
-/*
- * The following functions are already defined by <linux/highmem.h>
- * when CONFIG_HIGHMEM is not set.
- */
-#ifdef CONFIG_HIGHMEM
 extern void *kmap(struct page *page);
 extern void kunmap(struct page *page);
 extern void *kmap_atomic(struct page *page, enum km_type type);
 extern void kunmap_atomic(void *kvaddr, enum km_type type);
 extern void *kmap_atomic_pfn(unsigned long pfn, enum km_type type);
 extern struct page *kmap_atomic_to_page(const void *ptr);
-#endif
 
 #endif

trunk/arch/arm/include/asm/kmap_types.h

@@ -18,7 +18,6 @@ enum km_type {
 	KM_IRQ1,
 	KM_SOFTIRQ0,
 	KM_SOFTIRQ1,
-	KM_L1_CACHE,
 	KM_L2_CACHE,
 	KM_TYPE_NR
 };

trunk/arch/arm/include/asm/ucontext.h

@@ -59,22 +59,23 @@ struct iwmmxt_sigframe {
 #endif /* CONFIG_IWMMXT */
 
 #ifdef CONFIG_VFP
+#if __LINUX_ARM_ARCH__ < 6
+/* For ARM pre-v6, we use fstmiax and fldmiax.  This adds one extra
+ * word after the registers, and a word of padding at the end for
+ * alignment.  */
 #define VFP_MAGIC		0x56465001
+#define VFP_STORAGE_SIZE	152
+#else
+#define VFP_MAGIC		0x56465002
+#define VFP_STORAGE_SIZE	144
+#endif
 
 struct vfp_sigframe
 {
 	unsigned long		magic;
 	unsigned long		size;
-	struct user_vfp		ufp;
-	struct user_vfp_exc	ufp_exc;
-} __attribute__((__aligned__(8)));
-
-/*
- *  8 byte for magic and size, 264 byte for ufp, 12 bytes for ufp_exc,
- *  4 bytes padding.
- */
-#define VFP_STORAGE_SIZE	sizeof(struct vfp_sigframe)
-
+	union vfp_state		storage;
+};
 #endif /* CONFIG_VFP */
 
 /*
@@ -90,7 +91,7 @@ struct aux_sigframe {
 #ifdef CONFIG_IWMMXT
 	struct iwmmxt_sigframe	iwmmxt;
 #endif
-#ifdef CONFIG_VFP
+#if 0 && defined CONFIG_VFP /* Not yet saved.  */
 	struct vfp_sigframe	vfp;
 #endif
 	/* Something that isn't a valid magic number for any coprocessor.  */

trunk/arch/arm/include/asm/user.h

@@ -83,21 +83,11 @@ struct user{
 
 /*
  * User specific VFP registers. If only VFPv2 is present, registers 16 to 31
- * are ignored by the ptrace system call and the signal handler.
+ * are ignored by the ptrace system call.
  */
 struct user_vfp {
 	unsigned long long fpregs[32];
 	unsigned long fpscr;
 };
 
-/*
- * VFP exception registers exposed to user space during signal delivery.
- * Fields not relavant to the current VFP architecture are ignored.
- */
-struct user_vfp_exc {
-	unsigned long	fpexc;
-	unsigned long	fpinst;
-	unsigned long	fpinst2;
-};
-
 #endif /* _ARM_USER_H */