Messages in this thread | | | Date | Thu, 1 Mar 2007 00:41:11 -0800 | From | Andrew Morton <> | Subject | Re: [patch 03/22] fix deadlock in balance_dirty_pages |
| |
On Thu, 01 Mar 2007 09:37:06 +0100 Miklos Szeredi <miklos@szeredi.hu> wrote:
> > Sigh. What's this about i_mutex? That appears to be some critical > > information which _still_ isn't being communicated. > > > > This: > > ssize_t generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov, > unsigned long nr_segs, loff_t pos) > { > struct file *file = iocb->ki_filp; > struct address_space *mapping = file->f_mapping; > struct inode *inode = mapping->host; > ssize_t ret; > > BUG_ON(iocb->ki_pos != pos); > > mutex_lock(&inode->i_mutex); > ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs, > &iocb->ki_pos); > mutex_unlock(&inode->i_mutex); > > > It's in the stack trace. I thought it was obvious.
No, it is not obvious.
I'm just not going to apply weird hacks to work around a bug which I do not understand, and I have spent way too much time trying to understand this one.
So let us persist.
Please fully describe the role of i_mutex in this hang. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |