All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Juergen Gross <jgross@suse.com>
Cc: Jiri Kosina <jikos@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Michal Hocko <mhocko@suse.com>
Subject: Re: Access to non-RAM pages
Date: Sat, 1 Sep 2018 18:13:31 +0100	[thread overview]
Message-ID: <20180901171330.GF19965@ZenIV.linux.org.uk> (raw)
In-Reply-To: <b1b5ef64-d49b-e3f7-98b4-0ae3fd57b812@suse.com>

On Sat, Sep 01, 2018 at 12:47:48PM +0200, Juergen Gross wrote:
> On 31/08/18 23:18, Jiri Kosina wrote:
> > On Wed, 29 Aug 2018, Juergen Gross wrote:
> > 
> >> While being very unlikely I still believe this is possible. Any
> >> thoughts?
> > 
> > So in theory we should somehow test whether the next page is some form of 
> > mmio/gart/... mapping, but I guess that by itself would kill the 
> > performance advantage of the whole load_unaligned_zeropad() trick.
> > 
> > And yes, the sideffects of reading from mmio mapping is a real thing -- 
> > see for example the issue fixed by 2a3e83c6f9.
> > 
> > If noone has any clever idea how to work this around (I don't), I am 
> > afraid we'd have to ditch the whole DCACHE_WORD_ACCESS optimization, as 
> > it's silently dangerous.
> 
> Are there any architectures which can still use DCACHE_WORD_ACCESS?
> 
> x86 shouldn't, what about powerpc, arm and arm64?

IMO that's crap.  In absolute majority of cases there is a guaranteed gap
between the end of accessed object and the next page boundary.  Penalizing
each syscall that does pathname resolution to deal with something that
might only happen when the pathname length is just under 4Kb looks like
a bloody bad idea.

  reply	other threads:[~2018-09-01 17:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-29 12:10 Access to non-RAM pages Juergen Gross
2018-08-31 21:18 ` Jiri Kosina
2018-09-01 10:47   ` Juergen Gross
2018-09-01 17:13     ` Al Viro [this message]
2018-09-01 21:48       ` Jiri Kosina
2018-09-01 17:27   ` Linus Torvalds
2018-09-01 18:06     ` Linus Torvalds
2018-09-03  0:48       ` Benjamin Herrenschmidt
2018-09-03  0:55         ` Benjamin Herrenschmidt
2018-09-03  1:38           ` Linus Torvalds
2018-09-03  1:42             ` Linus Torvalds
2018-09-03  2:00               ` Benjamin Herrenschmidt
2018-09-03  2:10                 ` Linus Torvalds
2018-09-03  2:25                   ` Benjamin Herrenschmidt
2018-09-03  2:47                     ` Linus Torvalds
2018-09-03  2:52                       ` Linus Torvalds
2018-09-03  3:44                         ` Benjamin Herrenschmidt
2018-09-03  5:08                   ` Juergen Gross
2018-09-03  6:05                   ` Jiri Kosina
2018-09-03 10:36                   ` Will Deacon
2018-09-03  1:44             ` Benjamin Herrenschmidt
2018-09-03  1:46             ` Benjamin Herrenschmidt

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=20180901171330.GF19965@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=jgross@suse.com \
    --cc=jikos@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=torvalds@linux-foundation.org \
    /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.