From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: Pass mp to kmem_alloc and friends?
Date: Thu, 21 Jan 2016 07:35:03 +1100 [thread overview]
Message-ID: <20160120203503.GD20456@dastard> (raw)
In-Reply-To: <20160120195354.GA5500@birch.djwong.org>
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
next prev parent reply other threads:[~2016-01-20 20:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-20 17:59 Pass mp to kmem_alloc and friends? Eric Sandeen
2016-01-20 19:53 ` Darrick J. Wong
2016-01-20 20:35 ` Dave Chinner [this message]
2016-01-20 20:32 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160120203503.GD20456@dastard \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.