On Thu, May 02, 2019 at 05:24:39PM +0200, Jan Kara wrote: > On Wed 01-05-19 18:44:22, Matthew Wilcox wrote: > > On Wed, May 01, 2019 at 06:19:00PM -0400, Jann Horn wrote: > > > Regarding the LSFMM talk today: > > > So with the page ref bias, the maximum number of page references will > > > be something like 2^22, right? Is the bias only applied to writable > > > references or also readonly ones? > > > > 2^21, because it's going to get caught by the < 0 check. > > > > I think that's fine, though. Anyone trying to map that page so many times > > is clearly doing something either malicious or inadvertently very wrong. > > After the 2 millionth time, attempting to pin the page will fail, and > > the application will have to deal with that failure. > > So actually, you can still have ~2^31 *normal* page references (e.g. from > page tables). You would be limited to ~2^21 GUP references but I don't > think that would be a problem for any real workload. > > If we are concerned about malicous application causing DOS by pinning page > too many times and then normal reference could not be acquired without > causing issues like leaking the page, I think we could even let get_pin() > fail whenever say page->_refcount >= 1<<29 to still leave *plenty* of space > for normal page references (effectively user could consume only 1/4 of > refcount range for GUP pins). Oh, I haven't explained the page refcount solution properly :-( After the page refcount gets to 2^31, no more get_user_pages() calls will succeed. But normal get_page() calls will succeed, so you can still fork() or do normal IO, just not O_DIRECT or RDMA. I wanted to find a solution that didn't permit a local DoS by, eg, doing O_DIRECT writes from a page of libc. I mean, you can stop other I/O from occurring, but you can't prevent fork().
