All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Roland Dreier <rdreier@cisco.com>,
	venkatesh.pallipadi@intel.com, ak@muc.de,
	torvalds@linux-foundation.org, gregkh@suse.de, airlied@skynet.ie,
	davej@redhat.com, mingo@elte.hu, tglx@linutronix.de,
	hpa@zytor.com, akpm@linux-foundation.org, arjan@infradead.org,
	jesse.barnes@intel.com, linux-kernel@vger.kernel.org,
	Suresh Siddha <suresh.b.siddha@intel.com>
Subject: Re: [RFC PATCH 06/12] PAT 64b: Add ioremap_wc support
Date: Fri, 14 Dec 2007 13:40:27 -0800	[thread overview]
Message-ID: <20071214214026.GC717@linux-os.sc.intel.com> (raw)
In-Reply-To: <m1odctq3tn.fsf@ebiederm.dsl.xmission.com>

On Thu, Dec 13, 2007 at 09:48:36PM -0700, Eric W. Biederman wrote:
> Roland Dreier <rdreier@cisco.com> writes:
> 
> >  > > Also I didn't see anything like pgprot_wc() in the patchset (although
> >
> >  > pgprot_writcombined.
> >
> > Oh I see it now (pgprot_writecombine() actually).
> >
> > However the same comment as before applies: there needs to be a
> > fallback to pgprot_noncached() for all other architectures so that
> > drivers can actually use it in a sane way.
> 
> Sounds reasonable.

We will fix it in next rev.

> It should be the conflict checking that is the actual bottleneck.
> The rest is just gravy.

Yes. We are looking for comments for our proposal to track the
reserved/non-reserved regions some what different.
This is the critical issue which had been holding off PAT for years now...

<snip from the other mails>

Change x86_64 identity map to only map non-reserved memory. This helps
to handle UC/WC mapping of reserved region in a much simple manner
(we don't have to do cpa any more, as such not keep track of the actual
reference counts. We still track all the usages to keep the mappings
consistent. We just avoid the headache of splitting mattr regions for
managing ref counts for every individual usage of the reserved area).

For now, we don't track RAM pages using memattr infrastructure. This is because,
memattr infrastructure is not enough. i.e., while the page is getting
tracked using memattr infrastructure, potentially the page can get
freed(a bug that we need to catch, to avoid attribute aliasing).
For example, a driver does ioremap_uc and an application mapped the
same page using /dev/mem. When the driver does iounamp and free the page,
/dev/mem mapping is still live and we run into aliasing issue.

Can we use the existing page struct to keep track of the attribute
and usage? /dev/mem mappings then can increment the page ref count and not
allow to free the page while the /dev/mem mappings are active. And allow
/dev/mem to map only those pages which are marked reserved (which the driver
does before doing iomap).

Or when a WB mapping through /dev/mem is active, don't allow any driver
to map the page as UC.. Can we do this tracking for RAM pages through
struct page. Or there any issues we should keep in mind..

thanks,
suresh

  reply	other threads:[~2007-12-14 21:42 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-13 23:55 [RFC PATCH 00/12] PAT 64b: PAT support for X86_64 venkatesh.pallipadi
2007-12-13 23:55 ` [RFC PATCH 01/12] PAT 64b: Add cpu_shutdown() support venkatesh.pallipadi
2007-12-13 23:55 ` [RFC PATCH 02/12] PAT 64b: Basic PAT implementation venkatesh.pallipadi
2007-12-14  0:42   ` Andi Kleen
2007-12-14 18:31     ` Venki Pallipadi
2007-12-18  4:50       ` Eric W. Biederman
2007-12-14  3:48   ` Eric W. Biederman
2007-12-14  4:23     ` Eric W. Biederman
2007-12-14 21:10       ` Siddha, Suresh B
2007-12-14 23:34         ` Siddha, Suresh B
2007-12-15  7:55           ` Ingo Molnar
2007-12-14 10:25     ` Andi Kleen
2007-12-14 19:45       ` H. Peter Anvin
2007-12-18  4:42       ` Eric W. Biederman
2007-12-14 21:06     ` Siddha, Suresh B
2007-12-13 23:55 ` [RFC PATCH 03/12] PAT 64b: drm driver changes for PAT venkatesh.pallipadi
2007-12-13 23:55 ` [RFC PATCH 04/12] PAT 64b: reserve_mattr and free_mattr " venkatesh.pallipadi
2007-12-13 23:55 ` [RFC PATCH 05/12] PAT 64b: pci mmap conlfict patch venkatesh.pallipadi
2007-12-13 23:55 ` [RFC PATCH 06/12] PAT 64b: Add ioremap_wc support venkatesh.pallipadi
2007-12-14  4:17   ` Roland Dreier
2007-12-14  4:28     ` Eric W. Biederman
2007-12-14  4:32       ` Roland Dreier
2007-12-14  4:48         ` Eric W. Biederman
2007-12-14 21:40           ` Siddha, Suresh B [this message]
2007-12-14 23:19             ` Andi Kleen
2007-12-18  8:29             ` Eric W. Biederman
2007-12-13 23:55 ` [RFC PATCH 07/12] PAT 64b: dev mem chanegs for pat venkatesh.pallipadi
2007-12-13 23:55 ` [RFC PATCH 08/12] PAT 64b: coherent mmap and sysfs bin ioctl venkatesh.pallipadi
2007-12-14  0:19   ` Greg KH
2007-12-14  0:35     ` David Miller
2007-12-14  6:34       ` Greg KH
2007-12-16 21:57         ` Paul Mackerras
2007-12-17 12:41           ` Andi Kleen
2007-12-18  4:30             ` Eric W. Biederman
2007-12-18  4:51               ` H. Peter Anvin
2007-12-18  9:35               ` Andi Kleen
2007-12-18 13:48                 ` Eric W. Biederman
2007-12-14  0:43     ` Andi Kleen
2007-12-14  0:54   ` Jesse Barnes
2007-12-14  3:59   ` Eric W. Biederman
2007-12-14  6:02     ` Greg KH
2007-12-14  6:04       ` Eric W. Biederman
2007-12-14 10:19         ` Andi Kleen
2007-12-13 23:55 ` [RFC PATCH 09/12] PAT 64b: map only usable memory in identity mapping venkatesh.pallipadi
2007-12-13 23:55 ` [RFC PATCH 10/12] PAT 64b: Make acpi use early map instead of assuming identity map venkatesh.pallipadi
2007-12-13 23:55 ` [RFC PATCH 11/12] PAT 64b: devmem do not read pages not mapped in " venkatesh.pallipadi
2007-12-13 23:55 ` [RFC PATCH 12/12] PAT 64b: skip attr tracking for RAM venkatesh.pallipadi
2007-12-14  0:28 ` [RFC PATCH 00/12] PAT 64b: PAT support for X86_64 Dave Airlie
2007-12-14 22:00   ` Siddha, Suresh B
2007-12-14 22:27     ` Dave Airlie
2007-12-14 22:32       ` H. Peter Anvin
2007-12-14 22:37         ` Dave Airlie

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=20071214214026.GC717@linux-os.sc.intel.com \
    --to=suresh.b.siddha@intel.com \
    --cc=airlied@skynet.ie \
    --cc=ak@muc.de \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=davej@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@suse.de \
    --cc=hpa@zytor.com \
    --cc=jesse.barnes@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rdreier@cisco.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=venkatesh.pallipadi@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.