Re: PCI arbiter crash on last qemu image

From	Damien Zammit <damien@zamaudio.com>
Newsgroups	gnu.hurd.bug
Subject	Re: PCI arbiter crash on last qemu image
Date	2020-08-18 14:28 +1000
Message-ID	<mailman.131.1597724918.2469.bug-hurd@gnu.org> (permalink)
References	(1 earlier) <2f03cf83-9dff-1b92-a6e0-96ae20bfda49@zamaudio.com> <e3d57b71-af84-c035-7799-0c4dc6bfdae4@mailfence.com> <c5ae2597-dd25-58f6-8aa2-18b60b91fe5f@zamaudio.com> <ce86a983-886d-cf4d-bb44-106a17ad9282@mailfence.com> <36514972-223d-5a32-d5d9-c102caa9d715@zamaudio.com>

Show all headers | View raw

On 18/8/20 6:51 am, Joan Lledó wrote:
> El 17/8/20 a les 1:51, Damien Zammit ha escrit:
>> Perhaps a better way to fix the mapping problem I encountered
>> is by removing the check for previous mappings when trying to map regions,
> 
> I could check the pointer before reading from it at func_files.c, and if
> it happens to be null, then call the libpciaccess mapping function from
> there, i.e. mapping the memory in the first access instead of doing it
> during the startup. So there's no need to make any changes in your
> patch, do you think that'd work?
> 

That would probably work, but I don't want to break other usages of pciaccess
by including my change upstream, doing it your way would mean every other use case
for pciaccess would need to do the same thing as you are suggesting.

Perhaps we can just remove the check instead after all in pciaccess,
as that would be compatible with existing code.

Damien

Back to gnu.hurd.bug | Previous | Next | Find similar

Thread

Re: PCI arbiter crash on last qemu image Damien Zammit <damien@zamaudio.com> - 2020-08-18 14:28 +1000

csiph-web