- 29 Dec, 2003 40 commits
-
-
Andrew Morton authored
From: Rusty Russell <rusty@rustcorp.com.au> Steve Youngs, Stephen Hemminger Three more MODULE_ALIASes. Trivial, but useful if people want things to "just work" in 2.6.0.
-
Andrew Morton authored
From: Ingo Molnar <mingo@elte.hu> i've attached a minor fix for the 2.6.1 timeframe - we clearly meant __struct_cpy_bug(). Newest versions of gcc warn about this.
-
Andrew Morton authored
From: Manfred Spraul <manfred@colorfullife.com> slab_reclaim_pages is increased even if get_free_pages fails. The attached patch moves the update to the correct position.
-
Andrew Morton authored
From: Tim Schmielau <tim@physik3.uni-rostock.de>
-
Andrew Morton authored
From: Kurt Garloff <garloff@suse.de> The comment in front of vt_ioctl() reads /* * We handle the console-specific ioctl's here. We allow the * capability to modify any console, not just the fg_console.=20 */ Unfortunately, this does not apply to PIO_UNIMAPCLR, nor GIO_/PIO_UNIMAP. They always operate on the current foreground console, which is inconsistent at least. For most ioctls, the comment is applicable. It also causes problems, as setfont can't do the full job on the non-fg consoles. (OK, our setfont is slightly changed to even try it ... as you know.) The attached patch does fix this. I have a similar patch for 2.4, but it never got merged :-( because not many people seem to care and I submitted in the middle of the 2.4 series ... It has been in UnitedLinux/SUSE kernels for ages, though.
-
Andrew Morton authored
From: "Martin J. Bligh" <mbligh@aracnet.com>, Guillaume Morin <guillaume@morinfr.org> We need to clear the software dirty bit on the tail pages of a compound page when freeing it up. The tail pages can become dirtied by mmap'ing /dev/mem, and writing into any clustered page group (that a driver might have created or whatever). Plus it's better to run all these pages through the free_pages_check checks anyway.
-
Andrew Morton authored
From: Ingo Molnar <mingo@elte.hu> I'd also suggest the following patch below, to clarify the use of unsynchronized list_empty(). list_empty_careful() can only be safe in the very specific case of "one-shot" list entries which might be removed by another CPU. (but nothing else can happen to them and this is their only final state.) list_empty_careful() is otherwise completely unsynchronized on both the compiler and CPU level and is not 'SMP safe' in any way.
-
Andrew Morton authored
From: Geert Uytterhoeven <geert@linux-m68k.org> Mailing lists at vger.rutgers.edu are obsolete, use vger.kernel.org instead.
-
Andrew Morton authored
From: Joe Korty <joe.korty@ccur.com> The API for get_compat_timespec / put_compat_timespec is incorrect, it forces a caller with const args to (incorrectly) cast. The posix message queue patch is one such caller.
-
Andrew Morton authored
From: Gerd Knorr <kraxel@bytesex.org> Below is a ObviouslyCorrect[tm] patch which fixes the i2c bus timeout handling in the saa7146 driver.
-
Andrew Morton authored
The locking rules say that b_committed_data is covered by jbd_lock_bh_state(), so implement that during the start of commit, while throwing away unused shadow buffers. I don't expect that there is really a race here, but them's the rules.
-
Andrew Morton authored
From: Badari Pulavarty <pbadari@us.ibm.com> I found the problem with O_DIRECT memory leak. The problem is, when we are doing DIO read and crossed the end of file - we don't release referencess on all the pages we got from get_user_pages(). (since it is a success case). The fix is to call dio_cleanup() even for sucess cases.
-
Andrew Morton authored
From: Roland McGrath <roland@redhat.com> The following test program will crash every time if dynamically linked. I think this bites all 32-bit platforms, including 32-bit executables on 64-bit platforms that support them (and could in theory bite 64-bit platforms with bss sizes beyond the bounds of comprehension). volatile char hugebss[1080000000]; main() { printf("%p..%p\n", &hugebss[0], &hugebss[sizeof hugebss]); system("cat /proc/$PPID/maps"); hugebss[sizeof hugebss - 1] = 1; return 23; } The problem is that the kernel maps ld.so at 0x40000000 or some such place, before it maps the bss. Here the bss is so large that it overlaps and clobbers that mapping. I've changed it to map the bss before it loads the interpreter, so that part of the address space is reserved before ld.so's mapping (which doesn't really care where it goes) is done. This patch also adds error checking to the bss setup (and interpreter's bss setup). With the aforementioned change but no error checking, "ulimit -v 65536; ./hugebss" will crash in the store after the `system' call, because the kernel will have failed to allocate the bss and ignored the error, so the program runs without those pages being mapped at all. With this change it dies with a SIGKILL as for a failure to set up stack pages. It might be even better to try to detect the case earlier so that execve can return an error before it has wiped out the address space. But that seems like it would always be fragile and miss some corner cases, so I did not try to add such complexity.
-
Andrew Morton authored
From: Joe Korty <joe.korty@ccur.com> do_gettimeofday() is using tick_usec which is defined in terms of USER_HZ not HZ.
-
Andrew Morton authored
From: NeilBrown <neilb@cse.unsw.edu.au> stripe to be effective. This patch sets ra_pages appropriately.
-
Andrew Morton authored
From: NeilBrown <neilb@cse.unsw.edu.au> As no md personalities honour the merge_bvec_fn of underlying devices, we must make sure never to submit a bio larger than 1 page when a merge_bvec_fn is defined. raid5 already does this (it never submits bios larger than one page). With this patch, all other raid personalities limit their max_sectors when a merge_bvec_fn is present.
-
Andrew Morton authored
From: glee@gnupilgrims.org I think Adrian had forgotten to update the help text.
-
Andrew Morton authored
From: Jan Kara <jack@ucw.cz> here's patch which should fix deadlock with quotas+ext3 reported in 2.4 (the same problem existed in 2.6 but nobody found it).
-
Andrew Morton authored
From: Jan Kara <jack@ucw.cz> I'm sending you a fix of possible Oops in vfs_quota_sync(). Actually nobody has run into that I found it when I was looking through the code.
-
Andrew Morton authored
From: Geoffrey Lee <glee@gnupilgrims.org> This fixes what seems to be an obvious = vs == bug in the init301.c sis file.
-
Andrew Morton authored
From: William Lee Irwin III <wli@holomorphy.com> This field is 100% unused. This patch removes it.
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> 32bit siginfo would sometimes get passed incorrectly on x86-64. This change fixes the conversion function to be a bit dumber, but more correct.
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> Merge i386 fix. Don't panic in MP table parsing when the table is bad.
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> Merge signal race fixes from i386 to x86-64. Fix a bug in system call restart, noted by John Blackwood.
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> Merge the i386 fix for the page fault from Linus to x86-64 (I'm not actually sure what it fixes, but if it's good for 32bit it is likely good for 64bit too)
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> Make sure we never access anything in kernel mapping while doing the prefetch workaround checks on x86-64. Originally suggested by Jamie Lockier.
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> Another potential data corruption fix. The 32bit truncate64 on x86-64 did silently truncate offsets >32bit. That broke mysql for example. Fix that. From Chris Wilson
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> From Badari Pulavarty Without this sysrq-t shows the same backtrace for all processes on x86-64
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> A lot of people have run into this: the x86-64 cpuid driver didn't compile as module. Using a kludge suggested by Sam Ravnsborg.
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> Please consider applying this patch, I would consider it critical for x86-64. The 2.6.0 x86-64 IOMMU code unfortunately had a few problems, leading to non booting systems and in a few cases to data corruption. It fixes a two serious bugs in handling special kinds of scatter gather lists in pci_map_sg. AGP was completely broken with IOMMU because of a wrong #ifdef. Fix that. One TLB flush optimization I did a long time ago seems to break on some 3ware boards (who require IOMMU because they don't support 64bit addresses). The breakage lead to data corruption. This patch diables the optimization for now and fixes a potential SMP race in the flush code too. The TLB flush is done in a slower, but more reliable way now too. This patch fixes them. Please consider applying, because some of these problems hit quite many people. This also disables the IOMMU_DEBUG in the defconfig. A lot of people were using the IOMMU when they didn't need to, which multiplied the problems. IOMMU merge is disabled for now. This was an experimental optimization which helped with some block devices, but for production it seems to be better to disable it for now because there are some questionable corner cases when the IOMMU aperture fragments. The same is done for IOMMU SAC force, which was related to that. i386 has quite broken semantics for pci_alloc_consistent(). It uses the standard device DMA mask instead of the consistent mask. Make us bug-to-bug compatible here. This fixes problems with some sound drivers that don't support full 32bit addressing.
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> Add 32bit a.out support for x86-64. Not exactly an important bug fix, but maybe it will help someone. This should increase the current 98% compatibility to i386 to perhaps 98.1% @) I tested an old a.out SuSE 4.2 installation in chroot and it worked. It also ran some very old linux binaries from '92 found on ftp.funet.fi. The only program that didn't was the SuSE a.out GNU emacs, but I was too lazy to track that down. Core dumps are not supported.
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> It fixes the statfs64 emulation on x86-64. The problem is that x86-64 needs an __attribute__((aligned)) on the compat_statfs64 structure. The conclusion last time this was discussed was that the structure should be duplicated. Essentially it is the old shared structure copied to every user and x86-64 uses __attribute__((packed)).
-
Andrew Morton authored
From: Mark Haverkamp <markh@osdl.org> About three weeks ago markw at osdl posted a mail about a panic that he was seeing: http://marc.theaimsgroup.com/?l=linux-kernel&m=106737176716474&w=2 I believe what is happening, is that the dm __clone_and_map function is generating bio structures with the bi_idx field non-zero. When __blk_queue_bounce creates a new bio with bounce pages, it sets the bi_idx field to 0 rather than the bi_idx of the original. This causes trouble since bv_page pointers will be dereferenced later that are zero. The following uses the original bio structure's bi_idx in the new bio structure and in copy_to_high_bio_irq and bounce_end_io. This has cleared up the panic when using the volume. (acked by Joe Thornber)
-
Andrew Morton authored
From: Neil Brown <neilb@cse.unsw.edu.au> Change ext3 to run bd_claim() against external journal devices. It is significant only for those who have ext3 journals on a separate device, and gets exclusive access to that device.
-
Andrew Morton authored
From: Arnaldo Carvalho de Melo <acme@conectiva.com.br> pagemap.h, do not include thyself.
-
Andrew Morton authored
Remove pointless lock_kernel(), replace with the standard-but-still-odd i_sem-based lseek locking.
-
Andrew Morton authored
proc_kill_inodes() walks the s_files list, playing with ->f_dentry. But there is a window in which __fput() will leave a file on that list with a null f_dentry and f_vfsmnt. I'm not sure it was ever confirmed that this fixed the reported oops, but it seems much better to set those fields to null _after_ removing the filp from the list. (Actually, there's no need to null those pointers out at all. But whatever; it caught a bug).
-
Andrew Morton authored
From: William Lee Irwin III <wli@holomorphy.com> Our accounting of minor faults versus major faults is currently quite wrong. To fix it up we need to propagate the actual fault type back to the higher-level code. Repurpose the currently-unused third arg to ->nopage for this.
-
Andrew Morton authored
From: James Morris <jmorris@redhat.com> The patch below removes the CLONE_FILES flag from the kernel_thread() call which starts init. This is to prevent other kernel threads from sharing file descriptors opened by init (try 'lsof /dev/initctl' on a 2.6 system :-). The reason this patch is being proposed is so that usermode helper apps launched via kernel threads (e.g. modprobe, hotplug) do not then inherit any such file descriptors. This is not a problem in itself so far (other than being messy), but it is a problem for SELinux, which will otherwise need to grant access to /dev/initctl by modprobe and hotplug, a somewhat undesirable scenario. As far as I can tell, there is no reason why init needs to be spawned with CLONE_FILES. Please let me know if there are any objections to the change, which I would like to propose for 2.6.0+ as a cleanup.
-
Andrew Morton authored
From: Aniket Malatpure <aniket@sgi.com> Adds support for the IOC4 IDE part.
-