* [PATCH][next] powerpc/mm: fix spelling mistake "Outisde" -> "Outside"
From: Colin King @ 2019-04-23 15:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Aneesh Kumar K . V, linuxppc-dev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There are several identical spelling mistakes in warning messages,
fix these.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
arch/powerpc/mm/hash_utils_64.c | 4 ++--
arch/powerpc/mm/pgtable-hash64.c | 2 +-
arch/powerpc/mm/pgtable-radix.c | 6 +++---
arch/powerpc/mm/pgtable_64.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index f727197de713..6eb89643ce58 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -784,7 +784,7 @@ int hash__create_section_mapping(unsigned long start, unsigned long end, int nid
int rc;
if (end >= H_VMALLOC_START) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
return -1;
}
@@ -932,7 +932,7 @@ static void __init htab_initialize(void)
base, size, prot);
if ((base + size) >= H_VMALLOC_START) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
continue;
}
diff --git a/arch/powerpc/mm/pgtable-hash64.c b/arch/powerpc/mm/pgtable-hash64.c
index d934de4e2b3a..097a3b3538b1 100644
--- a/arch/powerpc/mm/pgtable-hash64.c
+++ b/arch/powerpc/mm/pgtable-hash64.c
@@ -115,7 +115,7 @@ int __meminit hash__vmemmap_create_mapping(unsigned long start,
int rc;
if ((start + page_size) >= H_VMEMMAP_END) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
return -1;
}
diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
index e6d5065b0bc8..fcb0169e2d32 100644
--- a/arch/powerpc/mm/pgtable-radix.c
+++ b/arch/powerpc/mm/pgtable-radix.c
@@ -341,7 +341,7 @@ void __init radix_init_pgtable(void)
*/
if ((reg->base + reg->size) >= RADIX_VMALLOC_START) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
continue;
}
@@ -902,7 +902,7 @@ static void __meminit remove_pagetable(unsigned long start, unsigned long end)
int __meminit radix__create_section_mapping(unsigned long start, unsigned long end, int nid)
{
if (end >= RADIX_VMALLOC_START) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
return -1;
}
@@ -934,7 +934,7 @@ int __meminit radix__vmemmap_create_mapping(unsigned long start,
int ret;
if ((start + page_size) >= RADIX_VMEMMAP_END) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
return -1;
}
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 72f58c076e26..95ad2a09501c 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -122,7 +122,7 @@ void __iomem *__ioremap_at(phys_addr_t pa, void *ea, unsigned long size, pgprot_
return NULL;
if ((ea + size) >= (void *)IOREMAP_END) {
- pr_warn("Outisde the supported range\n");
+ pr_warn("Outside the supported range\n");
return NULL;
}
--
2.20.1
^ permalink raw reply related
* [PATCH] powerpc/pseries: Use correct event modifier in rtas_parse_epow_errlog()
From: Yue Haibing @ 2019-04-23 14:35 UTC (permalink / raw)
To: benh, paulus, mpe, mahesh, npiggin, ganeshgr, anton
Cc: YueHaibing, linuxppc-dev, linux-kernel
From: YueHaibing <yuehaibing@huawei.com>
rtas_parse_epow_errlog() should pass 'modifier' to
handle_system_shutdown, because event modifier only use
bottom 4 bits.
Fixes: 55fc0c561742 ("powerpc/pseries: Parse and handle EPOW interrupts")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
arch/powerpc/platforms/pseries/ras.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
index c97d153..744604d 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -285,7 +285,7 @@ static void rtas_parse_epow_errlog(struct rtas_error_log *log)
break;
case EPOW_SYSTEM_SHUTDOWN:
- handle_system_shutdown(epow_log->event_modifier);
+ handle_system_shutdown(event_modifier);
break;
case EPOW_SYSTEM_HALT:
--
2.7.0
^ permalink raw reply related
* [PATCH v2 4/4] powerpc/boot: Add lzo support for uImage
From: Christophe Leroy @ 2019-04-23 14:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <2d3a59015307d368d6ac1a62fe7e47f5b39e2fe2.1556028978.git.christophe.leroy@c-s.fr>
This patch allows to generate lzo compressed uImage
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2: restore alphabetic order in Kconfig
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/boot/Makefile | 2 ++
arch/powerpc/boot/wrapper | 5 ++++-
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c9fd20988237..b5a3708a852d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -202,6 +202,7 @@ config PPC
select HAVE_KERNEL_BZIP2 if DEFAULT_UIMAGE
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZMA if DEFAULT_UIMAGE
+ select HAVE_KERNEL_LZO if DEFAULT_UIMAGE
select HAVE_KERNEL_XZ if PPC_BOOK3S || 44x
select HAVE_KPROBES
select HAVE_KPROBES_ON_FTRACE
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 0a7f8c2dc8af..4675575774d7 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -24,6 +24,7 @@ compress-$(CONFIG_KERNEL_GZIP) := CONFIG_KERNEL_GZIP
compress-$(CONFIG_KERNEL_XZ) := CONFIG_KERNEL_XZ
compress-$(CONFIG_KERNEL_LZMA) := CONFIG_KERNEL_LZMA
compress-$(CONFIG_KERNEL_BZIP2) := CONFIG_KERNEL_BZIP2
+compress-$(CONFIG_KERNEL_LZO) := CONFIG_KERNEL_LZO
ifdef CROSS32_COMPILE
BOOTCC := $(CROSS32_COMPILE)gcc
@@ -261,6 +262,7 @@ compressor-$(CONFIG_KERNEL_GZIP) := gz
compressor-$(CONFIG_KERNEL_XZ) := xz
compressor-$(CONFIG_KERNEL_LZMA) := lzma
compressor-$(CONFIG_KERNEL_BZIP2) := bz2
+compressor-$(CONFIG_KERNEL_LZO) := lzo
# args (to if_changed): 1 = (this rule), 2 = platform, 3 = dts 4=dtb 5=initrd
quiet_cmd_wrap = WRAP $@
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index d1384e8c0c6f..2fd3483f9d80 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -137,7 +137,7 @@ while [ "$#" -gt 0 ]; do
-Z)
shift
[ "$#" -gt 0 ] || usage
- [ "$1" != "gz" -o "$1" != "xz" -o "$1" != "lzma" -o "$1" != "bz2" -o "$1" != "none" ] || usage
+ [ "$1" != "gz" -o "$1" != "xz" -o "$1" != "lzma" -o "$1" != "bz2" -o "$1" != "lzo" -o "$1" != "none" ] || usage
compression=".$1"
uboot_comp=$1
@@ -383,6 +383,9 @@ if [ -z "$cacheit" -o ! -f "$vmz$compression" -o "$vmz$compression" -ot "$kernel
.bz2)
bzip2 -f "$vmz.$$"
;;
+ .lzo)
+ lzop -f -9 "$vmz.$$"
+ ;;
*)
# drop the compression suffix so the stripped vmlinux is used
compression=
--
2.13.3
^ permalink raw reply related
* [PATCH v2 3/4] powerpc/boot: Add bzip2 support for uImage
From: Christophe Leroy @ 2019-04-23 14:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <2d3a59015307d368d6ac1a62fe7e47f5b39e2fe2.1556028978.git.christophe.leroy@c-s.fr>
This patch allows to generate bzip2 compressed uImage
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2: Restore alphabetic order in Kconfig
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/boot/Makefile | 2 ++
arch/powerpc/boot/wrapper | 8 +++++++-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index dd22988cac0b..c9fd20988237 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -199,6 +199,7 @@ config PPC
select HAVE_IDE
select HAVE_IOREMAP_PROT
select HAVE_IRQ_EXIT_ON_IRQ_STACK
+ select HAVE_KERNEL_BZIP2 if DEFAULT_UIMAGE
select HAVE_KERNEL_GZIP
select HAVE_KERNEL_LZMA if DEFAULT_UIMAGE
select HAVE_KERNEL_XZ if PPC_BOOK3S || 44x
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 9b7b11a22925..0a7f8c2dc8af 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -23,6 +23,7 @@ all: $(obj)/zImage
compress-$(CONFIG_KERNEL_GZIP) := CONFIG_KERNEL_GZIP
compress-$(CONFIG_KERNEL_XZ) := CONFIG_KERNEL_XZ
compress-$(CONFIG_KERNEL_LZMA) := CONFIG_KERNEL_LZMA
+compress-$(CONFIG_KERNEL_BZIP2) := CONFIG_KERNEL_BZIP2
ifdef CROSS32_COMPILE
BOOTCC := $(CROSS32_COMPILE)gcc
@@ -259,6 +260,7 @@ endif
compressor-$(CONFIG_KERNEL_GZIP) := gz
compressor-$(CONFIG_KERNEL_XZ) := xz
compressor-$(CONFIG_KERNEL_LZMA) := lzma
+compressor-$(CONFIG_KERNEL_BZIP2) := bz2
# args (to if_changed): 1 = (this rule), 2 = platform, 3 = dts 4=dtb 5=initrd
quiet_cmd_wrap = WRAP $@
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 51dc42f5acbc..d1384e8c0c6f 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -137,7 +137,7 @@ while [ "$#" -gt 0 ]; do
-Z)
shift
[ "$#" -gt 0 ] || usage
- [ "$1" != "gz" -o "$1" != "xz" -o "$1" != "lzma" -o "$1" != "none" ] || usage
+ [ "$1" != "gz" -o "$1" != "xz" -o "$1" != "lzma" -o "$1" != "bz2" -o "$1" != "none" ] || usage
compression=".$1"
uboot_comp=$1
@@ -149,6 +149,9 @@ while [ "$#" -gt 0 ]; do
if [ $uboot_comp = "gz" ]; then
uboot_comp=gzip
fi
+ if [ $uboot_comp = "bz2" ]; then
+ uboot_comp=bzip2
+ fi
;;
--no-gzip)
# a "feature" of the the wrapper script is that it can be used outside
@@ -377,6 +380,9 @@ if [ -z "$cacheit" -o ! -f "$vmz$compression" -o "$vmz$compression" -ot "$kernel
.lzma)
xz --format=lzma -f -6 "$vmz.$$"
;;
+ .bz2)
+ bzip2 -f "$vmz.$$"
+ ;;
*)
# drop the compression suffix so the stripped vmlinux is used
compression=
--
2.13.3
^ permalink raw reply related
* [PATCH v2 2/4] powerpc/boot: Add lzma support for uImage
From: Christophe Leroy @ 2019-04-23 14:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <2d3a59015307d368d6ac1a62fe7e47f5b39e2fe2.1556028978.git.christophe.leroy@c-s.fr>
This patch allows to generate lzma compressed uImage
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2: restore alphabetic order in Kconfig
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/boot/Makefile | 2 ++
arch/powerpc/boot/wrapper | 5 ++++-
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2d0be82c3061..dd22988cac0b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -200,6 +200,7 @@ config PPC
select HAVE_IOREMAP_PROT
select HAVE_IRQ_EXIT_ON_IRQ_STACK
select HAVE_KERNEL_GZIP
+ select HAVE_KERNEL_LZMA if DEFAULT_UIMAGE
select HAVE_KERNEL_XZ if PPC_BOOK3S || 44x
select HAVE_KPROBES
select HAVE_KPROBES_ON_FTRACE
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 73d1f3562978..9b7b11a22925 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -22,6 +22,7 @@ all: $(obj)/zImage
compress-$(CONFIG_KERNEL_GZIP) := CONFIG_KERNEL_GZIP
compress-$(CONFIG_KERNEL_XZ) := CONFIG_KERNEL_XZ
+compress-$(CONFIG_KERNEL_LZMA) := CONFIG_KERNEL_LZMA
ifdef CROSS32_COMPILE
BOOTCC := $(CROSS32_COMPILE)gcc
@@ -257,6 +258,7 @@ endif
compressor-$(CONFIG_KERNEL_GZIP) := gz
compressor-$(CONFIG_KERNEL_XZ) := xz
+compressor-$(CONFIG_KERNEL_LZMA) := lzma
# args (to if_changed): 1 = (this rule), 2 = platform, 3 = dts 4=dtb 5=initrd
quiet_cmd_wrap = WRAP $@
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 4e9beecf2502..51dc42f5acbc 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -137,7 +137,7 @@ while [ "$#" -gt 0 ]; do
-Z)
shift
[ "$#" -gt 0 ] || usage
- [ "$1" != "gz" -o "$1" != "xz" -o "$1" != "none" ] || usage
+ [ "$1" != "gz" -o "$1" != "xz" -o "$1" != "lzma" -o "$1" != "none" ] || usage
compression=".$1"
uboot_comp=$1
@@ -374,6 +374,9 @@ if [ -z "$cacheit" -o ! -f "$vmz$compression" -o "$vmz$compression" -ot "$kernel
.gz)
gzip -n -f -9 "$vmz.$$"
;;
+ .lzma)
+ xz --format=lzma -f -6 "$vmz.$$"
+ ;;
*)
# drop the compression suffix so the stripped vmlinux is used
compression=
--
2.13.3
^ permalink raw reply related
* [PATCH v2 1/4] powerpc/boot: don't force gzipped uImage
From: Christophe Leroy @ 2019-04-23 14:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
This patch modifies the generation of uImage by handing over
the selected compression type instead of forcing gzip
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2: no change
---
arch/powerpc/boot/wrapper | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index f9141eaec6ff..4e9beecf2502 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -41,6 +41,7 @@ dts=
cacheit=
binary=
compression=.gz
+uboot_comp=gzip
pie=
format=
@@ -131,6 +132,7 @@ while [ "$#" -gt 0 ]; do
;;
-z)
compression=.gz
+ uboot_comp=gzip
;;
-Z)
shift
@@ -138,15 +140,21 @@ while [ "$#" -gt 0 ]; do
[ "$1" != "gz" -o "$1" != "xz" -o "$1" != "none" ] || usage
compression=".$1"
+ uboot_comp=$1
if [ $compression = ".none" ]; then
compression=
+ uboot_comp=none
fi
+ if [ $uboot_comp = "gz" ]; then
+ uboot_comp=gzip
+ fi
;;
--no-gzip)
# a "feature" of the the wrapper script is that it can be used outside
# the kernel tree. So keeping this around for backwards compatibility.
compression=
+ uboot_comp=none
;;
-?)
usage
@@ -369,6 +377,7 @@ if [ -z "$cacheit" -o ! -f "$vmz$compression" -o "$vmz$compression" -ot "$kernel
*)
# drop the compression suffix so the stripped vmlinux is used
compression=
+ uboot_comp=none
;;
esac
@@ -412,7 +421,7 @@ membase=`${CROSS}objdump -p "$kernel" | grep -m 1 LOAD | awk '{print $7}'`
case "$platform" in
uboot)
rm -f "$ofile"
- ${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a $membase -e $membase \
+ ${MKIMAGE} -A ppc -O linux -T kernel -C $uboot_comp -a $membase -e $membase \
$uboot_version -d "$vmz" "$ofile"
if [ -z "$cacheit" ]; then
rm -f "$vmz"
--
2.13.3
^ permalink raw reply related
* Re: [PATCH v12 00/31] Speculative page faults
From: Michal Hocko @ 2019-04-23 13:42 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jan Kara, sergey.senozhatsky.work, Peter Zijlstra, Will Deacon,
linux-mm, Paul Mackerras, Punit Agrawal, H. Peter Anvin,
Michel Lespinasse, Alexei Starovoitov, Andrea Arcangeli,
Andi Kleen, Minchan Kim, aneesh.kumar, x86, Daniel Jordan,
Ingo Molnar, David Rientjes, Paul E. McKenney, Haiyan Song,
Nick Piggin, sj38.park, Jerome Glisse, dave, kemi.wang,
Kirill A. Shutemov, Thomas Gleixner, Laurent Dufour, zhong jiang,
Ganesh Mahendran, Yang Shi, Mike Rapoport, linuxppc-dev, LKML,
Sergey Senozhatsky, vinayak menon, Andrew Morton, Tim Chen, haren
In-Reply-To: <20190423124148.GA19031@bombadil.infradead.org>
On Tue 23-04-19 05:41:48, Matthew Wilcox wrote:
> On Tue, Apr 23, 2019 at 12:47:07PM +0200, Michal Hocko wrote:
> > On Mon 22-04-19 14:29:16, Michel Lespinasse wrote:
> > [...]
> > > I want to add a note about mmap_sem. In the past there has been
> > > discussions about replacing it with an interval lock, but these never
> > > went anywhere because, mostly, of the fact that such mechanisms were
> > > too expensive to use in the page fault path. I think adding the spf
> > > mechanism would invite us to revisit this issue - interval locks may
> > > be a great way to avoid blocking between unrelated mmap_sem writers
> > > (for example, do not delay stack creation for new threads while a
> > > large mmap or munmap may be going on), and probably also to handle
> > > mmap_sem readers that can't easily use the spf mechanism (for example,
> > > gup callers which make use of the returned vmas). But again that is a
> > > separate topic to explore which doesn't have to get resolved before
> > > spf goes in.
> >
> > Well, I believe we should _really_ re-evaluate the range locking sooner
> > rather than later. Why? Because it looks like the most straightforward
> > approach to the mmap_sem contention for most usecases I have heard of
> > (mostly a mm{unm}ap, mremap standing in the way of page faults).
> > On a plus side it also makes us think about the current mmap (ab)users
> > which should lead to an overall code improvements and maintainability.
>
> Dave Chinner recently did evaluate the range lock for solving a problem
> in XFS and didn't like what he saw:
>
> https://lore.kernel.org/linux-fsdevel/20190418031013.GX29573@dread.disaster.area/T/#md981b32c12a2557a2dd0f79ad41d6c8df1f6f27c
Thank you, will have a look.
> I think scaling the lock needs to be tied to the actual data structure
> and not have a second tree on-the-side to fake-scale the locking. Anyway,
> we're going to have a session on this at LSFMM, right?
I thought we had something for the mmap_sem scaling but I do not see
this in a list of proposed topics. But we can certainly add it there.
> > SPF sounds like a good idea but it is a really big and intrusive surgery
> > to the #PF path. And more importantly without any real world usecase
> > numbers which would justify this. That being said I am not opposed to
> > this change I just think it is a large hammer while we haven't seen
> > attempts to tackle problems in a simpler way.
>
> I don't think the "no real world usecase numbers" is fair. Laurent quoted:
>
> > Ebizzy:
> > -------
> > The test is counting the number of records per second it can manage, the
> > higher is the best. I run it like this 'ebizzy -mTt <nrcpus>'. To get
> > consistent result I repeated the test 100 times and measure the average
> > result. The number is the record processes per second, the higher is the best.
> >
> > BASE SPF delta
> > 24 CPUs x86 5492.69 9383.07 70.83%
> > 1024 CPUS P8 VM 8476.74 17144.38 102%
>
> and cited 30% improvement for you-know-what product from an earlier
> version of the patch.
Well, we are talking about
45 files changed, 1277 insertions(+), 196 deletions(-)
which is a _major_ surgery in my book. Having a real life workloads numbers
is nothing unfair to ask for IMHO.
And let me remind you that I am not really opposing SPF in general. I
would just like to see a simpler approach before we go such a large
change. If the range locking is not really a scalable approach then all
right but from why I've see it should help a lot of most bottle-necks I
have seen.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v12 00/31] Speculative page faults
From: Peter Zijlstra @ 2019-04-23 12:48 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jan Kara, sergey.senozhatsky.work, Will Deacon, Michal Hocko,
linux-mm, Paul Mackerras, Punit Agrawal, H. Peter Anvin,
Michel Lespinasse, Alexei Starovoitov, Andrea Arcangeli,
Andi Kleen, Minchan Kim, aneesh.kumar, x86, Daniel Jordan,
Ingo Molnar, David Rientjes, Paul E. McKenney, Haiyan Song,
Nick Piggin, sj38.park, Jerome Glisse, dave, kemi.wang,
Kirill A. Shutemov, Thomas Gleixner, Laurent Dufour, zhong jiang,
Ganesh Mahendran, Yang Shi, Mike Rapoport, linuxppc-dev, LKML,
Sergey Senozhatsky, vinayak menon, Andrew Morton, Tim Chen, haren
In-Reply-To: <20190423124148.GA19031@bombadil.infradead.org>
On Tue, Apr 23, 2019 at 05:41:48AM -0700, Matthew Wilcox wrote:
> On Tue, Apr 23, 2019 at 12:47:07PM +0200, Michal Hocko wrote:
> > Well, I believe we should _really_ re-evaluate the range locking sooner
> > rather than later. Why? Because it looks like the most straightforward
> > approach to the mmap_sem contention for most usecases I have heard of
> > (mostly a mm{unm}ap, mremap standing in the way of page faults).
> > On a plus side it also makes us think about the current mmap (ab)users
> > which should lead to an overall code improvements and maintainability.
>
> Dave Chinner recently did evaluate the range lock for solving a problem
> in XFS and didn't like what he saw:
>
> https://lore.kernel.org/linux-fsdevel/20190418031013.GX29573@dread.disaster.area/T/#md981b32c12a2557a2dd0f79ad41d6c8df1f6f27c
>
> I think scaling the lock needs to be tied to the actual data structure
> and not have a second tree on-the-side to fake-scale the locking.
Right, which is how I ended up using the split PT locks. They already
provide fine(r) grained locking.
^ permalink raw reply
* Re: [PATCH v12 00/31] Speculative page faults
From: Matthew Wilcox @ 2019-04-23 12:41 UTC (permalink / raw)
To: Michal Hocko
Cc: Jan Kara, sergey.senozhatsky.work, Peter Zijlstra, Will Deacon,
linux-mm, Paul Mackerras, Punit Agrawal, H. Peter Anvin,
Michel Lespinasse, Alexei Starovoitov, Andrea Arcangeli,
Andi Kleen, Minchan Kim, aneesh.kumar, x86, Daniel Jordan,
Ingo Molnar, David Rientjes, Paul E. McKenney, Haiyan Song,
Nick Piggin, sj38.park, Jerome Glisse, dave, kemi.wang,
Kirill A. Shutemov, Thomas Gleixner, Laurent Dufour, zhong jiang,
Ganesh Mahendran, Yang Shi, Mike Rapoport, linuxppc-dev, LKML,
Sergey Senozhatsky, vinayak menon, Andrew Morton, Tim Chen, haren
In-Reply-To: <20190423104707.GK25106@dhcp22.suse.cz>
On Tue, Apr 23, 2019 at 12:47:07PM +0200, Michal Hocko wrote:
> On Mon 22-04-19 14:29:16, Michel Lespinasse wrote:
> [...]
> > I want to add a note about mmap_sem. In the past there has been
> > discussions about replacing it with an interval lock, but these never
> > went anywhere because, mostly, of the fact that such mechanisms were
> > too expensive to use in the page fault path. I think adding the spf
> > mechanism would invite us to revisit this issue - interval locks may
> > be a great way to avoid blocking between unrelated mmap_sem writers
> > (for example, do not delay stack creation for new threads while a
> > large mmap or munmap may be going on), and probably also to handle
> > mmap_sem readers that can't easily use the spf mechanism (for example,
> > gup callers which make use of the returned vmas). But again that is a
> > separate topic to explore which doesn't have to get resolved before
> > spf goes in.
>
> Well, I believe we should _really_ re-evaluate the range locking sooner
> rather than later. Why? Because it looks like the most straightforward
> approach to the mmap_sem contention for most usecases I have heard of
> (mostly a mm{unm}ap, mremap standing in the way of page faults).
> On a plus side it also makes us think about the current mmap (ab)users
> which should lead to an overall code improvements and maintainability.
Dave Chinner recently did evaluate the range lock for solving a problem
in XFS and didn't like what he saw:
https://lore.kernel.org/linux-fsdevel/20190418031013.GX29573@dread.disaster.area/T/#md981b32c12a2557a2dd0f79ad41d6c8df1f6f27c
I think scaling the lock needs to be tied to the actual data structure
and not have a second tree on-the-side to fake-scale the locking. Anyway,
we're going to have a session on this at LSFMM, right?
> SPF sounds like a good idea but it is a really big and intrusive surgery
> to the #PF path. And more importantly without any real world usecase
> numbers which would justify this. That being said I am not opposed to
> this change I just think it is a large hammer while we haven't seen
> attempts to tackle problems in a simpler way.
I don't think the "no real world usecase numbers" is fair. Laurent quoted:
> Ebizzy:
> -------
> The test is counting the number of records per second it can manage, the
> higher is the best. I run it like this 'ebizzy -mTt <nrcpus>'. To get
> consistent result I repeated the test 100 times and measure the average
> result. The number is the record processes per second, the higher is the best.
>
> BASE SPF delta
> 24 CPUs x86 5492.69 9383.07 70.83%
> 1024 CPUS P8 VM 8476.74 17144.38 102%
and cited 30% improvement for you-know-what product from an earlier
version of the patch.
^ permalink raw reply
* Re: [powerpc:next-test 40/58] WARNING: vmlinux.o(.text+0xb038): Section mismatch in reference from the function setup_kup() to the function .init.text:setup_kuep()
From: Christophe Leroy @ 2019-04-23 12:13 UTC (permalink / raw)
To: Michael Ellerman, Russell Currey
Cc: linuxppc-dev, kbuild test robot, kbuild-all
In-Reply-To: <201904220037.le30gXgO%lkp@intel.com>
Russel, Michael,
Looks like the reported problem comes from b28c97505eb1 ("powerpc/64:
Setup KUP on secondary CPUs")
(https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=next&id=b28c97505eb1a5265e367c398c3406be6ce5e313)
Is it really necessary to remove the __init tag on setup_kup() ?
Christophe
Le 21/04/2019 à 18:23, kbuild test robot a écrit :
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
> head: 26ad26718dfaa7cf49d106d212ebf2370076c253
> commit: 06fbe81b5909847aa13f9c86c2b6f9bbc5c2795b [40/58] powerpc/8xx: Add Kernel Userspace Execution Prevention
> config: powerpc-mpc885_ads_defconfig (attached as .config)
> compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 06fbe81b5909847aa13f9c86c2b6f9bbc5c2795b
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=powerpc
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
>
> All warnings (new ones prefixed by >>):
>
>>> WARNING: vmlinux.o(.text+0xb038): Section mismatch in reference from the function setup_kup() to the function .init.text:setup_kuep()
> The function setup_kup() references
> the function __init setup_kuep().
> This is often because setup_kup lacks a __init
> annotation or the annotation of setup_kuep is wrong.
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
^ permalink raw reply
* Re: [PATCH v12 00/31] Speculative page faults
From: Anshuman Khandual @ 2019-04-23 11:35 UTC (permalink / raw)
To: Laurent Dufour, akpm, mhocko, peterz, kirill, ak, dave, jack,
Matthew Wilcox, aneesh.kumar, benh, mpe, paulus, Thomas Gleixner,
Ingo Molnar, hpa, Will Deacon, Sergey Senozhatsky,
sergey.senozhatsky.work, Andrea Arcangeli, Alexei Starovoitov,
kemi.wang, Daniel Jordan, David Rientjes, Jerome Glisse,
Ganesh Mahendran, Minchan Kim, Punit Agrawal, vinayak menon,
Yang Shi, zhong jiang, Haiyan Song, Balbir Singh, sj38.park,
Michel Lespinasse, Mike Rapoport
Cc: linuxppc-dev, x86, linux-kernel, npiggin, linux-mm, paulmck,
Tim Chen, haren
In-Reply-To: <20190416134522.17540-1-ldufour@linux.ibm.com>
On 04/16/2019 07:14 PM, Laurent Dufour wrote:
> In pseudo code, this could be seen as:
> speculative_page_fault()
> {
> vma = find_vma_rcu()
> check vma sequence count
> check vma's support
> disable interrupt
> check pgd,p4d,...,pte
> save pmd and pte in vmf
> save vma sequence counter in vmf
> enable interrupt
> check vma sequence count
> handle_pte_fault(vma)
> ..
> page = alloc_page()
> pte_map_lock()
> disable interrupt
> abort if sequence counter has changed
> abort if pmd or pte has changed
> pte map and lock
> enable interrupt
> if abort
> free page
> abort
Would not it be better if the 'page' allocated here can be passed on to handle_pte_fault()
below so that in the fallback path it does not have to enter the buddy again ? Of course
it will require changes to handle_pte_fault() to accommodate a pre-allocated non-NULL
struct page to operate on or free back into the buddy if fallback path fails for some
other reason. This will probably make SPF path less overhead for cases where it has to
fallback on handle_pte_fault() after pte_map_lock() in speculative_page_fault().
> ...
> put_vma(vma)
> }
>
> arch_fault_handler()
> {
> if (speculative_page_fault(&vma))
> goto done
> again:
> lock(mmap_sem)
> vma = find_vma();
> handle_pte_fault(vma);
> if retry
> unlock(mmap_sem)
> goto again;
> done:
> handle fault error
> }
- Anshuman
^ permalink raw reply
* Re: [RESEND PATCH v3 02/11] arm64: mark (__)cpus_have_const_cap as __always_inline
From: Mark Rutland @ 2019-04-23 11:31 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-arch, linux-s390, Arnd Bergmann, Mathieu Malaterre,
will.deacon, x86, Heiko Carstens, linux-mips, linux-kernel,
marc.zyngier, Ingo Molnar, linux-mtd, catalin.marinas,
Andrew Morton, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190423034959.13525-3-yamada.masahiro@socionext.com>
[adding relevant arm64 folk to Cc]
On Tue, Apr 23, 2019 at 12:49:50PM +0900, Masahiro Yamada wrote:
> This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
> place. We need to eliminate potential issues beforehand.
>
> If it is enabled for arm64, the following errors are reported:
>
> In file included from ././include/linux/compiler_types.h:68,
> from <command-line>:
> ./arch/arm64/include/asm/jump_label.h: In function 'cpus_have_const_cap':
> ./include/linux/compiler-gcc.h:120:38: warning: asm operand 0 probably doesn't match constraints
> #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
> ^~~
> ./arch/arm64/include/asm/jump_label.h:32:2: note: in expansion of macro 'asm_volatile_goto'
> asm_volatile_goto(
> ^~~~~~~~~~~~~~~~~
> ./include/linux/compiler-gcc.h:120:38: error: impossible constraint in 'asm'
> #define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
> ^~~
> ./arch/arm64/include/asm/jump_label.h:32:2: note: in expansion of macro 'asm_volatile_goto'
> asm_volatile_goto(
> ^~~~~~~~~~~~~~~~~
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This looks sound to me, and from a quick scan of v5.1-rc6 with:
$ git grep -wW inline -- arch/arm64
... I didn't spot any other sites which obviously needed to be made
__always_inline.
I've built and booted this atop of defconfig and my usual suite of debug
options for fuzzing, at EL1 under QEMU/KVM, and at EL2 under QEMU/TCG,
with no issues in either case, so FWIW:
Tested-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
> ---
>
> Changes in v3: None
> Changes in v2:
> - split into a separate patch
>
> arch/arm64/include/asm/cpufeature.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index e505e1fbd2b9..77d1aa57323e 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -406,7 +406,7 @@ static inline bool cpu_have_feature(unsigned int num)
> }
>
> /* System capability check for constant caps */
> -static inline bool __cpus_have_const_cap(int num)
> +static __always_inline bool __cpus_have_const_cap(int num)
> {
> if (num >= ARM64_NCAPS)
> return false;
> @@ -420,7 +420,7 @@ static inline bool cpus_have_cap(unsigned int num)
> return test_bit(num, cpu_hwcaps);
> }
>
> -static inline bool cpus_have_const_cap(int num)
> +static __always_inline bool cpus_have_const_cap(int num)
> {
> if (static_branch_likely(&arm64_const_caps_ready))
> return __cpus_have_const_cap(num);
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v12 00/31] Speculative page faults
From: Michal Hocko @ 2019-04-23 10:47 UTC (permalink / raw)
To: Michel Lespinasse
Cc: Jan Kara, sergey.senozhatsky.work, Peter Zijlstra, Will Deacon,
linux-mm, Paul Mackerras, Punit Agrawal, H. Peter Anvin,
Mike Rapoport, Alexei Starovoitov, Andrea Arcangeli, dave,
Minchan Kim, aneesh.kumar, x86, Matthew Wilcox, Daniel Jordan,
Ingo Molnar, David Rientjes, Paul E. McKenney, Haiyan Song,
Nick Piggin, sj38.park, Jerome Glisse, Andi Kleen, kemi.wang,
Kirill A. Shutemov, Thomas Gleixner, Laurent Dufour, zhong jiang,
Ganesh Mahendran, Yang Shi, linuxppc-dev, LKML,
Sergey Senozhatsky, vinayak menon, Andrew Morton, Tim Chen, haren
In-Reply-To: <CANN689F1h9XoHPzr_FQY2WfN5bb2TTd6M3HLqoJ-DQuHkNbA7g@mail.gmail.com>
On Mon 22-04-19 14:29:16, Michel Lespinasse wrote:
[...]
> I want to add a note about mmap_sem. In the past there has been
> discussions about replacing it with an interval lock, but these never
> went anywhere because, mostly, of the fact that such mechanisms were
> too expensive to use in the page fault path. I think adding the spf
> mechanism would invite us to revisit this issue - interval locks may
> be a great way to avoid blocking between unrelated mmap_sem writers
> (for example, do not delay stack creation for new threads while a
> large mmap or munmap may be going on), and probably also to handle
> mmap_sem readers that can't easily use the spf mechanism (for example,
> gup callers which make use of the returned vmas). But again that is a
> separate topic to explore which doesn't have to get resolved before
> spf goes in.
Well, I believe we should _really_ re-evaluate the range locking sooner
rather than later. Why? Because it looks like the most straightforward
approach to the mmap_sem contention for most usecases I have heard of
(mostly a mm{unm}ap, mremap standing in the way of page faults).
On a plus side it also makes us think about the current mmap (ab)users
which should lead to an overall code improvements and maintainability.
SPF sounds like a good idea but it is a really big and intrusive surgery
to the #PF path. And more importantly without any real world usecase
numbers which would justify this. That being said I am not opposed to
this change I just think it is a large hammer while we haven't seen
attempts to tackle problems in a simpler way.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH RFT V3 1/8] clk: divider: add explicit big endian support
From: Jonas Gorski @ 2019-04-23 10:39 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Prashant Gaikwad, Heiko Stuebner, Michael Turquette,
Thierry Reding, Paul Mackerras, Fabio Estevam, linux-clk,
Michal Simek, Jonathan Hunter, open list:ARM/Rockchip SoC...,
NXP Linux Team, Anatolij Gustschin, Sascha Hauer, linux-tegra,
Linux ARM, Stephen Boyd, linuxppc-dev, Peter De Schrijver,
Pengutronix Kernel Team, Shawn Guo
In-Reply-To: <CAMuHMdX7E8fR+2s-gPgGLKUCdW_--YUDW7w+op3BDurgACFEmA@mail.gmail.com>
Hi Geert,
On Tue, 23 Apr 2019 at 09:49, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Jonas,
>
> On Thu, Apr 18, 2019 at 1:12 PM Jonas Gorski <jonas.gorski@gmail.com> wrote:
> > Add a clock specific flag to switch register accesses to big endian, to
> > allow runtime configuration of big endian divider clocks.
> >
> > Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
> > ---
> > V2 -> V3:
> > * fix passed arguments to clk_div_readl found by kbuild
> > * drop unneeded else in clk_div_readl
> > V1 -> V2:
> > * switch from global to local flag
> >
> > drivers/clk/clk-divider.c | 26 ++++++++++++++++++++++----
> > include/linux/clk-provider.h | 4 ++++
> > 2 files changed, 26 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> > index e5a17265cfaf..25c7404e376c 100644
> > --- a/drivers/clk/clk-divider.c
> > +++ b/drivers/clk/clk-divider.c
> > @@ -25,6 +25,24 @@
> > * parent - fixed parent. No clk_set_parent support
> > */
> >
> > +static inline u32 clk_div_readl(struct clk_divider *divider)
> > +{
> > + if (divider->flags & CLK_DIVIDER_BIG_ENDIAN)
> > + return ioread32be(divider->reg);
> > +
> > + return clk_readl(divider->reg);
> > +}
> > +
> > +static inline void clk_div_writel(struct clk_divider *divider, u32 val)
> > +{
> > + if (divider->flags & CLK_DIVIDER_BIG_ENDIAN)
> > + iowrite32be(val, divider->reg);
> > + else
> > + clk_writel(val, divider->reg);
> > +}
> > +
> > +#define div_mask(width) ((1 << (width)) - 1)
>
> What's the purpose of adding this definition?
> It does not seem to be used.
No purpose at all, it's an uncaught artifact from rebasing ._.
Stephen, which one is your preferred way of fixing that?
a) a new V4 patchset without this line
b) a follow up patch that removes it
c) just removing the line yourself
Regards
Jonas
^ permalink raw reply
* Re: [PATCH v12 00/31] Speculative page faults
From: Peter Zijlstra @ 2019-04-23 9:38 UTC (permalink / raw)
To: Michel Lespinasse
Cc: Jan Kara, sergey.senozhatsky.work, Will Deacon, Michal Hocko,
linux-mm, Paul Mackerras, Punit Agrawal, H. Peter Anvin,
Mike Rapoport, Alexei Starovoitov, Andrea Arcangeli, Andi Kleen,
Minchan Kim, aneesh.kumar, x86, Matthew Wilcox, Daniel Jordan,
Ingo Molnar, David Rientjes, Paul E. McKenney, Haiyan Song,
Nick Piggin, sj38.park, Jerome Glisse, dave, kemi.wang,
Kirill A. Shutemov, Thomas Gleixner, Laurent Dufour, zhong jiang,
Ganesh Mahendran, Yang Shi, linuxppc-dev, LKML,
Sergey Senozhatsky, vinayak menon, Andrew Morton, Tim Chen, haren
In-Reply-To: <CANN689F1h9XoHPzr_FQY2WfN5bb2TTd6M3HLqoJ-DQuHkNbA7g@mail.gmail.com>
On Mon, Apr 22, 2019 at 02:29:16PM -0700, Michel Lespinasse wrote:
> The proposed spf mechanism only handles anon vmas. Is there a
> fundamental reason why it couldn't handle mapped files too ?
> My understanding is that the mechanism of verifying the vma after
> taking back the ptl at the end of the fault would work there too ?
> The file has to stay referenced during the fault, but holding the vma's
> refcount could be made to cover that ? the vm_file refcount would have
> to be released in __free_vma() instead of remove_vma; I'm not quite sure
> if that has more implications than I realize ?
IIRC (and I really don't remember all that much) the trickiest bit was
vs unmount. Since files can stay open past the 'expected' duration,
umount could be delayed.
But yes, I think I had a version that did all that just 'fine'. Like
mentioned, I didn't keep the refcount because it sucked just as hard as
the mmap_sem contention, but the SRCU callback did the fput() just fine
(esp. now that we have delayed_fput).
^ permalink raw reply
* Re: [PATCH v12 21/31] mm: Introduce find_vma_rcu()
From: Peter Zijlstra @ 2019-04-23 9:27 UTC (permalink / raw)
To: Laurent Dufour
Cc: jack, sergey.senozhatsky.work, Will Deacon, mhocko, linux-mm,
paulus, Punit Agrawal, hpa, Michel Lespinasse, Alexei Starovoitov,
Andrea Arcangeli, ak, Minchan Kim, aneesh.kumar, x86,
Matthew Wilcox, Daniel Jordan, Ingo Molnar, David Rientjes,
paulmck, Haiyan Song, npiggin, sj38.park, Jerome Glisse, dave,
kemi.wang, kirill, Thomas Gleixner, zhong jiang, Ganesh Mahendran,
Yang Shi, Mike Rapoport, linuxppc-dev, linux-kernel,
Sergey Senozhatsky, vinayak menon, akpm, Tim Chen, haren
In-Reply-To: <20190416134522.17540-22-ldufour@linux.ibm.com>
On Tue, Apr 16, 2019 at 03:45:12PM +0200, Laurent Dufour wrote:
> This allows to search for a VMA structure without holding the mmap_sem.
>
> The search is repeated while the mm seqlock is changing and until we found
> a valid VMA.
>
> While under the RCU protection, a reference is taken on the VMA, so the
> caller must call put_vma() once it not more need the VMA structure.
>
> At the time a VMA is inserted in the MM RB tree, in vma_rb_insert(), a
> reference is taken to the VMA by calling get_vma().
>
> When removing a VMA from the MM RB tree, the VMA is not release immediately
> but at the end of the RCU grace period through vm_rcu_put(). This ensures
> that the VMA remains allocated until the end the RCU grace period.
>
> Since the vm_file pointer, if valid, is released in put_vma(), there is no
> guarantee that the file pointer will be valid on the returned VMA.
What I'm missing here, and in the previous patch introducing the
refcount (also see refcount_t), is _why_ we need the refcount thing at
all.
My original plan was to use SRCU, which at the time was not complete
enough so I abused/hacked preemptible RCU, but that is no longer the
case, SRCU has all the required bits and pieces.
Also; the initial motivation was prefaulting large VMAs and the
contention on mmap was killing things; but similarly, the contention on
the refcount (I did try that) killed things just the same.
So I'm really sad to see the refcount return; and without any apparent
justification.
^ permalink raw reply
* Re: [PATCH v2 10/10] powerpc/32s: Implement Kernel Userspace Access Protection
From: Christophe Leroy @ 2019-04-23 9:26 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras, ruscur
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <87ftqfu7j1.fsf@concordia.ellerman.id.au>
Le 18/04/2019 à 08:55, Michael Ellerman a écrit :
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>> diff --git a/arch/powerpc/include/asm/book3s/32/kup.h b/arch/powerpc/include/asm/book3s/32/kup.h
>> index 5f97c742ca71..b3560b2de435 100644
>> --- a/arch/powerpc/include/asm/book3s/32/kup.h
>> +++ b/arch/powerpc/include/asm/book3s/32/kup.h
>> @@ -37,6 +37,113 @@
> ...
>> +
>> +static inline void allow_user_access(void __user *to, const void __user *from, u32 size)
>> +{
>> + u32 addr = (__force u32)to;
>> + u32 end = min(addr + size, TASK_SIZE);
>> +
>> + if (!addr || addr >= TASK_SIZE || !size)
>> + return;
>> +
>> + current->thread.kuap = (addr & 0xf0000000) | ((((end - 1) >> 28) + 1) & 0xf);
>> + kuap_update_sr(mfsrin(addr) & ~SR_KS, addr, end); /* Clear Ks */
>> +}
>
> When rebasing on my v6 I changed the above to:
>
> static inline void allow_user_access(void __user *to, const void __user *from, u32 size)
> {
> u32 addr, end;
>
> if (__builtin_constant_p(to) && to == NULL)
> return;
Good point, it avoids keeping the test compiled in when the 'to' is not
NULL.
>
> addr = (__force u32)to;
>
> if (!addr || addr >= TASK_SIZE || !size)
> return;
Then the !addr test isn't needed anymore I think.
Christophe
>
> end = min(addr + size, TASK_SIZE);
> current->thread.kuap = (addr & 0xf0000000) | ((((end - 1) >> 28) + 1) & 0xf);
> kuap_update_sr(mfsrin(addr) & ~SR_KS, addr, end); /* Clear Ks */
> }
>
> Which I think achieves the same result. It does boot :)
>
>> +
>> +static inline void prevent_user_access(void __user *to, const void __user *from, u32 size)
>> +{
>> + u32 addr = (__force u32)to;
>> + u32 end = min(addr + size, TASK_SIZE);
>> +
>> + if (!addr || addr >= TASK_SIZE || !size)
>> + return;
>> +
>> + current->thread.kuap = 0;
>> + kuap_update_sr(mfsrin(addr) | SR_KS, addr, end); /* set Ks */
>> +}
>> +
>> +static inline void allow_read_from_user(const void __user *from, unsigned long size)
>> +{
>> +}
>
> And I dropped that.
>
> cheers
>
^ permalink raw reply
* linux-next: manual merge of the akpm-current tree with the powerpc-fixes and powerpc trees
From: Stephen Rothwell @ 2019-04-23 9:13 UTC (permalink / raw)
To: Andrew Morton, Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Alexandre Ghiti
[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/platforms/Kconfig.cputype
between commit:
8adddf349fda ("powerpc/mm/radix: Make Radix require HUGETLB_PAGE")
from the powerpc-fixes tree and commits:
1bb2bae2e6c7 ("powerpc/mm/radix: Use KUEP API for Radix MMU")
890274c2dc4c ("powerpc/64s: Implement KUAP for Radix MMU")
from the powerpc tree and commits:
80d5ae3cf456 ("mm: simplify MEMORY_ISOLATION && COMPACTION || CMA into CONTIG_ALLOC")
3653abf7cded ("hugetlb: allow to free gigantic pages regardless of the configuration")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/platforms/Kconfig.cputype
index 00b2bb536c74,03ca91439473..000000000000
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@@ -328,10 -324,8 +328,10 @@@ config ARCH_ENABLE_SPLIT_PMD_PTLOC
config PPC_RADIX_MMU
bool "Radix MMU Support"
- depends on PPC_BOOK3S_64
+ depends on PPC_BOOK3S_64 && HUGETLB_PAGE
- select ARCH_HAS_GIGANTIC_PAGE if (MEMORY_ISOLATION && COMPACTION) || CMA
+ select ARCH_HAS_GIGANTIC_PAGE
+ select PPC_HAVE_KUEP
+ select PPC_HAVE_KUAP
default y
help
Enable support for the Power ISA 3.0 Radix style MMU. Currently this
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the akpm-current tree with the powerpc-fixes tree
From: Stephen Rothwell @ 2019-04-23 9:06 UTC (permalink / raw)
To: Andrew Morton, Michael Ellerman, PowerPC
Cc: Alexey Kardashevskiy, Linux Next Mailing List, Ira Weiny,
Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/mm/mmu_context_iommu.c
between commits:
eb9d7a62c386 ("powerpc/mm_iommu: Fix potential deadlock")
7a3a4d763837 ("powerpc/mm_iommu: Allow pinning large regions")
from the powerpc-fixes tree and commit:
02f506bad7af ("mm/gup: replace get_user_pages_longterm() with FOLL_LONGTERM")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/mm/mmu_context_iommu.c
index 8330f135294f,755fe7adc0d8..000000000000
--- a/arch/powerpc/mm/mmu_context_iommu.c
+++ b/arch/powerpc/mm/mmu_context_iommu.c
@@@ -135,27 -144,18 +131,28 @@@ static long mm_iommu_do_alloc(struct mm
}
down_read(&mm->mmap_sem);
- ret = get_user_pages(ua, entries, FOLL_WRITE | FOLL_LONGTERM,
- mem->hpages, NULL);
+ chunk = (1UL << (PAGE_SHIFT + MAX_ORDER - 1)) /
+ sizeof(struct vm_area_struct *);
+ chunk = min(chunk, entries);
+ for (entry = 0; entry < entries; entry += chunk) {
+ unsigned long n = min(entries - entry, chunk);
+
- ret = get_user_pages_longterm(ua + (entry << PAGE_SHIFT), n,
- FOLL_WRITE, mem->hpages + entry, NULL);
++ ret = get_user_pages(ua + (entry << PAGE_SHIFT), n,
++ FOLL_WRITE | FOLL_LONGTERM,
++ mem->hpages + entry, NULL);
+ if (ret == n) {
+ pinned += n;
+ continue;
+ }
+ if (ret > 0)
+ pinned += ret;
+ break;
+ }
up_read(&mm->mmap_sem);
- if (ret != entries) {
- /* free the reference taken */
- for (i = 0; i < ret; i++)
- put_page(mem->hpages[i]);
-
- vfree(mem->hpas);
- kfree(mem);
- ret = -EFAULT;
- goto unlock_exit;
+ if (pinned != entries) {
+ if (!ret)
+ ret = -EFAULT;
+ goto free_exit;
}
pageshift = PAGE_SHIFT;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the akpm-current tree with the powerpc tree
From: Stephen Rothwell @ 2019-04-23 8:57 UTC (permalink / raw)
To: Andrew Morton, Michael Ellerman, PowerPC
Cc: Laurent Vivier, Michal Hocko, David Hildenbrand, Aneesh Kumar K.V,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2413 bytes --]
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/powerpc/mm/mem.c
between commit:
f172acbfae1a ("powerpc/mm: move warning from resize_hpt_for_hotplug()")
26ad26718dfa ("powerpc/mm: Fix section mismatch warning")
from the powerpc tree and commit:
fc6a586376ab ("mm, memory_hotplug: provide a more generic restrictions for memory hotplug")
e8b6bc564e97 ("mm/memory_hotplug: make __remove_pages() and arch_remove_memory() never fail")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/powerpc/mm/mem.c
index e12bec98366f,cc9425fb9056..000000000000
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@@ -109,8 -109,8 +109,8 @@@ int __weak remove_section_mapping(unsig
return -ENODEV;
}
- int __ref arch_add_memory(int nid, u64 start, u64 size, struct vmem_altmap *altmap,
- bool want_memblock)
-int __meminit arch_add_memory(int nid, u64 start, u64 size,
- struct mhp_restrictions *restrictions)
++int __ref arch_add_memory(int nid, u64 start, u64 size,
++ struct mhp_restrictions *restrictions)
{
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
@@@ -131,8 -131,8 +131,8 @@@
}
#ifdef CONFIG_MEMORY_HOTREMOVE
- int __ref arch_remove_memory(int nid, u64 start, u64 size,
- struct vmem_altmap *altmap)
-void __meminit arch_remove_memory(int nid, u64 start, u64 size,
- struct vmem_altmap *altmap)
++void __ref arch_remove_memory(int nid, u64 start, u64 size,
++ struct vmem_altmap *altmap)
{
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
@@@ -161,10 -160,7 +160,8 @@@
*/
vm_unmap_aliases();
- resize_hpt_for_hotplug(memblock_phys_mem_size());
+ if (resize_hpt_for_hotplug(memblock_phys_mem_size()) == -ENOSPC)
+ pr_warn("Hash collision while resizing HPT\n");
-
- return ret;
}
#endif
#endif /* CONFIG_MEMORY_HOTPLUG */
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* powerpc hugepage leak caused by 576ed913 "block: use bio_add_page in bio_iov_iter_get_pages"
From: David Gibson @ 2019-04-23 5:41 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, linux-kernel, Nick Piggin, Michael Ellerman,
Paul Mackerras, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2195 bytes --]
576ed913 "block: use bio_add_page in bio_iov_iter_get_pages", applied
late in the 4.19 cycle appears to introduce a regression causing a
huge page leak in a complicated set of circumstances I haven't fully
identified yet.
On a POWER8 machine with a kernel after the commit above, when I run a
KVM guest with RAM in hugetlbfs pages (and certain options, see below), a
handful of the hugepages used for RAM are not released after qemu and
the guest quit. Usually 2 or 3 16MiB pages are leaked, though I've
seen anything from 0-8 occasionally.
There are a bunch of conditions on when it occurs, only some of which
I've pinned down:
* It happens on a POWER8 8247-22L, but not a very similar 8247-21L,
and I haven't been able to work out why, yet.
* It only happens with certain combination of qemu block and caching
options for the guest's root fs. Specifically it appears to happen
when the file used for the guest's root disk image is opened with
O_DIRECT.
* It depends somewhat on guest activity.
- It doesn't occur if the guest is only booted to firmware
- Booting only to initramfs without mounting the "real" root fs
doesn't seem to trigger the problem
- It appears to happen reliably with RHEL6 and RHEL7 guests, but
only sometimes with RHEL8 guests, again, I don't know why at
this stage
I pinned it down to this (host kernel) patch by bisection, and I've
double checked afterwards to confirm it really is this commit, not a
mistake during the bisection.
I've tried a bunch of instrumentation, but it hasn't been very
illuminating so far:
* The leaked pages have non-zero count and are left in the
hugepage_activelist
* The leaked pages *don't* appear to be blocking release of the KVM
VM or the qemu process owning it
* The leaked pages *do* appear to be blocking release of the
associated address_space and (anonymous) inode, though I'm not 100%
certain about this.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH RFT V3 1/8] clk: divider: add explicit big endian support
From: Geert Uytterhoeven @ 2019-04-23 7:49 UTC (permalink / raw)
To: Jonas Gorski
Cc: Prashant Gaikwad, Heiko Stuebner, Michael Turquette,
Thierry Reding, Paul Mackerras, Fabio Estevam, linux-clk,
Michal Simek, Jonathan Hunter, open list:ARM/Rockchip SoC...,
NXP Linux Team, Anatolij Gustschin, Sascha Hauer, linux-tegra,
Linux ARM, Stephen Boyd, linuxppc-dev, Peter De Schrijver,
Pengutronix Kernel Team, Shawn Guo
In-Reply-To: <20190418111211.10474-2-jonas.gorski@gmail.com>
Hi Jonas,
On Thu, Apr 18, 2019 at 1:12 PM Jonas Gorski <jonas.gorski@gmail.com> wrote:
> Add a clock specific flag to switch register accesses to big endian, to
> allow runtime configuration of big endian divider clocks.
>
> Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
> ---
> V2 -> V3:
> * fix passed arguments to clk_div_readl found by kbuild
> * drop unneeded else in clk_div_readl
> V1 -> V2:
> * switch from global to local flag
>
> drivers/clk/clk-divider.c | 26 ++++++++++++++++++++++----
> include/linux/clk-provider.h | 4 ++++
> 2 files changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
> index e5a17265cfaf..25c7404e376c 100644
> --- a/drivers/clk/clk-divider.c
> +++ b/drivers/clk/clk-divider.c
> @@ -25,6 +25,24 @@
> * parent - fixed parent. No clk_set_parent support
> */
>
> +static inline u32 clk_div_readl(struct clk_divider *divider)
> +{
> + if (divider->flags & CLK_DIVIDER_BIG_ENDIAN)
> + return ioread32be(divider->reg);
> +
> + return clk_readl(divider->reg);
> +}
> +
> +static inline void clk_div_writel(struct clk_divider *divider, u32 val)
> +{
> + if (divider->flags & CLK_DIVIDER_BIG_ENDIAN)
> + iowrite32be(val, divider->reg);
> + else
> + clk_writel(val, divider->reg);
> +}
> +
> +#define div_mask(width) ((1 << (width)) - 1)
What's the purpose of adding this definition?
It does not seem to be used.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 0/3] Add runtime PM for SAI digital audio interface
From: Viorel Suman @ 2019-04-23 7:20 UTC (permalink / raw)
To: Daniel Baluta, broonie@kernel.org
Cc: alsa-devel@alsa-project.org, lgirdwood@gmail.com,
timur@kernel.org, Xiubo.Lee@gmail.com,
linuxppc-dev@lists.ozlabs.org, S.j. Wang,
linux-kernel@vger.kernel.org, tiwai@suse.com, dl-linux-imx,
perex@perex.cz, festevam@gmail.com
In-Reply-To: <20190422190213.30726-1-daniel.baluta@nxp.com>
For this series:
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
On Lu, 2019-04-22 at 19:02 +0000, Daniel Baluta wrote:
> First patch fixes a bug by correctly setting is_slave_mode, then
> second patch adds support for runtime PM and finally 3rd patch moves
> clock handling from startup/shtudown function to runtime PM handlers.
>
> Changes since v2: (after Viorel's comments)
> - no need to check for is_slave_mode when enabling/disabling the clocks
> because sai->mclk_streams is only set when SAI is in master mode.
>
> Changes since v1: (after Nicolin's comments)
> - added patch 1
> - added fsl_sai_remove in order to call pm_runtime_disable
> - only disable/enable mclk when SAI in master mode.
>
> Daniel Baluta (2):
> ASoC: fsl_sai: Update is_slave_mode with correct value
> ASoC: fsl_sai: Add support for runtime pm
>
> Shengjiu Wang (1):
> ASoC: fsl_sai: Move clock operation to PM runtime
>
> sound/soc/fsl/fsl_sai.c | 78 +++++++++++++++++++++++++++++++++--------
> 1 file changed, 63 insertions(+), 15 deletions(-)
>
> --
> 2.17.1
>
^ permalink raw reply
* [RESEND PATCH v3 11/11] compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING
From: Masahiro Yamada @ 2019-04-23 3:49 UTC (permalink / raw)
To: Andrew Morton, linux-arch
Cc: linux-s390, Arnd Bergmann, Mathieu Malaterre, x86, Heiko Carstens,
linux-mips, linux-kernel, Masahiro Yamada, Ingo Molnar, linux-mtd,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190423034959.13525-1-yamada.masahiro@socionext.com>
Commit 60a3cdd06394 ("x86: add optimized inlining") introduced
CONFIG_OPTIMIZE_INLINING, but it has been available only for x86.
The idea is obviously arch-agnostic. This commit moves the config
entry from arch/x86/Kconfig.debug to lib/Kconfig.debug so that all
architectures can benefit from it.
This can make a huge difference in kernel image size especially when
CONFIG_OPTIMIZE_FOR_SIZE is enabled.
For example, I got 3.5% smaller arm64 kernel for v5.1-rc1.
dec file
18983424 arch/arm64/boot/Image.before
18321920 arch/arm64/boot/Image.after
This also slightly improves the "Kernel hacking" Kconfig menu as
e61aca5158a8 ("Merge branch 'kconfig-diet' from Dave Hansen') suggested;
this config option would be a good fit in the "compiler option" menu.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Borislav Petkov <bp@suse.de>
---
Changes in v3: None
Changes in v2:
- split into a separate patch
arch/x86/Kconfig | 3 ---
arch/x86/Kconfig.debug | 14 --------------
include/linux/compiler_types.h | 3 +--
lib/Kconfig.debug | 14 ++++++++++++++
4 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 62fc3fda1a05..f214bb5d60d8 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -310,9 +310,6 @@ config ZONE_DMA32
config AUDIT_ARCH
def_bool y if X86_64
-config ARCH_SUPPORTS_OPTIMIZED_INLINING
- def_bool y
-
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
def_bool y
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 15d0fbe27872..f730680dc818 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -266,20 +266,6 @@ config CPA_DEBUG
---help---
Do change_page_attr() self-tests every 30 seconds.
-config OPTIMIZE_INLINING
- bool "Allow gcc to uninline functions marked 'inline'"
- ---help---
- This option determines if the kernel forces gcc to inline the functions
- developers have marked 'inline'. Doing so takes away freedom from gcc to
- do what it thinks is best, which is desirable for the gcc 3.x series of
- compilers. The gcc 4.x series have a rewritten inlining algorithm and
- enabling this option will generate a smaller kernel there. Hopefully
- this algorithm is so good that allowing gcc 4.x and above to make the
- decision will become the default in the future. Until then this option
- is there to test gcc for this.
-
- If unsure, say N.
-
config DEBUG_ENTRY
bool "Debug low-level entry code"
depends on DEBUG_KERNEL
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index ba814f18cb4c..19e58b9138a0 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -140,8 +140,7 @@ struct ftrace_likely_data {
* Do not use __always_inline here, since currently it expands to inline again
* (which would break users of __always_inline).
*/
-#if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
- !defined(CONFIG_OPTIMIZE_INLINING)
+#if !defined(CONFIG_OPTIMIZE_INLINING)
#define inline inline __attribute__((__always_inline__)) __gnu_inline \
__maybe_unused notrace
#else
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 00dbcdbc9a0d..37402f210115 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -310,6 +310,20 @@ config HEADERS_CHECK
exported to $(INSTALL_HDR_PATH) (usually 'usr/include' in
your build tree), to make sure they're suitable.
+config OPTIMIZE_INLINING
+ bool "Allow compiler to uninline functions marked 'inline'"
+ help
+ This option determines if the kernel forces gcc to inline the functions
+ developers have marked 'inline'. Doing so takes away freedom from gcc to
+ do what it thinks is best, which is desirable for the gcc 3.x series of
+ compilers. The gcc 4.x series have a rewritten inlining algorithm and
+ enabling this option will generate a smaller kernel there. Hopefully
+ this algorithm is so good that allowing gcc 4.x and above to make the
+ decision will become the default in the future. Until then this option
+ is there to test gcc for this.
+
+ If unsure, say N.
+
config DEBUG_SECTION_MISMATCH
bool "Enable full Section mismatch analysis"
help
--
2.17.1
^ permalink raw reply related
* [RESEND PATCH v3 05/11] mtd: rawnand: vf610_nfc: add initializer to avoid -Wmaybe-uninitialized
From: Masahiro Yamada @ 2019-04-23 3:49 UTC (permalink / raw)
To: Andrew Morton, linux-arch
Cc: linux-s390, Arnd Bergmann, Mathieu Malaterre, x86, Heiko Carstens,
linux-mips, linux-kernel, Masahiro Yamada, Ingo Molnar, linux-mtd,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20190423034959.13525-1-yamada.masahiro@socionext.com>
This prepares to move CONFIG_OPTIMIZE_INLINING from x86 to a common
place. We need to eliminate potential issues beforehand.
Kbuild test robot has never reported -Wmaybe-uninitialized warning
for this probably because vf610_nfc_run() is inlined by the x86
compiler's inlining heuristic.
If CONFIG_OPTIMIZE_INLINING is enabled for a different architecture
and vf610_nfc_run() is not inlined, the following warning is reported:
drivers/mtd/nand/raw/vf610_nfc.c: In function ‘vf610_nfc_cmd’:
drivers/mtd/nand/raw/vf610_nfc.c:455:3: warning: ‘offset’ may be used uninitialized in this function [-Wmaybe-uninitialized]
vf610_nfc_rd_from_sram(instr->ctx.data.buf.in + offset,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
nfc->regs + NFC_MAIN_AREA(0) + offset,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
trfr_sz, !nfc->data_access);
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v3: None
Changes in v2:
- split into a separate patch
drivers/mtd/nand/raw/vf610_nfc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/vf610_nfc.c b/drivers/mtd/nand/raw/vf610_nfc.c
index a662ca1970e5..19792d725ec2 100644
--- a/drivers/mtd/nand/raw/vf610_nfc.c
+++ b/drivers/mtd/nand/raw/vf610_nfc.c
@@ -364,7 +364,7 @@ static int vf610_nfc_cmd(struct nand_chip *chip,
{
const struct nand_op_instr *instr;
struct vf610_nfc *nfc = chip_to_nfc(chip);
- int op_id = -1, trfr_sz = 0, offset;
+ int op_id = -1, trfr_sz = 0, offset = 0;
u32 col = 0, row = 0, cmd1 = 0, cmd2 = 0, code = 0;
bool force8bit = false;
--
2.17.1
^ 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