xfs
[Top] [All Lists]

Re: [PATCH 05/14] xfs: fix missing KM_NOFS tags to keep lockdep happy

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: [PATCH 05/14] xfs: fix missing KM_NOFS tags to keep lockdep happy
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 21 May 2013 10:08:37 +1000
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130520211607.GC20028@xxxxxxx>
References: <1369007481-15185-1-git-send-email-david@xxxxxxxxxxxxx> <1369007481-15185-6-git-send-email-david@xxxxxxxxxxxxx> <20130520211607.GC20028@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, May 20, 2013 at 04:16:07PM -0500, Ben Myers wrote:
> On Mon, May 20, 2013 at 09:51:12AM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@xxxxxxxxxx>
> > 
> > There are several places where we use KM_SLEEP allocation contexts
> > and use the fact that there are called from transaction context to
>                       they
> 
> (fixed)
> 
> > add KM_NOFS where appropriate.
> 
> I think you're referring to the usage of PF_FSTRANS and us clearing __GFP_FS 
> in
> kmem_flags_convert?

Yes.

> > Unfortunately, there are several
> > places where the code makes this assumption but can be called from
> > outside transaction context but with filesystem locks held. These
> > places need explicit KM_NOFS annotations to avoid lockdep
> > complaining about reclaim contexts.
> > 
> > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>
> 
> Looks good.  In each case you added KM_NOFS where there was no transaction and
> locks would have been held.  Applied.
> 
> Reviewed-by: Ben Myers <bpm@xxxxxxx>

Thanks.

-Dave
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>