Re: Crash with 3.8.3 and TuxOnIce

Dave Chinner
2013-03-28T00:51:21Z

On Wed, Mar 27, 2013 at 09:58:43PM +0000, Pedro Ribeiro wrote:
> Hi Dave (and others),
>
> I've pretty much established the responsible: commit
> 437a255aa23766666aec78af63be4c253faa8d57
> (
> http://git.kernel.org/cgit/linux/kernel/git/stable/stable-queue.git/tree/releases/3.7.2/xfs-fix-direct-io-nested-transaction-deadlock.patch?id=HEAD
> ).

Seems completely unrelated to the problem you saw.

> Without this patch, the computer does not lock up in hibernate. So I
> understand that this is most likely a bug in ToI, not in xfs. Does this
> give you a better idea of how to solve the problem?

No.

> The only xfs-specific
> patch in ToI is below:
>
> diff --git a/fs/xfs/xfs_trans_ail.c b/fs/xfs/xfs_trans_ail.c
> index 0eda725..55de808 100644
> --- a/fs/xfs/xfs_trans_ail.c
> +++ b/fs/xfs/xfs_trans_ail.c
> @@ -511,6 +511,7 @@ xfsaild(
> struct xfs_ail *ailp = data;
> long tout = 0; /* milliseconds */
>
> + set_freezable();
> current->flags |= PF_MEMALLOC;

We do not ever set the PF_NOFREEZE, so set_freezable() is a no-op.
If ToI has introduced new freeze API dependencies, then I'm not
going to try to understand or fix them.

> while (!kthread_should_stop()) {
>
> Looking at the code blindly, it appears to be similar to what goes on in
> other filesystems...

That loop has a call to try_to_freeze() in it, which is how such
kthreads are supposed to handle freezing. i.e. once they enter a
state in which they can freeze, they call try_to_freeze() and then
get moved to the refrigerator.

You need to talk to the ToI developers...

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com