linux-kernel - Re: [patch 4/4] acpi: ioapic: Respect the resource flags

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: <54911823.3030602@linux.intel.com>
Date:	Wed, 17 Dec 2014 13:44:03 +0800
From:	Jiang Liu <jiang.liu@...ux.intel.com>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Yinghai Lu <yinghai@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [patch 4/4] acpi: ioapic: Respect the resource flags

Hi Thomas,
	Should I keep the development history or start from scratch
for this ACPI resource patch set?
Thanks!
Gerry

On 2014/12/12 19:43, Thomas Gleixner wrote:
> On Fri, 12 Dec 2014, Jiang Liu wrote:
>> On 2014/12/12 15:53, Thomas Gleixner wrote:
>>> On Thu, 11 Dec 2014, Yinghai Lu wrote:
>>>> On Thu, Dec 11, 2014 at 11:48 AM, Thomas Gleixner <tglx@...utronix.de> wrote:
>>>>> +static inline bool is_valid_mem_resource(struct resource *res)
>>>>> +{
>>>>> +       return !(res->flags & IORESOURCE_DISABLED) &&
>>>>> +               (res->flags & IORESOURCE_MEM);
>>>>> +}
>>>>> +
>>>> There is minor problem about mem pref handling, original code will ignore them.
>>>
>>> Bah. I missed that in that well documented function...
>>>
>>>> with this patch will let it follow through.
>>>>
>>>> should change is_valid_mem_resource to is_valid_mem_nonpref_resource()...
>>>>
>>>> +static inline bool is_valid_mem_nonpref_resource(struct resource *res)
>>>>  {
>>>>         return !(res->flags & IORESOURCE_DISABLED) &&
>>>> -               (res->flags & IORESOURCE_MEM);
>>>> +               (res->flags & IORESOURCE_MEM) &&
>>>> +               !(res->flags & IORESOURCE_PREFETCH);
>>>>  }
>>>
>>> Unfortunately that does not help, because nothing sets the
>>> IORESOURCE_PREFETCH flag. Will fix it proper.
>>>
>>> I still have no explanation why the translation offset needs to be
>>> applied here.
>> Hi Thomas,
>> 	I have read related section in ACPI spec, seems the addition
>> of translation_offset is redundant here.
>>
>> Quotation from ACPI spec 5a, 6.4.3.5.1
>> For bridges that translate addresses across the bridge, this is the
>> offset that must be added to the address on the secondary side to
>> obtain the address on the primary side. Non-bridge devices must list
>> 0 for all Address Translation offset bits.
>>
>> Quotation from ACPI spec 5, 9.17 I/O APIC Device:
>> It must also contain a _CRS object that reports the base address of the
>> I/O APIC device. The _CRS object is required to contain only one
>> resource, a memory resource pointing to the I/O APIC register base.
>>
>> IO APIC is not a bridge, so translation_offset should always be zero.
> 
> Right and we really need a proper interface for this on the acpi side,
> so we can avoid all that dance in the usage sites.
> 
> Thanks,
> 
> 	tglx
> --
> 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/
> 
--
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/