Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1639361

Re: [GIT PULL] Please pull NFS client fixes for 4.12

From Michal Hocko <mhocko@kernel.org>
Newsgroups linux.kernel
Subject Re: [GIT PULL] Please pull NFS client fixes for 4.12
Date 2017-05-11 14:30 +0200
Message-ID <tFVod-6fr-15@gated-at.bofh.it> (permalink)
References <tFCYh-34M-1@gated-at.bofh.it> <tFRaV-3wD-1@gated-at.bofh.it> <tFRaW-3wD-17@gated-at.bofh.it> <tFVez-6c7-31@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu 11-05-17 12:16:37, Trond Myklebust wrote:
> On Thu, 2017-05-11 at 09:59 +0200, Michal Hocko wrote:
> > On Thu 11-05-17 10:53:27, Nikolay Borisov wrote:
> > > 
> > > 
> > > On 10.05.2017 19:47, Trond Myklebust wrote:
> > 
> > [...]
> > > > - 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?
> > 
> > In practice it is hard to change the semantic of small allocations
> > never
> > fail _practically_. But this is absolutely not guaranteed! They can
> > fail
> > e.g. when the allocation context is the oom victim. Removing error
> > paths
> > for allocation failures is just wrong.
> 
> OK, this makes no fucking sense at all.
> 
> Either allocations can fail or they can't.
> 1) If they can't fail, then we don't need the checks.
> 2) If they can fail, then we do need them, and this hand wringing in
> the MM community about GFP_* semantics and how we need to prevent
> failure is fucking pointless.

everything which is not __GFP_NOFAIL might fail. We try hard not to fail
small allocations requests as much as we can in general but you _have_ to
check for failures. There is simply no way to guarantee "never fail"
semantic for all allocation requests. This has been like that basically
since years. And even this try-to-be-nofailing for small allocations has
been PITA for some corner cases.

-- 
Michal Hocko
SUSE Labs

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[GIT PULL] Please pull NFS client fixes for 4.12 Trond Myklebust <trondmy@primarydata.com> - 2017-05-10 18:50 +0200
  Re: [GIT PULL] Please pull NFS client fixes for 4.12 Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-10 22:10 +0200
  Re: [GIT PULL] Please pull NFS client fixes for 4.12 Nikolay Borisov <n.borisov.lkml@gmail.com> - 2017-05-11 10:00 +0200
    Re: [GIT PULL] Please pull NFS client fixes for 4.12 Michal Hocko <mhocko@kernel.org> - 2017-05-11 10:00 +0200
      Re: [GIT PULL] Please pull NFS client fixes for 4.12 Trond Myklebust <trondmy@primarydata.com> - 2017-05-11 14:20 +0200
        Re: [GIT PULL] Please pull NFS client fixes for 4.12 Michal Hocko <mhocko@kernel.org> - 2017-05-11 14:30 +0200
          Re: [GIT PULL] Please pull NFS client fixes for 4.12 Trond Myklebust <trondmy@primarydata.com> - 2017-05-11 14:50 +0200
            Re: [GIT PULL] Please pull NFS client fixes for 4.12 Michal Hocko <mhocko@kernel.org> - 2017-05-11 15:00 +0200
              Re: [GIT PULL] Please pull NFS client fixes for 4.12 Trond Myklebust <trondmy@primarydata.com> - 2017-05-11 15:20 +0200
                Re: [GIT PULL] Please pull NFS client fixes for 4.12 Michal Hocko <mhocko@kernel.org> - 2017-05-11 15:30 +0200
    Re: [GIT PULL] Please pull NFS client fixes for 4.12 Trond Myklebust <trondmy@primarydata.com> - 2017-05-11 15:50 +0200
      Re: [GIT PULL] Please pull NFS client fixes for 4.12 Michal Hocko <mhocko@kernel.org> - 2017-05-11 16:00 +0200

csiph-web