Michael Buesch [Mon, 8 Jan 2007 15:34:54 +0000 (16:34 +0100)]
[PATCH] Fix HWRNG built-in initcalls priority
This changes all HWRNG driver initcalls to module_init().
We must probe the RNGs after the major kernel subsystems
are already up and running (like PCI).
This fixes Bug 7730.
http://bugzilla.kernel.org/show_bug.cgi?id=7730
Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Both process_zones() and drain_node_pages() check for populated zones
before touching pagesets. However, __drain_pages does not do so,
This may result in a NULL pointer dereference for pagesets in unpopulated
zones if a NUMA setup is combined with cpu hotplug.
Initially the unpopulated zone has the pcp pointers pointing to the boot
pagesets. Since the zone is not populated the boot pageset pointers will
not be changed during page allocator and slab bootstrap.
If a cpu is later brought down (first call to __drain_pages()) then the pcp
pointers for cpus in unpopulated zones are set to NULL since __drain_pages
does not first check for an unpopulated zone.
If the cpu is then brought up again then we call process_zones() which will
ignore the unpopulated zone. So the pageset pointers will still be NULL.
If the cpu is then again brought down then __drain_pages will attempt to
drain pages by following the NULL pageset pointer for unpopulated zones.
Signed-off-by: Christoph Lameter <clameter@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
m41t00.c forgets to set the year field in set_rtc_time; fix that.
Signed-off-by: Philippe De Muyter <phdm@macqel.be> Acked-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
The oops is caused by a spurious interrupt that occurs when request_irq
is called. mv64xxx_i2c_fsm() tries to read drv_data->msg, which is NULL.
I noticed that hardware init is done after requesting irq. Thus any
pending irq from previous hardware usage may cause this.
The following patch fixes it:
Signed-off-by: Maxime Bizon <mbizon@freebox.fr> Acked-by: Mark A. Greer <mgreer@mvista.com> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Linus Torvalds [Sat, 16 Dec 2006 17:44:32 +0000 (09:44 -0800)]
[PATCH] Fix incorrect user space access locking in mincore() (CVE-2006-4814)
Doug Chapman noticed that mincore() will doa "copy_to_user()" of the
result while holding the mmap semaphore for reading, which is a big
no-no. While a recursive read-lock on a semaphore in the case of a page
fault happens to work, we don't actually allow them due to deadlock
schenarios with writers due to fairness issues.
Doug and Marcel sent in a patch to fix it, but I decided to just rewrite
the mess instead - not just fixing the locking problem, but making the
code smaller and (imho) much easier to understand.
Hugh Dickins [Sat, 6 Jan 2007 00:37:03 +0000 (16:37 -0800)]
[PATCH] fix OOM killing of swapoff
These days, if you swapoff when there isn't enough memory, OOM killer gives
"BUG: scheduling while atomic" and the machine hangs: badness() needs to do
its PF_SWAPOFF return after the task_unlock (tasklist_lock is also held
here, so p isn't going to be freed: PF_SWAPOFF might get turned off at any
moment, but that doesn't really matter).
Signed-off-by: Hugh Dickins <hugh@veritas.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Paul Moore [Mon, 18 Dec 2006 18:07:29 +0000 (13:07 -0500)]
[PATCH] NetLabel: correctly fill in unused CIPSOv4 level and category mappings
Back when the original NetLabel patches were being changed to use Netlink
attributes correctly some code was accidentially dropped which set all of the
undefined CIPSOv4 level and category mappings to a sentinel value. The result
is the mappings data in the kernel contains bogus mappings which always map to
zero. Having level and category mappings that map to zero could result in the
kernel assigning incorrect security attributes to packets.
This patch restores the old/correct behavior by initializing the mapping
data to the correct sentinel value.
Signed-off-by: Paul Moore <paul.moore@hp.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
David Hollis [Fri, 5 Jan 2007 17:34:05 +0000 (12:34 -0500)]
[PATCH] asix: Fix typo for AX88772 PHY Selection
The attached patch fixes a PHY selection problem that prevents AX88772
based devices (Linksys USB200Mv2, etc) devices from working. The
interface comes up and everything seems fine except the device doesn't
send/receive any packets. The one-liner attached fixes this issue and
makes the devices usable again.
Signed-off-by: David Hollis <dhollis@davehollis.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
It is important that we only assign dev->ip{,6}_ptr
only after all portions of the inet{,6} are setup.
Otherwise we can receive packets before the multicast
spinlocks et al. are initialized.
Signed-off-by: David L Stevens <dlstevens@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Georg Chini [Fri, 5 Jan 2007 01:03:38 +0000 (17:03 -0800)]
[PATCH] SOUND: Sparc CS4231: Fix IRQ return value and initialization.
SBUS: Change IRQ-handler return value from 0 to IRQ_HANDLED and
fix some initialisation problems.
Change period_bytes_min from 4096 to 256 to allow driver to work with
low latency (VOIP) applications. Hope this does not break EBUS.
Signed-off-by: Georg Chini <georg.chini@triaton-webhosting.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Jean Delvare [Thu, 4 Jan 2007 04:21:03 +0000 (23:21 -0500)]
[PATCH] V4L: cx88: Fix leadtek_eeprom tagging
reference to .init.text: from .text between 'cx88_card_setup'
(at offset 0x68c) and 'cx88_risc_field'
Caused by leadtek_eeprom() being declared __devinit and called from
a non-devinit context.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Ang Way Chuang [Thu, 4 Jan 2007 04:20:48 +0000 (23:20 -0500)]
[PATCH] dvb-core: fix bug in CRC-32 checking on 64-bit systems
CRC-32 checking during ULE decapsulation always failed on x86_64 systems due
to the size of a variable used to store CRC. This bug was discovered on
Fedora Core 6 with kernel-2.6.18-1.2849. The i386 counterpart has no such
problem. This patch has been tested on 64-bit system as well as 32-bit system.
Signed-off-by: Ang Way Chuang <wcang@nrg.cs.usm.my> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Linus Torvalds [Fri, 29 Dec 2006 18:00:58 +0000 (10:00 -0800)]
[PATCH] VM: Fix nasty and subtle race in shared mmap'ed page writeback
The VM layer (on the face of it, fairly reasonably) expected that when
it does a ->writepage() call to the filesystem, it would write out the
full page at that point in time. Especially since it had earlier marked
the whole page dirty with "set_page_dirty()".
But that isn't actually the case: ->writepage() does not actually write
a page, it writes the parts of the page that have been explicitly marked
dirty before, *and* that had not got written out for other reasons since
the last time we told it they were dirty.
That last caveat is the important one.
Which _most_ of the time ends up being the whole page (since we had
called "set_page_dirty()" on the page earlier), but if the filesystem
had done any dirty flushing of its own (for example, to honor some
internal write ordering guarantees), it might end up doing only a
partial page IO (or none at all) when ->writepage() is actually called.
That is the correct thing in general (since we actually often _want_
only the known-dirty parts of the page to be written out), but the
shared dirty page handling had implicitly forgotten about these details,
and had a number of cases where it was doing just the "->writepage()"
part, without telling the low-level filesystem that the whole page might
have been re-dirtied as part of being mapped writably into user space.
Since most of the time the FS did actually write out the full page, we
didn't notice this for a loong time, and this needed some really odd
patterns to trigger. But it caused occasional corruption with rtorrent
and with the Debian "apt" database, because both use shared mmaps to
update the end result.
This fixes it. Finally. After way too much hair-pulling.
Acked-by: Nick Piggin <nickpiggin@yahoo.com.au> Acked-by: Martin J. Bligh <mbligh@google.com> Acked-by: Martin Michlmayr <tbm@cyrius.com> Acked-by: Martin Johansson <martin@fatbob.nu> Acked-by: Ingo Molnar <mingo@elte.hu> Acked-by: Andrei Popa <andrei.popa@i-neo.ro> Cc: High Dickins <hugh@veritas.com> Cc: Andrew Morton <akpm@osdl.org>, Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Segher Boessenkool <segher@kernel.crashing.org> Cc: David Miller <davem@davemloft.net> Cc: Arjan van de Ven <arjan@infradead.org> Cc: Gordon Farquharson <gordonfarquharson@gmail.com> Cc: Guillaume Chazarain <guichaz@yahoo.fr> Cc: Theodore Tso <tytso@mit.edu> Cc: Kenneth Cheng <kenneth.w.chen@intel.com> Cc: Tobias Diedrich <ranma@tdiedrich.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[chrisw: backport to 2.6.19.1] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Jan Andersson [Tue, 2 Jan 2007 08:09:25 +0000 (00:09 -0800)]
[PATCH] sparc32: add offset in pci_map_sg()
Add sg->offset to sg->dvma_address in pci_map_sg() on sparc32. Without the
offset, transfers to buffers that do not begin on a page boundary will not
work as expected.
Signed-off-by: Jan Andersson <jan.andersson@ieee.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: William Lee Irwin III <wli@holomorphy.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Don't add it there please; add it lower down inside the existing #ifdef
__KERNEL__. You just made the _userspace_ net.h include random.h, which
then fails to compile unless <asm/types.h> was already included.
Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
David Miller [Tue, 2 Jan 2007 08:03:37 +0000 (00:03 -0800)]
[PATCH] SPARC64: Fix "mem=xxx" handling.
We were not being careful enough. When we trim the physical
memory areas, we have to make sure we don't remove the kernel
image or initial ramdisk image ranges.
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Eric Sandeen [Sat, 30 Dec 2006 23:30:32 +0000 (18:30 -0500)]
[PATCH] ext2: skip pages past number of blocks in ext2_find_entry (CVE-2006-6054)
This one was pointed out on the MOKB site:
http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html
If a directory's i_size is corrupted, ext2_find_entry() will keep processing
pages until the i_size is reached, even if there are no more blocks associated
with the directory inode. This patch puts in some minimal sanity-checking
so that we don't keep checking pages (and issuing errors) if we know there
can be no more data to read, based on the block count of the directory inode.
This is somewhat similar in approach to the ext3 patch I sent earlier this
year.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Phillip Lougher [Sat, 30 Dec 2006 23:28:06 +0000 (18:28 -0500)]
[PATCH] corrupted cramfs filesystems cause kernel oops (CVE-2006-5823)
Steve Grubb's fzfuzzer tool (http://people.redhat.com/sgrubb/files/
fsfuzzer-0.6.tar.gz) generates corrupt Cramfs filesystems which cause
Cramfs to kernel oops in cramfs_uncompress_block(). The cause of the oops
is an unchecked corrupted block length field read by cramfs_readpage().
This patch adds a sanity check to cramfs_readpage() which checks that the
block length field is sensible. The (PAGE_CACHE_SIZE << 1) size check is
intentional, even though the uncompressed data is not going to be larger
than PAGE_CACHE_SIZE, gzip sometimes generates compressed data larger than
the original source data. Mkcramfs checks that the compressed size is
always less than or equal to PAGE_CACHE_SIZE << 1. Of course Cramfs could
use the original uncompressed data in this case, but it doesn't.
Signed-off-by: Phillip Lougher <phillip@lougher.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
I've been using Steve Grubb's purely evil "fsfuzzer" tool, at
http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz
Basically it makes a filesystem, splats some random bits over it, then
tries to mount it and do some simple filesystem actions.
At best, the filesystem catches the corruption gracefully. At worst,
things spin out of control.
As you might guess, we found a couple places in ext3 where things spin out
of control :)
First, we had a corrupted directory that was never checked for
consistency... it was corrupt, and pointed to another bad "entry" of
length 0. The for() loop looped forever, since the length of
ext3_next_entry(de) was 0, and we kept looking at the same pointer over and
over and over and over... I modeled this check and subsequent action on
what is done for other directory types in ext3_readdir...
(adding this check adds some computational expense; I am testing a followup
patch to reduce the number of times we check and re-check these directory
entries, in all cases. Thanks for the idea, Andreas).
Next we had a root directory inode which had a corrupted size, claimed to
be > 200M on a 4M filesystem. There was only really 1 block in the
directory, but because the size was so large, readdir kept coming back for
more, spewing thousands of printk's along the way.
Per Andreas' suggestion, if we're in this read error condition and we're
trying to read an offset which is greater than i_blocks worth of bytes,
stop trying, and break out of the loop.
With these two changes fsfuzz test survives quite well on ext3.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Cc: <linux-ext4@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Ulrich Kunitz [Sat, 30 Dec 2006 21:35:17 +0000 (16:35 -0500)]
[PATCH] zd1211rw: Call ieee80211_rx in tasklet
The driver called ieee80211_rx in hardware interrupt context. This has
been against the intention of the ieee80211_rx function. It caused a bug
in the crypto routines used by WPA. This patch calls ieee80211_rx in a
tasklet.
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Ulrich Kunitz [Sat, 30 Dec 2006 21:18:14 +0000 (16:18 -0500)]
[PATCH] softmac: Fixed handling of deassociation from AP
In 2.6.19 a deauthentication from the AP doesn't start a
reassociation by the softmac code. It appears that
mac->associnfo.associating must be set and the
ieee80211softmac_assoc_work function must be scheduled. This patch
fixes that.
Signed-off-by: Ulrich Kunitz <kune@deine-taler.de> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Shantanu Goel [Sat, 30 Dec 2006 00:48:59 +0000 (16:48 -0800)]
[PATCH] Buglet in vmscan.c
Fix a rather obvious buglet. Noticed while instrumenting the VM using
/proc/vmstat.
Cc: Christoph Lameter <clameter@engr.sgi.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Mike Miller [Sat, 23 Dec 2006 20:11:58 +0000 (15:11 -0500)]
[PATCH] cciss: fix XFER_READ/XFER_WRITE in do_cciss_request
This patch fixes a stupid bug. Sometime during the 2tb enhancement I ended up
replacing the macros XFER_READ and XFER_WRITE with h->cciss_read and
h->cciss_write respectively. It seemed to work somehow at least on x86_64 and
ia64. I don't know how. But people started complaining about command timeouts
on older controllers like the 64xx series and only on ia32. This resolves the
issue reproduced in our lab. Please consider this for inclusion.
Signed-off-by: Mike Miller <mike.miller@hp.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Ed L Cashin [Fri, 22 Dec 2006 09:09:21 +0000 (01:09 -0800)]
[PATCH] fix aoe without scatter-gather [Bug 7662]
Fix a bug that only appears when AoE goes over a network card that does not
support scatter-gather. The headers in the linear part of the skb appeared
to be larger than they really were, resulting in data that was offset by 24
bytes.
This patch eliminates the offset data on cards that don't support
scatter-gather or have had scatter-gather turned off. There remains an
unrelated issue that I'll address in a separate email.
Fixes bugzilla #7662
Signed-off-by: "Ed L. Cashin" <ecashin@coraid.com> Cc: <stable@kernel.org> Cc: Greg KH <greg@kroah.com> Cc: <boddingt@optusnet.com.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Badari Pulavarty [Fri, 22 Dec 2006 09:06:23 +0000 (01:06 -0800)]
[PATCH] Fix for shmem_truncate_range() BUG_ON()
Ran into BUG() while doing madvise(REMOVE) testing. If we are punching a
hole into shared memory segment using madvise(REMOVE) and the entire hole
is below the indirect blocks, we hit following assert.
BUG_ON(limit <= SHMEM_NR_DIRECT);
Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com> Cc: Hugh Dickins <hugh@veritas.com> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Ingo Molnar [Thu, 21 Dec 2006 12:20:30 +0000 (13:20 +0100)]
[PATCH] sched: fix bad missed wakeups in the i386, x86_64, ia64, ACPI and APM idle code
Fernando Lopez-Lezcano reported frequent scheduling latencies and audio
xruns starting at the 2.6.18-rt kernel, and those problems persisted all
until current -rt kernels. The latencies were serious and unjustified by
system load, often in the milliseconds range.
After a patient and heroic multi-month effort of Fernando, where he
tested dozens of kernels, tried various configs, boot options,
test-patches of mine and provided latency traces of those incidents, the
following 'smoking gun' trace was captured by him:
what is visible in this trace is that CPU#1 ran try_to_wake_up() for
PID:5856, it placed PID:5856 on CPU#0's runqueue and ran resched_task()
for CPU#0. But it decided to not send an IPI that no CPU - due to
TS_POLLING. But CPU#0 never woke up after its NEED_RESCHED bit was set,
and only rescheduled to PID:5856 upon the next lapic timer IRQ. The
result was a 600+ usecs latency and a missed wakeup!
the bug turned out to be an idle-wakeup bug introduced into the mainline
kernel this summer via an optimization in the x86_64 tree:
[PATCH] i386/x86-64/ia64: Move polling flag into thread_info_status
During some profiling I noticed that default_idle causes a lot of
memory traffic. I think that is caused by the atomic operations
to clear/set the polling flag in thread_info. There is actually
no reason to make this atomic - only the idle thread does it
to itself, other CPUs only read it. So I moved it into ti->status.
the problem is this type of change:
if (!hlt_counter && boot_cpu_data.hlt_works_ok) {
- clear_thread_flag(TIF_POLLING_NRFLAG);
+ current_thread_info()->status &= ~TS_POLLING;
smp_mb__after_clear_bit();
while (!need_resched()) {
local_irq_disable();
this changes clear_thread_flag() to an explicit clearing of TS_POLLING.
clear_thread_flag() is defined as:
clear_bit(flag, &ti->flags);
and clear_bit() is a LOCK-ed atomic instruction on all x86 platforms:
hence smp_mb__after_clear_bit() is defined as a simple compile barrier:
#define smp_mb__after_clear_bit() barrier()
but the explicit TS_POLLING clearing introduced by the patch:
+ current_thread_info()->status &= ~TS_POLLING;
is not an atomic op! So the clearing of the TS_POLLING bit is freely
reorderable with the reading of the NEED_RESCHED bit - and both now
reside in different memory addresses.
CPU idle wakeup very much depends on ordered memory ops, the clearing of
the TS_POLLING flag must always be done before we test need_resched()
and hit the idle instruction(s). [Symmetrically, the wakeup code needs
to set NEED_RESCHED before it tests the TS_POLLING flag, so memory
ordering is paramount.]
Fernando's dual-core Athlon64 system has a sufficiently advanced memory
ordering model so that it triggered this scenario very often.
( And it also turned out that the reason why these latencies never
triggered on my testsystems is that i routinely use idle=poll, which
was the only idle variant not affected by this bug. )
The fix is to change the smp_mb__after_clear_bit() to an smp_mb(), to
act as an absolute barrier between the TS_POLLING write and the
NEED_RESCHED read. This affects almost all idling methods (default,
ACPI, APM), on all 3 x86 architectures: i386, x86_64, ia64.
Signed-off-by: Ingo Molnar <mingo@elte.hu> Tested-by: Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
[chrisw: backport to 2.6.19.1] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Dirk Eibach [Wed, 20 Dec 2006 07:34:43 +0000 (08:34 +0100)]
[PATCH] i2c: fix broken ds1337 initialization
On a custom board with ds1337 RTC I found that upgrade from 2.6.15 to
2.6.18 broke RTC support.
The main problem are changes to ds1337_init_client().
When a ds1337 recognizes a problem (e.g. power or clock failure) bit 7
in status register is set. This has to be reset by writing 0 to status
register. But since there are only 16 byte written to the chip and the
first byte is interpreted as an address, the status register (which is
the 16th) is never written.
The other problem is, that initializing all registers to zero is not
valid for day, date and month register. Funny enough this is checked by
ds1337_detect(), which depends on this values not being zero. So then
treated by ds1337_init_client() the ds1337 is not detected anymore,
whereas the failure bit in the status register is still set.
Marcel Holtmann [Mon, 11 Dec 2006 14:18:24 +0000 (15:18 +0100)]
[PATCH] Bluetooth: Add packet size checks for CAPI messages (CVE-2006-6106)
With malformed packets it might be possible to overwrite internal
CMTP and CAPI data structures. This patch adds additional length
checks to prevent these kinds of remote attacks.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Tejun Heo [Sat, 16 Dec 2006 11:02:32 +0000 (20:02 +0900)]
[PATCH] SCSI: add missing cdb clearing in scsi_execute()
Clear-garbage-after-CDB patch missed scsi_execute() and it causes some
ODDs (HL-DT-ST DVD-RAM GSA-H30N) choke during SCSI scan. Note that
this patch is only for -stable. There is another more reliable fix
for this problem proposed for devel tree.
Roland Dreier [Sat, 16 Dec 2006 04:58:14 +0000 (20:58 -0800)]
[PATCH] IB/srp: Fix FMR mapping for 32-bit kernels and addresses above 4G
struct srp_device.fmr_page_mask was unsigned long, which means that
the top part of addresses above 4G was being chopped off on 32-bit
architectures. Of course nothing good happens when data from SRP
targets is DMAed to the wrong place.
Fix this by changing fmr_page_mask to u64, to match the addresses
actually used by IB devices.
Thanks to Brian Cain <Brian.Cain@ge.com> and David McMillen
<davem@systemfabricworks.com> for help diagnosing the bug and testing
the fix.
Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Tim Chen [Wed, 13 Dec 2006 22:17:58 +0000 (14:17 -0800)]
[PATCH] sched: remove __cpuinitdata anotation to cpu_isolated_map
The structure cpu_isolated_map is used not only during initialization.
Multi-core scheduler configuration changes and exclusive cpusets
use this during run time. During setting of sched_mc_power_savings
policy, this structure is accessed to update sched_domains.
Signed-off-by: Tim Chen <tim.c.chen@intel.com> Acked-by: Suresh Siddha <suresh.b.siddha@intel.com> Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Roman Zippel [Wed, 13 Dec 2006 04:04:19 +0000 (23:04 -0500)]
[PATCH] kbuild: don't put temp files in source
The as-instr/ld-option need to create temporary files, but create them in the
output directory, when compiling external modules. Reformat them a bit and
use $(CC) instead of $(AS) as the former is used by kbuild to assemble files.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org> Cc: Andi Kleen <ak@suse.de> Cc: Jan Beulich <jbeulich@novell.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: <jpdenheijer@gmail.com> Cc: Horst Schirmeier <horst@schirmeier.com> Cc: Daniel Drake <dsd@gentoo.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Stefan Richter [Wed, 13 Dec 2006 04:00:16 +0000 (23:00 -0500)]
[PATCH] ieee1394: ohci1394: add PPC_PMAC platform code to driver probe
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=7431
iBook G3 threw a machine check exception and put the display backlight
to full brightness after ohci1394 was unloaded and reloaded.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
[dsd@gentoo.org: also added missing if condition, commit 63cca59e89892497e95e1e9c7156d3345fb7e2e8] Signed-off-by: Daniel Drake <dsd@gentoo.org> Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Tejun Heo [Wed, 13 Dec 2006 03:58:48 +0000 (22:58 -0500)]
[PATCH] libata: handle 0xff status properly
libata waits for !BSY even when the status register reports 0xff.
This causes long boot delays when D8 isn't pulled down properly. This
patch does the followings.
* don't wait if status register is 0xff in all wait functions
* make ata_busy_sleep() return 0 on success and -errno on failure.
-ENODEV is returned on 0xff status and -EBUSY on other failures.
* make ata_bus_softreset() succeed on 0xff status. 0xff status is not
reset failure. It indicates no device. This removes unnecessary
retries on such ports. Note that the code change assumes unoccupied
port reporting 0xff status does not produce valid device signature.
Signed-off-by: Tejun Heo <htejun@gmail.com> Cc: Joe Jin <lkmaillist@gmail.com> Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Hans Verkuil [Tue, 12 Dec 2006 05:36:39 +0000 (00:36 -0500)]
[PATCH] V4L: Fix broken TUNER_LG_NTSC_TAPE radio support
The TUNER_LG_NTSC_TAPE is identical in all respects to the
TUNER_PHILIPS_FM1236_MK3. So use the params struct for the Philips tuner.
Also add this LG_NTSC_TAPE tuner to the switches where radio specific
parameters are set so it behaves like a TUNER_PHILIPS_FM1236_MK3. This
change fixes the radio support for this tuner (the wrong bandswitch byte
was used).
Thanks to Andy Walls <cwalls@radix.net> for finding this bug.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Michael Krufky [Tue, 12 Dec 2006 05:34:27 +0000 (00:34 -0500)]
[PATCH] DVB: lgdt330x: fix signal / lock status detection bug
In some cases when using VSB, the AGC status register has been known to
falsely report "no signal" when in fact there is a carrier lock. The
datasheet labels these status flags as QAM only, yet the lgdt330x
module is using these flags for both QAM and VSB.
This patch allows for the carrier recovery lock status register to be
tested, even if the agc signal status register falsely reports no signal.
Thanks to jcrews from #linuxtv in irc, for initially reporting this bug.
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Andy Gospodarek [Tue, 21 Nov 2006 16:46:44 +0000 (11:46 -0500)]
[PATCH] bonding: incorrect bonding state reported via ioctl
This is a small fix-up to finish out the work done by Jay Vosburgh to
add carrier-state support for bonding devices. The output in
/proc/net/bonding/bondX was correct, but when collecting the same info
via an iotcl it could still be incorrect.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net> Cc: Jeff Garzik <jeff@garzik.org> Cc: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Arjan van de Ven [Mon, 11 Dec 2006 20:45:01 +0000 (21:45 +0100)]
[PATCH] x86-64: Mark rdtsc as sync only for netburst, not for core2
On the Core2 cpus, the rdtsc instruction is not serializing (as defined
in the architecture reference since rdtsc exists) and due to the deep
speculation of these cores, it's possible that you can observe time go
backwards between cores due to this speculation. Since the kernel
already deals with this with the SYNC_RDTSC flag, the solution is
simple, only assume that the instruction is serializing on family 15...
The price one pays for this is a slightly slower gettimeofday (by a
dozen or two cycles), but that increase is quite small to pay for a
really-going-forward tsc counter.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Hugh Dickins [Sun, 10 Dec 2006 10:18:43 +0000 (02:18 -0800)]
[PATCH] read_zero_pagealigned() locking fix
Ramiro Voicu hits the BUG_ON(!pte_none(*pte)) in zeromap_pte_range: kernel
bugzilla 7645. Right: read_zero_pagealigned uses down_read of mmap_sem,
but another thread's racing read of /dev/zero, or a normal fault, can
easily set that pte again, in between zap_page_range and zeromap_page_range
getting there. It's been wrong ever since 2.4.3.
The simple fix is to use down_write instead, but that would serialize reads
of /dev/zero more than at present: perhaps some app would be badly
affected. So instead let zeromap_page_range return the error instead of
BUG_ON, and read_zero_pagealigned break to the slower clear_user loop in
that case - there's no need to optimize for it.
Use -EEXIST for when a pte is found: BUG_ON in mmap_zero (the other user of
zeromap_page_range), though it really isn't interesting there. And since
mmap_zero wants -EAGAIN for out-of-memory, the zeromaps better return that
than -ENOMEM.
Signed-off-by: Hugh Dickins <hugh@veritas.com> Cc: Ramiro Voicu: <Ramiro.Voicu@cern.ch> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Daniel Barkalow [Fri, 8 Dec 2006 16:58:15 +0000 (11:58 -0500)]
[PATCH] forcedeth: Disable INTx when enabling MSI in forcedeth
At least some nforce cards continue to send legacy interrupts when MSI
is enabled, and these interrupts are treated as unhandled by the
kernel. This patch disables legacy interrupts explicitly when enabling
MSI mode.
The correct fix is to change the MSI infrastructure to disable legacy
interrupts when enabling MSI, but this is potentially risky if the
device isn't PCI-2.3 or is quirky, so the correct fix is going into
mainline, while patches like this one go into -stable.
Legend has it that it is most correct to disable legacy interrupts
before enabling MSI, but the mainline patch does it in the other
order, and this patch is "obviously" the same as mainline.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Cc: Jeff Garzik <jeff@garzik.org> Cc: Greg KH <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
[PATCH] x86: Fix boot hang due to nmi watchdog init code
2.6.19 stopped booting (or booted based on build/config) on our x86_64
systems due to a bug introduced in 2.6.19. check_nmi_watchdog schedules an
IPI on all cpus to busy wait on a flag, but fails to set the busywait
flag if NMI functionality is disabled. This causes the secondary cpus
to spin in an endless loop, causing the kernel bootup to hang.
Depending upon the build, the busywait flag got overwritten (stack variable)
and caused the kernel to bootup on certain builds. Following patch fixes
the bug by setting the busywait flag before returning from check_nmi_watchdog.
I guess using a stack variable is not good here as the calling function could
potentially return while the busy wait loop is still spinning on the flag.
Zachary Amsden [Thu, 7 Dec 2006 04:39:39 +0000 (20:39 -0800)]
[PATCH] softirq: remove BUG_ONs which can incorrectly trigger
It is possible to have tasklets get scheduled before softirqd has had a chance
to spawn on all CPUs. This is totally harmless; after success during action
CPU_UP_PREPARE, action CPU_ONLINE will be called, which immediately wakes
softirqd on the appropriate CPU to process the already pending tasklets. So
there is no danger of having a missed wakeup for any tasklets that were
already pending.
In particular, i386 is affected by this during startup, and is visible when
using a very large initrd; during the time it takes for the initrd to be
decompressed, a timer IRQ can come in and schedule RCU callbacks. It is also
possible that resending of a hardware IRQ via a softirq triggers the same bug.
Because of different timing conditions, this shows up in all emulators and
virtual machines tested, including Xen, VMware, Virtual PC, and Qemu. It is
also possible to trigger on native hardware with a large enough initrd,
although I don't have a reliable case demonstrating that.
Signed-off-by: Zachary Amsden <zach@vmware.com> Cc: <caglar@pardus.org.tr> Cc: Ingo Molnar <mingo@elte.hu> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Jiri Kosina [Thu, 7 Dec 2006 04:39:38 +0000 (20:39 -0800)]
[PATCH] autofs: fix error code path in autofs_fill_sb()
When kernel is compiled with old version of autofs (CONFIG_AUTOFS_FS), and
new (observed at least with 5.x.x) automount deamon is started, kernel
correctly reports incompatible version of kernel and userland daemon, but
then screws things up instead of correct handling of the error:
autofs: kernel does not match daemon version
=====================================
[ BUG: bad unlock balance detected! ]
-------------------------------------
automount/4199 is trying to release lock (&type->s_umount_key) at:
[<c0163b9e>] get_sb_nodev+0x76/0xa4
but there are no more locks to release!
other info that might help us debug this:
no locks held by automount/4199.
The problem: autofs_fill_super() returns EINVAL to get_sb_nodev(), but
before that, it calls kill_anon_super() to destroy the superblock which
won't be needed. This is however way too soon to call kill_anon_super(),
because get_sb_nodev() has to perform its own cleanup of the superblock
first (deactivate_super(), etc.). The correct time to call
kill_anon_super() is in the autofs_kill_sb() callback, which is called by
deactivate_super() at proper time, when the superblock is ready to be
killed.
I can see the same faulty codepath also in autofs4. This patch solves
issues in both filesystems in a same way - it postpones the
kill_anon_super() until the proper time is signalized by deactivate_super()
calling the kill_sb() callback.
[raven@themaw.net: update comment] Signed-off-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Ian Kent <raven@themaw.net> Cc: <stable@kernel.org> Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
The 'testproc' swsusp debug mode thaws tasks twice in a row, which is _very_
confusing. Fix that.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Andrew Morton [Thu, 7 Dec 2006 04:31:30 +0000 (20:31 -0800)]
[PATCH] add bottom_half.h
With CONFIG_SMP=n:
drivers/input/ff-memless.c:384: warning: implicit declaration of function 'local_bh_disable'
drivers/input/ff-memless.c:393: warning: implicit declaration of function 'local_bh_enable'
Really linux/spinlock.h should include linux/interrupt.h. But interrupt.h
includes sched.h which will need spinlock.h.
So the patch breaks the _bh declarations out into a separate header and
includes it in bothj interrupt.h and spinlock.h.
Jeet Chaudhuri [Thu, 7 Dec 2006 23:32:22 +0000 (01:32 +0200)]
[PATCH] IrDA: Incorrect TTP header reservation
We must reserve SAR + MAX_HEADER bytes for IrLMP to fit in.
This fixes an oops reported (and fixed) by Jeet Chaudhuri, when max_sdu_size
is greater than 0.
Signed-off-by: Samuel Ortiz <samuel@sortiz.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Patrick McHardy [Tue, 5 Dec 2006 04:01:31 +0000 (20:01 -0800)]
[PATCH] XFRM: Use output device disable_xfrm for forwarded packets
Currently the behaviour of disable_xfrm is inconsistent between
locally generated and forwarded packets. For locally generated
packets disable_xfrm disables the policy lookup if it is set on
the output device, for forwarded traffic however it looks at the
input device. This makes it impossible to disable xfrm on all
devices but a dummy device and use normal routing to direct
traffic to that device.
Always use the output device when checking disable_xfrm.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
David Miller [Tue, 5 Dec 2006 03:57:11 +0000 (19:57 -0800)]
[PATCH] TOKENRING: Remote memory corruptor in ibmtr.c
ip_summed changes last summer had missed that one. As the result,
we have ip_summed interpreted as CHECKSUM_PARTIAL now. IOW,
->csum is interpreted as offset of checksum in the packet. net/core/*
will both read and modify the value as that offset, with obvious
reasons. At the very least it's a remote memory corruptor.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Alexey Dobriyan [Sat, 2 Dec 2006 20:58:49 +0000 (23:58 +0300)]
[PATCH] do_coredump() and not stopping rewrite attacks? (CVE-2006-6304)
On Sat, Dec 02, 2006 at 11:47:44PM +0300, Alexey Dobriyan wrote:
> David Binderman compiled 2.6.19 with icc and grepped for "was set but never
> used". Many warnings are on
> http://coderock.org/kj/unused-2.6.19-fs
Heh, the very first line:
fs/exec.c(1465): remark #593: variable "flag" was set but never used
fs/exec.c:
1477 /*
1478 * We cannot trust fsuid as being the "true" uid of the
1479 * process nor do we know its entire history. We only know it
1480 * was tainted so we dump it as root in mode 2.
1481 */
1482 if (mm->dumpable == 2) { /* Setuid core dump mode */
1483 flag = O_EXCL; /* Stop rewrite attacks */
1484 current->fsuid = 0; /* Dump root private */
1485 }
And then filp_open follows with "flag" totally ignored.
ib_ucm_cleanup_events() holds file_mutex while calling ib_destroy_cm_id().
This can deadlock since ib_destroy_cm_id() flushes event handlers, and
ib_ucm_event_handler() needs file_mutex, too. Therefore, drop the
file_mutex during the call to ib_destroy_cm_id().
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com> Acked-by: Sean Hefty <sean.hefty@intel.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Maxime Austruy [Sun, 3 Dec 2006 16:40:01 +0000 (10:40 -0600)]
[PATCH] softmac: fix unbalanced mutex_lock/unlock in ieee80211softmac_wx_set_mlme
Routine ieee80211softmac_wx_set_mlme has one return that fails
to release a mutex acquired at entry.
Signed-off-by: Maxime Austruy <maxime@tralhalla.org> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
[PATCH] NETFILTER: bridge netfilter: deal with martians correctly
The attached patch resolves an issue where a IP DNATed packet with a
martian source is forwarded while it's better to drop it. It also
resolves messages complaining about ip forwarding being disabled while
it's actually enabled. Thanks to lepton <ytht.net@gmail.com> for
reporting this problem.
This is probably a candidate for the -stable release.
Signed-off-by: Bart De Schuymer <bdschuym@pandora.be> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
In compat mode, matches and targets valid hooks checks always successful due
to not initialized e->comefrom field yet. This patch separates this checks from
translation code and moves them after mark_source_chains() call, where these
marks are initialized.
Signed-off-by: Dmitry Mishin <dim@openvz.org>
Signed-off-by; Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Commit 590bdf7fd2292b47c428111cb1360e312eff207e introduced a regression
in match/target hook validation. mark_source_chains builds a bitmask
for each rule representing the hooks it can be reached from, which is
then used by the matches and targets to make sure they are only called
from valid hooks. The patch moved the match/target specific validation
before the mark_source_chains call, at which point the mask is always zero.
This patch returns back to the old order and moves the standard checks
to mark_source_chains. This allows to get rid of a special case for
standard targets as a nice side-effect.
Signed-off-by: Dmitry Mishin <dim@openvz.org> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Jurij Smakov [Mon, 4 Dec 2006 03:36:32 +0000 (19:36 -0800)]
[PATCH] SUNHME: Fix for sunhme failures on x86
The following patch fixes the failure of sunhme drivers on x86 hosts
due to missing pci_enable_device() and pci_set_master() calls, lost
during code refactoring. It has been filed as bugzilla bug #7502 [0]
and Debian bug #397460 [1].
David Miller [Sat, 2 Dec 2006 04:36:44 +0000 (20:36 -0800)]
[PATCH] PKT_SCHED act_gact: division by zero
Not returning -EINVAL, because someone might want to use the value
zero in some future gact_prob algorithm?
Signed-off-by: Kim Nordlund <kim.nordlund@nokia.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
This reverts commit 281ea49b0c294649a6de47a6f8fbe5611137726b,
which broke ACPI Interrupt source overrides that move
the SCI from one IRQ in PIC mode to another in IOAPIC mode.
If the SCI shared an interrupt line with another device,
this would result in a "irq 18: nobody cared" type failure.
http://bugzilla.kernel.org/show_bug.cgi?id=7601
Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Patrick McHardy [Fri, 1 Dec 2006 04:06:33 +0000 (20:06 -0800)]
[PATCH] NET_SCHED: policer: restore compatibility with old iproute binaries
The tc actions increased the size of struct tc_police, which broke
compatibility with old iproute binaries since both the act_police
and the old NET_CLS_POLICE code check for an exact size match.
Since the new members are not even used, the simple fix is to also
accept the size of the old structure. Dumping is not affected since
old userspace will receive a bigger structure, which is handled fine.
Signed-off-by: Patrick McHardy <kaber@trash.net> Acked-by: Jamal Hadi Salim <hadi@cyberus.ca> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Al Viro [Fri, 1 Dec 2006 03:47:59 +0000 (19:47 -0800)]
[PATCH] EBTABLES: Prevent wraparounds in checks for entry components' sizes.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Al Viro [Fri, 1 Dec 2006 03:47:58 +0000 (19:47 -0800)]
[PATCH] EBTABLES: Deal with the worst-case behaviour in loop checks.
No need to revisit a chain we'd already finished with during
the check for current hook. It's either instant loop (which
we'd just detected) or a duplicate work.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Al Viro [Fri, 1 Dec 2006 03:47:56 +0000 (19:47 -0800)]
[PATCH] EBTABLES: Verify that ebt_entries have zero ->distinguisher.
We need that for iterator to work; existing check had been too weak.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Al Viro [Fri, 1 Dec 2006 03:47:52 +0000 (19:47 -0800)]
[PATCH] EBTABLES: Fix wraparounds in ebt_entries verification.
We need to verify that
a) we are not too close to the end of buffer to dereference
b) next entry we'll be checking won't be _before_ our
While we are at it, don't subtract unrelated pointers...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Michael Buesch [Thu, 30 Nov 2006 00:51:12 +0000 (18:51 -0600)]
[PATCH] softmac: remove netif_tx_disable when scanning
In the scan section of ieee80211softmac, network transmits are disabled.
When SoftMAC re-enables transmits, it may override the wishes of a driver
that may have very good reasons for disabling transmits. At least one failure
in bcm43xx can be traced to this problem. In addition, several unexplained
problems may arise from the unexpected enabling of transmits.
Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Francois Romieu [Wed, 29 Nov 2006 21:21:33 +0000 (22:21 +0100)]
[PATCH] r8169: Fix iteration variable sign
This changes the type of variable "i" in rtl8169_init_one()
from "unsigned int" to "int". "i" is checked for < 0 later,
which can never happen for "unsigned". This results in broken
error handling.
Milan Svoboda [Wed, 29 Nov 2006 11:09:52 +0000 (12:09 +0100)]
[ARM] 3943/1: share declaration of struct pxa2xx_udc_mach_info between multiple platforms
Move declaration of struct pxa2xx_udc_mach_info from
include/asm-arm/arch-pxa/udc.h to new file
include/asm-arm/mach/udc_pxa2xx.h.
This allow us to use this structure with
multiple platforms - pxa and ixp4xx. USB
device controller used in pxa25x is the same
as controller used in ixp4xx.
Signed-off-by: Milan Svoboda <msvoboda@ra.rockwell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patrick McHardy [Wed, 29 Nov 2006 04:10:21 +0000 (20:10 -0800)]
[NETFILTER]: ipt_REJECT: fix memory corruption
On devices with hard_header_len > LL_MAX_HEADER ip_route_me_harder()
reallocates the skb, leading to memory corruption when using the stale
tcph pointer to update the checksum.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Yasuyuki Kozakai [Mon, 27 Nov 2006 18:26:46 +0000 (10:26 -0800)]
[NETFILTER]: conntrack: fix refcount leak when finding expectation
All users of __{ip,nf}_conntrack_expect_find() don't expect that
it increments the reference count of expectation.
Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>