lkml.org 
[lkml]   [2017]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR
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
> <kirill@shutemov.name> 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 doing this to MPX would.
> >> >>
> >> > What actually goes wrong in this case? That is, what combination of
> >> > MPX setup of subsequent allocations will cause a problem, and is the
> >> > problem worse than just a segfault? IMO it would be really nice to
> >> > keep the messy case confined to MPX.
> >>
> >> The MPX bounds tables are indexed by virtual address. They need to grow
> >> if the virtual address space grows. There's an MSR that controls
> >> whether we use the 48-bit or 57-bit layout. It basically decides
> >> whether we need a 2GB (48-bit) or 1TB (57-bit) bounds directory.
> >>
> >> The question is what we do with legacy MPX applications. We obviously
> >> can't let them just allocate a 2GB table and then go let the hardware
> >> pretend it's 1TB in size. We also can't hand the hardware using a 2GB
> >> table an address >48-bits.
> >>
> >> Ideally, I'd like to make sure that legacy MPX can't be enabled if this
> >> RLIMIT is set over 48-bits (really 47). I'd also like to make sure that
> >> legacy MPX is active, that the RLIMIT can't be raised because all hell
> >> will break loose when the new addresses show up.
> >
> > I think we can do this. See the patch below.
> >
> > Basically, we refuse to enable MPX and issue warning in dmesg if there's
> > anything mapped above 47-bits. Once MPX is enabled, mmap_max_addr() cannot
> > be higher than 47-bits too.
> >
> > Function call from mmap_max_addr() is unfortunate, but I don't see a
> > way around.
>
> 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 addresses but MPX is also on and mmap
> refuses to return large addresses.

Setting rlimit high doesn't mean that you necessary will get access to
full address space, even without MPX in picture. TASK_SIZE limits the
available address space too.

I think it's consistent with other resources in rlimit: setting RLIMIT_RSS
to unlimited doesn't really means you are not subject to other resource
management.

--
Kirill A. Shutemov

\
 
 \ /
  Last update: 2017-01-11 19:38    [W:0.104 / U:6.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site