Holger Schurig [Fri, 20 Feb 2004 16:52:31 +0000 (16:52 +0000)]
[ARM PATCH] 1670/1: PXA serial driver
Patch from Holger Schurig
PXA Serial port (FFUART, BTUART, STUART) and console support
This patch works perfectly here with "console=ttyS0,115200" in the
kernel command line. It contains Jean-frederic Clere fix to detect
STUART and BTUART.
Nico said that I should post it to your patch tracker. It replaces patch 1662/1
Greg Ungerer [Wed, 18 Feb 2004 14:15:10 +0000 (06:15 -0800)]
[PATCH] fixes to ColdFire/5407 startup code
Correct the cache setup bits for the 5407. This enables the write
buffers properly (despite what the previous comment said). This
combined with fixed cache flushing code provides a nice performance
boost on the 5407.
Also fix the ROMfs setup to only move the ROMfs region if it is actually
configured.
Greg Ungerer [Wed, 18 Feb 2004 13:41:28 +0000 (05:41 -0800)]
[PATCH] allow configuration for shared flat binary support
This adds the configuration option to enable the uClinux shared flat
binary support. The code support is already in the binfmt_load code,
just the config option is missing.
Andrew Morton [Wed, 18 Feb 2004 13:00:09 +0000 (05:00 -0800)]
[PATCH] mark ftape un-removable
From: Christoph Hellwig <hch@lst.de>
I've just grepped over the tree for reamining MOD_INC_USE_COUNT users, and
ftape is a really horrible one, it relies on MOD_{INC,DEV}_USE_COUNT in the
most horrible places + it's own bookkepping and the <= 2.4 may unload
hooks. And although I don't have the hardware I can guarantee it doesn't
work as expected.
So let's just remove the module_exit handler and mark it unremovable, if
someone wants to fix up ftape later it's fine with me, but it's a really
scary driver..
Andrew Morton [Wed, 18 Feb 2004 12:59:51 +0000 (04:59 -0800)]
[PATCH] crc32.c copyright fix
From: Matt Domsch <Matt_Domsch@dell.com>
Patch below applies to both 2.4.25 and 2.6.3, and replaces the public
domain statement and non-warranty with the GPL, as is permitted by the code
being in the public domain, and is done with legal advice.
Andrew Morton [Wed, 18 Feb 2004 12:59:42 +0000 (04:59 -0800)]
[PATCH] tuner driver fixes
From: Gerd Knorr <kraxel@bytesex.org>
"options tuner type=2" is just there for historical reasons and should
only be used/needed if the main driver doesn't allow to configure the
tuner type. I'm not sure whenever I can remove that altogether without
breaking anything. There are several users of the tuner module, some
outside the standard kernel tree ...
> > if (type < TUNERS) {
> > + t->type = type;
> > printk("tuner: type forced to %d (%s) [insmod]\n",
> > t->type,tuners[t->type].name);
> > set_type(client,type);
That is wrong, it will break in other corner cases, it may cause the
set_type() function not doing the initializations.
The prink can also be dropped because set_type does that too. The patch
below removes that. It also makes the kernel messages a bit more verbose
and adds support for two new tuners.
The file initramfs_data.cpio is slightly different when generated on
cygwin, compared to linux, which causes the kernel to panic with the
message "no cpio magic" (See Documentation/early-userspace/README).
The problem in cpio generation is due to the difference in sprintf
modifiers on cygwin. The code uses "%08ZX" for strlen of a device node.
printf man pages discourages "Z" and has 'z' instead. Both of these are
not available on cygwin sprintf (at least some versions of cygwin). The
net result of all of this is that the generated file literally contains
"ZX" and then the strlen after that and messes up that 110 offset etc. The
file is 516 bytes long on the system that I tested and on linux it is 512
bytes.
Andrew Morton [Wed, 18 Feb 2004 12:58:57 +0000 (04:58 -0800)]
[PATCH] Remove overenthusiastic BUG in smp_boot_cpus
From: "Martin J. Bligh" <mbligh@aracnet.com>
There's no real need to BUG and stop the system from booting if the BIOS
spec'ed apicid for the boot CPU isn't correct - we can continue perfectly
well with the real one.
I created the little wrapper function that was requested. I think the only
other arch, other than ia64, that doesn't at least include asm-generic/tlb.h
is arm.
Something appears broken in TLB flushing on IA64 (& possibly other
architectures). Functionally, it works but performance is bad on systems
with large cpu counts.
The result is that TLB flushing in exit_mmap() is frequently being done via
IPIs to all cpus rather than with a "ptc" instruction or with a new
context..
Andrew Morton [Wed, 18 Feb 2004 12:58:20 +0000 (04:58 -0800)]
[PATCH] Fix make rpm when using RH9 or Fedora..
From: Thomas Davis <tadavis@lbl.gov>
Doing a 'make rpm' will fail with the current RH9/Fedora RPM macros.
The failure message is this:
Processing files: kernel-debuginfo-2.6.3rc1mm1-12
error: Could not open %files file /usr/src/redhat/BUILD/kernel-2.6.3rc1mm1/debugfiles.list: No such file or directory
Andrew Morton [Wed, 18 Feb 2004 12:58:11 +0000 (04:58 -0800)]
[PATCH] dm-crypt
From: Christophe Saout <christophe@saout.de>
Adds a crypto module for device-mapper. The intent here is to remove
cryptoloop ASAP, to pull the remapping gunk out of the loops driver and to
migrate people onto dm-crypt. It is on-disk compatible with existing
cryptolop installations.
See http://www.saout.de/misc/dm-crypt/ for usage details.
Andrew Morton [Wed, 18 Feb 2004 12:57:52 +0000 (04:57 -0800)]
[PATCH] ide-tape: remove obsolete onstream support
From: Willem Riede <wrlk@riede.org>
The onstream drives, be they scsi, atapi, ieee1394 or usb, are supported by the
osst driver. When the drives were new, code was introduced in ide-tape
independently, but never really maintained since. There are issues with the
drives I found and dealt with in osst, that ide-tape doesn't address.
So this code in ide-tape is both redundant and imperfect. I assumed from
http://marc.theaimsgroup.com/?l=linux-kernel&m=107550547613846&w=2 that there
was buy in for removing it.
When this patch is applied, ide-tape will refuse to attach to an onstream DI
drive, and will write to syslog to use ide-scsi + osst instead.
Andrew Morton [Wed, 18 Feb 2004 12:57:25 +0000 (04:57 -0800)]
[PATCH] Fix race in epoll_ctl(EPOLL_CTL_MOD)
From: Davide Libenzi <davidel@xmailserver.org>
A potential race can happen in epoll_ctl(EPOLL_CTL_MOD) where an event can
happen in between f_op->poll() and the lock on ep->lock (we cannot call
f_op->poll() inside a lock, and the f_op->poll() callback does not carry
any info at the current time - missing wake_up_info() already ;). In that
case the event would be removed. We can easily leave the event inside the
ready list and have the ep_send_events() logic do the job for us at later
time. (Thanks to david.lee@teracruz.com for reporting the thing, since it
shouldn't have been a nice one ;)
Andrew Morton [Wed, 18 Feb 2004 12:56:48 +0000 (04:56 -0800)]
[PATCH] Fix __release_region() race
From: MAEDA Naoaki <maeda.naoaki@jp.fujitsu.com>
I am testing PCI hot-plug in 2.6.2 kernel, but sometimes a struct resource
tree in kernel/resource.c was broken if multiple hot-plug requests are
issued at the same time.
The reason is lots of drivers call release_region() on hot removal, and
__release_region(), which is invoked by release_region() macro, changes the
tree without holding a writer lock for resource_lock.
I think __release_region() must hold a writer lock as well as
__request_region() does.
A following patch fixes the issue in my environment.
Andrew Morton [Wed, 18 Feb 2004 12:56:30 +0000 (04:56 -0800)]
[PATCH] oprofile: add Pentium Mobile support
From: Philippe Elie <phil.el@wanadoo.fr>
From: Will Cohen <wcohen@redhat.com>
Add oprofile support for Pentium Mobile (P6 core). Pentium Mobile needs to
unmask LVPTC vector, since it doesn't hurt other P6 core based cpus we do
it unconditionally for all these.
This patch require userspace tools >= 0.8 (only in sourceforge cvs currently)
Andrew Morton [Wed, 18 Feb 2004 12:56:21 +0000 (04:56 -0800)]
[PATCH] oprofile: ARM infrastructure
From: Philippe Elie <phil.el@wanadoo.fr>
From: Zwane Mwaikambo <zwane@arm.linux.org.uk>
This patch adds infrastructure code and enables ARM to utilise the timer
int oprofile driver. There is PMU code under development for the XScale
but that is still forthcoming. In the meantime you can use the timer int
driver with an updated Oprofile-CVS userspace (SF is a bit slow, please
allow 24hrs).
Andrew Morton [Wed, 18 Feb 2004 12:55:53 +0000 (04:55 -0800)]
[PATCH] cleanup patch that prepares for 4Kb stacks
From: Arjan van de Ven <arjanv@redhat.com>
I have 4Kb stacks + IRQ stacks working in my tree. The biggest part of the
4K-stacks work is changing hardcoded 8Kb assumptions to the proper,
pre-existing define for this. That part of the patch is appropriate in
general, even when 4Kb stacks might not be.
Andrew Morton [Wed, 18 Feb 2004 12:55:44 +0000 (04:55 -0800)]
[PATCH] fix display of NBD in /proc/partitions
The recent change to /proc/partitions which prevents it from displaying
removeable media accidentally caused 128 NBD and 16 ramdisk partitions to
appear in /proc/partitions instead.
So add a specific gendisk flag which says "don't show me in /proc/partitions"
and use that.
Andrew Morton [Wed, 18 Feb 2004 12:55:26 +0000 (04:55 -0800)]
[PATCH] off_t in nfsd_commit needs to be loff_t
From: Neil Brown <neilb@cse.unsw.edu.au>,
From: Miquel van Smoorenburg <miquels@cistron.nl>
While I was stress-testing NFS/XFS on 2.6.1/2.6.2-rc, I found that
sometimes my "dd" would exit with:
# dd if=/dev/zero bs=4096 > /mnt/file
dd: writing `standard output': Invalid argument 1100753+0 records in 1100752+0 records out
After adding some debug printk's to the server and client code and some
tcpdump-ing, I found that the NFSERR_INVAL was returned by nfsd_commit on
the server.
Turns out that the "offset" argument is off_t instead of loff_t. It isn't
used at all (unfortunately), but it _is_ checked for sanity, so that's
where the error came from.
Andrew Morton [Wed, 18 Feb 2004 12:55:17 +0000 (04:55 -0800)]
[PATCH] drivers/char/vt possible race
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
I falled again on the crash in con_do_write() with driver->data beeing
NULL. It happens during boot, when userland is playing open/close games
with tty's, I was intentionally typing keys like mad during boot trying to
trigger another problem when this one poped up.
Looking at the code, I'm not sure how protected we are by the above (tty)
layer, paulus told me to not rely on anything like locking coming from
there, so I decided to extend the scope of the console semaphore one more
bit to cover races between calls to con_open, con_close and con_write.
Note that in con_do_write, I intentionally drop the semaphore to avoid
keeping it held when waiting on the local buffer, and I added some sanity
checks on tty->driver_data with some printk's in case we still have an open
race by the tty layer. At least, now, the couple vc_allocated &
tty->driver_data should be protected though.
I had a look at fs/proc/base.c and found that the 'lookup' functions for
these directories were checking that the task in question existed, but
overlooked the following:
1. In the function proc_pid_lookup, a check is required to ensure that
the task in question is a thread group leader. Without the check, any
task can have its data retrieved accordingly. Consider the following.
There is a multithreaded process 1777.
2. The other part of the bug is in the function proc_task_lookup. Here
there needs to be a check that the task X is indeed a thread of the
thread group Y when we read /proc/<Y>/task/<X>.
Right now, this check does not exist, which allows for any existing
task to have its data read from another thread group directory. The
following reads the stat directory of my bash shell from the thread
group 1.
gen2 23:28:07 ~: cd /proc/1
gen2 23:28:10 /proc/1: ls
auxv cwd exe maps mounts stat status wchan
cmdline environ fd mem root statm task
gen2 23:28:11 /proc/1: ls task
1
gen2 23:28:27 /proc/1: cat task/$$/stat
1671 (bash) S 1670 1671 1671 34817 1802 256 1953 8101 12 4 10 6 9 26 15 0 1 0 5789 3252224 454 4294967295134512640134955932322122510432212228404294960144 0 65536 368640412667614673222442959 0 0 17 0 0 0
Andrew Morton [Wed, 18 Feb 2004 12:54:41 +0000 (04:54 -0800)]
[PATCH] defer panic for too many items in boot parameter line
From: Werner Almesberger <werner@almesberger.net>
When passing too many unrecognized boot command line options (which become
arguments or environment variables), the 2.6 kernel panics (unlike 2.4,
which just ignores the extra items). Unfortunately, this happens before
the console is initialized, so all you get is a kernel that dies quickly,
for no apparent reason.
This is particularly irritating if using UML with
init=something wi th a lot of ar gu men t s
The patch below delays the panic until after console_init.
(akpm: I mainly added this in because we have other places where the
panic-later-on machinery is needed).
Andrew Morton [Wed, 18 Feb 2004 12:53:55 +0000 (04:53 -0800)]
[PATCH] Rename bitmap_snprintf() and cpumask_snprintf() to *_scnprintf()
From: Joe Korty <joe.korty@ccur.com>
Rename bitmap_snprintf() to bitmap_scnprintf() and cpumask_snprintf() to
cpumask_scnprintf(), as these functions now belong to the scnprintf family
of functions.
Andrew Morton [Wed, 18 Feb 2004 12:53:28 +0000 (04:53 -0800)]
[PATCH] 8259 timer ack fix
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Fix up the 8259 ack handling for buggy SMM firmware.
See http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/0956.html
Apparently the embedded 8259A-compatible core is not fully functional.
This patch lets the I/O APIC-driven NMI watchdog to function correctly.
Credit to Ross Dickson for discovering this.
Andrew Morton [Wed, 18 Feb 2004 12:53:19 +0000 (04:53 -0800)]
[PATCH] dm: drop BIO_SEG_VALID bit
From: Joe Thornber <thornber@redhat.com>
I just noticed that bio_clone copies the BIO_SEG_VALID bit from the original
bio when it was set. When we modify bi_idx or bi_vcnt afterwards the segment
counts are invalid and the bit must be dropped (though it is fairly unlikely
that it has already been set). [Christophe Saout]
Andrew Morton [Wed, 18 Feb 2004 12:51:58 +0000 (04:51 -0800)]
[PATCH] md: Allow partitioning of MD devices.
From: NeilBrown <neilb@cse.unsw.edu.au>
With this patch, md used two major numbers for arrays.
One Major is number 9 with name 'md' have unpartitioned md arrays, one per
minor number.
The other Major is allocated dynamically with name 'mdp' and had on array for
every 64 minors, allowing for upto 63 partitions.
The arrays under one major are completely separate from the arrays under the
other.
The preferred name for devices with the new major are of the form:
/dev/md/d1p3 # partion 3 of device 1 - minor 67
When a paritioned md device is assembled, the partitions are not recognised
until after the whole-array device is opened again. A future version of
mdadm will perform this open so that the need will be transparent.
Andrew Morton [Wed, 18 Feb 2004 12:51:49 +0000 (04:51 -0800)]
[PATCH] md: Dynamically limit size of bio requests used for raid1 resync
From: NeilBrown <neilb@cse.unsw.edu.au>
Currently raid1 uses PAGE_SIZE read/write requests for resync, as it doesn't
know how to honour per-device restrictions. This patch uses to bio_add_page
to honour those restrictions and ups the limit on request size to 64K. This
has a measurable impact on rebuild speed (25M/s -> 60M/s)
Andrew Morton [Wed, 18 Feb 2004 12:51:40 +0000 (04:51 -0800)]
[PATCH] md: Avoid unnecessary bio allocation during raid1 resync
From: NeilBrown <neilb@cse.unsw.edu.au>
For each resync request, we allocate a "r1_bio" which has a bio "master_bio"
attached that goes largely unused. We also allocate a read_bio which is
used. This patch removes the read_bio and just uses the master_bio instead.
This fixes a bug wherein bi_bdev of the master_bio wasn't being set, but was
being used.
We also introduce a new "sectors" field into the r1_bio as we can no-longer
rely in master_bio->bi_sectors.
Andrew Morton [Wed, 18 Feb 2004 12:51:31 +0000 (04:51 -0800)]
[PATCH] md: Remove some un-needed fields from r1bio_s
From: NeilBrown <neilb@cse.unsw.edu.au>
next_r1 is never used, so it can just go.
read_bio isn't needed as we can easily use one of the pointers in the
write_bios array - write_bios[->read_disk]. So rename "write_bios" to "bios"
and store the pointer to the read bio in there.
Andrew Morton [Wed, 18 Feb 2004 12:51:22 +0000 (04:51 -0800)]
[PATCH] md: Discard the cmd field from r1_bio structure
From: NeilBrown <neilb@cse.unsw.edu.au>
The only time it is really needed is to differentiate a retry-on-fail from a
write-after-read-for-resync request to raid1d. So we use a bit in 'state'
for that.
Andrew Morton [Wed, 18 Feb 2004 12:51:13 +0000 (04:51 -0800)]
[PATCH] md: Split read and write end_request handlers
From: NeilBrown <neilb@cse.unsw.edu.au>
Instead of having a single end_request handler that must determine whether it
was a read or a write request, we have two separate handlers, which makes
each of them easier to follow.
Andrew Morton [Wed, 18 Feb 2004 12:50:37 +0000 (04:50 -0800)]
[PATCH] kNFSd: ip_map_init does a kmalloc which isn't checked...
From: NeilBrown <neilb@cse.unsw.edu.au>
There is no way to return an error from a cache init routine, so instead we
make sure to pre-allocate the memory needed, and free it after the lookup
if the lookup failed.
Andrew Morton [Wed, 18 Feb 2004 12:50:28 +0000 (04:50 -0800)]
[PATCH] kNFSd: Allow sunrpc/svc cache init function to modify the "key"
From: NeilBrown <neilb@cse.unsw.edu.au>
When adding a item to a sunrpc/svc cache that contains kmalloced data it is
usefully to move the malloced data out of the key object into the new cache
object rather than copying (as then we would need to cope with kmalloc
failure and such). This means modifying the original.
If the kmalloced data forms part of the key, then we must not move the data
out until after the key isn't needed any more. So this patch moves the
call to "INIT" on a new item (which fills in the key) to *after* the item
has been found (or not), and also makes sure we only call the HASH function
once.
Thanks to "J. Bruce Fields" <bfields@fieldses.org>
also
1/ remove unnecessary assignment
2/ fix comments that lag behind implementation.
Andrew Morton [Wed, 18 Feb 2004 12:50:10 +0000 (04:50 -0800)]
[PATCH] #if versus #ifdef cleanup
From: Valdis.Kletnieks@vt.edu
15 changes of #if to #ifdef and 2 places CONFIG_FOO should be
defined(CONFIG_FOO). This gets rid of spurious warnings if you build with
"-Wundef" so you get a warning if you have a preprocessor command like:
#if CONFIG_ETRAX_DS1302_RSTBIT == 27
and you'll be told if it's substituting a zero rather than silent
weirdness and unexpected code generation.
Andrew Morton [Wed, 18 Feb 2004 12:49:52 +0000 (04:49 -0800)]
[PATCH] Enable coredumps > 2GB
From: Andi Kleen <ak@muc.de>
Some x86-64 users were complaining that coredumps >2GB don't work.
This will enable large coredump for everybody. Apparently the 32bit
gdb/binutils cannot handle them, but I hear the binutils people are working
on fixing that. I doubt it will harm people - unreadable coredumps are not
worse than no coredump and it won't make any difference in space usage if
you get a 1.99GB or a 2.5GB coredump. So just enable it unconditionally.
If it should be really a problem for 32bit the rlimit defaults in
resource.h could be changed.
For file systems that don't support O_LARGEFILE you should just get an
truncated coredumps for big address spaces.
Andrew Morton [Wed, 18 Feb 2004 12:49:43 +0000 (04:49 -0800)]
[PATCH] devfs: race fixes and cleanup
From: Andrey Borzenkov <arvidjaar@mail.ru>
- use struct nameidata in devfs_d_revalidate_wait to detect when it is
called without i_sem hold; take i_sem on parent in this case. This
prevents both deadlock with devfs_lookup by allowing it to drop i_sem
consistently and oops in d_instantiate by ensuring that it always runs
protected
- remove dead code that deals with major number allocation. The only
remaining user was devfs itself and patch changes it to
- use register_chardev to get device number for internal /dev/.devfsd and
/dev/.statd.
- remove dead auto allocation flag as well
- remove code that does module get on dev open - it is handled by fops_get.
Use init_special_inode consistently
- get rid of struct cdev_type and bdev_type - both have just single dev_t
now
Andrew Morton [Wed, 18 Feb 2004 12:49:34 +0000 (04:49 -0800)]
[PATCH] snprintf fixes
From: Juergen Quade <quade@hsnr.de>
Lots of places in the kernel are using [v]snprintf wrongly: they assume it
returns the number of characters copied. It doesn't. It returns the
number of characters which _would_ have been copied had the buffer not been
filled up.
So create new functions vscnprintf() and scnprintf() which have the
expected (sane) semaptics, and migrate callers over to using them.
Andrew Morton [Wed, 18 Feb 2004 12:49:05 +0000 (04:49 -0800)]
[PATCH] NGROUPS 2.6.2rc2 + fixups
From: Tim Hockin <thockin@sun.com>,
Neil Brown <neilb@cse.unsw.edu.au>,
me
New groups infrastructure. task->groups and task->ngroups are replaced by
task->group_info. Group)info is a refcounted, dynamic struct with an array
of pages. This allows for large numbers of groups. The current limit of
32 groups has been raised to 64k groups. It can be raised more by changing
the NGROUPS_MAX constant in limits.h
Someone complained about the number of references to /etc/modules.conf in
the documentation. While fixing them up (and examples where changed),
removed those which are redundant due to MODULE_ALIAS.
The issue of exceedingly large hash tables has been discussed on the
mailing list a while back, but seems to slip through the cracks.
What we found is it's not a problem for x86 (and most other
architectures) because __get_free_pages won't be able to get anything
beyond order MAX_ORDER-1 (10) which means at most those hash tables are
4MB each (assume 4K page size). However, on ia64, in order to support
larger hugeTLB page size, the MAX_ORDER is bumped up to 18, which now
means a 2GB upper limits enforced by the page allocator (assume 16K page
size). PPC64 is another example that bumps up MAX_ORDER.
Last time I checked, the tcp ehash table is taking a whooping (insane!)
2GB on one of our large machine. dentry and inode hash tables also take
considerable amount of memory.
Setting the size of these tables is difficult: they need to be constrained on
many-zone ia64 machines, but this could cause significant performance
problems when there are (for example) 100 million dentries in cache.
Large-memory machines which do not slice that memory up into huge numbers of
zones do not need to run the risk of this slowdown.
So the sizing algorithms remain essentially unchanged, and boot-time options
are provided which permit the tables to be scaled down.
Andrew Morton [Wed, 18 Feb 2004 12:47:47 +0000 (04:47 -0800)]
[PATCH] Use CPU_UP_PREPARE properly
From: Rusty Russell <rusty@rustcorp.com.au>
The cpu hotplug code actually provides two notifiers: CPU_UP_PREPARE
which preceeds the online and can fail, and CPU_ONLINE which can't.
Current usage is only done at boot, so this distinction doesn't
matter, but it's a bad example to set. This also means that the
migration threads do not have to be higher priority than the
others, since they are ready to go before any CPU_ONLINE callbacks
are done.
This patch is experimental but fairly straight foward: I haven't been
able to test it since extracting it from the hotplug cpu code, so it's
possible I screwed something up.
Andrew Morton [Wed, 18 Feb 2004 12:47:38 +0000 (04:47 -0800)]
[PATCH] Remove More Unneccessary CPU Notifiers
From: Rusty Russell <rusty@rustcorp.com.au>
Three more removed CPU notifiers extracted from the hotplug CPU patch.
kernel/softirq.c: the tasklet cpu prepration callback is useless:
the vectors are already initialized to NULL. Even with the hotplug
CPU patches, they're of little or no use.
fs/buffer.c: once again, they are already initialized to zero.
mm/page_alloc.c: once again, already initialized to zero.
Andrew Morton [Wed, 18 Feb 2004 12:47:29 +0000 (04:47 -0800)]
[PATCH] Minor workqueue.c cleanup
From: Rusty Russell <rusty@rustcorp.com.au>
Move duplicated code to __queue_work(), and don't set the CPU for
queue_delayed_work() until the timer goes off. The second one only has an
effect on CONFIG_HOTPLUG_CPU where the CPU goes down and the timer goes off
on a different CPU than it was scheduled on.
Andrew Morton [Wed, 18 Feb 2004 12:47:20 +0000 (04:47 -0800)]
[PATCH] Remove kstat cpu notifiers
From: Rusty Russell <rusty@rustcorp.com.au>
Some well-meaning person put a notifier in for CPUs to update the kstat
structures in sched.c. However, it does nothing, and even with the full
hotplug CPU patch, it still does nothing.
Simple counters very rarely need anything done when CPUs come up or go
down. If you have per-cpu caches, or per-cpu threads, you need to do
something. But very rarely for stats.
Andrew Morton [Wed, 18 Feb 2004 12:47:11 +0000 (04:47 -0800)]
[PATCH] kthread primitive
From: Rusty Russell <rusty@rustcorp.com.au>
These two patches provide the framework for stopping kernel threads to
allow hotplug CPU. This one just adds kthread.c and kthread.h, next
one uses it.
Most importantly, adds a Monty Python quote to the kernel.
Details:
The hotplug CPU code introduces two major problems:
1) Threads which previously never stopped (migration thread,
ksoftirqd, keventd) have to be stopped cleanly as CPUs go offline.
2) Threads which previously never had to be created now have
to be created when a CPU goes online.
Unfortunately, stopping a thread is fairly baroque, involving memory
barriers, a completion and spinning until the task is actually dead
(for example, complete_and_exit() must be used if inside a module).
There are also three problems in starting a thread:
1) Doing it from a random process context risks environment contamination:
better to do it from keventd to guarantee a clean environment, a-la
call_usermodehelper.
2) Getting the task struct without races is a hard: see kernel/sched.c
migration_call(), kernel/workqueue.c create_workqueue_thread().
3) There are races in starting a thread for a CPU which is not yet
online: migration thread does a complex dance at the moment for
a similar reason (there may be no migration thread to migrate us).
Place all this logic in some primitives to make life easier:
kthread_create() and kthread_stop(). These primitives require no
extra data-structures in the caller: they operate on normal "struct
task_struct"s.
Other changes:
- Expose keventd_up(), as keventd and migration threads will use kthread to
launch, and kthread normally uses workqueues and must recognize this case.
- Kthreads created at boot before "keventd" are spawned directly. However,
this means that they don't have all signals blocked, and hence can be
killed. The simplest solution is to always explicitly block all signals in
the kthread.
- Change over the migration threads, the workqueue threads and the
ksoftirqd threads to use kthread.
- module.c currently spawns threads directly to stop the machine, so a
module can be atomically tested for removal.
- Unfortunately, this means that the current task is manipulated (which
races with set_cpus_allowed, for example), and it can't set its priority
artificially high. Using a kernel thread can solve this cleanly, and with
kthread_run, it's simple.
- kthreads use keventd, so they inherit its cpus_allowed mask. Unset it.
All current users set it explicity anyway, but it's nice to fix.
- call_usermode_helper uses keventd, so the process created inherits its
cpus_allowed mask. Unset it.
- Prevent errors in boot when cpus_possible() contains a cpu which is not
online (ie. a cpu didn't come up). This doesn't happen on x86, since a
boot failure makes that CPU no longer possible (hacky, but it works).
- When the cpu fails to come up, some callbacks do kthread_stop(), which
doesn't work without keventd (which hasn't started yet). Call it directly,
and take care that it restores signal state (note: do_sigaction does a
flush on blocked signals, so we don't need to repeat it).
Andrew Morton [Wed, 18 Feb 2004 12:47:01 +0000 (04:47 -0800)]
[PATCH] ACPI PM timer
From: Dominik Brodowski <linux@dominikbrodowski.de>,
John Stultz <johnstul@us.ibm.com>,
Dmitry Torokhov
Add the ACPI Powermanagement Timer as x86 kernel timing source. Unlike the
Time Stamp Counter, it is a reliable timing source which does not get
affected by aggressive powermanagement features like CPU frequency scaling.
Some ideas and some code are based on Arjan van de Ven's implementation for
2.4, and on R. Byron Moore's drivers/acpi/hardware/hwtimer.c.
We also replace the loop based delay_pmtmr with a TSC based delay_pmtmr,
which resolves a number of issues caused by the loop based delay. Unsynced
TSCs as well frequency changing TSCs will effect the length of __delay(), but
it seems this method works best.
Andrew Morton [Wed, 18 Feb 2004 12:46:43 +0000 (04:46 -0800)]
[PATCH] loop.c doesn't fail init gracefully
From: BlaisorBlade <blaisorblade_spam@yahoo.it>
loop_init doesn't fail gracefully for two reasons:
1) If initialization of loop driver fails, we have an call to
devfs_add("loop") without any devfs_remove; I add that.
2) On lwn.net 2.6 kernel docs, Jonathan Corbet says: "If you are calling
add_disk() in your driver initialization routine, you should not fail
the initialization process after the first call."
So I make loop.c conform to this request by moving add_disk after all
memory allocations.
Andrew Morton [Wed, 18 Feb 2004 12:46:25 +0000 (04:46 -0800)]
[PATCH] remove useless highmem bounce from loop/cryptoloop
From: Ben Slusky <sluskyb@paranoiacs.org>
The attached patch changes the loop device transfer functions (including
cryptoloop transfers) to accept page/offset pairs instead of virtual
addresses, and removes the redundant kmaps in do_lo_send, do_lo_receive,
and loop_transfer_bio. Per Andrew Morton's request a while back.
Andrew Morton [Wed, 18 Feb 2004 12:46:08 +0000 (04:46 -0800)]
[PATCH] ppc64: iseries IRQ fix
From: Stephen Rothwell <sfr@canb.auug.org.au>
This patch lets 2.6.3-rc4 build and boot on an PPC64 iSeries box (at least
for my configuration). The veth.o bit in the networking Makefile got there
by accident and should be removed anyway ...
There is more to make it work properly (note the "Temporary hack"), but
this gets us closer.