<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/Documentation, branch v2.6.32.12</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>i2c-i801: Add Intel Cougar Point device IDs</title>
<updated>2010-04-26T14:41:32+00:00</updated>
<author>
<name>Seth Heasley</name>
<email>seth.heasley@intel.com</email>
</author>
<published>2010-03-02T11:23:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c10fdc2140e1c4de6bde59b1802f7e914d81b38d'/>
<id>c10fdc2140e1c4de6bde59b1802f7e914d81b38d</id>
<content type='text'>
commit 393764340beb595c1ad7dd2d2243c2b6551aaa71 upstream.

Add the Intel Cougar Point (PCH) SMBus controller device IDs.

Signed-off-by: Seth Heasley &lt;seth.heasley@intel.com&gt;
Signed-off-by: Jean Delvare &lt;khali@linux-fr.org&gt;
Cc: maximilian attems &lt;max@stro.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 393764340beb595c1ad7dd2d2243c2b6551aaa71 upstream.

Add the Intel Cougar Point (PCH) SMBus controller device IDs.

Signed-off-by: Seth Heasley &lt;seth.heasley@intel.com&gt;
Signed-off-by: Jean Delvare &lt;khali@linux-fr.org&gt;
Cc: maximilian attems &lt;max@stro.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>thinkpad-acpi: lock down video output state access</title>
<updated>2010-04-26T14:41:22+00:00</updated>
<author>
<name>Henrique de Moraes Holschuh</name>
<email>hmh@hmh.eng.br</email>
</author>
<published>2010-02-26T01:22:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1b0d63f15fb79d0cb840f8b701f343548b5640e8'/>
<id>1b0d63f15fb79d0cb840f8b701f343548b5640e8</id>
<content type='text'>
commit b525c06cdbd8a3963f0173ccd23f9147d4c384b5 upstream.

Given the right combination of ThinkPad and X.org, just reading the
video output control state is enough to hard-crash X.org.

Until the day I somehow find out a model or BIOS cut date to not
provide this feature to ThinkPads that can do video switching through
X RandR, change permissions so that only processes with CAP_SYS_ADMIN
can access any sort of video output control state.

This bug could be considered a local DoS I suppose, as it allows any
non-privledged local user to cause some versions of X.org to
hard-crash some ThinkPads.

Reported-by: Jidanni &lt;jidanni@jidanni.org&gt;
Signed-off-by: Henrique de Moraes Holschuh &lt;hmh@hmh.eng.br&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b525c06cdbd8a3963f0173ccd23f9147d4c384b5 upstream.

Given the right combination of ThinkPad and X.org, just reading the
video output control state is enough to hard-crash X.org.

Until the day I somehow find out a model or BIOS cut date to not
provide this feature to ThinkPads that can do video switching through
X RandR, change permissions so that only processes with CAP_SYS_ADMIN
can access any sort of video output control state.

This bug could be considered a local DoS I suppose, as it allows any
non-privledged local user to cause some versions of X.org to
hard-crash some ThinkPads.

Reported-by: Jidanni &lt;jidanni@jidanni.org&gt;
Signed-off-by: Henrique de Moraes Holschuh &lt;hmh@hmh.eng.br&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>thinkpad-acpi: issue backlight class events</title>
<updated>2010-04-26T14:41:21+00:00</updated>
<author>
<name>Henrique de Moraes Holschuh</name>
<email>hmh@hmh.eng.br</email>
</author>
<published>2009-12-09T01:36:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8bf934d74b1e22fbf206a163653915a12ab67350'/>
<id>8bf934d74b1e22fbf206a163653915a12ab67350</id>
<content type='text'>
commit 347a26860e2293b1347996876d3550499c7bb31f upstream.

Take advantage of the new events capabilities of the backlight class to
notify userspace of backlight changes.

This depends on "backlight: Allow drivers to update the core, and
generate events on changes", by Matthew Garrett.

Signed-off-by: Henrique de Moraes Holschuh &lt;hmh@hmh.eng.br&gt;
Cc: Matthew Garrett &lt;mjg@redhat.com&gt;
Cc: Richard Purdie &lt;rpurdie@linux.intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 347a26860e2293b1347996876d3550499c7bb31f upstream.

Take advantage of the new events capabilities of the backlight class to
notify userspace of backlight changes.

This depends on "backlight: Allow drivers to update the core, and
generate events on changes", by Matthew Garrett.

Signed-off-by: Henrique de Moraes Holschuh &lt;hmh@hmh.eng.br&gt;
Cc: Matthew Garrett &lt;mjg@redhat.com&gt;
Cc: Richard Purdie &lt;rpurdie@linux.intel.com&gt;
Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>doc: add the documentation for mpol=local</title>
<updated>2010-04-01T22:58:28+00:00</updated>
<author>
<name>KOSAKI Motohiro</name>
<email>kosaki.motohiro@jp.fujitsu.com</email>
</author>
<published>2010-03-23T20:35:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=457396780d363fc2bc19301a31d489210bbfe365'/>
<id>457396780d363fc2bc19301a31d489210bbfe365</id>
<content type='text'>
commit 5574169613b40b85d6f4c67208fa4846b897a0a1 upstream.

commit 3f226aa1c (mempolicy: support mpol=local tmpfs mount option) added
new mpol=local mount option.  but it didn't add a documentation.

This patch does it.

Signed-off-by: KOSAKI Motohiro &lt;kosaki.motohiro@jp.fujitsu.com&gt;
Cc: Ravikiran Thirumalai &lt;kiran@scalex86.org&gt;
Cc: Christoph Lameter &lt;cl@linux-foundation.org&gt;
Cc: Mel Gorman &lt;mel@csn.ul.ie&gt;
Acked-by: Lee Schermerhorn &lt;lee.schermerhorn@hp.com&gt;
Cc: Hugh Dickins &lt;hugh.dickins@tiscali.co.uk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5574169613b40b85d6f4c67208fa4846b897a0a1 upstream.

commit 3f226aa1c (mempolicy: support mpol=local tmpfs mount option) added
new mpol=local mount option.  but it didn't add a documentation.

This patch does it.

Signed-off-by: KOSAKI Motohiro &lt;kosaki.motohiro@jp.fujitsu.com&gt;
Cc: Ravikiran Thirumalai &lt;kiran@scalex86.org&gt;
Cc: Christoph Lameter &lt;cl@linux-foundation.org&gt;
Cc: Mel Gorman &lt;mel@csn.ul.ie&gt;
Acked-by: Lee Schermerhorn &lt;lee.schermerhorn@hp.com&gt;
Cc: Hugh Dickins &lt;hugh.dickins@tiscali.co.uk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86, mm: Allow highmem user page tables to be disabled at boot time</title>
<updated>2010-03-15T15:50:18+00:00</updated>
<author>
<name>Ian Campbell</name>
<email>ian.campbell@citrix.com</email>
</author>
<published>2010-02-17T10:38:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1942aeab7ae78a4840a594ce1bf2e29d63fe426f'/>
<id>1942aeab7ae78a4840a594ce1bf2e29d63fe426f</id>
<content type='text'>
commit 14315592009c17035cac81f4954d5a1f4d71e489 upstream.

Distros generally (I looked at Debian, RHEL5 and SLES11) seem to
enable CONFIG_HIGHPTE for any x86 configuration which has highmem
enabled. This means that the overhead applies even to machines which
have a fairly modest amount of high memory and which therefore do not
really benefit from allocating PTEs in high memory but still pay the
price of the additional mapping operations.

Running kernbench on a 4G box I found that with CONFIG_HIGHPTE=y but
no actual highptes being allocated there was a reduction in system
time used from 59.737s to 55.9s.

With CONFIG_HIGHPTE=y and highmem PTEs being allocated:
  Average Optimal load -j 4 Run (std deviation):
  Elapsed Time 175.396 (0.238914)
  User Time 515.983 (5.85019)
  System Time 59.737 (1.26727)
  Percent CPU 263.8 (71.6796)
  Context Switches 39989.7 (4672.64)
  Sleeps 42617.7 (246.307)

With CONFIG_HIGHPTE=y but with no highmem PTEs being allocated:
  Average Optimal load -j 4 Run (std deviation):
  Elapsed Time 174.278 (0.831968)
  User Time 515.659 (6.07012)
  System Time 55.9 (1.07799)
  Percent CPU 263.8 (71.266)
  Context Switches 39929.6 (4485.13)
  Sleeps 42583.7 (373.039)

This patch allows the user to control the allocation of PTEs in
highmem from the command line ("userpte=nohigh") but retains the
status-quo as the default.

It is possible that some simple heuristic could be developed which
allows auto-tuning of this option however I don't have a sufficiently
large machine available to me to perform any particularly meaningful
experiments. We could probably handwave up an argument for a threshold
at 16G of total RAM.

Assuming 768M of lowmem we have 196608 potential lowmem PTE
pages. Each page can map 2M of RAM in a PAE-enabled configuration,
meaning a maximum of 384G of RAM could potentially be mapped using
lowmem PTEs.

Even allowing generous factor of 10 to account for other required
lowmem allocations, generous slop to account for page sharing (which
reduces the total amount of RAM mappable by a given number of PT
pages) and other innacuracies in the estimations it would seem that
even a 32G machine would not have a particularly pressing need for
highmem PTEs. I think 32G could be considered to be at the upper bound
of what might be sensible on a 32 bit machine (although I think in
practice 64G is still supported).

It's seems questionable if HIGHPTE is even a win for any amount of RAM
you would sensibly run a 32 bit kernel on rather than going 64 bit.

Signed-off-by: Ian Campbell &lt;ian.campbell@citrix.com&gt;
LKML-Reference: &lt;1266403090-20162-1-git-send-email-ian.campbell@citrix.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 14315592009c17035cac81f4954d5a1f4d71e489 upstream.

Distros generally (I looked at Debian, RHEL5 and SLES11) seem to
enable CONFIG_HIGHPTE for any x86 configuration which has highmem
enabled. This means that the overhead applies even to machines which
have a fairly modest amount of high memory and which therefore do not
really benefit from allocating PTEs in high memory but still pay the
price of the additional mapping operations.

Running kernbench on a 4G box I found that with CONFIG_HIGHPTE=y but
no actual highptes being allocated there was a reduction in system
time used from 59.737s to 55.9s.

With CONFIG_HIGHPTE=y and highmem PTEs being allocated:
  Average Optimal load -j 4 Run (std deviation):
  Elapsed Time 175.396 (0.238914)
  User Time 515.983 (5.85019)
  System Time 59.737 (1.26727)
  Percent CPU 263.8 (71.6796)
  Context Switches 39989.7 (4672.64)
  Sleeps 42617.7 (246.307)

With CONFIG_HIGHPTE=y but with no highmem PTEs being allocated:
  Average Optimal load -j 4 Run (std deviation):
  Elapsed Time 174.278 (0.831968)
  User Time 515.659 (6.07012)
  System Time 55.9 (1.07799)
  Percent CPU 263.8 (71.266)
  Context Switches 39929.6 (4485.13)
  Sleeps 42583.7 (373.039)

This patch allows the user to control the allocation of PTEs in
highmem from the command line ("userpte=nohigh") but retains the
status-quo as the default.

It is possible that some simple heuristic could be developed which
allows auto-tuning of this option however I don't have a sufficiently
large machine available to me to perform any particularly meaningful
experiments. We could probably handwave up an argument for a threshold
at 16G of total RAM.

Assuming 768M of lowmem we have 196608 potential lowmem PTE
pages. Each page can map 2M of RAM in a PAE-enabled configuration,
meaning a maximum of 384G of RAM could potentially be mapped using
lowmem PTEs.

Even allowing generous factor of 10 to account for other required
lowmem allocations, generous slop to account for page sharing (which
reduces the total amount of RAM mappable by a given number of PT
pages) and other innacuracies in the estimations it would seem that
even a 32G machine would not have a particularly pressing need for
highmem PTEs. I think 32G could be considered to be at the upper bound
of what might be sensible on a 32 bit machine (although I think in
practice 64G is still supported).

It's seems questionable if HIGHPTE is even a win for any amount of RAM
you would sensibly run a 32 bit kernel on rather than going 64 bit.

Signed-off-by: Ian Campbell &lt;ian.campbell@citrix.com&gt;
LKML-Reference: &lt;1266403090-20162-1-git-send-email-ian.campbell@citrix.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@zytor.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>KVM: allow userspace to adjust kvmclock offset</title>
<updated>2010-02-09T12:50:56+00:00</updated>
<author>
<name>Glauber Costa</name>
<email>glommer@redhat.com</email>
</author>
<published>2010-02-01T18:54:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4f7d6662c57dbaa6be09cc0bad2c01d005638a4d'/>
<id>4f7d6662c57dbaa6be09cc0bad2c01d005638a4d</id>
<content type='text'>
(cherry picked from afbcf7ab8d1bc8c2d04792f6d9e786e0adeb328d)

When we migrate a kvm guest that uses pvclock between two hosts, we may
suffer a large skew. This is because there can be significant differences
between the monotonic clock of the hosts involved. When a new host with
a much larger monotonic time starts running the guest, the view of time
will be significantly impacted.

Situation is much worse when we do the opposite, and migrate to a host with
a smaller monotonic clock.

This proposed ioctl will allow userspace to inform us what is the monotonic
clock value in the source host, so we can keep the time skew short, and
more importantly, never goes backwards. Userspace may also need to trigger
the current data, since from the first migration onwards, it won't be
reflected by a simple call to clock_gettime() anymore.

[marcelo: future-proof abi with a flags field]
[jan: fix KVM_GET_CLOCK by clearing flags field instead of checking it]

Signed-off-by: Glauber Costa &lt;glommer@redhat.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
(cherry picked from afbcf7ab8d1bc8c2d04792f6d9e786e0adeb328d)

When we migrate a kvm guest that uses pvclock between two hosts, we may
suffer a large skew. This is because there can be significant differences
between the monotonic clock of the hosts involved. When a new host with
a much larger monotonic time starts running the guest, the view of time
will be significantly impacted.

Situation is much worse when we do the opposite, and migrate to a host with
a smaller monotonic clock.

This proposed ioctl will allow userspace to inform us what is the monotonic
clock value in the source host, so we can keep the time skew short, and
more importantly, never goes backwards. Userspace may also need to trigger
the current data, since from the first migration onwards, it won't be
reflected by a simple call to clock_gettime() anymore.

[marcelo: future-proof abi with a flags field]
[jan: fix KVM_GET_CLOCK by clearing flags field instead of checking it]

Signed-off-by: Glauber Costa &lt;glommer@redhat.com&gt;
Signed-off-by: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>V4L/DVB (13680b): DocBook/media: create links for included sources</title>
<updated>2010-01-28T23:01:03+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2009-12-03T22:51:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=3cd4bea0c43831b242a8562f713122b1b9daf21a'/>
<id>3cd4bea0c43831b242a8562f713122b1b9daf21a</id>
<content type='text'>
commit 5bf583473813530c1bf82051a35fac8d5045f4f7 upstream.

If docs are being built in a separate directory, xmlto and xsltproc
can't find included sources.  Make links back to the source directory.

I would much prefer to have xmlto and xsltproc look in the source
directory for included entities but couldn't see how to do that.  This
needs to be solved in some way for 2.6.32, even if this patch isn't the
right way to do it.

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5bf583473813530c1bf82051a35fac8d5045f4f7 upstream.

If docs are being built in a separate directory, xmlto and xsltproc
can't find included sources.  Make links back to the source directory.

I would much prefer to have xmlto and xsltproc look in the source
directory for included entities but couldn't see how to do that.  This
needs to be solved in some way for 2.6.32, even if this patch isn't the
right way to do it.

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>V4L/DVB (13680a): DocBook/media: copy images after building HTML</title>
<updated>2010-01-28T23:01:02+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2009-12-03T22:50:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=35f42c92098c70fc576e3baa8955db9fb2ba9cb5'/>
<id>35f42c92098c70fc576e3baa8955db9fb2ba9cb5</id>
<content type='text'>
commit 49b14650ba5bf80234cb1984fd8396aff03430ce upstream.

The rule for %.html removes the output directory, so there is no point
in copying images before building HTML.

Documentation/DocBook/Makefile |   10 +++++-----

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 49b14650ba5bf80234cb1984fd8396aff03430ce upstream.

The rule for %.html removes the output directory, so there is no point
in copying images before building HTML.

Documentation/DocBook/Makefile |   10 +++++-----

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>V4L/DVB (13168): Add support for Asus Europa Hybrid DVB-T card (SAA7134 SubVendor ID: 0x1043 Device ID: 0x4847)</title>
<updated>2010-01-28T23:00:56+00:00</updated>
<author>
<name>Danny Wood</name>
<email>danwood76@gmail.com</email>
</author>
<published>2009-09-20T15:14:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=96ef353c45ee9ef98c28c72c1c240c9825c75392'/>
<id>96ef353c45ee9ef98c28c72c1c240c9825c75392</id>
<content type='text'>
commit e3c6e1aaa5db7822524f5b1355960fd732910068 upstream.

Adds the device IDs and driver linking to allow the Asus Europa DVB-T
card to operate with these drivers.
The device has a SAA7134 chipset with a TD1316 Hybrid Tuner.
All inputs work on the card including switching between DVB-T and
Analogue TV, there is also no IR with this card.

[mchehab@redhat.com: CodingStyle fixes]

Signed-off-by: Danny Wood &lt;danwood76@gmail.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e3c6e1aaa5db7822524f5b1355960fd732910068 upstream.

Adds the device IDs and driver linking to allow the Asus Europa DVB-T
card to operate with these drivers.
The device has a SAA7134 chipset with a TD1316 Hybrid Tuner.
All inputs work on the card including switching between DVB-T and
Analogue TV, there is also no IR with this card.

[mchehab@redhat.com: CodingStyle fixes]

Signed-off-by: Danny Wood &lt;danwood76@gmail.com&gt;
Cc: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: Update documentation to correct the inode_readahead_blks option name</title>
<updated>2010-01-06T23:05:18+00:00</updated>
<author>
<name>Fang Wenqi</name>
<email>anton.fang@gmail.com</email>
</author>
<published>2009-12-24T22:51:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=743c078e0e10e41b8b10f3c07973068d76fcc866'/>
<id>743c078e0e10e41b8b10f3c07973068d76fcc866</id>
<content type='text'>
commit 6d3b82f2d31f22085e5711b28dddcb9fb3d97a25 upstream.

Per commit 240799cd, the option name for readahead should be
inode_readahead_blks, not inode_readahead.

Signed-off-by: Fang Wenqi &lt;antonf@turbolinux.com.cn&gt;
Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6d3b82f2d31f22085e5711b28dddcb9fb3d97a25 upstream.

Per commit 240799cd, the option name for readahead should be
inode_readahead_blks, not inode_readahead.

Signed-off-by: Fang Wenqi &lt;antonf@turbolinux.com.cn&gt;
Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
