On Fri, Jun 27, 2014 at 10:42 AM, Dave Hansen wrote:
> On 06/27/2014 10:34 AM, Dave Hansen wrote:
>> I'm claiming that we need COW behavior for the bounds tables, at least
>> by default. If userspace knows enough about the ways that it is using
>> the tables and knows how to share them, let it
On 06/27/2014 10:34 AM, Dave Hansen wrote:
> I'm claiming that we need COW behavior for the bounds tables, at least
> by default. If userspace knows enough about the ways that it is using
> the tables and knows how to share them, let it go to town. The kernel
> will permit this kind of usage
On 06/26/2014 05:26 PM, Andy Lutomirski wrote:
> On Thu, Jun 26, 2014 at 5:19 PM, Dave Hansen wrote:
>> On 06/26/2014 04:15 PM, Andy Lutomirski wrote:
>>> Also, egads: what happens when a bound table entry is associated with
>>> a MAP_SHARED page?
>>
>> Bounds table entries are for pointers. Do
On 06/26/2014 05:26 PM, Andy Lutomirski wrote:
On Thu, Jun 26, 2014 at 5:19 PM, Dave Hansen dave.han...@intel.com wrote:
On 06/26/2014 04:15 PM, Andy Lutomirski wrote:
Also, egads: what happens when a bound table entry is associated with
a MAP_SHARED page?
Bounds table entries are for
On 06/27/2014 10:34 AM, Dave Hansen wrote:
I'm claiming that we need COW behavior for the bounds tables, at least
by default. If userspace knows enough about the ways that it is using
the tables and knows how to share them, let it go to town. The kernel
will permit this kind of usage model,
On Fri, Jun 27, 2014 at 10:42 AM, Dave Hansen dave.han...@intel.com wrote:
On 06/27/2014 10:34 AM, Dave Hansen wrote:
I'm claiming that we need COW behavior for the bounds tables, at least
by default. If userspace knows enough about the ways that it is using
the tables and knows how to share
On Thu, Jun 26, 2014 at 5:19 PM, Dave Hansen wrote:
> On 06/26/2014 04:15 PM, Andy Lutomirski wrote:
>> So here's my mental image of how I might do this if I were doing it
>> entirely in userspace: I'd create a file or memfd for the bound tables
>> and another for the bound directory. These
On 06/26/2014 04:15 PM, Andy Lutomirski wrote:
> So here's my mental image of how I might do this if I were doing it
> entirely in userspace: I'd create a file or memfd for the bound tables
> and another for the bound directory. These files would be *huge*: the
> bound directory file would be 2GB
On Thu, Jun 26, 2014 at 3:58 PM, Dave Hansen wrote:
> On 06/26/2014 03:19 PM, Andy Lutomirski wrote:
>> On Wed, Jun 25, 2014 at 2:45 PM, Dave Hansen wrote:
>>> On 06/25/2014 02:05 PM, Andy Lutomirski wrote:
Hmm. the memfd_create thing may be able to do this for you. If you
created a
On 06/26/2014 03:19 PM, Andy Lutomirski wrote:
> On Wed, Jun 25, 2014 at 2:45 PM, Dave Hansen wrote:
>> On 06/25/2014 02:05 PM, Andy Lutomirski wrote:
>>> Hmm. the memfd_create thing may be able to do this for you. If you
>>> created a per-mm memfd and mapped it, it all just might work.
>>
>>
On Wed, Jun 25, 2014 at 2:45 PM, Dave Hansen wrote:
> On 06/25/2014 02:05 PM, Andy Lutomirski wrote:
>> Hmm. the memfd_create thing may be able to do this for you. If you
>> created a per-mm memfd and mapped it, it all just might work.
>
> memfd_create() seems to bring a fair amount of baggage
On 06/25/2014 02:05 PM, Andy Lutomirski wrote:
> Hmm. the memfd_create thing may be able to do this for you. If you
> created a per-mm memfd and mapped it, it all just might work.
memfd_create() seems to bring a fair amount of baggage along (the fd
part :) if all we want is a marker. Really,
On 06/25/2014 02:05 PM, Andy Lutomirski wrote:
Hmm. the memfd_create thing may be able to do this for you. If you
created a per-mm memfd and mapped it, it all just might work.
memfd_create() seems to bring a fair amount of baggage along (the fd
part :) if all we want is a marker. Really, all
On Wed, Jun 25, 2014 at 2:45 PM, Dave Hansen dave.han...@intel.com wrote:
On 06/25/2014 02:05 PM, Andy Lutomirski wrote:
Hmm. the memfd_create thing may be able to do this for you. If you
created a per-mm memfd and mapped it, it all just might work.
memfd_create() seems to bring a fair
On 06/26/2014 03:19 PM, Andy Lutomirski wrote:
On Wed, Jun 25, 2014 at 2:45 PM, Dave Hansen dave.han...@intel.com wrote:
On 06/25/2014 02:05 PM, Andy Lutomirski wrote:
Hmm. the memfd_create thing may be able to do this for you. If you
created a per-mm memfd and mapped it, it all just might
On Thu, Jun 26, 2014 at 3:58 PM, Dave Hansen dave.han...@intel.com wrote:
On 06/26/2014 03:19 PM, Andy Lutomirski wrote:
On Wed, Jun 25, 2014 at 2:45 PM, Dave Hansen dave.han...@intel.com wrote:
On 06/25/2014 02:05 PM, Andy Lutomirski wrote:
Hmm. the memfd_create thing may be able to do this
On 06/26/2014 04:15 PM, Andy Lutomirski wrote:
So here's my mental image of how I might do this if I were doing it
entirely in userspace: I'd create a file or memfd for the bound tables
and another for the bound directory. These files would be *huge*: the
bound directory file would be 2GB and
On Thu, Jun 26, 2014 at 5:19 PM, Dave Hansen dave.han...@intel.com wrote:
On 06/26/2014 04:15 PM, Andy Lutomirski wrote:
So here's my mental image of how I might do this if I were doing it
entirely in userspace: I'd create a file or memfd for the bound tables
and another for the bound
On 06/25/2014 02:04 PM, Andy Lutomirski wrote:
> On Tue, Jun 24, 2014 at 6:40 PM, Ren, Qiaowei wrote:
>> Hmm, _install_special_mapping should completely prevent merging, even among
>> MPX vmas.
>>
>> So, could you tell me how to set MPX specific ->name to the vma when it is
>> created? Seems
On Wed, Jun 25, 2014 at 2:04 PM, Andy Lutomirski wrote:
> On Tue, Jun 24, 2014 at 6:40 PM, Ren, Qiaowei wrote:
>> On 2014-06-25, Andy Lutomirski wrote:
>>> On Mon, Jun 23, 2014 at 10:53 PM, Ren, Qiaowei
>>> wrote:
On 2014-06-24, Andy Lutomirski wrote:
>> On 06/23/2014 01:06 PM, Andy
On Tue, Jun 24, 2014 at 6:40 PM, Ren, Qiaowei wrote:
> On 2014-06-25, Andy Lutomirski wrote:
>> On Mon, Jun 23, 2014 at 10:53 PM, Ren, Qiaowei
>> wrote:
>>> On 2014-06-24, Andy Lutomirski wrote:
> On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
>> Can the new vm_operation "name" be use
On Tue, Jun 24, 2014 at 6:40 PM, Ren, Qiaowei qiaowei@intel.com wrote:
On 2014-06-25, Andy Lutomirski wrote:
On Mon, Jun 23, 2014 at 10:53 PM, Ren, Qiaowei qiaowei@intel.com
wrote:
On 2014-06-24, Andy Lutomirski wrote:
On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
Can the new
On Wed, Jun 25, 2014 at 2:04 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Jun 24, 2014 at 6:40 PM, Ren, Qiaowei qiaowei@intel.com wrote:
On 2014-06-25, Andy Lutomirski wrote:
On Mon, Jun 23, 2014 at 10:53 PM, Ren, Qiaowei qiaowei@intel.com
wrote:
On 2014-06-24, Andy
On 06/25/2014 02:04 PM, Andy Lutomirski wrote:
On Tue, Jun 24, 2014 at 6:40 PM, Ren, Qiaowei qiaowei@intel.com wrote:
Hmm, _install_special_mapping should completely prevent merging, even among
MPX vmas.
So, could you tell me how to set MPX specific -name to the vma when it is
created?
On 2014-06-25, Andy Lutomirski wrote:
> On Mon, Jun 23, 2014 at 10:53 PM, Ren, Qiaowei
> wrote:
>> On 2014-06-24, Andy Lutomirski wrote:
On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
> Can the new vm_operation "name" be use for this? The magic
> "always written to core dumps"
On Mon, Jun 23, 2014 at 10:53 PM, Ren, Qiaowei wrote:
> On 2014-06-24, Andy Lutomirski wrote:
>>> On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
Can the new vm_operation "name" be use for this? The magic "always
written to core dumps" feature might need to be reconsidered.
>>>
>>> One
On Mon, Jun 23, 2014 at 10:53 PM, Ren, Qiaowei qiaowei@intel.com wrote:
On 2014-06-24, Andy Lutomirski wrote:
On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
Can the new vm_operation name be use for this? The magic always
written to core dumps feature might need to be reconsidered.
One
On 2014-06-25, Andy Lutomirski wrote:
On Mon, Jun 23, 2014 at 10:53 PM, Ren, Qiaowei qiaowei@intel.com
wrote:
On 2014-06-24, Andy Lutomirski wrote:
On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
Can the new vm_operation name be use for this? The magic
always written to core dumps
On 2014-06-24, Andy Lutomirski wrote:
>> On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
>>> Can the new vm_operation "name" be use for this? The magic "always
>>> written to core dumps" feature might need to be reconsidered.
>>
>> One thing I'd like to avoid is an MPX vma getting merged with a
On 2014-06-24, Andy Lutomirski wrote:
>> +/* Make bounds tables and bouds directory unlocked. */
>> +if (vm_flags & VM_LOCKED)
>> +vm_flags &= ~VM_LOCKED;
>
> Why? I would expect MCL_FUTURE to lock these.
>
Andy, I was just a little confused about LOCKED & POPULATE earlier
On Mon, Jun 23, 2014 at 1:28 PM, Dave Hansen wrote:
> On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
>> Can the new vm_operation "name" be use for this? The magic "always
>> written to core dumps" feature might need to be reconsidered.
>
> One thing I'd like to avoid is an MPX vma getting merged
On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
> Can the new vm_operation "name" be use for this? The magic "always
> written to core dumps" feature might need to be reconsidered.
One thing I'd like to avoid is an MPX vma getting merged with a non-MPX
vma. I don't see any code to prevent two
On Mon, Jun 23, 2014 at 1:03 PM, Dave Hansen wrote:
> On 06/23/2014 12:49 PM, Andy Lutomirski wrote:
>> On 06/18/2014 02:44 AM, Qiaowei Ren wrote:
>>> This patch adds one MPX specific mmap interface, which only handles
>>> mpx related maps, including bounds table and bounds directory.
>>>
>>> In
On 06/23/2014 12:49 PM, Andy Lutomirski wrote:
> On 06/18/2014 02:44 AM, Qiaowei Ren wrote:
>> This patch adds one MPX specific mmap interface, which only handles
>> mpx related maps, including bounds table and bounds directory.
>>
>> In order to track MPX specific memory usage, this interface is
On 06/18/2014 02:44 AM, Qiaowei Ren wrote:
> This patch adds one MPX specific mmap interface, which only handles
> mpx related maps, including bounds table and bounds directory.
>
> In order to track MPX specific memory usage, this interface is added
> to stick new vm_flag VM_MPX in the
On 06/18/2014 02:44 AM, Qiaowei Ren wrote:
This patch adds one MPX specific mmap interface, which only handles
mpx related maps, including bounds table and bounds directory.
In order to track MPX specific memory usage, this interface is added
to stick new vm_flag VM_MPX in the
On 06/23/2014 12:49 PM, Andy Lutomirski wrote:
On 06/18/2014 02:44 AM, Qiaowei Ren wrote:
This patch adds one MPX specific mmap interface, which only handles
mpx related maps, including bounds table and bounds directory.
In order to track MPX specific memory usage, this interface is added
to
On Mon, Jun 23, 2014 at 1:03 PM, Dave Hansen dave.han...@intel.com wrote:
On 06/23/2014 12:49 PM, Andy Lutomirski wrote:
On 06/18/2014 02:44 AM, Qiaowei Ren wrote:
This patch adds one MPX specific mmap interface, which only handles
mpx related maps, including bounds table and bounds directory.
On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
Can the new vm_operation name be use for this? The magic always
written to core dumps feature might need to be reconsidered.
One thing I'd like to avoid is an MPX vma getting merged with a non-MPX
vma. I don't see any code to prevent two VMAs
On Mon, Jun 23, 2014 at 1:28 PM, Dave Hansen dave.han...@intel.com wrote:
On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
Can the new vm_operation name be use for this? The magic always
written to core dumps feature might need to be reconsidered.
One thing I'd like to avoid is an MPX vma
On 2014-06-24, Andy Lutomirski wrote:
+/* Make bounds tables and bouds directory unlocked. */
+if (vm_flags VM_LOCKED)
+vm_flags = ~VM_LOCKED;
Why? I would expect MCL_FUTURE to lock these.
Andy, I was just a little confused about LOCKED POPULATE earlier and I
On 2014-06-24, Andy Lutomirski wrote:
On 06/23/2014 01:06 PM, Andy Lutomirski wrote:
Can the new vm_operation name be use for this? The magic always
written to core dumps feature might need to be reconsidered.
One thing I'd like to avoid is an MPX vma getting merged with a
non-MPX vma. I
42 matches
Mail list logo
