Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1552270
| From | "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR |
| Date | 2017-01-05 20:40 +0100 |
| Message-ID | <sWm3f-7kY-15@gated-at.bofh.it> (permalink) |
| References | <sSPdv-45l-3@gated-at.bofh.it> <sSPdB-45l-27@gated-at.bofh.it> <sWlJT-7ej-9@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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 limit > is dropped? Nothing: we only prevent creating new mappings. All existing are not affected. The semantics here the same as with other resource limits. > Similarly, why do we do with an application running with something > incompatible with the larger address space that tries to raise the > limit? Say, legacy MPX. It has to know what it does. Yes, it can change limit to the point where application is unusable. But you can to the same with other limits. -- Kirill A. Shutemov
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Dave Hansen <dave.hansen@intel.com> - 2017-01-05 20:20 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-01-05 20:40 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Dave Hansen <dave.hansen@intel.com> - 2017-01-05 20:40 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-05 21:20 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Dave Hansen <dave.hansen@intel.com> - 2017-01-05 21:50 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-05 22:30 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Dave Hansen <dave.hansen@intel.com> - 2017-01-06 00:20 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-11 15:30 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-11 19:10 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-11 19:40 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Dave Hansen <dave.hansen@intel.com> - 2017-01-11 20:00 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andy Lutomirski <luto@amacapital.net> - 2017-01-11 20:30 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Linus Torvalds <torvalds@linux-foundation.org> - 2017-01-11 20:40 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Andi Kleen <ak@linux.intel.com> - 2017-01-11 22:50 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-11 20:40 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Linus Torvalds <torvalds@linux-foundation.org> - 2017-01-11 20:40 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR Dave Hansen <dave.hansen@intel.com> - 2017-01-11 19:30 +0100
Re: [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-01-05 21:20 +0100
csiph-web