lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <27240C0AC20F114CBF8149A2696CBE4A195A8D@SHSMSX101.ccr.corp.intel.com>
Date:	Fri, 12 Oct 2012 15:29:31 +0000
From:	"Liu, Chuansheng" <chuansheng.liu@...el.com>
To:	anish kumar <anish198519851985@...il.com>
CC:	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] genirq: for edge interrupt IRQS_ONESHOT support with
 irq thread



> -----Original Message-----
> From: anish kumar [mailto:anish198519851985@...il.com]
> Sent: Friday, October 12, 2012 11:25 PM
> To: Liu, Chuansheng
> Cc: Thomas Gleixner; linux-kernel@...r.kernel.org
> Subject: RE: [PATCH] genirq: for edge interrupt IRQS_ONESHOT support with irq
> thread
> 
> On Fri, 2012-10-12 at 14:57 +0000, Liu, Chuansheng wrote:
> > > On SMP an interrupt which is raised after the ack() again before the
> > > handler finishes, can invoke another delivery on a different CPU,
> > > which then sees the IRQ_INPROGESS flag, masks it and flags it
> > > PENDING. When the primary handler on the first CPU returns, it sees
> > > the PENDING flag, unmasks and invokes the handler another time.
> > In this case, when IRQ_INPROGRESS flag is set, on another CPU, it will
> > mask and ack it, if before the primary handler on the first CPU returns,
> > the edge interrupt is raised again, it will be lost, right?
> Why will the interrupt be raised again?Is not it masked?I read tglx
I means because it is masked, if at this time device issues edge irq,
It will not be delivered and lost.

> statement as this:if the interrupt is being handled on one core, then
> the delivery of new interrupt can be on the second core and in that case
> it will see IRQ_INPROGRESS flag and it will *mask* it and set the flag
> as pending.So there is no chance of any new interrupt.
> > So I think set PENDING just confirm one time, it just depends on primary
> handler
> > execution time and irq frequency.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ