* [PATCH v2 9/9] hvc_console: Allow backends to set I/O buffer size
From: Geoff Levand @ 2020-05-09 18:58 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Geert Uytterhoeven, Markus Elfring,
Emmanuel Nicolet
In-Reply-To: <cover.1589049250.git.geoff@infradead.org>
To allow HVC backends to set the I/O buffer sizes to values
that are most efficient for the backend, change the macro
definitions where the buffer sizes are set to be conditional
on whether or not the macros are already defined. Also,
rename the macros from N_OUTBUF to HVC_N_OUBUF and from
N_INBUF to HVC_N_INBUF.
Typical usage in the backend source file would be:
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
drivers/tty/hvc/hvc_console.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 436cc51c92c3..2928bad057fc 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -42,12 +42,15 @@
#define HVC_CLOSE_WAIT (HZ/100) /* 1/10 of a second */
/*
- * These sizes are most efficient for vio, because they are the
- * native transfer size. We could make them selectable in the
- * future to better deal with backends that want other buffer sizes.
+ * These default sizes are most efficient for vio, because they are
+ * the native transfer size.
*/
-#define N_OUTBUF 16
-#define N_INBUF 16
+#if !defined(HVC_N_OUTBUF)
+# define HVC_N_OUTBUF 16
+#endif
+#if !defined(HVC_N_INBUF)
+# define HVC_N_INBUF 16
+#endif
#define __ALIGNED__ __attribute__((__aligned__(sizeof(long))))
@@ -151,7 +154,7 @@ static uint32_t vtermnos[MAX_NR_HVC_CONSOLES] =
static void hvc_console_print(struct console *co, const char *b,
unsigned count)
{
- char c[N_OUTBUF] __ALIGNED__;
+ char c[HVC_N_OUTBUF] __ALIGNED__;
unsigned i = 0, n = 0;
int r, donecr = 0, index = co->index;
@@ -640,7 +643,7 @@ static int __hvc_poll(struct hvc_struct *hp, bool may_sleep)
{
struct tty_struct *tty;
int i, n, count, poll_mask = 0;
- char buf[N_INBUF] __ALIGNED__;
+ char buf[HVC_N_INBUF] __ALIGNED__;
unsigned long flags;
int read_total = 0;
int written_total = 0;
@@ -681,7 +684,7 @@ static int __hvc_poll(struct hvc_struct *hp, bool may_sleep)
read_again:
/* Read data if any */
- count = tty_buffer_request_room(&hp->port, N_INBUF);
+ count = tty_buffer_request_room(&hp->port, HVC_N_INBUF);
/* If flip is full, just reschedule a later read */
if (count == 0) {
--
2.20.1
^ permalink raw reply related
* [PATCH v2 1/9] powerpc/head_check: Automatic verbosity
From: Geoff Levand @ 2020-05-09 18:58 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Geert Uytterhoeven, Markus Elfring,
Emmanuel Nicolet
In-Reply-To: <cover.1589049250.git.geoff@infradead.org>
To aid debugging build problems turn on shell tracing for the
head_check script when the build is verbose.
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
arch/powerpc/tools/head_check.sh | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/tools/head_check.sh b/arch/powerpc/tools/head_check.sh
index ad9e57209aa4..37061fb9b58e 100644
--- a/arch/powerpc/tools/head_check.sh
+++ b/arch/powerpc/tools/head_check.sh
@@ -31,8 +31,10 @@
# level entry code (boot, interrupt vectors, etc) until r2 is set up. This
# could cause the kernel to die in early boot.
-# Turn this on if you want more debug output:
-# set -x
+# Allow for verbose output
+if [ "$V" = "1" ]; then
+ set -x
+fi
if [ $# -lt 2 ]; then
echo "$0 [path to nm] [path to vmlinux]" 1>&2
--
2.20.1
^ permalink raw reply related
* [PATCH v2 0/9] powerpc + ps3 patches
From: Geoff Levand @ 2020-05-09 18:58 UTC (permalink / raw)
To: Michael Ellerman, David S. Miller, Jens Axboe
Cc: linuxppc-dev, Geert Uytterhoeven, Markus Elfring,
Emmanuel Nicolet
Hi Michael,
This is a combined V2 of the two patch sets I sent out on March 27th,
'PS3 patches for v5.7' and 'powerpc: Minor updates to improve build debugging'.
I've dropped these two patches that were in my 'PS3 patches for v5.7' set:
powerpc/ps3: Add lv1_panic
powerpc/ps3: Add udbg_panic
and replaced them with a new patch:
powerpc/ps3: Fix kexec shutdown hang
There is new patch I've added in this set:
hvc_console: Allow backends to set I/O buffer size
which I've been using in my debugging. There is nothing using this feature in
the upstream kernel, and I don't plan to submit anything that would use it, so
use your discretion as to merge it.
-Geoff
The following changes since commit 0e698dfa282211e414076f9dc7e83c1c288314fd:
Linux 5.7-rc4 (2020-05-03 14:56:04 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git for-merge-powerpc-v2
for you to fetch changes up to 6f6294df663a53f47bb28abcbb1ef756c6a59922:
hvc_console: Allow backends to set I/O buffer size (2020-05-09 11:24:42 -0700)
----------------------------------------------------------------
Emmanuel Nicolet (1):
ps3disk: use the default segment boundary
Geoff Levand (6):
powerpc/head_check: Automatic verbosity
powerpc/wrapper: Output linker map file
powerpc/head_check: Avoid broken pipe
powerpc/ps3: Add check for otheros image size
powerpc/ps3: Fix kexec shutdown hang
hvc_console: Allow backends to set I/O buffer size
Markus Elfring (2):
drivers/ps3: Remove duplicate error messages
net/ps3_gelic_net: Remove duplicate error message
arch/powerpc/boot/wrapper | 20 +++++++++++++++++---
arch/powerpc/platforms/ps3/mm.c | 22 ++++++++++++----------
arch/powerpc/tools/head_check.sh | 8 +++++---
drivers/block/ps3disk.c | 1 -
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 2 --
drivers/ps3/ps3-lpm.c | 2 --
drivers/ps3/ps3-vuart.c | 1 -
drivers/tty/hvc/hvc_console.c | 19 +++++++++++--------
8 files changed, 45 insertions(+), 30 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH v2 7/9] powerpc/ps3: Add check for otheros image size
From: Geoff Levand @ 2020-05-09 18:58 UTC (permalink / raw)
To: Michael Ellerman
Cc: linuxppc-dev, Geert Uytterhoeven, Markus Elfring,
Emmanuel Nicolet
In-Reply-To: <cover.1589049250.git.geoff@infradead.org>
The ps3's otheros flash loader has a size limit of 16 MiB for the
uncompressed image. If that limit will be reached output the
flash image file as 'otheros-too-big.bld'.
Signed-off-by: Geoff Levand <geoff@infradead.org>
---
arch/powerpc/boot/wrapper | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 35ace40d9fc2..ab1e3ddc79f3 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -571,7 +571,20 @@ ps3)
count=$overlay_size bs=1
odir="$(dirname "$ofile.bin")"
- rm -f "$odir/otheros.bld"
- gzip -n --force -9 --stdout "$ofile.bin" > "$odir/otheros.bld"
+
+ # The ps3's flash loader has a size limit of 16 MiB for the uncompressed
+ # image. If a compressed image that exceeded this limit is written to
+ # flash the loader will decompress that image until the 16 MiB limit is
+ # reached, then enter the system reset vector of the partially decompressed
+ # image. No warning is issued.
+ rm -f "$odir"/{otheros,otheros-too-big}.bld
+ size=$(${CROSS}nm --no-sort --radix=d "$ofile" | egrep ' _end$' | cut -d' ' -f1)
+ bld="otheros.bld"
+ if [ $size -gt $((0x1000000)) ]; then
+ bld="otheros-too-big.bld"
+ echo " INFO: Uncompressed kernel is too large to program into PS3 flash memory;" \
+ "size=0x$(printf "%x\n" $size), limit=0x1000000."
+ fi
+ gzip -n --force -9 --stdout "$ofile.bin" > "$odir/$bld"
;;
esac
--
2.20.1
^ permalink raw reply related
* Re: ioremap() called early from pnv_pci_init_ioda_phb()
From: Oliver O'Halloran @ 2020-05-09 22:59 UTC (permalink / raw)
To: Christophe Leroy; +Cc: Qian Cai, linuxppc-dev, LKML
In-Reply-To: <a4ae5c50-f317-4224-a5f2-6e1030e62d2b@csgroup.eu>
On Sun, May 10, 2020 at 1:51 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 08/05/2020 à 19:41, Qian Cai a écrit :
> >
> >
> >> On May 8, 2020, at 10:39 AM, Qian Cai <cai@lca.pw> wrote:
> >>
> >> Booting POWER9 PowerNV has this message,
> >>
> >> "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use early_ioremap() instead”
> >>
> >> but use the patch below will result in leaks because it will never call early_iounmap() anywhere. However, it looks me it was by design that phb->regs mapping would be there forever where it would be used in pnv_ioda_get_inval_reg(), so is just that check_early_ioremap_leak() initcall too strong?
> >>
> >> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> >> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> >> @@ -36,6 +36,7 @@
> >> #include <asm/firmware.h>
> >> #include <asm/pnv-pci.h>
> >> #include <asm/mmzone.h>
> >> +#include <asm/early_ioremap.h>
> >>
> >> #include <misc/cxl-base.h>
> >>
> >> @@ -3827,7 +3828,7 @@ static void __init pnv_pci_init_ioda_phb(struct device_node *np,
> >> /* Get registers */
> >> if (!of_address_to_resource(np, 0, &r)) {
> >> phb->regs_phys = r.start;
> >> - phb->regs = ioremap(r.start, resource_size(&r));
> >> + phb->regs = early_ioremap(r.start, resource_size(&r));
> >> if (phb->regs == NULL)
> >> pr_err(" Failed to map registers !\n”);
> >
> > This will also trigger a panic with debugfs reads, so isn’t that this commit bogus at least for powerpc64?
> >
> > d538aadc2718 (“powerpc/ioremap: warn on early use of ioremap()")
>
> No d538aadc2718 is not bogus. That's the point, we want to remove all
> early usages of ioremap() in order to remove the hack with the
> ioremap_bot stuff and all, and stick to the generic ioremap logic.
>
> In order to do so, all early use of ioremap() has to be converted to
> early_ioremap() or to fixmap or anything else that allows to do ioremaps
> before the slab is ready.
>
> early_ioremap() is for temporary mappings necessary at boottime. For
> long lasting mappings, another method is to be used.
>
> Now, the point is that other architectures like for instance x86 don't
> seem to have to use early_ioremap() much. Powerpc is for instance doing
> early mappings for PCI. Seems like x86 initialises PCI once slab is
> ready. Can't powerpc do the same ?
Patches welcome.
^ permalink raw reply
* Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open
From: rananta @ 2020-05-10 1:30 UTC (permalink / raw)
To: Greg KH; +Cc: andrew, linuxppc-dev, linux-kernel, jslaby
In-Reply-To: <20200506094851.GA2787548@kroah.com>
On 2020-05-06 02:48, Greg KH wrote:
> On Mon, Apr 27, 2020 at 08:26:01PM -0700, Raghavendra Rao Ananta wrote:
>> Potentially, hvc_open() can be called in parallel when two tasks calls
>> open() on /dev/hvcX. In such a scenario, if the
>> hp->ops->notifier_add()
>> callback in the function fails, where it sets the tty->driver_data to
>> NULL, the parallel hvc_open() can see this NULL and cause a memory
>> abort.
>> Hence, serialize hvc_open and check if tty->private_data is NULL
>> before
>> proceeding ahead.
>>
>> The issue can be easily reproduced by launching two tasks
>> simultaneously
>> that does nothing but open() and close() on /dev/hvcX.
>> For example:
>> $ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 &
>>
>> Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
>> ---
>> drivers/tty/hvc/hvc_console.c | 16 ++++++++++++++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/tty/hvc/hvc_console.c
>> b/drivers/tty/hvc/hvc_console.c
>> index 436cc51c92c3..ebe26fe5ac09 100644
>> --- a/drivers/tty/hvc/hvc_console.c
>> +++ b/drivers/tty/hvc/hvc_console.c
>> @@ -75,6 +75,8 @@ static LIST_HEAD(hvc_structs);
>> */
>> static DEFINE_MUTEX(hvc_structs_mutex);
>>
>> +/* Mutex to serialize hvc_open */
>> +static DEFINE_MUTEX(hvc_open_mutex);
>> /*
>> * This value is used to assign a tty->index value to a hvc_struct
>> based
>> * upon order of exposure via hvc_probe(), when we can not match it
>> to
>> @@ -346,16 +348,24 @@ static int hvc_install(struct tty_driver
>> *driver, struct tty_struct *tty)
>> */
>> static int hvc_open(struct tty_struct *tty, struct file * filp)
>> {
>> - struct hvc_struct *hp = tty->driver_data;
>> + struct hvc_struct *hp;
>> unsigned long flags;
>> int rc = 0;
>>
>> + mutex_lock(&hvc_open_mutex);
>> +
>> + hp = tty->driver_data;
>> + if (!hp) {
>> + rc = -EIO;
>> + goto out;
>> + }
>> +
>> spin_lock_irqsave(&hp->port.lock, flags);
>> /* Check and then increment for fast path open. */
>> if (hp->port.count++ > 0) {
>> spin_unlock_irqrestore(&hp->port.lock, flags);
>> hvc_kick();
>> - return 0;
>> + goto out;
>> } /* else count == 0 */
>> spin_unlock_irqrestore(&hp->port.lock, flags);
>
> Wait, why isn't this driver just calling tty_port_open() instead of
> trying to open-code all of this?
>
> Keeping a single mutext for open will not protect it from close, it
> will
> just slow things down a bit. There should already be a tty lock held
> by
> the tty core for open() to keep it from racing things, right?
The tty lock should have been held, but not likely across ->install()
and
->open() callbacks, thus resulting in a race between hvc_install() and
hvc_open(),
where hvc_install() sets a data and the hvc_open() clears it. hvc_open()
doesn't
check if the data was set to NULL and proceeds.
>
> Try just removing all of this logic and replacing it with a call to
> tty_port_open() and see if that fixes this issue.
>
> As "proof" of this, I don't see other serial drivers needing a single
> mutex for their open calls, do you?
>
> thanks,
>
> greg k-h
Thank you.
Raghavendra
^ permalink raw reply
* [Bug 207359] MegaRAID SAS 9361 controller hang/reset
From: bugzilla-daemon @ 2020-05-10 3:02 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-207359-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=207359
--- Comment #3 from Cameron (cam@neo-zeon.de) ---
Created attachment 289041
--> https://bugzilla.kernel.org/attachment.cgi?id=289041&action=edit
5.6.11 megaraid POWER hang
Still happens with 5.6.11. There seems to be potentially a bit more output this
time, and I've included output from shutting down too in case it's useful.
--
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [PATCH] powerpc/powernv/pci: fix a RCU-list lock
From: Qian Cai @ 2020-05-10 5:13 UTC (permalink / raw)
To: mpe; +Cc: paulmck, aik, linux-kernel, paulus, Qian Cai, linuxppc-dev
It is unsafe to traverse tbl->it_group_list without the RCU read lock.
WARNING: suspicious RCU usage
5.7.0-rc4-next-20200508 #1 Not tainted
-----------------------------
arch/powerpc/platforms/powernv/pci-ioda-tce.c:355 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
3 locks held by qemu-kvm/4305:
#0: c000000bc3fe6988 (&container->group_lock){++++}-{3:3}, at: vfio_fops_unl_ioctl+0x108/0x410 [vfio]
#1: c00800000fcc7400 (&vfio.iommu_drivers_lock){+.+.}-{3:3}, at: vfio_fops_unl_ioctl+0x148/0x410 [vfio]
#2: c000000bc3fe4d68 (&container->lock){+.+.}-{3:3}, at: tce_iommu_attach_group+0x3c/0x4f0 [vfio_iommu_spapr_tce]
stack backtrace:
CPU: 4 PID: 4305 Comm: qemu-kvm Not tainted 5.7.0-rc4-next-20200508 #1
Call Trace:
[c0000010f29afa60] [c0000000007154c8] dump_stack+0xfc/0x174 (unreliable)
[c0000010f29afab0] [c0000000001d8ff0] lockdep_rcu_suspicious+0x140/0x164
[c0000010f29afb30] [c0000000000dae2c] pnv_pci_unlink_table_and_group+0x11c/0x200
[c0000010f29afb70] [c0000000000d4a34] pnv_pci_ioda2_unset_window+0xc4/0x190
[c0000010f29afbf0] [c0000000000d4b4c] pnv_ioda2_take_ownership+0x4c/0xd0
[c0000010f29afc30] [c00800000fd60ee0] tce_iommu_attach_group+0x2c8/0x4f0 [vfio_iommu_spapr_tce]
[c0000010f29afcd0] [c00800000fcc11a0] vfio_fops_unl_ioctl+0x238/0x410 [vfio]
[c0000010f29afd50] [c0000000005430a8] ksys_ioctl+0xd8/0x130
[c0000010f29afda0] [c000000000543128] sys_ioctl+0x28/0x40
[c0000010f29afdc0] [c000000000038af4] system_call_exception+0x114/0x1e0
[c0000010f29afe20] [c00000000000c8f0] system_call_common+0xf0/0x278
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/powerpc/platforms/powernv/pci-ioda-tce.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda-tce.c b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
index 5dc6847d5f4c..6be9cf292b4e 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
@@ -352,6 +352,8 @@ void pnv_pci_unlink_table_and_group(struct iommu_table *tbl,
/* Remove link to a group from table's list of attached groups */
found = false;
+
+ rcu_read_lock();
list_for_each_entry_rcu(tgl, &tbl->it_group_list, next) {
if (tgl->table_group == table_group) {
list_del_rcu(&tgl->next);
@@ -360,6 +362,8 @@ void pnv_pci_unlink_table_and_group(struct iommu_table *tbl,
break;
}
}
+ rcu_read_unlock();
+
if (WARN_ON(!found))
return;
--
2.21.0 (Apple Git-122.2)
^ permalink raw reply related
* [PATCH] powerpc/mm/book3s64/iommu: fix some RCU-list locks
From: Qian Cai @ 2020-05-10 5:15 UTC (permalink / raw)
To: mpe; +Cc: paulmck, aik, linux-kernel, paulus, Qian Cai, linuxppc-dev
It is safe to traverse mm->context.iommu_group_mem_list with either
mem_list_mutex or the RCU read lock held. Silence a few RCU-list false
positive warnings and fix a few missing RCU read locks.
arch/powerpc/mm/book3s64/iommu_api.c:330 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by qemu-kvm/4305:
#0: c000000bc3fe4d68 (&container->lock){+.+.}-{3:3}, at: tce_iommu_ioctl.part.9+0xc7c/0x1870 [vfio_iommu_spapr_tce]
#1: c000000001501910 (mem_list_mutex){+.+.}-{3:3}, at: mm_iommu_get+0x50/0x190
====
arch/powerpc/mm/book3s64/iommu_api.c:132 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by qemu-kvm/4305:
#0: c000000bc3fe4d68 (&container->lock){+.+.}-{3:3}, at: tce_iommu_ioctl.part.9+0xc7c/0x1870 [vfio_iommu_spapr_tce]
#1: c000000001501910 (mem_list_mutex){+.+.}-{3:3}, at: mm_iommu_do_alloc+0x120/0x5f0
====
arch/powerpc/mm/book3s64/iommu_api.c:292 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by qemu-kvm/4312:
#0: c000000ecafe23c8 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0xdc/0x950 [kvm]
#1: c000000045e6c468 (&kvm->srcu){....}-{0:0}, at: kvmppc_h_put_tce+0x88/0x340 [kvm]
====
arch/powerpc/mm/book3s64/iommu_api.c:424 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by qemu-kvm/4312:
#0: c000000ecafe23c8 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0xdc/0x950 [kvm]
#1: c000000045e6c468 (&kvm->srcu){....}-{0:0}, at: kvmppc_h_put_tce+0x88/0x340 [kvm]
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/powerpc/mm/book3s64/iommu_api.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/iommu_api.c b/arch/powerpc/mm/book3s64/iommu_api.c
index fa05bbd1f682..bf0108b6f445 100644
--- a/arch/powerpc/mm/book3s64/iommu_api.c
+++ b/arch/powerpc/mm/book3s64/iommu_api.c
@@ -129,7 +129,8 @@ static long mm_iommu_do_alloc(struct mm_struct *mm, unsigned long ua,
mutex_lock(&mem_list_mutex);
- list_for_each_entry_rcu(mem2, &mm->context.iommu_group_mem_list, next) {
+ list_for_each_entry_rcu(mem2, &mm->context.iommu_group_mem_list, next,
+ lockdep_is_held(&mem_list_mutex)) {
/* Overlap? */
if ((mem2->ua < (ua + (entries << PAGE_SHIFT))) &&
(ua < (mem2->ua +
@@ -289,6 +290,7 @@ struct mm_iommu_table_group_mem_t *mm_iommu_lookup(struct mm_struct *mm,
{
struct mm_iommu_table_group_mem_t *mem, *ret = NULL;
+ rcu_read_lock();
list_for_each_entry_rcu(mem, &mm->context.iommu_group_mem_list, next) {
if ((mem->ua <= ua) &&
(ua + size <= mem->ua +
@@ -297,6 +299,7 @@ struct mm_iommu_table_group_mem_t *mm_iommu_lookup(struct mm_struct *mm,
break;
}
}
+ rcu_read_unlock();
return ret;
}
@@ -327,7 +330,8 @@ struct mm_iommu_table_group_mem_t *mm_iommu_get(struct mm_struct *mm,
mutex_lock(&mem_list_mutex);
- list_for_each_entry_rcu(mem, &mm->context.iommu_group_mem_list, next) {
+ list_for_each_entry_rcu(mem, &mm->context.iommu_group_mem_list, next,
+ lockdep_is_held(&mem_list_mutex)) {
if ((mem->ua == ua) && (mem->entries == entries)) {
ret = mem;
++mem->used;
@@ -421,6 +425,7 @@ bool mm_iommu_is_devmem(struct mm_struct *mm, unsigned long hpa,
struct mm_iommu_table_group_mem_t *mem;
unsigned long end;
+ rcu_read_lock();
list_for_each_entry_rcu(mem, &mm->context.iommu_group_mem_list, next) {
if (mem->dev_hpa == MM_IOMMU_TABLE_INVALID_HPA)
continue;
@@ -437,6 +442,7 @@ bool mm_iommu_is_devmem(struct mm_struct *mm, unsigned long hpa,
return true;
}
}
+ rcu_read_unlock();
return false;
}
--
2.21.0 (Apple Git-122.2)
^ permalink raw reply related
* [PATCH] powerpc/kvm/book3s64/vio: fix some RCU-list locks
From: Qian Cai @ 2020-05-10 5:18 UTC (permalink / raw)
To: mpe; +Cc: paulmck, aik, linux-kernel, kvm-ppc, paulus, Qian Cai,
linuxppc-dev
It is unsafe to traverse kvm->arch.spapr_tce_tables and
stt->iommu_tables without the RCU read lock held. Also, add
cond_resched_rcu() in places with the RCU read lock held that could take
a while to finish.
arch/powerpc/kvm/book3s_64_vio.c:76 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
no locks held by qemu-kvm/4265.
stack backtrace:
CPU: 96 PID: 4265 Comm: qemu-kvm Not tainted 5.7.0-rc4-next-20200508+ #2
Call Trace:
[c000201a8690f720] [c000000000715948] dump_stack+0xfc/0x174 (unreliable)
[c000201a8690f770] [c0000000001d9470] lockdep_rcu_suspicious+0x140/0x164
[c000201a8690f7f0] [c008000010b9fb48] kvm_spapr_tce_release_iommu_group+0x1f0/0x220 [kvm]
[c000201a8690f870] [c008000010b8462c] kvm_spapr_tce_release_vfio_group+0x54/0xb0 [kvm]
[c000201a8690f8a0] [c008000010b84710] kvm_vfio_destroy+0x88/0x140 [kvm]
[c000201a8690f8f0] [c008000010b7d488] kvm_put_kvm+0x370/0x600 [kvm]
[c000201a8690f990] [c008000010b7e3c0] kvm_vm_release+0x38/0x60 [kvm]
[c000201a8690f9c0] [c0000000005223f4] __fput+0x124/0x330
[c000201a8690fa20] [c000000000151cd8] task_work_run+0xb8/0x130
[c000201a8690fa70] [c0000000001197e8] do_exit+0x4e8/0xfa0
[c000201a8690fb70] [c00000000011a374] do_group_exit+0x64/0xd0
[c000201a8690fbb0] [c000000000132c90] get_signal+0x1f0/0x1200
[c000201a8690fcc0] [c000000000020690] do_notify_resume+0x130/0x3c0
[c000201a8690fda0] [c000000000038d64] syscall_exit_prepare+0x1a4/0x280
[c000201a8690fe20] [c00000000000c8f8] system_call_common+0xf8/0x278
====
arch/powerpc/kvm/book3s_64_vio.c:368 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by qemu-kvm/4264:
#0: c000201ae2d000d8 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0xdc/0x950 [kvm]
#1: c000200c9ed0c468 (&kvm->srcu){....}-{0:0}, at: kvmppc_h_put_tce+0x88/0x340 [kvm]
====
arch/powerpc/kvm/book3s_64_vio.c:108 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by qemu-kvm/4257:
#0: c000200b1b363a40 (&kv->lock){+.+.}-{3:3}, at: kvm_vfio_set_attr+0x598/0x6c0 [kvm]
====
arch/powerpc/kvm/book3s_64_vio.c:146 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by qemu-kvm/4257:
#0: c000200b1b363a40 (&kv->lock){+.+.}-{3:3}, at: kvm_vfio_set_attr+0x598/0x6c0 [kvm]
Signed-off-by: Qian Cai <cai@lca.pw>
---
arch/powerpc/kvm/book3s_64_vio.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_vio.c b/arch/powerpc/kvm/book3s_64_vio.c
index 50555ad1db93..4f5016bab723 100644
--- a/arch/powerpc/kvm/book3s_64_vio.c
+++ b/arch/powerpc/kvm/book3s_64_vio.c
@@ -73,6 +73,7 @@ extern void kvm_spapr_tce_release_iommu_group(struct kvm *kvm,
struct kvmppc_spapr_tce_iommu_table *stit, *tmp;
struct iommu_table_group *table_group = NULL;
+ rcu_read_lock();
list_for_each_entry_rcu(stt, &kvm->arch.spapr_tce_tables, list) {
table_group = iommu_group_get_iommudata(grp);
@@ -87,7 +88,9 @@ extern void kvm_spapr_tce_release_iommu_group(struct kvm *kvm,
kref_put(&stit->kref, kvm_spapr_tce_liobn_put);
}
}
+ cond_resched_rcu();
}
+ rcu_read_unlock();
}
extern long kvm_spapr_tce_attach_iommu_group(struct kvm *kvm, int tablefd,
@@ -105,12 +108,14 @@ extern long kvm_spapr_tce_attach_iommu_group(struct kvm *kvm, int tablefd,
if (!f.file)
return -EBADF;
+ rcu_read_lock();
list_for_each_entry_rcu(stt, &kvm->arch.spapr_tce_tables, list) {
if (stt == f.file->private_data) {
found = true;
break;
}
}
+ rcu_read_unlock();
fdput(f);
@@ -143,6 +148,7 @@ extern long kvm_spapr_tce_attach_iommu_group(struct kvm *kvm, int tablefd,
if (!tbl)
return -EINVAL;
+ rcu_read_lock();
list_for_each_entry_rcu(stit, &stt->iommu_tables, next) {
if (tbl != stit->tbl)
continue;
@@ -150,14 +156,17 @@ extern long kvm_spapr_tce_attach_iommu_group(struct kvm *kvm, int tablefd,
if (!kref_get_unless_zero(&stit->kref)) {
/* stit is being destroyed */
iommu_tce_table_put(tbl);
+ rcu_read_unlock();
return -ENOTTY;
}
/*
* The table is already known to this KVM, we just increased
* its KVM reference counter and can return.
*/
+ rcu_read_unlock();
return 0;
}
+ rcu_read_unlock();
stit = kzalloc(sizeof(*stit), GFP_KERNEL);
if (!stit) {
@@ -365,18 +374,20 @@ static long kvmppc_tce_validate(struct kvmppc_spapr_tce_table *stt,
if (kvmppc_tce_to_ua(stt->kvm, tce, &ua))
return H_TOO_HARD;
+ rcu_read_lock();
list_for_each_entry_rcu(stit, &stt->iommu_tables, next) {
unsigned long hpa = 0;
struct mm_iommu_table_group_mem_t *mem;
long shift = stit->tbl->it_page_shift;
mem = mm_iommu_lookup(stt->kvm->mm, ua, 1ULL << shift);
- if (!mem)
- return H_TOO_HARD;
-
- if (mm_iommu_ua_to_hpa(mem, ua, shift, &hpa))
+ if (!mem || mm_iommu_ua_to_hpa(mem, ua, shift, &hpa)) {
+ rcu_read_unlock();
return H_TOO_HARD;
+ }
+ cond_resched_rcu();
}
+ rcu_read_unlock();
return H_SUCCESS;
}
--
2.21.0 (Apple Git-122.2)
^ permalink raw reply related
* Re: [PATCH] tty: hvc: Fix data abort due to race in hvc_open
From: Greg KH @ 2020-05-10 6:48 UTC (permalink / raw)
To: rananta; +Cc: andrew, linuxppc-dev, linux-kernel, jslaby
In-Reply-To: <98bbe7afabf48d8e8fe839fdc9e836a5@codeaurora.org>
On Sat, May 09, 2020 at 06:30:56PM -0700, rananta@codeaurora.org wrote:
> On 2020-05-06 02:48, Greg KH wrote:
> > On Mon, Apr 27, 2020 at 08:26:01PM -0700, Raghavendra Rao Ananta wrote:
> > > Potentially, hvc_open() can be called in parallel when two tasks calls
> > > open() on /dev/hvcX. In such a scenario, if the
> > > hp->ops->notifier_add()
> > > callback in the function fails, where it sets the tty->driver_data to
> > > NULL, the parallel hvc_open() can see this NULL and cause a memory
> > > abort.
> > > Hence, serialize hvc_open and check if tty->private_data is NULL
> > > before
> > > proceeding ahead.
> > >
> > > The issue can be easily reproduced by launching two tasks
> > > simultaneously
> > > that does nothing but open() and close() on /dev/hvcX.
> > > For example:
> > > $ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 &
> > >
> > > Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
> > > ---
> > > drivers/tty/hvc/hvc_console.c | 16 ++++++++++++++--
> > > 1 file changed, 14 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/tty/hvc/hvc_console.c
> > > b/drivers/tty/hvc/hvc_console.c
> > > index 436cc51c92c3..ebe26fe5ac09 100644
> > > --- a/drivers/tty/hvc/hvc_console.c
> > > +++ b/drivers/tty/hvc/hvc_console.c
> > > @@ -75,6 +75,8 @@ static LIST_HEAD(hvc_structs);
> > > */
> > > static DEFINE_MUTEX(hvc_structs_mutex);
> > >
> > > +/* Mutex to serialize hvc_open */
> > > +static DEFINE_MUTEX(hvc_open_mutex);
> > > /*
> > > * This value is used to assign a tty->index value to a hvc_struct
> > > based
> > > * upon order of exposure via hvc_probe(), when we can not match it
> > > to
> > > @@ -346,16 +348,24 @@ static int hvc_install(struct tty_driver
> > > *driver, struct tty_struct *tty)
> > > */
> > > static int hvc_open(struct tty_struct *tty, struct file * filp)
> > > {
> > > - struct hvc_struct *hp = tty->driver_data;
> > > + struct hvc_struct *hp;
> > > unsigned long flags;
> > > int rc = 0;
> > >
> > > + mutex_lock(&hvc_open_mutex);
> > > +
> > > + hp = tty->driver_data;
> > > + if (!hp) {
> > > + rc = -EIO;
> > > + goto out;
> > > + }
> > > +
> > > spin_lock_irqsave(&hp->port.lock, flags);
> > > /* Check and then increment for fast path open. */
> > > if (hp->port.count++ > 0) {
> > > spin_unlock_irqrestore(&hp->port.lock, flags);
> > > hvc_kick();
> > > - return 0;
> > > + goto out;
> > > } /* else count == 0 */
> > > spin_unlock_irqrestore(&hp->port.lock, flags);
> >
> > Wait, why isn't this driver just calling tty_port_open() instead of
> > trying to open-code all of this?
> >
> > Keeping a single mutext for open will not protect it from close, it will
> > just slow things down a bit. There should already be a tty lock held by
> > the tty core for open() to keep it from racing things, right?
> The tty lock should have been held, but not likely across ->install() and
> ->open() callbacks, thus resulting in a race between hvc_install() and
> hvc_open(),
How? The tty lock is held in install, and should not conflict with
open(), otherwise we would be seeing this happen in all tty drivers,
right?
> where hvc_install() sets a data and the hvc_open() clears it. hvc_open()
> doesn't
> check if the data was set to NULL and proceeds.
What data is being set that hvc_open is checking?
And you are not grabbing a lock in your install callback, you are only
serializing your open call here, I don't see how this is fixing anything
other than perhaps slowing down your codepaths.
As an arument why this isn't correct, can you answer why this same type
of change wouldn't be required for all tty drivers in the tree?
thanks,
greg k-h
^ permalink raw reply
* sort out the flush_icache_range mess
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
Hi all,
flush_icache_range is mostly used for kernel address, except for the following
cases:
- the nommu brk and mmap implementations,
- the read_code helper that is only used for binfmt_flat, binfmt_elf_fdpic,
and binfmt_aout including the broken ia32 compat version
- binfmt_flat itself,
none of which really are used by a typical MMU enabled kernel, as a.out can
only be build for alpha and m68k to start with.
But strangely enough commit ae92ef8a4424 ("PATCH] flush icache in correct
context") added a "set_fs(KERNEL_DS)" around the flush_icache_range call
in the module loader, because apparently m68k assumed user pointers.
This series first cleans up the cacheflush implementations, largely by
switching as much as possible to the asm-generic version after a few
preparations, then moves the misnamed current flush_icache_user_range to
a new name, to finally introduce a real flush_icache_user_range to be used
for the above use cases to flush the instruction cache for a userspace
address range. The last patch then drops the set_fs in the module code
and moves it into the m68k implementation.
A git tree is available here:
git://git.infradead.org/users/hch/misc.git flush_icache_range
Gitweb:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/flush_icache_range
^ permalink raw reply
* [PATCH 01/31] arm: fix the flush_icache_range arguments in set_fiq_handler
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
The arguments passed look bogus, try to fix them to something that seems
to make sense.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm/kernel/fiq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
index cd1234c103fcd..98ca3e3fa8471 100644
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -98,8 +98,8 @@ void set_fiq_handler(void *start, unsigned int length)
memcpy(base + offset, start, length);
if (!cache_is_vipt_nonaliasing())
- flush_icache_range((unsigned long)base + offset, offset +
- length);
+ flush_icache_range((unsigned long)base + offset,
+ (unsigned long)base + offset + length);
flush_icache_range(0xffff0000 + offset, 0xffff0000 + offset + length);
}
--
2.26.2
^ permalink raw reply related
* [PATCH 02/31] arm64: fix the flush_icache_range arguments in machine_kexec
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
The second argument is the end "pointer", not the length.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm64/kernel/machine_kexec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index 8e9c924423b4e..a0b144cfaea71 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -177,6 +177,7 @@ void machine_kexec(struct kimage *kimage)
* the offline CPUs. Therefore, we must use the __* variant here.
*/
__flush_icache_range((uintptr_t)reboot_code_buffer,
+ (uintptr_t)reboot_code_buffer +
arm64_relocate_new_kernel_size);
/* Flush the kimage list and its buffers. */
--
2.26.2
^ permalink raw reply related
* [PATCH 03/31] MIPS: unexport __flush_icache_user_range
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
__flush_icache_user_range is not used in modular code, so unexport it.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/mips/mm/cache.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/mips/mm/cache.c b/arch/mips/mm/cache.c
index 33b409391ddb6..ad6df1cea866f 100644
--- a/arch/mips/mm/cache.c
+++ b/arch/mips/mm/cache.c
@@ -36,7 +36,6 @@ EXPORT_SYMBOL_GPL(flush_icache_range);
void (*local_flush_icache_range)(unsigned long start, unsigned long end);
EXPORT_SYMBOL_GPL(local_flush_icache_range);
void (*__flush_icache_user_range)(unsigned long start, unsigned long end);
-EXPORT_SYMBOL_GPL(__flush_icache_user_range);
void (*__local_flush_icache_user_range)(unsigned long start, unsigned long end);
EXPORT_SYMBOL_GPL(__local_flush_icache_user_range);
--
2.26.2
^ permalink raw reply related
* [PATCH 04/31] nds32: unexport flush_icache_page
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
flush_icache_page is only used by mm/memory.c.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/nds32/mm/cacheflush.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/nds32/mm/cacheflush.c b/arch/nds32/mm/cacheflush.c
index 254703653b6f5..8f168b33065fa 100644
--- a/arch/nds32/mm/cacheflush.c
+++ b/arch/nds32/mm/cacheflush.c
@@ -35,7 +35,6 @@ void flush_icache_page(struct vm_area_struct *vma, struct page *page)
kunmap_atomic((void *)kaddr);
local_irq_restore(flags);
}
-EXPORT_SYMBOL(flush_icache_page);
void flush_icache_user_range(struct vm_area_struct *vma, struct page *page,
unsigned long addr, int len)
--
2.26.2
^ permalink raw reply related
* [PATCH 05/31] powerpc: unexport flush_icache_user_range
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
flush_icache_user_range is only used by copy_to_user_page, which is
only used by core VM code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/powerpc/mm/mem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 041ed7cfd341a..f0d1bf0a8e14f 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -587,7 +587,6 @@ void flush_icache_user_range(struct vm_area_struct *vma, struct page *page,
flush_icache_range(maddr, maddr + len);
kunmap(page);
}
-EXPORT_SYMBOL(flush_icache_user_range);
/*
* System memory should not be in /proc/iomem but various tools expect it
--
2.26.2
^ permalink raw reply related
* [PATCH 06/31] unicore32: remove flush_cache_user_range
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
flush_cache_user_range is an ARMism not used by any generic or unicore32
specific code.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/unicore32/include/asm/cacheflush.h | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/unicore32/include/asm/cacheflush.h b/arch/unicore32/include/asm/cacheflush.h
index dc8c0b41538f8..9393ca4047e93 100644
--- a/arch/unicore32/include/asm/cacheflush.h
+++ b/arch/unicore32/include/asm/cacheflush.h
@@ -132,14 +132,6 @@ extern void flush_cache_page(struct vm_area_struct *vma,
#define flush_cache_dup_mm(mm) flush_cache_mm(mm)
-/*
- * flush_cache_user_range is used when we want to ensure that the
- * Harvard caches are synchronised for the user space address range.
- * This is used for the UniCore private sys_cacheflush system call.
- */
-#define flush_cache_user_range(vma, start, end) \
- __cpuc_coherent_user_range((start) & PAGE_MASK, PAGE_ALIGN(end))
-
/*
* Perform necessary cache operations to ensure that data previously
* stored within this range of addresses can be executed by the CPU.
--
2.26.2
^ permalink raw reply related
* [PATCH 07/31] asm-generic: fix the inclusion guards for cacheflush.h
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
cacheflush.h uses a somewhat to generic include guard name that clashes
with various arch files. Use a more specific one.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
include/asm-generic/cacheflush.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
index cac7404b2bdd2..906277492ec59 100644
--- a/include/asm-generic/cacheflush.h
+++ b/include/asm-generic/cacheflush.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef __ASM_CACHEFLUSH_H
-#define __ASM_CACHEFLUSH_H
+#ifndef _ASM_GENERIC_CACHEFLUSH_H
+#define _ASM_GENERIC_CACHEFLUSH_H
/* Keep includes the same across arches. */
#include <linux/mm.h>
@@ -109,4 +109,4 @@ static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
memcpy(dst, src, len)
#endif
-#endif /* __ASM_CACHEFLUSH_H */
+#endif /* _ASM_GENERIC_CACHEFLUSH_H */
--
2.26.2
^ permalink raw reply related
* [PATCH 08/31] asm-generic: don't include <linux/mm.h> in cacheflush.h
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
This seems to lead to some crazy include loops when using
asm-generic/cacheflush.h on more architectures, so leave it
to the arch header for now.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/um/include/asm/tlb.h | 2 ++
arch/x86/include/asm/cacheflush.h | 2 ++
include/asm-generic/cacheflush.h | 3 ---
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/um/include/asm/tlb.h b/arch/um/include/asm/tlb.h
index 70ee603839006..ff9c62828962c 100644
--- a/arch/um/include/asm/tlb.h
+++ b/arch/um/include/asm/tlb.h
@@ -2,6 +2,8 @@
#ifndef __UM_TLB_H
#define __UM_TLB_H
+#include <linux/mm.h>
+
#include <asm/tlbflush.h>
#include <asm-generic/cacheflush.h>
#include <asm-generic/tlb.h>
diff --git a/arch/x86/include/asm/cacheflush.h b/arch/x86/include/asm/cacheflush.h
index 63feaf2a5f93d..b192d917a6d0b 100644
--- a/arch/x86/include/asm/cacheflush.h
+++ b/arch/x86/include/asm/cacheflush.h
@@ -2,6 +2,8 @@
#ifndef _ASM_X86_CACHEFLUSH_H
#define _ASM_X86_CACHEFLUSH_H
+#include <linux/mm.h>
+
/* Caches aren't brain-dead on the intel. */
#include <asm-generic/cacheflush.h>
#include <asm/special_insns.h>
diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
index 906277492ec59..bf9bb83e9fc8d 100644
--- a/include/asm-generic/cacheflush.h
+++ b/include/asm-generic/cacheflush.h
@@ -2,9 +2,6 @@
#ifndef _ASM_GENERIC_CACHEFLUSH_H
#define _ASM_GENERIC_CACHEFLUSH_H
-/* Keep includes the same across arches. */
-#include <linux/mm.h>
-
#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
/*
--
2.26.2
^ permalink raw reply related
* [PATCH 09/31] asm-generic: improve the flush_dcache_page stub
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
There is a magic ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE cpp symbol that
guards non-stub availability of flush_dcache_pagge. Use that to
check if flush_dcache_pagg is implemented.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
include/asm-generic/cacheflush.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
index bf9bb83e9fc8d..bbbb4d4ef6516 100644
--- a/include/asm-generic/cacheflush.h
+++ b/include/asm-generic/cacheflush.h
@@ -2,8 +2,6 @@
#ifndef _ASM_GENERIC_CACHEFLUSH_H
#define _ASM_GENERIC_CACHEFLUSH_H
-#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
-
/*
* The cache doesn't need to be flushed when TLB entries change when
* the cache is mapped to physical memory, not virtual memory
@@ -42,12 +40,14 @@ static inline void flush_cache_page(struct vm_area_struct *vma,
}
#endif
-#ifndef flush_dcache_page
+#ifndef ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
static inline void flush_dcache_page(struct page *page)
{
}
+#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
#endif
+
#ifndef flush_dcache_mmap_lock
static inline void flush_dcache_mmap_lock(struct address_space *mapping)
{
--
2.26.2
^ permalink raw reply related
* [PATCH 10/31] alpha: use asm-generic/cacheflush.h
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
Alpha needs almost no cache flushing routines of its own. Rely on
asm-generic/cacheflush.h for the defaults.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/alpha/include/asm/cacheflush.h | 28 ++++++----------------------
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/arch/alpha/include/asm/cacheflush.h b/arch/alpha/include/asm/cacheflush.h
index 89128489cb598..636d7ca0d05f6 100644
--- a/arch/alpha/include/asm/cacheflush.h
+++ b/arch/alpha/include/asm/cacheflush.h
@@ -4,19 +4,6 @@
#include <linux/mm.h>
-/* Caches aren't brain-dead on the Alpha. */
-#define flush_cache_all() do { } while (0)
-#define flush_cache_mm(mm) do { } while (0)
-#define flush_cache_dup_mm(mm) do { } while (0)
-#define flush_cache_range(vma, start, end) do { } while (0)
-#define flush_cache_page(vma, vmaddr, pfn) do { } while (0)
-#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
-#define flush_dcache_page(page) do { } while (0)
-#define flush_dcache_mmap_lock(mapping) do { } while (0)
-#define flush_dcache_mmap_unlock(mapping) do { } while (0)
-#define flush_cache_vmap(start, end) do { } while (0)
-#define flush_cache_vunmap(start, end) do { } while (0)
-
/* Note that the following two definitions are _highly_ dependent
on the contexts in which they are used in the kernel. I personally
think it is criminal how loosely defined these macros are. */
@@ -59,20 +46,17 @@ flush_icache_user_range(struct vm_area_struct *vma, struct page *page,
mm->context[smp_processor_id()] = 0;
}
}
-#else
+#define flush_icache_user_range flush_icache_user_range
+#else /* CONFIG_SMP */
extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr, int len);
-#endif
+#define flush_icache_user_range flush_icache_user_range
+#endif /* CONFIG_SMP */
/* This is used only in __do_fault and do_swap_page. */
#define flush_icache_page(vma, page) \
- flush_icache_user_range((vma), (page), 0, 0)
+ flush_icache_user_range((vma), (page), 0, 0)
-#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
-do { memcpy(dst, src, len); \
- flush_icache_user_range(vma, page, vaddr, len); \
-} while (0)
-#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
- memcpy(dst, src, len)
+#include <asm-generic/cacheflush.h>
#endif /* _ALPHA_CACHEFLUSH_H */
--
2.26.2
^ permalink raw reply related
* [PATCH 11/31] arm64: use asm-generic/cacheflush.h
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
ARM64 needs almost no cache flushing routines of its own. Rely on
asm-generic/cacheflush.h for the defaults.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/arm64/include/asm/cacheflush.h | 46 ++++-------------------------
1 file changed, 5 insertions(+), 41 deletions(-)
diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h
index e6cca3d4acf70..03a5a187163ab 100644
--- a/arch/arm64/include/asm/cacheflush.h
+++ b/arch/arm64/include/asm/cacheflush.h
@@ -94,20 +94,7 @@ static inline void flush_icache_range(unsigned long start, unsigned long end)
#endif
kick_all_cpus_sync();
}
-
-static inline void flush_cache_mm(struct mm_struct *mm)
-{
-}
-
-static inline void flush_cache_page(struct vm_area_struct *vma,
- unsigned long user_addr, unsigned long pfn)
-{
-}
-
-static inline void flush_cache_range(struct vm_area_struct *vma,
- unsigned long start, unsigned long end)
-{
-}
+#define flush_icache_range flush_icache_range
/*
* Cache maintenance functions used by the DMA API. No to be used directly.
@@ -123,12 +110,7 @@ extern void __dma_flush_area(const void *, size_t);
*/
extern void copy_to_user_page(struct vm_area_struct *, struct page *,
unsigned long, void *, const void *, unsigned long);
-#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
- do { \
- memcpy(dst, src, len); \
- } while (0)
-
-#define flush_cache_dup_mm(mm) flush_cache_mm(mm)
+#define copy_to_user_page copy_to_user_page
/*
* flush_dcache_page is used when the kernel has written to the page
@@ -154,29 +136,11 @@ static __always_inline void __flush_icache_all(void)
dsb(ish);
}
-#define flush_dcache_mmap_lock(mapping) do { } while (0)
-#define flush_dcache_mmap_unlock(mapping) do { } while (0)
-
-/*
- * We don't appear to need to do anything here. In fact, if we did, we'd
- * duplicate cache flushing elsewhere performed by flush_dcache_page().
- */
-#define flush_icache_page(vma,page) do { } while (0)
-
-/*
- * Not required on AArch64 (PIPT or VIPT non-aliasing D-cache).
- */
-static inline void flush_cache_vmap(unsigned long start, unsigned long end)
-{
-}
-
-static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
-{
-}
-
int set_memory_valid(unsigned long addr, int numpages, int enable);
int set_direct_map_invalid_noflush(struct page *page);
int set_direct_map_default_noflush(struct page *page);
-#endif
+#include <asm-generic/cacheflush.h>
+
+#endif /* __ASM_CACHEFLUSH_H */
--
2.26.2
^ permalink raw reply related
* [PATCH 12/31] c6x: use asm-generic/cacheflush.h
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
C6x needs almost no cache flushing routines of its own. Rely on
asm-generic/cacheflush.h for the defaults.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/c6x/include/asm/cacheflush.h | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/arch/c6x/include/asm/cacheflush.h b/arch/c6x/include/asm/cacheflush.h
index 4540b40475e6c..10922d528de6d 100644
--- a/arch/c6x/include/asm/cacheflush.h
+++ b/arch/c6x/include/asm/cacheflush.h
@@ -16,21 +16,6 @@
#include <asm/page.h>
#include <asm/string.h>
-/*
- * virtually-indexed cache management (our cache is physically indexed)
- */
-#define flush_cache_all() do {} while (0)
-#define flush_cache_mm(mm) do {} while (0)
-#define flush_cache_dup_mm(mm) do {} while (0)
-#define flush_cache_range(mm, start, end) do {} while (0)
-#define flush_cache_page(vma, vmaddr, pfn) do {} while (0)
-#define flush_cache_vmap(start, end) do {} while (0)
-#define flush_cache_vunmap(start, end) do {} while (0)
-#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
-#define flush_dcache_page(page) do {} while (0)
-#define flush_dcache_mmap_lock(mapping) do {} while (0)
-#define flush_dcache_mmap_unlock(mapping) do {} while (0)
-
/*
* physically-indexed cache management
*/
@@ -49,14 +34,12 @@ do { \
(unsigned long) page_address(page) + PAGE_SIZE)); \
} while (0)
-
#define copy_to_user_page(vma, page, vaddr, dst, src, len) \
do { \
memcpy(dst, src, len); \
flush_icache_range((unsigned) (dst), (unsigned) (dst) + (len)); \
} while (0)
-#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
- memcpy(dst, src, len)
+#include <asm-generic/cacheflush.h>
#endif /* _ASM_C6X_CACHEFLUSH_H */
--
2.26.2
^ permalink raw reply related
* [PATCH 13/31] hexagon: use asm-generic/cacheflush.h
From: Christoph Hellwig @ 2020-05-10 7:54 UTC (permalink / raw)
To: Andrew Morton, Arnd Bergmann, Roman Zippel
Cc: linux-arch, linux-xtensa, Michal Simek, Jessica Yu, linux-ia64,
linux-c6x-dev, linux-sh, linux-hexagon, x86, linux-um,
linux-kernel, linux-mips, linux-mm, linux-m68k, openrisc,
linux-alpha, sparclinux, linux-fsdevel, linux-riscv, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20200510075510.987823-1-hch@lst.de>
Hexagon needs almost no cache flushing routines of its own. Rely on
asm-generic/cacheflush.h for the defaults.
Signed-off-by: Christoph Hellwig <hch@lst.de>
---
arch/hexagon/include/asm/cacheflush.h | 19 +++++--------------
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/arch/hexagon/include/asm/cacheflush.h b/arch/hexagon/include/asm/cacheflush.h
index fb447de45d54c..6eff0730e6efd 100644
--- a/arch/hexagon/include/asm/cacheflush.h
+++ b/arch/hexagon/include/asm/cacheflush.h
@@ -25,29 +25,17 @@
#define LINESIZE 32
#define LINEBITS 5
-#define flush_cache_all() do { } while (0)
-#define flush_cache_mm(mm) do { } while (0)
-#define flush_cache_dup_mm(mm) do { } while (0)
-#define flush_cache_range(vma, start, end) do { } while (0)
-#define flush_cache_page(vma, vmaddr, pfn) do { } while (0)
-#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0
-#define flush_dcache_page(page) do { } while (0)
-#define flush_dcache_mmap_lock(mapping) do { } while (0)
-#define flush_dcache_mmap_unlock(mapping) do { } while (0)
-#define flush_icache_page(vma, pg) do { } while (0)
-#define flush_icache_user_range(vma, pg, adr, len) do { } while (0)
-#define flush_cache_vmap(start, end) do { } while (0)
-#define flush_cache_vunmap(start, end) do { } while (0)
-
/*
* Flush Dcache range through current map.
*/
extern void flush_dcache_range(unsigned long start, unsigned long end);
+#define flush_dcache_range flush_dcache_range
/*
* Flush Icache range through current map.
*/
extern void flush_icache_range(unsigned long start, unsigned long end);
+#define flush_icache_range flush_icache_range
/*
* Memory-management related flushes are there to ensure in non-physically
@@ -78,6 +66,7 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
void copy_to_user_page(struct vm_area_struct *vma, struct page *page,
unsigned long vaddr, void *dst, void *src, int len);
+#define copy_to_user_page copy_to_user_page
#define copy_from_user_page(vma, page, vaddr, dst, src, len) \
memcpy(dst, src, len)
@@ -85,4 +74,6 @@ void copy_to_user_page(struct vm_area_struct *vma, struct page *page,
extern void hexagon_inv_dcache_range(unsigned long start, unsigned long end);
extern void hexagon_clean_dcache_range(unsigned long start, unsigned long end);
+#include <asm-generic/cacheflush.h>
+
#endif
--
2.26.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox