[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] new interface: memory_object_get_proxy
From: |
Samuel Thibault |
Subject: |
Re: [PATCH] new interface: memory_object_get_proxy |
Date: |
Sat, 30 Oct 2021 15:27:00 +0200 |
User-agent: |
NeoMutt/20170609 (1.8.3) |
Joan Lledó, le sam. 30 oct. 2021 08:38:23 +0200, a ecrit:
> > I don't think you can access the entry once you've unlocked the map.
> >
>
> You're probably right b/c it doesn't seem the entry is being accessed after
> the lock release in any other place of the code.
You have to, yes. The problem is what if another threads tries to unmap
the address range concurrently. You want to keep the lock held until
you acquired a ref on the memory object. Then you are safe: the ref
guarantees that the memory object won't disappear. And from the rest of
the discussion it seems you indeed need such a ref, which you'll just
transfer to the creation of the proxy.
Samuel
- Re: gnumach RPC: get info about the calling task, (continued)
- Re: gnumach RPC: get info about the calling task, Joan Lledó, 2021/10/24
- [PATCH] new interface: memory_object_get_proxy, Joan Lledó, 2021/10/24
- Re: [PATCH] new interface: memory_object_get_proxy, Sergey Bugaev, 2021/10/24
- Re: [PATCH] new interface: memory_object_get_proxy, Joan Lledó, 2021/10/30
- Re: [PATCH] new interface: memory_object_get_proxy, Sergey Bugaev, 2021/10/30
- Re: [PATCH] new interface: memory_object_get_proxy, Sergey Bugaev, 2021/10/30
- Re: [PATCH] new interface: memory_object_get_proxy, Samuel Thibault, 2021/10/30
- Re: [PATCH] new interface: memory_object_get_proxy,
Samuel Thibault <=