Re: Recent libpciaccess changes

[Joan Lledó]

Hi,

El 7/2/22 a les 11:42, Damien Zammit ha escrit:
> libpciaccess:
> I have not been able to prove it yet, but I think the function call
> pci_device_hurd_map_range() attempts to look up _SERVERS_BUS_PCI during
> bootstrap and fails because it does not exist (no root filesystem exists).

Yes, the hurd module is to be used only by nested arbiters and 
libpciaccess clients, and it assumes there's a fs with a master arbiter 
running at /servers/bus/pci

> Joan, I heard we are not supposed to use the hurd access method during 
> bootstrap,
> only the x86 access method.  Is this the problem, and if so, how can we fix 
> this?
> How did you envisage your mapping of regions to work during bootstrap when there
> is no filesystem access?

Regrettably I didn't think on that, because I'm not familiar with your 
work on rump (I'll watch your fosdem talk soon :)). And yes, it should 
use the x86 backend, but it calls pci_system_x86_create() at [1], does 
that call fail in your scenario? In that case it will take the hurd 
methods at [2] which includes the hurd_map_range() function, which needs 
a fs. That probably worked before my mapping implementation because 
there were no hurd mapping methods and the ones in the x86 module were 
being used in all cases.

Is there a way to detect, from the hurd_create() function, when is your 
scenario running? If so, the solution would be reassign 
pci_sys->methods->[map_range, unmap_range] back to the x86 ones in that 
case.

> Samuel suggested on IRC that we could make it try the x86 map range function 
> first
> and then fall back to hurd method, is there any problem with that?

I don't have the time now to study it, but I'd say that would bypass the 
protection set from the parent arbiter, since it would test the 
permissions the current user has over "mem", before testing the 
permissions in the file system created by the parent arbiter.

> Perhaps there is a better solution to make the access method selectable via a 
> parameter,
> instead of implementing fallback mechanisms and making assumptions about what 
> is running?
> Would that work better?
>
> In any case, we do need better testing of changes in different scenarios
> to not put a burden on Samuel to fix everything we break.

How can I reproduce your scenario?


--------
[1] 
https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/blob/master/src/hurd_pci.c#L619
[2] 
https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/blob/master/src/hurd_pci.c#L634