[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130128162238.7fba92fe.akpm@linux-foundation.org>
Date: Mon, 28 Jan 2013 16:22:38 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Alexander Holler <holler@...oftware.de>
Cc: linux-kernel@...r.kernel.org, linux-fbdev@...r.kernel.org,
Florian Tobias Schandinat <FlorianSchandinat@....de>,
Bernie Thompson <bernie@...gable.com>,
Steve Glendinning <steve.glendinning@...well.net>,
<stable@...r.kernel.org>
Subject: Re: [PATCH 2/3 v2] fb: udlfb: fix hang at disconnect
On Fri, 25 Jan 2013 19:49:27 +0100
Alexander Holler <holler@...oftware.de> wrote:
> When a device was disconnected the driver may hang at waiting for urbs it never
> will get. Fix this by using a timeout while waiting for the used semaphore.
>
> There is still a memory leak if a timeout happens, but at least the driver
> now continues his disconnect routine.
>
> ...
>
> --- a/drivers/video/udlfb.c
> +++ b/drivers/video/udlfb.c
> @@ -1832,8 +1832,9 @@ static void dlfb_free_urb_list(struct dlfb_data *dev)
> /* keep waiting and freeing, until we've got 'em all */
> while (count--) {
>
> - /* Getting interrupted means a leak, but ok at disconnect */
> - ret = down_interruptible(&dev->urbs.limit_sem);
> + /* Timeout likely occurs at disconnect (resulting in a leak) */
> + ret = down_timeout_killable(&dev->urbs.limit_sem,
> + FREE_URB_TIMEOUT);
> if (ret)
> break;
This is rather a hack. Do you have an understanding of the underlying
bug? Why is the driver waiting for things which will never happen?
--
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