David S. Miller [Sat, 27 Jan 2007 03:17:10 +0000 (19:17 -0800)]
[PATCH] SPARC64: Set g4/g5 properly in sun4v dtlb-prot handling.
Mirror the logic in the sun4u handler, we have to update
both registers even when we branch out to window fault
fixup handling.
The way it works is that if we are in etrap processing a
fault already, g4/g5 holds the original fault information.
If we take a window spill fault while doing etrap, then
we put the window spill fault info into g4/g5 and this is
what the top-level fault handler ends up processing first.
Then we retry the originally faulting instruction, and
process the original fault at that time.
This is all necessary because of how constrained the trap
registers are in these code paths. These cases trigger
very rarely, so even if there is some performance implication
it's doesn't happen very often. In fact the rarity is why
it took so long to trigger and find this particular bug.
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
"Nadia Derbey has reported that mmap of /dev/kmem no longer works with
the kernel virtual address as offset, and Franck has confirmed that
his patch came from a misunderstanding of what an offset means to
/dev/kmem - whereas his patch description seems to say that he was
correcting the offset on a few plaforms, there was no such problem to
correct, and his patch was in fact changing its API on all platforms."
Suggested-by: Hugh Dickins <hugh@veritas.com> Cc: Franck Bui-Huu <fbuihuu@gmail.com> Cc: Nadia Derbey <Nadia.Derbey@bull.net> Cc: Andi Kleen <ak@suse.de> Cc: Arjan van de Ven <arjan@infradead.org> Cc: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Linas Vepstas [Tue, 23 Jan 2007 18:40:54 +0000 (19:40 +0100)]
[PATCH] elevator: move clearing of unplug flag earlier
A flag was recently added to the elevator code to avoid
performing an unplug when reuests are being re-queued.
The goal of this flag was to avoid a deep recursion that
can occur when re-queueing requests after a SCSI device/host
reset. See http://lkml.org/lkml/2006/5/17/254
However, that fix added the flag near the bottom of a case
statement, where an earlier break (in an if statement) could
transport one out of the case, without setting the flag.
This patch sets the flag earlier in the case statement.
I re-discovered the deep recursion recently during testing;
I was told that it was a known problem, and the fix to it was
in the kernel I was testing. Indeed it was ... but it didn't
fix the bug. With the patch below, I no longer see the bug.
Patrick McHardy [Wed, 24 Jan 2007 16:46:39 +0000 (17:46 +0100)]
[PATCH] NETFILTER: Fix iptables ABI breakage on (at least) CRIS
With the introduction of x_tables we accidentally broke compatibility
by defining IPT_TABLE_MAXNAMELEN to XT_FUNCTION_MAXNAMELEN instead of
XT_TABLE_MAXNAMELEN, which is two bytes larger.
On most architectures it doesn't really matter since we don't have
any tables with names that long in the kernel and the structure
layout didn't change because of alignment requirements of following
members. On CRIS however (and other architectures that don't align
data) this changed the structure layout and thus broke compatibility
with old iptables binaries.
Changing it back will break compatibility with binaries compiled
against recent kernels again, but since the breakage has only been
there for three releases this seems like the better choice.
Spotted by Jonas Berlin <xkr47@outerspace.dyndns.org>.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Andi Kleen [Tue, 23 Jan 2007 17:17:09 +0000 (04:17 +1100)]
[PATCH] x86: Work around gcc 4.2 over aggressive optimizer
The new PDA code uses a dummy _proxy_pda variable to describe
memory references to the PDA. It is never referenced
in inline assembly, but exists as input/output arguments.
gcc 4.2 in some cases can CSE references to this which causes
unresolved symbols. Define it to zero to avoid this.
Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Ingo Molnar [Tue, 23 Jan 2007 16:16:26 +0000 (17:16 +0100)]
[PATCH] ACPI: fix cpufreq regression
recently cpufreq support on my laptop (Lenovo T60) broke completely:
when it's plugged into AC it would never go higher than 1 GHz - neither
1.3 GHz nor 1.83 GHz is possible - no matter which governor (userspace,
speed or ondemand) is used.
after some cpufreq debugging i tracked the regression back to the
following (totally correct) bug-fix commit:
[PATCH] Correct bound checking from the value returned from _PPC method.
this bugfix, which makes other laptops work, made a previously hidden
(BIOS) bug visible on my laptop.
The bug is the following: if the _PPC (Performance Present Capabilities)
optional ACPI object is queried /after/ bootup then the BIOS reports an
incorrect value of '2'.
My laptop (Lenovo T60) has the following performance states supported:
Per ACPI specification, a _PPC value of '0' means that all 3 performance
states are usable. A _PPC value of '1' means states 1 .. 2 are usable, a
value of '2' means only state '2' (slowest) is usable.
now, the _PPC object is optional, and it also comes with notification.
Furthermore, when a CPU object is initialized, the _PPC object is
initialized as well. So the following evaluation of the _PPC object is
superfluous:
and this is the point where my laptop's BIOS returns the incorrect value
of '2'. Note that it has not sent any notification event, so the value
is probably not really intentional (possibly spurious), and Windows
likely doesnt query it after bootup either. Maybe the value is kept at
'2' normally, and is only set to the real value when a true asynchronous
event (such as AC plug event, battery switch, etc.) occurs.
So i /think/ this is a grey area of the ACPI spec: per the letter of the
spec the _PPC value only changes when notified, so there's no reason to
query it after the system has booted up. So in my opinion the best (and
most compatible) strategy would be to do the change below, and to not
evaluate the _PPC object in the acpi_processor_get_performance_info()
call, but only evaluate it if _PPC is present during CPU object init, or
if it's notified during an asynchronous event. This change is more
permissive than the previous logic, so it definitely shouldnt break any
existing system.
This also happens to fix my laptop, which is merrily chugging along at
1.83 GHz now. Yay!
Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Dave Jones <davej@redhat.com> Acked-by: Len Brown <len.brown@intel.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Jeff Dike [Mon, 22 Jan 2007 20:38:27 +0000 (15:38 -0500)]
[PATCH] Fix UML on non-standard VM split hosts
This fixes UML on hosts with non-standard VM splits. We had changed
the config variable that controls UML behavior on such hosts, but not
propogated the change everywhere. In particular, the values of
STUB_CODE and STUB_DATA relied on the old variable.
I also reformatted the HOST_VMSPLIT_3G help to make it more standard.
Spotted by uml@flonatel.org.
Signed-off-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
--
arch/um/Kconfig.i386 | 38 +++++++++++++++++++-------------------
1 file changed, 19 insertions(+), 19 deletions(-)
Erez Zilber [Mon, 22 Jan 2007 13:03:53 +0000 (15:03 +0200)]
[PATCH] IB/iser: return error code when PDUs may not be sent
iSER limits the number of outstanding PDUs to send. When this threshold is
reached, it should return an error code (-ENOBUFS) instead of setting the
suspend_tx bit (which should be used only by libiscsi). Without this fix,
during logout, open-iscsi over iSER tries to logout forever.
Signed-off-by: Erez Zilber <erezz@voltaire.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Paul Moore [Fri, 19 Jan 2007 19:25:50 +0000 (14:25 -0500)]
[PATCH] SELinux: fix an oops with NetLabel and non-MLS SELinux policy
In the case where a user has configured NetLabel in the kernel but is not
using a SELinux policy with the MLS/MCS feature enabled there is a bug in
mls_export_cat() where a NULL pointer is used. The initial problem report and
discussion can be found here (this patch has been ACK'd by Stephen Smalley and
James Morris in the discussion thread below):
This patch is specific to the 2.6.19.y kernel series as the mls_export_cat()
function has been replaced in the 2.6.20 kernel.
Signed-off-by: Paul Moore <paul.moore@hp.com> Acked-by: Stephen Smalley <sds@tycho.nsa.gov> Acked-by: James Morris <jmorris@namei.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Herbert Xu [Wed, 17 Jan 2007 02:35:01 +0000 (13:35 +1100)]
[PATCH] IPSEC: Policy list disorder
The recent hashing introduced an off-by-one bug in policy list insertion.
Instead of adding after the last entry with a lesser or equal priority,
we're adding after the successor of that entry.
This patch fixes this and also adds a warning if we detect a duplicate
entry in the policy list. This should never happen due to this if clause.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
[PATCH] NETFILTER: ctnetlink: check for status attribute existence on conntrack creation
Check that status flags are available in the netlink message received
to create a new conntrack.
Fixes a crash in ctnetlink_create_conntrack when the CTA_STATUS attribute
is not present.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
[PATCH] IPV6 MCAST: Fix joining all-node multicast group on device initialization.
Join all-node multicast group after assignment of dev->ip6_ptr
because it must be assigned when ipv6_dev_mc_inc() is called.
This fixes Bug#7817, reported by <gernoth@informatik.uni-erlangen.de>.
Closes: 7817 Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Ard van Breemen [Thu, 11 Jan 2007 15:22:57 +0000 (10:22 -0500)]
[PATCH] PCI: prevent down_read when pci_devices is empty
The pci_find_subsys gets called very early by obsolete ide setup parameters.
This is a bogus call since pci is not initialized yet, so the list is empty.
But in the mean time, interrupts get enabled by down_read. This can result in
a kernel panic when the irq controller gets initialized.
This patch checks if the device list is empty before taking the semaphore, and
hence will not enable irq's. Furthermore it will inform that it is called
while pci_devices is empty as a reminder that the ide code needs to be fixed.
The pci_get_subsys can get called in the same manner, and as such is patched
in the same manner.
[akpm@osdl.org: cleanups] Signed-off-by: Ard van Breemen <ard@telegraafnet.nl> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[chrisw: fold in 6a4c24ec5212 to avoid printk spamming] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Ard van Breemen [Thu, 11 Jan 2007 15:21:52 +0000 (10:21 -0500)]
[PATCH] start_kernel: test if irq's got enabled early, barf, and disable them again
The calls made by parse_parms to other initialization code might enable
interrupts again way too early.
Having interrupts on this early can make systems PANIC when they initialize
the IRQ controllers (which happens later in the code). This patch detects
that irq's are enabled again, barfs about it and disables them again as a
safety net.
[akpm@osdl.org: cleanups] Signed-off-by: Ard van Breemen <ard@telegraafnet.nl> 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>
Linus Torvalds [Thu, 11 Jan 2007 15:20:10 +0000 (10:20 -0500)]
[PATCH] Fix up CIFS for "test_clear_page_dirty()" removal
Fix up CIFS for "test_clear_page_dirty()" removal
This also adds he required page "writeback" flag handling, that cifs
hasn't been doing and that the page dirty flag changes made obvious.
Acked-by: Steve French <smfltc@us.ibm.com> Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Nathan Lynch [Thu, 11 Jan 2007 07:15:28 +0000 (23:15 -0800)]
[PATCH] sched: tasks cannot run on cpus onlined after boot
Commit 5c1e176781f43bc902a51e5832f789756bff911b ("sched: force /sbin/init
off isolated cpus") sets init's cpus_allowed to a subset of cpu_online_map
at boot time, which means that tasks won't be scheduled on cpus that are
added to the system later.
Make init's cpus_allowed a subset of cpu_possible_map instead. This should
still preserve the behavior that Nick's change intended.
Thanks to Giuliano Pochini for reporting this and testing the fix:
Stefan Richter [Thu, 11 Jan 2007 07:50:27 +0000 (08:50 +0100)]
[PATCH] ieee1394: sbp2: fix probing of some DVD-ROM/RWs
Since commit 98e238cd42be6c0852da519303cf0182690f8d9f in Linux 2.6.19,
"ieee1394: sbp2: don't prefer MODE SENSE 10", some FireWire DVD-ROMs and
DVD-RWs were mistaken as CD-ROM because sr_mod now sent MODE SENSE 6.
The MMC command set includes only MODE SENSE 10.
http://bugzilla.kernel.org/show_bug.cgi?id=7800
This fix lets sbp2 switch scsi_device.use_10_for_rw on for MMC LUs.
This should rather be done in the command set driver sr_mod, not in the
sbp2 transport driver, and an according patch will follow for a next
Linux release.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
[PATCH] Fix reparenting to the same thread group. (take 2)
This patch fixes the case when we reparent to a different thread in the
same thread group. This modifies the code so that we do not send
signals and do not change the signal to send to SIGCHLD unless we have
change the thread group of our parents. It also suppresses sending
pdeath_sig in this cas as well since the result of geppid doesn't
change.
Thanks to Oleg for spotting my bug of only fixing this for non-ptraced
tasks.
This fixes the issues identified by Albert Cahalan in thread
http://lkml.org/lkml/2006/12/21/22.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Acked-by: Mike Galbraith <efault@gmx.de> Cc: Albert Cahalan <acahalan@gmail.com> Cc: Andrew Morton <akpm@osdl.org> Cc: Roland McGrath <roland@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Coywolf Qi Hunt <qiyong@fc-cn.com> Acked-by: Oleg Nesterov <oleg@tv-sign.ru> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[chrisw: fold in 241ceee0b442, Oleg's fix to restore user visible behaviour] Signed-off-by: Chris Wright <chrisw@sous-sol.org>
[PATCH] IB/mthca: Fix off-by-one in FMR handling on memfree
mthca_table_find() will return the wrong address when the table entry
being searched for is exactly at the beginning of a sglist entry
(other than the first), because it uses >= when it should use >.
Example: assume we have 2 entries in scatterlist, 4K each, offset is
4K. The current code will return first entry + 4K when we really want
the second entry.
In particular this means mapping an FMR on a memfree HCA may end up
writing the page table into the wrong place, leading to memory
corruption and also causing the HCA to use an incorrect address
translation table.
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Karsten Wiese [Wed, 10 Jan 2007 12:33:27 +0000 (13:33 +0100)]
[PATCH] Repair snd-usb-usx2y over OHCI
The previous patch "Repair snd-usb-usx2y for usb 2.6.18" assumed
urb->start_frame roll over beyond MAX_INT for both UHCI & OHCI.
This isn't true until now (kernel 2.6.20).
Fix this by only looking at the common between OHCI & UHCI Frame number
range.
This is for mainline and stable kernels >= 2.6.18.
Signed-off-by: Karsten Wiese <fzu@wemgehoertderstaat.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
The included patch translates arpt_counters to xt_counters, making
userspace arptables compile against recent kernels.
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>
Patrick McHardy [Wed, 10 Jan 2007 07:04:47 +0000 (08:04 +0100)]
[PATCH] NETFILTER: nf_conntrack_ipv6: fix crash when handling fragments
When IPv6 connection tracking splits up a defragmented packet into
its original fragments, the packets are taken from a list and are
passed to the network stack with skb->next still set. This causes
dev_hard_start_xmit to treat them as GSO fragments, resulting in
a use after free when connection tracking handles the next fragment.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Patrick McHardy [Wed, 10 Jan 2007 07:04:46 +0000 (08:04 +0100)]
[PATCH] NETFILTER: Fix routing of REJECT target generated packets in output chain
Packets generated by the REJECT target in the output chain have a local
destination address and a foreign source address. Make sure not to use
the foreign source address for the output route lookup.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
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>
projects / karo-tx-linux.git / log