On Tue, Aug 04, 2020 at 08:44:42AM +, David Laight wrote:
> From: James Bottomley
> > Sent: 03 August 2020 16:43
> >
> > On Mon, 2020-08-03 at 10:28 -0500, Eric W. Biederman wrote:
> > [...]
> > > What is wrong with live migration between one qemu process and
> > > another qemu process on the
From: James Bottomley
> Sent: 03 August 2020 16:43
>
> On Mon, 2020-08-03 at 10:28 -0500, Eric W. Biederman wrote:
> [...]
> > What is wrong with live migration between one qemu process and
> > another qemu process on the same machine not work for this use case?
> >
> > Just reusing live
On 8/3/2020 11:42 AM, James Bottomley wrote:
> On Mon, 2020-08-03 at 10:28 -0500, Eric W. Biederman wrote:
> [...]
>> What is wrong with live migration between one qemu process and
>> another qemu process on the same machine not work for this use case?
>>
>> Just reusing live migration would seem
On 8/3/2020 11:28 AM, ebied...@xmission.com wrote:
> Steven Sistare writes:
>> On 7/30/2020 5:58 PM, ebied...@xmission.com wrote:
>>> Here is another suggestion.
>>>
>>> Have a very simple program that does:
>>>
>>> for (;;) {
>>> handle = dlopen("/my/real/program");
>>>
On Mon, 2020-08-03 at 10:28 -0500, Eric W. Biederman wrote:
[...]
> What is wrong with live migration between one qemu process and
> another qemu process on the same machine not work for this use case?
>
> Just reusing live migration would seem to be the simplest path of
> all, as the code is
Steven Sistare writes:
> On 7/30/2020 5:58 PM, ebied...@xmission.com wrote:
>> Here is another suggestion.
>>
>> Have a very simple program that does:
>>
>> for (;;) {
>> handle = dlopen("/my/real/program");
>> real_main = dlsym(handle, "main");
>>
> Maybe. We still need to preserve an anonymous segment, though. MADV_DOEXEC,
> or mshare,
> or something else. And I think the ability to preserve memory containing
> pointers to itself
> is an interesting use case, though not ours.
Why does all this remind me of the old sendmail code.
On 7/27/2020 1:11 PM, Anthony Yznaga wrote:
> This patchset adds support for preserving an anonymous memory range across
> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
> sharing memory in this manner, as opposed to re-attaching to a named shared
> memory segment, is
On 7/31/2020 1:48 PM, Jason Gunthorpe wrote:
> On Fri, Jul 31, 2020 at 01:15:34PM -0400, Steven Sistare wrote:
>> On 7/31/2020 12:56 PM, Jason Gunthorpe wrote:
>>> On Fri, Jul 31, 2020 at 12:11:52PM -0400, Steven Sistare wrote:
> Your preservation-across-exec use-case might or might not need
On Fri, Jul 31, 2020 at 01:15:34PM -0400, Steven Sistare wrote:
> On 7/31/2020 12:56 PM, Jason Gunthorpe wrote:
> > On Fri, Jul 31, 2020 at 12:11:52PM -0400, Steven Sistare wrote:
> >>> Your preservation-across-exec use-case might or might not need the
> >>> VMA to be mapped at the same address.
On Fri, Jul 31, 2020 at 12:11:52PM -0400, Steven Sistare wrote:
> On 7/31/2020 11:27 AM, Matthew Wilcox wrote:
> > On Fri, Jul 31, 2020 at 10:57:44AM -0400, Steven Sistare wrote:
> >> Matthews sileby/mshare proposal has the same issue. If a process opts-in
> >> and mmap's an address in the shared
On 7/31/2020 12:56 PM, Jason Gunthorpe wrote:
> On Fri, Jul 31, 2020 at 12:11:52PM -0400, Steven Sistare wrote:
>>> Your preservation-across-exec use-case might or might not need the
>>> VMA to be mapped at the same address.
>>
>> It does. qemu registers memory with vfio which remembers the
On Fri, Jul 31, 2020 at 12:11:52PM -0400, Steven Sistare wrote:
> > Your preservation-across-exec use-case might or might not need the
> > VMA to be mapped at the same address.
>
> It does. qemu registers memory with vfio which remembers the va's in kernel
> metadata for the device.
Once the
On 7/31/2020 11:27 AM, Matthew Wilcox wrote:
> On Fri, Jul 31, 2020 at 10:57:44AM -0400, Steven Sistare wrote:
>> Matthews sileby/mshare proposal has the same issue. If a process opts-in
>> and mmap's an address in the shared region, then content becomes mapped at
>> a VA that was known to the
On Fri, Jul 31, 2020 at 10:57:44AM -0400, Steven Sistare wrote:
> Matthews sileby/mshare proposal has the same issue. If a process opts-in
> and mmap's an address in the shared region, then content becomes mapped at
> a VA that was known to the pre-fork or pre-exec process. Trust must still
> be
On 7/30/2020 5:58 PM, ebied...@xmission.com wrote:
> Steven Sistare writes:
>> On 7/30/2020 1:49 PM, Matthew Wilcox wrote:
>>> On Thu, Jul 30, 2020 at 01:35:51PM -0400, Steven Sistare wrote:
mshare + VA reservation is another possible solution.
Or MADV_DOEXEC alone, which is ready
Hi,
Sileby looks interesting! I had just written up the following idea which
seems similar but includes a mechanism for revoking mappings.
Alexander Graf recently brought up an idea that solves the following
problem:
When process A passes shared memory file descriptors to process B there
is no
Steven Sistare writes:
> On 7/30/2020 1:49 PM, Matthew Wilcox wrote:
>> On Thu, Jul 30, 2020 at 01:35:51PM -0400, Steven Sistare wrote:
>>> mshare + VA reservation is another possible solution.
>>>
>>> Or MADV_DOEXEC alone, which is ready now. I hope we can get back to
>>> reviewing that.
>>
On 7/30/2020 1:49 PM, Matthew Wilcox wrote:
> On Thu, Jul 30, 2020 at 01:35:51PM -0400, Steven Sistare wrote:
>> mshare + VA reservation is another possible solution.
>>
>> Or MADV_DOEXEC alone, which is ready now. I hope we can get back to
>> reviewing that.
>
> We are. This is the part of
On Thu, Jul 30, 2020 at 01:35:51PM -0400, Steven Sistare wrote:
> mshare + VA reservation is another possible solution.
>
> Or MADV_DOEXEC alone, which is ready now. I hope we can get back to
> reviewing that.
We are. This is the part of the review process where we explore other
solutions to
On 7/30/2020 1:12 PM, Matthew Wilcox wrote:
> On Thu, Jul 30, 2020 at 11:59:42AM -0400, Steven Sistare wrote:
>> On 7/30/2020 11:22 AM, Matthew Wilcox wrote:
>>> On Mon, Jul 27, 2020 at 10:11:22AM -0700, Anthony Yznaga wrote:
This patchset adds support for preserving an anonymous memory range
On Thu, Jul 30, 2020 at 11:59:42AM -0400, Steven Sistare wrote:
> On 7/30/2020 11:22 AM, Matthew Wilcox wrote:
> > On Mon, Jul 27, 2020 at 10:11:22AM -0700, Anthony Yznaga wrote:
> >> This patchset adds support for preserving an anonymous memory range across
> >> exec(3) using a new madvise
On 7/30/2020 11:22 AM, Matthew Wilcox wrote:
> On Mon, Jul 27, 2020 at 10:11:22AM -0700, Anthony Yznaga wrote:
>> This patchset adds support for preserving an anonymous memory range across
>> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
>> sharing memory in this
On Thu, Jul 30, 2020 at 04:34:50PM +0100, Matthew Wilcox wrote:
> On Thu, Jul 30, 2020 at 05:27:05PM +0200, Christian Brauner wrote:
> > On Thu, Jul 30, 2020 at 04:22:50PM +0100, Matthew Wilcox wrote:
> > > On Mon, Jul 27, 2020 at 10:11:22AM -0700, Anthony Yznaga wrote:
> > > > This patchset adds
On Thu, Jul 30, 2020 at 05:27:05PM +0200, Christian Brauner wrote:
> On Thu, Jul 30, 2020 at 04:22:50PM +0100, Matthew Wilcox wrote:
> > On Mon, Jul 27, 2020 at 10:11:22AM -0700, Anthony Yznaga wrote:
> > > This patchset adds support for preserving an anonymous memory range across
> > > exec(3)
On Thu, Jul 30, 2020 at 04:22:50PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 27, 2020 at 10:11:22AM -0700, Anthony Yznaga wrote:
> > This patchset adds support for preserving an anonymous memory range across
> > exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
> >
On Mon, Jul 27, 2020 at 10:11:22AM -0700, Anthony Yznaga wrote:
> This patchset adds support for preserving an anonymous memory range across
> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
> sharing memory in this manner, as opposed to re-attaching to a named shared
>
On 7/28/20 4:34 AM, Kirill Tkhai wrote:
> On 27.07.2020 20:11, Anthony Yznaga wrote:
>> This patchset adds support for preserving an anonymous memory range across
>> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
>> sharing memory in this manner, as opposed to
On 7/28/2020 10:23 AM, Andy Lutomirski wrote:
>> On Jul 27, 2020, at 10:02 AM, Anthony Yznaga
>> wrote:
>>
>> This patchset adds support for preserving an anonymous memory range across
>> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
>> sharing memory in this
> On Jul 27, 2020, at 10:02 AM, Anthony Yznaga
> wrote:
>
> This patchset adds support for preserving an anonymous memory range across
> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
> sharing memory in this manner, as opposed to re-attaching to a named shared
>
On Mon, Jul 27, 2020 at 02:00:17PM -0400, Steven Sistare wrote:
> On 7/27/2020 1:07 PM, ebied...@xmission.com wrote:
> > Anthony Yznaga writes:
> >
> >> This patchset adds support for preserving an anonymous memory range across
> >> exec(3) using a new madvise MADV_DOEXEC argument. The primary
On 27.07.2020 20:11, Anthony Yznaga wrote:
> This patchset adds support for preserving an anonymous memory range across
> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
> sharing memory in this manner, as opposed to re-attaching to a named shared
> memory segment, is to
On 7/27/2020 1:07 PM, ebied...@xmission.com wrote:
> Anthony Yznaga writes:
>
>> This patchset adds support for preserving an anonymous memory range across
>> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
>> sharing memory in this manner, as opposed to re-attaching
Anthony Yznaga writes:
> This patchset adds support for preserving an anonymous memory range across
> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
> sharing memory in this manner, as opposed to re-attaching to a named shared
> memory segment, is to ensure it is
This patchset adds support for preserving an anonymous memory range across
exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
sharing memory in this manner, as opposed to re-attaching to a named shared
memory segment, is to ensure it is mapped at the same virtual address in
35 matches
Mail list logo
