Unkillable gdb process gets system unusably slow

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

Unkillable gdb process gets system unusably slow

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 stdio.h #include string.h

[PATCH] Allow changing O_SYNC with fcntl().

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)

[PATCH] Allow changing O_SYNC with fcntl().

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)

inotify_rm_watch() EINVAL race condition for deleted files

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

inotify_rm_watch() EINVAL race condition for deleted files

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

Re: SMP read() stopping at memory page boundaries

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

Re: SMP read() stopping at memory page boundaries

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 think this sh

Re: SMP read() stopping at memory page boundaries

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 first because it ha

SMP read() stopping at memory page boundaries

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

SMP read() stopping at memory page boundaries

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

Re: SMP read() stopping at memory page boundaries

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 first because it happened

Re: SMP read() stopping at memory page boundaries

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 think this should ever happen, right? man 2 read

Re: SMP read() stopping at memory page boundaries

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 to do

O_APPEND, lseek() and pwrite()

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.

O_APPEND, lseek() and pwrite()

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.