On Wed, Jan 20, 2016 at 11:59:09AM -0600, Eric Sandeen wrote: > I had a request for the kmem_alloc deadlock warning to print the > filesystem involved. > > Any objections to passing mp into kmem_alloc() and friends whenever > it's reasonably available from the caller? > > It'd be a big mechanical change, don't want to embark on that unless > it seems acceptable & useful. > > I think we generally know the root causes of the most common deadlock > warnings, but it's a warm fuzzy to give as much info as possible. > > Heck, I almost wonder if passing a descriptive string in, for at > least the problematic cases we know about, i.e. "extent map realloc" > so we'd get something like: > > XFS (sdb1): myprocess(123) possible memory allocation deadlock size 12345 during extent map realloc in kmem_alloc (mode:0x250) > > I dunno ... too much? :) Not enough? What about putting in just enough macro madness to report the name & line number of the calling function in the message? XFS (sdb1): myprocess(123) possible kmem_alloc deadlock in xfs_eat_my_data.c:5135 (size:12345 mode:0x250) (or maybe a tracepoint?) --D > > -Eric > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
