<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/char, branch v2.6.33</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip</title>
<updated>2010-02-11T22:01:10+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2010-02-11T22:01:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5ea8d3759244590defd369828c965101c97b65e1'/>
<id>5ea8d3759244590defd369828c965101c97b65e1</id>
<content type='text'>
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  x86, apic: Don't use logical-flat mode when CPU hotplug may exceed 8 CPUs
  x86-32: Make AT_VECTOR_SIZE_ARCH=2
  x86/agp: Fix amd64-agp module initialization regression
  x86, doc: Fix minor spelling error in arch/x86/mm/gup.c
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  x86, apic: Don't use logical-flat mode when CPU hotplug may exceed 8 CPUs
  x86-32: Make AT_VECTOR_SIZE_ARCH=2
  x86/agp: Fix amd64-agp module initialization regression
  x86, doc: Fix minor spelling error in arch/x86/mm/gup.c
</pre>
</div>
</content>
</entry>
<entry>
<title>tpm_infineon: fix suspend/resume handler for pnp_driver</title>
<updated>2010-02-11T21:59:42+00:00</updated>
<author>
<name>Marcel Selhorst</name>
<email>m.selhorst@sirrix.com</email>
</author>
<published>2010-02-10T21:56:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=93716b9470fbfd9efdc7d0f2445cb34635de3f6d'/>
<id>93716b9470fbfd9efdc7d0f2445cb34635de3f6d</id>
<content type='text'>
When suspending, tpm_infineon calls the generic suspend function of the
TPM framework.  However, the TPM framework does not return and the system
hangs upon suspend.  When sending the necessary command "TPM_SaveState"
directly within the driver, suspending and resuming works fine.

Signed-off-by: Marcel Selhorst &lt;m.selhorst@sirrix.com&gt;
Cc: OGAWA Hirofumi &lt;hirofumi@mail.parknet.co.jp&gt;
Cc: Debora Velarde &lt;debora@linux.vnet.ibm.com&gt;
Cc: Rajiv Andrade &lt;srajiv@linux.vnet.ibm.com&gt;
Cc: &lt;stable@kernel.org&gt;		[2.6.32.x]
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When suspending, tpm_infineon calls the generic suspend function of the
TPM framework.  However, the TPM framework does not return and the system
hangs upon suspend.  When sending the necessary command "TPM_SaveState"
directly within the driver, suspending and resuming works fine.

Signed-off-by: Marcel Selhorst &lt;m.selhorst@sirrix.com&gt;
Cc: OGAWA Hirofumi &lt;hirofumi@mail.parknet.co.jp&gt;
Cc: Debora Velarde &lt;debora@linux.vnet.ibm.com&gt;
Cc: Rajiv Andrade &lt;srajiv@linux.vnet.ibm.com&gt;
Cc: &lt;stable@kernel.org&gt;		[2.6.32.x]
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix race in tty_fasync() properly</title>
<updated>2010-02-07T18:26:01+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2010-02-07T18:11:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=80e1e823989ec44d8e35bdfddadbddcffec90424'/>
<id>80e1e823989ec44d8e35bdfddadbddcffec90424</id>
<content type='text'>
This reverts commit 703625118069 ("tty: fix race in tty_fasync") and
commit b04da8bfdfbb ("fnctl: f_modown should call write_lock_irqsave/
restore") that tried to fix up some of the fallout but was incomplete.

It turns out that we really cannot hold 'tty-&gt;ctrl_lock' over calling
__f_setown, because not only did that cause problems with interrupt
disables (which the second commit fixed), it also causes a potential
ABBA deadlock due to lock ordering.

Thanks to Tetsuo Handa for following up on the issue, and running
lockdep to show the problem.  It goes roughly like this:

 - f_getown gets filp-&gt;f_owner.lock for reading without interrupts
   disabled, so an interrupt that happens while that lock is held can
   cause a lockdep chain from f_owner.lock -&gt; sighand-&gt;siglock.

 - at the same time, the tty-&gt;ctrl_lock -&gt; f_owner.lock chain that
   commit 703625118069 introduced, together with the pre-existing
   sighand-&gt;siglock -&gt; tty-&gt;ctrl_lock chain means that we have a lock
   dependency the other way too.

So instead of extending tty-&gt;ctrl_lock over the whole __f_setown() call,
we now just take a reference to the 'pid' structure while holding the
lock, and then release it after having done the __f_setown.  That still
guarantees that 'struct pid' won't go away from under us, which is all
we really ever needed.

Reported-and-tested-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Acked-by: Américo Wang &lt;xiyou.wangcong@gmail.com&gt;
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 703625118069 ("tty: fix race in tty_fasync") and
commit b04da8bfdfbb ("fnctl: f_modown should call write_lock_irqsave/
restore") that tried to fix up some of the fallout but was incomplete.

It turns out that we really cannot hold 'tty-&gt;ctrl_lock' over calling
__f_setown, because not only did that cause problems with interrupt
disables (which the second commit fixed), it also causes a potential
ABBA deadlock due to lock ordering.

Thanks to Tetsuo Handa for following up on the issue, and running
lockdep to show the problem.  It goes roughly like this:

 - f_getown gets filp-&gt;f_owner.lock for reading without interrupts
   disabled, so an interrupt that happens while that lock is held can
   cause a lockdep chain from f_owner.lock -&gt; sighand-&gt;siglock.

 - at the same time, the tty-&gt;ctrl_lock -&gt; f_owner.lock chain that
   commit 703625118069 introduced, together with the pre-existing
   sighand-&gt;siglock -&gt; tty-&gt;ctrl_lock chain means that we have a lock
   dependency the other way too.

So instead of extending tty-&gt;ctrl_lock over the whole __f_setown() call,
we now just take a reference to the 'pid' structure while holding the
lock, and then release it after having done the __f_setown.  That still
guarantees that 'struct pid' won't go away from under us, which is all
we really ever needed.

Reported-and-tested-by: Tetsuo Handa &lt;penguin-kernel@I-love.SAKURA.ne.jp&gt;
Acked-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Acked-by: Américo Wang &lt;xiyou.wangcong@gmail.com&gt;
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86/agp: Fix amd64-agp module initialization regression</title>
<updated>2010-02-04T06:27:26+00:00</updated>
<author>
<name>FUJITA Tomonori</name>
<email>fujita.tomonori@lab.ntt.co.jp</email>
</author>
<published>2010-02-04T05:43:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=06df6dafb5d9e3cfa3588c6ce79328b91582b6af'/>
<id>06df6dafb5d9e3cfa3588c6ce79328b91582b6af</id>
<content type='text'>
This fixes the regression introduced by commit
42590a75019a50012f25a962246498dead428433 ("x86/agp: Fix
agp_amd64_init and agp_amd64_cleanup").

The commit 61684ceaad4f65d1a9832c722f7bd5e7fc714de9 fixed the
above regression but it's not enough. When amd64-agp is built as
a module, AGP isn't initialized, iommu is initialized, all the
aperture is owned by the iommu.

Reported-by: Marin Mitov &lt;mitov@issp.bas.bg&gt;
Signed-off-by: FUJITA Tomonori &lt;fujita.tomonori@lab.ntt.co.jp&gt;
Tested-by: Marin Mitov &lt;mitov@issp.bas.bg&gt;
LKML-Reference: &lt;20100204090802S.fujita.tomonori@lab.ntt.co.jp&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes the regression introduced by commit
42590a75019a50012f25a962246498dead428433 ("x86/agp: Fix
agp_amd64_init and agp_amd64_cleanup").

The commit 61684ceaad4f65d1a9832c722f7bd5e7fc714de9 fixed the
above regression but it's not enough. When amd64-agp is built as
a module, AGP isn't initialized, iommu is initialized, all the
aperture is owned by the iommu.

Reported-by: Marin Mitov &lt;mitov@issp.bas.bg&gt;
Signed-off-by: FUJITA Tomonori &lt;fujita.tomonori@lab.ntt.co.jp&gt;
Tested-by: Marin Mitov &lt;mitov@issp.bas.bg&gt;
LKML-Reference: &lt;20100204090802S.fujita.tomonori@lab.ntt.co.jp&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>devmem: fix kmem write bug on memory holes</title>
<updated>2010-02-03T02:11:22+00:00</updated>
<author>
<name>Wu Fengguang</name>
<email>fengguang.wu@intel.com</email>
</author>
<published>2010-02-02T21:44:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c85e9a97c4102ce2e83112da850d838cfab5ab13'/>
<id>c85e9a97c4102ce2e83112da850d838cfab5ab13</id>
<content type='text'>
write_kmem() used to assume vwrite() always return the full buffer length.
However now vwrite() could return 0 to indicate memory hole.  This
creates a bug that "buf" is not advanced accordingly.

Fix it to simply ignore the return value, hence the memory hole.

Signed-off-by: Wu Fengguang &lt;fengguang.wu@intel.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Christoph Lameter &lt;cl@linux-foundation.org&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Nick Piggin &lt;npiggin@suse.de&gt;
Cc: KAMEZAWA Hiroyuki &lt;kamezawa.hiroyu@jp.fujitsu.com&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
write_kmem() used to assume vwrite() always return the full buffer length.
However now vwrite() could return 0 to indicate memory hole.  This
creates a bug that "buf" is not advanced accordingly.

Fix it to simply ignore the return value, hence the memory hole.

Signed-off-by: Wu Fengguang &lt;fengguang.wu@intel.com&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Christoph Lameter &lt;cl@linux-foundation.org&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Tejun Heo &lt;tj@kernel.org&gt;
Cc: Nick Piggin &lt;npiggin@suse.de&gt;
Cc: KAMEZAWA Hiroyuki &lt;kamezawa.hiroyu@jp.fujitsu.com&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>devmem: check vmalloc address on kmem read/write</title>
<updated>2010-02-03T02:11:22+00:00</updated>
<author>
<name>KAMEZAWA Hiroyuki</name>
<email>kamezawa.hiroyu@jp.fujitsu.com</email>
</author>
<published>2010-02-02T21:44:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=325fda71d0badc1073dc59f12a948f24ff05796a'/>
<id>325fda71d0badc1073dc59f12a948f24ff05796a</id>
<content type='text'>
Otherwise vmalloc_to_page() will BUG().

This also makes the kmem read/write implementation aligned with mem(4):
"References to nonexistent locations cause errors to be returned." Here we
return -ENXIO (inspired by Hugh) if no bytes have been transfered to/from
user space, otherwise return partial read/write results.

Signed-off-by: KAMEZAWA Hiroyuki &lt;kamezawa.hiroyu@jp.fujitsu.com&gt;
Signed-off-by: Wu Fengguang &lt;fengguang.wu@intel.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Cc: Hugh Dickins &lt;hugh.dickins@tiscali.co.uk&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Otherwise vmalloc_to_page() will BUG().

This also makes the kmem read/write implementation aligned with mem(4):
"References to nonexistent locations cause errors to be returned." Here we
return -ENXIO (inspired by Hugh) if no bytes have been transfered to/from
user space, otherwise return partial read/write results.

Signed-off-by: KAMEZAWA Hiroyuki &lt;kamezawa.hiroyu@jp.fujitsu.com&gt;
Signed-off-by: Wu Fengguang &lt;fengguang.wu@intel.com&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
Cc: Hugh Dickins &lt;hugh.dickins@tiscali.co.uk&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6</title>
<updated>2010-02-02T20:48:49+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2010-02-02T20:48:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=489b24f2cbdcc1c93f55a2707733bba702ba8dbf'/>
<id>489b24f2cbdcc1c93f55a2707733bba702ba8dbf</id>
<content type='text'>
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  random: Remove unused inode variable
  crypto: padlock-sha - Add import/export support
  random: drop weird m_time/a_time manipulation
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  random: Remove unused inode variable
  crypto: padlock-sha - Add import/export support
  random: drop weird m_time/a_time manipulation
</pre>
</div>
</content>
</entry>
<entry>
<title>random: Remove unused inode variable</title>
<updated>2010-02-01T19:50:27+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2010-02-01T10:48:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=cd1510cb5f892907fe1a662f90b41fb3a42954e0'/>
<id>cd1510cb5f892907fe1a662f90b41fb3a42954e0</id>
<content type='text'>
The previous changeset left behind an unused inode variable.
This patch removes it.

Reported-by: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The previous changeset left behind an unused inode variable.
This patch removes it.

Reported-by: Stephen Rothwell &lt;sfr@canb.auug.org.au&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>random: drop weird m_time/a_time manipulation</title>
<updated>2010-02-01T19:50:23+00:00</updated>
<author>
<name>Matt Mackall</name>
<email>mpm@selenic.com</email>
</author>
<published>2010-01-29T08:50:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a996996dd75a9086b12d1cb4010f26e1748993f0'/>
<id>a996996dd75a9086b12d1cb4010f26e1748993f0</id>
<content type='text'>
No other driver does anything remotely like this that I know of except
for the tty drivers, and I can't see any reason for random/urandom to do
it. In fact, it's a (trivial, harmless) timing information leak. And
obviously, it generates power- and flash-cycle wasting I/O, especially
if combined with something like hwrngd. Also, it breaks ubifs's
expectations.

Signed-off-by: Matt Mackall &lt;mpm@selenic.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
No other driver does anything remotely like this that I know of except
for the tty drivers, and I can't see any reason for random/urandom to do
it. In fact, it's a (trivial, harmless) timing information leak. And
obviously, it generates power- and flash-cycle wasting I/O, especially
if combined with something like hwrngd. Also, it breaks ubifs's
expectations.

Signed-off-by: Matt Mackall &lt;mpm@selenic.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>x86/agp: Fix agp_amd64_init regression</title>
<updated>2010-01-31T06:52:26+00:00</updated>
<author>
<name>FUJITA Tomonori</name>
<email>fujita.tomonori@lab.ntt.co.jp</email>
</author>
<published>2010-01-25T05:10:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=61684ceaad4f65d1a9832c722f7bd5e7fc714de9'/>
<id>61684ceaad4f65d1a9832c722f7bd5e7fc714de9</id>
<content type='text'>
This fixes the regression introduced by commit
42590a75019a50012f25a962246498dead428433 ("x86/agp: Fix
agp_amd64_init and agp_amd64_cleanup").

The above commit changes agp_amd64_init() not to do anything if
gart_iommu_aperture is not zero.

If GART iommu calls agp_amd64_init(), we need to skip
agp_amd64_init() when it's called later via module_init.

The problem is that gart_iommu_init() calls agp_amd64_init()
with not zero gart_iommu_aperture so agp_amd64_init() is never
initialized.

When gart_iommu_init() calls agp_amd64_init(), agp should be
always initialized.

Reported-by: Marin Mitov &lt;mitov@issp.bas.bg&gt;
Reported-by: Johannes Hirte &lt;johannes.hirte@fem.tu-ilmenau.de&gt;
Signed-off-by: FUJITA Tomonori &lt;fujita.tomonori@lab.ntt.co.jp&gt;
Tested-by: Marin Mitov &lt;mitov@issp.bas.bg&gt;
Tested-by: Kevin Winchester &lt;kjwinchester@gmail.com&gt;
Cc: davej@redhat.com
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
LKML-Reference: &lt;20100125141006O.fujita.tomonori@lab.ntt.co.jp&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes the regression introduced by commit
42590a75019a50012f25a962246498dead428433 ("x86/agp: Fix
agp_amd64_init and agp_amd64_cleanup").

The above commit changes agp_amd64_init() not to do anything if
gart_iommu_aperture is not zero.

If GART iommu calls agp_amd64_init(), we need to skip
agp_amd64_init() when it's called later via module_init.

The problem is that gart_iommu_init() calls agp_amd64_init()
with not zero gart_iommu_aperture so agp_amd64_init() is never
initialized.

When gart_iommu_init() calls agp_amd64_init(), agp should be
always initialized.

Reported-by: Marin Mitov &lt;mitov@issp.bas.bg&gt;
Reported-by: Johannes Hirte &lt;johannes.hirte@fem.tu-ilmenau.de&gt;
Signed-off-by: FUJITA Tomonori &lt;fujita.tomonori@lab.ntt.co.jp&gt;
Tested-by: Marin Mitov &lt;mitov@issp.bas.bg&gt;
Tested-by: Kevin Winchester &lt;kjwinchester@gmail.com&gt;
Cc: davej@redhat.com
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
LKML-Reference: &lt;20100125141006O.fujita.tomonori@lab.ntt.co.jp&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
</feed>
