aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/DocBook/s390-drivers.tmpl21
-rw-r--r--Documentation/Smack.txt493
-rw-r--r--Documentation/filesystems/proc.txt95
-rw-r--r--Documentation/gpio.txt133
-rw-r--r--Documentation/i2c/chips/pca95393
-rw-r--r--Documentation/ia64/aliasing-test.c15
-rw-r--r--Documentation/kernel-parameters.txt3
-rw-r--r--Documentation/pcmcia/driver-changes.txt4
-rw-r--r--Documentation/pm_qos_interface.txt59
-rw-r--r--Documentation/sysctl/vm.txt7
10 files changed, 788 insertions, 45 deletions
diff --git a/Documentation/DocBook/s390-drivers.tmpl b/Documentation/DocBook/s390-drivers.tmpl
index 3d2f31b99dd9..4acc73240a6d 100644
--- a/Documentation/DocBook/s390-drivers.tmpl
+++ b/Documentation/DocBook/s390-drivers.tmpl
@@ -59,7 +59,7 @@
59 <title>Introduction</title> 59 <title>Introduction</title>
60 <para> 60 <para>
61 This document describes the interfaces available for device drivers that 61 This document describes the interfaces available for device drivers that
62 drive s390 based channel attached devices. This includes interfaces for 62 drive s390 based channel attached I/O devices. This includes interfaces for
63 interaction with the hardware and interfaces for interacting with the 63 interaction with the hardware and interfaces for interacting with the
64 common driver core. Those interfaces are provided by the s390 common I/O 64 common driver core. Those interfaces are provided by the s390 common I/O
65 layer. 65 layer.
@@ -86,9 +86,10 @@
86 The ccw bus typically contains the majority of devices available to 86 The ccw bus typically contains the majority of devices available to
87 a s390 system. Named after the channel command word (ccw), the basic 87 a s390 system. Named after the channel command word (ccw), the basic
88 command structure used to address its devices, the ccw bus contains 88 command structure used to address its devices, the ccw bus contains
89 so-called channel attached devices. They are addressed via subchannels, 89 so-called channel attached devices. They are addressed via I/O
90 visible on the css bus. A device driver, however, will never interact 90 subchannels, visible on the css bus. A device driver for
91 with the subchannel directly, but only via the device on the ccw bus, 91 channel-attached devices, however, will never interact with the
92 subchannel directly, but only via the I/O device on the ccw bus,
92 the ccw device. 93 the ccw device.
93 </para> 94 </para>
94 <sect1 id="channelIO"> 95 <sect1 id="channelIO">
@@ -116,7 +117,6 @@
116!Iinclude/asm-s390/ccwdev.h 117!Iinclude/asm-s390/ccwdev.h
117!Edrivers/s390/cio/device.c 118!Edrivers/s390/cio/device.c
118!Edrivers/s390/cio/device_ops.c 119!Edrivers/s390/cio/device_ops.c
119!Edrivers/s390/cio/airq.c
120 </sect1> 120 </sect1>
121 <sect1 id="cmf"> 121 <sect1 id="cmf">
122 <title>The channel-measurement facility</title> 122 <title>The channel-measurement facility</title>
@@ -147,4 +147,15 @@
147 </sect1> 147 </sect1>
148 </chapter> 148 </chapter>
149 149
150 <chapter id="genericinterfaces">
151 <title>Generic interfaces</title>
152 <para>
153 Some interfaces are available to other drivers that do not necessarily
154 have anything to do with the busses described above, but still are
155 indirectly using basic infrastructure in the common I/O layer.
156 One example is the support for adapter interrupts.
157 </para>
158!Edrivers/s390/cio/airq.c
159 </chapter>
160
150</book> 161</book>
diff --git a/Documentation/Smack.txt b/Documentation/Smack.txt
new file mode 100644
index 000000000000..989c2fcd8111
--- /dev/null
+++ b/Documentation/Smack.txt
@@ -0,0 +1,493 @@
1
2
3 "Good for you, you've decided to clean the elevator!"
4 - The Elevator, from Dark Star
5
6Smack is the the Simplified Mandatory Access Control Kernel.
7Smack is a kernel based implementation of mandatory access
8control that includes simplicity in its primary design goals.
9
10Smack is not the only Mandatory Access Control scheme
11available for Linux. Those new to Mandatory Access Control
12are encouraged to compare Smack with the other mechanisms
13available to determine which is best suited to the problem
14at hand.
15
16Smack consists of three major components:
17 - The kernel
18 - A start-up script and a few modified applications
19 - Configuration data
20
21The kernel component of Smack is implemented as a Linux
22Security Modules (LSM) module. It requires netlabel and
23works best with file systems that support extended attributes,
24although xattr support is not strictly required.
25It is safe to run a Smack kernel under a "vanilla" distribution.
26Smack kernels use the CIPSO IP option. Some network
27configurations are intolerant of IP options and can impede
28access to systems that use them as Smack does.
29
30The startup script etc-init.d-smack should be installed
31in /etc/init.d/smack and should be invoked early in the
32start-up process. On Fedora rc5.d/S02smack is recommended.
33This script ensures that certain devices have the correct
34Smack attributes and loads the Smack configuration if
35any is defined. This script invokes two programs that
36ensure configuration data is properly formatted. These
37programs are /usr/sbin/smackload and /usr/sin/smackcipso.
38The system will run just fine without these programs,
39but it will be difficult to set access rules properly.
40
41A version of "ls" that provides a "-M" option to display
42Smack labels on long listing is available.
43
44A hacked version of sshd that allows network logins by users
45with specific Smack labels is available. This version does
46not work for scp. You must set the /etc/ssh/sshd_config
47line:
48 UsePrivilegeSeparation no
49
50The format of /etc/smack/usr is:
51
52 username smack
53
54In keeping with the intent of Smack, configuration data is
55minimal and not strictly required. The most important
56configuration step is mounting the smackfs pseudo filesystem.
57
58Add this line to /etc/fstab:
59
60 smackfs /smack smackfs smackfsdef=* 0 0
61
62and create the /smack directory for mounting.
63
64Smack uses extended attributes (xattrs) to store file labels.
65The command to set a Smack label on a file is:
66
67 # attr -S -s SMACK64 -V "value" path
68
69NOTE: Smack labels are limited to 23 characters. The attr command
70 does not enforce this restriction and can be used to set
71 invalid Smack labels on files.
72
73If you don't do anything special all users will get the floor ("_")
74label when they log in. If you do want to log in via the hacked ssh
75at other labels use the attr command to set the smack value on the
76home directory and it's contents.
77
78You can add access rules in /etc/smack/accesses. They take the form:
79
80 subjectlabel objectlabel access
81
82access is a combination of the letters rwxa which specify the
83kind of access permitted a subject with subjectlabel on an
84object with objectlabel. If there is no rule no access is allowed.
85
86A process can see the smack label it is running with by
87reading /proc/self/attr/current. A privileged process can
88set the process smack by writing there.
89
90Look for additional programs on http://schaufler-ca.com
91
92From the Smack Whitepaper:
93
94The Simplified Mandatory Access Control Kernel
95
96Casey Schaufler
97casey@schaufler-ca.com
98
99Mandatory Access Control
100
101Computer systems employ a variety of schemes to constrain how information is
102shared among the people and services using the machine. Some of these schemes
103allow the program or user to decide what other programs or users are allowed
104access to pieces of data. These schemes are called discretionary access
105control mechanisms because the access control is specified at the discretion
106of the user. Other schemes do not leave the decision regarding what a user or
107program can access up to users or programs. These schemes are called mandatory
108access control mechanisms because you don't have a choice regarding the users
109or programs that have access to pieces of data.
110
111Bell & LaPadula
112
113From the middle of the 1980's until the turn of the century Mandatory Access
114Control (MAC) was very closely associated with the Bell & LaPadula security
115model, a mathematical description of the United States Department of Defense
116policy for marking paper documents. MAC in this form enjoyed a following
117within the Capital Beltway and Scandinavian supercomputer centers but was
118often sited as failing to address general needs.
119
120Domain Type Enforcement
121
122Around the turn of the century Domain Type Enforcement (DTE) became popular.
123This scheme organizes users, programs, and data into domains that are
124protected from each other. This scheme has been widely deployed as a component
125of popular Linux distributions. The administrative overhead required to
126maintain this scheme and the detailed understanding of the whole system
127necessary to provide a secure domain mapping leads to the scheme being
128disabled or used in limited ways in the majority of cases.
129
130Smack
131
132Smack is a Mandatory Access Control mechanism designed to provide useful MAC
133while avoiding the pitfalls of its predecessors. The limitations of Bell &
134LaPadula are addressed by providing a scheme whereby access can be controlled
135according to the requirements of the system and its purpose rather than those
136imposed by an arcane government policy. The complexity of Domain Type
137Enforcement and avoided by defining access controls in terms of the access
138modes already in use.
139
140Smack Terminology
141
142The jargon used to talk about Smack will be familiar to those who have dealt
143with other MAC systems and shouldn't be too difficult for the uninitiated to
144pick up. There are four terms that are used in a specific way and that are
145especially important:
146
147 Subject: A subject is an active entity on the computer system.
148 On Smack a subject is a task, which is in turn the basic unit
149 of execution.
150
151 Object: An object is a passive entity on the computer system.
152 On Smack files of all types, IPC, and tasks can be objects.
153
154 Access: Any attempt by a subject to put information into or get
155 information from an object is an access.
156
157 Label: Data that identifies the Mandatory Access Control
158 characteristics of a subject or an object.
159
160These definitions are consistent with the traditional use in the security
161community. There are also some terms from Linux that are likely to crop up:
162
163 Capability: A task that possesses a capability has permission to
164 violate an aspect of the system security policy, as identified by
165 the specific capability. A task that possesses one or more
166 capabilities is a privileged task, whereas a task with no
167 capabilities is an unprivileged task.
168
169 Privilege: A task that is allowed to violate the system security
170 policy is said to have privilege. As of this writing a task can
171 have privilege either by possessing capabilities or by having an
172 effective user of root.
173
174Smack Basics
175
176Smack is an extension to a Linux system. It enforces additional restrictions
177on what subjects can access which objects, based on the labels attached to
178each of the subject and the object.
179
180Labels
181
182Smack labels are ASCII character strings, one to twenty-three characters in
183length. Single character labels using special characters, that being anything
184other than a letter or digit, are reserved for use by the Smack development
185team. Smack labels are unstructured, case sensitive, and the only operation
186ever performed on them is comparison for equality. Smack labels cannot
187contain unprintable characters or the "/" (slash) character.
188
189There are some predefined labels:
190
191 _ Pronounced "floor", a single underscore character.
192 ^ Pronounced "hat", a single circumflex character.
193 * Pronounced "star", a single asterisk character.
194 ? Pronounced "huh", a single question mark character.
195
196Every task on a Smack system is assigned a label. System tasks, such as
197init(8) and systems daemons, are run with the floor ("_") label. User tasks
198are assigned labels according to the specification found in the
199/etc/smack/user configuration file.
200
201Access Rules
202
203Smack uses the traditional access modes of Linux. These modes are read,
204execute, write, and occasionally append. There are a few cases where the
205access mode may not be obvious. These include:
206
207 Signals: A signal is a write operation from the subject task to
208 the object task.
209 Internet Domain IPC: Transmission of a packet is considered a
210 write operation from the source task to the destination task.
211
212Smack restricts access based on the label attached to a subject and the label
213attached to the object it is trying to access. The rules enforced are, in
214order:
215
216 1. Any access requested by a task labeled "*" is denied.
217 2. A read or execute access requested by a task labeled "^"
218 is permitted.
219 3. A read or execute access requested on an object labeled "_"
220 is permitted.
221 4. Any access requested on an object labeled "*" is permitted.
222 5. Any access requested by a task on an object with the same
223 label is permitted.
224 6. Any access requested that is explicitly defined in the loaded
225 rule set is permitted.
226 7. Any other access is denied.
227
228Smack Access Rules
229
230With the isolation provided by Smack access separation is simple. There are
231many interesting cases where limited access by subjects to objects with
232different labels is desired. One example is the familiar spy model of
233sensitivity, where a scientist working on a highly classified project would be
234able to read documents of lower classifications and anything she writes will
235be "born" highly classified. To accommodate such schemes Smack includes a
236mechanism for specifying rules allowing access between labels.
237
238Access Rule Format
239
240The format of an access rule is:
241
242 subject-label object-label access
243
244Where subject-label is the Smack label of the task, object-label is the Smack
245label of the thing being accessed, and access is a string specifying the sort
246of access allowed. The Smack labels are limited to 23 characters. The access
247specification is searched for letters that describe access modes:
248
249 a: indicates that append access should be granted.
250 r: indicates that read access should be granted.
251 w: indicates that write access should be granted.
252 x: indicates that execute access should be granted.
253
254Uppercase values for the specification letters are allowed as well.
255Access mode specifications can be in any order. Examples of acceptable rules
256are:
257
258 TopSecret Secret rx
259 Secret Unclass R
260 Manager Game x
261 User HR w
262 New Old rRrRr
263 Closed Off -
264
265Examples of unacceptable rules are:
266
267 Top Secret Secret rx
268 Ace Ace r
269 Odd spells waxbeans
270
271Spaces are not allowed in labels. Since a subject always has access to files
272with the same label specifying a rule for that case is pointless. Only
273valid letters (rwxaRWXA) and the dash ('-') character are allowed in
274access specifications. The dash is a placeholder, so "a-r" is the same
275as "ar". A lone dash is used to specify that no access should be allowed.
276
277Applying Access Rules
278
279The developers of Linux rarely define new sorts of things, usually importing
280schemes and concepts from other systems. Most often, the other systems are
281variants of Unix. Unix has many endearing properties, but consistency of
282access control models is not one of them. Smack strives to treat accesses as
283uniformly as is sensible while keeping with the spirit of the underlying
284mechanism.
285
286File system objects including files, directories, named pipes, symbolic links,
287and devices require access permissions that closely match those used by mode
288bit access. To open a file for reading read access is required on the file. To
289search a directory requires execute access. Creating a file with write access
290requires both read and write access on the containing directory. Deleting a
291file requires read and write access to the file and to the containing
292directory. It is possible that a user may be able to see that a file exists
293but not any of its attributes by the circumstance of having read access to the
294containing directory but not to the differently labeled file. This is an
295artifact of the file name being data in the directory, not a part of the file.
296
297IPC objects, message queues, semaphore sets, and memory segments exist in flat
298namespaces and access requests are only required to match the object in
299question.
300
301Process objects reflect tasks on the system and the Smack label used to access
302them is the same Smack label that the task would use for its own access
303attempts. Sending a signal via the kill() system call is a write operation
304from the signaler to the recipient. Debugging a process requires both reading
305and writing. Creating a new task is an internal operation that results in two
306tasks with identical Smack labels and requires no access checks.
307
308Sockets are data structures attached to processes and sending a packet from
309one process to another requires that the sender have write access to the
310receiver. The receiver is not required to have read access to the sender.
311
312Setting Access Rules
313
314The configuration file /etc/smack/accesses contains the rules to be set at
315system startup. The contents are written to the special file /smack/load.
316Rules can be written to /smack/load at any time and take effect immediately.
317For any pair of subject and object labels there can be only one rule, with the
318most recently specified overriding any earlier specification.
319
320The program smackload is provided to ensure data is formatted
321properly when written to /smack/load. This program reads lines
322of the form
323
324 subjectlabel objectlabel mode.
325
326Task Attribute
327
328The Smack label of a process can be read from /proc/<pid>/attr/current. A
329process can read its own Smack label from /proc/self/attr/current. A
330privileged process can change its own Smack label by writing to
331/proc/self/attr/current but not the label of another process.
332
333File Attribute
334
335The Smack label of a filesystem object is stored as an extended attribute
336named SMACK64 on the file. This attribute is in the security namespace. It can
337only be changed by a process with privilege.
338
339Privilege
340
341A process with CAP_MAC_OVERRIDE is privileged.
342
343Smack Networking
344
345As mentioned before, Smack enforces access control on network protocol
346transmissions. Every packet sent by a Smack process is tagged with its Smack
347label. This is done by adding a CIPSO tag to the header of the IP packet. Each
348packet received is expected to have a CIPSO tag that identifies the label and
349if it lacks such a tag the network ambient label is assumed. Before the packet
350is delivered a check is made to determine that a subject with the label on the
351packet has write access to the receiving process and if that is not the case
352the packet is dropped.
353
354CIPSO Configuration
355
356It is normally unnecessary to specify the CIPSO configuration. The default
357values used by the system handle all internal cases. Smack will compose CIPSO
358label values to match the Smack labels being used without administrative
359intervention. Unlabeled packets that come into the system will be given the
360ambient label.
361
362Smack requires configuration in the case where packets from a system that is
363not smack that speaks CIPSO may be encountered. Usually this will be a Trusted
364Solaris system, but there are other, less widely deployed systems out there.
365CIPSO provides 3 important values, a Domain Of Interpretation (DOI), a level,
366and a category set with each packet. The DOI is intended to identify a group
367of systems that use compatible labeling schemes, and the DOI specified on the
368smack system must match that of the remote system or packets will be
369discarded. The DOI is 3 by default. The value can be read from /smack/doi and
370can be changed by writing to /smack/doi.
371
372The label and category set are mapped to a Smack label as defined in
373/etc/smack/cipso.
374
375A Smack/CIPSO mapping has the form:
376
377 smack level [category [category]*]
378
379Smack does not expect the level or category sets to be related in any
380particular way and does not assume or assign accesses based on them. Some
381examples of mappings:
382
383 TopSecret 7
384 TS:A,B 7 1 2
385 SecBDE 5 2 4 6
386 RAFTERS 7 12 26
387
388The ":" and "," characters are permitted in a Smack label but have no special
389meaning.
390
391The mapping of Smack labels to CIPSO values is defined by writing to
392/smack/cipso. Again, the format of data written to this special file
393is highly restrictive, so the program smackcipso is provided to
394ensure the writes are done properly. This program takes mappings
395on the standard input and sends them to /smack/cipso properly.
396
397In addition to explicit mappings Smack supports direct CIPSO mappings. One
398CIPSO level is used to indicate that the category set passed in the packet is
399in fact an encoding of the Smack label. The level used is 250 by default. The
400value can be read from /smack/direct and changed by writing to /smack/direct.
401
402Socket Attributes
403
404There are two attributes that are associated with sockets. These attributes
405can only be set by privileged tasks, but any task can read them for their own
406sockets.
407
408 SMACK64IPIN: The Smack label of the task object. A privileged
409 program that will enforce policy may set this to the star label.
410
411 SMACK64IPOUT: The Smack label transmitted with outgoing packets.
412 A privileged program may set this to match the label of another
413 task with which it hopes to communicate.
414
415Writing Applications for Smack
416
417There are three sorts of applications that will run on a Smack system. How an
418application interacts with Smack will determine what it will have to do to
419work properly under Smack.
420
421Smack Ignorant Applications
422
423By far the majority of applications have no reason whatever to care about the
424unique properties of Smack. Since invoking a program has no impact on the
425Smack label associated with the process the only concern likely to arise is
426whether the process has execute access to the program.
427
428Smack Relevant Applications
429
430Some programs can be improved by teaching them about Smack, but do not make
431any security decisions themselves. The utility ls(1) is one example of such a
432program.
433
434Smack Enforcing Applications
435
436These are special programs that not only know about Smack, but participate in
437the enforcement of system policy. In most cases these are the programs that
438set up user sessions. There are also network services that provide information
439to processes running with various labels.
440
441File System Interfaces
442
443Smack maintains labels on file system objects using extended attributes. The
444Smack label of a file, directory, or other file system object can be obtained
445using getxattr(2).
446
447 len = getxattr("/", "security.SMACK64", value, sizeof (value));
448
449will put the Smack label of the root directory into value. A privileged
450process can set the Smack label of a file system object with setxattr(2).
451
452 len = strlen("Rubble");
453 rc = setxattr("/foo", "security.SMACK64", "Rubble", len, 0);
454
455will set the Smack label of /foo to "Rubble" if the program has appropriate
456privilege.
457
458Socket Interfaces
459
460The socket attributes can be read using fgetxattr(2).
461
462A privileged process can set the Smack label of outgoing packets with
463fsetxattr(2).
464
465 len = strlen("Rubble");
466 rc = fsetxattr(fd, "security.SMACK64IPOUT", "Rubble", len, 0);
467
468will set the Smack label "Rubble" on packets going out from the socket if the
469program has appropriate privilege.
470
471 rc = fsetxattr(fd, "security.SMACK64IPIN, "*", strlen("*"), 0);
472
473will set the Smack label "*" as the object label against which incoming
474packets will be checked if the program has appropriate privilege.
475
476Administration
477
478Smack supports some mount options:
479
480 smackfsdef=label: specifies the label to give files that lack
481 the Smack label extended attribute.
482
483 smackfsroot=label: specifies the label to assign the root of the
484 file system if it lacks the Smack extended attribute.
485
486 smackfshat=label: specifies a label that must have read access to
487 all labels set on the filesystem. Not yet enforced.
488
489 smackfsfloor=label: specifies a label to which all labels set on the
490 filesystem must have read access. Not yet enforced.
491
492These mount options apply to all file system types.
493
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 0b1b0c008613..e2799b5fafea 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1315,13 +1315,28 @@ for writeout by the pdflush daemons. It is expressed in 100'ths of a second.
1315Data which has been dirty in-memory for longer than this interval will be 1315Data which has been dirty in-memory for longer than this interval will be
1316written out next time a pdflush daemon wakes up. 1316written out next time a pdflush daemon wakes up.
1317 1317
1318highmem_is_dirtyable
1319--------------------
1320
1321Only present if CONFIG_HIGHMEM is set.
1322
1323This defaults to 0 (false), meaning that the ratios set above are calculated
1324as a percentage of lowmem only. This protects against excessive scanning
1325in page reclaim, swapping and general VM distress.
1326
1327Setting this to 1 can be useful on 32 bit machines where you want to make
1328random changes within an MMAPed file that is larger than your available
1329lowmem without causing large quantities of random IO. Is is safe if the
1330behavior of all programs running on the machine is known and memory will
1331not be otherwise stressed.
1332
1318legacy_va_layout 1333legacy_va_layout
1319---------------- 1334----------------
1320 1335
1321If non-zero, this sysctl disables the new 32-bit mmap mmap layout - the kernel 1336If non-zero, this sysctl disables the new 32-bit mmap mmap layout - the kernel
1322will use the legacy (2.4) layout for all processes. 1337will use the legacy (2.4) layout for all processes.
1323 1338
1324lower_zone_protection 1339lowmem_reserve_ratio
1325--------------------- 1340---------------------
1326 1341
1327For some specialised workloads on highmem machines it is dangerous for 1342For some specialised workloads on highmem machines it is dangerous for
@@ -1341,25 +1356,71 @@ captured into pinned user memory.
1341mechanism will also defend that region from allocations which could use 1356mechanism will also defend that region from allocations which could use
1342highmem or lowmem). 1357highmem or lowmem).
1343 1358
1344The `lower_zone_protection' tunable determines how aggressive the kernel is 1359The `lowmem_reserve_ratio' tunable determines how aggressive the kernel is
1345in defending these lower zones. The default value is zero - no 1360in defending these lower zones.
1346protection at all.
1347 1361
1348If you have a machine which uses highmem or ISA DMA and your 1362If you have a machine which uses highmem or ISA DMA and your
1349applications are using mlock(), or if you are running with no swap then 1363applications are using mlock(), or if you are running with no swap then
1350you probably should increase the lower_zone_protection setting. 1364you probably should change the lowmem_reserve_ratio setting.
1351 1365
1352The units of this tunable are fairly vague. It is approximately equal 1366The lowmem_reserve_ratio is an array. You can see them by reading this file.
1353to "megabytes," so setting lower_zone_protection=100 will protect around 100 1367-
1354megabytes of the lowmem zone from user allocations. It will also make 1368% cat /proc/sys/vm/lowmem_reserve_ratio
1355those 100 megabytes unavailable for use by applications and by 1369256 256 32
1356pagecache, so there is a cost. 1370-
1357 1371Note: # of this elements is one fewer than number of zones. Because the highest
1358The effects of this tunable may be observed by monitoring 1372 zone's value is not necessary for following calculation.
1359/proc/meminfo:LowFree. Write a single huge file and observe the point 1373
1360at which LowFree ceases to fall. 1374But, these values are not used directly. The kernel calculates # of protection
1361 1375pages for each zones from them. These are shown as array of protection pages
1362A reasonable value for lower_zone_protection is 100. 1376in /proc/zoneinfo like followings. (This is an example of x86-64 box).
1377Each zone has an array of protection pages like this.
1378
1379-
1380Node 0, zone DMA
1381 pages free 1355
1382 min 3
1383 low 3
1384 high 4
1385 :
1386 :
1387 numa_other 0
1388 protection: (0, 2004, 2004, 2004)
1389 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1390 pagesets
1391 cpu: 0 pcp: 0
1392 :
1393-
1394These protections are added to score to judge whether this zone should be used
1395for page allocation or should be reclaimed.
1396
1397In this example, if normal pages (index=2) are required to this DMA zone and
1398pages_high is used for watermark, the kernel judges this zone should not be
1399used because pages_free(1355) is smaller than watermark + protection[2]
1400(4 + 2004 = 2008). If this protection value is 0, this zone would be used for
1401normal page requirement. If requirement is DMA zone(index=0), protection[0]
1402(=0) is used.
1403
1404zone[i]'s protection[j] is calculated by following exprssion.
1405
1406(i < j):
1407 zone[i]->protection[j]
1408 = (total sums of present_pages from zone[i+1] to zone[j] on the node)
1409 / lowmem_reserve_ratio[i];
1410(i = j):
1411 (should not be protected. = 0;
1412(i > j):
1413 (not necessary, but looks 0)
1414
1415The default values of lowmem_reserve_ratio[i] are
1416 256 (if zone[i] means DMA or DMA32 zone)
1417 32 (others).
1418As above expression, they are reciprocal number of ratio.
1419256 means 1/256. # of protection pages becomes about "0.39%" of total present
1420pages of higher zones on the node.
1421
1422If you would like to protect more pages, smaller values are effective.
1423The minimum value is 1 (1/1 -> 100%).
1363 1424
1364page-cluster 1425page-cluster
1365------------ 1426------------
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index 6bc2ba215df9..8da724e2a0ff 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -32,7 +32,7 @@ The exact capabilities of GPIOs vary between systems. Common options:
32 - Input values are likewise readable (1, 0). Some chips support readback 32 - Input values are likewise readable (1, 0). Some chips support readback
33 of pins configured as "output", which is very useful in such "wire-OR" 33 of pins configured as "output", which is very useful in such "wire-OR"
34 cases (to support bidirectional signaling). GPIO controllers may have 34 cases (to support bidirectional signaling). GPIO controllers may have
35 input de-glitch logic, sometimes with software controls. 35 input de-glitch/debounce logic, sometimes with software controls.
36 36
37 - Inputs can often be used as IRQ signals, often edge triggered but 37 - Inputs can often be used as IRQ signals, often edge triggered but
38 sometimes level triggered. Such IRQs may be configurable as system 38 sometimes level triggered. Such IRQs may be configurable as system
@@ -60,10 +60,13 @@ used on a board that's wired differently. Only least-common-denominator
60functionality can be very portable. Other features are platform-specific, 60functionality can be very portable. Other features are platform-specific,
61and that can be critical for glue logic. 61and that can be critical for glue logic.
62 62
63Plus, this doesn't define an implementation framework, just an interface. 63Plus, this doesn't require any implementation framework, just an interface.
64One platform might implement it as simple inline functions accessing chip 64One platform might implement it as simple inline functions accessing chip
65registers; another might implement it by delegating through abstractions 65registers; another might implement it by delegating through abstractions
66used for several very different kinds of GPIO controller. 66used for several very different kinds of GPIO controller. (There is some
67optional code supporting such an implementation strategy, described later
68in this document, but drivers acting as clients to the GPIO interface must
69not care how it's implemented.)
67 70
68That said, if the convention is supported on their platform, drivers should 71That said, if the convention is supported on their platform, drivers should
69use it when possible. Platforms should declare GENERIC_GPIO support in 72use it when possible. Platforms should declare GENERIC_GPIO support in
@@ -121,6 +124,11 @@ before tasking is enabled, as part of early board setup.
121For output GPIOs, the value provided becomes the initial output value. 124For output GPIOs, the value provided becomes the initial output value.
122This helps avoid signal glitching during system startup. 125This helps avoid signal glitching during system startup.
123 126
127For compatibility with legacy interfaces to GPIOs, setting the direction
128of a GPIO implicitly requests that GPIO (see below) if it has not been
129requested already. That compatibility may be removed in the future;
130explicitly requesting GPIOs is strongly preferred.
131
124Setting the direction can fail if the GPIO number is invalid, or when 132Setting the direction can fail if the GPIO number is invalid, or when
125that particular GPIO can't be used in that mode. It's generally a bad 133that particular GPIO can't be used in that mode. It's generally a bad
126idea to rely on boot firmware to have set the direction correctly, since 134idea to rely on boot firmware to have set the direction correctly, since
@@ -133,6 +141,7 @@ Spinlock-Safe GPIO access
133------------------------- 141-------------------------
134Most GPIO controllers can be accessed with memory read/write instructions. 142Most GPIO controllers can be accessed with memory read/write instructions.
135That doesn't need to sleep, and can safely be done from inside IRQ handlers. 143That doesn't need to sleep, and can safely be done from inside IRQ handlers.
144(That includes hardirq contexts on RT kernels.)
136 145
137Use these calls to access such GPIOs: 146Use these calls to access such GPIOs:
138 147
@@ -145,7 +154,7 @@ Use these calls to access such GPIOs:
145The values are boolean, zero for low, nonzero for high. When reading the 154The values are boolean, zero for low, nonzero for high. When reading the
146value of an output pin, the value returned should be what's seen on the 155value of an output pin, the value returned should be what's seen on the
147pin ... that won't always match the specified output value, because of 156pin ... that won't always match the specified output value, because of
148issues including wire-OR and output latencies. 157issues including open-drain signaling and output latencies.
149 158
150The get/set calls have no error returns because "invalid GPIO" should have 159The get/set calls have no error returns because "invalid GPIO" should have
151been reported earlier from gpio_direction_*(). However, note that not all 160been reported earlier from gpio_direction_*(). However, note that not all
@@ -170,7 +179,8 @@ get to the head of a queue to transmit a command and get its response.
170This requires sleeping, which can't be done from inside IRQ handlers. 179This requires sleeping, which can't be done from inside IRQ handlers.
171 180
172Platforms that support this type of GPIO distinguish them from other GPIOs 181Platforms that support this type of GPIO distinguish them from other GPIOs
173by returning nonzero from this call: 182by returning nonzero from this call (which requires a valid GPIO number,
183either explicitly or implicitly requested):
174 184
175 int gpio_cansleep(unsigned gpio); 185 int gpio_cansleep(unsigned gpio);
176 186
@@ -209,8 +219,11 @@ before tasking is enabled, as part of early board setup.
209These calls serve two basic purposes. One is marking the signals which 219These calls serve two basic purposes. One is marking the signals which
210are actually in use as GPIOs, for better diagnostics; systems may have 220are actually in use as GPIOs, for better diagnostics; systems may have
211several hundred potential GPIOs, but often only a dozen are used on any 221several hundred potential GPIOs, but often only a dozen are used on any
212given board. Another is to catch conflicts between drivers, reporting 222given board. Another is to catch conflicts, identifying errors when
213errors when drivers wrongly think they have exclusive use of that signal. 223(a) two or more drivers wrongly think they have exclusive use of that
224signal, or (b) something wrongly believes it's safe to remove drivers
225needed to manage a signal that's in active use. That is, requesting a
226GPIO can serve as a kind of lock.
214 227
215These two calls are optional because not not all current Linux platforms 228These two calls are optional because not not all current Linux platforms
216offer such functionality in their GPIO support; a valid implementation 229offer such functionality in their GPIO support; a valid implementation
@@ -223,6 +236,9 @@ Note that requesting a GPIO does NOT cause it to be configured in any
223way; it just marks that GPIO as in use. Separate code must handle any 236way; it just marks that GPIO as in use. Separate code must handle any
224pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown). 237pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown).
225 238
239Also note that it's your responsibility to have stopped using a GPIO
240before you free it.
241
226 242
227GPIOs mapped to IRQs 243GPIOs mapped to IRQs
228-------------------- 244--------------------
@@ -238,7 +254,7 @@ map between them using calls like:
238 254
239Those return either the corresponding number in the other namespace, or 255Those return either the corresponding number in the other namespace, or
240else a negative errno code if the mapping can't be done. (For example, 256else a negative errno code if the mapping can't be done. (For example,
241some GPIOs can't used as IRQs.) It is an unchecked error to use a GPIO 257some GPIOs can't be used as IRQs.) It is an unchecked error to use a GPIO
242number that wasn't set up as an input using gpio_direction_input(), or 258number that wasn't set up as an input using gpio_direction_input(), or
243to use an IRQ number that didn't originally come from gpio_to_irq(). 259to use an IRQ number that didn't originally come from gpio_to_irq().
244 260
@@ -299,17 +315,110 @@ Related to multiplexing is configuration and enabling of the pullups or
299pulldowns integrated on some platforms. Not all platforms support them, 315pulldowns integrated on some platforms. Not all platforms support them,
300or support them in the same way; and any given board might use external 316or support them in the same way; and any given board might use external
301pullups (or pulldowns) so that the on-chip ones should not be used. 317pullups (or pulldowns) so that the on-chip ones should not be used.
318(When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.)
302 319
303There are other system-specific mechanisms that are not specified here, 320There are other system-specific mechanisms that are not specified here,
304like the aforementioned options for input de-glitching and wire-OR output. 321like the aforementioned options for input de-glitching and wire-OR output.
305Hardware may support reading or writing GPIOs in gangs, but that's usually 322Hardware may support reading or writing GPIOs in gangs, but that's usually
306configuration dependent: for GPIOs sharing the same bank. (GPIOs are 323configuration dependent: for GPIOs sharing the same bank. (GPIOs are
307commonly grouped in banks of 16 or 32, with a given SOC having several such 324commonly grouped in banks of 16 or 32, with a given SOC having several such
308banks.) Some systems can trigger IRQs from output GPIOs. Code relying on 325banks.) Some systems can trigger IRQs from output GPIOs, or read values
309such mechanisms will necessarily be nonportable. 326from pins not managed as GPIOs. Code relying on such mechanisms will
327necessarily be nonportable.
310 328
311Dynamic definition of GPIOs is not currently supported; for example, as 329Dynamic definition of GPIOs is not currently standard; for example, as
312a side effect of configuring an add-on board with some GPIO expanders. 330a side effect of configuring an add-on board with some GPIO expanders.
313 331
314These calls are purely for kernel space, but a userspace API could be built 332These calls are purely for kernel space, but a userspace API could be built
315on top of it. 333on top of them.
334
335
336GPIO implementor's framework (OPTIONAL)
337=======================================
338As noted earlier, there is an optional implementation framework making it
339easier for platforms to support different kinds of GPIO controller using
340the same programming interface.
341
342As a debugging aid, if debugfs is available a /sys/kernel/debug/gpio file
343will be found there. That will list all the controllers registered through
344this framework, and the state of the GPIOs currently in use.
345
346
347Controller Drivers: gpio_chip
348-----------------------------
349In this framework each GPIO controller is packaged as a "struct gpio_chip"
350with information common to each controller of that type:
351
352 - methods to establish GPIO direction
353 - methods used to access GPIO values
354 - flag saying whether calls to its methods may sleep
355 - optional debugfs dump method (showing extra state like pullup config)
356 - label for diagnostics
357
358There is also per-instance data, which may come from device.platform_data:
359the number of its first GPIO, and how many GPIOs it exposes.
360
361The code implementing a gpio_chip should support multiple instances of the
362controller, possibly using the driver model. That code will configure each
363gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be
364rare; use gpiochip_remove() when it is unavoidable.
365
366Most often a gpio_chip is part of an instance-specific structure with state
367not exposed by the GPIO interfaces, such as addressing, power management,
368and more. Chips such as codecs will have complex non-GPIO state,
369
370Any debugfs dump method should normally ignore signals which haven't been
371requested as GPIOs. They can use gpiochip_is_requested(), which returns
372either NULL or the label associated with that GPIO when it was requested.
373
374
375Platform Support
376----------------
377To support this framework, a platform's Kconfig will "select HAVE_GPIO_LIB"
378and arrange that its <asm/gpio.h> includes <asm-generic/gpio.h> and defines
379three functions: gpio_get_value(), gpio_set_value(), and gpio_cansleep().
380They may also want to provide a custom value for ARCH_NR_GPIOS.
381
382Trivial implementations of those functions can directly use framework
383code, which always dispatches through the gpio_chip:
384
385 #define gpio_get_value __gpio_get_value
386 #define gpio_set_value __gpio_set_value
387 #define gpio_cansleep __gpio_cansleep
388
389Fancier implementations could instead define those as inline functions with
390logic optimizing access to specific SOC-based GPIOs. For example, if the
391referenced GPIO is the constant "12", getting or setting its value could
392cost as little as two or three instructions, never sleeping. When such an
393optimization is not possible those calls must delegate to the framework
394code, costing at least a few dozen instructions. For bitbanged I/O, such
395instruction savings can be significant.
396
397For SOCs, platform-specific code defines and registers gpio_chip instances
398for each bank of on-chip GPIOs. Those GPIOs should be numbered/labeled to
399match chip vendor documentation, and directly match board schematics. They
400may well start at zero and go up to a platform-specific limit. Such GPIOs
401are normally integrated into platform initialization to make them always be
402available, from arch_initcall() or earlier; they can often serve as IRQs.
403
404
405Board Support
406-------------
407For external GPIO controllers -- such as I2C or SPI expanders, ASICs, multi
408function devices, FPGAs or CPLDs -- most often board-specific code handles
409registering controller devices and ensures that their drivers know what GPIO
410numbers to use with gpiochip_add(). Their numbers often start right after
411platform-specific GPIOs.
412
413For example, board setup code could create structures identifying the range
414of GPIOs that chip will expose, and passes them to each GPIO expander chip
415using platform_data. Then the chip driver's probe() routine could pass that
416data to gpiochip_add().
417
418Initialization order can be important. For example, when a device relies on
419an I2C-based GPIO, its probe() routine should only be called after that GPIO
420becomes available. That may mean the device should not be registered until
421calls for that GPIO can work. One way to address such dependencies is for
422such gpio_chip controllers to provide setup() and teardown() callbacks to
423board specific code; those board specific callbacks would register devices
424once all the necessary resources are available.
diff --git a/Documentation/i2c/chips/pca9539 b/Documentation/i2c/chips/pca9539
index c4fce6a13537..1d81c530c4a5 100644
--- a/Documentation/i2c/chips/pca9539
+++ b/Documentation/i2c/chips/pca9539
@@ -1,6 +1,9 @@
1Kernel driver pca9539 1Kernel driver pca9539
2===================== 2=====================
3 3
4NOTE: this driver is deprecated and will be dropped soon, use
5drivers/gpio/pca9539.c instead.
6
4Supported chips: 7Supported chips:
5 * Philips PCA9539 8 * Philips PCA9539
6 Prefix: 'pca9539' 9 Prefix: 'pca9539'
diff --git a/Documentation/ia64/aliasing-test.c b/Documentation/ia64/aliasing-test.c
index 773a814d4093..d23610fb2ff9 100644
--- a/Documentation/ia64/aliasing-test.c
+++ b/Documentation/ia64/aliasing-test.c
@@ -16,6 +16,7 @@
16#include <fcntl.h> 16#include <fcntl.h>
17#include <fnmatch.h> 17#include <fnmatch.h>
18#include <string.h> 18#include <string.h>
19#include <sys/ioctl.h>
19#include <sys/mman.h> 20#include <sys/mman.h>
20#include <sys/stat.h> 21#include <sys/stat.h>
21#include <unistd.h> 22#include <unistd.h>
@@ -65,7 +66,7 @@ int scan_tree(char *path, char *file, off_t offset, size_t length, int touch)
65{ 66{
66 struct dirent **namelist; 67 struct dirent **namelist;
67 char *name, *path2; 68 char *name, *path2;
68 int i, n, r, rc, result = 0; 69 int i, n, r, rc = 0, result = 0;
69 struct stat buf; 70 struct stat buf;
70 71
71 n = scandir(path, &namelist, 0, alphasort); 72 n = scandir(path, &namelist, 0, alphasort);
@@ -113,7 +114,7 @@ skip:
113 free(namelist[i]); 114 free(namelist[i]);
114 } 115 }
115 free(namelist); 116 free(namelist);
116 return rc; 117 return result;
117} 118}
118 119
119char buf[1024]; 120char buf[1024];
@@ -149,7 +150,7 @@ int scan_rom(char *path, char *file)
149{ 150{
150 struct dirent **namelist; 151 struct dirent **namelist;
151 char *name, *path2; 152 char *name, *path2;
152 int i, n, r, rc, result = 0; 153 int i, n, r, rc = 0, result = 0;
153 struct stat buf; 154 struct stat buf;
154 155
155 n = scandir(path, &namelist, 0, alphasort); 156 n = scandir(path, &namelist, 0, alphasort);
@@ -180,7 +181,7 @@ int scan_rom(char *path, char *file)
180 * important thing is that no MCA happened. 181 * important thing is that no MCA happened.
181 */ 182 */
182 if (rc > 0) 183 if (rc > 0)
183 fprintf(stderr, "PASS: %s read %ld bytes\n", path2, rc); 184 fprintf(stderr, "PASS: %s read %d bytes\n", path2, rc);
184 else { 185 else {
185 fprintf(stderr, "PASS: %s not readable\n", path2); 186 fprintf(stderr, "PASS: %s not readable\n", path2);
186 return rc; 187 return rc;
@@ -201,10 +202,10 @@ skip:
201 free(namelist[i]); 202 free(namelist[i]);
202 } 203 }
203 free(namelist); 204 free(namelist);
204 return rc; 205 return result;
205} 206}
206 207
207int main() 208int main(void)
208{ 209{
209 int rc; 210 int rc;
210 211
@@ -256,4 +257,6 @@ int main()
256 scan_tree("/proc/bus/pci", "??.?", 0xA0000, 0x20000, 0); 257 scan_tree("/proc/bus/pci", "??.?", 0xA0000, 0x20000, 0);
257 scan_tree("/proc/bus/pci", "??.?", 0xC0000, 0x40000, 1); 258 scan_tree("/proc/bus/pci", "??.?", 0xC0000, 0x40000, 1);
258 scan_tree("/proc/bus/pci", "??.?", 0, 1024*1024, 0); 259 scan_tree("/proc/bus/pci", "??.?", 0, 1024*1024, 0);
260
261 return rc;
259} 262}
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 9ad4e6fc56fd..8fd5aa40585f 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -780,6 +780,9 @@ and is between 256 and 4096 characters. It is defined in the file
780 loop use the MONITOR/MWAIT idle loop anyways. Performance should be the same 780 loop use the MONITOR/MWAIT idle loop anyways. Performance should be the same
781 as idle=poll. 781 as idle=poll.
782 782
783 ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem
784 Claim all unknown PCI IDE storage controllers.
785
783 ignore_loglevel [KNL] 786 ignore_loglevel [KNL]
784 Ignore loglevel setting - this will print /all/ 787 Ignore loglevel setting - this will print /all/
785 kernel messages to the console. Useful for debugging. 788 kernel messages to the console. Useful for debugging.
diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt
index 4739c5c3face..96f155e68750 100644
--- a/Documentation/pcmcia/driver-changes.txt
+++ b/Documentation/pcmcia/driver-changes.txt
@@ -33,8 +33,8 @@ This file details changes in 2.6 which affect PCMCIA card driver authors:
33 and can be used (e.g. for SET_NETDEV_DEV) by using 33 and can be used (e.g. for SET_NETDEV_DEV) by using
34 handle_to_dev(client_handle_t * handle). 34 handle_to_dev(client_handle_t * handle).
35 35
36* Convert internal I/O port addresses to unsigned long (as of 2.6.11) 36* Convert internal I/O port addresses to unsigned int (as of 2.6.11)
37 ioaddr_t should be replaced by kio_addr_t in PCMCIA card drivers. 37 ioaddr_t should be replaced by unsigned int in PCMCIA card drivers.
38 38
39* irq_mask and irq_list parameters (as of 2.6.11) 39* irq_mask and irq_list parameters (as of 2.6.11)
40 The irq_mask and irq_list parameters should no longer be used in 40 The irq_mask and irq_list parameters should no longer be used in
diff --git a/Documentation/pm_qos_interface.txt b/Documentation/pm_qos_interface.txt
new file mode 100644
index 000000000000..49adb1a33514
--- /dev/null
+++ b/Documentation/pm_qos_interface.txt
@@ -0,0 +1,59 @@
1PM quality of Service interface.
2
3This interface provides a kernel and user mode interface for registering
4performance expectations by drivers, subsystems and user space applications on
5one of the parameters.
6
7Currently we have {cpu_dma_latency, network_latency, network_throughput} as the
8initial set of pm_qos parameters.
9
10The infrastructure exposes multiple misc device nodes one per implemented
11parameter. The set of parameters implement is defined by pm_qos_power_init()
12and pm_qos_params.h. This is done because having the available parameters
13being runtime configurable or changeable from a driver was seen as too easy to
14abuse.
15
16For each parameter a list of performance requirements is maintained along with
17an aggregated target value. The aggregated target value is updated with
18changes to the requirement list or elements of the list. Typically the
19aggregated target value is simply the max or min of the requirement values held
20in the parameter list elements.
21
22From kernel mode the use of this interface is simple:
23pm_qos_add_requirement(param_id, name, target_value):
24Will insert a named element in the list for that identified PM_QOS parameter
25with the target value. Upon change to this list the new target is recomputed
26and any registered notifiers are called only if the target value is now
27different.
28
29pm_qos_update_requirement(param_id, name, new_target_value):
30Will search the list identified by the param_id for the named list element and
31then update its target value, calling the notification tree if the aggregated
32target is changed. with that name is already registered.
33
34pm_qos_remove_requirement(param_id, name):
35Will search the identified list for the named element and remove it, after
36removal it will update the aggregate target and call the notification tree if
37the target was changed as a result of removing the named requirement.
38
39
40From user mode:
41Only processes can register a pm_qos requirement. To provide for automatic
42cleanup for process the interface requires the process to register its
43parameter requirements in the following way:
44
45To register the default pm_qos target for the specific parameter, the process
46must open one of /dev/[cpu_dma_latency, network_latency, network_throughput]
47
48As long as the device node is held open that process has a registered
49requirement on the parameter. The name of the requirement is "process_<PID>"
50derived from the current->pid from within the open system call.
51
52To change the requested target value the process needs to write a s32 value to
53the open device node. This translates to a pm_qos_update_requirement call.
54
55To remove the user mode request for a target value simply close the device
56node.
57
58
59
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 6f31f0a247d0..24eac1bc735d 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -22,6 +22,7 @@ Currently, these files are in /proc/sys/vm:
22- dirty_background_ratio 22- dirty_background_ratio
23- dirty_expire_centisecs 23- dirty_expire_centisecs
24- dirty_writeback_centisecs 24- dirty_writeback_centisecs
25- highmem_is_dirtyable (only if CONFIG_HIGHMEM set)
25- max_map_count 26- max_map_count
26- min_free_kbytes 27- min_free_kbytes
27- laptop_mode 28- laptop_mode
@@ -40,9 +41,9 @@ Currently, these files are in /proc/sys/vm:
40============================================================== 41==============================================================
41 42
42dirty_ratio, dirty_background_ratio, dirty_expire_centisecs, 43dirty_ratio, dirty_background_ratio, dirty_expire_centisecs,
43dirty_writeback_centisecs, vfs_cache_pressure, laptop_mode, 44dirty_writeback_centisecs, highmem_is_dirtyable,
44block_dump, swap_token_timeout, drop-caches, 45vfs_cache_pressure, laptop_mode, block_dump, swap_token_timeout,
45hugepages_treat_as_movable: 46drop-caches, hugepages_treat_as_movable:
46 47
47See Documentation/filesystems/proc.txt 48See Documentation/filesystems/proc.txt
48 49