linux-kernel - Re: [PATCH 1/4] x86: fix assign_irq

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]

Date:	Fri, 12 Dec 2008 10:20:41 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	Mike Travis <travis@....com>, Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] x86: fix assign_irq_vector boot up problem


* Rusty Russell <rusty@...tcorp.com.au> wrote:

> On Thursday 11 December 2008 21:58:07 Mike Travis wrote:
> > Impact: fix boot up problem.
> > 
> > Fix a problem encountered with the Intel SATA-AHCI disk driver
> > right at system startup.  Cpumask_intersects really needs to be
> > a 3-way intersect, and since we need a cpumask_var_t later on,
> > then just use it for the 3-way intersect as well.
> 
> This one looks fine.
> 
> My plan was for Ingo to pull that for-ingo tree into his cpus4096 tree 
> and take the x86 patches from there.  But he hasn't so maybe I should 
> take this chance to fold that patch in?

i have no objections against the bits - just the sparseirq complication 
came in. A lot of effort went into irq/sparseirq's io_apic.c changes and 
cleanup.

So to do this cleanly, i merged those bits into cpus4096 and the 
x86/reboot bits as well - now the plan would be for Mike to send a 
(rebased) series against that base. I tried a plain merge and the 
conflicts in io_apic.c were a horrendous 76 rejects due to the 
irq/sparseirq interaction. Also, some of the commits subjects looked a 
bit raw so this bit of the tree needs to be redone.

(Note that the existing cpumask-base+scheduler bits in cpus4096 are 
golden already and we dont have to touch them in any way, it's just the 
new x86 bits and new cpumask infrastructure bits that look odd or 
clashy.)

	Ingo
--
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/