Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1552274
| From | Dave Hansen <dave.hansen@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-17@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> <sWm3f-7kY-15@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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 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. 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.
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