All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Christoph Hellwig <hch@lst.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Guo Ren <guoren@kernel.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Nick Hu <nickhu@andestech.com>, Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>, Helge Deller <deller@gmx.de>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, Geoff Levand <geoff@infradead.org>,
	Paul Cercueil <paul@crapouillou.net>,
	Ulf Hansson <ulf.hansson@linaro.org>, Alex Shi <alexs@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linux-sh@vger.kernel.org, linux-mmc@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-mm@kvack.org,
	linux-doc@vger.kernel.org
Subject: Re: flush_kernel_dcache_page fixes and removal
Date: Tue, 13 Jul 2021 09:46:48 +0100	[thread overview]
Message-ID: <20210713084648.GF22278@shell.armlinux.org.uk> (raw)
In-Reply-To: <20210712060928.4161649-1-hch@lst.de>

On Mon, Jul 12, 2021 at 08:09:22AM +0200, Christoph Hellwig wrote:
> while looking to convert the block layer away from kmap_atomic towards
> kmap_local_page and prefeably the helpers that abstract it away I noticed
> that a few block drivers directly or implicitly call
> flush_kernel_dcache_page before kunmapping a page that has been written
> to.  flush_kernel_dcache_page is documented to to be used in such cases,
> but flush_dcache_page is actually required when the page could be in
> the page cache and mapped to userspace, which is pretty much always the
> case when kmapping an arbitrary page.  Unfortunately the documentation
> doesn't exactly make that clear, which lead to this misused.  And it turns
> out that only the copy_strings / copy_string_kernel in the exec code
> were actually correct users of flush_kernel_dcache_page, which is why
> I think we should just remove it and eat the very minor overhead in
> exec rather than confusing poor driver writers.

I think you need to be careful - I seem to have a recollection that the
reason we ended up with flush_kernel_dcache_page() was the need to avoid
the taking of the mmap lock for 32-bit ARM VIVT based CPUs in
flush_dcache_page(). 32-bit ARM flush_dcache_page() can block.

If you're sure that all these changes you're making do not end up
calling flush_dcache_page() from a path where we are atomic, then fine.

The second issue I have is that, when we are reading a page into a page
cache page, how can that page be mapped to userspace? Isn't that a
violation of semantics? If the page is mapped to userspace but does not
contain data from the underlying storage device, then the page contains
stale data (if it's a new page, lets hope that's zeroed and not some
previous contents - which would be a massive security hole.) As I
understand it, the flush_kernel_dcache_page() calls in the block layer
are primarily there to cope with drivers that do PIO read to write to a
page cache page to ensure that later userspace mappings can see the data
in the page cache page - by ensuring that the page cache pages are in
the same state as far as caches go as if they had been DMA'd to.

We know that the current implementation works fine - you're now
proposing to radically change it, asserting that it's buggy. I'm
nervous about this change.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

WARNING: multiple messages have this Message-ID
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Christoph Hellwig <hch@lst.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Guo Ren <guoren@kernel.org>,
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
	Nick Hu <nickhu@andestech.com>, Greentime Hu <green.hu@gmail.com>,
	Vincent Chen <deanbo422@gmail.com>, Helge Deller <deller@gmx.de>,
	Yoshinori Sato <ysato@users.sourceforge.jp>,
	Rich Felker <dalias@libc.org>, Geoff Levand <geoff@infradead.org>,
	Paul Cercueil <paul@crapouillou.net>,
	Ulf Hansson <ulf.hansson@linaro.org>, Alex Shi <alexs@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org,
	linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org,
	linux-sh@vger.kernel.org, linux-mmc@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-mm@kvack.org,
	linux-doc@vger.kernel.org
Subject: Re: flush_kernel_dcache_page fixes and removal
Date: Tue, 13 Jul 2021 09:46:48 +0100	[thread overview]
Message-ID: <20210713084648.GF22278@shell.armlinux.org.uk> (raw)
In-Reply-To: <20210712060928.4161649-1-hch@lst.de>

On Mon, Jul 12, 2021 at 08:09:22AM +0200, Christoph Hellwig wrote:
> while looking to convert the block layer away from kmap_atomic towards
> kmap_local_page and prefeably the helpers that abstract it away I noticed
> that a few block drivers directly or implicitly call
> flush_kernel_dcache_page before kunmapping a page that has been written
> to.  flush_kernel_dcache_page is documented to to be used in such cases,
> but flush_dcache_page is actually required when the page could be in
> the page cache and mapped to userspace, which is pretty much always the
> case when kmapping an arbitrary page.  Unfortunately the documentation
> doesn't exactly make that clear, which lead to this misused.  And it turns
> out that only the copy_strings / copy_string_kernel in the exec code
> were actually correct users of flush_kernel_dcache_page, which is why
> I think we should just remove it and eat the very minor overhead in
> exec rather than confusing poor driver writers.

I think you need to be careful - I seem to have a recollection that the
reason we ended up with flush_kernel_dcache_page() was the need to avoid
the taking of the mmap lock for 32-bit ARM VIVT based CPUs in
flush_dcache_page(). 32-bit ARM flush_dcache_page() can block.

If you're sure that all these changes you're making do not end up
calling flush_dcache_page() from a path where we are atomic, then fine.

The second issue I have is that, when we are reading a page into a page
cache page, how can that page be mapped to userspace? Isn't that a
violation of semantics? If the page is mapped to userspace but does not
contain data from the underlying storage device, then the page contains
stale data (if it's a new page, lets hope that's zeroed and not some
previous contents - which would be a massive security hole.) As I
understand it, the flush_kernel_dcache_page() calls in the block layer
are primarily there to cope with drivers that do PIO read to write to a
page cache page to ensure that later userspace mappings can see the data
in the page cache page - by ensuring that the page cache pages are in
the same state as far as caches go as if they had been DMA'd to.

We know that the current implementation works fine - you're now
proposing to radically change it, asserting that it's buggy. I'm
nervous about this change.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-07-13  8:47 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-12  6:09 Christoph Hellwig
2021-07-12  6:09 ` Christoph Hellwig
2021-07-12  6:09 ` [PATCH 1/6] mmc: JZ4740: remove the flush_kernel_dcache_page call in jz4740_mmc_read_data Christoph Hellwig
2021-07-12  6:09   ` Christoph Hellwig
2021-07-19  8:15   ` Paul Cercueil
2021-07-19  8:15     ` Paul Cercueil
2021-08-04 11:12   ` Ulf Hansson
2021-08-04 11:12     ` Ulf Hansson
2021-08-04 11:12     ` Ulf Hansson
2021-07-12  6:09 ` [PATCH 2/6] mmc: mmc_spi: replace flush_kernel_dcache_page with flush_dcache_page Christoph Hellwig
2021-07-12  6:09   ` Christoph Hellwig
2021-08-04 11:12   ` Ulf Hansson
2021-08-04 11:12     ` Ulf Hansson
2021-08-04 11:12     ` Ulf Hansson
2021-07-12  6:09 ` [PATCH 3/6] ps3disk: " Christoph Hellwig
2021-07-12  6:09   ` Christoph Hellwig
2021-07-19  3:07   ` Geoff Levand
2021-07-19  3:07     ` Geoff Levand
2021-07-12  6:09 ` [PATCH 4/6] scatterlist: " Christoph Hellwig
2021-07-12  6:09   ` Christoph Hellwig
2021-07-12  6:09 ` [PATCH 5/6] aacraid: remove an unused include Christoph Hellwig
2021-07-12  6:09   ` Christoph Hellwig
2021-07-19  1:50   ` Martin K. Petersen
2021-07-19  1:50     ` Martin K. Petersen
2021-07-12  6:09 ` [PATCH 6/6] mm: remove flush_kernel_dcache_page Christoph Hellwig
2021-07-12  6:09   ` Christoph Hellwig
2021-07-12 23:56   ` Ira Weiny
2021-07-12 23:56     ` Ira Weiny
2021-07-12 19:24 ` flush_kernel_dcache_page fixes and removal Linus Torvalds
2021-07-12 19:24   ` Linus Torvalds
2021-07-12 19:24   ` Linus Torvalds
2021-07-13  5:46   ` Christoph Hellwig
2021-07-13  5:46     ` Christoph Hellwig
2021-07-13  8:46 ` Russell King (Oracle) [this message]
2021-07-13  8:46   ` Russell King (Oracle)
2021-07-13  9:11   ` Christoph Hellwig
2021-07-13  9:11     ` Christoph Hellwig
2021-07-19  5:38   ` Herbert Xu
2021-07-19  5:38     ` Herbert Xu
2021-07-19 15:42     ` Russell King (Oracle)
2021-07-19 15:42       ` Russell King (Oracle)
2021-07-14  3:13 ` Guo Ren
2021-07-14  3:13   ` Guo Ren
2021-07-14  3:13   ` Guo Ren

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=20210713084648.GF22278@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexs@kernel.org \
    --cc=dalias@libc.org \
    --cc=deanbo422@gmail.com \
    --cc=deller@gmx.de \
    --cc=geoff@infradead.org \
    --cc=green.hu@gmail.com \
    --cc=guoren@kernel.org \
    --cc=hch@lst.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-csky@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=nickhu@andestech.com \
    --cc=paul@crapouillou.net \
    --cc=torvalds@linux-foundation.org \
    --cc=tsbogend@alpha.franken.de \
    --cc=ulf.hansson@linaro.org \
    --cc=ysato@users.sourceforge.jp \
    --subject='Re: flush_kernel_dcache_page fixes and removal' \
    /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

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.