From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs@oss.sgi.com
Subject: Re: Pass mp to kmem_alloc and friends?
Date: Thu, 21 Jan 2016 07:32:11 +1100 [thread overview]
Message-ID: <20160120203211.GC20456@dastard> (raw)
In-Reply-To: <569FCAED.4050306@sandeen.net>
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
prev parent reply other threads:[~2016-01-20 20:32 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
2016-01-20 20:32 ` Dave Chinner [this message]
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=20160120203211.GC20456@dastard \
--to=david@fromorbit.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.