Pass mp to kmem_alloc and friends?

Pass mp to kmem_alloc and friends?

[Eric Sandeen]

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? :)

-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Pass mp to kmem_alloc and friends?

[Darrick J. Wong]

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@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Pass mp to kmem_alloc and friends?

[Dave Chinner]

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 I hinted at this in the configurable error handling patchset
I have so that we could have configurable ENOMEM error handling. My
comment in the current commit message for that patch includes this:

| I'm not yet sure how to hook it into the memory allocation calls -
| that will be done in a later patch; this just demonstrates how
| multiple classes are configured and initialised. It may be that we
| don't configure specific errors here - instead configure how we
| handle specific types of allocation failure e.g. GFP_KERNEL vs
| GFP_NOFS vs allocations inside transactions. Either way, we are
| going to need to plumb the error config handler into the
| memory allocation code in some manner.

So I think we are going to have to plumb the xfs_mount into these
calls at some point in the near future.

> 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)

If we want more context, then make it an error message that can dump
the stack when the error level is turned up. i.e. if we pass in an
xfs_mount, we can use XFS_ERROR_REPORT here...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Pass mp to kmem_alloc and friends?

[Dave Chinner]

On Wed, Jan 20, 2016 at 11:53:54AM -0800, Darrick J. Wong wrote:
> 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)

Problem with that is the the return address will often just point to
a higher level wrapper function, and we are still without any
caller context. e.g. if we find the caller is xfs_buf_alloc_maps(),
what operation was being performed that needed a new buffer
allocated?

IMO, the only thing that will actually be useful for debugging at
this point is a full stack dump....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs