From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: hch@lst.de, torvalds@linux-foundation.org,
akpm@linux-foundation.org, James.Bottomley@hansenpartnership.com,
guoren@kernel.org, tsbogend@alpha.franken.de,
nickhu@andestech.com, green.hu@gmail.com, deanbo422@gmail.com,
deller@gmx.de, ysato@users.sourceforge.jp, dalias@libc.org,
geoff@infradead.org, paul@crapouillou.net,
ulf.hansson@linaro.org, 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: Mon, 19 Jul 2021 16:42:38 +0100 [thread overview]
Message-ID: <20210719154238.GS22278@shell.armlinux.org.uk> (raw)
In-Reply-To: <20210719053851.GA16780@gondor.apana.org.au>
On Mon, Jul 19, 2021 at 01:38:51PM +0800, Herbert Xu wrote:
> Russell King Oracle <linux@armlinux.org.uk> wrote:
> >
> > 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 Crypto API has been calling flush_dcache_page from softirq
> context since before the advent of git (see crypto/scatterwalk.c
> from the initial import). So if 32-bit ARM blocks on it then this
> has been broken for almost 20 years.
I think what's confusing me is the naming of flush_dcache_mmap_lock().
The mmap lock is a read-write semaphore (see linux/mmap-lock.h), and
is even called "mmap_lock" in mm_struct, but this has nothing to do
with flush_dcache_mmap_lock().
So no, flush_dcache_mmap_lock() doesn't block as I first thought, and
therefore flush_dcache_page() doesn't block either.
Sorry for the noise.
However, I now seem to remember some discussion in the past when I was
trying to get people to use flush_dcache_page() to solve the coherency
problems when block drivers were doing PIO to page cache pages. I seem
to remember there being objections to it, which is one of the reasons
we ended up with a lighter weight flush_kernel_dcache_page(). But
shrug, dim and distant memories.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2021-07-19 16:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-12 6:09 flush_kernel_dcache_page fixes and removal 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-19 8:15 ` Paul Cercueil
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-08-04 11:12 ` Ulf Hansson
2021-07-12 6:09 ` [PATCH 3/6] ps3disk: " Christoph Hellwig
2021-07-19 3:07 ` Geoff Levand
2021-07-12 6:09 ` [PATCH 4/6] scatterlist: " Christoph Hellwig
2021-07-12 6:09 ` [PATCH 5/6] aacraid: remove an unused include Christoph Hellwig
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 23:56 ` Ira Weiny
2021-07-12 19:24 ` flush_kernel_dcache_page fixes and removal Linus Torvalds
2021-07-13 5:46 ` Christoph Hellwig
2021-07-13 8:46 ` Russell King (Oracle)
2021-07-13 9:11 ` Christoph Hellwig
2021-07-19 5:38 ` Herbert Xu
2021-07-19 15:42 ` Russell King (Oracle) [this message]
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=20210719154238.GS22278@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=herbert@gondor.apana.org.au \
--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 \
/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;
as well as URLs for NNTP newsgroup(s).