linux-kernel - Re: [PATCH] pnp: replace deprecated __check_region to request

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:	Thu, 11 Aug 2011 23:27:35 -0400
From:	Adam M Belay <abelay@....EDU>
To:	Wang Shaoyan <stufever@...il.com>
Cc:	Bjorn Helgaas <bhelgaas@...gle.com>, linux-kernel@...r.kernel.org,
	Wang Shaoyan <wangshaoyan.pt@...bao.com>,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH] pnp: replace deprecated __check_region to
	request_region

Hi Wang,

Yes, I think your description of the race condition is right. However, 
as Bjorn
mentioned, there are many x86 init paths that will try to reserve the same
resources as those reported by pnp/acpi. There needs to be a better way to
coordinate legacy device enumeration. Otherwise, the request_region() calls
could fail when there isn't an actual resource conflict.

IF we could find a good way to clean up the legacy users of request_region()
then we could probably make pnp behave more like pci with regard to resource
reservations.

Cheers,
Adam

Quoting Wang Shaoyan <stufever@...il.com>:

> Hi
>
> 2011/8/12 Bjorn Helgaas <bhelgaas@...gle.com>:
>> We usually funnel PNP stuff through the linux-acpi@...r.kernel.org
>> mailing list, so I added a cc: to it.
>>
>
> Thanks for your reminding!
>
>> request_region() is not a drop-in replacement for __check_region()
>> because __check_region() releases the resource before it returns
>> success.  I agree that it would be good to get rid of
>> __check_region(), but I think it's a little more work than just this.
>>
>> I suppose you could just do the release_resource() in
>> pnp_check_port(), after request_region() was successful.  But the
>> problem with __check_region() is that it's racy, and moving the
>> release_resource() into pnp_check_port() doesn't remove the race.  It
>> just moves the problem from __check_region() (which is easy to grep
>> for) into PNP (where it's not so obvious).
>>
>
> I don't think the racy is still exist. In old days, the racy is exist
> in this situation:
> check_region()
> ...do something    <-- here another process may do check and request 
> same region
> request_region()   <-- if some process request the same resource, it
> will fail here
>
> But nowadays, request_region has replaced the check_region, it will
> check and request in the same function, so no racy still exist. Am I
> right?
>
>> Part of the problem is that the PNP core doesn't actually request any
>> of the resources used by PNP devices.  The PCI core *does* reserve
>> resources, independent of any drivers, and it would certainly be
>> reasonable to expect the PNP core to do the same, but it doesn't.
>> This is mostly because there are a bunch of hardcoded legacy resources
>> that conflict with PNP devices, and we haven't figured out a good way
>> to resolve the conflicts.
>>
>> Bjorn
>>
>
>
>
> --
> Wang Shaoyan
>


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