- 07 Dec, 2006 40 commits
-
-
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:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
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:
-
Hans-Christian Egtvedt authored
<quote Imre Deak from Thu, 12 Jan 2006 21:18:54 +0200> In order for spi_busnum_to_master to work spi master devices must be linked into the spi_master_class.subsys.kset list. At the moment the default class_obj_subsys.kset is used and we can't enumerate the master devices. </quote> Signed-off-by:
Hans-Christian Egtvedt <hcegtvedt@atmel.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
-
Hans-Christian Egtvedt authored
Correct the following in driver/spi/spi.c in function spi_busnum_to_master: * must allow bus_num 0, the if is really not needed. * correct the name buffer which is too small for bus_num >= 10000. It should be 9 bytes big, not 8. Signed-off-by:
-
Andreas Gruenbacher authored
lock_super() is unnecessary for setting super-block feature flags. Use the provided *_SET_COMPAT_FEATURE() macros as well. Signed-off-by:
Andreas Gruenbacher <agruen@suse.de> Cc: <linux-ext4@vger.kernel.org> Signed-off-by:
-
Paul Jackson authored
A couple of minor code simplifications to the kernel/cpuset.c code. No functional change. Just a little less code and a little more readable. Signed-off-by:
Paul Jackson <pj@sgi.com> Signed-off-by:
-
Jan Engelhardt authored
linux/cdev.h uses struct kobject and other structs and should therefore include them. Currently, a module either needs to add the missing includes itself, or, in case a module includes other headers already, needs to put <linux/cdev.h> last, which goes against a alphabetically-sorted include list. Signed-off-by:
Jan Engelhardt <jengelh@gmx.de> Signed-off-by:
-
Peter Zijlstra authored
rmmod/3080 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: (proc_subdir_lock){--..}, at: [<c04a33b0>] remove_proc_entry+0x40/0x191 and this task is already holding: (ide_lock){++..}, at: [<c05651a2>] ide_unregister_subdriver+0x39/0xc8 which would create a new lock dependency: (ide_lock){++..} -> (proc_subdir_lock){--..} but this new dependency connects a hard-irq-safe lock: (ide_lock){++..} ... which became hard-irq-safe at: [<c043c458>] lock_acquire+0x4b/0x6b [<c06129d7>] _spin_lock_irqsave+0x22/0x32 [<c0567870>] ide_intr+0x17/0x1a9 [<c044eb31>] handle_IRQ_event+0x20/0x4d [<c044ebf2>] __do_IRQ+0x94/0xef [<c0406771>] do_IRQ+0x9e/0xbd to a hard-irq-unsafe lock: (proc_subdir_lock){--..} ... which became hard-irq-unsafe at: ... [<c043c458>] lock_acquire+0x4b/0x6b [<c06126ab>] _spin_lock+0x19/0x28 [<c04a32f2>] xlate_proc_name+0x1b/0x99 [<c04a3547>] proc_create+0x46/0xdf [<c04a3642>] create_proc_entry+0x62/0xa5 [<c07c1972>] proc_misc_init+0x1c/0x1d2 [<c07c1844>] proc_root_init+0x4c/0xe9 [<c07ad703>] start_kernel+0x294/0x3b3 Move ide_remove_proc_entries() out from under ide_lock; there is nothing that indicates that this is needed. In specific, the call to ide_add_proc_entries() is unprotected, and there is nothing else in the file using the respective ->proc fields. Also the lock order around destroy_proc_ide_interface() suggests this. Alan sayeth: proc_ide_write_settings walks the setting list under ide_setting_sem, read ditto. remove_proc_entry is doing proc side housekeeping. Looks fine to me, although that old code is such a mess anything could be going on. Signed-off-by: -
Alan Cox authored
Jeff noted that the via driver returned an error to an unsigned int in a a case where errors are not permitted. Move the check down earlier so we can handle it properly. Not as pretty but it works this way and avoids hacking up ugly stuff in the legacy ide core. Signed-off-by:
Alan Cox <alan@redhat.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Suzuki K P authored
One of our test team hit a reiserfs_panic while running fsstress tests on 2.6.19-rc1. The message looks like : REISERFS: panic(device Null superblock): reiserfs[5676]: assertion !(p->path_length != 1 ) failed at fs/reiserfs/stree.c:397:reiserfs_check_path: path not properly relsed. The backtrace looked : kernel BUG in reiserfs_panic at fs/reiserfs/prints.c:361! .reiserfs_check_path+0x58/0x74 .reiserfs_get_block+0x1444/0x1508 .__block_prepare_write+0x1c8/0x558 .block_prepare_write+0x34/0x64 .reiserfs_prepare_write+0x118/0x1d0 .generic_file_buffered_write+0x314/0x82c .__generic_file_aio_write_nolock+0x350/0x3e0 .__generic_file_write_nolock+0x78/0xb0 .generic_file_write+0x60/0xf0 .reiserfs_file_write+0x198/0x2038 .vfs_write+0xd0/0x1b4 .sys_write+0x4c/0x8c syscall_exit+0x0/0x4 Upon debugging I found that the restart_transaction was not releasing the path if the th->refcount was > 1. /*static*/ int restart_transaction(struct reiserfs_transaction_handle *th, struct inode *inode, struct path *path) { [...] /* we cannot restart while nested */ if (th->t_refcount > 1) { <<- Path is not released in this case! return 0; } pathrelse(path); <<- Path released here. [...] This could happen in such a situation : In reiserfs/inode.c: reiserfs_get_block() :: if (repeat == NO_DISK_SPACE || repeat == QUOTA_EXCEEDED) { /* restart the transaction to give the journal a chance to free ** some blocks. releases the path, so we have to go back to ** research if we succeed on the second try */ SB_JOURNAL(inode->i_sb)->j_next_async_flush = 1; -->> retval = restart_transaction(th, inode, &path); <<-- We are supposed to release the path, no matter we succeed or fail. But if the th->refcount is > 1, the path is still valid. And, if (retval) goto failure; repeat = _allocate_block(th, block, inode, &allocated_block_nr, NULL, create); If the above allocate_block fails with NO_DISK_SPACE or QUOTA_EXCEEDED, we would have path which is not released. if (repeat != NO_DISK_SPACE && repeat != QUOTA_EXCEEDED) { goto research; } if (repeat == QUOTA_EXCEEDED) retval = -EDQUOT; else retval = -ENOSPC; goto failure; [...] failure: [...] reiserfs_check_path(&path); << Panics here ! Attached here is a patch which could fix the issue. fix reiserfs/inode.c : restart_transaction() to release the path in all cases. The restart_transaction() doesn't release the path when the the journal handle has a refcount > 1. This would trigger a reiserfs_panic() if we encounter an -ENOSPC / -EDQUOT in reiserfs_get_block(). Signed-off-by:Suzuki K P <suzuki@in.ibm.com> Cc: "Vladimir V. Saveliev" <vs@namesys.com> Cc: <reiserfs-dev@namesys.com> Cc: Jeff Mahoney <jeffm@suse.com> Acked-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
