Jan Kara wrote: > The problem is that the hung process need not be directly related to the > hang. It can be just a victim of a race with some other process > manipulating j_barrier_count. I agree. /bin/sh would not hang by such simple write() call. /bin/sh will be a victim of somebody else's write() calls. But I think these three cases have something characteristic point. For updating rpm's database, I think rpm would wait for data to be written (using O_SYNC or fsync()). For auditing login event, I think the issuer of audit event would wait for data to be written. For postgresql, I think postmaster would wait for transaction log to be written. So, my guess is multiple threads are writing data (maybe one is sync mode and another is async mode, maybe one is calling fsync() and another is calling write()). I wish there are test programs that cover such combinations. If this hang occurs by simply multiple threads writing data in async mode, this hang must have been reported so many times. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
