Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 158616
b: refs/heads/master
c: ab3bbaa
h: refs/heads/master
v: v3
  • Loading branch information
Trond Myklebust authored and Trond Myklebust committed Sep 11, 2009
1 parent bc902a6 commit efb07b9
Show file tree
Hide file tree
Showing 1,060 changed files with 47,815 additions and 15,555 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: 2ecda72b49a0849ce41e7fa1fa974a245b9119f8
refs/heads/master: ab3bbaa8b257845e248e9a01d12a69ca245f4197
24 changes: 24 additions & 0 deletions trunk/Documentation/feature-removal-schedule.txt
Original file line number Diff line number Diff line change
Expand Up @@ -468,3 +468,27 @@ Why: cpu_policy_rwsem has a new cleaner definition making it local to
cpufreq core and contained inside cpufreq.c. Other dependent
drivers should not use it in order to safely avoid lockdep issues.
Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

----------------------------

What: sound-slot/service-* module aliases and related clutters in
sound/sound_core.c
When: August 2010
Why: OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR
(14) and requests modules using custom sound-slot/service-*
module aliases. The only benefit of doing this is allowing
use of custom module aliases which might as well be considered
a bug at this point. This preemptive claiming prevents
alternative OSS implementations.

Till the feature is removed, the kernel will be requesting
both sound-slot/service-* and the standard char-major-* module
aliases and allow turning off the pre-claiming selectively via
CONFIG_SOUND_OSS_CORE_PRECLAIM and soundcore.preclaim_oss
kernel parameter.

After the transition phase is complete, both the custom module
aliases and switches to disable it will go away. This removal
will also allow making ALSA OSS emulation independent of
sound_core. The dependency will be broken then too.
Who: Tejun Heo <tj@kernel.org>
3 changes: 3 additions & 0 deletions trunk/Documentation/filesystems/9p.txt
Original file line number Diff line number Diff line change
Expand Up @@ -123,6 +123,9 @@ available from the same CVS repository.
There are user and developer mailing lists available through the v9fs project
on sourceforge (http://sourceforge.net/projects/v9fs).

A stand-alone version of the module (which should build for any 2.6 kernel)
is available via (http://github.com/ericvh/9p-sac/tree/master)

News and other information is maintained on SWiK (http://swik.net/v9fs).

Bug reports may be issued through the kernel.org bugzilla
Expand Down
26 changes: 12 additions & 14 deletions trunk/Documentation/filesystems/afs.txt
Original file line number Diff line number Diff line change
Expand Up @@ -23,15 +23,13 @@ it does support include:

(*) Security (currently only AFS kaserver and KerberosIV tickets).

(*) File reading.
(*) File reading and writing.

(*) Automounting.

It does not yet support the following AFS features:

(*) Write support.
(*) Local caching (via fscache).

(*) Local caching.
It does not yet support the following AFS features:

(*) pioctl() system call.

Expand All @@ -56,7 +54,7 @@ They permit the debugging messages to be turned on dynamically by manipulating
the masks in the following files:

/sys/module/af_rxrpc/parameters/debug
/sys/module/afs/parameters/debug
/sys/module/kafs/parameters/debug


=====
Expand All @@ -66,9 +64,9 @@ USAGE
When inserting the driver modules the root cell must be specified along with a
list of volume location server IP addresses:

insmod af_rxrpc.o
insmod rxkad.o
insmod kafs.o rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91
modprobe af_rxrpc
modprobe rxkad
modprobe kafs rootcell=cambridge.redhat.com:172.16.18.73:172.16.18.91

The first module is the AF_RXRPC network protocol driver. This provides the
RxRPC remote operation protocol and may also be accessed from userspace. See:
Expand All @@ -81,7 +79,7 @@ is the actual filesystem driver for the AFS filesystem.
Once the module has been loaded, more modules can be added by the following
procedure:

echo add grand.central.org 18.7.14.88:128.2.191.224 >/proc/fs/afs/cells
echo add grand.central.org 18.9.48.14:128.2.203.61:130.237.48.87 >/proc/fs/afs/cells

Where the parameters to the "add" command are the name of a cell and a list of
volume location servers within that cell, with the latter separated by colons.
Expand All @@ -101,7 +99,7 @@ The name of the volume can be suffixes with ".backup" or ".readonly" to
specify connection to only volumes of those types.

The name of the cell is optional, and if not given during a mount, then the
named volume will be looked up in the cell specified during insmod.
named volume will be looked up in the cell specified during modprobe.

Additional cells can be added through /proc (see later section).

Expand Down Expand Up @@ -163,14 +161,14 @@ THE CELL DATABASE

The filesystem maintains an internal database of all the cells it knows and the
IP addresses of the volume location servers for those cells. The cell to which
the system belongs is added to the database when insmod is performed by the
the system belongs is added to the database when modprobe is performed by the
"rootcell=" argument or, if compiled in, using a "kafs.rootcell=" argument on
the kernel command line.

Further cells can be added by commands similar to the following:

echo add CELLNAME VLADDR[:VLADDR][:VLADDR]... >/proc/fs/afs/cells
echo add grand.central.org 18.7.14.88:128.2.191.224 >/proc/fs/afs/cells
echo add grand.central.org 18.9.48.14:128.2.203.61:130.237.48.87 >/proc/fs/afs/cells

No other cell database operations are available at this time.

Expand Down Expand Up @@ -233,7 +231,7 @@ insmod /tmp/kafs.o rootcell=cambridge.redhat.com:172.16.18.91
mount -t afs \%root.afs. /afs
mount -t afs \%cambridge.redhat.com:root.cell. /afs/cambridge.redhat.com/

echo add grand.central.org 18.7.14.88:128.2.191.224 > /proc/fs/afs/cells
echo add grand.central.org 18.9.48.14:128.2.203.61:130.237.48.87 > /proc/fs/afs/cells
mount -t afs "#grand.central.org:root.cell." /afs/grand.central.org/
mount -t afs "#grand.central.org:root.archive." /afs/grand.central.org/archive
mount -t afs "#grand.central.org:root.contrib." /afs/grand.central.org/contrib
Expand Down
15 changes: 5 additions & 10 deletions trunk/Documentation/filesystems/proc.txt
Original file line number Diff line number Diff line change
Expand Up @@ -1167,13 +1167,11 @@ CHAPTER 3: PER-PROCESS PARAMETERS
3.1 /proc/<pid>/oom_adj - Adjust the oom-killer score
------------------------------------------------------

This file can be used to adjust the score used to select which processes should
be killed in an out-of-memory situation. The oom_adj value is a characteristic
of the task's mm, so all threads that share an mm with pid will have the same
oom_adj value. A high value will increase the likelihood of this process being
killed by the oom-killer. Valid values are in the range -16 to +15 as
explained below and a special value of -17, which disables oom-killing
altogether for threads sharing pid's mm.
This file can be used to adjust the score used to select which processes
should be killed in an out-of-memory situation. Giving it a high score will
increase the likelihood of this process being killed by the oom-killer. Valid
values are in the range -16 to +15, plus the special value -17, which disables
oom-killing altogether for this process.

The process to be killed in an out-of-memory situation is selected among all others
based on its badness score. This value equals the original memory size of the process
Expand All @@ -1187,9 +1185,6 @@ the parent's score if they do not share the same memory. Thus forking servers
are the prime candidates to be killed. Having only one 'hungry' child will make
parent less preferable than the child.

/proc/<pid>/oom_adj cannot be changed for kthreads since they are immune from
oom-killing already.

/proc/<pid>/oom_score shows process' current badness score.

The following heuristics are then applied:
Expand Down
39 changes: 38 additions & 1 deletion trunk/Documentation/keys.txt
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ This document has the following sections:
- Notes on accessing payload contents
- Defining a key type
- Request-key callback service
- Key access filesystem
- Garbage collection


============
Expand Down Expand Up @@ -113,6 +113,9 @@ Each key has a number of attributes:

(*) Dead. The key's type was unregistered, and so the key is now useless.

Keys in the last three states are subject to garbage collection. See the
section on "Garbage collection".


====================
KEY SERVICE OVERVIEW
Expand Down Expand Up @@ -754,6 +757,26 @@ The keyctl syscall functions are:
successful.


(*) Install the calling process's session keyring on its parent.

long keyctl(KEYCTL_SESSION_TO_PARENT);

This functions attempts to install the calling process's session keyring
on to the calling process's parent, replacing the parent's current session
keyring.

The calling process must have the same ownership as its parent, the
keyring must have the same ownership as the calling process, the calling
process must have LINK permission on the keyring and the active LSM module
mustn't deny permission, otherwise error EPERM will be returned.

Error ENOMEM will be returned if there was insufficient memory to complete
the operation, otherwise 0 will be returned to indicate success.

The keyring will be replaced next time the parent process leaves the
kernel and resumes executing userspace.


===============
KERNEL SERVICES
===============
Expand Down Expand Up @@ -1231,3 +1254,17 @@ by executing:

In this case, the program isn't required to actually attach the key to a ring;
the rings are provided for reference.


==================
GARBAGE COLLECTION
==================

Dead keys (for which the type has been removed) will be automatically unlinked
from those keyrings that point to them and deleted as soon as possible by a
background garbage collector.

Similarly, revoked and expired keys will be garbage collected, but only after a
certain amount of time has passed. This time is set as a number of seconds in:

/proc/sys/kernel/keys/gc_delay
31 changes: 31 additions & 0 deletions trunk/Documentation/kmemleak.txt
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,13 @@ To trigger an intermediate memory scan:

# echo scan > /sys/kernel/debug/kmemleak

To clear the list of all current possible memory leaks:

# echo clear > /sys/kernel/debug/kmemleak

New leaks will then come up upon reading /sys/kernel/debug/kmemleak
again.

Note that the orphan objects are listed in the order they were allocated
and one object at the beginning of the list may cause other subsequent
objects to be reported as orphan.
Expand All @@ -42,6 +49,9 @@ Memory scanning parameters can be modified at run-time by writing to the
scan=<secs> - set the automatic memory scanning period in seconds
(default 600, 0 to stop the automatic scanning)
scan - trigger a memory scan
clear - clear list of current memory leak suspects, done by
marking all current reported unreferenced objects grey
dump=<addr> - dump information about the object found at <addr>

Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on
the kernel command line.
Expand Down Expand Up @@ -86,6 +96,27 @@ avoid this, kmemleak can also store the number of values pointing to an
address inside the block address range that need to be found so that the
block is not considered a leak. One example is __vmalloc().

Testing specific sections with kmemleak
---------------------------------------

Upon initial bootup your /sys/kernel/debug/kmemleak output page may be
quite extensive. This can also be the case if you have very buggy code
when doing development. To work around these situations you can use the
'clear' command to clear all reported unreferenced objects from the
/sys/kernel/debug/kmemleak output. By issuing a 'scan' after a 'clear'
you can find new unreferenced objects; this should help with testing
specific sections of code.

To test a critical section on demand with a clean kmemleak do:

# echo clear > /sys/kernel/debug/kmemleak
... test your kernel or modules ...
# echo scan > /sys/kernel/debug/kmemleak

Then as usual to get your report with:

# cat /sys/kernel/debug/kmemleak

Kmemleak API
------------

Expand Down
7 changes: 7 additions & 0 deletions trunk/Documentation/s390/s390dbf.txt
Original file line number Diff line number Diff line change
Expand Up @@ -495,6 +495,13 @@ and for each vararg a long value. So e.g. for a debug entry with a format
string plus two varargs one would need to allocate a (3 * sizeof(long))
byte data area in the debug_register() function.

IMPORTANT: Using "%s" in sprintf event functions is dangerous. You can only
use "%s" in the sprintf event functions, if the memory for the passed string is
available as long as the debug feature exists. The reason behind this is that
due to performance considerations only a pointer to the string is stored in
the debug feature. If you log a string that is freed afterwards, you will get
an OOPS when inspecting the debug feature, because then the debug feature will
access the already freed memory.

NOTE: If using the sprintf view do NOT use other event/exception functions
than the sprintf-event and -exception functions.
Expand Down
30 changes: 30 additions & 0 deletions trunk/Documentation/sound/alsa/ALSA-Configuration.txt
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,12 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
slots - Reserve the slot index for the given driver.
This option takes multiple strings.
See "Module Autoloading Support" section for details.
debug - Specifies the debug message level
(0 = disable debug prints, 1 = normal debug messages,
2 = verbose debug messages)
This option appears only when CONFIG_SND_DEBUG=y.
This option can be dynamically changed via sysfs
/sys/modules/snd/parameters/debug file.

Module snd-pcm-oss
------------------
Expand Down Expand Up @@ -513,6 +519,26 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
or input, but you may use this module for any application which
requires a sound card (like RealPlayer).

pcm_devs - Number of PCM devices assigned to each card
(default = 1, up to 4)
pcm_substreams - Number of PCM substreams assigned to each PCM
(default = 8, up to 16)
hrtimer - Use hrtimer (=1, default) or system timer (=0)
fake_buffer - Fake buffer allocations (default = 1)

When multiple PCM devices are created, snd-dummy gives different
behavior to each PCM device:
0 = interleaved with mmap support
1 = non-interleaved with mmap support
2 = interleaved without mmap
3 = non-interleaved without mmap

As default, snd-dummy drivers doesn't allocate the real buffers
but either ignores read/write or mmap a single dummy page to all
buffer pages, in order to save the resouces. If your apps need
the read/ written buffer data to be consistent, pass fake_buffer=0
option.

The power-management is supported.

Module snd-echo3g
Expand Down Expand Up @@ -768,6 +794,10 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
bdl_pos_adj - Specifies the DMA IRQ timing delay in samples.
Passing -1 will make the driver to choose the appropriate
value based on the controller chip.
patch - Specifies the early "patch" files to modify the HD-audio
setup before initializing the codecs. This option is
available only when CONFIG_SND_HDA_PATCH_LOADER=y is set.
See HD-Audio.txt for details.

[Single (global) options]
single_cmd - Use single immediate commands to communicate with
Expand Down
Loading

0 comments on commit efb07b9

Please sign in to comment.