- 03 Feb, 2006 40 commits
-
-
OGAWA Hirofumi authored
This patch replaces an own implementation with LL_RW_BLOCK(SWRITE,) which was newly added. Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Andrew Morton authored
Five callsites. I dunno how all this crap got back in there :( Signed-off-by:
-
Paul Fulghum authored
Change locking in the new tty buffering facility from using tty->read_lock, which is currently ignored by drivers and thus ineffective. New locking uses a new tty buffering specific lock enforced centrally in the tty buffering code. Two drivers (esp and cyclades) are updated to use the tty buffering functions instead of accessing tty buffering internals directly. This is required for the new locking to work. Minor checks for NULL buffers added to tty_prepare_flip_string/tty_prepare_flip_string_flags Signed-off-by:
Paul Fulghum <paulkf@microgate.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Alexey Dobriyan authored
On mips: drivers/char/ipmi/ipmi_si_intf.c:1274: error: conflicting types for 'mem_inb' include/asm/io.h:436: error: previous definition of 'mem_inb' was here Don't look at line 436 unless you really know what you're doing. Move those static functions out of more or less generic namespace. Signed-off-by:
Alexey "## should be banned" Dobriyan <adobriyan@gmail.com> Acked-by:
Corey Minyard <minyard@acm.org> Signed-off-by:
-
Fernando Luis Vazquez Cao authored
The compilation of kexec/kdump seems to be broken for x86_64. Remove the dependency of kexec on CONFIG_IA32_EMULATION. Signed-off-by:
Fernando Vazquez <fernando@intellilink.co.jp> Signed-off-by:
-
Paul E. McKenney authored
Fix to broken comment to synchronize_rcu() noted by Keith Owens. Also add sentence noting that synchronize_sched() and synchronize_rcu() are not necessarily identical. Signed-off-by:
Paul E. McKenney <paulmck@us.ibm.com> Cc: Keith Owens <kaos@sgi.com> Cc: Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
Herbert Poetzl authored
The quota check in ext2_new_inode() returns ENOSPC where it should return EDQUOT instead. Signed-off-by:
Herbert Pötzl <herbert@13thfloor.at> Acked-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Zhang, Yanmin authored
The patch implements cpu topology exportation by sysfs. Items (attributes) are similar to /proc/cpuinfo. 1) /sys/devices/system/cpu/cpuX/topology/physical_package_id: represent the physical package id of cpu X; 2) /sys/devices/system/cpu/cpuX/topology/core_id: represent the cpu core id to cpu X; 3) /sys/devices/system/cpu/cpuX/topology/thread_siblings: represent the thread siblings to cpu X in the same core; 4) /sys/devices/system/cpu/cpuX/topology/core_siblings: represent the thread siblings to cpu X in the same physical package; To implement it in an architecture-neutral way, a new source file, driver/base/topology.c, is to export the 5 attributes. If one architecture wants to support this feature, it just needs to implement 4 defines, typically in file include/asm-XXX/topology.h. The 4 defines are: #define topology_physical_package_id(cpu) #define topology_core_id(cpu) #define topology_thread_siblings(cpu) #define topology_core_siblings(cpu) The type of **_id is int. The type of siblings is cpumask_t. To be consistent on all architectures, the 4 attributes should have deafult values if their values are unavailable. Below is the rule. 1) physical_package_id: If cpu has no physical package id, -1 is the default value. 2) core_id: If cpu doesn't support multi-core, its core id is 0. 3) thread_siblings: Just include itself, if the cpu doesn't support HT/multi-thread. 4) core_siblings: Just include itself, if the cpu doesn't support multi-core and HT/Multi-thread. So be careful when declaring the 4 defines in include/asm-XXX/topology.h. If an attribute isn't defined on an architecture, it won't be exported. Thank Nathan, Greg, Andi, Paul and Venki. The patch provides defines for i386/x86_64/ia64. Signed-off-by:
Zhang, Yanmin <yanmin.zhang@intel.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Greg KH <greg@kroah.com> Signed-off-by:
-
Alexey Dobriyan authored
j->write_buffer_rp is a pointer. Signed-off-by:
-
Peter Williams authored
The implementation of int_sqrt() assumes that longs have 32 bits. On systems that have 64 bit longs this will result in gross errors when the argument to the function is greater than 2^32 - 1 on such systems. I doubt whether any such use is currently made of int_sqrt() but the attached patch fixes the problem anyway. Signed-off-by:
Peter Williams <pwil3058@bigpond.com.au> Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by:
-
Herbert Poetzl authored
The already removed sync_dquots_dev(dev,type) is still defined in the no-quota case. Signed-off-by:
-
Adrian Bunk authored
- jsm_driver.c: remove the now unused jsm_rawreadok module_param - jsm_tty.c: remove a now unused variable Is there any problem with removing the now useless jsm_rawreadok module_param? Signed-off-by:
Adrian Bunk <bunk@stusta.de> Cc: V. Ananda Krishnan <mansarov@us.ibm.com> Signed-off-by:
-
V. Ananda Krishnan authored
Signed-off-by:
V. Ananda Krishnan <mansarov@us.ibm.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
dean gaudet authored
There is code in setfl() which attempts to preserve the O_APPEND flag on IS_APPEND files... however IS_APPEND files could also be opened O_RDONLY and in that case setfl() should not require O_APPEND... coreutils 5.93 tail -f attempts to set O_NONBLOCK even on regular files... unfortunately if you try this on an append-only log file the result is this: fcntl64(3, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE) fcntl64(3, F_SETFL, O_RDONLY|O_NONBLOCK|O_LARGEFILE) = -1 EPERM (Operation not permitted) I offer up the patch below as one way of fixing the problem... i've tested it fixes the problem with tail -f but haven't really tested beyond that. (I also reported the coreutils bug upstream... it shouldn't fail imho... <https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=15473>) Signed-off-by:
dean gaudet <dean@arctic.org> Cc: Al Viro <viro@ftp.linux.org.uk> Acked-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Markus Lidel authored
- This controller violates the I2O spec for the I/O registers. The patch contains a workaround which moves the registers to the proper location. (originally author: Matthew Starzewski) - If a message frame is beyond the mapped address range a error is returned. Signed-off-by:
Markus Lidel <Markus.Lidel@shadowconnect.com> Signed-off-by:
-
Markus Lidel authored
If PCI device is enabled before probing, it will not be disabled at exit. Signed-off-by:
-
Jeff Moyer authored
Currently, if you open a file O_DIRECT, truncate it to a size that is not a multiple of the disk block size, and then try to read the last block in the file, the read will return 0. The problem is in do_direct_IO, here: /* Handle holes */ if (!buffer_mapped(map_bh)) { char *kaddr; ... if (dio->block_in_file >= i_size_read(dio->inode)>>blkbits) { /* We hit eof */ page_cache_release(page); goto out; } We shift off any remaining bytes in the final block of the I/O, resulting in a 0-sized read. I've attached a patch that fixes this. I'm not happy about how ugly the math is getting, so suggestions are more than welcome. I've tested this with a simple program that performs the steps outlined for reproducing the problem above. Without the patch, we get a 0-sized result from read. With the patch, we get the correct return value from the short read. Signed-off-by:Jeff Moyer <jmoyer@redhat.com> Cc: Badari Pulavarty <pbadari@us.ibm.com> Cc: Suparna Bhattacharya <suparna@in.ibm.com> Cc: Mingming Cao <cmm@us.ibm.com> Cc: Joel Becker <Joel.Becker@oracle.com> Cc: "Chen, Kenneth W" <kenneth.w.chen@intel.com> Signed-off-by:
-
Carsten Otte authored
In case we have CONFIG_FS_XIP, ext2_show_options shows "xip" if EXT2_MOUNT_XIP mount flag is set. Signed-off-by:
Carsten Otte <cotte@de.ibm.com> Signed-off-by:
-
schwab@suse.de authored
Don't compute and display the per-irq sums on ia64 either, too much overhead for mostly useless figures. Cc: Olaf Hering <olh@suse.de> Acked-by:
"Luck, Tony" <tony.luck@intel.com> Signed-off-by:
-
Randy Dunlap authored
drivers/edac/e752x_edac.c:1042:7: warning: obsolete struct initializer, use C99 syntax Signed-off-by:
Randy Dunlap <rdunlap@xenotime.net> Signed-off-by:
-
Randy Dunlap authored
kernel/cpuset.c:644:38: warning: non-ANSI function declaration of function 'cpuset_update_task_memory_state' Signed-off-by:
Paul Jackson <pj@sgi.com> Signed-off-by:
-
Arnaud Giersch authored
Remove dead address for David Campbell in MAINTAINERS. Signed-off-by:
Arnaud Giersch <arnaud.giersch@free.fr> Signed-off-by:
-
Arnaud Giersch authored
Fix documentation to actually match the code. Signed-off-by:
-
George Anzinger authored
- In case of a negative nsec value the result of the division must be normalized. - Remove inline from an exported function. Signed-off-by:
George Anzinger <george@wildturkeyranch.net> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Latchesar Ionkov authored
When v9fs_mux_rpc sends a 9P message, it may be put in the queue of unsent request. If the user process receives a signal, v9fs_mux_rpc sets the request error to ERREQFLUSH and assigns NULL to request's send message. If the message was still in the unsent queue, v9fs_write_work would produce an oops while processing it. The patch makes sure that requests that are being flushed are moved to the pending requests queue safely. If a request is being flushed, don't remove it from the list of pending requests even if it receives a reply before the flush is acknoledged. The request will be removed during from the Rflush handler (v9fs_mux_flush_cb). Signed-off-by:
Latchesar Ionkov <lucho@ionkov.net> Cc: Eric Van Hensbergen <ericvh@ericvh.myip.org> Signed-off-by:
-
Latchesar Ionkov authored
v9fs_put_str used to store pointer to the source string, instead of the cbuf copy. This patch corrects it. Signed-off-by:
-
Latchesar Ionkov authored
Two symlink fixes, v9fs_readlink didn't copy the last character of the symlink name, v9fs_vfs_follow_link incorrectly called strlen of newly allocated buffer instead of PATH_MAX. Signed-off-by:
-
Arnaud Giersch authored
Add support for the built-in parallel port on SGI O2 (a.k.a. IP32). Define a new configuration option: PARPORT_IP32. The module is named parport_ip32. Hardware support for SPP, EPP and ECP modes along with DMA support when available are currently implemented. Signed-off-by:
-
Felix Oxley authored
Signed-off-by:
Felix Oxley <lkml@oxley.org> Signed-off-by:
-
Domen Puncer authored
A few lines above the patch we have: char *srec; srec = kmalloc(SCIOC_SRECSIZE, GFP_KERNEL); sizeof pointer is probably not meant here. Signed-off-by:
Domen Puncer <domen@coderock.org> Signed-off-by:
-
Tobias Klauser authored
Signed-off-by:
Tobias Klauser <tklauser@nuerscht.ch> Signed-off-by:
-
Andreas Gruenbacher authored
There is a code path that passed size to ext2_xattr_set (ext3_xattr_set_handle) before initializing it. The callees don't use the value in that case, but gcc cannot tell. Always initialize size to get rid of the warnings. Signed-off-by:
Andreas Gruenbacher <agruen@suse.de> Signed-off-by:
-
Andreas Schwab authored
Fix this warning: fs/ufs/super.c: In function âufs_fill_superâ: fs/ufs/super.c:858: warning: case label value exceeds maximum value for type which happens because __s8 != char. These macros are used for struct ufs_super_block.fs_clean which is declared as __s8. Signed-off-by:
Andreas Schwab <schwab@suse.de> Signed-off-by:
-
Dave Jones authored
The AMD76x chipsets aren't used in 64-bit, so don't offer the driver to the user. Signed-off-by:
Dave Jones <davej@redhat.com> Acked-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Tong Li authored
Fix the problem in kernel 2.6.15.1 (and early versions) that OProfile on x86_64 does not correctly collect the stack traces for kernel functions. The original code in valid_kernel_stack() in arch/i386/oprofile/backtrace.c assumes that the frame pointer (headaddr) should be greater than stack (i.e., regs). This assumption is wrong for x86_64 because NMIs in x86_64 use a seperate stack different from the kernel stack. Therefore, the variable stack now points to some location on the NMI stack, which turns out to be at a higher address than the frame pointer (headaddr) on the kernel stack. The correct comparison here should be between headaddr and regs->rsp for x86_64. Signed-off-by:
Tong Li <tong.n.li@intel.com> Cc: John Levon <levon@movementarian.org> Cc: Philippe Elie <phil.el@wanadoo.fr> Signed-off-by:
-
Alan Cox authored
Breakage reported by Adrian Bunk Untested (no hardware) Signed-off-by:
-
Alan Cox authored
INKERNEL is always defined HOST is never defined therefore RTA is also never defined Strip the relevant garbage out of the headers on this basis. Signed-off-by:
-
Marcelo Tosatti authored
Shrinks "struct dentry" from 128 bytes to 124 on x86, allowing 31 objects per slab instead of 30. Cc: John Levon <levon@movementarian.org> Cc: Philippe Elie <phil.el@wanadoo.fr> Signed-off-by:
-
Evgeniy Dushistov authored
This fixes the code like this: bh = sb_find_get_block (sb, tmp + j); if ((bh && DATA_BUFFER_USED(bh)) || tmp != fs32_to_cpu(sb, *p)) { retry = 1; brelse (bh); goto next1; } bforget (bh); sb_find_get_block() ordinarily returns a buffer_head with b_count>=2, and this code assume that in case if "b_count>1" buffer is used, so this caused infinite loop. (akpm: that is-the-buffer-busy code is incomprehensible. Good riddance. Use of block_truncate_page() seems sane). Signed-off-by:Evgeniy Dushistov <dushistov@mail.ru> Signed-off-by:
-
Evgeniy Dushistov authored
"rm" command, on file system with "ufs1" type cause system hang up. This is, in fact, not so bad as it seems to be, because of after that in "kernel control path" there are 3-4 places which may cause "oops". So the first patch fix oopses, and the second patch fix "kernel hang up". "oops" appears because of reading of group's summary info partly wrong, and access to not first group's summary info cause "oops". Signed-off-by:
-
