Skip to contentSkip to conversation

question on scsi_alloc_sdev()

DISCUSSION Martin Peschke 2 participants 2 messages Aug 10, 2006 SCSI

lore
Share & tools
lore
#0 lore raw

Does anybody know for sure whether scsi_alloc_sdev() is guaranteed to be called in process context or not?

There seem to be contradictory signs in scsi_scan.c:
scsi_alloc_sdev() uses GFP_ATOMIC, as related functions do. It might be called in a section protected by a mutex.

I conducted a little experiment using might_sleep() in scsi_alloc_sdev()
- no backtrace on the console, hence process context.

Or, is the purpose of GFP_ATOMIC just (SCSI) I/O avoidance, and sleeping isn't an issue?

Thanks,
Martin

#1 lore raw
Quoted 2 lines · Martin Peschke

Does anybody know for sure whether scsi_alloc_sdev() is guaranteed to be called in process context or not?

It's always called in the scan or setup path, so yes, process context is guaranteed.

Quoted 3 lines

There seem to be contradictory signs in scsi_scan.c:
scsi_alloc_sdev() uses GFP_ATOMIC, as related functions do. It might be called in a section protected by a mutex.

It is always protected by the scan mutex, but a mutex is a sleeping lock, so it could also be GFP_KERNEL.

Quoted 5 lines

I conducted a little experiment using might_sleep() in scsi_alloc_sdev()
- no backtrace on the console, hence process context.

Or, is the purpose of GFP_ATOMIC just (SCSI) I/O avoidance, and sleeping isn't an issue?

I'm guessing it's just historical.

James