- 08 Mar, 2005 40 commits
-
-
Randy Dunlap authored
oss/es1370: fix initdata section reference: Error: ./sound/oss/es1370.o .text refers to 00000000000042bd R_X86_64_32S .init.data+0x0000000000000024 Error: ./sound/oss/es1370.o .text refers to 00000000000042c5 R_X86_64_32S .init.data+0x0000000000000020 Signed-off-by:
Randy Dunlap <rddunlap@osdl.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Randy Dunlap authored
oss/cmpci: fix initdata section reference: Error: ./sound/oss/cmpci.o .text refers to 000000000000418e R_X86_64_32S .init.data+0x0000000000000004 Error: ./sound/oss/cmpci.o .text refers to 0000000000004196 R_X86_64_32S .init.data Signed-off-by:
-
Randy Dunlap authored
oss/cs4281: fix initdata section references: Error: ./sound/oss/cs4281/cs4281.o .text refers to 0000000000006dae R_X86_64_32S .init.data+0x0000000000000004 Error: ./sound/oss/cs4281/cs4281.o .text refers to 0000000000006db6 R_X86_64_32S .init.data Error: ./sound/oss/cs4281/cs4281m.o .text refers to 0000000000006dae R_X86_64_32S .init.data+0x0000000000000004 Error: ./sound/oss/cs4281/cs4281m.o .text refers to 0000000000006db6 R_X86_64_32S .init.data Signed-off-by:
-
Randy Dunlap authored
atm/zatm: fix text section references to __init text and __initdata; they should be __devinit instead of __init; Error: ./drivers/atm/zatm.o .text refers to 0000000000001abb R_X86_64_PC32 .init.text+0x0000000000000154 Error: ./drivers/atm/zatm.o .text refers to 0000000000001ad3 R_X86_64_PC32 .init.text+0x0000000000000154 Signed-off-by:
-
Randy Dunlap authored
atm/ambassador: fix text section references to __init text and __initdata; The biggest negative about this AFAIK is that it makes ucode_data non-initdata, and that moves about 8 KB of data from .init.data to .data. Similarly, .text increases by approx. 1300 bytes (on x86-32). Error: ./drivers/atm/ambassador.o .text refers to 0000000000002a07 R_X86_64_PC32 .init.text+0x0000000000000149 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002a45 R_X86_64_32S .init.data+0x0000000000000040 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002a7c R_X86_64_PC32 .init.data+0x0000000000000020 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002a83 R_X86_64_PC32 .init.data+0x000000000000001c Error: ./drivers/atm/ambassador.o .text refers to 0000000000002b40 R_X86_64_PC32 .init.text+0x0000000000000149 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002bbc R_X86_64_PC32 .init.text+0x0000000000000149 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002c0f R_X86_64_32S .init.data+0x0000000000000024 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002c17 R_X86_64_32S .init.data+0x0000000000000020 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002c3c R_X86_64_PC32 .init.data+0xfffffffffffffffc Error: ./drivers/atm/ambassador.o .text refers to 0000000000002c6a R_X86_64_PC32 .init.text+0x0000000000000149 Error: ./drivers/atm/ambassador.o .text refers to 0000000000002c77 R_X86_64_32S .init.data+0x0000000000000040 Signed-off-by:
-
Randy Dunlap authored
atm/lanai: fix text section references to __init text; they should be __devinit instead of __init; Error: ./drivers/atm/lanai.o .text refers to 0000000000002105 R_X86_64_PC32 .init.text+0x0000000000000021 Error: ./drivers/atm/lanai.o .text refers to 0000000000002116 R_X86_64_PC32 .init.text+0x0000000000000021 Error: ./drivers/atm/lanai.o .text refers to 0000000000002132 R_X86_64_PC32 .init.text+0x0000000000000021 Signed-off-by:
-
Paul Fulghum authored
Fix register access typo in synclinkmp.c that caused value to be written to wrong register. Signed-off-by:
-
Panagiotis Issaris authored
The EFI driver allocates memory and writes into it without checking the success of the allocation. Furthermore, on failure of the firmware_register() it doesn't free the allocated memory and on failure of the subsys_create_file() calls it returns zero instead of the errorcode. Signed-off-by:
Panagiotis Issaris <panagiotis.issaris@mech.kuleuven.ac.be> Signed-off-by:
-
Jeff Moyer authored
There is a memory in the autofs4_wait function, if multiple processes are waiting on the same queue: name = kmalloc(NAME_MAX + 1, GFP_KERNEL); if (!name) return -ENOMEM; ... if ( !wq ) { /* Create a new wait queue */ wq = kmalloc(sizeof(struct autofs_wait_queue), GFP_KERNEL); if ( !wq ) { kfree(name); up(&sbi->wq_sem); return -ENOMEM; } ... wq->name = name; ... } else { atomic_inc(&wq->wait_ctr); up(&sbi->wq_sem); ... } In the else clause, we forget to free the name we kmalloc'd above. This is pretty easy to trigger with the following reproducer: setup an automount map as follows: for n in `seq 1 48`; do echo "$n server:/export/$n" >> /etc/auto.test; done setup a master map entry to point at this: echo "/test /etc/auto.test --timeout=1" >> /etc/auto.master Now, assuming the nfs server was setup to export said directories, run the following shell script in two xterms: #!/bin/sh while true; do for n in `seq 1 48`; do ls /test/$n done sleep 2 done and watch the size-256 slab cache grow Within 4 minutes, I had the size-256 cache grow to 384k. On a kernel with the below patch applied, the size-256 remained constant during an over-night run. Signed-off-by:Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
-
Jan Kara authored
Attached patch from Nathan splits the checks done in quotactl() in XFS and VFS parts (it's mostly just moving of code back and forth). It's done mainly because XFS guys would like to implement more types of quotas and I don't want them to slow down the general VFS case. Signed-off-by:
Nathan Scott <nathans@sgi.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Corey Minyard authored
This patch cleans up the DMI handling so that multiple interfaces can be reported from the DMI tables and so that the DMI slave address can be transferred up to the upper layer. It also adds an option to specify the slave address as an init parm and removes some unnecessary initializers. This patch also adds inc/dec usecount functions for the SMIs so they can modify the usecounts of modules they use (added because the SMB driver uses the I2C code). Signed-off-by:
Corey Minyard <minyard@acm.org> Signed-off-by:
-
Nathan T. Lynch authored
With hotplug cpu and preempt, we tend to see smp_processor_id warnings from idle loop code because it's always checking whether its cpu has gone offline. Replacing every use of smp_processor_id with _smp_processor_id in all idle loop code is one solution; another way is explicitly binding idle threads to their cpus (the smp_processor_id warning does not fire if the caller is bound only to the calling cpu). This has the (admittedly slight) advantage of letting us know if an idle thread ever runs on the wrong cpu. Signed-off-by:
Nathan Lynch <ntl@pobox.com> Acked-by:
Joel Schopp <jschopp@austin.ibm.com> Signed-off-by:
-
Andries E. Brouwer authored
A well-known kernel bug is that it guesses at the partition type and the partitions on any disk it encounters. This is bad because needless I/O is done, slowing down the boot, sometimes quite a lot, especially when I/O errors occur. And it is bad because sometimes we guess wrong. In other words, we need the user space command `partition', where "partition -t dos /dev/sda" reads a DOS-type partition table. (And "partition /dev/sda" tries all known heuristics to decide what type of partitioning might be present.) The two variants are: (i) partition tells the kernel to do the partition table reading, and (ii) partition uses partx to read the partition table and tells the kernel one-by-one about the partitions found this way. Since this is a fundamental change, a long transition period is needed, and that period could start with a kernel boot parameter telling the kernel not to do partition table parsing on a particular disk, or a particular type of disks, or all disks. This could have been the intro to a patch doing that, but is not. (It is just an RFC.) The tiny patch below prompted the above - it was suggested by Uwe Bonnes who encountered USB devices without partition table where our present heuristics did not suffice to stop partition table parsing. It causes the kernel to ignore partitions of type 0. A band-aid. I think nobody uses such partitions seriously, but nevertheless this should probably live in -mm for a while to see if anybody complains. Signed-off-by:
-
Alexey Dobriyan authored
For when the layout of `struct resource' changes. Signed-off-by:
Alexey Dobriyan <adobriyan@mail.ru> Acked-by:
William Irwin <wli@holomorphy.com> Signed-off-by:
-
Peter Samuelson authored
AIX curses.h defines macros 'clear_screen' and 'color_names' but does not define 'scroll()'. Signed-Off-By:
Peter Samuelson <peter@p12n.org> Signed-off-by:
-
matthias.kunze@gmx-topmail.de authored
Add a boot-time option to set the loglevel. We already have `quiet' and `debug', which set it to specific levels. This is better. Signed-off-by:
-
Alexander Nyberg authored
There's a missing failure handling check here that would possibly lead to a null dereference later on, I'm not sure about the correct return value however. I haven't tried it as I'm not sure how to trigger the case ;) Found by the Coverity tool. Signed-off-by:
Alexander Nyberg <alexn@dsv.su.se> Signed-off-by:
-
David Howells authored
The attached patch updates the documentation on the kernel keys to describe the locking associated with keys and key type operations. Signed-Off-By:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Vladimir Saveliev authored
This patch makes reiserfs to return -EIO when rename-ing went wrong instead of calling BUG(). Signed-off-by:
-
a.llano@usyscom.com authored
I've been testing the 1-Wire Dallas in a bigendian machine (through a GPIO) and I've found some problems that can easily addressed with the provided patch. (inline at the end of the message). I have a question about the implementation of w1_smem. In the line 90 of drivers/w1/w1_smem.c. for (i = 0; i < 9; ++i) count += sprintf(buf + count, "%02x ", ((u8 *)&sl->reg_num)[i]); I don't see why this loop is execute 9 times when the provided reg_num is 8 bytes long. I don't understand the purpose of the last byte. Signed-off-by: -
Badari Pulavarty authored
Add nobh_wripage() support for the filesystems which uses nobh_prepare_write/nobh_commit_write(). Idea here is to reduce unnecessary bufferhead creation/attachment to the page through pageout()->block_write_full_page(). nobh_wripage() tries to operate by directly creating bios, but it falls back to __block_write_full_page() if it can't make progress. Note that this is not really generic routine and can't be used for filesystems which uses page->Private for anything other than buffer heads. Signed-off-by:
Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by:
-
Badari Pulavarty authored
Export kallsyms_lookup_name() for kprobe/jprobe module use. (akpm: modules which use kprobes/jrobes are usually problem-specific and will not be merged into the mainline kernel, so we we're actually to see actual users of this patch merged) Signed-off-by:
-
smurf@smurf.noris.de authored
The "bksend" example script doesn't work if PAGER (used by "bk changes") is set to something which doesn't fallback to plain stdout if its output isn't a tty. Fixed by forcing PAGER to be /bin/cat. Signed-Off-By:
Matthias Urlichs <smurf@debian.org> Acked-by:
Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
smurf@smurf.noris.de authored
CREDITS update for Mattihas Urlichs. Signed-Off-By:
-
rene.scharfe@lsrfire.ath.cx authored
This patch removes the mount options of the proc filesystem. They don't have any effect since 2.4.something. Only proc_fill_super() calls parse_options, notably proc_remount() does not. And proc_fill_super() is only called at the very first mount which in turn is the one caused by kern_mount() in fs/proc/root.c and that passes a NULL pointer as mount options string. It is called only once because proc is a filesystem with a single super_block (i.e. it uses get_sb_single()). Since noone seems to miss the uid and gid options so far I suggest to simply remove them. Their function can be easily performed in userspace. E.g. this (if it worked like intended): # mount -t proc -o uid=procuser,gid=procgrp proc /proc can be done like so, probably in some init script: # mount -t proc proc /proc && chown procuser:procgrp /proc But I don't see why anyone would want to do that in the first place. Signed-off-by: -
Gerd Knorr authored
Did some code reorganization: split up the source into four files: - tuner-core.c for all the interfacing stuff (register driver, handle insmod options, react on v4l ioctls, ...), - tuner-simple.c for all those trivial 4-byte-command-sequence tuner chips. - mt20xx.c for the mt2032 and mt2050 tuners. - tda8290.c for the tda8290/8272 combo (this code is new). I also did a number of cleanups like using dev_printk() for the messages everythere. There should be no functional changes beside the new support for the tda8290 tuner. Signed-off-by:
Gerd Knorr <kraxel@bytesex.org> Signed-off-by:
-
Gerd Knorr authored
Just a new PCI Subsystem ID and a PM fix from Pavel. Signed-off-by:
-
Andrea Arcangeli authored
I'd need it merged into mainline at some point, unless anybody has strong arguments against it. All I can guarantee here, is that I'll back it out myself in the future, iff Cpushare will fail and nobody else started using it in the meantime for similar security purposes. (akpm: project details are at http://www.cpushare.com/technical. It seems like a good idea to me, and one which is worth supporting. I agree that for this to be successful, the added robustness of Andrea's simple and specific jail is worthwhile). Signed-off-by:
Andrea Arcangeli <andrea@cpushare.com> Signed-off-by:
-
Tim Bird authored
Here's a little patch which is useful for showing timing information for kernel bootup activities. This patch adds a new Kconfig option under "Kernel Hacking" and a new option for the kernel command line. It also provides a script for showing delta information. Note that the timing data may not be correct on some platforms until after time_init() is called. Recently (as of about 2.6.10) I found that the message log produced by dmesg is truncated when I use this feature. That is, the first few printk messages of the boot sequence are not in the dmesg output, although they are printed to console during startup. This is a new behavior - dmesg output was fine as of 2.6.9. Increasing CONFIG_LOG_BUF_SHIFT had no effect on the truncation. Has something changed with printk recently? For more information on this patch, see: http://tree.celinuxforum.org/CelfPubWiki/InstrumentedPrintk Here's some sample output: ... [4294667.296000] Kernel command line: ro root=/dev/nfs ip=dhcp hdc=ide-scsi console=vga console=ttyS0,115200 [4294667.296000] ide_setup: hdc=ide-scsi [4294667.296000] Initializing CPU#0 [4294667.296000] PID hash table entries: 512 (order: 9, 8192 bytes) [ 0.000000] Detected 1995.620 MHz processor. [ 21.397369] Using tsc for high-res timesource [ 21.399820] Console: colour VGA+ 80x25 [ 21.537244] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 21.544547] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 21.555066] Memory: 125076k/130240k available (2002k kernel code, 4556k reserved, 1006k data, 140k init, 0k highmem) [ 21.565775] Checking if this processor honours the WP bit even in supervisor mode... Ok. [ 21.574089] Calibrating delay loop... 3940.35 BogoMIPS (lpj=1970176) [ 21.596511] Mount-cache hash table entries: 512 (order: 0, 4096 bytes) [ 21.603263] CPU: After generic identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000 [ 21.603276] CPU: After vendor identify, caps: bfebfbff 00000000 00000000 00000000 00004400 00000000 00000000 [ 21.603287] CPU: Trace cache: 12K uops, L1 D cache: 8K [ 21.608884] CPU: L2 cache: 128K ... And now the patch... Signed-off-by:
Tim Bird <tim.bird@am.sony.com> Signed-off-by:
-
Anton Altaparmakov authored
Implements fallback to file_operations->write in the case that aops->{prepare,commit}_write are not present on the backing filesystem. The fallback happens in two different ways: - For normal loop devices, i.e. ones which do not do transformation on the data but simply pass it along, we simply call fops->write. This should be pretty much just as fast as using aops->{prepare,commit}_write directly. - For all other loop devices (e.g. xor and cryptoloop), i.e. all the ones which may be doing transformations on the data, we allocate and map a page (once for each bio), then for each bio vec we copy the bio vec page data to our mapped page, apply the loop transformation, and use fops->write to write out the transformed data from our page. Once all bio vecs from the bio are done, we unmap and free the page. This approach is the absolute minimum of overhead I could come up with and for performance hungry people, as you can see I left the address space operations method in place for filesystems which implement aops->{prepare,commit}_write. I have tested this patch with normal loop devices using aops->{prepare,commit}_write on the backing filesystem, with normal loop devices using the fops->write code path and with cryptoloop devices using the double buffering + fops->write code path. Signed-off-by:Anton Altaparmakov <aia21@cantab.net> Signed-off-by:
-
Zwane Mwaikambo authored
We take down ksoftirqds at CPU_DEAD time, so there is a brief period whereupon there is a ksoftirqd thread for an offline processor, it is at this point that ->cpus_allowed won't have it pinned anymore. An online processor would then take down that ksoftirqd and exit it. Ensure that we only offline the processor when it's safe and never run softirqs in another processor's ksoftirqd context. This also gets rid of the warnings in ksoftirqd on cpu offline. Signed-off-by:
Zwane Mwaikambo <zwane@arm.linux.org.uk> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Jan Kara authored
Attached patch adds functions ufs_quota_read() and ufs_quota_write() to the UFS code. So quotas for UFS should work again (they were broken by the quota io redesign). I don't actually think the patch is too much important as I'm not sure anybody uses quotas on UFS but we're in the "stable" branch so just dropping a support did not seem right to me. Signed-off-by:
-
Dave Olien authored
I've had this patch reviewed by Jens, and incorporated his recommended fixes. The patch adds new interfaces to bio.c that support the creation of local bio and bvec pools. This is important for layered drivers that need to allocate new bio and bvec structures in response to bio's submitted to it from higher up. The layered drivers can allocate local pools of bio structures to preclude deadlock under global bio pool exhaustion. The device mapper source files have been modified to remove duplicate bio code, and to use the new interfaces to create local bio pools. From: Dave Olien <dmo@osdl.org> Change bio_clone() to use the global bio_set pool instead of the bio_set pool associated with the bio argument. This is because raid5 and raid6 bio's are not allocated from a bio_set and have no bio_set associated with them. This patch along with the patch Linux just accepted allows raid5 and raid6 to function. Signed-off-by:
-
Ingo Molnar authored
This patch does the final consolidation of asm-*/resource.h file, without changing any of the rlimit definitions on any architecture. Primarily it removes the __ARCH_RLIMIT_ORDER method and replaces it with a more compact and isolated one that allows architectures to define only the offending rlimits. This method has the positive effect that adding a new rlimit can now be purely done via changing asm-generic/resource.h alone. Previously one would have to patch 4 other (sparc, sparc64, alpha and mips) resource.h files. The patch also does style unification, whitespace cleanups and simplification of resource.h files and cleans up the asm-generic/resource.h file as well. I've added more comments too. This patch should have no effect on any code on any architecture. (i.e. it's a pure identity patch.) Tested on x86 and carefully reviewed to make sure that Sparc, Sparc64, MIPS and Alpha rlimits are still the same as required by the ABI. Signed-off-by:
Chris Wright <chrisw@osdl.org> Signed-off-by:
-
ken@mvista.com authored
In lp_write(), copy_from_user() is called to copy data into a statically allocated kernel buffer before down_interruptible() is called. If a second thread of execution comes in between the copy_from_user() and the down_interruptible() calls, silent data corruption could result. Signed-off-by:
-
Stephen Hemminger authored
The /proc/driver/rtc interface didn't have any module owner hook. The simplest fix is to just convert this to the single version of seq_file. Also, fix initialization of rtc_dev to use C99 form. Signed-off-by:
Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
Adrian Bunk authored
With the release of gcc 4.0 being only a few months away and people already tring compiling with it, it's time for adding a compiler-gcc4.h . This patch contains the following changes: - remove compiler-gcc+.h - compiler-gcc4.h: new file based on a corrected compiler-gcc+.h - compiler.h: include compiler-gcc4.h for gcc 4 - compiler.h: #error for gcc > 4 - compiler-gcc3.h: remove __compiler_offsetof (there will never be a gcc 3.5) small indention corrections I've tested the compilation with both gcc 3.4.4 and a recent gcc 4.0 snapshot from Debian experimental. Signed-off-by:Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Ernie Petrides authored
While investigating the 2.4 memory corruption problem fixed by the patch previously posted, it was noticed that the 2.6 version of get_kcore_size() inappropriately uses sizeof(struct memelfnote) in its calculation of the /proc/kcore ELF header size. What is actually stored in the header is an "elf_note" structure plus the 4 ASCII chars "CORE". It just so happens that on 32-bit arches, both calculations result in the same value (16). But on 64-bit arches, the allocated size (24) is larger than necessary (16). This does not result in any possible data corruption, but it might be nice to correct this "conceptual" error. Signed-off-by:
-
Yoichi Yuasa authored
This patch updates serial driver for VR41xx serial unit. Some check are added to verify_port. Signed-off-by:
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by:
-
Arun Sharma authored
Move ioctl TCSBRKP support to compat layer. Same rationale as TCSBRK. - Remove corresponding code under ppc64, sparc64 and s390. - Use ULONG_IOCTL() instead of COMPATIBLE_IOCTL(), since the argument is int, not pointer. Signed-off-by:
Gordon Jin <gordon.jin@intel.com> Signed-off-by:
Arun Sharma <arun.sharma@intel.com> Signed-off-by:
-
