Linux-kernel mailing list archive 1999-22,: I/O Requests again

# I/O Requests again

Chris Smith (cd_smith@ou.edu)
Tue, 1 Jun 1999 13:36:20 -0600

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Andre M. Hedrick: "Re: Disk corrupted when disk out of space (VFAT)"
- Previous message: Nimrod Zimerman: "Re: sound and control-c"

Hi,

Okay, I posted a question yesterday about calling make_request() from within
my block driver's request_fn. I have since realized that this would
deadlock trying to grab the I/O request spinlock twice, since it is held by
add_request through the call to dev->request_fn. Yes, I see that request_fn
needs to hold that lock to play around with its request list, but if I stop
playing around with my request list, can I safely release the lock to call
make_request?

My problem comes from the fact that the saved flags are stored in a local
variable in the calling instance of add_request! Are there safe values for
these flags that I can use to unlock the I/O request queue, assuming I don't
play with request lists until I lock it again? And in particular, can I
call make_request with interrupts disabled? Here's my basic plan for my
driver right now, so please let me know if this is okay (essentially, it's
supposed to make an existing block device available through my major
number):

xxx_end_request()
{
finish the corresponding request to my driver
}

xxx_make_request()
{
unlock the I/O request spinlock (but keep current flags)
create a new struct buffer_head with completion function set to
xxx_end_request
call make_request
lock the I/O request spinlock (keep current flags)
}

xxx_request()
{
Get and remove the current request
Call xxx_make_request to create the underlying request
}

So, any reason this doesn't work? (Again, apologies if this question is
answered somewhere obvious that I haven't found.)

TIA,
Chris

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Andre M. Hedrick: "Re: Disk corrupted when disk out of space (VFAT)"
- Previous message: Nimrod Zimerman: "Re: sound and control-c"