[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+DvKQK_JAmy9AyJgX6wp=nMatYiAb5882JTzDuoD4Bcuzo2Cw@mail.gmail.com>
Date: Thu, 8 Feb 2018 20:47:57 -0500
From: Daniel Micay <danielmicay@...il.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Jann Horn <jannh@...gle.com>, linux-mm@...ck.org,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
kernel list <linux-kernel@...r.kernel.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Kees Cook <keescook@...omium.org>
Subject: Re: [RFC] Warn the user when they could overflow mapcount
I think there are likely legitimate programs mapping something a bunch of times.
Falling back to a global object -> count mapping (an rbtree / radix
trie or whatever) with a lock once it hits saturation wouldn't risk
breaking something. It would permanently leave the inline count
saturated and just use the address of the inline counter as the key
for the map to find the 64-bit counter. Once it gets to 0 in the map,
it can delete it from the map and do the standard freeing process,
avoiding leaks. It would really just make it a 64-bit reference count
heavily size optimized for the common case. It would work elsewhere
too, not just this case.
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.
