From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Nelson <markn@au1.ibm.com>,
Gunnar von Boehn <VONBOEHN@de.ibm.com>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
Maxim Shchetynin <maxim@linux.vnet.ibm.com>,
Paul Mackerras <paulus@samba.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: AZFS file system proposal
Date: Wed, 09 Jul 2008 16:48:06 +1000 [thread overview]
Message-ID: <1215586086.8970.348.camel@pasglop> (raw)
In-Reply-To: <200807081642.19507.arnd@arndb.de>
> Cc:'ing some more people that might have more of a clue on this question.
> _memcpy_fromio does a "sync" at the start and an "eieio" at the end.
> IFAICT, neither are needed here because the source is always memory.
>
> It also handles unaligned memory accesses, which copy_to_user should
> also do correctly, so it *looks* like it should work with just a
> copy_to_user, but it still feels wrong to use an __iomem pointer
> as the source for a copy_to_user.
>
> Any ideas?
It's a bit nasty yes. The problem is that copy_to/from_user might
do cache tricks which will blow up if the area is non-cacheable.
We have a similar problem with Mark's work on faster copy functions
since things like sys_read() can be called on userspace non-cacheable
memory such as spu local stores.
So I'm not 100% sure what the right approach here. Our copy_tofrom_user
today does dcbt on the source for example, which I hope only turns into
a no-op... The risk is if we start using dcbz.
Cheers,
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Maxim Shchetynin <maxim@linux.vnet.ibm.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>,
Segher Boessenkool <segher@kernel.crashing.org>,
Gunnar von Boehn <VONBOEHN@de.ibm.com>,
Mark Nelson <markn@au1.ibm.com>
Subject: Re: AZFS file system proposal
Date: Wed, 09 Jul 2008 16:48:06 +1000 [thread overview]
Message-ID: <1215586086.8970.348.camel@pasglop> (raw)
In-Reply-To: <200807081642.19507.arnd@arndb.de>
> Cc:'ing some more people that might have more of a clue on this question.
> _memcpy_fromio does a "sync" at the start and an "eieio" at the end.
> IFAICT, neither are needed here because the source is always memory.
>
> It also handles unaligned memory accesses, which copy_to_user should
> also do correctly, so it *looks* like it should work with just a
> copy_to_user, but it still feels wrong to use an __iomem pointer
> as the source for a copy_to_user.
>
> Any ideas?
It's a bit nasty yes. The problem is that copy_to/from_user might
do cache tricks which will blow up if the area is non-cacheable.
We have a similar problem with Mark's work on faster copy functions
since things like sys_read() can be called on userspace non-cacheable
memory such as spu local stores.
So I'm not 100% sure what the right approach here. Our copy_tofrom_user
today does dcbt on the source for example, which I hope only turns into
a no-op... The risk is if we start using dcbz.
Cheers,
Ben.
next prev parent reply other threads:[~2008-07-09 6:54 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-18 14:06 AZFS file system proposal Maxim Shchetynin
2008-06-18 14:06 ` Maxim Shchetynin
2008-07-01 14:59 ` Arnd Bergmann
2008-07-01 14:59 ` Arnd Bergmann
2008-07-07 15:39 ` Maxim Shchetynin
2008-07-07 15:39 ` Maxim Shchetynin
2008-07-07 15:39 ` Maxim Shchetynin
2008-07-08 14:42 ` Arnd Bergmann
2008-07-08 14:42 ` Arnd Bergmann
2008-07-08 14:42 ` Arnd Bergmann
2008-07-09 6:48 ` Benjamin Herrenschmidt [this message]
2008-07-09 6:48 ` Benjamin Herrenschmidt
2008-07-07 15:42 ` azfs: initial submit of azfs, a non-buffered filesystem Maxim Shchetynin
2008-07-07 15:42 ` Maxim Shchetynin
2008-07-07 15:42 ` Maxim Shchetynin
2008-07-07 19:37 ` Uli Luckas
2008-07-07 19:37 ` Uli Luckas
2008-07-08 9:10 ` Maxim Shchetynin
2008-07-08 9:10 ` Maxim Shchetynin
2008-07-08 9:10 ` Maxim Shchetynin
2008-07-09 8:58 ` AZFS file system proposal Benjamin Herrenschmidt
2008-07-09 8:58 ` Benjamin Herrenschmidt
2008-07-09 9:14 ` Maxim Shchetynin
2008-07-09 9:14 ` Maxim Shchetynin
2008-07-09 9:14 ` Maxim Shchetynin
2008-07-09 9:23 ` Benjamin Herrenschmidt
2008-07-09 10:58 ` Maxim Shchetynin
2008-07-09 10:58 ` Maxim Shchetynin
2008-07-09 10:58 ` Maxim Shchetynin
-- strict thread matches above, loose matches on Subject: below --
2008-06-09 8:46 Maxim Shchetynin
2008-06-09 8:46 ` Maxim Shchetynin
2008-06-09 12:55 ` Matthew Wilcox
2008-06-10 8:49 ` Maxim Shchetynin
2008-06-10 8:49 ` Maxim Shchetynin
2008-06-10 22:02 ` Jan Engelhardt
2008-06-17 9:06 ` Maxim Shchetynin
2008-06-17 9:06 ` Maxim Shchetynin
2008-06-17 9:35 ` Jan Engelhardt
2008-06-17 10:53 ` Jörn Engel
2008-06-17 10:53 ` Jörn Engel
2008-06-17 14:06 ` Maxim Shchetynin
2008-06-17 14:06 ` Maxim Shchetynin
2008-06-17 14:45 ` Jörn Engel
2008-06-17 14:45 ` Jörn Engel
2008-06-17 11:57 ` Maxim Shchetynin
2008-06-17 11:57 ` Maxim Shchetynin
2008-06-17 14:36 ` Jan Engelhardt
2008-06-17 15:51 ` Jörn Engel
2008-06-17 15:51 ` Jörn Engel
2008-06-18 11:15 ` Maxim Shchetynin
2008-06-18 11:15 ` Maxim Shchetynin
2008-06-18 20:56 ` Jörn Engel
2008-06-18 11:21 ` Maxim Shchetynin
2008-06-18 11:21 ` Maxim Shchetynin
2008-06-17 15:02 ` Dmitri Vorobiev
2008-06-18 14:01 ` Maxim Shchetynin
2008-06-18 14:01 ` Maxim Shchetynin
2008-06-18 11:27 ` Christoph Hellwig
2008-06-18 14:03 ` Maxim Shchetynin
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=1215586086.8970.348.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=VONBOEHN@de.ibm.com \
--cc=arnd@arndb.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=markn@au1.ibm.com \
--cc=maxim@linux.vnet.ibm.com \
--cc=paulus@samba.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.