Skip to content

Commit 0ffbe26

Browse files
author
James Morris
committed
Merge branch 'master' into next
2 parents 4e5d6f7 + 7ebd467 commit 0ffbe26

5,014 files changed

Lines changed: 37774 additions & 10386 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

Documentation/DocBook/tracepoint.tmpl

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,15 @@
1616
</address>
1717
</affiliation>
1818
</author>
19+
<author>
20+
<firstname>William</firstname>
21+
<surname>Cohen</surname>
22+
<affiliation>
23+
<address>
24+
<email>wcohen@redhat.com</email>
25+
</address>
26+
</affiliation>
27+
</author>
1928
</authorgroup>
2029

2130
<legalnotice>
@@ -91,4 +100,8 @@
91100
!Iinclude/trace/events/signal.h
92101
</chapter>
93102
103+
<chapter id="block">
104+
<title>Block IO</title>
105+
!Iinclude/trace/events/block.h
106+
</chapter>
94107
</book>

Documentation/HOWTO

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -234,7 +234,7 @@ process is as follows:
234234
Linus, usually the patches that have already been included in the
235235
-next kernel for a few weeks. The preferred way to submit big changes
236236
is using git (the kernel's source management tool, more information
237-
can be found at http://git.or.cz/) but plain patches are also just
237+
can be found at http://git-scm.com/) but plain patches are also just
238238
fine.
239239
- After two weeks a -rc1 kernel is released it is now possible to push
240240
only patches that do not include new features that could affect the

Documentation/RCU/NMI-RCU.txt

Lines changed: 22 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -34,7 +34,7 @@ NMI handler.
3434
cpu = smp_processor_id();
3535
++nmi_count(cpu);
3636

37-
if (!rcu_dereference(nmi_callback)(regs, cpu))
37+
if (!rcu_dereference_sched(nmi_callback)(regs, cpu))
3838
default_do_nmi(regs);
3939

4040
nmi_exit();
@@ -47,12 +47,13 @@ function pointer. If this handler returns zero, do_nmi() invokes the
4747
default_do_nmi() function to handle a machine-specific NMI. Finally,
4848
preemption is restored.
4949

50-
Strictly speaking, rcu_dereference() is not needed, since this code runs
51-
only on i386, which does not need rcu_dereference() anyway. However,
52-
it is a good documentation aid, particularly for anyone attempting to
53-
do something similar on Alpha.
50+
In theory, rcu_dereference_sched() is not needed, since this code runs
51+
only on i386, which in theory does not need rcu_dereference_sched()
52+
anyway. However, in practice it is a good documentation aid, particularly
53+
for anyone attempting to do something similar on Alpha or on systems
54+
with aggressive optimizing compilers.
5455

55-
Quick Quiz: Why might the rcu_dereference() be necessary on Alpha,
56+
Quick Quiz: Why might the rcu_dereference_sched() be necessary on Alpha,
5657
given that the code referenced by the pointer is read-only?
5758

5859

@@ -99,17 +100,21 @@ invoke irq_enter() and irq_exit() on NMI entry and exit, respectively.
99100

100101
Answer to Quick Quiz
101102

102-
Why might the rcu_dereference() be necessary on Alpha, given
103+
Why might the rcu_dereference_sched() be necessary on Alpha, given
103104
that the code referenced by the pointer is read-only?
104105

105106
Answer: The caller to set_nmi_callback() might well have
106-
initialized some data that is to be used by the
107-
new NMI handler. In this case, the rcu_dereference()
108-
would be needed, because otherwise a CPU that received
109-
an NMI just after the new handler was set might see
110-
the pointer to the new NMI handler, but the old
111-
pre-initialized version of the handler's data.
112-
113-
More important, the rcu_dereference() makes it clear
114-
to someone reading the code that the pointer is being
115-
protected by RCU.
107+
initialized some data that is to be used by the new NMI
108+
handler. In this case, the rcu_dereference_sched() would
109+
be needed, because otherwise a CPU that received an NMI
110+
just after the new handler was set might see the pointer
111+
to the new NMI handler, but the old pre-initialized
112+
version of the handler's data.
113+
114+
This same sad story can happen on other CPUs when using
115+
a compiler with aggressive pointer-value speculation
116+
optimizations.
117+
118+
More important, the rcu_dereference_sched() makes it
119+
clear to someone reading the code that the pointer is
120+
being protected by RCU-sched.

Documentation/RCU/checklist.txt

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -260,7 +260,8 @@ over a rather long period of time, but improvements are always welcome!
260260
The reason that it is permissible to use RCU list-traversal
261261
primitives when the update-side lock is held is that doing so
262262
can be quite helpful in reducing code bloat when common code is
263-
shared between readers and updaters.
263+
shared between readers and updaters. Additional primitives
264+
are provided for this case, as discussed in lockdep.txt.
264265

265266
10. Conversely, if you are in an RCU read-side critical section,
266267
and you don't hold the appropriate update-side lock, you -must-
@@ -344,8 +345,8 @@ over a rather long period of time, but improvements are always welcome!
344345
requiring SRCU's read-side deadlock immunity or low read-side
345346
realtime latency.
346347

347-
Note that, rcu_assign_pointer() and rcu_dereference() relate to
348-
SRCU just as they do to other forms of RCU.
348+
Note that, rcu_assign_pointer() relates to SRCU just as they do
349+
to other forms of RCU.
349350

350351
15. The whole point of call_rcu(), synchronize_rcu(), and friends
351352
is to wait until all pre-existing readers have finished before

Documentation/RCU/lockdep.txt

Lines changed: 26 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -32,9 +32,20 @@ checking of rcu_dereference() primitives:
3232
srcu_dereference(p, sp):
3333
Check for SRCU read-side critical section.
3434
rcu_dereference_check(p, c):
35-
Use explicit check expression "c".
35+
Use explicit check expression "c". This is useful in
36+
code that is invoked by both readers and updaters.
3637
rcu_dereference_raw(p)
3738
Don't check. (Use sparingly, if at all.)
39+
rcu_dereference_protected(p, c):
40+
Use explicit check expression "c", and omit all barriers
41+
and compiler constraints. This is useful when the data
42+
structure cannot change, for example, in code that is
43+
invoked only by updaters.
44+
rcu_access_pointer(p):
45+
Return the value of the pointer and omit all barriers,
46+
but retain the compiler constraints that prevent duplicating
47+
or coalescsing. This is useful when when testing the
48+
value of the pointer itself, for example, against NULL.
3849

3950
The rcu_dereference_check() check expression can be any boolean
4051
expression, but would normally include one of the rcu_read_lock_held()
@@ -59,7 +70,20 @@ In case (1), the pointer is picked up in an RCU-safe manner for vanilla
5970
RCU read-side critical sections, in case (2) the ->file_lock prevents
6071
any change from taking place, and finally, in case (3) the current task
6172
is the only task accessing the file_struct, again preventing any change
62-
from taking place.
73+
from taking place. If the above statement was invoked only from updater
74+
code, it could instead be written as follows:
75+
76+
file = rcu_dereference_protected(fdt->fd[fd],
77+
lockdep_is_held(&files->file_lock) ||
78+
atomic_read(&files->count) == 1);
79+
80+
This would verify cases #2 and #3 above, and furthermore lockdep would
81+
complain if this was used in an RCU read-side critical section unless one
82+
of these two cases held. Because rcu_dereference_protected() omits all
83+
barriers and compiler constraints, it generates better code than do the
84+
other flavors of rcu_dereference(). On the other hand, it is illegal
85+
to use rcu_dereference_protected() if either the RCU-protected pointer
86+
or the RCU-protected data that it points to can change concurrently.
6387

6488
There are currently only "universal" versions of the rcu_assign_pointer()
6589
and RCU list-/tree-traversal primitives, which do not (yet) check for

Documentation/RCU/whatisRCU.txt

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -840,6 +840,12 @@ SRCU: Initialization/cleanup
840840
init_srcu_struct
841841
cleanup_srcu_struct
842842

843+
All: lockdep-checked RCU-protected pointer access
844+
845+
rcu_dereference_check
846+
rcu_dereference_protected
847+
rcu_access_pointer
848+
843849
See the comment headers in the source code (or the docbook generated
844850
from them) for more information.
845851

Documentation/block/biodoc.txt

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1162,8 +1162,8 @@ where a driver received a request ala this before:
11621162

11631163
As mentioned, there is no virtual mapping of a bio. For DMA, this is
11641164
not a problem as the driver probably never will need a virtual mapping.
1165-
Instead it needs a bus mapping (pci_map_page for a single segment or
1166-
use blk_rq_map_sg for scatter gather) to be able to ship it to the driver. For
1165+
Instead it needs a bus mapping (dma_map_page for a single segment or
1166+
use dma_map_sg for scatter gather) to be able to ship it to the driver. For
11671167
PIO drivers (or drivers that need to revert to PIO transfer once in a
11681168
while (IDE for example)), where the CPU is doing the actual data
11691169
transfer a virtual mapping is needed. If the driver supports highmem I/O,

Documentation/cgroups/cgroups.txt

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -235,8 +235,7 @@ containing the following files describing that cgroup:
235235
- cgroup.procs: list of tgids in the cgroup. This list is not
236236
guaranteed to be sorted or free of duplicate tgids, and userspace
237237
should sort/uniquify the list if this property is required.
238-
Writing a tgid into this file moves all threads with that tgid into
239-
this cgroup.
238+
This is a read-only file, for now.
240239
- notify_on_release flag: run the release agent on exit?
241240
- release_agent: the path to use for release notifications (this file
242241
exists in the top cgroup only)

Documentation/connector/cn_test.c

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -25,6 +25,7 @@
2525
#include <linux/module.h>
2626
#include <linux/moduleparam.h>
2727
#include <linux/skbuff.h>
28+
#include <linux/slab.h>
2829
#include <linux/timer.h>
2930

3031
#include <linux/connector.h>
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,9 @@
11

2-
What is imacfb?
2+
What is efifb?
33
===============
44

55
This is a generic EFI platform driver for Intel based Apple computers.
6-
Imacfb is only for EFI booted Intel Macs.
6+
efifb is only for EFI booted Intel Macs.
77

88
Supported Hardware
99
==================
@@ -16,16 +16,16 @@ MacMini
1616
How to use it?
1717
==============
1818

19-
Imacfb does not have any kind of autodetection of your machine.
19+
efifb does not have any kind of autodetection of your machine.
2020
You have to add the following kernel parameters in your elilo.conf:
2121
Macbook :
22-
video=imacfb:macbook
22+
video=efifb:macbook
2323
MacMini :
24-
video=imacfb:mini
24+
video=efifb:mini
2525
Macbook Pro 15", iMac 17" :
26-
video=imacfb:i17
26+
video=efifb:i17
2727
Macbook Pro 17", iMac 20" :
28-
video=imacfb:i20
28+
video=efifb:i20
2929

3030
--
3131
Edgar Hucek <gimli@dark-green.com>

0 commit comments

Comments
 (0)