- 07 Dec, 2006 40 commits
-
-
Mariusz Kozlowski authored
In file included from drivers/char/ip2/ip2main.c:285: drivers/char/ip2/i2lib.c: In function `i2Output': drivers/char/ip2/i2lib.c:1019: warning: unused variable `rc' Signed-off-by:Mariusz Kozlowski <m.kozlowski@tuxland.pl> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Andrew Morton authored
Saves nearly 4kbytes on x86. Cc: Arnaldo Carvalho de Melo <acme@mandriva.com> Cc: <linux-ext4@vger.kernel.org> Signed-off-by:
-
Andrew Morton authored
Saves nearly 4kbytes on x86. Cc: Arnaldo Carvalho de Melo <acme@mandriva.com> Cc: <linux-ext4@vger.kernel.org> Signed-off-by:
-
Andrew Morton authored
As Mikulas points out, (1 << anything) won't be evaluating to zero. This code is long-dead. Cc: Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> Signed-off-by:
-
Derek Fults authored
This allows a hyphenated range of positive numbers in the string passed to command line helper function, get_options. Currently the command line option "isolcpus=" takes as its argument a list of cpus. Format: <cpu number>,...,<cpu number> Valid values of <cpu_number> include all cpus, 0 to "number of CPUs in system - 1". This can get extremely long when isolating the majority of cpus on a large system. The kernel isolcpus code would not need any changing to use this feature. To use it, the change would be in the command line format for 'isolcpus=' Format: <cpu number>,...,<cpu number> or <cpu number>-<cpu number> (must be a positive range in ascending order.) or a mixture <cpu number>,...,<cpu number>-<cpu number> Signed-off-by:
Derek Fults <dfults@sgi.com> Cc: "Randy.Dunlap" <rdunlap@xenotime.net> Signed-off-by:
-
Dave Jones authored
Print the other (hopefully) known good pointer when list_head debugging too, which may yield additional clues. Also fix for 80-columns to win akpm brownie points. Signed-off-by:
Dave Jones <davej@redhat.com> Signed-off-by:
-
Neil Horman authored
Clean up several code points in which the return code from misc_register is not handled properly. Several modules failed to deregister various hooks when misc_register fails, and this patch cleans them up. Also there are a few modules that legitimately don't care about the failure status of misc register. These drivers however unilaterally call misc_deregister on module unload. Since misc_register doesn't initialize the list_head in the init_routine if it fails, the deregister operation is at risk for oopsing when list_del is called. The initial solution was to manually init the list in the miscdev structure in each of those modules, but the consensus in this thread was to consolodate and do that universally inside misc_register. Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Kylene Jo Hall <kjhall@us.ibm.com> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: Olaf Hering <olh@suse.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Vasily Averin authored
d_count check after dget() is always true. Signed-off-by:
Vasily Averin <vvs@sw.ru> Signed-off-by:
-
Alexey Dobriyan authored
Fixing sbpcd.c baroque error printing in process. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Cc: Jens Axboe <axboe@suse.de> Signed-off-by:
-
Randy Dunlap authored
Fix hpfs printk warnings: fs/hpfs/dir.c:87: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'long unsigned int' fs/hpfs/dir.c:147: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'long int' fs/hpfs/dir.c:148: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'long int' fs/hpfs/dnode.c:537: warning: format '%08x' expects type 'unsigned int', but argument 5 has type 'long unsigned int' fs/hpfs/dnode.c:854: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'loff_t' fs/hpfs/ea.c:247: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'long unsigned int' fs/hpfs/inode.c:254: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'long unsigned int' fs/hpfs/map.c:129: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'ino_t' fs/hpfs/map.c:135: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'ino_t' fs/hpfs/map.c:140: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'ino_t' fs/hpfs/map.c:147: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'ino_t' fs/hpfs/map.c:154: warning: format '%08x' expects type 'unsigned int', but argument 3 has type 'ino_t' Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
Alexey Dobriyan authored
- switch to error message buffer in .bss - missing va_end() (htf it worked before?) - use vsnprintf() - rename variables to understandable "fmt", "args". - "const char *fmt", yes. - add __attribute__((format ... Still, put that coffee down before reading more. Signed-off-by:
-
Alexey Dobriyan authored
It would very lame to get buffer overflow via one of the following. Signed-off-by:
-
Paul B Schroeder authored
This is on our "Envoy" boxes which we have, according to the documentation, an "Exar ST16C554/554D Quad UART with 16-byte Fifo's". The box also has two other "on-board" serial ports and a modem chip. The two on-board serial UARTs were being detected along with the first two Exar UARTs. The last two Exar UARTs were not showing up and neither was the modem. This patch was the only way I could the kernel to see beyond the standard four serial ports and get all four of the Exar UARTs to show up. [akpm@osdl.org: build fix] Signed-off-by:
Paul B Schroeder <pschroeder@uplogix.com> Cc: Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Acked-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Peter Zijlstra authored
============================================= [ INFO: possible recursive locking detected ] 2.6.18-1.2699.fc6 #1 --------------------------------------------- swapper/0 is trying to acquire lock: (&list->lock#3){+...}, at: [<c05ad307>] skb_dequeue+0x12/0x43 but task is already holding lock: (&list->lock#3){+...}, at: [<df98cd79>] bcsp_dequeue+0x6a/0x11e [hci_uart] Two different list locks nest, annotate so. Signed-off-by:Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Marcel Holtmann <marcel@holtmann.org> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Alexey Dobriyan authored
One of the mistakes a module_param() user can make is to supply default value of module parameter as the last argument. module_param() accepts permissions instead. If default value is, say, 3 (-------wx), parameter becomes world-writeable. So far, the only remedy was to apply grep(1) and read drivers submitted to -mm. BTDT. With this patch applied, compiler will finally do some job. *) bounds checking on permissions *) world-writeable bit checking on permissions *) compile breakage if checks trigger First version of this check (only "& 2" part) directly caught 4 out of 7 places during my last grep. Subject: Neverending module_param() bugs [X] drivers/acpi/sbs.c:101:module_param(capacity_mode, int, CAPACITY_UNIT); [X] drivers/acpi/sbs.c:102:module_param(update_mode, int, UPDATE_MODE); [ ] drivers/acpi/sbs.c:103:module_param(update_info_mode, int, UPDATE_INFO_MODE); [ ] drivers/acpi/sbs.c:104:module_param(update_time, int, UPDATE_TIME); [ ] drivers/acpi/sbs.c:105:module_param(update_time2, int, UPDATE_TIME2); [X] drivers/char/watchdog/sbc8360.c:203:module_param(timeout, int, 27); [X] drivers/media/video/tuner-simple.c:13:module_param(offset, int, 0666); Signed-off-by: -
Oleg Nesterov authored
Thomas Graf wrote: > > nla_nest_start() may return NULL, either rely on prepare_reply() to be > correct and BUG() on failure or do proper error handling for all > functions. nla_put() in taskstat.c can fail only if the 'size' argument of alloc_skb() was not right. This is a kernel bug, we should not hide it. So add 'BUG()' on error path and check for 'na == NULL'. > genlmsg_cancel() is only required in error paths for dumping > procedures. So we can remove 'genlmsg_cancel()' calls and 'void *reply' (saves 227 bytes). Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Thomas Graf <tgraf@suug.ch> Cc: Shailabh Nagar <nagar@watson.ibm.com> Cc: Balbir Singh <balbir@in.ibm.com> Cc: Jay Lan <jlan@sgi.com> Signed-off-by:
-
Oleg Nesterov authored
Currently taskstats_user_cmd()/taskstats_exit() do: 1) allocate stats 2) fill stats 3) make a temporary copy on stack (236 bytes) 4) copy that copy to skb 5) free stats With the help of nla_reserve() we can operate on skb->data directly, thus avoiding all these steps except 2). So, before this patch: // copy *stats to skb->data int mk_reply(skb, ..., struct taskstats *stats); fill_pid(stats); mk_reply(skb, ..., stats); After: // return a pointer to skb->data struct taskstats *mk_reply(skb, ...); stat = mk_reply(skb, ...); fill_pid(stats); Shrinks taskatsks.o by 162 bytes. A stupid benchmark (send one million TASKSTATS_CMD_ATTR_PID) shows the real user sys before: 4.02 0.06 3.96 4.02 0.04 3.98 4.02 0.04 3.97 after: 3.86 0.08 3.78 3.88 0.10 3.77 3.89 0.09 3.80 but this looks suspiciously good. Signed-off-by:
Shailabh Nagar <nagar@watson.ibm.com> Cc: Balbir Singh <balbir@in.ibm.com> Cc: Jay Lan <jlan@sgi.com> Cc: Thomas Graf <tgraf@suug.ch> Signed-off-by:
-
Oleg Nesterov authored
Introduce mk_reply() helper which does all nla_put()s on reply. Saves 453 bytes and a preparation for the next patch. Signed-off-by:
-
Oleg Nesterov authored
Allocate ->signal->stats on demand in taskstats_exit(), this allows us to remove taskstats_tgid_alloc() (the last non-trivial inline) from taskstat's public interface. Signed-off-by:
-
Oleg Nesterov authored
do_exit: taskstats_exit_alloc() ... taskstats_exit_send() taskstats_exit_free() I think this is not good, let it be a single function exported to the core kernel, taskstats_exit(), which does alloc + send + free itself. Signed-off-by:
-
Oleg Nesterov authored
If there are no listeners, every task does unneeded kmem_cache alloc/free on exit. We don't need listeners->sem for 'if (!list_empty())' check. Yes, we may have a false positive, but this doesn't differ from the case when the listener is unregistered after we drop the semaphore. So we don't need to do allocation beforehand. Signed-off-by:
-
OGAWA Hirofumi authored
Use put_pages_list() instead of opencoding it. Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
Akinobu Mita authored
This patch makes module init return proper value instead of -1 (-EPERM). Cc: Tim Waugh <tim@cyberelk.net> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
-
Andrew Morton authored
Signed-off-by:
-
Andrew Morton authored
probe_kernel_address() purports to be generic, only it forgot to select KERNEL_DS, so it presently won't work right on all architectures. Signed-off-by:
-
Ryan Underwood authored
Add support for the parallel port (implemented as separate PCI function) on the Oxford Semiconductor OX16PCI952. Signed-off-by:
Ryan Underwood <nemesis@icequake.net> Signed-off-by:
-
Randy Dunlap authored
Make PRINTK_TIME depend on PRINTK. Only display/offer it if PRINTK is enabled. Signed-off-by:
-
Heiko Carstens authored
Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Signed-off-by:
-
Heiko Carstens authored
Signed-off-by:
-
Roland McGrath authored
The CLONE_CHILD_CLEARTID flag is used by NPTL to have its threads communicate via memory/futex when they exit, so pthread_join can synchronize using a simple futex wait. The word of user memory where NPTL stores a thread's own TID is what it passes; this gets reset to zero at thread exit. It is not desireable to touch this user memory when threads are dying due to a fatal signal. A core dump is more usefully representative of the dying program state if the threads live at the time of the crash have their NPTL data structures unperturbed. The userland expectation of CLONE_CHILD_CLEARTID has only ever been that it works for a thread making an _exit system call. This problem was identified by Ernie Petrides <petrides@redhat.com>. Signed-off-by:
Roland McGrath <roland@redhat.com> Cc: Ernie Petrides <petrides@redhat.com> Cc: Jakub Jelinek <jakub@redhat.com> Acked-by:
-
Mika Kukkonen authored
Function v9fs_get_idpool returns int, not u32. Actually it returns -1 on errors, and these two callers check if the value is smaller than 0, which was caught by gcc with extra warning flags. Compile tested only but should be OK, as the value computed in v9fs_get_idpool() is also int. Signed-of-by:
Mika Kukkonen <mikukkon@iki.fi> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Ron Minnich <rminnich@lanl.gov> Cc: Latchesar Ionkov <lucho@ionkov.net> Signed-off-by:
-
Randy Dunlap authored
Fix sparse NULL warning; drivers/misc/tifm_core.c:223:17: warning: Using plain integer as NULL pointer Fix style while there. Signed-off-by:
-
Eric Sandeen authored
I've been using Steve Grubb's purely evil "fsfuzzer" tool, at http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz Basically it makes a filesystem, splats some random bits over it, then tries to mount it and do some simple filesystem actions. At best, the filesystem catches the corruption gracefully. At worst, things spin out of control. As you might guess, we found a couple places in ext4 where things spin out of control :) First, we had a corrupted directory that was never checked for consistency... it was corrupt, and pointed to another bad "entry" of length 0. The for() loop looped forever, since the length of ext4_next_entry(de) was 0, and we kept looking at the same pointer over and over and over and over... I modeled this check and subsequent action on what is done for other directory types in ext4_readdir... (adding this check adds some computational expense; I am testing a followup patch to reduce the number of times we check and re-check these directory entries, in all cases. Thanks for the idea, Andreas). Next we had a root directory inode which had a corrupted size, claimed to be > 200M on a 4M filesystem. There was only really 1 block in the directory, but because the size was so large, readdir kept coming back for more, spewing thousands of printk's along the way. Per Andreas' suggestion, if we're in this read error condition and we're trying to read an offset which is greater than i_blocks worth of bytes, stop trying, and break out of the loop. With these two changes fsfuzz test survives quite well on ext4. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Cc: <linux-ext4@vger.kernel.org> Signed-off-by:
-
Eric Sandeen authored
I've been using Steve Grubb's purely evil "fsfuzzer" tool, at http://people.redhat.com/sgrubb/files/fsfuzzer-0.4.tar.gz Basically it makes a filesystem, splats some random bits over it, then tries to mount it and do some simple filesystem actions. At best, the filesystem catches the corruption gracefully. At worst, things spin out of control. As you might guess, we found a couple places in ext3 where things spin out of control :) First, we had a corrupted directory that was never checked for consistency... it was corrupt, and pointed to another bad "entry" of length 0. The for() loop looped forever, since the length of ext3_next_entry(de) was 0, and we kept looking at the same pointer over and over and over and over... I modeled this check and subsequent action on what is done for other directory types in ext3_readdir... (adding this check adds some computational expense; I am testing a followup patch to reduce the number of times we check and re-check these directory entries, in all cases. Thanks for the idea, Andreas). Next we had a root directory inode which had a corrupted size, claimed to be > 200M on a 4M filesystem. There was only really 1 block in the directory, but because the size was so large, readdir kept coming back for more, spewing thousands of printk's along the way. Per Andreas' suggestion, if we're in this read error condition and we're trying to read an offset which is greater than i_blocks worth of bytes, stop trying, and break out of the loop. With these two changes fsfuzz test survives quite well on ext3. Signed-off-by:
-
Marcus Meissner authored
Randomizes -pie compiled binaries from 64k (0x10000) up to ELF_ET_DYN_BASE. 0 -> 64k is excluded to allow NULL ptr accesses to fail. Signed-off-by:
Marcus Meissner <meissner@suse.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
-
Jarek Poplawski authored
- numeric string size replaced with constant in print_lock_name and print_lockdep_cache, - return on null pointer in print_lock_dependencies, - one more lockdep return with 0 with unlocking fix in mark_lock. Signed-off-by:
Jarek Poplawski <jarkao2@o2.pl> Acked-by:
-
Jarek Poplawski authored
Here are mainly some lockdep returns with 0 with unlocking fixes. Signed-off-by:
-
Alexey Dobriyan authored
paride_register() returns 1 on success, 0 on failure and module init code looks like static int __init foo_init(void) { return paride_register(&foo) - 1; } which is not what one get used to. Converted to usual 0/-E convention. In case of kbic driver, unwind registration. It was just return (paride_register(&k951)||paride_register(&k971))-1; Signed-off-by: -
Alexey Dobriyan authored
We're about to change the semantics of pi_register()'s return value, so rename it to something else first, so that any unconverted code reliaby breaks. Signed-off-by:
-
