linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Barry Song <21cnbao@gmail.com>
To: Michal Hocko <mhocko@suse.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	 Barry Song <v-songbaohua@oppo.com>,
	Uladzislau Rezki <urezki@gmail.com>,
	 Christoph Hellwig <hch@infradead.org>,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	Christoph Lameter <cl@linux.com>,
	 Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	 Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	 Roman Gushchin <roman.gushchin@linux.dev>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>
Subject: Re: [PATCH RFC] mm: warn potential return NULL for kmalloc_array and kvmalloc_array with __GFP_NOFAIL
Date: Fri, 19 Jul 2024 12:35:55 +1200	[thread overview]
Message-ID: <CAGsJ_4wNre89_pQWvU0jj6reLaETYOTUVu3DYwPo8Up1DM1-8A@mail.gmail.com> (raw)
In-Reply-To: <ZpjXacbUGxTs9cR0@tiehlicka>

On Thu, Jul 18, 2024 at 8:50 PM Michal Hocko <mhocko@suse.com> wrote:
>
> On Thu 18-07-24 20:43:53, Barry Song wrote:
> > On Thu, Jul 18, 2024 at 8:32 PM Michal Hocko <mhocko@suse.com> wrote:
> > >
> > > On Thu 18-07-24 20:18:02, Barry Song wrote:
> > > > So the purpose is making sure the semantics - NOFAIL means no failure
> > > > and we don't need to check ret.  If we can't really succeed, it should throw
> > > > a BUG to stop any potential exploits.
> > >
> > > This would require to panic consistently on failure in all allocator
> > > path that can bail out. E.g. page allocator on GFP_NOWAIT|GFP_NOFAIL
> > > req. not sure how many more.
> >
> > Right, this GFP_NOFAIL issue seems quite messy. However, at least vmalloc
> > will retry by itself, even if alloc_pages might have failed with
> > GFP_NOWAIT | GFP_NOFAIL.
> >
> > But isn't that the definition of __GFP_NOFAIL?
> >
> >  * %__GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
> >  * cannot handle allocation failures. The allocation could block
> >  * indefinitely but will never return with failure. Testing for
> >  * failure is pointless."
> >
> > So I believe any code that doesn't retry and ends up returning NULL should be
> > fixed.
>
> Yes, those shouldn't really fail. NOWAIT|NOFAIL was something that
> should never happen and I really hope it doesn't. Others should really
> retry but it's been some time since I've checked the last time.


I assume allocations directly using alloc_pages() might not respect GFP_NOFAIL
and violate the semantics of GFP_NOFAIL.

static inline struct page *
__alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
                                                struct alloc_context *ac) {
        /*
         * Make sure that __GFP_NOFAIL request doesn't leak out and make sure
         * we always retry
         */
        if (gfp_mask & __GFP_NOFAIL) {
                /*
                 * All existing users of the __GFP_NOFAIL are blockable, so warn
                 * of any new users that actually require GFP_NOWAIT
                 */
                if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask))
                        goto fail;
...
}

Additionally, at least drivers/vdpa/vdpa_user/iova_domain.c is
incorrect with GFP_ATOMIC
| __GFP_NOFAIL.

void vduse_domain_remove_user_bounce_pages(struct vduse_iova_domain *domain)
{
        ...

        count = domain->bounce_size >> PAGE_SHIFT;
        for (i = 0; i < count; i++) {
                ...

                /* Copy user page to kernel page if it's in use */
                if (map->orig_phys != INVALID_PHYS_ADDR) {
                        page = alloc_page(GFP_ATOMIC | __GFP_NOFAIL);
                        memcpy_from_page(page_address(page),
                                         map->bounce_page, 0, PAGE_SIZE);
                }
                put_page(map->bounce_page);
                map->bounce_page = page;
        }
        domain->user_bounce_pages = false;
out:
        write_unlock(&domain->bounce_lock);
}

GFP_NOFAIL things need to be fixed. Let me investigate further.

>
> These overflow checks were added without any acks by MM people...
> --
> Michal Hocko
> SUSE Labs

Thanks
Barry


  reply	other threads:[~2024-07-19  0:36 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-17 23:00 Barry Song
2024-07-18  6:58 ` Michal Hocko
2024-07-18  7:04   ` Christoph Hellwig
2024-07-18  7:12     ` Michal Hocko
2024-07-18  8:16       ` Vlastimil Babka
2024-07-18  7:22   ` Barry Song
2024-07-18  7:27     ` Michal Hocko
2024-07-18  7:41       ` Barry Song
2024-07-18  7:53         ` Michal Hocko
2024-07-18  8:18           ` Barry Song
2024-07-18  8:32             ` Michal Hocko
2024-07-18  8:43               ` Barry Song
2024-07-18  8:50                 ` Michal Hocko
2024-07-19  0:35                   ` Barry Song [this message]
2024-07-19  7:02                     ` Michal Hocko
2024-07-19  7:07                       ` Barry Song
2024-07-19  7:42                         ` Michal Hocko
2024-07-19  7:51                           ` Barry Song
2024-07-19  8:01                             ` Michal Hocko
2024-07-19  8:28                               ` Barry Song
2024-07-19  8:40                                 ` Michal Hocko
2024-07-19  9:36                                   ` Barry Song
2024-07-19  9:45                                     ` Michal Hocko
2024-07-19  9:58                                       ` Barry Song
2024-07-19 10:57                                         ` Michal Hocko
2024-07-19 11:05                                           ` Barry Song
2024-07-19 11:19                                             ` Michal Hocko
2024-07-19  8:50                               ` Vlastimil Babka
2024-07-19  9:33                                 ` Michal Hocko
2024-07-19 10:10                                   ` Vlastimil Babka
2024-07-19 10:52                                     ` Michal Hocko
2024-07-19 11:13                                       ` Vlastimil Babka
2024-07-19 11:26                                         ` Michal Hocko
2024-07-19 13:02                                           ` Barry Song
2024-07-19 13:30                                             ` Michal Hocko
2024-07-20  0:36                                               ` Barry Song
2024-07-22  7:23                                                 ` Michal Hocko
2024-07-22  7:34                                                   ` Vlastimil Babka
2024-07-19  7:37                       ` Christoph Hellwig
2024-07-19  7:43                         ` Barry Song
2024-07-19  7:53                           ` Christoph Hellwig
2024-07-20 22:14                             ` Barry Song
2024-07-22  7:26                               ` Michal Hocko
2024-07-22  8:09                                 ` Barry Song
2024-07-22  9:01                                   ` Michal Hocko
2024-07-22 23:18                                     ` Christoph Hellwig
2024-07-22 23:22                                       ` Barry Song
2024-07-19  8:35                     ` Vlastimil Babka
2024-07-18  7:48 ` Hailong Liu
2024-07-18  8:33   ` Barry Song

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=CAGsJ_4wNre89_pQWvU0jj6reLaETYOTUVu3DYwPo8Up1DM1-8A@mail.gmail.com \
    --to=21cnbao@gmail.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=hch@infradead.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=mhocko@suse.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=urezki@gmail.com \
    --cc=v-songbaohua@oppo.com \
    --cc=vbabka@suse.cz \
    /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