From: Jason Gunthorpe <jgg@ziepe.ca>
To: Michal Hocko <mhocko@kernel.org>
Cc: Matthew Wilcox <willy@infradead.org>,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Jeff Layton <jlayton@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Luis Henriques <lhenriques@suse.com>,
Christoph Hellwig <hch@lst.de>,
Carlos Maiolino <cmaiolino@redhat.com>
Subject: Re: [PATCH] mm: Make kvfree safe to call
Date: Mon, 29 Jul 2019 10:42:17 -0300 [thread overview]
Message-ID: <20190729134217.GA17990@ziepe.ca> (raw)
In-Reply-To: <20190729092830.GB10926@dhcp22.suse.cz>
On Mon, Jul 29, 2019 at 11:28:30AM +0200, Michal Hocko wrote:
> On Fri 26-07-19 14:01:37, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > Since vfree() can sleep, calling kvfree() from contexts where sleeping
> > is not permitted (eg holding a spinlock) is a bit of a lottery whether
> > it'll work. Introduce kvfree_safe() for situations where we know we can
> > sleep, but make kvfree() safe by default.
>
> So now you have converted all kvfree callers to an atomic version. Is
> that really desirable? Aren't we adding way too much work to be done in
> a deferred context? If not then why a regular vfree cannot do this
> already and then we do not need vfree_atomic and kvfree_safe.
I know infiniband has kvfree calls under user control, mayne uses of
kvfree are related to allocating kernel memory for some potentially
large user data on the syscall path..
I'm also nervous about making them all queuing.
If we added kvfree_atomic() & a warning how many places would hit the
warning and need conversion?
Jason
prev parent reply other threads:[~2019-07-29 13:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-26 21:01 [PATCH] mm: Make kvfree safe to call Matthew Wilcox
2019-07-26 21:10 ` Alexander Duyck
2019-07-26 21:25 ` Jeff Layton
2019-07-27 0:38 ` Matthew Wilcox
2019-07-27 14:54 ` Jeff Layton
2019-07-29 9:28 ` Michal Hocko
2019-07-29 13:42 ` Jason Gunthorpe [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=20190729134217.GA17990@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=akpm@linux-foundation.org \
--cc=cmaiolino@redhat.com \
--cc=hch@lst.de \
--cc=jlayton@kernel.org \
--cc=lhenriques@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).