Re: [PATCH] pnp: replace deprecated __check_region torequest_region

From: Adam M Belay
Date: Thu Aug 11 2011 - 23:27:54 EST

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


Quoting Wang Shaoyan <stufever@xxxxxxxxx>:


2011/8/12 Bjorn Helgaas <bhelgaas@xxxxxxxxxx>:
We usually funnel PNP stuff through the linux-acpi@xxxxxxxxxxxxxxx
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() 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

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.


Wang Shaoyan

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