Fully reproducible with me. v2.6.23.1 x86-64 SMP kernel, Core 2 CPU, gdb
v6.6.90.20070912-debian.
gdb ./hang
run
fr 1
p (char*)base
p command hangs and the entire system becomes unusably slow. kill -9
doesn't kill gdb.
/* gcc hang.c -o hang -g -Wall */
#include
#include
#include
#include
#in
Is there a reason why this isn't allowed now?
---
fs/fcntl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 8685263..fc0c92e 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -203,7 +203,7 @@ asmlinkage long sys_dup(unsigned int fildes)
r
1. Add IN_DELETE_SELF watch to a file
2. unlink() the file
3. Try to remove the watch -> EINVAL
I undestand this happens because there's an IN_IGNORED event in the
inotify queue, but couldn't inotify_rm_watch() be silent about it if the
event hasn't been read()? Otherwise there's a race condition
On Wed, 2007-06-20 at 18:05 +0100, Alan Cox wrote:
> > I thought this wouldn't happen when reading from local filesystems.
> > Anyway, my real program was doing that, and it was still seeing partial
> > data. But looks like I can't reproduce it in my test program with two
> > pread()s, so I'll have
On Wed, 2007-06-20 at 09:22 -0700, Ray Lee wrote:
> On 6/20/07, Timo Sirainen <[EMAIL PROTECTED]> wrote:
> > On Wed, 2007-06-20 at 17:52 +0300, Timo Sirainen wrote:
> > > Sometimes read() returns only 4096 bytes. I'm locking the file, so I
> > > don't thi
On Wed, 2007-06-20 at 17:52 +0300, Timo Sirainen wrote:
> Sometimes read() returns only 4096 bytes. I'm locking the file, so I
> don't think this should ever happen, right?
Sorry, the problem was with file truncating so there's no bug with
locking. I didn't notice it fi
Tested with various 2.6.x i386/x86-64 SMP kernels and CPUs, for example
2.6.21.3/x86-64.
Process 1:
- lock file
- write(4096 + 16 bytes)
- unlock file
Process 2:
- lock file
- read(8192 bytes)
- unlock file
Sometimes read() returns only 4096 bytes. I'm locking the file, so I
don't think
If I open a file with O_APPEND and write() to it, it looks like the
file offset is updated and I can get it with lseek(SEEK_CUR). Can I
trust that this behavior won't change in future Linux versions?
Apparently this isn't standard, because at least OS X and Solaris
don't do this.
pwrite()
8 matches
Mail list logo