Messages in this thread | | | Date | Tue, 15 Jun 2010 17:45:06 +0530 | From | Srikar Dronamraju <> | Subject | Re: [PATCH v5 7/14] x86 support for Uprobes |
| |
> > > > > > I'm no x86 port guru, but this looks rather worriesome to me. Why does > > > do_notify_resume have different calling conventions on 32 vs 64-bit? > > > And if there is a good reason that 32-bit has them disabled, why is > > > enabling them in the middle of do_notify_resume okay? > > > > Thanks for bringing this up. I have no idea about why do_notify_resume() > > gets called with interrupts disabled in 32 bit. > > Perhaps just because there is no reason to explicitly enable irqs? > > > I would be happy to know > > the reason and rework based on inputs. I did query a few people about > > this but I havent got an answer on why we they are disabled on 32 bit and > > if its Okay to enable at this place. > > I think it is OK to enable interrupts. do_notify_resume() calls do_signal() > which enables them anyway. > > But there is another question I already asked. Why the code uses > native_irq_enable()? IIRC, you explained that local_irq_enable() doesn't > work for unkown reason. This is strange, and imho should be explained. >
local_irq_enable() translates to raw_local_irq_enable(). However raw_local_irq_enable on x86 seems to depend on CONFIG_PARAVIRT. On a machine, where CONFIG_PARAVIRT was defined, local_irq_enable translates to something other than native_irq_enable. It translates to PVOP_VCALLEE0(pv_irq_ops.irq_enable);
Is it okay to use local_irq_enable() and then make CONFIG_UPROBES depend on !CONFIG_PARAVIRT?
> And I do not see a need to disable irqs again. > > Oleg. >
| |