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]
Date:	Tue, 8 Feb 2011 15:05:06 +0000
From:	Ian Campbell <>
To:	Thomas Gleixner <>
CC:	Jeremy Fitzhardinge <>,
	LKML <>,
	Konrad Rzeszutek Wilk <>
Subject: Re: [patch 0/4] XEN: Interrupt cleanups

On Tue, 2011-02-08 at 14:55 +0000, Thomas Gleixner wrote:
> On Tue, 8 Feb 2011, Ian Campbell wrote:
> > On Mon, 2011-02-07 at 13:57 -0800, Jeremy Fitzhardinge wrote:
> > > On 02/07/2011 01:33 PM, Thomas Gleixner wrote:
> > > > Ok. The irq_chip conversion is mostly mechanical, but I'm really
> > > > concerned about that IRQ_SUSPENDED hackery. It'd be nice if you
> > > > resp. Ian could give that a test ride. That would allow me to cleanup
> > > > stuff in the core code.
> > > 
> > > Ian notes: "tglx's 4 patch interrupt cleanup series on LKML causes some
> > > oddities on PV migration. Will dig further tomorrow..."
> > > 
> > > So it looks like there's still something amiss.
> > 
> > The patches missed an indirect use of IRQF_NO_SUSPEND pulled in via
> > IRQF_TIMER. The following fixed things for me (probably belongs in your
> > patch 4/4).
> > 
> > With this fixlet PV guest migration works just fine. I also booted the
> > entire series as a dom0 kernel and it appeared fine.
> > 
> > I also tested alongside the cleanup patches Jeremy mentioned before and
> > as expected there is no interaction.
> > 
> > So, with the fixes to 2/4 (irq_move_irq think from yesterday) and 4/4
> > (below), the entire series is:
> > Acked-by: Ian Campbell <>
> Cool. So what's the best way to proceed ? That code is not yet in
> linus tree, right ?


> So I guess the best way is that I add the core changes to a rc-4 based
> branch and you can pull it in and apply the whole xen stuff to your
> own tree.

My existing cleanup patches are in Konrad's tree (which is in linux-next
etc) so that probably makes most sense as a home for this series. So
unless Konrad has any objections I think it makes sense to pull your
core changes into that branch and then apply your Xen bits on top.

Konrad's branch with my stuff is:
  git:// stable/irq.rework

Konrad, this thread starts at <>

> I base my pending patches on top of that so it wont be any problem
> when merging the stuff together in next or linus later.

I don't think there will be much trouble with overlap between these and
any Xen events.c changes for the next merge window but what you suggest
should remove the risk.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists