Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 345635
b: refs/heads/master
c: 374a868
h: refs/heads/master
i:
  345633: 7794650
  345631: bb62c21
v: v3
  • Loading branch information
Paulo Zanoni authored and Daniel Vetter committed Nov 29, 2012
1 parent 636127d commit ce0718d
Show file tree
Hide file tree
Showing 797 changed files with 13,950 additions and 33,309 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 2f3f24061c5c489074ad492bf694a5a76ebd8fc5
refs/heads/master: 374a868a726eb8a1cb28ba88805e51ce34222f8d
5 changes: 0 additions & 5 deletions trunk/CREDITS
Original file line number Diff line number Diff line change
Expand Up @@ -1823,11 +1823,6 @@ S: Kattreinstr 38
S: D-64295
S: Germany

N: Avi Kivity
E: avi.kivity@gmail.com
D: Kernel-based Virtual Machine (KVM)
S: Ra'annana, Israel

N: Andi Kleen
E: andi@firstfloor.org
U: http://www.halobates.de
Expand Down
9 changes: 0 additions & 9 deletions trunk/Documentation/DMA-attributes.txt
Original file line number Diff line number Diff line change
Expand Up @@ -91,12 +91,3 @@ transferred to 'device' domain. This attribute can be also used for
dma_unmap_{single,page,sg} functions family to force buffer to stay in
device domain after releasing a mapping for it. Use this attribute with
care!

DMA_ATTR_FORCE_CONTIGUOUS
-------------------------

By default DMA-mapping subsystem is allowed to assemble the buffer
allocated by dma_alloc_attrs() function from individual pages if it can
be mapped as contiguous chunk into device dma address space. By
specifing this attribute the allocated buffer is forced to be contiguous
also in physical memory.
19 changes: 2 additions & 17 deletions trunk/Documentation/DocBook/drm.tmpl
Original file line number Diff line number Diff line change
Expand Up @@ -1611,10 +1611,10 @@ void intel_crt_init(struct drm_device *dev)
</sect2>
</sect1>

<!-- Internals: kms helper functions -->
<!-- Internals: mid-layer helper functions -->

<sect1>
<title>Mode Setting Helper Functions</title>
<title>Mid-layer Helper Functions</title>
<para>
The CRTC, encoder and connector functions provided by the drivers
implement the DRM API. They're called by the DRM core and ioctl handlers
Expand Down Expand Up @@ -2096,21 +2096,6 @@ void intel_crt_init(struct drm_device *dev)
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Modeset Helper Functions Reference</title>
!Edrivers/gpu/drm/drm_crtc_helper.c
</sect2>
<sect2>
<title>fbdev Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
!Edrivers/gpu/drm/drm_fb_helper.c
</sect2>
<sect2>
<title>Display Port Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
!Iinclude/drm/drm_dp_helper.h
!Edrivers/gpu/drm/drm_dp_helper.c
</sect2>
</sect1>

<!-- Internals: vertical blanking -->
Expand Down
12 changes: 6 additions & 6 deletions trunk/Documentation/arm64/memory.txt
Original file line number Diff line number Diff line change
Expand Up @@ -27,17 +27,17 @@ Start End Size Use
-----------------------------------------------------------------------
0000000000000000 0000007fffffffff 512GB user

ffffff8000000000 ffffffbbfffeffff ~240GB vmalloc
ffffff8000000000 ffffffbbfffcffff ~240GB vmalloc

ffffffbbffff0000 ffffffbbffffffff 64KB [guard page]
ffffffbbfffd0000 ffffffbcfffdffff 64KB [guard page]

ffffffbc00000000 ffffffbdffffffff 8GB vmemmap
ffffffbbfffe0000 ffffffbcfffeffff 64KB PCI I/O space

ffffffbe00000000 ffffffbffbbfffff ~8GB [guard, future vmmemap]
ffffffbbffff0000 ffffffbcffffffff 64KB [guard page]

ffffffbffbe00000 ffffffbffbe0ffff 64KB PCI I/O space
ffffffbc00000000 ffffffbdffffffff 8GB vmemmap

ffffffbbffff0000 ffffffbcffffffff ~2MB [guard]
ffffffbe00000000 ffffffbffbffffff ~8GB [guard, future vmmemap]

ffffffbffc000000 ffffffbfffffffff 64MB modules

Expand Down
4 changes: 0 additions & 4 deletions trunk/Documentation/cgroups/memory.txt
Original file line number Diff line number Diff line change
Expand Up @@ -466,10 +466,6 @@ Note:
5.3 swappiness

Similar to /proc/sys/vm/swappiness, but affecting a hierarchy of groups only.
Please note that unlike the global swappiness, memcg knob set to 0
really prevents from any swapping even if there is a swap storage
available. This might lead to memcg OOM killer if there are no file
pages to reclaim.

Following cgroups' swappiness can't be changed.
- root cgroup (uses /proc/sys/vm/swappiness).
Expand Down
9 changes: 1 addition & 8 deletions trunk/Documentation/devicetree/bindings/net/mdio-gpio.txt
Original file line number Diff line number Diff line change
Expand Up @@ -8,16 +8,9 @@ gpios property as described in section VIII.1 in the following order:

MDC, MDIO.

Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases"
node.

Example:

aliases {
mdio-gpio0 = <&mdio0>;
};

mdio0: mdio {
mdio {
compatible = "virtual,mdio-gpio";
#address-cells = <1>;
#size-cells = <0>;
Expand Down
16 changes: 4 additions & 12 deletions trunk/Documentation/filesystems/proc.txt
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ Table of Contents
2 Modifying System Parameters

3 Per-Process Parameters
3.1 /proc/<pid>/oom_adj & /proc/<pid>/oom_score_adj - Adjust the oom-killer
3.1 /proc/<pid>/oom_score_adj - Adjust the oom-killer
score
3.2 /proc/<pid>/oom_score - Display current oom-killer score
3.3 /proc/<pid>/io - Display the IO accounting fields
Expand Down Expand Up @@ -1320,10 +1320,10 @@ of the kernel.
CHAPTER 3: PER-PROCESS PARAMETERS
------------------------------------------------------------------------------

3.1 /proc/<pid>/oom_adj & /proc/<pid>/oom_score_adj- Adjust the oom-killer score
3.1 /proc/<pid>/oom_score_adj- Adjust the oom-killer score
--------------------------------------------------------------------------------

These file can be used to adjust the badness heuristic used to select which
This file can be used to adjust the badness heuristic used to select which
process gets killed in out of memory conditions.

The badness heuristic assigns a value to each candidate task ranging from 0
Expand Down Expand Up @@ -1361,12 +1361,6 @@ same system, cpuset, mempolicy, or memory controller resources to use at least
equivalent to discounting 50% of the task's allowed memory from being considered
as scoring against the task.

For backwards compatibility with previous kernels, /proc/<pid>/oom_adj may also
be used to tune the badness score. Its acceptable values range from -16
(OOM_ADJUST_MIN) to +15 (OOM_ADJUST_MAX) and a special value of -17
(OOM_DISABLE) to disable oom killing entirely for that task. Its value is
scaled linearly with /proc/<pid>/oom_score_adj.

The value of /proc/<pid>/oom_score_adj may be reduced no lower than the last
value set by a CAP_SYS_RESOURCE process. To reduce the value any lower
requires CAP_SYS_RESOURCE.
Expand All @@ -1381,9 +1375,7 @@ minimal amount of work.
-------------------------------------------------------------

This file can be used to check the current score used by the oom-killer is for
any given <pid>. Use it together with /proc/<pid>/oom_score_adj to tune which
process should be killed in an out-of-memory situation.

any given <pid>.

3.3 /proc/<pid>/io - Display the IO accounting fields
-------------------------------------------------------
Expand Down
88 changes: 0 additions & 88 deletions trunk/Documentation/kref.txt
Original file line number Diff line number Diff line change
Expand Up @@ -213,91 +213,3 @@ presentation on krefs, which can be found at:
and:
http://www.kroah.com/linux/talks/ols_2004_kref_talk/


The above example could also be optimized using kref_get_unless_zero() in
the following way:

static struct my_data *get_entry()
{
struct my_data *entry = NULL;
mutex_lock(&mutex);
if (!list_empty(&q)) {
entry = container_of(q.next, struct my_data, link);
if (!kref_get_unless_zero(&entry->refcount))
entry = NULL;
}
mutex_unlock(&mutex);
return entry;
}

static void release_entry(struct kref *ref)
{
struct my_data *entry = container_of(ref, struct my_data, refcount);

mutex_lock(&mutex);
list_del(&entry->link);
mutex_unlock(&mutex);
kfree(entry);
}

static void put_entry(struct my_data *entry)
{
kref_put(&entry->refcount, release_entry);
}

Which is useful to remove the mutex lock around kref_put() in put_entry(), but
it's important that kref_get_unless_zero is enclosed in the same critical
section that finds the entry in the lookup table,
otherwise kref_get_unless_zero may reference already freed memory.
Note that it is illegal to use kref_get_unless_zero without checking its
return value. If you are sure (by already having a valid pointer) that
kref_get_unless_zero() will return true, then use kref_get() instead.

The function kref_get_unless_zero also makes it possible to use rcu
locking for lookups in the above example:

struct my_data
{
struct rcu_head rhead;
.
struct kref refcount;
.
.
};

static struct my_data *get_entry_rcu()
{
struct my_data *entry = NULL;
rcu_read_lock();
if (!list_empty(&q)) {
entry = container_of(q.next, struct my_data, link);
if (!kref_get_unless_zero(&entry->refcount))
entry = NULL;
}
rcu_read_unlock();
return entry;
}

static void release_entry_rcu(struct kref *ref)
{
struct my_data *entry = container_of(ref, struct my_data, refcount);

mutex_lock(&mutex);
list_del_rcu(&entry->link);
mutex_unlock(&mutex);
kfree_rcu(entry, rhead);
}

static void put_entry(struct my_data *entry)
{
kref_put(&entry->refcount, release_entry_rcu);
}

But note that the struct kref member needs to remain in valid memory for a
rcu grace period after release_entry_rcu was called. That can be accomplished
by using kfree_rcu(entry, rhead) as done above, or by calling synchronize_rcu()
before using kfree, but note that synchronize_rcu() may sleep for a
substantial amount of time.


Thomas Hellstrom <thellstrom@vmware.com>
2 changes: 1 addition & 1 deletion trunk/Documentation/networking/netdev-features.txt
Original file line number Diff line number Diff line change
Expand Up @@ -164,4 +164,4 @@ read the CRC recorded by the NIC on receipt of the packet.
This requests that the NIC receive all possible frames, including errored
frames (such as bad FCS, etc). This can be helpful when sniffing a link with
bad packets on it. Some NICs may receive more packets if also put into normal
PROMISC mode.
PROMISC mdoe.
4 changes: 2 additions & 2 deletions trunk/Documentation/networking/vxlan.txt
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ no entry is in the forwarding table.
# ip link delete vxlan0

3. Show vxlan info
# ip -d link show vxlan0
# ip -d show vxlan0

It is possible to create, destroy and display the vxlan
forwarding table using the new bridge command.
Expand All @@ -41,7 +41,7 @@ forwarding table using the new bridge command.
# bridge fdb add to 00:17:42:8a:b4:05 dst 192.19.0.2 dev vxlan0

2. Delete forwarding table entry
# bridge fdb delete 00:17:42:8a:b4:05 dev vxlan0
# bridge fdb delete 00:17:42:8a:b4:05

3. Show forwarding table
# bridge fdb show dev vxlan0
Loading

0 comments on commit ce0718d

Please sign in to comment.