On Wed 22-06-16 11:03:20, Dave Chinner wrote:
> On Tue, Jun 21, 2016 at 04:26:28PM +0200, Michal Hocko wrote:
> > On Wed 15-06-16 17:21:54, Dave Chinner wrote:
[...]
> > > There are allocations outside transaction context which need to be
> > > GFP_NOFS - this is what KM_NOFS was originally intended for.
> >
> > Is it feasible to mark those by the scope NOFS api as well and drop
> > the direct KM_NOFS usage? This should help to identify those that are
> > lockdep only and use the annotation to prevent from the false positives.
>
> I don't understand what you are suggesting here. This all started
> because we use GFP_NOFS in a handful of places to shut up lockdep
> and you didn't want us to use GFP_NOFS like that. Now it sounds to
> me like you are advocating setting unconditional GFP_NOFS allocation
> contexts for entire XFS code paths - whether it's necessary or
> not - to avoid problems with lockdep false positives.
No, I meant only those paths which need GFP_NOFS for other than lockdep
purposes would use the scope api.
Anyway, it seems that we are not getting closer to a desired solution
here. Or I am not following it at least...
It seems that we have effectively two possibilities (from the
MM/lockdep) POV. Either add an explicit API to disable the reclaim
lockdep machinery for all allocation in a certain scope or a GFP mask
to to achieve the same for a particular allocation. Which one would work
better for the xfs usecase?
--
Michal Hocko
SUSE Labs
|