Re: [PATCH] pnp: replace deprecated __check_region to request_region

From: Wang Shaoyan
Date: Thu Aug 11 2011 - 22:23:39 EST


Hi

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()
...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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/