[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210719053851.GA16780@gondor.apana.org.au>
Date: Mon, 19 Jul 2021 13:38:51 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Russell King Oracle <linux@...linux.org.uk>
Cc: hch@....de, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, James.Bottomley@...senpartnership.com,
guoren@...nel.org, tsbogend@...ha.franken.de, nickhu@...estech.com,
green.hu@...il.com, deanbo422@...il.com, deller@....de,
ysato@...rs.sourceforge.jp, dalias@...c.org, geoff@...radead.org,
paul@...pouillou.net, ulf.hansson@...aro.org, alexs@...nel.org,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-csky@...r.kernel.org, linux-mips@...r.kernel.org,
linux-parisc@...r.kernel.org, linux-sh@...r.kernel.org,
linux-mmc@...r.kernel.org, linux-scsi@...r.kernel.org,
linux-mm@...ck.org, linux-doc@...r.kernel.org
Subject: Re: flush_kernel_dcache_page fixes and removal
Russell King Oracle <linux@...linux.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@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists