linux-kernel - Re: [PATCH] x86: adjust GFP mask handling for coherent allocations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 27 Oct 2009 19:15:59 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	JBeulich@...ell.com
Cc:	fujita.tomonori@....ntt.co.jp, mingo@...e.hu, yinghai@...nel.org,
	tglx@...utronix.de, tiwai@...e.de, linux-kernel@...r.kernel.org,
	jbarnes@...tuousgeek.org, hpa@...or.com
Subject: Re: [PATCH] x86: adjust GFP mask handling for coherent	 allocations

On Tue, 27 Oct 2009 09:47:32 +0000
"Jan Beulich" <JBeulich@...ell.com> wrote:

> >>> FUJITA Tomonori <fujita.tomonori@....ntt.co.jp> 27.10.09 10:37 >>>
> >On Tue, 27 Oct 2009 09:23:38 +0000
> >"Jan Beulich" <JBeulich@...ell.com> wrote:
> >
> >> Because there's quite a few of them - just search for callers of
> >> dma_alloc_coherent() passing NULL as the first argument. Of course
> >> I'd rather see the fallback gone, but I think this requires cooperation
> >> from/action taken by the driver maintainers first. A first step might be
> >> to add a WRN_ON() for that case, but I don't see it being reasonable
> >> to eliminate the fallback right away. Hence, with it having got broken
> >> in .26 I think it is reasonable to fix it for the time being.
> >
> >Well, the most of them are drivers that nobody cares about (uses).
> >
> >What drivers did you hit this problem with?
> 
> drivers/firmware/dell_rbu.c (on .27.x, and in particular with the derivation
> of __GFP_NORETRY from __GFP_DMA, which fortunately doesn't exist in
> newer kernels anymore).

I don't know anything about this driver (and even I'm not sure why
this driver uses dma_alloc_coherent) but why can't this driver use
rbu_device with dma API?


diff --git a/drivers/firmware/dell_rbu.c b/drivers/firmware/dell_rbu.c
index b4704e1..481b009 100644
--- a/drivers/firmware/dell_rbu.c
+++ b/drivers/firmware/dell_rbu.c
@@ -372,8 +372,8 @@ static void img_update_free(void)
 	memset(rbu_data.image_update_buffer, 0,
 		rbu_data.image_update_buffer_size);
 	if (rbu_data.dma_alloc == 1)
-		dma_free_coherent(NULL, rbu_data.bios_image_size,
-			rbu_data.image_update_buffer, dell_rbu_dmaaddr);
+		dma_free_coherent(&rbu_device->dev, rbu_data.bios_image_size,
+				  rbu_data.image_update_buffer, dell_rbu_dmaaddr);
 	else
 		free_pages((unsigned long) rbu_data.image_update_buffer,
 			rbu_data.image_update_ordernum);
@@ -443,7 +443,7 @@ static int img_update_realloc(unsigned long size)
 	if (img_buf_phys_addr > BIOS_SCAN_LIMIT) {
 		free_pages((unsigned long) image_update_buffer, ordernum);
 		ordernum = -1;
-		image_update_buffer = dma_alloc_coherent(NULL, size,
+		image_update_buffer = dma_alloc_coherent(&rbu_device->dev, size,
 			&dell_rbu_dmaaddr, GFP_KERNEL);
 		dma_alloc = 1;
 	}
@@ -699,6 +699,8 @@ static int __init dcdrbu_init(void)
 			"failed\n", __func__);
 		return PTR_ERR(rbu_device);
 	}
+	rbu_device->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+	rbu_device->dev.dma_mask = &rbu_device->dev.coherent_dma_mask;
 
 	rc = sysfs_create_bin_file(&rbu_device->dev.kobj, &rbu_data_attr);
 	if (rc)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/