question on scsi_alloc_sdev()

question on scsi_alloc_sdev()

[Martin Peschke]

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

Re: question on scsi_alloc_sdev()

[James Bottomley]

On Thu, 2006-08-10 at 16:37 +0200, Martin Peschke wrote:
> 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.

> 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.

> 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