<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v2.6.33.2</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v2.6.33.2</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v2.6.33.2'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2010-04-01T23:02:33Z</updated>
<entry>
<title>Linux 2.6.33.2</title>
<updated>2010-04-01T23:02:33Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@suse.de</email>
</author>
<published>2010-04-01T23:02:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=19f00f070c17584b5acaf186baf4d12a7d2ed125'/>
<id>urn:sha1:19f00f070c17584b5acaf186baf4d12a7d2ed125</id>
<content type='text'>
</content>
</entry>
<entry>
<title>pata_via: fix VT6410/6415/6330 detection issue</title>
<updated>2010-04-01T23:02:15Z</updated>
<author>
<name>JosephChan@via.com.tw</name>
<email>JosephChan@via.com.tw</email>
</author>
<published>2010-03-25T12:51:47Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=77aba144b01d97cd877dbbca15b1ba5b11192e5f'/>
<id>urn:sha1:77aba144b01d97cd877dbbca15b1ba5b11192e5f</id>
<content type='text'>
commit bc8a67386fd462914269fa93446e1891955a8bb3 upstream.

When using VT6410/6415/6330 chips on some VIA's platforms, the HDD
connection to VT6410/6415/6330 cannot be detected.

It is because the driver detects wrong via_isa_bridge ID, and then
causes this issue to happen.

Signed-off-by: Joseph Chan &lt;josephchan@via.com.tw&gt;
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>GFS2: Skip check for mandatory locks when unlocking</title>
<updated>2010-04-01T23:02:15Z</updated>
<author>
<name>Sachin Prabhu</name>
<email>sprabhu@redhat.com</email>
</author>
<published>2010-03-11T17:24:45Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8afdd016d273b1c2641e979fdaa28e96b6f9fb9c'/>
<id>urn:sha1:8afdd016d273b1c2641e979fdaa28e96b6f9fb9c</id>
<content type='text'>
commit 720e7749279bde0d08684b1bb4e7a2eedeec6394 upstream.

gfs2_lock() will skip locks on file which have mode set to 02666. This is a problem in cases where the mode of the file is changed after a process has obtained a lock on the file. Such a lock will be skipped and will result in a BUG in locks_remove_flock().

gfs2_lock() should skip the check for mandatory locks when unlocking a file.

Signed-off-by: Sachin Prabhu &lt;sprabhu@redhat.com&gt;
Signed-off-by: Steven Whitehouse &lt;swhiteho@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>classmate-laptop: use a single MODULE_DEVICE_TABLE to get correct aliases</title>
<updated>2010-04-01T23:02:14Z</updated>
<author>
<name>Thadeu Lima de Souza Cascardo</name>
<email>cascardo@holoscopio.com</email>
</author>
<published>2010-02-09T22:37:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=993d82e3f2d2bd769b4b6246fa943d5ac71c46a2'/>
<id>urn:sha1:993d82e3f2d2bd769b4b6246fa943d5ac71c46a2</id>
<content type='text'>
commit 02e77a55f7b7e36888e39c62439fedb90ae4e808 upstream.

Instead of a MODULE_DEVICE_TABLE for every acpi_driver ids table, we
create a table containing all ids to export to get a module alias for
each one.

This will fix automatic loading of the driver when one of the ACPI
devices is not present (like the accelerometer, which is not present in
some models).

Signed-off-by: Thadeu Lima de Souza Cascardo &lt;cascardo@holoscopio.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>x86: Fix sched_clock_cpu for systems with unsynchronized TSC</title>
<updated>2010-04-01T23:02:14Z</updated>
<author>
<name>Dimitri Sivanich</name>
<email>sivanich@sgi.com</email>
</author>
<published>2010-03-01T17:48:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=39ec71179f7c02f2a9c1b37b1132f2d091a9cf1c'/>
<id>urn:sha1:39ec71179f7c02f2a9c1b37b1132f2d091a9cf1c</id>
<content type='text'>
commit 14be1f7454ea96ee614467a49cf018a1a383b189 upstream.

On UV systems, the TSC is not synchronized across blades.  The
sched_clock_cpu() function is returning values that can go
backwards  (I've seen as much as 8 seconds) when switching
between cpus.

As each cpu comes up, early_init_intel() will currently set the
sched_clock_stable flag true.  When mark_tsc_unstable() runs, it
clears the flag, but this only occurs once (the first time a cpu
comes up whose TSC is not synchronized with cpu 0).  After this,
early_init_intel() will set the flag again as the next cpu comes
up.

Only set sched_clock_stable if tsc has not been marked unstable.

Signed-off-by: Dimitri Sivanich &lt;sivanich@sgi.com&gt;
Acked-by: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Acked-by: Peter Zijlstra &lt;a.p.zijlstra@chello.nl&gt;
LKML-Reference: &lt;20100301174815.GC8224@sgi.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>b43: Workaround circular locking in hw-tkip key update callback</title>
<updated>2010-04-01T23:02:14Z</updated>
<author>
<name>Michael Buesch</name>
<email>mb@bu3sch.de</email>
</author>
<published>2010-03-19T15:38:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cb81a2ace8bd4354cc40ff341543a9791719383c'/>
<id>urn:sha1:cb81a2ace8bd4354cc40ff341543a9791719383c</id>
<content type='text'>
commit 96869a39399269a776a94812e9fff3d38b47d838 upstream

The TKIP key update callback is called from the RX path, where the driver
mutex is already locked. This results in a circular locking bug.
Avoid this by removing the lock.

Johannes noted that there is a separate bug: The callback still breaks on SDIO
hardware, because SDIO hardware access needs to sleep, but we are not allowed
to sleep in the callback due to mac80211's RCU locking.

Signed-off-by: Michael Buesch &lt;mb@bu3sch.de&gt;
Tested-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Reported-by: kecsa@kutfo.hit.bme.hu
Cc: Johannes Berg &lt;johannes@sipsolutions.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>Bluetooth: Fix kernel crash on L2CAP stress tests</title>
<updated>2010-04-01T23:02:13Z</updated>
<author>
<name>Andrei Emeltchenko</name>
<email>andrei.emeltchenko@nokia.com</email>
</author>
<published>2010-03-19T08:26:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cf724d19f2e56135927eadc1154940d3f42f9f0e'/>
<id>urn:sha1:cf724d19f2e56135927eadc1154940d3f42f9f0e</id>
<content type='text'>
commit c2c77ec83bdad17fb688557b5b3fdc36661dd1c6 upstream.

Added very simple check that req buffer has enough space to
fit configuration parameters. Shall be enough to reject packets
with configuration size more than req buffer.

Crash trace below

[ 6069.659393] Unable to handle kernel paging request at virtual address 02000205
[ 6069.673034] Internal error: Oops: 805 [#1] PREEMPT
...
[ 6069.727172] PC is at l2cap_add_conf_opt+0x70/0xf0 [l2cap]
[ 6069.732604] LR is at l2cap_recv_frame+0x1350/0x2e78 [l2cap]
...
[ 6070.030303] Backtrace:
[ 6070.032806] [&lt;bf1c2880&gt;] (l2cap_add_conf_opt+0x0/0xf0 [l2cap]) from
[&lt;bf1c6624&gt;] (l2cap_recv_frame+0x1350/0x2e78 [l2cap])
[ 6070.043823]  r8:dc5d3100 r7:df2a91d6 r6:00000001 r5:df2a8000 r4:00000200
[ 6070.050659] [&lt;bf1c52d4&gt;] (l2cap_recv_frame+0x0/0x2e78 [l2cap]) from
[&lt;bf1c8408&gt;] (l2cap_recv_acldata+0x2bc/0x350 [l2cap])
[ 6070.061798] [&lt;bf1c814c&gt;] (l2cap_recv_acldata+0x0/0x350 [l2cap]) from
[&lt;bf0037a4&gt;] (hci_rx_task+0x244/0x478 [bluetooth])
[ 6070.072631]  r6:dc647700 r5:00000001 r4:df2ab740
[ 6070.077362] [&lt;bf003560&gt;] (hci_rx_task+0x0/0x478 [bluetooth]) from
[&lt;c006b9fc&gt;] (tasklet_action+0x78/0xd8)
[ 6070.087005] [&lt;c006b984&gt;] (tasklet_action+0x0/0xd8) from [&lt;c006c160&gt;]

Signed-off-by: Andrei Emeltchenko &lt;andrei.emeltchenko@nokia.com&gt;
Acked-by: Gustavo F. Padovan &lt;gustavo@padovan.org&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>Bluetooth: Fix potential bad memory access with sysfs files</title>
<updated>2010-04-01T23:02:13Z</updated>
<author>
<name>Marcel Holtmann</name>
<email>marcel@holtmann.org</email>
</author>
<published>2010-03-15T21:12:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a318674438c789f5bf46a91cf24b5988b2091f16'/>
<id>urn:sha1:a318674438c789f5bf46a91cf24b5988b2091f16</id>
<content type='text'>
commit 101545f6fef4a0a3ea8daf0b5b880df2c6a92a69 upstream.

When creating a high number of Bluetooth sockets (L2CAP, SCO
and RFCOMM) it is possible to scribble repeatedly on arbitrary
pages of memory. Ensure that the content of these sysfs files is
always less than one page. Even if this means truncating. The
files in question are scheduled to be moved over to debugfs in
the future anyway.

Based on initial patches from Neil Brown and Linus Torvalds

Reported-by: Neil Brown &lt;neilb@suse.de&gt;
Signed-off-by: Marcel Holtmann &lt;marcel@holtmann.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>ahci: use BIOS date in broken_suspend list</title>
<updated>2010-04-01T23:02:13Z</updated>
<author>
<name>Tejun Heo</name>
<email>tj@kernel.org</email>
</author>
<published>2010-03-16T00:50:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3ecee16aa4617db7cb756ad01526d395dc86d95f'/>
<id>urn:sha1:3ecee16aa4617db7cb756ad01526d395dc86d95f</id>
<content type='text'>
commit 9deb343189b3cf45e84dd08480f330575ffe2004 upstream.

HP is recycling both DMI_PRODUCT_NAME and DMI_BIOS_VERSION making
ahci_broken_suspend() trigger for later products which are not
affected by the original problems.  Match BIOS date instead of version
and add references to bko's so that full information can be found
easier later.

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=15462

Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Reported-by: tigerfishdaisy@gmail.com
Signed-off-by: Jeff Garzik &lt;jgarzik@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>quota: Fix warning when a delayed write happens before quota is enabled</title>
<updated>2010-04-01T23:02:12Z</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2010-02-09T17:20:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e58bb78fcd092688765b18574ea4055c2509aee5'/>
<id>urn:sha1:e58bb78fcd092688765b18574ea4055c2509aee5</id>
<content type='text'>
commit 0a5a9c725512461d19397490f3adf29931dca1f2 upstream.

If a delayed-allocation write happens before quota is enabled, the
kernel spits out a warning:
WARNING: at fs/quota/dquot.c:988 dquot_claim_space+0x77/0x112()

because the fact that user has some delayed allocation is not recorded
in quota structure.

Make dquot_initialize() update amount of reserved space for user if it sees
inode has some space reserved. Also make sure that reserved quota space does
not go negative and we warn about the filesystem bug just once.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
</feed>
