[lkml]   [2002]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Arch option to touch newly allocated pages
> If UML can detect pages which tmpfs can't back as they leave the allocator,
> then it can prevent the rest of the UML kernel from getting randomly SIGBUSed
> as it touches those pages.

Yes I follow this. I don't understand how it is related to your intended

> To recap in case it got lost in the confusion, I want __alloc_pages to call
> an arch hook before it return memory, turning every instance of

alloc_pages is only called at the time the backing page is created - by
then it doesnt matter - its too late. You'd need to hack up the same code
areas that are used for mlock MCL_FUTURE not alloc_pages

> Given that we are talking about tmpfs running out of space, the host still
> has plenty of free memory, and UML kernel stacks can receive the SIGBUS
> (because they've been allocated with this mechanism), is this still
> objectionable?

With the vm no overcommit code the tmpfs cannot run out of space filling
in pages, only when you make a tmpfs file larger. The code guarantees there
are swap pages available to back between offset 0 and the file size. A
write extending a tmpfs file may fail reporting the disk full.

The code guarantees (modulo bugs of course!) that the total number of
pages that could be created by touching addresses that have already been
mapped including accounting for tmpfs on the basis above never exceeds the
number of pages available.

The bugs at the moment being
1. ptrace isnt accounted for its special weirdnesses
2. MAP_NORESERVE isnt forcibly accounted in these modes as required

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.098 / U:6.412 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site