* On sg_miter_next sg_miter_stop @ 2011-03-16 1:40 va stg2010 2011-03-16 4:50 ` Mulyadi Santosa 0 siblings, 1 reply; 5+ messages in thread From: va stg2010 @ 2011-03-16 1:40 UTC (permalink / raw) To: kernelnewbies Hi Can someone explain to me reason for the comment at line 332-333 of this code http://lxr.linux.no/#linux+v2.6.27.7/lib/scatterlist.c#L332 comment is: " IRQ must stay disabled till @miter@ is stopped." Thankyou vks ^ permalink raw reply [flat|nested] 5+ messages in thread
* On sg_miter_next sg_miter_stop 2011-03-16 1:40 On sg_miter_next sg_miter_stop va stg2010 @ 2011-03-16 4:50 ` Mulyadi Santosa 2011-03-16 17:26 ` va stg2010 0 siblings, 1 reply; 5+ messages in thread From: Mulyadi Santosa @ 2011-03-16 4:50 UTC (permalink / raw) To: kernelnewbies Hi.. On Wed, Mar 16, 2011 at 08:40, va stg2010 <va.storage2010@gmail.com> wrote: > Hi > Can someone explain to me reason for the comment at line 332-333 of this code > http://lxr.linux.no/#linux+v2.6.27.7/lib/scatterlist.c#L332 > > comment is: > " ? IRQ must stay disabled till @miter@ is stopped." OK, is this the complete comment you referred? "Context: 332 * IRQ disabled if SG_MITER_ATOMIC. IRQ must stay disabled till 333 * @miter@ is stopped. May sleep if !SG_MITER_ATOMIC." well, then, my raw guess is, because it must be done atomically (when asked to do so). Usually, atomic operation has tight relationship with something that must be done in short time and/or must not be interrupted by interrupt handler. Since this is talking about scatter list, I could only guess few example...perhaps in bio handling? -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* On sg_miter_next sg_miter_stop 2011-03-16 4:50 ` Mulyadi Santosa @ 2011-03-16 17:26 ` va stg2010 2011-03-16 17:49 ` Mulyadi Santosa 0 siblings, 1 reply; 5+ messages in thread From: va stg2010 @ 2011-03-16 17:26 UTC (permalink / raw) To: kernelnewbies Mulyadi, I referred to this comment. "IRQ must stay disabled till @miter@ is stopped. " Yes my operations are atomic and I set miter->flag as SG_MITER_ATOMIC when i call sg_miter_start() But from comment it seems sg_miter_stop should be called before IRQ is enabled. 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 Call Trace: [<ffffffff8150188c>] dump_stack+0x8/0x34 [<ffffffff815024e0>] schedule+0x4c0/0x908 BUG: scheduling while atomic: swapper/0/0x00000001 Modules linked in: my_scsi_lld Call Trace: [<ffffffff8150188c>] dump_stack+0x8/0x34 [<ffffffff815024e0>] schedule+0x4c0/0x908 [<ffffffff81134318>] cpu_idle+0x48/0x50 BUG: scheduling while atomic: swapper/0/0x00000001 Modules linked in: my_scsi_lld Call Trace: [<ffffffff8150188c>] dump_stack+0x8/0x34 [<ffffffff815024e0>] schedule+0x4c0/0x908 [<ffffffff81134318>] cpu_idle+0x48/0x50 BUG: scheduling while atomic: swapper/0/0x00000001 Modules linked in: my_scsi_lld Call Trace: [<ffffffff8150188c>] dump_stack+0x8/0x34 [<ffffffff815024e0>] schedule+0x4c0/0x908 [<ffffffff81134318>] cpu_idle+0x48/0x50 On Tue, Mar 15, 2011 at 9:50 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote: > Hi.. > > On Wed, Mar 16, 2011 at 08:40, va stg2010 <va.storage2010@gmail.com> wrote: >> Hi >> Can someone explain to me reason for the comment at line 332-333 of this code >> http://lxr.linux.no/#linux+v2.6.27.7/lib/scatterlist.c#L332 >> >> comment is: >> " ? IRQ must stay disabled till @miter@ is stopped." > > OK, is this the complete comment you referred? > "Context: > ?332 * ? IRQ disabled if SG_MITER_ATOMIC. ?IRQ must stay disabled till > ?333 * ? @miter@ is stopped. ?May sleep if !SG_MITER_ATOMIC." > > well, then, my raw guess is, because it must be done atomically (when > asked to do so). Usually, atomic operation has tight relationship with > something that must be done in short time and/or must not be > interrupted by interrupt handler. > > Since this is talking about scatter list, I could only guess few > example...perhaps in bio handling? > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > ^ permalink raw reply [flat|nested] 5+ messages in thread
* On sg_miter_next sg_miter_stop 2011-03-16 17:26 ` va stg2010 @ 2011-03-16 17:49 ` Mulyadi Santosa 2011-03-16 18:48 ` va stg2010 0 siblings, 1 reply; 5+ messages in thread From: Mulyadi Santosa @ 2011-03-16 17:49 UTC (permalink / raw) To: kernelnewbies Hi... On Thu, Mar 17, 2011 at 00:26, va stg2010 <va.storage2010@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. kmap_atomic() theoritically should not be affected by the state of interrupt delivery.... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ^ permalink raw reply [flat|nested] 5+ messages in thread
* On sg_miter_next sg_miter_stop 2011-03-16 17:49 ` Mulyadi Santosa @ 2011-03-16 18:48 ` va stg2010 0 siblings, 0 replies; 5+ messages in thread From: va stg2010 @ 2011-03-16 18:48 UTC (permalink / raw) To: kernelnewbies On Wed, Mar 16, 2011 at 10:49 AM, Mulyadi Santosa <mulyadi.santosa@gmail.com> wrote: > Hi... > > On Thu, Mar 17, 2011 at 00:26, va stg2010 <va.storage2010@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(). ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-03-16 18:48 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-03-16 1:40 On sg_miter_next sg_miter_stop va stg2010 2011-03-16 4:50 ` Mulyadi Santosa 2011-03-16 17:26 ` va stg2010 2011-03-16 17:49 ` Mulyadi Santosa 2011-03-16 18:48 ` va stg2010
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).