linux-kernel - Re: [PATCH 09/16] iommu/amd: Add IOAPIC remapping routines

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: <20121001134753.GF4099@phenom.dumpdata.com>
Date:	Mon, 1 Oct 2012 09:47:53 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Joerg Roedel <joerg.roedel@....com>
Cc:	iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/16] iommu/amd: Add IOAPIC remapping routines

On Mon, Oct 01, 2012 at 10:40:51AM +0200, Joerg Roedel wrote:
> On Fri, Sep 28, 2012 at 10:45:15AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Sep 28, 2012 at 02:23:59PM +0200, Joerg Roedel wrote:
> > > +	/*
> > > +	 * Mask level triggered irqs.
> > > +	 * Use IRQ_DELAYED_DISABLE for edge triggered irqs.
> > 
> > so how come it is not set?
> 
> Don't understand this. What is not set?

the IRQ_DELAYED_DISABLE. But I could not even find that enum anymore?
Has that been obsoleted?
> 
> > > +	if (!config_enabled(CONFIG_SMP))
> > > +		return -1;
> > 
> > -1? -ENOx something?
> 
> No, -1 for compatibiblity with the other implementation of this.

OK.
> 
> > > +	err = apic->cpu_mask_to_apicid_and(cfg->domain, mask, &dest);
> > > +	if (err) {
> > > +		if (assign_irq_vector(irq, cfg, data->affinity))
> > > +			pr_err("AMD-Vi: Failed to recover vector for irq %d\n", irq);
> > 
> > If we do OK with the assignment of the vector, should we just continue
> > on instead of returning error?
> 
> The purpose of this is to recover to the old affinity if we failed at
> this point. Even in this case, setting the new affinity still failed and
> we need to inform the caller about this. Thus returning the error.
> Also note the pr_err message which also tells you about the
> recovery-case :)

I was thinking the other way around. You recover the old affinity. Should
you print out a warning mentioning to the system admin that you could not
set the new affinity but reverted to the old one? Or will that not serve
anything except spam the kernel logs?
--
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/