mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@davemloft.net>
To: nickpiggin@yahoo.com.au
Cc: hugh@veritas.com, akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 07/11] unpaged: COW on VM_UNPAGED
Date: Thu, 17 Nov 2005 22:45:16 -0800 (PST)	[thread overview]
Message-ID: <20051117.224516.118147408.davem@davemloft.net> (raw)
In-Reply-To: <437D6AD0.5080909@yahoo.com.au>

From: Nick Piggin <nickpiggin@yahoo.com.au>
Date: Fri, 18 Nov 2005 16:46:56 +1100

> I think for 2.6.15, yes. We [read: I :(] was too hasty in removing
> this completely. However I think it would not be unresonable to spit
> out a warning, and remove it in 2.6.??

I am so convinced that handling COW faults on VM_RESERVED is
unnecessary, that I think it's prudent to spit out a warning
for MAP_PRIVATE+VM_RESERVED and changing it to MAP_SHARED
to complete the mmap() call.

I bet every single application still works.

And we'll have none of this rediculious complex crap handling COW
pages in VM_RESERVED areas, which I believe is seriously more
complicated than what we started with before any of the VM_RESERVED
changed went into 2.6.15.  In fact, we might as well go back to the
2.6.14 stuff instead.  I do not see the second half of Hugh's patches
as progress, it's a severe regression to even 2.6.14

Doing a get_user_pages() on a VM_UNPAGED area, that's sane, and
we know exactly what makes use of that.  COW faults on VM_UNPAGED
areas, that's not sane, and we don't know of a single instance
which correctly needs that behavior.

MAP_SHARED mappings of reserved pages shared between driver, device,
and userspace is common and understandable.  But MAP_PRIVATE mappings
of such things?  Please show me an example of something legitimately
using that, and not doing so by mistake.  I will drop all of my
arguments once I see that :-)

Because, frankly, a lot of these COW on VM_UNPAGED patches seemingly
are derived from studying the MM and a few drivers and saying "oh yes,
that's _possible_" but that is far from being enough to justify this
complexity.  We really need to see real usage, that makes sense.
All the cases I've investigated in userspace are "they really want
MAP_SHARED" or "they didn't need PROT_WRITE in the first place".

  reply	other threads:[~2005-11-18  6:45 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-17 19:28 [PATCH 00/11] unpaged: PageReserved VM fixups Hugh Dickins
2005-11-17 19:29 ` [PATCH 01/11] unpaged: get_user_pages VM_RESERVED Hugh Dickins
2005-11-17 23:29   ` David S. Miller
2005-11-17 19:30 ` [PATCH 02/11] unpaged: private write VM_RESERVED Hugh Dickins
2005-11-17 19:41   ` Dave Jones
2005-11-17 20:46     ` Dominik Brodowski
2005-11-17 20:51       ` Dave Jones
2005-11-17 23:58         ` David S. Miller
2005-11-18  7:12           ` Dominik Brodowski
2005-11-18  7:59             ` David S. Miller
2005-11-17 20:59       ` Dominik Brodowski
2005-11-17 23:36   ` David S. Miller
2005-11-17 19:31 ` [PATCH 03/11] unpaged: sound nopage get_page Hugh Dickins
2005-11-17 23:41   ` David S. Miller
2005-11-17 19:32 ` [PATCH 04/11] unpaged: unifdefed PageCompound Hugh Dickins
2005-11-17 23:43   ` David S. Miller
2005-11-19 20:15     ` Hugh Dickins
2005-11-19 20:55       ` William Lee Irwin III
2005-11-19 21:41         ` David S. Miller
2005-11-19 21:58           ` William Lee Irwin III
2005-11-17 19:34 ` [PATCH 05/11] unpaged: VM_UNPAGED Hugh Dickins
2005-11-17 20:59   ` William Lee Irwin III
2005-11-17 23:46   ` David S. Miller
2005-11-17 19:36 ` [PATCH 06/11] unpaged: VM_NONLINEAR VM_RESERVED Hugh Dickins
2005-11-17 19:37 ` [PATCH 07/11] unpaged: COW on VM_UNPAGED Hugh Dickins
2005-11-17 23:52   ` David S. Miller
2005-11-18  5:46     ` Nick Piggin
2005-11-18  6:45       ` David S. Miller [this message]
2005-11-18  7:27         ` Hugh Dickins
2005-11-18  7:46           ` Andrew Morton
2005-11-18  8:04           ` David S. Miller
2005-11-18  8:12             ` Hugh Dickins
2005-11-18  8:02         ` Hugh Dickins
2005-11-18  8:08           ` David S. Miller
2005-11-18  8:13             ` Hugh Dickins
2005-11-18  8:36               ` David S. Miller
2005-11-18  9:33                 ` Hugh Dickins
2005-11-18 21:08           ` Dave Jones
2005-11-18 19:12     ` Alan Cox
2005-11-17 19:38 ` [PATCH 08/11] unpaged: anon in VM_UNPAGED Hugh Dickins
2005-11-17 19:38 ` [PATCH 09/11] unpaged: ZERO_PAGE " Hugh Dickins
2005-11-17 21:25   ` Ingo Oeser
2005-11-18 19:58     ` Hugh Dickins
2005-11-17 19:39 ` [PATCH 10/11] unpaged: PG_reserved bad_page Hugh Dickins
2005-11-17 19:40 ` [PATCH 11/11] unpaged: copy_page_range vma Hugh Dickins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051117.224516.118147408.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=akpm@osdl.org \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome