All of lore.kernel.org
 help / color / mirror / Atom feed
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!

WARNING: multiple messages have this Message-ID (diff)
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!

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

  reply	other threads:[~2021-07-19 16:12 UTC|newest]

Thread overview: 44+ 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 ` 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)
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) [this message]
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=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 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.