On Wed 15-06-16 17:21:54, Dave Chinner wrote:
[...]

Hopefully you can see the complexity of the issue - for an allocation
in the bmap btree code that could occur outside both inside and
outside of a transaction context, we've got to work out which of
those ~60 high level entry points would need to be annotated. And
then we have to ensure that in future we don't miss adding or
removing an annotation as we change the code deep inside the btree
implementation. It's the latter that is the long term maintainence
problem the hihg-level annotation approach introduces.

Sure I can see the complexity here. I might still see this over
simplified but I originally thought that the annotation would be used at
the highest level which never gets called from the transaction or other
NOFS context. So all the layers down would inherit that automatically. I
guess that such a place can be identified from the lockdep report by a
trained eye.
 

quoted

quoted

I think such an annotation approach really requires per-alloc site
annotation, the reason for it should be more obvious from the
context. e.g. any function that does memory alloc and takes an
optional transaction context needs annotation. Hence, from an XFS
perspective, I think it makes more sense to add a new KM_ flag to
indicate this call site requirement, then jump through whatever
lockdep hoop is required within the kmem_* allocation wrappers.
e.g, we can ignore the new KM_* flag if we are in a transaction
context and so the flag is only activated in the situations were
we currently enforce an external GFP_NOFS context from the call
site.....

Hmm, I thought we would achive this by using the scope GFP_NOFS usage
which would mark those transaction related conctexts and no lockdep
specific workarounds would be needed...

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.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>