On 12/22/21 at 10:42am, Christoph Hellwig wrote: > On Wed, Dec 22, 2021 at 05:37:07PM +0800, Baoquan He wrote: > > > /* allocate transfer buffer */ > > > - buffer = kmalloc(512, GFP_KERNEL | GFP_DMA); > > > + buffer = kmalloc(512, GFP_KERNEL); > > > > Thanks a lot for doing this. When I browsed the code path, I come to > > blk_rq_map_kern() but I am not sure if blk_queue_may_bounce() is true in > > the sr_probe() case, then it may enter into bio_map_kern(). > > blk_queue_may_bounce will be entered for the few drives that set > BLK_BOUNCE_HIGH because they can't handle highmem (which is a subset > of the non-ZONE_DMA memory). The only driver that actually requires > ZONE_DMA based bouncing is ps3rom, and that driver does a manual > and ubconditional bounce buffering. Got it now, thx. > > > Next I will post my original patchset to mute the allocation failure if > > it's requesting page from DMA zone and DMA zone has no managed page. And > > meanwhile, I will try to collect those places of kmalloc(GFP_DMA) into a > > RFC mail, see if we can change them one by one. Anyone can pick one > > place to fix if interested or knowing it well. > > I've already sent out patches for all of drivers/scsi/ today, except > for the ps3rom bounce buffer alllocation which is fine but should > probably be changed to use the page allocator directly. Sounds really great. Any thought or plan for those callsites in other places? Possibly we can skip those s390 related drivers since s390 only has DMA zone, no DMA32, it should be OK. And could you please also add me to CC when send out these patches? We have this problem in our RHEL8 which is based on kernel4.18, if finally removing dma-kmalloc(), we need back port these driver fixes too. If not paying attention, these patches may scatter in different sub-components and unnoticable. > > > Finally, we can remove the > > need of dma-kmalloc() as people suggested. Any comment? > > Yes. >
