- 26 Apr, 2004 40 commits
-
-
Andrew Morton authored
From: Marek Szuba <scriptkiddie@wp.pl> Use the configured default NLS rather than hardwire it.
-
Andrew Morton authored
From: Matt Mackall <mpm@selenic.com>
-
Andrew Morton authored
This function doesn't correctly accumulate -EIO for its caller.
-
Andrew Morton authored
-
Andrew Morton authored
From: Martin Schwidefsky <schwidefsky@de.ibm.com> This patch add a system control that allows to switch off the jiffies timer interrupts while a cpu sleeps in idle. This is useful for a system running with virtual cpus under z/VM.
-
Andrew Morton authored
From: Matt Domsch <Matt_Domsch@dell.com> I moved the home of the efibootmgr utility from domsch.com to linux.dell.com. Note the move in drivers/firmware/Kconfig, also note version 0.5.0-test3 or above is necessary.
-
Andrew Morton authored
From: Matt Domsch <Matt_Domsch@dell.com> Patch below fixes three small bugs in efivars.c as posted by Matt Tolentino last week and included in the latest -mm. Aside from this small patch, I'm quite pleased with Matt T's work, thanks! - dummy() used for reading write-only sysfs files should return -ENODEV to indicate failure, not 0. - efivar_create() should return the number of bytes written on success, not zero. - efivar_delete() should return the number of bytes written on success, not zero.
-
Andrew Morton authored
From: Matt Tolentino <metolent@snoqualmie.dp.intel.com> Third efivars driver update patch that removes x86 references to the /proc version of the driver.
-
Andrew Morton authored
From: Matt Tolentino <metolent@snoqualmie.dp.intel.com> Second efivars driver update patch that adds efivars into the drivers/firmware directory.
-
Andrew Morton authored
From: Matt Tolentino <metolent@snoqualmie.dp.intel.com> I broke up the efivars driver update patch I had sent out quite a while ago into several smaller patches. This includes several fixes and suggestions that were pointed out. The patches are broken down as follows: 1 - remove all traces of efivars from arch/ia64/ 2 - add new sysfs based efivars driver into drivers/firmware with accompanying Kconfig/Makefile changes to make it fully functional for ia64 again. 3 - cleans up x86 references to the /proc version of the efivars driver.
-
Andrew Morton authored
From: Geert Uytterhoeven <geert@linux-m68k.org> M68k bitops updates (from Roman Zippel): - Optimize find_{first,next}_zero_bit() - Add missing implementations of find_{first,next}_bit()
-
Andrew Morton authored
From: Geert Uytterhoeven <geert@linux-m68k.org> Amiga A2065 Ethernet: Add KERN_* prefixes to printk() messages
-
Andrew Morton authored
From: Maneesh Soni <maneesh@in.ibm.com> Clarify some things which were confusing poeple...
-
Andrew Morton authored
From: Manfred Spraul <manfred@colorfullife.com> Below is a patch that redefines the kmem_cache_alloc `align' argument: - align not zero: use the specified alignment. I think values smaller than sizeof(void*) will work, even on archs with strict alignment requirement (or at least: slab shouldn't crash. Obviously the user must handle the alignment properly). - align zero: * debug on: align to sizeof(void*) * debug off, SLAB_HWCACHE_ALIGN clear: align to sizeof(void*) * debug off, SLAB_HWCACHE_ALIGN set: align to the smaller of - cache_line_size() - the object size, rounded up to the next power of two. Slab never honored cache align for tiny objects: otherwise the 32-byte kmalloc objects would use 128 byte objects. There is one additional point: right now slab uses ints for the bufctls. Using short would save two bytes for each object. Initially I had used short, but davem objected. IIRC because some archs do not handle short efficiently. Should I allow arch overrides for the bufctls? On i386, saving two bytes might allow a few additional anon_vma objects in each page.
-
Andrew Morton authored
From: Paul Jackson <pj@sgi.com> The #include of linux/module.h in several arch/*/mm/hugetlbpage.c files for EXPORT_SYMBOL(hugetlb_total_pages) is now unneeded.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> Doesn't compile with CONFIG_BLK_DEV_INITRD=n. Be more careful with the conditionals. Spotted by Dave Boutcher...
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> This patch moves the initrd when "make_room" runs out of space, rather than stepping over it. The problem with stepping over it is that it gets copied with the kernel when this happens, which wastes space. Also ensures that the initrd isn't where the kernel wants to be moved to: if it is, it gets moved out the way.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> Clean up initrd handling. 1) Expose initrd_start and initrd_end to prom.c (replacing its local initrd_start and initrd_len). 2) Don't hand mem (aka klimit) through functions which don't need it. 3) Add more debugging under DEBUG_PROM in case we broke anything.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> 1) Define PROM_ERROR: checks for call_prom() < 0 are bogus (returns ulong) 2) All OF access functions should be marked __init. 3) prom_strtoul isn't used at all.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> Ben Herrenschmidt made this actually boot.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> copy_device_tree calls inspect_node() which recurses to copy the Open Firmware device tree. It just copied into memory above the kernel for about 8MB, which can overwrite the initrd, and/or get truncated on big machines. The real solution is to allocate memory properly for all the prom_init memory users. However, that's quite a change. This patch introduces a "make_room" macro which inspect_node uses to get memory. This does the same as before, except skips over the initrd if neccessary.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> finish_device_tree simply allocates nodes by incrementing klimit (ie. using memory on top of the kernel). Change it to figure out how much memory it needs, then use lmb_alloc to allocate that, then fill it in. This gets rid of the only manipulation of klimit after prom_init.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> Rather than pre-declaring static functions, order them so it's not neccessary. This makes the code easier to navigate and patch.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> Rather than pre-declaring static functions, order them so it's not neccessary. This makes the code easier to navigate and patch.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> Rather than pre-declaring static functions, order them so it's not neccessary. This makes the code easier to navigate and patch.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> Rather than pre-declaring static functions, order them so it's not neccessary. This makes the code easier to navigate and patch.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> Move all the functions that run normally (ie. with the kernel in the correct address) to the bottom of prom.c, and keep all the functions which use RELOC() to the top, above "prom_init()" which calls them. Also, make prom_initialize_dart_table and prom_initialize_tce_table static.
-
Andrew Morton authored
From: Jan Kara <jack@ucw.cz> It fixes a memory leak when turning journalled quotas off.
-
Andrew Morton authored
We're testing the nullness of `sb' potentially after rereferencing it (although the compiler will have reordered things to avoid such a bug). Just remove the test - the superblock pointer shouldn't be null in there.
-
Andrew Morton authored
From: Jan Kara <jack@ucw.cz> When there are lots of dirty dquots the vfs_quota_sync() is too slow (it has O(N^2) behaviour). Attached patch implements list of dirty dquots for each superblock and quota type. Using this lists sync is trivially linear. Attached patch is against 2.6.5 with journalled quota and previous patch for hash table size. (Jan had a test which went from 8 minutes to 0.8 seconds...)
-
Andrew Morton authored
From: Jan Kara <jack@ucw.cz> I found out that quota uses hash table with just 43 entries to hash dquot entries. I guess that we can afford using one page for that (quotactl(Q_GETQUOTA...), got faster like 3x for 4000 users). Attached patch implements that.
-
Andrew Morton authored
From: Jan Kara <jack@ucw.cz> I've attached a fix for a problem in ext3 journalled quota patch - the problem is that detecting whether dqput() sleeps was wrong and so we could possibly schedule when holding a spinlock.
-
Andrew Morton authored
From: Chris Wright <chrisw@osdl.org> Contributions from: Stephen Smalley <sds@epoch.ncsc.mil> Andy Lutomirski <luto@stanford.edu> During exec the LSM bprm_apply_creds() hooks may tranisition the program to a new security context (like setuid binaries). The security context of the new task is dependent on state such as if the task is being ptraced. ptrace_detach() doesn't take the task_lock() when clearing task->ptrace. So there is a race possible where a process starts off being ptraced, the malicious ptracer detaches and if any checks agains task->ptrace are done more than once, the results are indeterminate. This patch ensures task_lock() is held while bprm_apply_creds() hooks are called, keeping it safe against ptrace_attach() races. Additionally, tests against task->ptrace (and ->fs->count, ->files->count and ->sighand->count all of which signify potential unsafe resource sharing during a security context transition) are done only once the results are passed down to hooks, making it safe against ptrace_detach() races. Additionally: - s/must_must_not_trace_exec/unsafe_exec/ - move unsafe_exec() call above security_bprm_apply_creds() call rather than in call for readability. - fix dummy hook to honor the case where root is ptracing - couple minor formatting/spelling fixes
-
Andrew Morton authored
From: Chris Mason <mason@suse.com> block_write_full_page might see and lock clean metadata buffers, which leads to bogus vs-12339 messages. Change the message to ignore bh locked.
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> call_usermodehelper uses keventd to create a thread, guaranteeing a nice, clean kernel thread. Unfortunately, there is a case where call_usermodehelper is called with &bus->subsys.rwsem held (via bus_add_driver()), but keventd could be running bus_add_device(), which is blocked on the same lock. The result is deadlock, and it comes from using keventd for both. In this case, it can be fixed by using a completely independent thread for call_usermodehelper, or an independent workqueue. Workqueues have the infrastructure we need, so we use one. Move EXPORT_SYMBOL while we're there, too. akpm fixes: Make it compile with !CONFIG_KMOD
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> Workqueues are a great primitive for running things from user context from a completely clean environment. Unfortunately, they currently insist on creating one thread per CPU, which is overkill for many situations, so the more generic keventd workqueue is used for these. Recently deadlocks using keventd were demonstrated, showing that it is not suitable for all uses. 1) Clean up CPU iterators. Always a nice touch. 2) Add __create_workqueue() and create_singlethread_workqueue(), keeping source compatibility. 3) Put workqueues in workqueue list even if !CONFIG_HOTPLUG_CPU (means we need a lock to protect that list). Now we can tell if a wq is single-threaded using list_empty(&wq->list). 4) For single-threaded workqueues, override CPU in queue_work, delayed_work_timer_fn and flush_workqueue to be 0. flush_workqueue now does redundant passes for single-threaded workqueues, but the code remains simple. 5) Make create_workqueue_thread return the thread, so we can easily kthread_bind for multi-threaded workqueues. akpm fixes: - Fix up is_single_threaded() handling - single-threaded wq thread does not have "/0" appended.
-
David Brownell authored
Here's another fix it'd be good to merge ... No changes to the Linux code at all, but it'll makes the Windows configuration of a Linux device running the Ethernet/RNDIS gadget behave correctly on more versions of Windows. (It might prevent some Bluescreening too.)
-
http://lia64.bkbits.net/to-linus-2.5Linus Torvalds authored
into ppc970.osdl.org:/home/torvalds/v2.6/linux
-
Greg Edwards authored
There's an obsolete check in sn_init_pdas() left over from the 2.4 days that panics if the cpu PDA and cpu_data area span more than a page. With 2.6, we're not limited to a page, so remove the check entirely.
-
Alex Williamson authored
I just ran into a bug introduced by the most recent iosapic.c patch. The scenario is a builtin driver is up and running happily. A module loads for a devices that happens to share the same interrupt vector, in this case a network driver. The module calls pci_enable_device() as it should, which eventually lands in iosapic_enable_intr(). We then proceed to mask the interrupt and kill the device that's already running. As a bonus, request_interrupt() doesn't fix the problem because we only call the startup for the interrupt handler on the first action attached to the interrupt. I think the best way out of this is simply to detect when an action is already attached to a vector and leave it alone. This also prevents interrupts from moving to other cpus (on boxes w/o irq redirection) for no good reason.
-