On Mon, Jan 2, 2017 at 12:35 AM, Kirill A. Shutemov
wrote:
> On Fri, Dec 30, 2016 at 06:08:27PM -0800, Andy Lutomirski wrote:
>> On Wed, Dec 28, 2016 at 6:53 PM, Carlos O'Donell wrote:
>> > On 12/26/2016 09:24 PM, Kirill A. Shutemov wrote:
>> >> On Mon, Dec 26, 2016 at 06:06:01PM -0800, Andy Luto
On Wed, Jan 11, 2017 at 11:31:25AM -0800, Linus Torvalds wrote:
> On Wed, Jan 11, 2017 at 11:20 AM, Andy Lutomirski wrote:
> >
> > Taking a step back, I think it would be fantastic if we could find a
> > way to make this work without any inheritable settings at all.
> > Perhaps we could have a per
On Wed, Jan 11, 2017 at 11:32 AM, Kirill A. Shutemov
wrote:
>
> Running legacy binary with full address space is valuable option.
I disagree.
It's simply not valuable enough to worry about. Especially when there
is a fairly trivial wrapper approach: just make a full-address-space
wrapper than ac
On Wed, Jan 11, 2017 at 11:20:38AM -0800, Andy Lutomirski wrote:
> On Wed, Jan 11, 2017 at 10:49 AM, Dave Hansen wrote:
> > On 01/11/2017 10:37 AM, Kirill A. Shutemov wrote:
> >>> How about preventing the max addr from being changed to too high a
> >>> value while MPX is on instead of overriding t
On Wed, Jan 11, 2017 at 11:20 AM, Andy Lutomirski wrote:
>
> Taking a step back, I think it would be fantastic if we could find a
> way to make this work without any inheritable settings at all.
> Perhaps we could have a per-mm value that is initialized to 2^47-1 on
> execve() and can be raised by
On Wed, Jan 11, 2017 at 10:49 AM, Dave Hansen wrote:
> On 01/11/2017 10:37 AM, Kirill A. Shutemov wrote:
>>> How about preventing the max addr from being changed to too high a
>>> value while MPX is on instead of overriding the set value? This would
>>> have the added benefit that it would preven
On 01/11/2017 10:37 AM, Kirill A. Shutemov wrote:
>> How about preventing the max addr from being changed to too high a
>> value while MPX is on instead of overriding the set value? This would
>> have the added benefit that it would prevent silent failures where you
>> think you've enabled large a
On Wed, Jan 11, 2017 at 10:09:17AM -0800, Andy Lutomirski wrote:
> On Wed, Jan 11, 2017 at 6:29 AM, Kirill A. Shutemov
> wrote:
> > On Thu, Jan 05, 2017 at 12:49:44PM -0800, Dave Hansen wrote:
> >> On 01/05/2017 12:14 PM, Andy Lutomirski wrote:
> >> >> I'm not sure I'm comfortable with this. Do o
On 01/11/2017 06:29 AM, Kirill A. Shutemov wrote:
> +#define mmap_max_addr() \
> +({ \
> + unsigned long max_addr = min(TASK_SIZE, rlimit(RLIMIT_VADDR)); \
> + /* At the moment, MPX cannot handle addresses above 47-bits */
On Wed, Jan 11, 2017 at 6:29 AM, Kirill A. Shutemov
wrote:
> On Thu, Jan 05, 2017 at 12:49:44PM -0800, Dave Hansen wrote:
>> On 01/05/2017 12:14 PM, Andy Lutomirski wrote:
>> >> I'm not sure I'm comfortable with this. Do other rlimit changes cause
>> >> silent data corruption? I'm pretty sure do
On Thu, Jan 05, 2017 at 12:49:44PM -0800, Dave Hansen wrote:
> On 01/05/2017 12:14 PM, Andy Lutomirski wrote:
> >> I'm not sure I'm comfortable with this. Do other rlimit changes cause
> >> silent data corruption? I'm pretty sure doing this to MPX would.
> >>
> > What actually goes wrong in this
On 01/05/2017 01:27 PM, Andy Lutomirski wrote:
> On Thu, Jan 5, 2017 at 12:49 PM, Dave Hansen wrote:
...
>> Remember, we already have (legacy MPX) binaries in the wild that have no
>> knowledge of this stuff. So, we can implicitly have the kernel bump
>> this rlimit around, but we can't expect us
On Thu, Jan 5, 2017 at 12:49 PM, Dave Hansen wrote:
> On 01/05/2017 12:14 PM, Andy Lutomirski wrote:
>>> I'm not sure I'm comfortable with this. Do other rlimit changes cause
>>> silent data corruption? I'm pretty sure doing this to MPX would.
>>>
>> What actually goes wrong in this case? That
On 01/05/2017 12:14 PM, Andy Lutomirski wrote:
>> I'm not sure I'm comfortable with this. Do other rlimit changes cause
>> silent data corruption? I'm pretty sure doing this to MPX would.
>>
> What actually goes wrong in this case? That is, what combination of
> MPX setup of subsequent allocatio
On Thu, Jan 5, 2017 at 11:39 AM, Dave Hansen wrote:
> On 01/05/2017 11:29 AM, Kirill A. Shutemov wrote:
>> On Thu, Jan 05, 2017 at 11:13:57AM -0800, Dave Hansen wrote:
>>> On 12/26/2016 05:54 PM, Kirill A. Shutemov wrote:
MM would use min(RLIMIT_VADDR, TASK_SIZE) as upper limit of virtual
>>>
On Thu, Jan 05, 2017 at 11:39:16AM -0800, Dave Hansen wrote:
> On 01/05/2017 11:29 AM, Kirill A. Shutemov wrote:
> > On Thu, Jan 05, 2017 at 11:13:57AM -0800, Dave Hansen wrote:
> >> On 12/26/2016 05:54 PM, Kirill A. Shutemov wrote:
> >>> MM would use min(RLIMIT_VADDR, TASK_SIZE) as upper limit of
On 01/05/2017 11:29 AM, Kirill A. Shutemov wrote:
> On Thu, Jan 05, 2017 at 11:13:57AM -0800, Dave Hansen wrote:
>> On 12/26/2016 05:54 PM, Kirill A. Shutemov wrote:
>>> MM would use min(RLIMIT_VADDR, TASK_SIZE) as upper limit of virtual
>>> address available to map by userspace.
>>
>> What happens
On Thu, Jan 05, 2017 at 11:13:57AM -0800, Dave Hansen wrote:
> On 12/26/2016 05:54 PM, Kirill A. Shutemov wrote:
> > MM would use min(RLIMIT_VADDR, TASK_SIZE) as upper limit of virtual
> > address available to map by userspace.
>
> What happens to existing mappings above the limit when this upper
On 12/26/2016 05:54 PM, Kirill A. Shutemov wrote:
> MM would use min(RLIMIT_VADDR, TASK_SIZE) as upper limit of virtual
> address available to map by userspace.
What happens to existing mappings above the limit when this upper limit
is dropped?
Similarly, why do we do with an application running
On Wed, Jan 4, 2017 at 6:19 AM, Kirill A. Shutemov wrote:
> On Tue, Jan 03, 2017 at 10:27:22AM -0800, Andy Lutomirski wrote:
>> On Tue, Jan 3, 2017 at 8:04 AM, Kirill A. Shutemov
>> wrote:
>> > And what about stack? I'm not sure that everybody would be happy with
>> > stack in the middle of addr
On Tue, Jan 03, 2017 at 10:27:22AM -0800, Andy Lutomirski wrote:
> On Tue, Jan 3, 2017 at 8:04 AM, Kirill A. Shutemov
> wrote:
> > And what about stack? I'm not sure that everybody would be happy with
> > stack in the middle of address space.
>
> I would, personally. I think that, for very larg
On Tuesday, January 3, 2017 2:09:16 PM CET Andy Lutomirski wrote:
> >
> >> When
> >> ADDR_LIMIT_EXPLICIT is in effect, prctl can set a 64-bit numeric
> >> limit. If ADDR_LIMIT_EXPLICIT is cleared, the prctl value stops being
> >> settable and reading it via prctl returns whatever is implied by the
On Tuesday, January 3, 2017 10:29:33 AM CET Andy Lutomirski wrote:
>
> Hmm. What if we approached this a bit differently? We could add a
> single new personality bit ADDR_LIMIT_EXPLICIT. Setting this bit
> cause PER_LINUX32_3GB etc to be automatically cleared.
Both the ADDR_LIMIT_32BIT and ADD
On Tue, Jan 3, 2017 at 2:07 PM, Arnd Bergmann wrote:
> On Tuesday, January 3, 2017 10:29:33 AM CET Andy Lutomirski wrote:
>>
>> Hmm. What if we approached this a bit differently? We could add a
>> single new personality bit ADDR_LIMIT_EXPLICIT. Setting this bit
>> cause PER_LINUX32_3GB etc to b
On Tue, Jan 3, 2017 at 5:18 AM, Arnd Bergmann wrote:
> On Monday, January 2, 2017 10:08:28 PM CET Andy Lutomirski wrote:
>>
>> > This seems to nicely address the same problem on arm64, which has
>> > run into the same issue due to the various page table formats
>> > that can currently be chosen at
On Tue, Jan 3, 2017 at 8:04 AM, Kirill A. Shutemov wrote:
> On Mon, Jan 02, 2017 at 10:08:28PM -0800, Andy Lutomirski wrote:
>> On Mon, Jan 2, 2017 at 12:44 AM, Arnd Bergmann wrote:
>> > On Tuesday, December 27, 2016 4:54:13 AM CET Kirill A. Shutemov wrote:
>> >> As with other resources you can s
On Mon, Jan 02, 2017 at 10:08:28PM -0800, Andy Lutomirski wrote:
> On Mon, Jan 2, 2017 at 12:44 AM, Arnd Bergmann wrote:
> > On Tuesday, December 27, 2016 4:54:13 AM CET Kirill A. Shutemov wrote:
> >> As with other resources you can set the limit lower than current usage.
> >> It would affect only
On Monday, January 2, 2017 10:08:28 PM CET Andy Lutomirski wrote:
>
> > This seems to nicely address the same problem on arm64, which has
> > run into the same issue due to the various page table formats
> > that can currently be chosen at compile time.
>
> On further reflection, I think this has
On Mon, Jan 2, 2017 at 12:44 AM, Arnd Bergmann wrote:
> On Tuesday, December 27, 2016 4:54:13 AM CET Kirill A. Shutemov wrote:
>> As with other resources you can set the limit lower than current usage.
>> It would affect only future virtual address space allocations.
I still don't buy all these u
On Mon, Dec 26, 2016 at 07:22:03PM -0800, Andy Lutomirski wrote:
> On Mon, Dec 26, 2016 at 6:24 PM, Kirill A. Shutemov
> wrote:
> > On Mon, Dec 26, 2016 at 06:06:01PM -0800, Andy Lutomirski wrote:
> >> On Mon, Dec 26, 2016 at 5:54 PM, Kirill A. Shutemov
> >> wrote:
> >> > This patch introduces ne
On Tuesday, December 27, 2016 4:54:13 AM CET Kirill A. Shutemov wrote:
> This patch introduces new rlimit resource to manage maximum virtual
> address available to userspace to map.
>
> On x86, 5-level paging enables 56-bit userspace virtual address space.
> Not all user space is ready to handle w
On Fri, Dec 30, 2016 at 06:08:27PM -0800, Andy Lutomirski wrote:
> On Wed, Dec 28, 2016 at 6:53 PM, Carlos O'Donell wrote:
> > On 12/26/2016 09:24 PM, Kirill A. Shutemov wrote:
> >> On Mon, Dec 26, 2016 at 06:06:01PM -0800, Andy Lutomirski wrote:
> >>> On Mon, Dec 26, 2016 at 5:54 PM, Kirill A. Sh
On Wed, Dec 28, 2016 at 6:53 PM, Carlos O'Donell wrote:
> On 12/26/2016 09:24 PM, Kirill A. Shutemov wrote:
>> On Mon, Dec 26, 2016 at 06:06:01PM -0800, Andy Lutomirski wrote:
>>> On Mon, Dec 26, 2016 at 5:54 PM, Kirill A. Shutemov
>>> wrote:
This patch introduces new rlimit resource to mana
On 12/26/2016 09:24 PM, Kirill A. Shutemov wrote:
> On Mon, Dec 26, 2016 at 06:06:01PM -0800, Andy Lutomirski wrote:
>> On Mon, Dec 26, 2016 at 5:54 PM, Kirill A. Shutemov
>> wrote:
>>> This patch introduces new rlimit resource to manage maximum virtual
>>> address available to userspace to map.
>
On Mon, Dec 26, 2016 at 6:24 PM, Kirill A. Shutemov
wrote:
> On Mon, Dec 26, 2016 at 06:06:01PM -0800, Andy Lutomirski wrote:
>> On Mon, Dec 26, 2016 at 5:54 PM, Kirill A. Shutemov
>> wrote:
>> > This patch introduces new rlimit resource to manage maximum virtual
>> > address available to userspa
On Mon, Dec 26, 2016 at 06:06:01PM -0800, Andy Lutomirski wrote:
> On Mon, Dec 26, 2016 at 5:54 PM, Kirill A. Shutemov
> wrote:
> > This patch introduces new rlimit resource to manage maximum virtual
> > address available to userspace to map.
> >
> > On x86, 5-level paging enables 56-bit userspace
On Mon, Dec 26, 2016 at 5:54 PM, Kirill A. Shutemov
wrote:
> This patch introduces new rlimit resource to manage maximum virtual
> address available to userspace to map.
>
> On x86, 5-level paging enables 56-bit userspace virtual address space.
> Not all user space is ready to handle wide addresse
This patch introduces new rlimit resource to manage maximum virtual
address available to userspace to map.
On x86, 5-level paging enables 56-bit userspace virtual address space.
Not all user space is ready to handle wide addresses. It's known that
at least some JIT compilers use high bit in pointe
38 matches
Mail list logo
