Stable kernel 2.6.25.11

Sorry Alexey to have you waited but as you probably saw, i was quite busy elsewhere ;). with
that said, having seen your knowledge/idiocy ratio (no need to go further than say
http://thread.gmane.org/gmane.linux.kernel/706524/focus=7...), i'll cut this answer short
and just point out a few obvious things in the hope you'll think more next time before
posting.

> kmalloc(0) is harmless.

it's not in general. it returns a non-NULL ptr so !ptr checks will not catch it and that can
later result in their dereference of userland memory. in other words, it's a design error,
this call should return something that's guaranteeed to fault on dereference. the kernel even
has a special range for exactly this purpose: the negative error codes.

> Multiplication overflow on 64-bit can't happen

 2fc:   4d 29 fc                sub    %r15,%r12
 2ff:   49 c1 ec 0c             shr    $0xc,%r12
 303:   49 63 fc                movslq %r12d,%rdi
 306:   45 89 e5                mov    %r12d,%r13d
 309:   48 c1 e7 03             shl    $0x3,%rdi
 30d:   e8 00 00 00 00          callq  312 <pagemap_read+0xc4>  30e: R_X86_64_PC32
__kmalloc+0xfffffffffffffffc

do you know what movslq does? (extra quiz question: do you know why it's there at all?) do you
understand what the following shl will do to the result?

> Don't know what exact aspect of "sleeping on put_user" you mean.

that other threads can schedule during that sleep and do all kinds of changes to the virtual
address space (and consequently, the underlying physical pages as well) that this code may not
have expected to happen. i don't know if that's the case, i was asking the question myself,
but considering that someone went to lengths to call get_user_pages in this code, there must
be a reason for it.

> Notice put_page() calls in pagemap_read(). Why they're there? Probably,
> because get_user_pages() pins pages, so they won't dissapear from under
> you.

it pins physical pages, it doesn't pin virtual memory mappings in place (that's what the mmap
semaphore is for). so while the pinned pages may very well stay in RAM, the put_user may not
access them at all if copy-on-write or munmap/mmap brought in a different set of physical (and
quite possibly, not pinned) pages. whether that's a problem or not, i can't tell (read: i'm
not going to spend any more time on this), hence the question.

> Regarding mprotect(): user will clear PROT_WRITE, and kernel will
> put_user() to it. You know what will happen. Amazing hole.

if copy-on-write moves your carefully pinned page away and replaces it with a non-pinned one,
an assumption this code relies (or may rely, we don't know as of now) on is broken. what
consequences that has, i don't know, hence my question.