From: Baoquan He <bhe@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hch@lst.de,
cl@linux.com, 42.hyeyoo@gmail.com, penberg@kernel.org,
rientjes@google.com, iamjoonsoo.kim@lge.com, vbabka@suse.cz,
David.Laight@ACULAB.COM, david@redhat.com,
herbert@gondor.apana.org.au, davem@davemloft.net,
linux-crypto@vger.kernel.org, steffen.klassert@secunet.com,
netdev@vger.kernel.org, hca@linux.ibm.com, gor@linux.ibm.com,
agordeev@linux.ibm.com, borntraeger@linux.ibm.com,
svens@linux.ibm.com, linux-s390@vger.kernel.org,
michael@walle.cc, linux-i2c@vger.kernel.org, wsa@kernel.org
Subject: [PATCH 00/22] Don't use kmalloc() with GFP_DMA
Date: Sat, 19 Feb 2022 08:51:59 +0800 [thread overview]
Message-ID: <20220219005221.634-1-bhe@redhat.com> (raw)
Let's replace it with other ways. This is the first step towards
removing dma-kmalloc support in kernel (Means that if everyting
is going well, we can't use kmalloc(GFP_DMA) to allocate buffer in the
future).
This series includes below changes which are easier to recognise and
make.
1) Remove GFP_DMA from dma_alloc_wc/noncoherent(), dma_pool_alloc(),
and dmam_alloc_coherent() which are redundant to specify GFP_DMA when
calling.
2) Replace kmalloc(GFP_DMA)/dma_map_xxxx() pair with dma_alloc_noncoherent().
Next, plan to investigate how we should handle places as below. We
firstly need figure out whether they really need buffer from ZONE_DMA.
If yes, how to change them with other ways. This need help from
maintainers, experts from sub-components and code contributors or anyone
knowing them well. E.g s390 and crypyto, we need guidance and help.
1) Kmalloc(GFP_DMA) in s390 platform, under arch/s390 and drivers/s390;
2) Kmalloc(GFP_DMA) in drivers/crypto;
3) Kmalloc(GFP_DMA) in network drivers under drivers/net, e.g skb
buffer requested from DMA zone.
4) Kmalloc(GFP_DMA) in device register control, e.g using regmap, devres
to read/write register, while memory from ZONE_DMA is required, e.g
i2c, spi.
For this first patch series, thanks to Hyeonggon for helping
reviewing and great suggestions on patch improving. We will work
together to continue the next steps of work.
Any comment, thought, or suggestoin is welcome and appreciated,
including but not limited to:
1) whether we should remove dma-kmalloc support in kernel();
3) why kmalloc(GFP_DMA) is needed in a certain place. why memory from
ZONE_DMA has to be requested in the case.
2) how to replace it with other ways in any place which you are familiar
with;
===========================Background information=======================
Prelusion:
Earlier, allocation failure was observed when calling kmalloc() with
GFP_DMA. It requests to allocate slab page from DMA zone while no managed
pages at all in there. Because in the current kernel, dma-kmalloc will
be created as long as CONFIG_ZONE_DMA is enabled. However, kdump kernel
of x86_64 doesn't have managed pages on DMA zone since below commit. The
details of this kdump issue can be found in reference link (a).
commit 6f599d84231f ("x86/kdump: Always reserve the low 1M when the crashkernel option is specified")
To make clear the root cause and fix, many reviewers contributed their
thoughts and suggestions in the thread of the patchset v3 (a). Finally
Hyeonggon concluded what we can do to fix the kdump issue for now as a
workaround, and further action to get rid of dma-kmalloc which is not
a reasonable existence. (Please see Hyeonggon's reply in refernce (b)).
Quote Hyeonggon's words here:
~~~~
What about one of those?:
1) Do not call warn_alloc in page allocator if will always fail
to allocate ZONE_DMA pages.
2) let's check all callers of kmalloc with GFP_DMA
if they really need GFP_DMA flag and replace those by DMA API or
just remove GFP_DMA from kmalloc()
3) Drop support for allocating DMA memory from slab allocator
(as Christoph Hellwig said) and convert them to use DMA32
and see what happens
~~~~
Then Christoph acked Hyeonggon's conclusion, and said "This is the right
thing to do, but it will take a while." (See reference link (c))
==========Reference links=======
(a) v4 post including the details of kdump issue:
https://lore.kernel.org/all/20211223094435.248523-1-bhe@redhat.com/T/#u
(b) v3 post including many reviewers' comments:
https://lore.kernel.org/all/20211213122712.23805-1-bhe@redhat.com/T/#u
(c) Hyeonggon's mail concluding the solution:
https://lore.kernel.org/all/20211215044818.GB1097530@odroid/T/#u
(d) Christoph acked the plan in this mail:
https://lore.kernel.org/all/20211215072710.GA3010@lst.de/T/#u
Baoquan He (21):
parisc: pci-dma: remove stale code and comment
gpu: ipu-v3: Don't use GFP_DMA when calling dma_alloc_coherent()
drm/sti: Don't use GFP_DMA when calling dma_alloc_wc()
sound: n64: Don't use GFP_DMA when calling dma_alloc_coherent()
fbdev: da8xx: Don't use GFP_DMA when calling dma_alloc_coherent()
fbdev: mx3fb: Don't use GFP_DMA when calling dma_alloc_wc()
usb: gadget: lpc32xx_udc: Don't use GFP_DMA when calling
dma_alloc_coherent()
usb: cdns3: Don't use GFP_DMA when calling dma_alloc_coherent()
uio: pruss: Don't use GFP_DMA when calling dma_alloc_coherent()
staging: emxx_udc: Don't use GFP_DMA when calling dma_alloc_coherent()
staging: emxx_udc: Don't use GFP_DMA when calling dma_alloc_coherent()
spi: atmel: Don't use GFP_DMA when calling dma_alloc_coherent()
spi: spi-ti-qspi: Don't use GFP_DMA when calling dma_alloc_coherent()
usb: cdns3: Don't use GFP_DMA when calling dma_pool_alloc()
usb: udc: lpc32xx: Don't use GFP_DMA when calling dma_pool_alloc()
net: marvell: prestera: Don't use GFP_DMA when calling
dma_pool_alloc()
net: ethernet: mtk-star-emac: Don't use GFP_DMA when calling
dmam_alloc_coherent()
ethernet: rocker: Use dma_alloc_noncoherent() for dma buffer
HID: intel-ish-hid: Use dma_alloc_noncoherent() for dma buffer
mmc: wbsd: Use dma_alloc_noncoherent() for dma buffer
mtd: rawnand: Use dma_alloc_noncoherent() for dma buffer
Hyeonggon Yoo (1):
net: moxa: Don't use GFP_DMA when calling dma_alloc_coherent()
arch/parisc/kernel/pci-dma.c | 8 ---
drivers/gpu/drm/sti/sti_cursor.c | 4 +-
drivers/gpu/drm/sti/sti_hqvdp.c | 2 +-
drivers/gpu/ipu-v3/ipu-image-convert.c | 2 +-
drivers/hid/intel-ish-hid/ishtp-fw-loader.c | 23 +++-----
drivers/mmc/host/wbsd.c | 45 +++-----------
drivers/mtd/nand/raw/marvell_nand.c | 55 ++++++++++-------
.../ethernet/marvell/prestera/prestera_rxtx.c | 2 +-
drivers/net/ethernet/mediatek/mtk_star_emac.c | 2 +-
drivers/net/ethernet/moxa/moxart_ether.c | 4 +-
drivers/net/ethernet/rocker/rocker_main.c | 59 ++++++++-----------
drivers/spi/spi-atmel.c | 4 +-
drivers/spi/spi-ti-qspi.c | 2 +-
drivers/staging/emxx_udc/emxx_udc.c | 2 +-
drivers/staging/media/imx/imx-media-utils.c | 2 +-
drivers/uio/uio_pruss.c | 2 +-
drivers/usb/cdns3/cdns3-gadget.c | 4 +-
drivers/usb/gadget/udc/lpc32xx_udc.c | 4 +-
drivers/video/fbdev/da8xx-fb.c | 4 +-
drivers/video/fbdev/fsl-diu-fb.c | 2 +-
drivers/video/fbdev/mx3fb.c | 2 +-
sound/mips/snd-n64.c | 2 +-
22 files changed, 97 insertions(+), 139 deletions(-)
--
2.17.2
next reply other threads:[~2022-02-19 0:52 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-19 0:51 Baoquan He [this message]
2022-02-19 0:52 ` [PATCH 01/22] parisc: pci-dma: remove stale code and comment Baoquan He
2022-02-19 7:07 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 02/22] net: moxa: Don't use GFP_DMA when calling dma_alloc_coherent() Baoquan He
2022-02-19 7:07 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 03/22] gpu: ipu-v3: " Baoquan He
2022-02-19 7:07 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 04/22] drm/sti: Don't use GFP_DMA when calling dma_alloc_wc() Baoquan He
2022-02-19 7:08 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 05/22] sound: n64: Don't use GFP_DMA when calling dma_alloc_coherent() Baoquan He
2022-02-19 7:08 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 06/22] fbdev: da8xx: " Baoquan He
2022-02-19 7:08 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 07/22] fbdev: mx3fb: Don't use GFP_DMA when calling dma_alloc_wc() Baoquan He
2022-02-19 7:08 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 08/22] usb: gadget: lpc32xx_udc: Don't use GFP_DMA when calling dma_alloc_coherent() Baoquan He
2022-02-19 7:09 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 09/22] usb: cdns3: " Baoquan He
2022-02-19 7:09 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 10/22] uio: pruss: " Baoquan He
2022-02-19 7:09 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 11/22] staging: emxx_udc: " Baoquan He
2022-02-19 6:51 ` Wolfram Sang
2022-02-20 1:55 ` Baoquan He
2022-02-19 7:09 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 12/22] " Baoquan He
2022-02-19 7:10 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 13/22] spi: atmel: " Baoquan He
2022-02-19 7:10 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 14/22] spi: spi-ti-qspi: " Baoquan He
2022-02-19 7:12 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 15/22] usb: cdns3: Don't use GFP_DMA32 when calling dma_pool_alloc() Baoquan He
2022-02-19 7:13 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 16/22] usb: udc: lpc32xx: Don't use GFP_DMA " Baoquan He
2022-02-19 7:13 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 17/22] net: marvell: prestera: " Baoquan He
2022-02-19 4:54 ` Jakub Kicinski
2022-02-20 2:06 ` Baoquan He
2022-02-19 7:13 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 18/22] net: ethernet: mtk-star-emac: Don't use GFP_DMA when calling dmam_alloc_coherent() Baoquan He
2022-02-19 7:13 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 19/22] ethernet: rocker: Use dma_alloc_noncoherent() for dma buffer Baoquan He
2022-02-19 7:14 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 20/22] HID: intel-ish-hid: " Baoquan He
2022-02-19 7:14 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 21/22] mmc: wbsd: " Baoquan He
2022-02-19 7:17 ` Christoph Hellwig
2022-02-20 8:40 ` Baoquan He
2022-02-22 8:45 ` Christoph Hellwig
2022-02-22 9:14 ` Baoquan He
2022-02-22 13:11 ` Christoph Hellwig
2022-02-22 13:40 ` Baoquan He
2022-02-22 13:41 ` [PATCH 1/2] dma-mapping: check dma_mask for streaming mapping allocs Baoquan He
2022-02-22 15:59 ` Christoph Hellwig
2022-02-23 0:28 ` Baoquan He
2022-02-23 14:25 ` Christoph Hellwig
2022-02-23 14:57 ` David Laight
2022-02-24 14:11 ` Baoquan He
2022-02-24 14:27 ` David Laight
2022-02-25 15:39 ` 'Baoquan He'
2022-02-22 13:42 ` [PATCH 2/2] kernel/dma: rename dma_alloc_direct and dma_map_direct Baoquan He
2022-02-22 15:59 ` Christoph Hellwig
2022-02-19 0:52 ` [PATCH 22/22] mtd: rawnand: Use dma_alloc_noncoherent() for dma buffer Baoquan He
2022-02-19 7:19 ` Christoph Hellwig
2022-02-19 11:18 ` Hyeonggon Yoo
2022-02-22 8:46 ` Christoph Hellwig
2022-02-22 9:06 ` David Laight
2022-02-22 13:16 ` 'Christoph Hellwig'
2022-02-21 13:57 ` [PATCH 00/22] Don't use kmalloc() with GFP_DMA Heiko Carstens
2022-02-22 8:44 ` Christoph Hellwig
2022-02-22 13:12 ` Baoquan He
2022-02-22 13:26 ` Baoquan He
2022-02-23 19:18 ` Heiko Carstens
2022-02-24 6:33 ` Christoph Hellwig
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=20220219005221.634-1-bhe@redhat.com \
--to=bhe@redhat.com \
--cc=42.hyeyoo@gmail.com \
--cc=David.Laight@ACULAB.COM \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@linux.ibm.com \
--cc=cl@linux.com \
--cc=davem@davemloft.net \
--cc=david@redhat.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hch@lst.de \
--cc=herbert@gondor.apana.org.au \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=michael@walle.cc \
--cc=netdev@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=steffen.klassert@secunet.com \
--cc=svens@linux.ibm.com \
--cc=vbabka@suse.cz \
--cc=wsa@kernel.org \
/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.