- 26 3月, 2006 1 次提交
-
-
由 Carsten Otte 提交于
nr_segs is unsigned long and thus cannot be negative. We checked against 0 few lines before. Signed-off-by: NCarsten Otte <cotte@de.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 10 1月, 2006 1 次提交
-
-
由 Jes Sorensen 提交于
This patch converts the inode semaphore to a mutex. I have tested it on XFS and compiled as much as one can consider on an ia64. Anyway your luck with it might be different. Modified-by: NIngo Molnar <mingo@elte.hu> (finished the conversion) Signed-off-by: NJes Sorensen <jes@sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 05 1月, 2006 1 次提交
-
-
由 Linus Torvalds 提交于
In particular, allow over-large read- or write-requests to be downgraded to a more reasonable range, rather than considering them outright errors. We want to protect lower layers from (the sadly all too common) overflow conditions, but prefer to do so by chopping the requests up, rather than just refusing them outright. Cc: Peter Anvin <hpa@zytor.com> Cc: Ulrich Drepper <drepper@redhat.com> Cc: Andi Kleen <ak@suse.de> Cc: Al Viro <viro@ftp.linux.org.uk> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 30 9月, 2005 1 次提交
-
-
由 Kostik Belousov 提交于
it seems that readv(2)/writev(2) syscalls do not call file_permission callback. Looks like this is overlook. I have filled the issue into redhat bugzilla as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169433 and got the recommendation to post this on lsm mailing list. The following trivial patch solves the problem. Signed-off-by: NKostik Belousov <kostikbel@gmail.com> Signed-off-by: NChris Wright <chrisw@osdl.org>
-
- 08 9月, 2005 1 次提交
-
-
由 Eric Dumazet 提交于
struct file cleanup: f_maxcount has an unique value (INT_MAX). Just use the hard-wired value. Signed-off-by: NEric Dumazet <dada1@cosmosbay.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 13 7月, 2005 1 次提交
-
-
由 Robert Love 提交于
inotify is intended to correct the deficiencies of dnotify, particularly its inability to scale and its terrible user interface: * dnotify requires the opening of one fd per each directory that you intend to watch. This quickly results in too many open files and pins removable media, preventing unmount. * dnotify is directory-based. You only learn about changes to directories. Sure, a change to a file in a directory affects the directory, but you are then forced to keep a cache of stat structures. * dnotify's interface to user-space is awful. Signals? inotify provides a more usable, simple, powerful solution to file change notification: * inotify's interface is a system call that returns a fd, not SIGIO. You get a single fd, which is select()-able. * inotify has an event that says "the filesystem that the item you were watching is on was unmounted." * inotify can watch directories or files. Inotify is currently used by Beagle (a desktop search infrastructure), Gamin (a FAM replacement), and other projects. See Documentation/filesystems/inotify.txt. Signed-off-by: NRobert Love <rml@novell.com> Cc: John McCutchan <ttb@tentacle.dhs.org> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 24 6月, 2005 1 次提交
-
-
由 Benjamin LaHaise 提交于
When do_sync_(read|write) encounters an aio method that makes use of the retry mechanism, they fail to correctly retry the operation. This fixes that by adding the appropriate sleep and retry mechanism. Signed-off-by: NBenjamin LaHaise <benjamin.c.lahaise@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 2 次提交
-
-
由 Dave Hansen 提交于
Bugme bug 4326: http://bugme.osdl.org/show_bug.cgi?id=4326 reports: executing the systemcall readv with Bad argument ->len == -1) it gives out error EFAULT instead of EINVAL Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-