- 09 Jan, 2006 40 commits
-
-
Guillaume Chazarain authored
What's the true meaning of the printk return value? Should it include the priority prefix length of 3? and what about the timing information? In both cases it was broken: strace -e write echo 1 > /dev/kmsg => write(1, "1\n", 2) = 5 strace -e write echo "<1>1" > /dev/kmsg => write(1, "<1>1\n", 5) = 8 The returned length was "length of input string + 3", I made it "length of string output to the log buffer". Note that I couldn't find any printk caller in the kernel interested by its return value besides kmsg_write. Signed-off-by:
Guillaume Chazarain <guichaz@yahoo.fr> Acked-By:
Tim Bird <tim.bird@am.sony.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
NeilBrown authored
When making an fctl locking call through compat_sys_fcntl64 (i.e. a 32bit app on a 64bit kernel), the syscall can return a locking range that is in conflict with the queried lock. If some aspect of this range does not fit in the 32bit structure, something needs to be done. The current code is wrong in several respects: - It returns data to userspace even if no conflict was found i.e. it should check l_type for F_UNLCK - It returns -EOVERFLOW too agressively. A lock range covering the last possible byte of the file (start = COMPAT_OFF_T_MAX, len = 1) should be possible, but is rejected with the current test. - A extra-long 'len' should not be a problem. If only that part of the conflicting lock that would be visible to the 32bit app needs to be reported to the 32bit app anyway. This patch addresses those three issues and adds a comment to (hopefully) record it for posterity. Note: this patch mainly affects test-cases. Real applications rarely is ever see the problems. This patch has been tested (LSB test suite), and works. Signed-off-by:
Neil Brown <neilb@suse.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Christoph Hellwig <hch@lst.de> Cc: Matthew Wilcox <willy@debian.org> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by:
-
NeilBrown authored
SUS requires that when truncating a file to the size that it currently is: truncate and ftruncate should NOT modify ctime or mtime O_TRUNC SHOULD modify ctime and mtime. Currently mtime and ctime are always modified on most local filesystems (side effect of ->truncate) or never modified (on NFS). With this patch: ATTR_CTIME|ATTR_MTIME are sent with ATTR_SIZE precisely when an update of these times is required whether size changes or not (via a new argument to do_truncate). This allows NFS to do the right thing for O_TRUNC. inode_setattr nolonger forces ATTR_MTIME|ATTR_CTIME when the ATTR_SIZE sets the size to it's current value. This allows local filesystems to do the right thing for f?truncate. Also, the logic in inode_setattr is changed a bit so there are two return points. One returns the error from vmtruncate if it failed, the other returns 0 (there can be no other failure). Finally, if vmtruncate succeeds, and ATTR_SIZE is the only change requested, we now fall-through and mark_inode_dirty. If a filesystem did not have a ->truncate function, then vmtruncate will have changed i_size, without marking the inode as 'dirty', and I think this is wrong. Signed-off-by: -
David Howells authored
Make it possible to include linux/pagevec.h multiple times without incurring errors due to duplicate definitions. Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Antonino A. Daplas authored
Reported from Redhat Bugzilla Bug 170450 "I updated to the development kernel and now during boot only the top of the text is visable. For example the monitor screen the is the lines and I can only see text in the asterisk area.
-
Samuel Thibault authored
When doublescan mode is in use, scanlines must be doubled. Thanks to Jason Dravet <dravet@hotmail.com> for reporting and testing. Signed-off-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Cc: <stable@kernel.org> Signed-off-by:
-
Christoph Hellwig authored
inode can never be NULL when calling this function. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
The ptrace_get_task_struct() helper that I added as part of the ptrace consolidation is useful in variety of places that currently opencode it. Switch them to the common helpers. Add a ptrace_traceme() helper that needs to be explicitly called, and simplify the ptrace_get_task_struct() interface. We don't need the request argument now, and we return the task_struct directly, using ERR_PTR() for error returns. It's a bit more code in the callers, but we have two sane routines that do one thing well now. Signed-off-by:
-
Tom Zanussi authored
librelay and relay-app.h have been retired - update Documentation to reflect that. Signed-off-by:
Tom Zanussi <zanussi@us.ibm.com> Signed-off-by:
-
Tom Zanussi authored
This patch renames relayfs_file_operations to relay_file_operations, and the file operations themselves from relayfs_XXX to relay_file_XXX, to make it more clear that they refer to relay files. Signed-off-by:
-
Tom Zanussi authored
Documentation update for creating global buffers. Signed-off-by:
-
Tom Zanussi authored
This patch adds the optional is_global outparam to the create_buf_file() callback. This can be used by clients to create a single global relayfs buffer instead of the default per-cpu buffers. This was suggested as being useful for certain debugging applications where it's more convenient to be able to get all the data from a single channel without having to go to the bother of dealing with per-cpu files. Signed-off-by:
-
Tom Zanussi authored
Documentation update for creating relay files in other filesystems. Signed-off-by:
-
Tom Zanussi authored
This patch adds a couple of callback functions that allow a client to hook into relay_open()/close() and supply the files that will be used to represent the channel buffers; the default implementation if no callbacks are defined is to create the files in relayfs. This is to support the creation and use of relay files in other filesystems such as debugfs, as implied by the fact that relayfs_file_operations are exported. Signed-off-by:
-
Tom Zanussi authored
Documentation update for non-relay files. Signed-off-by:
-
Tom Zanussi authored
Since we're no longer using relayfs_inode_info, remove relayfs_alloc_inode() and relayfs_destroy_inode() along with the relayfs inode cache. Signed-off-by:
-
Tom Zanussi authored
Use inode->u.generic_ip instead of relayfs_inode_info to store pointer to user data. Clients using relayfs_file_create() to create their own files would probably more expect their data to be stored in generic_ip; we also intend in the next set of patches to get rid of relayfs-specific stuff in the file operations, so we might as well do it here. Signed-off-by:
-
Tom Zanussi authored
This patch adds and exports relayfs_remove_file(), for API symmetry (with relayfs_create_file()). Signed-off-by:
-
Tom Zanussi authored
This patch adds a mandatory fileops param to relayfs_create_file() and exports that function so that clients can use it to create files defined by their own set of file operations, in relayfs. The purpose is to allow relayfs applications to create their own set of 'control' files alongside their relay files in relayfs rather than having to create them in /proc or debugfs for instance. relayfs_create_file() is also used by relay_open_buf() to create the relay files for a channel. In this case, a pointer to relayfs_file_operations is passed in, along with a pointer to the buffer associated with the file. Signed-off-by:
-
Tom Zanussi authored
The patch series implementa or fixes 3 things that were specifically requested or suggested by relayfs users: - support for non-relay files (patches 1-6) Currently, the relayfs API only supports the creation of directories (relayfs_create_dir()) and relay files (relay_open()). These patches adds support for non-relay files (relayfs_create_file()). This is so relayfs applications can create 'control files' in relayfs itself rather than in /proc or via a netlink channel, as is currently done in the relay-app examples. Basically what this amounts to is exporting relayfs_create_file() with an additional file_ops param that clients can use to supply file operations for their own special-purpose files in relayfs. - make exported relay file ops useful (patches 7-8) The relayfs relay_file_operations have always been exported, the intent being to make it possible to create relay files in other filesystems such as debugfs. The problem, though, is that currently the file operations are too tightly coupled to relayfs to actually be used for this purpose. This patch fixes that by adding a couple of callback functions that allow a client to hook into relay_open()/close() and supply the files that will be used to represent the channel buffers; the default implementation if no callbacks are defined is to create the files in relayfs. - add an option to create global relay buffer (patches 9-10) The file creation callback also supplies an optional param, is_global, that can be used by clients to create a single global relayfs buffer instead of the default per-cpu buffers. This was suggested as being useful for certain debugging applications where it's more convenient to be able to get all the data from a single channel without having to go to the bother of dealing with per-cpu files. - cleanup, some renaming and Documentation updates (patches 11-12) There were several comments that the use of netlink in the example code was non-intuitive and in fact the whole relay-app business was needlessly confusing. Based on that feedback, the example code has been completely converted over to relayfs control files as supported by this patch, and have also been made completely self-contained. The converted examples along with a couple of new examples that demonstrate using exported relay files can be found in relay-apps tarball: http://prdownloads.sourceforge.net/relayfs/relay-apps-0.9.tar.gz?download This patch: Separate buffer create/destroy from inode create/destroy. We want to be able to associate other data and not just relay buffers with inodes. Buffer create/destroy is moved out of inode.c and into relayfs core code. Signed-off-by:
-
Andrew Morton authored
Unobfsucate this struct member Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
-
Jan Beulich authored
Needed for the Novell kernel debugger and perhaps some per-cpu data on x86_64 in the future. Cc: Andi Kleen <ak@muc.de> Signed-off-by:
-
Nick Piggin authored
Use atomic_inc_not_zero for rcu files instead of special case rcuref. Signed-off-by:
Nick Piggin <npiggin@suse.de> Cc: "Paul E. McKenney" <paulmck@us.ibm.com> Signed-off-by:
-
Nick Piggin authored
Convert atomic_dec_and_lock to use new atomic primitives. Signed-off-by:
-
Peter Osterlund authored
Use bd_claim() when opening the cdrom device to prevent user space programs such as cdrecord, hald and kded from interfering with the burning process. Signed-off-by:
Peter Osterlund <petero2@telia.com> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Adrian Bunk authored
This patch contains the following cleanups: - make needlessly global functions static - every file should include the headers containing the prototypes for it's global functions Signed-off-by:
Adrian Bunk <bunk@stusta.de> Acked-by:
"Paul E. McKenney" <paulmck@us.ibm.com> Signed-off-by:
-
Adrian Bunk authored
"extern inline" -> "static inline" Since there's no pullphone() function this patch removes the dead prototype. Signed-off-by:
Karsten Keil <kkeil@suse.de> Signed-off-by:
-
Adrian Bunk authored
This patch moves the rtc_interrupt() prototype to rtc.h and removes the prototypes from C files. It also renames static rtc_interrupt() functions in arch/arm/mach-integrator/time.c and arch/sh64/kernel/time.c to avoid compile problems. Signed-off-by:
Paul Gortmaker <p_gortmaker@yahoo.com> Acked-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
OGAWA Hirofumi authored
This patch add EXPORT_SYMBOL(filemap_write_and_wait) and use it. See mm/filemap.c: And changes the filemap_write_and_wait() and filemap_write_and_wait_range(). Current filemap_write_and_wait() doesn't wait if filemap_fdatawrite() returns error. However, even if filemap_fdatawrite() returned an error, it may have submitted the partially data pages to the device. (e.g. in the case of -ENOSPC) <quotation> Andrew Morton writes, If filemap_fdatawrite() returns an error, this might be due to some I/O problem: dead disk, unplugged cable, etc. Given the generally crappy quality of the kernel's handling of such exceptions, there's a good chance that the filemap_fdatawait() will get stuck in D state forever. </quotation> So, this patch doesn't wait if filemap_fdatawrite() returns the -EIO. Trond, could you please review the nfs part? Especially I'm not sure, nfs must use the "filemap_fdatawrite(inode->i_mapping) == 0", or not. Acked-by:
Trond Myklebust <trond.myklebust@fys.uio.no> Signed-off-by:
-
OGAWA Hirofumi authored
This patch changes generic_cont_expand(), in order to share the code with fatfs. - Use vmtruncate() if ->prepare_write() returns a error. Even if ->prepare_write() returns an error, it may already have added some blocks. So, this truncates blocks outside of ->i_size by vmtruncate(). - Add generic_cont_expand_simple(). The generic_cont_expand_simple() assumes that ->prepare_write() can handle the block boundary. With this, we don't need to care the extra byte. And for expanding a file size by truncate(), fatfs uses the added generic_cont_expand_simple(). Signed-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
OGAWA Hirofumi authored
This exports/changes the sync_page_range/_nolock(). The fatfs needs sync_page_range/_nolock() for expanding truncate, and changes "size_t count" to "loff_t count". Signed-off-by:
-
OGAWA Hirofumi authored
This patch add to support of ->direct_IO() for mostly read. The user of this seems to want to use for streaming read. So, current direct I/O has limitation, it can only overwrite. (For write operation, mainly we need to handle the hole etc..) Signed-off-by:
-
OGAWA Hirofumi authored
All EXPORT_SYMBOL of fatfs is only for vfat/msdos. _GPL would be proper. Signed-off-by:
-
OGAWA Hirofumi authored
Signed-off-by:
-
OGAWA Hirofumi authored
We don't need to allocate buffer for checking the buffer is uptodate. This use sb_find_get_block() instead, and if it returns NULL it's not uptodate. Signed-off-by:
-
OGAWA Hirofumi authored
It is overkill to update the FS_INFO whenever modifying prev_free/free_clusters, because those are just a hint. So, this patch uses ->write_super() for updating FS_INFO instead. Signed-off-by:
-
Russell King authored
Some ARM platforms have the ability to program the interrupt controller to detect various interrupt edges and/or levels. For some platforms, this is critical to setup correctly, particularly those which the setting is dependent on the device. Currently, ARM drivers do (eg) the following: err = request_irq(irq, ...); set_irq_type(irq, IRQT_RISING); However, if the interrupt has previously been programmed to be level sensitive (for whatever reason) then this will cause an interrupt storm. Hence, if we combine set_irq_type() with request_irq(), we can then safely set the type prior to unmasking the interrupt. The unfortunate problem is that in order to support this, these flags need to be visible outside of the ARM architecture - drivers such as smc91x need these flags and they're cross-architecture. Finally, the SA_TRIGGER_* flag passed to request_irq() should reflect the property that the device would like. The IRQ controller code should do its best to select the most appropriate supported mode. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Paul Fulghum authored
New character device driver for the SyncLink GT and SyncLink AC families of synchronous and asynchronous serial adapters Signed-off-by:
Paul Fulghum <paulkf@microgate.com> Signed-off-by:
-
Tim Schmielau authored
Include fixes for 2.6.14-git11. Should allow to remove sched.h from module.h on i386, x86_64, arm, ia64, ppc, ppc64, and s390. Probably more to come since I haven't yet checked the other archs. Signed-off-by:
Tim Schmielau <tim@physik3.uni-rostock.de> Signed-off-by:
-
Paul Jackson authored
For systems that aren't using cpusets, but have them CONFIG_CPUSET enabled in their kernel (eventually this may be most distribution kernels), this patch removes even the minimal rcu_read_lock() from the memory page allocation path. Actually, it removes that rcu call for any task that is in the root cpuset (top_cpuset), which on systems not actively using cpusets, is all tasks. We don't need the rcu check for tasks in the top_cpuset, because the top_cpuset is statically allocated, so at no risk of being freed out from underneath us. Signed-off-by:
Paul Jackson <pj@sgi.com> Signed-off-by:
-
