> On 09/20/16 18:07, H. Peter Anvin wrote:
> >
> >> - vvar is highly magical. IMO letting it get mapped with VM_MAYWRITE
> >> is asking for trouble, as anything that writes it will COW it, leading
> >> to strange malfunctions.
> >>
>
> The vvar page obviously needs to be mapped MAP_SHARED, and
> On 09/20/16 18:07, H. Peter Anvin wrote:
> >
> >> - vvar is highly magical. IMO letting it get mapped with VM_MAYWRITE
> >> is asking for trouble, as anything that writes it will COW it, leading
> >> to strange malfunctions.
> >>
>
> The vvar page obviously needs to be mapped MAP_SHARED, and
On 09/20/16 18:07, H. Peter Anvin wrote:
>
>> - vvar is highly magical. IMO letting it get mapped with VM_MAYWRITE
>> is asking for trouble, as anything that writes it will COW it, leading
>> to strange malfunctions.
>>
The vvar page obviously needs to be mapped MAP_SHARED, and the
underlying
On 09/20/16 18:07, H. Peter Anvin wrote:
>
>> - vvar is highly magical. IMO letting it get mapped with VM_MAYWRITE
>> is asking for trouble, as anything that writes it will COW it, leading
>> to strange malfunctions.
>>
The vvar page obviously needs to be mapped MAP_SHARED, and the
underlying
On 09/20/16 17:54, Andy Lutomirski wrote:
> - If vvar is in the same inode, then that inode won't be a valid ELF
> image, because the ELF header won't be in the right place.
So the vvar ought to move into an actual ELF segment, which is probably
The Right Thing anyway.
> - vvar is highly
On 09/20/16 17:54, Andy Lutomirski wrote:
> - If vvar is in the same inode, then that inode won't be a valid ELF
> image, because the ELF header won't be in the right place.
So the vvar ought to move into an actual ELF segment, which is probably
The Right Thing anyway.
> - vvar is highly
On Tue, Sep 20, 2016 at 5:32 PM, H. Peter Anvin wrote:
> On 09/20/16 17:22, H. Peter Anvin wrote:
>> The more I'm thinking about this, why don't we simply have these (the
>> various possible vdsos as well as vvar) as actual files in sysfs instead
>> of introducing a new
On Tue, Sep 20, 2016 at 5:32 PM, H. Peter Anvin wrote:
> On 09/20/16 17:22, H. Peter Anvin wrote:
>> The more I'm thinking about this, why don't we simply have these (the
>> various possible vdsos as well as vvar) as actual files in sysfs instead
>> of introducing a new filesystem? I don't
On 09/20/16 17:22, H. Peter Anvin wrote:
> The more I'm thinking about this, why don't we simply have these (the
> various possible vdsos as well as vvar) as actual files in sysfs instead
> of introducing a new filesystem? I don't believe sysfs actually has to
> be mounted in order for sysfs
On 09/20/16 17:22, H. Peter Anvin wrote:
> The more I'm thinking about this, why don't we simply have these (the
> various possible vdsos as well as vvar) as actual files in sysfs instead
> of introducing a new filesystem? I don't believe sysfs actually has to
> be mounted in order for sysfs
The more I'm thinking about this, why don't we simply have these (the
various possible vdsos as well as vvar) as actual files in sysfs instead
of introducing a new filesystem? I don't believe sysfs actually has to
be mounted in order for sysfs files to have an inode.
It could also be in procfs,
The more I'm thinking about this, why don't we simply have these (the
various possible vdsos as well as vvar) as actual files in sysfs instead
of introducing a new filesystem? I don't believe sysfs actually has to
be mounted in order for sysfs files to have an inode.
It could also be in procfs,
2016-08-26 17:42 GMT+03:00 Dmitry Safonov <0x7f454...@gmail.com>:
> 2016-08-26 17:32 GMT+03:00 Andy Lutomirski :
>> On Fri, Aug 26, 2016 at 4:16 AM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
>>> 2016-08-26 2:00 GMT+03:00 H. Peter Anvin :
On August 25,
2016-08-26 17:42 GMT+03:00 Dmitry Safonov <0x7f454...@gmail.com>:
> 2016-08-26 17:32 GMT+03:00 Andy Lutomirski :
>> On Fri, Aug 26, 2016 at 4:16 AM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
>>> 2016-08-26 2:00 GMT+03:00 H. Peter Anvin :
On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov
2016-08-26 17:32 GMT+03:00 Andy Lutomirski :
> On Fri, Aug 26, 2016 at 4:16 AM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
>> 2016-08-26 2:00 GMT+03:00 H. Peter Anvin :
>>> On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x7f454...@gmail.com>
>>> wrote:
2016-08-26 17:32 GMT+03:00 Andy Lutomirski :
> On Fri, Aug 26, 2016 at 4:16 AM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
>> 2016-08-26 2:00 GMT+03:00 H. Peter Anvin :
>>> On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x7f454...@gmail.com>
>>> wrote:
2016-08-25 23:49 GMT+03:00 H.
On Fri, Aug 26, 2016 at 4:16 AM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
> 2016-08-26 2:00 GMT+03:00 H. Peter Anvin :
>> On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x7f454...@gmail.com>
>> wrote:
>>>2016-08-25 23:49 GMT+03:00 H. Peter Anvin :
On
On Fri, Aug 26, 2016 at 4:16 AM, Dmitry Safonov <0x7f454...@gmail.com> wrote:
> 2016-08-26 2:00 GMT+03:00 H. Peter Anvin :
>> On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x7f454...@gmail.com>
>> wrote:
>>>2016-08-25 23:49 GMT+03:00 H. Peter Anvin :
On August 25, 2016 8:21:07 AM PDT,
2016-08-26 2:00 GMT+03:00 H. Peter Anvin :
> On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x7f454...@gmail.com>
> wrote:
>>2016-08-25 23:49 GMT+03:00 H. Peter Anvin :
>>> On August 25, 2016 8:21:07 AM PDT, Dmitry Safonov
>> wrote:
2016-08-26 2:00 GMT+03:00 H. Peter Anvin :
> On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x7f454...@gmail.com>
> wrote:
>>2016-08-25 23:49 GMT+03:00 H. Peter Anvin :
>>> On August 25, 2016 8:21:07 AM PDT, Dmitry Safonov
>> wrote:
This patches set is cleanly RFC and is not supposed to
On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x7f454...@gmail.com> wrote:
>2016-08-25 23:49 GMT+03:00 H. Peter Anvin :
>> On August 25, 2016 8:21:07 AM PDT, Dmitry Safonov
> wrote:
>>>This patches set is cleanly RFC and is not supposed to be applied.
On August 25, 2016 3:53:43 PM PDT, Dmitry Safonov <0x7f454...@gmail.com> wrote:
>2016-08-25 23:49 GMT+03:00 H. Peter Anvin :
>> On August 25, 2016 8:21:07 AM PDT, Dmitry Safonov
> wrote:
>>>This patches set is cleanly RFC and is not supposed to be applied.
>>>Also for RFC time it builds only on
2016-08-25 23:49 GMT+03:00 H. Peter Anvin :
> On August 25, 2016 8:21:07 AM PDT, Dmitry Safonov
> wrote:
>>This patches set is cleanly RFC and is not supposed to be applied.
>>Also for RFC time it builds only on x86_64.
>>
>>So, in a mail thread Oleg told
2016-08-25 23:49 GMT+03:00 H. Peter Anvin :
> On August 25, 2016 8:21:07 AM PDT, Dmitry Safonov
> wrote:
>>This patches set is cleanly RFC and is not supposed to be applied.
>>Also for RFC time it builds only on x86_64.
>>
>>So, in a mail thread Oleg told that it would be worth to introduce
On August 25, 2016 8:21:07 AM PDT, Dmitry Safonov
wrote:
>This patches set is cleanly RFC and is not supposed to be applied.
>Also for RFC time it builds only on x86_64.
>
>So, in a mail thread Oleg told that it would be worth to introduce
>vm_file
>for vdso mappings as
On August 25, 2016 8:21:07 AM PDT, Dmitry Safonov
wrote:
>This patches set is cleanly RFC and is not supposed to be applied.
>Also for RFC time it builds only on x86_64.
>
>So, in a mail thread Oleg told that it would be worth to introduce
>vm_file
>for vdso mappings as currently uprobes can not
26 matches
Mail list logo