From: Barry Song <21cnbao@gmail.com>
To: akpm@linux-foundation.org, linux-mm@kvack.org
Cc: 42.hyeyoo@gmail.com, cl@linux.com, hch@infradead.org,
iamjoonsoo.kim@lge.com, lstoakes@gmail.com, mhocko@suse.com,
penberg@kernel.org, rientjes@google.com,
roman.gushchin@linux.dev, urezki@gmail.com,
v-songbaohua@oppo.com, vbabka@suse.cz,
virtualization@lists.linux.dev, hailong.liu@oppo.com,
torvalds@linux-foundation.org
Subject: [PATCH 0/5] mm: clarify nofail memory allocation
Date: Wed, 24 Jul 2024 20:55:39 +1200 [thread overview]
Message-ID: <20240724085544.299090-1-21cnbao@gmail.com> (raw)
From: Barry Song <v-songbaohua@oppo.com>
__GFP_NOFAIL carries the semantics of never failing, so its callers
do not check the return value:
%__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.
However, __GFP_NOFAIL can sometimes fail if it exceeds size limits
or is used with GFP_ATOMIC/GFP_NOWAIT in a non-sleepable context.
This can expose security vulnerabilities due to potential NULL
dereferences.
Since __GFP_NOFAIL does not support non-blocking allocation, we introduce
GFP_NOFAIL with inclusive blocking semantics and encourage using GFP_NOFAIL
as a replacement for __GFP_NOFAIL in non-mm.
If we must still fail a nofail allocation, we should trigger a BUG rather
than exposing NULL dereferences to callers who do not check the return
value.
* The discussion started from this topic:
[PATCH RFC] mm: warn potential return NULL for kmalloc_array and
kvmalloc_array with __GFP_NOFAIL
https://lore.kernel.org/linux-mm/20240717230025.77361-1-21cnbao@gmail.com/
Thank you to Michal, Christoph, Vlastimil, and Hailong for all the
comments.
Barry Song (5):
vpda: try to fix the potential crash due to misusing __GFP_NOFAIL
mm: Document __GFP_NOFAIL must be blockable
mm: BUG_ON to avoid NULL deference while __GFP_NOFAIL fails
mm: Introduce GFP_NOFAIL with the inclusion of __GFP_RECLAIM
non-mm: discourage the usage of __GFP_NOFAIL and encourage GFP_NOFAIL
arch/powerpc/sysdev/xive/common.c | 2 +-
drivers/gpu/drm/drm_modeset_lock.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_dmem.c | 8 +++----
drivers/gpu/drm/virtio/virtgpu_vq.c | 2 +-
drivers/hv/vmbus_drv.c | 2 +-
drivers/infiniband/hw/cxgb4/mem.c | 4 ++--
drivers/md/dm-region-hash.c | 2 +-
.../chelsio/inline_crypto/chtls/chtls_cm.c | 6 ++---
.../chelsio/inline_crypto/chtls/chtls_hw.c | 2 +-
drivers/target/iscsi/cxgbit/cxgbit_cm.c | 2 +-
drivers/tty/tty_ldisc.c | 2 +-
drivers/vdpa/vdpa_user/iova_domain.c | 24 +++++++++++++++----
fs/bcachefs/btree_iter.c | 2 +-
fs/bcachefs/fs-io-buffered.c | 2 +-
fs/bcachefs/io_write.c | 2 +-
fs/btrfs/extent_io.c | 8 +++----
fs/buffer.c | 6 ++---
fs/erofs/fscache.c | 2 +-
fs/erofs/zdata.c | 10 ++++----
fs/ext4/extents.c | 8 +++----
fs/ext4/extents_status.c | 4 ++--
fs/ext4/mballoc.c | 12 +++++-----
fs/ext4/page-io.c | 2 +-
fs/f2fs/checkpoint.c | 2 +-
fs/f2fs/data.c | 4 ++--
fs/f2fs/f2fs.h | 2 +-
fs/f2fs/node.c | 2 +-
fs/fuse/dev.c | 2 +-
fs/fuse/file.c | 4 ++--
fs/fuse/inode.c | 4 ++--
fs/fuse/virtio_fs.c | 4 ++--
fs/gfs2/meta_io.c | 2 +-
fs/gfs2/rgrp.c | 6 ++---
fs/gfs2/trans.c | 2 +-
fs/iomap/buffered-io.c | 2 +-
fs/jbd2/journal.c | 4 ++--
fs/jbd2/revoke.c | 2 +-
fs/jbd2/transaction.c | 6 ++---
fs/notify/fanotify/fanotify.c | 2 +-
fs/reiserfs/journal.c | 2 +-
fs/udf/directory.c | 2 +-
fs/xfs/libxfs/xfs_alloc.c | 2 +-
fs/xfs/libxfs/xfs_attr_leaf.c | 8 +++----
fs/xfs/libxfs/xfs_bmap.c | 2 +-
fs/xfs/libxfs/xfs_btree.h | 2 +-
fs/xfs/libxfs/xfs_btree_staging.c | 2 +-
fs/xfs/libxfs/xfs_da_btree.c | 8 +++----
fs/xfs/libxfs/xfs_defer.c | 4 ++--
fs/xfs/libxfs/xfs_dir2.c | 10 ++++----
fs/xfs/libxfs/xfs_dir2_block.c | 2 +-
fs/xfs/libxfs/xfs_dir2_sf.c | 8 +++----
fs/xfs/libxfs/xfs_exchmaps.c | 4 ++--
fs/xfs/libxfs/xfs_iext_tree.c | 4 ++--
fs/xfs/libxfs/xfs_inode_fork.c | 14 +++++------
fs/xfs/libxfs/xfs_refcount.c | 4 ++--
fs/xfs/libxfs/xfs_rmap.c | 2 +-
fs/xfs/xfs_attr_item.c | 8 +++----
fs/xfs/xfs_attr_list.c | 2 +-
fs/xfs/xfs_bmap_item.c | 6 ++---
fs/xfs/xfs_buf.c | 8 +++----
fs/xfs/xfs_buf_item.c | 4 ++--
fs/xfs/xfs_buf_item_recover.c | 2 +-
fs/xfs/xfs_dquot.c | 2 +-
fs/xfs/xfs_exchmaps_item.c | 4 ++--
fs/xfs/xfs_extent_busy.c | 2 +-
fs/xfs/xfs_extfree_item.c | 10 ++++----
fs/xfs/xfs_icache.c | 2 +-
fs/xfs/xfs_icreate_item.c | 2 +-
fs/xfs/xfs_inode_item.c | 2 +-
fs/xfs/xfs_inode_item_recover.c | 2 +-
fs/xfs/xfs_iunlink_item.c | 2 +-
fs/xfs/xfs_iwalk.c | 2 +-
fs/xfs/xfs_log.c | 2 +-
fs/xfs/xfs_log_cil.c | 2 +-
fs/xfs/xfs_log_recover.c | 6 ++---
fs/xfs/xfs_mount.c | 2 +-
fs/xfs/xfs_mru_cache.c | 4 ++--
fs/xfs/xfs_qm.c | 4 ++--
fs/xfs/xfs_refcount_item.c | 8 +++----
fs/xfs/xfs_rmap_item.c | 8 +++----
fs/xfs/xfs_rtalloc.c | 2 +-
fs/xfs/xfs_super.c | 2 +-
fs/xfs/xfs_trans.c | 4 ++--
fs/xfs/xfs_trans_dquot.c | 2 +-
include/linux/buffer_head.h | 4 ++--
include/linux/gfp_types.h | 7 ++++++
include/linux/slab.h | 4 +++-
kernel/resource.c | 2 +-
lib/list-test.c | 8 +++----
lib/ref_tracker.c | 2 +-
lib/rhashtable.c | 6 ++---
lib/test_hmm.c | 6 ++---
mm/page_alloc.c | 10 ++++----
mm/util.c | 1 +
net/ceph/osd_client.c | 2 +-
net/ceph/osdmap.c | 4 ++--
net/core/sock.c | 4 ++--
net/ipv4/inet_connection_sock.c | 2 +-
net/ipv4/tcp_output.c | 2 +-
security/smack/smackfs.c | 2 +-
100 files changed, 222 insertions(+), 196 deletions(-)
--
2.34.1
next reply other threads:[~2024-07-24 8:56 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-24 8:55 Barry Song [this message]
2024-07-24 8:55 ` [PATCH RFC 1/5] vpda: try to fix the potential crash due to misusing __GFP_NOFAIL Barry Song
2024-07-24 12:26 ` Michal Hocko
2024-07-24 22:50 ` Barry Song
2024-07-25 6:08 ` Michal Hocko
2024-07-25 7:00 ` Barry Song
2024-07-29 3:42 ` Jason Wang
2024-07-29 6:05 ` Barry Song
[not found] ` <CACGkMEuv4M_NaUQPHH59MPevGoJJoYb70LykcCODD=nUvik3ZQ@mail.gmail.com>
2024-07-30 3:08 ` Barry Song
2024-07-24 8:55 ` [PATCH 2/5] mm: Document __GFP_NOFAIL must be blockable Barry Song
2024-07-24 11:58 ` Michal Hocko
2024-08-03 23:09 ` Davidlohr Bueso
2024-07-24 8:55 ` [PATCH 3/5] mm: BUG_ON to avoid NULL deference while __GFP_NOFAIL fails Barry Song
2024-07-24 10:03 ` Vlastimil Babka
2024-07-24 10:11 ` Barry Song
2024-07-24 12:10 ` Michal Hocko
2024-07-24 8:55 ` [PATCH 4/5] mm: Introduce GFP_NOFAIL with the inclusion of __GFP_RECLAIM Barry Song
2024-07-24 12:12 ` Michal Hocko
2024-07-24 8:55 ` [PATCH RFC 5/5] non-mm: discourage the usage of __GFP_NOFAIL and encourage GFP_NOFAIL Barry Song
2024-07-24 9:53 ` Vlastimil Babka
2024-07-24 9:58 ` Barry Song
2024-07-24 13:14 ` Christoph Hellwig
2024-07-24 12:25 ` Michal Hocko
2024-07-24 13:13 ` Christoph Hellwig
2024-07-24 13:21 ` Michal Hocko
2024-07-24 13:23 ` Christoph Hellwig
2024-07-24 13:31 ` Michal Hocko
2024-07-24 13:33 ` Vlastimil Babka
2024-07-24 13:38 ` Christoph Hellwig
2024-07-24 13:47 ` Michal Hocko
2024-07-24 13:55 ` Christoph Hellwig
2024-07-24 14:39 ` Vlastimil Babka
2024-07-24 14:41 ` Christoph Hellwig
2024-07-25 1:47 ` Barry Song
2024-07-29 9:56 ` Barry Song
2024-07-29 10:03 ` Vlastimil Babka
2024-07-29 10:16 ` Barry Song
2024-07-24 12:17 ` Michal Hocko
2024-07-25 1:38 ` Barry Song
2024-07-25 6:16 ` Michal Hocko
2024-07-26 21:08 ` Davidlohr Bueso
2024-07-29 11:50 ` Michal Hocko
2024-08-03 22:15 ` Davidlohr Bueso
2024-08-05 7:49 ` 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=20240724085544.299090-1-21cnbao@gmail.com \
--to=21cnbao@gmail.com \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=hailong.liu@oppo.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=torvalds@linux-foundation.org \
--cc=urezki@gmail.com \
--cc=v-songbaohua@oppo.com \
--cc=vbabka@suse.cz \
--cc=virtualization@lists.linux.dev \
/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