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]
Message-ID: <BAE9DCEF64577A439B3A37F36F9B691C034FF787@orsmsx418.amr.corp.intel.com>
Date:	Mon, 29 Oct 2007 09:02:34 -0700
From:	"Nelson, Shannon" <shannon.nelson@...el.com>
To:	"Williams, Dan J" <dan.j.williams@...el.com>,
	"Haavard Skinnemoen" <hskinnemoen@...el.com>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	"linux-kernel" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] DMA: Fix broken device refcounting

>From: Williams, Dan J 
>On Sat, 2007-10-27 at 06:49 -0700, Haavard Skinnemoen wrote:
>> On Fri, 26 Oct 2007 09:36:17 -0700
>> Dan Williams <dan.j.williams@...el.com> wrote:
>> 
>> > @@ -221,7 +220,6 @@ void dma_chan_cleanup(struct kref *kref)
>> >  {
>> >       struct dma_chan *chan = container_of(kref, struct 
>dma_chan, refcount);
>> >       chan->device->device_free_chan_resources(chan);
>> > -     kref_put(&chan->device->refcount, dma_async_device_cleanup);
>> >  }
>> >  EXPORT_SYMBOL(dma_chan_cleanup);
>> 
>> While I can't see any problems with the rest of the patch, I 
>think this
>> part is wrong for the same reasons removing the kref_put() from the
>> class device cleanup function is. I don't see any constraint that
>> guarantees that dma_chan_cleanup() will always be called before
>> dma_dev_release(), which means that "chan" may have been freed before
>> this function gets a chance to run. Please correct me if I'm wrong.
>
>Absolutely right, the driver, not dmaengine, frees the memory so there
>must be a per channel reference on the device to hold off the driver's
>remove routine.
>> 
>> HÃ¥vard
>
>So how about this...
>
>---snip---
>dmaengine: Fix broken device refcounting
>
>From: Haavard Skinnemoen <hskinnemoen@...el.com>
>
>When a DMA device is unregistered, its reference count is decremented
>twice for each channel: Once dma_class_dev_release() and once in
>dma_chan_cleanup(). This may result in the DMA device driver's
>remove() function completing before all channels have been cleaned
>up, causing lots of use-after-free fun.
>
>Fix it by incrementing the device's reference count twice for each
>channel during registration.
>
>Signed-off-by: Haavard Skinnemoen <hskinnemoen@...el.com>
>[dan.j.williams@...el.com: kill unnecessary client refcounting]
>Signed-off-by: Dan Williams <dan.j.williams@...el.com>
>---
>
> drivers/dma/dmaengine.c |   17 ++++++-----------
> 1 files changed, 6 insertions(+), 11 deletions(-)
>
>diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
>index 84257f7..ec7e871 100644
>--- a/drivers/dma/dmaengine.c
>+++ b/drivers/dma/dmaengine.c
>@@ -186,10 +186,9 @@ static void dma_client_chan_alloc(struct 
>dma_client *client)
> 				/* we are done once this client rejects
> 				 * an available resource
> 				 */
>-				if (ack == DMA_ACK) {
>+				if (ack == DMA_ACK)
> 					dma_chan_get(chan);
>-					kref_get(&device->refcount);
>-				} else if (ack == DMA_NAK)
>+				else if (ack == DMA_NAK)
> 					return;
> 			}
> 		}
>@@ -276,11 +275,8 @@ static void 
>dma_clients_notify_removed(struct dma_chan *chan)
> 		/* client was holding resources for this channel so
> 		 * free it
> 		 */
>-		if (ack == DMA_ACK) {
>+		if (ack == DMA_ACK)
> 			dma_chan_put(chan);
>-			kref_put(&chan->device->refcount,
>-				dma_async_device_cleanup);
>-		}
> 	}
> 
> 	mutex_unlock(&dma_list_mutex);
>@@ -320,11 +316,8 @@ void dma_async_client_unregister(struct 
>dma_client *client)
> 			ack = client->event_callback(client, chan,
> 				DMA_RESOURCE_REMOVED);
> 
>-			if (ack == DMA_ACK) {
>+			if (ack == DMA_ACK)
> 				dma_chan_put(chan);
>-				kref_put(&chan->device->refcount,
>-					dma_async_device_cleanup);
>-			}
> 		}
> 
> 	list_del(&client->global_node);
>@@ -401,6 +394,8 @@ int dma_async_device_register(struct 
>dma_device *device)
> 			goto err_out;
> 		}
> 
>+		/* One for the channel, one of the class device */
>+		kref_get(&device->refcount);
> 		kref_get(&device->refcount);
> 		kref_init(&chan->refcount);
> 		chan->slow_ref = 0;
>
>

I tested this in my ioatdma setup and no longer get the panic.  I'm good with this if you two are happy with it.  

Signed-off-by: Shannon Nelson <shannon.nelson@...el.com>

sln
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ