close(int sg_fd). Preferably a close() should be done after all issued write()s have had
their corresponding read() calls completed. Unfortunately this is not
always possible (e.g. the user may choose to send a kill signal to a
running process). The sg driver implements "fast" close semantics and thus
will return more or less immediately (i.e. not wait on any event). This
is application friendly but requires the sg driver to arrange for an
orderly cleanup of those packets that are still "in flight".

When close() leaves outstanding SCSI commands still awaiting responses,
the sg driver maintains its internal structures for the now defunct
file descriptor. These internal structures are maintained until all
outstanding responses (some might be timeouts) are received. When the
sg driver is loaded as a module and has any open file descriptors or
"defunct" file descriptors then it cannot be unloaded. An attempt to
call rmmod sg will report the driver is busy. Defunct
file descriptors that remain for some time, perhaps awaiting a timeout,
can be observed with the cat /proc/scsi/sg/debug
command. In this case "closed=1" will be set on the defunct file descriptor
[see Section 11.1]. Defunct file descriptors do not impede
attempts by applications to open() new file descriptors on the same SCSI
device.

The kernel arranges for only the last close() on a file descriptor to be
seen by a driver (and to emphasize this, the corresponding sg driver call
is named sg_release() rather than sg_close()). This is only significant when
an application uses fork() or dup().