All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Russell King Oracle <linux@armlinux.org.uk>
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 13:38:51 +0800	[thread overview]
Message-ID: <20210719053851.GA16780@gondor.apana.org.au> (raw)
In-Reply-To: <20210713084648.GF22278@shell.armlinux.org.uk>

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.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

WARNING: multiple messages have this Message-ID (diff)
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Russell King Oracle <linux@armlinux.org.uk>
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 13:38:51 +0800	[thread overview]
Message-ID: <20210719053851.GA16780@gondor.apana.org.au> (raw)
In-Reply-To: <20210713084648.GF22278@shell.armlinux.org.uk>

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.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
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-19  5:39 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 [this message]
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=20210719053851.GA16780@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --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=linux@armlinux.org.uk \
    --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.