From mboxrd@z Thu Jan 1 00:00:00 1970 From: va.storage2010@gmail.com (va stg2010) Date: Wed, 16 Mar 2011 11:48:36 -0700 Subject: On sg_miter_next sg_miter_stop In-Reply-To: References: Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org On Wed, Mar 16, 2011 at 10:49 AM, Mulyadi Santosa wrote: > Hi... > > On Thu, Mar 17, 2011 at 00:26, va stg2010 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().