Michael Buesch [Fri, 27 Oct 2006 16:16:39 +0000 (11:16 -0500)]
[PATCH] bcm43xx: fix watchdog timeouts.
This fixes a netdev watchdog timeout problem.
The problem is caused by a needed netif_tx_disable
in the hardware calibration code and can be shown by the
following timegraph.
|---5secs - ~10 jiffies time---|---|OOPS
^ ^
last real TX periodic work stops netif
At OOPS, the following happens:
The watchdog timer triggers, because the timeout of 5secs
is over. The watchdog first checks for stopped TX.
_Usually_ TX is only stopped from the TX handler to indicate
a full TX queue. But this is different. We need to stop TX here,
regardless of the TX queue state. So the watchdog recognizes
the stopped device and assumes it is stopped due to full
TX queues (Which is a _wrong_ assumption in this case). It then
tests how far the last TX has been in the past. If it's more than
5secs (which is the case for low or no traffic), it will fire
a TX timeout.
Acked-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
David Miller [Thu, 26 Oct 2006 06:51:07 +0000 (23:51 -0700)]
[PATCH] SPARC64: Fix memory corruption in pci_4u_free_consistent().
The second argument to free_npages() was being incorrectly
calculated, which would thus access far past the end of the
arena->map[] bitmap.
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
David Miller [Thu, 26 Oct 2006 06:50:12 +0000 (23:50 -0700)]
[PATCH] SPARC64: Fix central/FHC bus handling on Ex000 systems.
1) probe_other_fhcs() wants to see only non-central FHC
busses, so skip FHCs that don't sit off the root
2) Like SBUS, FHC can lack the appropriate address and
size cell count properties, so add an of_busses[]
entry and handlers for that.
3) Central FHC irq translator probing was buggy. We
were trying to use dp->child in irq_trans_init but
that linkage is not setup at this point.
So instead, pass in the parent of "dp" and look for
the child "fhc" with parent "central".
Thanks to the tireless assistence of Ben Collins in tracking
down these problems and testing out these fixes.
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Russell King [Tue, 17 Oct 2006 11:26:34 +0000 (13:26 +0200)]
[PATCH] SERIAL: Fix oops when removing suspended serial port
[SERIAL] Fix oops when removing suspended serial port
A serial card might have been removed when the system is resumed.
This results in a suspended port being shut down, which results in
the ports shutdown method being called twice in a row. This causes
BUGs. Avoid this by tracking the suspended state separately from
the initialised state.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: maximilian attems <maks@sternwelten.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Russell King [Tue, 17 Oct 2006 11:19:40 +0000 (13:19 +0200)]
[PATCH] SERIAL: Fix resume handling bug
Unfortunately, pcmcia_dev_present() returns false when a device is
suspended, so checking this on resume does not work too well. Omit
this test.
the backported patch below is already in fedora tree. -maks
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: maximilian attems <maks@sternwelten.at> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Brian King [Sun, 24 Sep 2006 03:59:49 +0000 (03:59 +0000)]
[PATCH] SCSI: DAC960: PCI id table fixup
[SCSI] DAC960: PCI id table fixup
The PCI ID table in the DAC960 driver conflicts with some devices
that use the ipr driver. All ipr adapters that use this chip
have an IBM subvendor ID and all DAC960 adapters that use this
chip have a Mylex subvendor id.
Signed-off-by: Brian King <brking@us.ibm.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
[PATCH] uml: fix processor selection to exclude unsupported processors and features
Makes UML compile on any possible processor choice. The two problems were:
*) x86 code, when 386 is selected, checks at runtime boot_cpuflags, which we do
not have.
*) 3Dnow support for memcpy() et al. does not compile currently and fixing this
is not trivial, so simply disable it; with this change, if one selects MK7
UML compiles (while it did not).
Merged upstream.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
When using flow control, the PHY needs to accept multicast pause frames.
Without this fix, these frames were getting discarded by the PHY before
doing any flow control.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Arnaud Patard [Mon, 16 Oct 2006 12:35:57 +0000 (14:35 +0200)]
[PATCH] ALSA: emu10k1: Fix outl() in snd_emu10k1_resume_regs()
The emu10k1 driver saves the A_IOCFG and HCFG register on suspend and restores
it on resumes. Unfortunately, this doesn't work as the arguments to outl() are
reversed.
When PHY is turned off on shutdown, it can causes the IRQ to get stuck on.
Make sure and disable the IRQ first, and if IRQ occurs when device
is not running, don't access PHY because that can hang.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Suresh Siddha [Thu, 12 Oct 2006 16:14:05 +0000 (09:14 -0700)]
[PATCH] mm: fix a race condition under SMC + COW
Failing context is a multi threaded process context and the failing
sequence is as follows.
One thread T0 doing self modifying code on page X on processor P0 and
another thread T1 doing COW (breaking the COW setup as part of just
happened fork() in another thread T2) on the same page X on processor P1.
T0 doing SMC can endup modifying the new page Y (allocated by the T1 doing
COW on P1) but because of different I/D TLB's, P0 ITLB will not see the new
mapping till the flush TLB IPI from P1 is received. During this interval,
if T0 executes the code created by SMC it can result in an app error (as
ITLB still points to old page X and endup executing the content in page X
rather than using the content in page Y).
Fix this issue by first clearing the PTE and flushing it, before updating
it with new entry.
Hugh sayeth:
I was a bit sceptical, in the habit of thinking that Self Modifying Code
must look such issues itself: but I guess there's nothing it can do to avoid
this one.
Fair enough, what you're changing it to is pretty much what powerpc and
s390 were already doing, and is a more robust way of proceeding, consistent
with how ptes are set everywhere else.
The ptep_clear_flush is a bit heavy-handed (it's anxious to return the pte
that was atomically cleared), but we'd have to wander through lots of arches
to get the right minimal behaviour. It'd also be nice to eliminate
ptep_establish completely, now only used to define other macros/inlines: it
always seemed obfuscation to me, what you've got there now is clearer.
Let's put those cleanups on a TODO list.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Acked-by: "David S. Miller" <davem@davemloft.net> Acked-by: Hugh Dickins <hugh@veritas.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
The clocksource infrastructure introduced with commit ad596171ed635c51a9eef829187af100cbf8dcf7 broke 31 bit s390.
The reason is that the do_div() primitive for 31 bit always
had a restriction: it could only divide an unsigned 64 bit
integer by an unsigned 31 bit integer. The clocksource code
now uses do_div() with a base value that has the most
significant bit set. The result is that clock->cycle_interval
has a funny value which causes the linux time to jump around
like mad.
The solution is "obvious": implement a proper __div64_32
function for 31 bit s390.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Acked-by: Steven Whitehouse <swhiteho@redhat.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Vasily Tarasov [Wed, 11 Oct 2006 11:23:48 +0000 (13:23 +0200)]
block layer: elv_iosched_show should get elv_list_lock
elv_iosched_show function iterates other elv_list,
hence elv_list_lock should be got.
Also the question is: in elv_iosched_show, elv_iosched_store
q->elevator->elevator_type construction is used without locking q->queue_lock.
Is it expected?..
Patrick McHardy [Wed, 11 Oct 2006 08:53:26 +0000 (01:53 -0700)]
NETFILTER: NAT: fix NOTRACK checksum handling
The whole idea with the NOTRACK netfilter target is that
you can force the netfilter code to avoid connection
tracking, and all costs assosciated with it, by making
traffic match a NOTRACK rule.
But this is totally broken by the fact that we do a checksum
calculation over the packet before we do the NOTRACK bypass
check, which is very expensive. People setup NOTRACK rules
explicitly to avoid all of these kinds of costs.
This patch from Patrick, already in Linus's tree, fixes the
bug.
Move the check for ip_conntrack_untracked before the call to
skb_checksum_help to fix NOTRACK excemptions from NAT. Pre-2.6.19
NAT code breaks TSO by invalidating hardware checksums for every
packet, even if explicitly excluded from NAT through NOTRACK.
2.6.19 includes a fix that makes NAT and TSO live in harmony,
but the performance degradation caused by this deserves making
at least the workaround work properly in -stable.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Larry Finger [Tue, 10 Oct 2006 17:18:26 +0000 (12:18 -0500)]
bcm43xx: fix regressions in 2.6.18
The bcm43xx code in 2.6.18 has a serious problems not found in 2.6.17, due to
a change in the locking mechanism introduced to reduce latency. The following patch
fixes the problems in locking, reduces the latency associated with the periodic
work tasklet, and contains code needed for those cards that use 64-bit DMA.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jon Mason [Tue, 10 Oct 2006 14:04:23 +0000 (09:04 -0500)]
x86-64: Calgary IOMMU: Fix off by one when calculating register space location
This patch has already been submitted for inclusion in the 2.6.19
tree, but not backported to the 2.6.18. Please pull the bug fix
below into the stable tree for the 2.6.18.1 release.
The purpose of the code being modified is to determine the location
of the calgary chip address space. This is done by a magical formula
of FE0MB-8MB*OneBasedChassisNumber+1MB*(RioNodeId-ChassisBase) to
find the offset where BIOS puts it. In this formula,
OneBasedChassisNumber corresponds to the NUMA node, and rionodeid is
always 2 or 3 depending on which chip in the system it is. The
problem was that we had an off by one error that caused us to account
some busses to the wrong chip and thus give them the wrong address
space.
Thanks alexander.krause@erazor-zone.de, dzpost@dedekind.net, for the
reports and patch test, and phelps@mantara.com for the independent patch
and verification.
Signed-off-by: Jim Cromie <jim.cromie@gmail.com> Cc: <alexander.krause@erazor-zone.de> Cc: <dzpost@dedekind.net> Cc: <phelps@mantara.com> Acked-by: John Stultz <johnstul@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Andrew Morton [Sun, 1 Oct 2006 06:29:29 +0000 (23:29 -0700)]
invalidate_inode_pages2(): ignore page refcounts
The recent fix to invalidate_inode_pages() (git commit 016eb4a) managed to
unfix invalidate_inode_pages2().
The problem is that various bits of code in the kernel can take transient refs
on pages: the page scanner will do this when inspecting a batch of pages, and
the lru_cache_add() batching pagevecs also hold a ref.
Net result is transient failures in invalidate_inode_pages2(). This affects
NFS directory invalidation (observed) and presumably also block-backed
direct-io (not yet reported).
Fix it by reverting invalidate_inode_pages2() back to the old version which
ignores the page refcounts.
We may come up with something more clever later, but for now we need a 2.6.18
fix for NFS.
Cc: Chuck Lever <cel@citi.umich.edu> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The century bit PCF8563_MO_C in the month register is misinterpreted. It
is set to 1 for the 20th century and 0 for 21th, and the driver is
expecting the opposite behavior.
David Miller [Thu, 28 Sep 2006 21:50:30 +0000 (14:50 -0700)]
TCP: Fix and simplify microsecond rtt sampling
This changes the microsecond RTT sampling so that samples are taken in
the same way that RTT samples are taken for the RTO calculator: on the
last segment acknowledged, and only when the segment hasn't been
retransmitted.
Signed-off-by: John Heffner <jheffner@psc.edu> Acked-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Neil Brown [Tue, 3 Oct 2006 07:15:00 +0000 (17:15 +1000)]
MD: Fix problem where hot-added drives are not resynced.
If a drive is added with HOT_ADD_DISK rather than ADD_NEW_DISK,
saved_raid_disk isn't initialised properly, and the drive can be
included in the array without a resync.
From: Neil Brown <neilb@suse.de> Cc: <syrius.ml@no-log.org> Cc: Richard Bollinger <rabollinger@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Miller [Thu, 28 Sep 2006 02:04:35 +0000 (19:04 -0700)]
IPV6: Disable SG for GSO unless we have checksum
Because the system won't turn off the SG flag for us we
need to do this manually on the IPv6 path. Otherwise we
will throw IPv6 packets with bad checksums at the hardware.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Miller [Wed, 27 Sep 2006 23:25:17 +0000 (16:25 -0700)]
PKT_SCHED: cls_basic: Use unsigned int when generating handle
gcc-4.1 and later take advantage of the fact that in the
C language certain types of overflow/underflow are undefined,
and this is completely legitimate.
Prevents filters from being added if the first generated
handle already exists.
Signed-off-by: Kim Nordlund <kim.nordlund@nokia.com> Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Wed, 27 Sep 2006 06:15:38 +0000 (23:15 -0700)]
SPARC64: Fix sparc64 ramdisk handling
[SPARC64]: Kill bogus check from bootmem_init().
There is an ancient and totally incorrect sanity check being
done on the ramdisk location. The check assumes that the
kernel is always loaded to physical address zero, which is
wrong. It was trying to validate the ramdisk value by saying that
if it fell within the kernel image address range it must be wrong.
Anyways, kill this because it actually creates problems. The
'ramdisk_image' should always be adjusted down by KERNBASE.
SILO can easily put the ramdisk in a location which causes
this test to trigger, breaking things.
[ Based almost entirely upon a patch from Ben Collins. ]
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
A while ago Ingo patched tcp_v4_rcv on net/ipv4/tcp_ipv4.c to use
bh_lock_sock_nested and silence a lock validator warning. This fixed
it for IPv4, but recently I saw a report of the same warning on IPv6.
Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
As there are other places that call cpufreq_update_policy without
the hotplug lock, it seems better to keep the hotplug locking
at the lower level for the time being until this is revamped.
Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David S. Miller [Sun, 24 Sep 2006 01:26:24 +0000 (18:26 -0700)]
SPARC64: Fix serious bug in sched_clock() on sparc64
Unfortunately, sparc64 doesn't have an easy way to do a "64 X 64 -->
128" bit multiply like PowerPC and IA64 do. We were doing a
"64 X 64 --> 64" bit multiple which causes overflow very quickly with
a 30-bit quotient shift.
So use a quotientshift count of 10 instead of 30, just like x86 and
ARM do.
This also fixes the wrapping of printk timestamp values every ~17
seconds.
Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jonathan Corbet [Mon, 25 Sep 2006 23:25:37 +0000 (16:25 -0700)]
Fix VIDIOC_ENUMSTD bug
The v4l2 API documentation for VIDIOC_ENUMSTD says:
To enumerate all standards applications shall begin at index
zero, incrementing by one until the driver returns EINVAL.
The actual code, however, tests the index this way:
if (index<=0 || index >= vfd->tvnormsize) {
ret=-EINVAL;
So any application which passes in index=0 gets EINVAL right off the bat
- and, in fact, this is what happens to mplayer. So I think the
following patch is called for, and maybe even appropriate for a 2.6.18.x
stable release.
Signed-off-by: Jonathan Corbet <corbet@lwn.net> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Ed Swierk [Mon, 25 Sep 2006 23:25:36 +0000 (16:25 -0700)]
load_module: no BUG if module_subsys uninitialized
Invoking load_module() before param_sysfs_init() is called crashes in
mod_sysfs_setup(), since the kset in module_subsys is not initialized yet.
In my case, net-pf-1 is getting modprobed as a result of hotplug trying to
create a UNIX socket. Calls to hotplug begin after the topology_init
initcall.
Another patch for the same symptom (module_subsys-initialize-earlier.patch)
moves param_sysfs_init() to the subsys initcalls, but this is still not
early enough in the boot process in some cases. In particular,
topology_init() causes /sbin/hotplug to run, which requests net-pf-1 (the
UNIX socket protocol) which can be compiled as a module. Moving
param_sysfs_init() to the postcore initcalls fixes this particular race,
but there might well be other cases where a usermodehelper causes a module
to load earlier still.
The patch makes load_module() return an error rather than crashing the
kernel if invoked before module_subsys is initialized.
Cc: Mark Huang <mlhuang@cs.princeton.edu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We have additional_cpus= option for allocating possible_cpus. But nid
for possible cpus are not fixed at boot time. cpus which is offlined at
boot or cpus which is not on SRAT is not tied to its node. This will
cause panic at cpu onlining.
Usually, pxm_to_nid() mapping is fixed at boot time by SRAT.
But, unfortunately, some system (my system!) do not include
full SRAT table for possible cpus. (Then, I use
additiona_cpus= option.)
For such possible cpus, pxm<->nid should be fixed at
hot-add. We now have acpi_map_pxm_to_node() which is also
used at boot. It's suitable here.
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
backlight: fix oops in __mutex_lock_slowpath during head /sys/class/graphics/fb0/*
Seems like not all drivers use the framebuffer_alloc() function and won't
have an initialized mutex. But those don't have a backlight, anyway.
Signed-off-by: Michael Hanselmann <linux-kernel@hansmi.ch> Cc: Olaf Hering <olaf@aepfle.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Daniel R Thompson <daniel.thompson@st.com> Cc: Jon Smirl <jonsmirl@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
keith mannthey [Mon, 25 Sep 2006 23:24:39 +0000 (16:24 -0700)]
i386 bootioremap / kexec fix
With CONFIG_PHYSICAL_START set to a non default values the i386
boot_ioremap code calculated its pte index wrong and users of boot_ioremap
have their areas incorrectly mapped (for me SRAT table not mapped during
early boot). This patch removes the addr < BOOT_PTE_PTRS constraint.
Signed-off-by: Keith Mannthey<kmannth@us.ibm.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
sysfs: remove duplicated dput in sysfs_update_file
Following function can drops d_count twice against one reference
by lookup_one_len.
<SOURCE>
/**
* sysfs_update_file - update the modified timestamp on an object attribute.
* @kobj: object we're acting for.
* @attr: attribute descriptor.
*/
int sysfs_update_file(struct kobject * kobj, const struct attribute * attr)
{
struct dentry * dir = kobj->dentry;
struct dentry * victim;
int res = -ENOENT;
mutex_lock(&dir->d_inode->i_mutex);
victim = lookup_one_len(attr->name, dir, strlen(attr->name));
if (!IS_ERR(victim)) {
/* make sure dentry is really there */
if (victim->d_inode &&
(victim->d_parent->d_inode == dir->d_inode)) {
victim->d_inode->i_mtime = CURRENT_TIME;
fsnotify_modify(victim);
/**
* Drop reference from initial sysfs_get_dentry().
*/
dput(victim);
res = 0;
} else
d_drop(victim);
/**
* Drop the reference acquired from sysfs_get_dentry() above.
*/
dput(victim);
}
mutex_unlock(&dir->d_inode->i_mutex);
return res;
}
</SOURCE>
PCI-hotplug (drivers/pci/hotplug/pci_hotplug_core.c) is only user of
this function. I confirmed that dentry of /sys/bus/pci/slots/XXX/*
have negative d_count value.
Ulrich Weigand found a bug with the current version of the
asm-powerpc/ptrace.h that prevents building at least the
SPU target version of gdb, since some ptrace opcodes are
not defined.
The problem seems to have originated in the merging of 32 and
64 bit versions of that file, the problem is that some opcodes
are only valid on 64 bit kernels, but are also used by 32 bit
programs, so they can't depends on the __powerpc64__ symbol.
David Woodhouse [Thu, 21 Sep 2006 07:48:27 +0000 (08:48 +0100)]
Fix exported headers for SPARC, SPARC64
Mostly removing files which have no business being used in userspace.
Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Woodhouse [Sun, 17 Sep 2006 07:39:39 +0000 (08:39 +0100)]
Fix 'make headers_check' on m32r
> asm-m32r/page.h requires asm-generic/memory_model.h, which does not exist
> asm-m32r/ptrace.h requires asm/m32r.h, which does not exist
> asm-m32r/signal.h requires linux/linkage.h, which does not exist
> asm-m32r/unistd.h requires asm/syscall.h, which does not exist
> asm-m32r/user.h requires asm/processor.h, which does not exist
Paul Mundt [Tue, 19 Sep 2006 18:27:17 +0000 (03:27 +0900)]
Fix 'make headers_check' on sh64
Cleanup for user headers, as noted:
asm-sh64/page.h requires asm-generic/memory_model.h, which does not exist in exported headers
asm-sh64/shmparam.h requires asm/cache.h, which does not exist in exported headers
asm-sh64/signal.h requires asm/processor.h, which does not exist in exported headers
asm-sh64/user.h requires asm/processor.h, which does not exist in exported headers
Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Paul Mundt [Tue, 19 Sep 2006 18:25:34 +0000 (03:25 +0900)]
Fix 'make headers_check' on sh
Cleanup for user headers, as noted:
asm-sh/page.h requires asm-generic/memory_model.h, which does not exist in exported headers
asm-sh/ptrace.h requires asm/ubc.h, which does not exist in exported headers
Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The sky2 driver will hang if transmit flow control is enabled
and it receives a pause frame. The pause frame gets partially
processed by hardware but never makes it through to the correct
logic. This patch made it into 2.6.17 stable, but never got
accepted for 2.6.18, so it will have to go into 2.6.18.1
See also: http://bugzilla.kernel.org/show_bug.cgi?id=6839
Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Currently one can enable slab reclaim by setting an explicit option in
/proc/sys/vm/zone_reclaim_mode. Slab reclaim is then used as a final
option if the freeing of unmapped file backed pages is not enough to free
enough pages to allow a local allocation.
However, that means that the slab can grow excessively and that most memory
of a node may be used by slabs. We have had a case where a machine with
46GB of memory was using 40-42GB for slab. Zone reclaim was effective in
dealing with pagecache pages. However, slab reclaim was only done during
global reclaim (which is a bit rare on NUMA systems).
This patch implements slab reclaim during zone reclaim. Zone reclaim
occurs if there is a danger of an off node allocation. At that point we
1. Shrink the per node page cache if the number of pagecache
pages is more than min_unmapped_ratio percent of pages in a zone.
2. Shrink the slab cache if the number of the nodes reclaimable slab pages
(patch depends on earlier one that implements that counter)
are more than min_slab_ratio (a new /proc/sys/vm tunable).
The shrinking of the slab cache is a bit problematic since it is not node
specific. So we simply calculate what point in the slab we want to reach
(current per node slab use minus the number of pages that neeed to be
allocated) and then repeately run the global reclaim until that is
unsuccessful or we have reached the limit. I hope we will have zone based
slab reclaim at some point which will make that easier.
The default for the min_slab_ratio is 5%
Also remove the slab option from /proc/sys/vm/zone_reclaim_mode.
[akpm@osdl.org: cleanups] 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: Greg Kroah-Hartman <gregkh@suse.de>
Fix longstanding load balancing bug in the scheduler
The scheduler will stop load balancing if the most busy processor contains
processes pinned via processor affinity.
The scheduler currently only does one search for busiest cpu. If it cannot
pull any tasks away from the busiest cpu because they were pinned then the
scheduler goes into a corner and sulks leaving the idle processors idle.
F.e. If you have processor 0 busy running four tasks pinned via taskset,
there are none on processor 1 and one just started two processes on
processor 2 then the scheduler will not move one of the two processes away
from processor 2.
This patch fixes that issue by forcing the scheduler to come out of its
corner and retrying the load balancing by considering other processors for
load balancing.
This patch was originally developed by John Hawkes and discussed at
http://marc.theaimsgroup.com/?l=linux-kernel&m=113901368523205&w=2.
I have removed extraneous material and gone back to equipping struct rq
with the cpu the queue is associated with since this makes the patch much
easier and it is likely that others in the future will have the same
difficulty of figuring out which processor owns which runqueue.
The overhead added through these patches is a single word on the stack if
the kernel is configured to support 32 cpus or less (32 bit). For 32 bit
environments the maximum number of cpus that can be configued is 255 which
would result in the use of 32 bytes additional on the stack. On IA64 up to
1k cpus can be configured which will result in the use of 128 additional
bytes on the stack. The maximum additional cache footprint is one
cacheline. Typically memory use will be much less than a cacheline and the
additional cpumask will be placed on the stack in a cacheline that already
contains other local variable.
Signed-off-by: Christoph Lameter <clameter@sgi.com> Cc: John Hawkes <hawkes@sgi.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Peter Williams <pwil3058@bigpond.net.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jan Kara [Mon, 11 Sep 2006 22:13:37 +0000 (15:13 -0700)]
jbd: fix commit of ordered data buffers
Original commit code assumes, that when a buffer on BJ_SyncData list is
locked, it is being written to disk. But this is not true and hence it can
lead to a potential data loss on crash. Also the code didn't count with
the fact that journal_dirty_data() can steal buffers from committing
transaction and hence could write buffers that no longer belong to the
committing transaction. Finally it could possibly happen that we tried
writing out one buffer several times.
The patch below tries to solve these problems by a complete rewrite of the
data commit code. We go through buffers on t_sync_datalist, lock buffers
needing write out and store them in an array. Buffers are also immediately
refiled to BJ_Locked list or unfiled (if the write out is completed). When
the array is full or we have to block on buffer lock, we submit all
accumulated buffers for IO.
[suitable for 2.6.18.x around the 2.6.19-rc2 timeframe]
Signed-off-by: Jan Kara <jack@suse.cz> Cc: Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jack Morgenstein [Wed, 20 Sep 2006 22:47:16 +0000 (15:47 -0700)]
IB/mthca: Fix lid used for sending traps
The SM LID used to send traps to is incorrectly set to port LID. This
is a regression from 2.6.17 -- after a PortInfo MAD is received, no
traps are sent to the SM LID. The traps go to the loopback interface
instead, and are dropped there. The SM LID should be taken from the
sm_lid of the PortInfo response.
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
S390: user readable uninitialised kernel memory (CVE-2006-5174)
[S390] user readable uninitialised kernel memory.
A user space program can read uninitialised kernel memory
by appending to a file from a bad address and then reading
the result back. The cause is the copy_from_user function
that does not clear the remaining bytes of the kernel
buffer after it got a fault on the user space address.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Daniel Drake [Mon, 9 Oct 2006 15:06:16 +0000 (16:06 +0100)]
zd1211rw: ZD1211B ASIC/FWT, not jointly decoder
The vendor driver chooses this value based on an ifndef ASIC,
and ASIC is never defined.
Signed-off-by: Daniel Drake <dsd@gentoo.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mike Isely [Sun, 8 Oct 2006 18:42:17 +0000 (14:42 -0400)]
V4L: pvrusb2: Limit hor res for 24xxx devices
Currently it is not understood how to properly control the horizontal
capture resolution on 24xxx devices. The pvrusb2 driver is doing
everything it should (pass resolution paramter(s) to cx2341x and
cx25840 modules) but for some reason the result is corrupted video if
any resolution other than 720 is used. This patch causes the driver
to only permit a horizontal resolution of 720 to be used on 24xxx
devices. Even if the app requests something else, the driver will
force the resolution back to 720. This patch still allows full
control of the resolution for 29xxx devices.
Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mike Isely [Sun, 8 Oct 2006 18:42:14 +0000 (14:42 -0400)]
V4L: pvrusb2: Suppress compiler warning
The pvrusb2 driver needs to call video_devdata() in order to correctly
transform a file pointer into a video_device pointer. Unfortunately
the prototype for this function has been marked V4L1-only and there's
no official substitute that I can find for V4L2. Adding to the
mystery is that the implementation for this function exists whether or
not V4L1 compatibility has been selected. The upshot of all this is
that we get a compilation warning here about a missing prototype but
the code links OK. This fix solves the warning by copying the
prototype into the source file that is using it. Yes this is a hack,
but it's a safe one for 2.6.18 (any alternative would be much more
intrusive). A better solution should be forthcoming for the next
kernel.
Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Mike Isely [Sun, 8 Oct 2006 18:42:08 +0000 (14:42 -0400)]
V4L: pvrusb2: Solve mutex deadlock
There is a mutex ordering problem between the pvrusb2 driver and the
v4l core. Two different pathways take mutexes in opposing orders and
this (under rare circumstances) can cause a deadlock. The two mutexes
in question are videodev_lock in the v4l core and device_lock inside
the pvrusb2 driver. The device_lock instance in the driver protects a
private global array of context pointers which had been implemented in
advance of v4l core changes which eliminate the video_set_drvdata()
and video_get_drvdata() functions.
This patch restores the use of video_get_drvdata() and
video_set_drvdata(), eliminating the need for the array and the mutex.
(This is actually a patch to restore the previous implementation.) We
can do this for 2.6.18 since those functions are in fact still
present. A better (and larger) solution will be done for later
kernels.
Signed-off-by: Mike Isely <isely@pobox.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Yeasah Pell [Sun, 8 Oct 2006 18:41:43 +0000 (14:41 -0400)]
DVB: cx24123: fix PLL divisor setup
The cx24109 datasheet says: "NOTE: if A=0, then N=N+1"
The current code is the result of a misinterpretation of the datasheet to
mean exactly the opposite of the requirement -- The actual value of N is 1
greater than the value written when A is 0, so 1 needs to be *subtracted*
from it to compensate.
Signed-off-by: Yeasah Pell <yeasah@schwide.net> Signed-off-by: Steven Toth <stoth@hauppauge.com> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Hans Verkuil [Sun, 8 Oct 2006 18:41:42 +0000 (14:41 -0400)]
V4L: Fix msp343xG handling regression
The msp3430G and msp3435G models cannot do Automatic Standard Detection,
so these should be forced to BTSC. These chips are early production
versions for the msp34xxG series and are quite rare.
The workaround for kernel 2.6.18 is to use 'standard=32' as msp3400 module
option.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Michael Krufky <mkrufky@linuxtv.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jeff Dike [Thu, 5 Oct 2006 18:27:32 +0000 (20:27 +0200)]
UML: Fix UML build failure
don't know if the following is already queued, it fixes an ARCH=um build
failure, evidence here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=115875912525137&w=2
and following thread.
Cc-ing uml maintainers and I hope I didn't follow too many
Submitting-patches rules...
The patch is taken from:
http://user-mode-linux.sourceforge.net/work/current/2.6/2.6.18/patches/no-syscallx
Since the syscallx macros seem to be under threat, this patch stops
using them, using syscall instead.
Acked-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
uml: use DEFCONFIG_LIST to avoid reading host's config
This should make sure that, for UML, host's configuration files are not
considered, which avoids various pains to the user. Our dependency are such that
the obtained Kconfig will be valid and will lead to successful compilation -
however they cannot prevent an user from disabling any boot device, and if an
option is not set in the read .config (say /boot/config-XXX), with make
menuconfig ARCH=um, it is not set. This always disables UBD and all console I/O
channels, which leads to non-working UML kernels, so this bothers users -
especially now, since it will happen on almost every machine
(/boot/config-`uname -r` exists almost on every machine). It can be workarounded
with make defconfig ARCH=um, but it is non-obvious and can be avoided, so please
_do_ merge this patch.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Acked-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Enable compilation of x86_64 crypto code;, and add the needed constant
to make the code compile again (that macro was added to i386 asm-offsets
between 2.6.17 and 2.6.18, in 6c2bb98bc33ae33c7a33a133a4cd5a06395fece5).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Acked-by: Jeff Dike <jdike@addtoit.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Patrick McHardy [Tue, 10 Oct 2006 04:16:11 +0000 (21:16 -0700)]
NET_SCHED: Fix fallout from dev->qdisc RCU change
The move of qdisc destruction to a rcu callback broke locking in the
entire qdisc layer by invalidating previously valid assumptions about
the context in which changes to the qdisc tree occur.
The two assumptions were:
- since changes only happen in process context, read_lock doesn't need
bottem half protection. Now invalid since destruction of inner qdiscs,
classifiers, actions and estimators happens in the RCU callback unless
they're manually deleted, resulting in dead-locks when read_lock in
process context is interrupted by write_lock_bh in bottem half context.
- since changes only happen under the RTNL, no additional locking is
necessary for data not used during packet processing (f.e. u32_list).
Again, since destruction now happens in the RCU callback, this assumption
is not valid anymore, causing races while using this data, which can
result in corruption or use-after-free.
Instead of "fixing" this by disabling bottem halfs everywhere and adding
new locks/refcounting, this patch makes these assumptions valid again by
moving destruction back to process context. Since only the dev->qdisc
pointer is protected by RCU, but ->enqueue and the qdisc tree are still
protected by dev->qdisc_lock, destruction of the tree can be performed
immediately and only the final free needs to happen in the rcu callback
to make sure dev_queue_xmit doesn't access already freed memory.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
projects / karo-tx-linux.git / log