On sg_miter_next sg_miter_stop

[va stg2010]

On Wed, Mar 16, 2011 at 10:49 AM, Mulyadi Santosa
<mulyadi.santosa at gmail.com> wrote:
> Hi...
>
> On Thu, Mar 17, 2011 at 00:26, va stg2010 <va.storage2010 at gmail.com> wrote:
>> I also looked into sg_miter_next()   and sg_miter_stop()
>> implementations.  They  are calling  kmap_atomic()   and
>> kunmap_atomic() respectively.    Based on comment --  Is following an
>> illegal operation? and why?
>> 1)  IRQ disabled
>> 2) sg_miter_next , meaning kmap_atomic
>> 3) IRQ enabled
>> 4)  IRQ  disabled again little later
>> 5) sg_miter_stop, meaning kunmap_atomic()
>>
>> The above sequence caused following scheduler messages (if
>> sg_miter_stop()  is moved between step1 & step3 then following error
>> messages disappeared) :--------
>> BUG: scheduling while atomic: swapper/0/0xffffffff
>> Modules linked in: my_scsi_lld
>
> quite likely the error was triggered not due to kmap_atomic() and
> kunmap_atomic(), but due to something that you do toward the page
> allocated via kmap_atomic() itself.

The page is given to my scsi mid layer LLDD by  linux-scsi layer for
SCSI read request.  When sg_miter_stop() happens the page will have
READ data available and I call scsi_done().