Re: [PATCH v4 1/2] SCSI: Asynchronous event notification infrastructure

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: James Bottomley
Date: Monday, October 29, 2007 - 8:51 am

On Mon, 2007-10-29 at 10:42 -0400, Jeff Garzik wrote:

This still doesn't solve the fundamental corruption problem:
sdev->event_work has to contain the work entry until the workqueue has
finished executing it (which is some unspecified time in the future).
As soon as you drop the sdev->list_lock, the system thinks
sdev->event_work is available for reuse.  If we fire another event
before the work queue finished processing the prior event, the queue
will be corrupted.

Although I hate GFP_ATOMIC allocations, I think that's the only viable
way to get out of this corruption problem (using a mechanism similar to
what I proposed yesterday).

Also, I think Kristin's initial use of execute_in_user_context() was a
good call .. if we already have a user context, there's no need to
bother the workqueue ... some of these events will likely trigger from
thread backed kernel daemons.

James


-
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [PATCH v4 1/2] SCSI: Asynchronous event notification i ..., James Bottomley, (Mon Oct 29, 8:51 am)