- 19 Aug, 2003 28 commits
-
-
Simon Evans authored
This updates the blkmtd driver with the latest which has been in the MTD CVS for quite a while. It is a rewrite from the 2.4 version to work with the new block layer changes.
-
Sam Ravnborg authored
When the *config targets were moved to scripts/kconfig/Makefile the graphical configurator support broke. The following patch is a minimal fix, required to restore support of 'make xconfig' and 'make gconfig'.
-
Arnd Bergmann authored
A small bug in local.h apparently got copied a few times. I noticed this because I copied the same bug to s390. This patch should fix the occurrences in BK, but there are others that are not merged yet, e.g. ppc64 in -mm3.
-
Adam Belay authored
This is a rewrite of the awe_wave detection code that will allow this driver to be compiled. It moves detection functions to a common location at the end of the file and makes the code driver-model compatible. Also it fixes a bug in which the driver could possibly write to incorrect ports when using isapnp cards. Unfortunantly I do not currently have an AWE32 to test these changes so I could only check for compilation and driver registration.
-
Andi Kleen authored
There was a quite nasty long standing bug in the x86-64 port. The interrupt gates had a DPL of 3, allowing user space to trigger any interrupt. I have not found a way to exploit it this to crash the kernel, but it definitely shouldn't happen. It could e.g. cause problems with drivers that do not handle shared interrupt properly. This also broke some programs who assumed that int <random number> causes a signal.
-
Andi Kleen authored
Various compile fixes for x86-64 in the current BKCVS tree. - Use new information from acpi_pci_link_get_irq: handle edge and level triggered interrupts properly - Fixes for pci_dev->pretty_name Only changes x86-64 specific code.
-
Linus Torvalds authored
Linux historically has had. Only x86-64 uses anything else, so make the special case be _there_.
-
Marc Zyngier authored
- Don't leave resource name uninitialized if CONFIG_EISA_NAME is not set. - Print root device bus_id (so we know which bridge is probed). - From Zwane Mwaikambo : Add a release method to virtual root, so it stays quiet if probing fails (because some pci-eisa bridge have been found before).
-
Neil Brown authored
From: Mark Hemment <markhe@veritas.com> For RPC over UDP, after receiving a packet kick another thread as soon as possible. This helps NFS performance.
-
Neil Brown authored
This is important on multi-homes hosts.
-
Neil Brown authored
Just make sure that once SK_DEAD is set, nothing is attempted on the socket.
-
Andrew Morton authored
From: Bernardo Innocenti <bernie@develer.com> sysctl.h needs compiler.h
-
Andrew Morton authored
Fix infinite loop in the device probe function.
-
Andrew Morton authored
From: Peter Osterlund <petero2@telia.com> It oopses on module unload in the kobject layer due to misordered destruction of things. And we need to initialise the unplug timer in blk_alloc_queue(), because we kill that timer in blk_alloc_queue()'s companion function, blk_cleanup_queue().
-
Andrew Morton authored
From: Philippe Elie <phil.el@wanadoo.fr> If drain_array_locked() is passed the `force' command, it must go in and empty the head array.
-
Andrew Morton authored
This driver has a global list of devices which has no locking.
-
Andrew Morton authored
If the driver fails partway through probing, the recovery code will call ac97_release_codec(NULL), which oopses.
-
Andrew Morton authored
From: Stephen Smalley <sds@epoch.ncsc.mil> This patch fixes a bug in the SELinux module by adding a check of the filesystem labeling behavior value obtained from the policy.
-
Andrew Morton authored
From: Stephen Smalley <sds@epoch.ncsc.mil> This patch fixes a bug in the SELinux access vector cache code, which was incorrectly using spin_lock_irq rather than spin_lock_irqsave for the avc_log_lock. As this code can be called from hardirq (e.g. from the file_send_sigiotask hook), we need irqsave/restore here.
-
Andrew Morton authored
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> ioctx_alloc() leaks an mm->mm_count ref on an error path.
-
Andrew Morton authored
From: Sean Estabrooks <seanlkml@rogers.com> - fix space at end of line in config files; - add error check on put_user(); (Daniele Bellucci <bellucda@tiscali.it>) - add missing Kconfig piece for ikconfig;
-
Andrew Morton authored
From: Oliver Xymoron <oxymoron@waste.org> Currently, a writepage() which detects that it is writing outside i_size (due to concurrent truncate) will abandon the write, returning -EIO. The return value will bogusly cause an error to be recorded in the address_space. So convert all those writepage() instances to return zero in this case.
-
Andrew Morton authored
From: Oliver Xymoron <oxymoron@waste.org> This patch just saves a few bytes in the inode by turning mapping->gfp_mask into an unsigned long mapping->flags. The mapping's gfp mask is placed in the 16 high bits of mapping->flags and two of the remaining 16 bits are used for tracking EIO and ENOSPC errors. This leaves 14 bits in the mapping for future use. They should be accessed with the atomic bitops.
-
Andrew Morton authored
From: Oliver Xymoron <oxymoron@waste.org> These patches add the infrastructure for reporting asynchronous write errors to block devices to userspace. Error which are detected due to pdflush or VM writeout are reported at the next fsync, fdatasync, or msync on the given file, and on close if the error occurs in time. We do this by propagating any errors into page->mapping->error when they are detected. In fsync(), msync(), fdatasync() and close() we return that error and zero it out. The Open Group say close() _may_ fail if an I/O error occurred while reading from or writing to the file system. Well, in this implementation close() can return -EIO or -ENOSPC. And in that case it will succeed, not fail - perhaps that is what they meant. There are three patches in this series and testing has only been performed with all three applied.
-
Andrew Morton authored
From: mikep@csd.uu.se There has been a number of problem reports about local APIC interacting badly with ACPI on P4s due to the P4 local APIC force-enable change in 2.5.74, This patch reverts the 2.5.74 patch, so if the BIOS disables the local APIC on a P4, we don't enable it by default any more. The rescue the situation for those P4 systems where the local APIC _can_ be enabled safely, I've added two kernel parameters that can be used to override broken BIOSen: - "nolapic" prevents the kernel from enabling or using the local APIC. This is stronger than listing a machine in the DMI scan blacklist, since it also works for machines that boot with the local APIC already enabled. - "lapic" tells the kernel to force-enable the P4 local APIC if the BIOS disabled it. I haven't changed the logic for P6/K7 family processors, so we still force-enable those unless "nolapic" was passed to the kernel. The patch also includes a cleanup: the dont_use_local_apic_timer flag variable is not set any more since 2.5.74, so it's removed.
-
Andrew Morton authored
From: Eric Valette <eric.valette@free.fr> The following patch integrated in 2.5.74, <http://lists.insecure.org/lists/linux-kernel/2003/Jun/5840.html> really enables the APIC even if BIOS disabled it. Unfortunately, enabling APIC really does not seem to work on this ASUS laptop and ACPI (which is mandatory) crash the kernel in ACPI code at boot time while "Executing all Devices _STA and_INIT methods" Unless someones find a bug in ACPI code related to APIC management, It is safer to add this machine in the DMI black list (along with DELL, IBM, ...). So, as suggested by the author of the problematic change, I added and entry in the DMI black list. But my guess is that most laptop will soon be present in this list....
-
Andrew Morton authored
From: Ernie Petrides <petrides@redhat.com> (I can't get anyone to review this, but I'm sure there's a bug in there, and Ernie's patch has been in -mm for some time). There is a long-standing locking hole in the kernel's handling of the signals related to stopping and resuming processes. When a process handles SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU, the "sighand" lock is held while the signal is dequeued and appropriate masks are updated. But the "sighand" lock is dropped in several cases before the task's state is changed to TASK_STOPPED (or before a group-stop is initiated). If a process running on another cpu posts a SIGCONT or SIGKILL just after the "victim" process releases the lock but before its state is set to TASK_STOPPED, the corresponding wakeup will be lost and the victim will remain stopped despite the successive SIGCONT or SIGKILL. In this case, a repeated posting of SIGCONT or SIGKILL will have no effect, since the original one is already pending (and so causes a repeated posting to be discarded). The occurrence of a SIGSTOP/SIGKILL race where the victim has blocked all other signals will result in an unkillable process. Although a fabricated test program can reproduce a SIGSTOP/SIGCONT race hang in less than a minute (on a 2-cpu Dell Precision 450), the scenario that has been most frequently encountered is a hang during reboot or shutdown. This occurs because /sbin/killall5 brackets the scanning of /proc/* and associated signal posting to (most) of the processes still running with kill(-1, SIGSTOP) and kill(-1, SIGCONT) calls to temporarily freeze every process except for "init". Occasionally, its parent (running the /etc/rc6.d/S01reboot shell script) gets stuck in TASK_STOPPED state with pending SIGCONT and SIGCLD signals, but with no other process left to wake it up. In order to fix the race condition, the locking in do_signal_stop() and get_signal_to_deliver() needed reworking to close the hole. Due to lock ordering issues between the "sighand" lock and tasklist_lock, there are two cases where the former lock needs to be released and then reacquired, thus allowing a tiny hole for a SIGCONT/SIGKILL to be posted. These two cases are resolved by rechecking for a pending SIGCONT/SIGKILL after the locks are (re)acquired in the proper order. Anyone wanting a copy of the test program may e-mail me off-list.
-
Andrew Morton authored
From: Andi Kleen <ak@suse.de> POSIX says si_band in siginfo_t must be long. glibc uses this, except for Alpha. This type must be correct on little endian machines, otherwise Konqueror does not get any events from dnotity for created/deleted files. Currenly asm-generic/siginfo.h uses int, which is wrong. This patch adds a new macro __ARCH_SI_BAND_T which is int for alpha and long for everybody else. This makes the type on x86-64 come out correctly
-
- 18 Aug, 2003 12 commits
-
-
bk://kernel.bkbits.net/jgarzik/net-drivers-2.6Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
Alan Cox authored
-
Jeff Garzik authored
-
Simon Kelley authored
1) Add another card to the PCMCIA card database. 2) Fix a bug in wireless extensions. 3) Remove extra code for compilation without the firmware loader 4) force-enable CRC32 and FW_LOADER in Kconfig.
-
Jeff Garzik authored
-
Adam Kropelin authored
-
Karol Kozimor authored
-
Matthew Natalier authored
It wants big endian vlan tags. IEEE, or just weird?
-
Javier Achirica authored
-
bk://kernel.bkbits.net/jgarzik/misc-2.6Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
Jeff Garzik authored
on NCAPINTS value found in include/asm-i386/cpufeature.h.
-
Rob Landley authored
-