From: Nikolay Borisov <n.borisov.lkml@gmail.com>
To: Trond Myklebust <trondmy@primarydata.com>,
"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [GIT PULL] Please pull NFS client fixes for 4.12
Date: Thu, 11 May 2017 10:53:27 +0300 [thread overview]
Message-ID: <be16be57-235c-fdf9-f708-3898aeeeb5aa@gmail.com> (raw)
In-Reply-To: <1494434821.4764.1.camel@primarydata.com>
On 10.05.2017 19:47, Trond Myklebust wrote:
> Hi Linus,
>
> The following changes since commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3:
>
> Linux 4.11-rc7 (2017-04-16 13:00:18 -0700)
>
> are available in the git repository at:
>
> git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.12-1
>
> for you to fetch changes up to 76b2a303384e1d6299c3a0249f0f0ce2f8f96017:
>
> pNFS/flexfiles: Always attempt to call layoutstats when flexfiles is enabled (2017-05-09 16:02:57 -0400)
>
> ----------------------------------------------------------------
> NFS client updates for Linux 4.12
>
> Highlights include:
>
> Stable bugfixes:
> - Fix use after free in write error path
> - Use GFP_NOIO for two allocations in writeback
> - Fix a hang in OPEN related to server reboot
> - Check the result of nfs4_pnfs_ds_connect
> - Fix an rcu lock leak
>
> Features:
> - Removal of the unmaintained and unused OSD pNFS layout
> - Cleanup and removal of lots of unnecessary dprintk()s
> - Cleanup and removal of some memory failure paths now that
> GFP_NOFS is guaranteed to never fail.
What guarantees that? Since if this is the case then this can result in
a lot of opportunities for cleanup across the whole kernel tree. After
discussing with mhocko (cc'ed) it seems that in practice everything
below COSTLY_ORDER which are not GFP_NORETRY will never fail. But this
semantic is not the same as GFP_NOFAIL. E.g. nothing guarantees that
this will stay like that in the future?
[omitted for brevity]
next prev parent reply other threads:[~2017-05-11 7:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-10 16:47 [GIT PULL] Please pull NFS client fixes for 4.12 Trond Myklebust
2017-05-10 20:06 ` Linus Torvalds
2017-05-11 7:53 ` Nikolay Borisov [this message]
2017-05-11 7:59 ` Michal Hocko
2017-05-11 12:16 ` Trond Myklebust
2017-05-11 12:26 ` Michal Hocko
2017-05-11 12:45 ` Trond Myklebust
2017-05-11 12:56 ` Michal Hocko
2017-05-11 13:10 ` Trond Myklebust
2017-05-11 13:27 ` Michal Hocko
2017-05-16 15:15 ` Jonathan Corbet
2017-05-11 13:41 ` Trond Myklebust
2017-05-11 13:54 ` Michal Hocko
-- strict thread matches above, loose matches on Subject: below --
2017-06-28 14:19 Trond Myklebust
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=be16be57-235c-fdf9-f708-3898aeeeb5aa@gmail.com \
--to=n.borisov.lkml@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=torvalds@linux-foundation.org \
--cc=trondmy@primarydata.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 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).