[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <657e6d0ada18e8ca0350bc6b3a80c49b3c0b341c.camel@intel.com>
Date: Sat, 13 Oct 2018 00:04:14 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "jannh@...gle.com" <jannh@...gle.com>
CC: "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"daniel@...earbox.net" <daniel@...earbox.net>, "keescook@...omium.org"
<keescook@...omium.org>, "jeyu@...nel.org" <jeyu@...nel.org>,
"arjan@...ux.intel.com" <arjan@...ux.intel.com>, "linux-mips@...ux-mips.org"
<linux-mips@...ux-mips.org>, "tglx@...utronix.de" <tglx@...utronix.de>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>, "x86@...nel.org"
<x86@...nel.org>, "kristen@...ux.intel.com" <kristen@...ux.intel.com>,
"Dock, Deneen T" <deneen.t.dock@...el.com>, "catalin.marinas@....com"
<catalin.marinas@....com>, "mingo@...hat.com" <mingo@...hat.com>,
"will.deacon@....com" <will.deacon@....com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
"bp@...en8.de" <bp@...en8.de>, "Hansen, Dave" <dave.hansen@...el.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "davem@...emloft.net"
<davem@...emloft.net>, "linux-arch@...r.kernel.org"
<linux-arch@...r.kernel.org>, "arnd@...db.de" <arnd@...db.de>,
"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>
Subject: Re: [PATCH v2 1/7] modules: Create rlimit for module space
On Fri, 2018-10-12 at 19:22 +0200, Jann Horn wrote:
> On Fri, Oct 12, 2018 at 7:04 PM Edgecombe, Rick P
> <rick.p.edgecombe@...el.com> wrote:
> > On Fri, 2018-10-12 at 02:35 +0200, Jann Horn wrote:
> > > Why all the rbtree stuff instead of stashing a pointer in struct
> > > vmap_area, or something like that?
> >
> > Since the tracking was not for all vmalloc usage, the intention was to not
> > bloat
> > the structure for other usages likes stacks. I thought usually there
> > wouldn't be
> > nearly as much module space allocations as there would be kernel stacks, but
> > I
> > didn't do any actual measurements on the tradeoffs.
>
> I imagine that one extra pointer in there - pointing to your struct
> mod_alloc_user - would probably not be terrible. 8 bytes more per
> kernel stack shouldn't be so bad?
I looked into this and it starts to look a little messy. The nommu.c version of
vmalloc doesn't use or expose access to vmap_area or vm_struct. So it starts to
look like a bunch of IFDEFs to remove the rlimit in the nommu case or making a
stand in that maintains pretend vm struct's in nommu.c. I had actually
previously tried to at least pull the allocations size from vmalloc structs, but it broke on nommu.
Thought I would check back and see. How important do you think this is?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
