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
|