All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	LKML <linux-kernel@vger.kernel.org>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Steven Whitehouse <swhiteho@redhat.com>,
	Bob Peterson <rpeterso@redhat.com>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	Anna Schumaker <anna.schumaker@netapp.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	Mikulas Patocka <mpatocka@redhat.com>,
	linux-mtd@lists.infradead.org, linux-ext4@vger.kernel.org,
	cluster-devel@redhat.com, linux-nfs@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: vmalloc with GFP_NOFS
Date: Thu, 10 May 2018 07:58:25 +0200	[thread overview]
Message-ID: <20180510055825.GB32366@dhcp22.suse.cz> (raw)
In-Reply-To: <20180509220231.GD25312@magnolia>

On Wed 09-05-18 15:02:31, Darrick J. Wong wrote:
> On Wed, May 09, 2018 at 11:04:47PM +0200, Michal Hocko wrote:
> > On Wed 09-05-18 08:13:51, Darrick J. Wong wrote:
[...]
> > > > FS resp. IO submitting code paths have to be careful when allocating
> > > 
> > > Not sure what 'FS resp. IO' means here -- 'FS and IO' ?
> > > 
> > > (Or is this one of those things where this looks like plain English text
> > > but in reality it's some sort of markup that I'm not so familiar with?)
> > > 
> > > Confused because I've seen 'resp.' used as shorthand for
> > > 'responsible'...
> > 
> > Well, I've tried to cover both. Filesystem and IO code paths which
> > allocate while in sensitive context. IO submission is kinda clear but I
> > am not sure what a general term for filsystem code paths would be. I
> > would be greatful for any hints here.
> 
> "Code paths in the filesystem and IO stacks must be careful when
> allocating memory to prevent recursion deadlocks caused by direct memory
> reclaim calling back into the FS or IO paths and blocking on already
> held resources (e.g. locks)." ?

Great, thanks!
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	LKML <linux-kernel@vger.kernel.org>,
	Artem Bityutskiy <dedekind1@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	David Woodhouse <dwmw2@infradead.org>,
	Brian Norris <computersforpeace@gmail.com>,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Marek Vasut <marek.vasut@gmail.com>,
	Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Steven Whitehouse <swhiteho@redhat.com>,
	Bob Peterson <rpeterso@redhat.com>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	Anna Schumaker <anna.schumaker@netapp.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Philippe Ombredanne <pombredanne@nexb.com>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	Mikulas Patocka <mpatocka@redhat.com>,
Subject: Re: vmalloc with GFP_NOFS
Date: Thu, 10 May 2018 07:58:25 +0200	[thread overview]
Message-ID: <20180510055825.GB32366@dhcp22.suse.cz> (raw)
In-Reply-To: <20180509220231.GD25312@magnolia>

On Wed 09-05-18 15:02:31, Darrick J. Wong wrote:
> On Wed, May 09, 2018 at 11:04:47PM +0200, Michal Hocko wrote:
> > On Wed 09-05-18 08:13:51, Darrick J. Wong wrote:
[...]
> > > > FS resp. IO submitting code paths have to be careful when allocating
> > > 
> > > Not sure what 'FS resp. IO' means here -- 'FS and IO' ?
> > > 
> > > (Or is this one of those things where this looks like plain English text
> > > but in reality it's some sort of markup that I'm not so familiar with?)
> > > 
> > > Confused because I've seen 'resp.' used as shorthand for
> > > 'responsible'...
> > 
> > Well, I've tried to cover both. Filesystem and IO code paths which
> > allocate while in sensitive context. IO submission is kinda clear but I
> > am not sure what a general term for filsystem code paths would be. I
> > would be greatful for any hints here.
> 
> "Code paths in the filesystem and IO stacks must be careful when
> allocating memory to prevent recursion deadlocks caused by direct memory
> reclaim calling back into the FS or IO paths and blocking on already
> held resources (e.g. locks)." ?

Great, thanks!
-- 
Michal Hocko
SUSE Labs

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] vmalloc with GFP_NOFS
Date: Thu, 10 May 2018 07:58:25 +0200	[thread overview]
Message-ID: <20180510055825.GB32366@dhcp22.suse.cz> (raw)
In-Reply-To: <20180509220231.GD25312@magnolia>

On Wed 09-05-18 15:02:31, Darrick J. Wong wrote:
> On Wed, May 09, 2018 at 11:04:47PM +0200, Michal Hocko wrote:
> > On Wed 09-05-18 08:13:51, Darrick J. Wong wrote:
[...]
> > > > FS resp. IO submitting code paths have to be careful when allocating
> > > 
> > > Not sure what 'FS resp. IO' means here -- 'FS and IO' ?
> > > 
> > > (Or is this one of those things where this looks like plain English text
> > > but in reality it's some sort of markup that I'm not so familiar with?)
> > > 
> > > Confused because I've seen 'resp.' used as shorthand for
> > > 'responsible'...
> > 
> > Well, I've tried to cover both. Filesystem and IO code paths which
> > allocate while in sensitive context. IO submission is kinda clear but I
> > am not sure what a general term for filsystem code paths would be. I
> > would be greatful for any hints here.
> 
> "Code paths in the filesystem and IO stacks must be careful when
> allocating memory to prevent recursion deadlocks caused by direct memory
> reclaim calling back into the FS or IO paths and blocking on already
> held resources (e.g. locks)." ?

Great, thanks!
-- 
Michal Hocko
SUSE Labs



  reply	other threads:[~2018-05-10  5:58 UTC|newest]

Thread overview: 127+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-24 16:27 vmalloc with GFP_NOFS Michal Hocko
2018-04-24 16:27 ` [Cluster-devel] " Michal Hocko
2018-04-24 16:27 ` Michal Hocko
2018-04-24 16:27 ` Michal Hocko
2018-04-24 16:46 ` Mikulas Patocka
2018-04-24 16:46   ` [Cluster-devel] " Mikulas Patocka
2018-04-24 16:46   ` Mikulas Patocka
2018-04-24 16:55   ` Michal Hocko
2018-04-24 16:55     ` [Cluster-devel] " Michal Hocko
2018-04-24 16:55     ` Michal Hocko
2018-04-24 17:05     ` Mikulas Patocka
2018-04-24 17:05       ` [Cluster-devel] " Mikulas Patocka
2018-04-24 17:05       ` Mikulas Patocka
2018-04-24 18:35 ` Theodore Y. Ts'o
2018-04-24 18:35   ` [Cluster-devel] " Theodore Y. Ts'o
2018-04-24 18:35   ` Theodore Y. Ts'o
2018-04-24 19:25   ` Michal Hocko
2018-04-24 19:25     ` [Cluster-devel] " Michal Hocko
2018-04-24 19:25     ` Michal Hocko
2018-05-09 13:42     ` Michal Hocko
2018-05-09 13:42       ` [Cluster-devel] " Michal Hocko
2018-05-09 13:42       ` Michal Hocko
2018-05-09 14:13       ` David Sterba
2018-05-09 14:13         ` [Cluster-devel] " David Sterba
2018-05-09 14:13         ` David Sterba
2018-05-09 15:13       ` Darrick J. Wong
2018-05-09 15:13         ` [Cluster-devel] " Darrick J. Wong
2018-05-09 15:13         ` Darrick J. Wong
2018-05-09 16:24         ` Mike Rapoport
2018-05-09 16:24           ` [Cluster-devel] " Mike Rapoport
2018-05-09 16:24           ` Mike Rapoport
2018-05-09 21:06           ` Michal Hocko
2018-05-09 21:06             ` [Cluster-devel] " Michal Hocko
2018-05-09 21:06             ` Michal Hocko
2018-05-09 21:04         ` Michal Hocko
2018-05-09 21:04           ` [Cluster-devel] " Michal Hocko
2018-05-09 21:04           ` Michal Hocko
2018-05-09 22:02           ` Darrick J. Wong
2018-05-09 22:02             ` [Cluster-devel] " Darrick J. Wong
2018-05-09 22:02             ` Darrick J. Wong
2018-05-10  5:58             ` Michal Hocko [this message]
2018-05-10  5:58               ` [Cluster-devel] " Michal Hocko
2018-05-10  5:58               ` Michal Hocko
2018-05-10  7:18               ` Michal Hocko
2018-05-10  7:18                 ` [Cluster-devel] " Michal Hocko
2018-05-10  7:18                 ` Michal Hocko
2018-05-24 11:43   ` [PATCH] doc: document scope NOFS, NOIO APIs Michal Hocko
2018-05-24 11:43     ` Michal Hocko
2018-05-24 14:33     ` Shakeel Butt
2018-05-24 14:47       ` Michal Hocko
2018-05-24 16:37     ` Randy Dunlap
2018-05-25  7:52       ` Michal Hocko
2018-05-28  7:21         ` Nikolay Borisov
2018-05-29  8:22           ` Michal Hocko
2018-05-28 11:32         ` Vlastimil Babka
2018-05-24 20:52     ` Jonathan Corbet
2018-05-24 20:52       ` Jonathan Corbet
2018-05-25  8:11       ` Michal Hocko
2018-05-24 22:17     ` Dave Chinner
2018-05-24 23:25       ` Theodore Y. Ts'o
2018-05-25  8:16       ` Michal Hocko
2018-05-27 12:47         ` Mike Rapoport
2018-05-28  9:21           ` Michal Hocko
2018-05-28 16:10             ` Randy Dunlap
2018-05-29  8:21               ` Michal Hocko
2018-05-27 23:48         ` Dave Chinner
2018-05-28  9:19           ` Michal Hocko
2018-05-28 22:32             ` Dave Chinner
2018-05-29  8:18               ` Michal Hocko
2018-05-29  8:26     ` [PATCH v2] " Michal Hocko
2018-05-29  8:26       ` Michal Hocko
2018-05-29 10:22       ` Dave Chinner
2018-05-29 11:50       ` Mike Rapoport
2018-05-29 11:51       ` Jonathan Corbet
2018-05-29 11:51         ` Jonathan Corbet
2018-05-29 12:37         ` Michal Hocko
2018-07-17 12:49   ` vmalloc with GFP_NOFS Michal Hocko
2018-07-17 12:49     ` [Cluster-devel] " Michal Hocko
2018-07-17 12:49     ` Michal Hocko
2018-04-24 19:03 ` Richard Weinberger
2018-04-24 19:03   ` [Cluster-devel] " Richard Weinberger
2018-04-24 19:03   ` Richard Weinberger
2018-04-24 19:28   ` Michal Hocko
2018-04-24 19:28     ` [Cluster-devel] " Michal Hocko
2018-04-24 19:28     ` Michal Hocko
2018-04-24 22:18     ` Richard Weinberger
2018-04-24 22:18       ` [Cluster-devel] " Richard Weinberger
2018-04-24 22:18       ` Richard Weinberger
2018-04-24 23:09       ` Michal Hocko
2018-04-24 23:09         ` [Cluster-devel] " Michal Hocko
2018-04-24 23:09         ` Michal Hocko
2018-04-24 23:17         ` Mikulas Patocka
2018-04-24 23:17           ` [Cluster-devel] " Mikulas Patocka
2018-04-24 23:17           ` Mikulas Patocka
2018-04-24 23:25           ` Michal Hocko
2018-04-24 23:25             ` [Cluster-devel] " Michal Hocko
2018-04-24 23:25             ` Michal Hocko
2018-04-25 12:43             ` Mikulas Patocka
2018-04-25 12:43               ` [Cluster-devel] " Mikulas Patocka
2018-04-25 12:43               ` Mikulas Patocka
2018-04-25 14:45               ` Michal Hocko
2018-04-25 14:45                 ` [Cluster-devel] " Michal Hocko
2018-04-25 14:45                 ` Michal Hocko
2018-04-25 15:25                 ` Mikulas Patocka
2018-04-25 15:25                   ` [Cluster-devel] " Mikulas Patocka
2018-04-25 15:25                   ` Mikulas Patocka
2018-04-25 16:56                   ` Michal Hocko
2018-04-25 16:56                     ` [Cluster-devel] " Michal Hocko
2018-04-25 16:56                     ` Michal Hocko
2018-07-17 12:47   ` Michal Hocko
2018-07-17 12:47     ` [Cluster-devel] " Michal Hocko
2018-07-17 12:47     ` Michal Hocko
2018-04-24 19:05 ` Richard Weinberger
2018-04-24 19:05   ` [Cluster-devel] " Richard Weinberger
2018-04-24 19:05   ` Richard Weinberger
2018-04-24 19:10 ` Richard Weinberger
2018-04-24 19:10   ` [Cluster-devel] " Richard Weinberger
2018-04-24 19:10   ` Richard Weinberger
2018-04-24 19:26 ` Steven Whitehouse
2018-04-24 19:26   ` [Cluster-devel] " Steven Whitehouse
2018-04-24 19:26   ` Steven Whitehouse
2018-04-24 20:09   ` Michal Hocko
2018-04-24 20:09     ` [Cluster-devel] " Michal Hocko
2018-04-24 20:09     ` Michal Hocko
2018-07-17 12:50     ` Michal Hocko
2018-07-17 12:50       ` [Cluster-devel] " Michal Hocko
2018-07-17 12:50       ` Michal Hocko

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=20180510055825.GB32366@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=adilger.kernel@dilger.ca \
    --cc=adrian.hunter@intel.com \
    --cc=anna.schumaker@netapp.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=cluster-devel@redhat.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@wedev4u.fr \
    --cc=darrick.wong@oracle.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=marek.vasut@gmail.com \
    --cc=mpatocka@redhat.com \
    --cc=pombredanne@nexb.com \
    --cc=richard@nod.at \
    --cc=rpeterso@redhat.com \
    --cc=swhiteho@redhat.com \
    --cc=trond.myklebust@primarydata.com \
    --cc=tytso@mit.edu \
    /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.