* Re: CONFIG_ARCH_SUPPORTS_INT128: Why not mips, s390, powerpc, and alpha?
From: George Spelvin @ 2019-03-30 10:30 UTC (permalink / raw)
To: heiko.carstens, lkml; +Cc: linux-s390, linuxppc-dev, linux-mips, linux-alpha
In-Reply-To: <20190330084346.GA3801@osiris>
On Sat, 30 Mar 2019 at 09:43:47 +0100, Heiko Carstens wrote:
> It hasn't been enabled on s390 simply because at least I wasn't aware
> of this config option. Feel free to send a patch, otherwise I will
> enable this. Whatever you prefer.
>
> Thanks for pointing this out!
Here's a draft patch, but obviously it should be tested!
From 6f3cc608c49dba33a38e81232a2fd46e8fa8dbcd Mon Sep 17 00:00:00 2001
From: George Spelvin <lkml@sdf.org>
Date: Sat, 30 Mar 2019 10:27:14 +0000
Subject: [PATCH] s390: Enable CONFIG_ARCH_SUPPORTS_INT128 on 64-bit builds
If a platform supports a 64x64->128-bit widening multiply,
that allows more efficient scaling of 64-bit values in various
parts of the kernel. GCC advertises __int128 support with the
__INT128__ #define, but we care about efficient inline
support, so this is a separate flag.
For s390, that was added on 24 March 2017 by
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=246457
which is part of GCC 7.
It also only applies to TARGET_ARCH12, which I am guessing
corresponds to HAVE_MARCH_ZEC12_FEATURES. clang support is
pure guesswork.
Signed-off-by: George Spelvin <lkml@sdf.org>
---
arch/s390/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index ed554b09eb3f..43e6dc677f7d 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -372,6 +372,7 @@ endchoice
config 64BIT
def_bool y
+ select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 70000 && HAVE_MARCH_ZEC12_FEATURES || CC_IS_CLANG
config COMPAT
def_bool y
--
2.20.1
^ permalink raw reply related
* Re: CONFIG_ARCH_SUPPORTS_INT128: Why not mips, s390, powerpc, and alpha?
From: George Spelvin @ 2019-03-30 11:28 UTC (permalink / raw)
To: lkml, segher; +Cc: linux-s390, linuxppc-dev, linux-mips, linux-alpha
In-Reply-To: <20190329202557.GL3969@gate.crashing.org>
General update:
I've since found the reason for the GCC version check.
It's not *broken* support (apologies for impugning GCC),
but *inefficient* support via a muditi3 helper function.
The version check is the version which added in-line code generation.
For example, s390 support was added in March of 2017 and is part
of the 7.1 release.
I hvave to do some digging through gcc version history to
find when it was added to various architectures.
(And MIPS64v6 support is still lacking in gcc 9.)
On Fri, 29 Mar 2019 at 15:25:58 -0500, Segher Boessenkool wrote:
> On Fri, Mar 29, 2019 at 01:07:07PM +0000, George Spelvin wrote:
>> I don't have easy access to an Alpha cross-compiler to test, but
>> as it has UMULH, I suspect it would work, too.
>
> https://mirrors.edge.kernel.org/pub/tools/crosstool/
Thanks for the pointer; I have a working Alpha cross-compiler now.
>> u64 get_random_u64(void);
>> u64 get_random_max64(u64 range, u64 lim)
>> {
>> unsigned __int128 prod;
>> do {
>> prod = (unsigned __int128)get_random_u64() * range;
>> } while (unlikely((u64)prod < lim));
>> return prod >> 64;
>> }
>
>> MIPS:
>> .L7:
>> jal get_random_u64
>> nop
>> dmultu $2,$17
>> mflo $3
>> sltu $4,$3,$16
>> bne $4,$0,.L7
>> mfhi $2
>>
>> PowerPC:
>> .L9:
>> bl get_random_u64
>> nop
>> mulld 9,3,31
>> mulhdu 3,3,31
>> cmpld 7,30,9
>> bgt 7,.L9
>>
>> I like that the MIPS code leaves the high half of the product in
>> the hi register until it tests the low half; I wish PowerPC would
>> similarly move the mulhdu *after* the loop,
> The MIPS code has the multiplication inside the loop as well, and even
> the mfhi I think: MIPS has delay slots.
Yes, it's in the delay slot, which is fine (the branch is unlikely,
after all). But it does the compare (sltu) before accessing %hi, which
is good as %hi often has a longer latency than %lo. (On out-of-order
cores, of course, none of this matters.)
> GCC treats the int128 as one register until it has expanded to RTL, and it
> does not do such loop optimisations after that, apparently.
>
> File a PR please? https://gcc.gnu.org/bugzilla/
Er... about what? The fact that the PowerPC code is not
>> PowerPC:
>> .L9:
>> bl get_random_u64
>> nop
>> mulld 9,3,31
>> cmpld 7,30,9
>> bgt 7,.L9
>> mulhdu 3,3,31
I'm not sure quite how to explain it in gcc-ese.
^ permalink raw reply
* Re: CONFIG_ARCH_SUPPORTS_INT128: Why not mips, s390, powerpc, and alpha?
From: George Spelvin @ 2019-03-30 13:00 UTC (permalink / raw)
To: heiko.carstens, lkml; +Cc: linux-s390, linuxppc-dev, linux-mips, linux-alpha
In-Reply-To: <201903301030.x2UAUNOg026448@sdf.org>
I've been tracking down when "umulditi3" support was added to various
gcc platforms. So far, I've found:
ia64: 2005-07-28, gcc 4.1.0
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=102463
mips: 2008-06-09, gcc 4.4.0
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=136600
alpha: 2013-02-01, gcc 4.8.0
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=195668
s390: 2011-10-07, gcc 4.7.0
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=179647
ppc64: 2013-02-01, gcc 4.8.0
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=195667
Here's a revised s390 patch.
From e8ea8c0a5d618385049248649b8c13717b598a42 Mon Sep 17 00:00:00 2001
From: George Spelvin <lkml@sdf.org>
Date: Sat, 30 Mar 2019 10:27:14 +0000
Subject: [PATCH v2] s390: Enable CONFIG_ARCH_SUPPORTS_INT128 on 64-bit builds
If a platform supports a 64x64->128-bit widening multiply,
that allows more efficient scaling of 64-bit values in various
parts of the kernel. GCC advertises __int128 support with the
__INT128__ #define, but we care about efficient inline
support, so this is a separate flag.
For s390, that was added on 2011-10-07 by
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=179647
which is part of GCC 4.7.
Signed-off-by: George Spelvin <lkml@sdf.org>
---
arch/s390/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index ed554b09eb3f..6ddaee6573f4 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -372,6 +372,7 @@ endchoice
config 64BIT
def_bool y
+ select ARCH_SUPPORTS_INT128 if GCC_VERSION >= 40700 || CC_IS_CLANG
config COMPAT
def_bool y
--
2.20.1
^ permalink raw reply related
* Re: [RFC PATCH] drivers/dax: Allow to include DEV_DAX_PMEM as builtin
From: Dan Williams @ 2019-03-30 15:33 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: Linux MM, linuxppc-dev, linux-nvdimm
In-Reply-To: <20190330054205.28005-1-aneesh.kumar@linux.ibm.com>
On Fri, Mar 29, 2019 at 10:42 PM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> This move the dependency to DEV_DAX_PMEM_COMPAT such that only
> if DEV_DAX_PMEM is built as module we can allow the compat support.
>
> This allows to test the new code easily in a emulation setup where we
> often build things without module support.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> ---
> drivers/dax/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
> index 5ef624fe3934..e582e088b48c 100644
> --- a/drivers/dax/Kconfig
> +++ b/drivers/dax/Kconfig
> @@ -23,7 +23,6 @@ config DEV_DAX
> config DEV_DAX_PMEM
> tristate "PMEM DAX: direct access to persistent memory"
> depends on LIBNVDIMM && NVDIMM_DAX && DEV_DAX
> - depends on m # until we can kill DEV_DAX_PMEM_COMPAT
> default DEV_DAX
> help
> Support raw access to persistent memory. Note that this
> @@ -50,7 +49,7 @@ config DEV_DAX_KMEM
>
> config DEV_DAX_PMEM_COMPAT
> tristate "PMEM DAX: support the deprecated /sys/class/dax interface"
> - depends on DEV_DAX_PMEM
> + depends on DEV_DAX_PMEM=m
Looks ok, just also a needs a "depends on m" here, because
DEV_DAX_PMEM_COMPAT=y is an invalid config.
^ permalink raw reply
* Re: [PATCH 0/5] simple sort swap function usage improvements
From: George Spelvin @ 2019-03-30 17:16 UTC (permalink / raw)
To: adrian.hunter, ard.biesheuvel, benh, bp, darrick.wong, dchinner,
dedekind1, gregkh, hpa, jlbec, jpoimboe, linux-kernel, linux-mtd,
linux-snps-arc, linuxppc-dev, lkml, mark, mingo, mpe,
naveen.n.rao, ocfs2-devel, paulus, richard, sfr, st5pub, tglx,
vgupta, x86
Cc: mhocko, gustavo, peterz, amir73il, linux, kamalesh, piaojun,
yamada.masahiro, jiang.biao2, jslaby, yuehaibing, rppt,
ge.changwei, keescook, jannh, ashish.samant, npiggin, jiangyiwen,
andriy.shevchenko, lchen, malat, akpm
In-Reply-To: <18626931553963861@sas1-b3ec53dbc12b.qloud-c.yandex.net>
Great work; that is indeed a logical follow-on.
Reviewed by: George Spelvin <lkml@sdf.org>
I you feel even more ambitious, you could try impementing Rasmus
Villemoes' idea of having generic *compare* functions. (It's on
my to-do list, but I haven't made meaningful progress yet, and I'm
happy to pawn it off.)
A significant fraction of the time, the sort key is a 4- or 8-byte
integer field in a structure at a small offset from the base or
list_head.
A function pointer < 4096 could be interpreted as encoding:
- Key size (1 bit)
- Key signedness (1 bit)
- Sort direction (1 bit)
- Offset (9 bits; +/-256 words = +/-1024 bytes, or 0..511 words from start)
With the correct level of preprocessor hackery,
SIMPLE_CMP_ASCENDING(struct type, key_field)
SIMPLE_LIST_CMP_ASCENDING(struct type, list_field, key_field)
SIMPLE_CMP_DESCENDING(struct type, key_field)
SIMPLE_LIST_CMP_DESCENDING(struct type, list_field, key_field)
could encode all that and cause a compile-time error if the key
is the wrong type or the offset is out of range.
^ permalink raw reply
* Re: [PATCH 0/5] simple sort swap function usage improvements
From: Andy Shevchenko @ 2019-03-30 18:32 UTC (permalink / raw)
To: Andrey Abramov
Cc: Michal Hocko, Gustavo A. R. Silva, Peter Zijlstra (Intel),
Dave Chinner, Rasmus Villemoes, Linux Kernel Mailing List,
piaojun, Masahiro Yamada, Paul Mackerras, H. Peter Anvin,
jiang.biao2, Jiri Slaby, Stephen Rothwell, darrick.wong,
Richard Weinberger, mark,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), YueHaibing,
lchen, rppt, ge.changwei, Ingo Molnar, naveen.n.rao,
linux-snps-arc, kamalesh, amir73il, Kees Cook, Jann Horn,
ashish.samant, Nicholas Piggin, jiangyiwen, Borislav Petkov,
Joel Becker, Josh Poimboeuf, Thomas Gleixner, Andy Shevchenko,
George Spelvin, Artem Bityutskiy, Mathieu Malaterre, Vineet Gupta,
Ard Biesheuvel, Adrian Hunter, Greg Kroah-Hartman,
open list:MEMORY TECHNOLOGY..., Morton Andrew,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT, ocfs2-devel
In-Reply-To: <18626931553963861@sas1-b3ec53dbc12b.qloud-c.yandex.net>
On Sat, Mar 30, 2019 at 6:39 PM Andrey Abramov <st5pub@yandex.ru> wrote:
>
> This is the logical continuation of sort improvements by George Spelvin
> "lib/sort & lib/list_sort: faster and smaller" series
> (added to the linux-next really recently).
>
> Patches from 1 to 4 replace simple swap functions with the built-in
> (which is now much faster) and grouped by subsystem (after that only
> 3 files implement custom swap - arch/x86/kernel/unwind_orc.c,
> kernel/jump_label.c and lib/extable.c).
>
> Patch #5 replaces the int type with the size_t type of the size argument
> in the swap function.
> Andrey Abramov (5):
> arch/arc: unwind.c: replace swap function with built-in one
> powerpc: module_[32|64].c: replace swap function with built-in one
> ocfs2: dir,refcounttree,xattr: replace swap functions with built-in
> one
> ubifs: find.c: replace swap function with built-in one
> Lib: sort.h: replace int size with size_t size in the swap function
You have to do something about Cc list.
50 people is complete overkill. Seems as your series is a set of
independent fixes. Why not to split and Cc based on individual case?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 5/5] Lib: sort.h: replace int size with size_t size in the swap function
From: gregkh @ 2019-03-30 18:38 UTC (permalink / raw)
To: Andrey Abramov
Cc: mhocko@suse.com, gustavo@embeddedor.com, peterz@infradead.org,
Dave Chinner, Rasmus Villemoes, Linux Kernel Mailing List,
piaojun@huawei.com, yamada.masahiro@socionext.com,
paulus@samba.org, hpa@zytor.com, jiang.biao2@zte.com.cn,
jslaby@suse.cz, sfr@canb.auug.org.au, darrick.wong@oracle.com,
richard@nod.at, mark@fasheh.com, x86@kernel.org,
yuehaibing@huawei.com, lchen@suse.com, rppt@linux.ibm.com,
ge.changwei@h3c.com, mingo@redhat.com,
naveen.n.rao@linux.vnet.ibm.com,
linux-snps-arc@lists.infradead.org, kamalesh@linux.vnet.ibm.com,
amir73il@gmail.com, keescook@chromium.org, jannh@google.com,
ashish.samant@oracle.com, npiggin@gmail.com,
jiangyiwen@huawei.com, bp@alien8.de, jlbec@evilplan.org,
jpoimboe@redhat.com, tglx@linutronix.de, Andy Shevchenko,
George Spelvin, dedekind1@gmail.com, malat@debian.org,
vgupta@synopsys.com, ard.biesheuvel@linaro.org,
adrian.hunter@intel.com, linux-mtd@lists.infradead.org,
Morton Andrew, linuxppc-dev@lists.ozlabs.org,
ocfs2-devel@oss.oracle.com
In-Reply-To: <20467491553964233@myt4-c0b480c282c8.qloud-c.yandex.net>
On Sat, Mar 30, 2019 at 07:43:53PM +0300, Andrey Abramov wrote:
> Replace int type with size_t type of the size argument
> in the swap function, also affect all its dependencies.
This says _what_ the patch does, but it gives no clue as to _why_ you
are doing this. Neither did your 0/5 patch :(
Why make this change? Nothing afterward depends on it from what I can
tell, so why is it needed?
thanks,
greg k-h
^ permalink raw reply
* Re: CONFIG_ARCH_SUPPORTS_INT128: Why not mips, s390, powerpc, and alpha?
From: Segher Boessenkool @ 2019-03-30 23:14 UTC (permalink / raw)
To: Michael Cree, George Spelvin, linux-alpha, linux-mips, linux-s390,
linuxppc-dev
In-Reply-To: <20190329200015.ujmjrvn6ta67h74j@tower>
On Sat, Mar 30, 2019 at 09:00:15AM +1300, Michael Cree wrote:
> It does move the umulh inside the loop but that seems sensible since
> the use of unlikely() implies that the loop is unlikely to be taken
> so on average it would be a good bet to start the calculation of
> umulh earlier since it has a few cycles latency to get the result,
> and it is pipelined so it can be calculated in the shadow of the
> mulq instruction on the same execution unit.
That may make sense, but it is not what happens, sorry. It _starts off_
as part of the loop, and it is never moved outside.
The only difference between a likely loop and an unlikely loop here I've
seen (on all targets I tried) is that with a likely loop the loop target
is aligned, while with an unlikely loop it isn't.
> On the older CPUs
> (before EV6 which are not out-of-order execution) having the umulh
> inside the loop may be a net gain.
Yes. Similarly, on Power you can often calculate the high mul at the same
time as the low mul, for no extra cost. This may be true on many archs.
Segher
^ permalink raw reply
* Re: CONFIG_ARCH_SUPPORTS_INT128: Why not mips, s390, powerpc, and alpha?
From: Segher Boessenkool @ 2019-03-30 23:52 UTC (permalink / raw)
To: George Spelvin; +Cc: linux-s390, linuxppc-dev, linux-mips, linux-alpha
In-Reply-To: <201903301128.x2UBSLNH017484@sdf.org>
On Sat, Mar 30, 2019 at 11:28:21AM +0000, George Spelvin wrote:
> >> I like that the MIPS code leaves the high half of the product in
> >> the hi register until it tests the low half; I wish PowerPC would
> >> similarly move the mulhdu *after* the loop,
>
> > The MIPS code has the multiplication inside the loop as well, and even
> > the mfhi I think: MIPS has delay slots.
>
> Yes, it's in the delay slot, which is fine (the branch is unlikely,
> after all). But it does the compare (sltu) before accessing %hi, which
> is good as %hi often has a longer latency than %lo. (On out-of-order
> cores, of course, none of this matters.)
Yes. But it does the mfhi on every iteration, while it only needs it for
the last one (or after the last one). This may not be more expensive for
the actual hardware, but it is for GCC's cost model
> > GCC treats the int128 as one register until it has expanded to RTL, and it
> > does not do such loop optimisations after that, apparently.
> >
> > File a PR please? https://gcc.gnu.org/bugzilla/
>
> Er... about what? The fact that the PowerPC code is not
> >> PowerPC:
> >> .L9:
> >> bl get_random_u64
> >> nop
> >> mulld 9,3,31
> >> cmpld 7,30,9
> >> bgt 7,.L9
> >> mulhdu 3,3,31
>
> I'm not sure quite how to explain it in gcc-ese.
Yeah, exactly, like that. This transformation is called "loop sinking"
usually: if anything that is set within a loop is only used after the loop,
it can be set after the loop (provided you keep the set's sources alive).
Segher
^ permalink raw reply
* Re: CONFIG_ARCH_SUPPORTS_INT128: Why not mips, s390, powerpc, and alpha?
From: Segher Boessenkool @ 2019-03-31 0:30 UTC (permalink / raw)
To: George Spelvin
Cc: linux-s390, linux-alpha, heiko.carstens, linuxppc-dev, linux-mips
In-Reply-To: <201903301030.x2UAUNOg026448@sdf.org>
On Sat, Mar 30, 2019 at 10:30:23AM +0000, George Spelvin wrote:
> For s390, that was added on 24 March 2017 by
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=246457
> which is part of GCC 7.
>
> It also only applies to TARGET_ARCH12, which I am guessing
> corresponds to HAVE_MARCH_ZEC12_FEATURES.
zEC12 is arch10, while z14 is arch12. See
https://sourceware.org/binutils/docs-2.32/as/s390-Options.html#s390-Options
for example; it lists the correspondences, and states "The processor names
starting with arch refer to the edition number in the Principle of
Operations manual. They can be used as alternate processor names and have
been added for compatibility with the IBM XL compiler."
Newer GCC does not use the somewhat confusing TARGET_ARCH12 name anymore;
see https://gcc.gnu.org/r264796 .
Segher
^ permalink raw reply
* [PATCH 4/5] ubifs: find.c: replace swap function with built-in one
From: Andrey Abramov @ 2019-03-30 16:43 UTC (permalink / raw)
To: vgupta@synopsys.com, benh@kernel.crashing.org, paulus@samba.org,
mpe@ellerman.id.au, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, x86@kernel.org, mark@fasheh.com,
jlbec@evilplan.org, richard@nod.at, dedekind1@gmail.com,
adrian.hunter@intel.com, gregkh@linuxfoundation.org,
naveen.n.rao@linux.vnet.ibm.com, jpoimboe@redhat.com,
Dave Chinner, darrick.wong@oracle.com, ard.biesheuvel@linaro.org,
George Spelvin, linux-snps-arc@lists.infradead.org,
Linux Kernel Mailing List, linuxppc-dev@lists.ozlabs.org,
ocfs2-devel@oss.oracle.com, linux-mtd@lists.infradead.org,
sfr@canb.auug.org.au
Cc: mhocko@suse.com, gustavo@embeddedor.com, peterz@infradead.org,
amir73il@gmail.com, Rasmus Villemoes, kamalesh@linux.vnet.ibm.com,
piaojun@huawei.com, yamada.masahiro@socionext.com,
jiang.biao2@zte.com.cn, jslaby@suse.cz, yuehaibing@huawei.com,
rppt@linux.ibm.com, ge.changwei@h3c.com, keescook@chromium.org,
jannh@google.com, ashish.samant@oracle.com, npiggin@gmail.com,
jiangyiwen@huawei.com, Andy Shevchenko, lchen@suse.com,
malat@debian.org, Morton Andrew
In-Reply-To: <18626931553963861@sas1-b3ec53dbc12b.qloud-c.yandex.net>
Replace swap_dirty_idx function with built-in one,
because swap_dirty_idx does only a simple byte to byte swap.
Signed-off-by: Andrey Abramov <st5pub@yandex.ru>
---
fs/ubifs/find.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/fs/ubifs/find.c b/fs/ubifs/find.c
index f9646835b026..5deaae7fcead 100644
--- a/fs/ubifs/find.c
+++ b/fs/ubifs/find.c
@@ -747,12 +747,6 @@ static int cmp_dirty_idx(const struct ubifs_lprops **a,
return lpa->dirty + lpa->free - lpb->dirty - lpb->free;
}
-static void swap_dirty_idx(struct ubifs_lprops **a, struct ubifs_lprops **b,
- int size)
-{
- swap(*a, *b);
-}
-
/**
* ubifs_save_dirty_idx_lnums - save an array of the most dirty index LEB nos.
* @c: the UBIFS file-system description object
@@ -772,8 +766,7 @@ int ubifs_save_dirty_idx_lnums(struct ubifs_info *c)
sizeof(void *) * c->dirty_idx.cnt);
/* Sort it so that the dirtiest is now at the end */
sort(c->dirty_idx.arr, c->dirty_idx.cnt, sizeof(void *),
- (int (*)(const void *, const void *))cmp_dirty_idx,
- (void (*)(void *, void *, int))swap_dirty_idx);
+ (int (*)(const void *, const void *))cmp_dirty_idx, NULL);
dbg_find("found %d dirty index LEBs", c->dirty_idx.cnt);
if (c->dirty_idx.cnt)
dbg_find("dirtiest index LEB is %d with dirty %d and free %d",
--
2.21.0
^ permalink raw reply related
* [PATCH 5/5] Lib: sort.h: replace int size with size_t size in the swap function
From: Andrey Abramov @ 2019-03-30 16:43 UTC (permalink / raw)
To: vgupta@synopsys.com, benh@kernel.crashing.org, paulus@samba.org,
mpe@ellerman.id.au, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, x86@kernel.org, mark@fasheh.com,
jlbec@evilplan.org, richard@nod.at, dedekind1@gmail.com,
adrian.hunter@intel.com, gregkh@linuxfoundation.org,
naveen.n.rao@linux.vnet.ibm.com, jpoimboe@redhat.com,
Dave Chinner, darrick.wong@oracle.com, ard.biesheuvel@linaro.org,
George Spelvin, linux-snps-arc@lists.infradead.org,
Linux Kernel Mailing List, linuxppc-dev@lists.ozlabs.org,
ocfs2-devel@oss.oracle.com, linux-mtd@lists.infradead.org,
sfr@canb.auug.org.au
Cc: mhocko@suse.com, gustavo@embeddedor.com, peterz@infradead.org,
amir73il@gmail.com, Rasmus Villemoes, kamalesh@linux.vnet.ibm.com,
piaojun@huawei.com, yamada.masahiro@socionext.com,
jiang.biao2@zte.com.cn, jslaby@suse.cz, yuehaibing@huawei.com,
rppt@linux.ibm.com, ge.changwei@h3c.com, keescook@chromium.org,
jannh@google.com, ashish.samant@oracle.com, npiggin@gmail.com,
jiangyiwen@huawei.com, Andy Shevchenko, lchen@suse.com,
malat@debian.org, Morton Andrew
In-Reply-To: <18626931553963861@sas1-b3ec53dbc12b.qloud-c.yandex.net>
Replace int type with size_t type of the size argument
in the swap function, also affect all its dependencies.
Signed-off-by: Andrey Abramov <st5pub@yandex.ru>
---
arch/x86/kernel/unwind_orc.c | 2 +-
include/linux/sort.h | 2 +-
kernel/jump_label.c | 2 +-
lib/extable.c | 2 +-
lib/sort.c | 6 +++---
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index 89be1be1790c..1078c287198c 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -176,7 +176,7 @@ static struct orc_entry *orc_find(unsigned long ip)
return orc_ftrace_find(ip);
}
-static void orc_sort_swap(void *_a, void *_b, int size)
+static void orc_sort_swap(void *_a, void *_b, size_t size)
{
struct orc_entry *orc_a, *orc_b;
struct orc_entry orc_tmp;
diff --git a/include/linux/sort.h b/include/linux/sort.h
index 2b99a5dd073d..aea39d552ff7 100644
--- a/include/linux/sort.h
+++ b/include/linux/sort.h
@@ -6,6 +6,6 @@
void sort(void *base, size_t num, size_t size,
int (*cmp)(const void *, const void *),
- void (*swap)(void *, void *, int));
+ void (*swap)(void *, void *, size_t));
#endif
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index bad96b476eb6..340b788571fb 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -45,7 +45,7 @@ static int jump_label_cmp(const void *a, const void *b)
return 0;
}
-static void jump_label_swap(void *a, void *b, int size)
+static void jump_label_swap(void *a, void *b, size_t size)
{
long delta = (unsigned long)a - (unsigned long)b;
struct jump_entry *jea = a;
diff --git a/lib/extable.c b/lib/extable.c
index f54996fdd0b8..db2888342cd7 100644
--- a/lib/extable.c
+++ b/lib/extable.c
@@ -28,7 +28,7 @@ static inline unsigned long ex_to_insn(const struct exception_table_entry *x)
#ifndef ARCH_HAS_RELATIVE_EXTABLE
#define swap_ex NULL
#else
-static void swap_ex(void *a, void *b, int size)
+static void swap_ex(void *a, void *b, size_t size)
{
struct exception_table_entry *x = a, *y = b, tmp;
int delta = b - a;
diff --git a/lib/sort.c b/lib/sort.c
index 50855ea8c262..60fbbc29104a 100644
--- a/lib/sort.c
+++ b/lib/sort.c
@@ -114,7 +114,7 @@ static void swap_bytes(void *a, void *b, size_t n)
} while (n);
}
-typedef void (*swap_func_t)(void *a, void *b, int size);
+typedef void (*swap_func_t)(void *a, void *b, size_t size);
/*
* The values are arbitrary as long as they can't be confused with
@@ -138,7 +138,7 @@ static void do_swap(void *a, void *b, size_t size, swap_func_t swap_func)
else if (swap_func == SWAP_BYTES)
swap_bytes(a, b, size);
else
- swap_func(a, b, (int)size);
+ swap_func(a, b, size);
}
/**
@@ -187,7 +187,7 @@ static size_t parent(size_t i, unsigned int lsbit, size_t size)
*/
void sort(void *base, size_t num, size_t size,
int (*cmp_func)(const void *, const void *),
- void (*swap_func)(void *, void *, int size))
+ void (*swap_func)(void *, void *, size_t size))
{
/* pre-scale counters for performance */
size_t n = num * size, a = (num/2) * size;
--
2.21.0
^ permalink raw reply related
* [PATCH 0/5] simple sort swap function usage improvements
From: Andrey Abramov @ 2019-03-30 16:37 UTC (permalink / raw)
To: vgupta, benh, paulus, mpe, tglx, mingo, bp, hpa, x86, mark, jlbec,
richard, dedekind1, adrian.hunter, gregkh, naveen.n.rao, jpoimboe,
Dave Chinner, darrick.wong, ard.biesheuvel, George Spelvin,
linux-snps-arc, Linux Kernel Mailing List, linuxppc-dev,
ocfs2-devel, linux-mtd, sfr
Cc: mhocko, gustavo, peterz, amir73il, Rasmus Villemoes, kamalesh,
piaojun, yamada.masahiro, jiang.biao2, jslaby, yuehaibing, rppt,
ge.changwei, keescook, jannh, ashish.samant, npiggin, jiangyiwen,
Andy Shevchenko, lchen, malat, Morton Andrew
This is the logical continuation of sort improvements by George Spelvin
"lib/sort & lib/list_sort: faster and smaller" series
(added to the linux-next really recently).
Patches from 1 to 4 replace simple swap functions with the built-in
(which is now much faster) and grouped by subsystem (after that only
3 files implement custom swap - arch/x86/kernel/unwind_orc.c,
kernel/jump_label.c and lib/extable.c).
Patch #5 replaces the int type with the size_t type of the size argument
in the swap function.
Andrey Abramov (5):
arch/arc: unwind.c: replace swap function with built-in one
powerpc: module_[32|64].c: replace swap function with built-in one
ocfs2: dir,refcounttree,xattr: replace swap functions with built-in
one
ubifs: find.c: replace swap function with built-in one
Lib: sort.h: replace int size with size_t size in the swap function
arch/arc/kernel/unwind.c | 20 ++------------------
arch/powerpc/kernel/module_32.c | 17 +----------------
arch/powerpc/kernel/module_64.c | 17 +----------------
arch/x86/kernel/unwind_orc.c | 2 +-
fs/ocfs2/dir.c | 13 +------------
fs/ocfs2/refcounttree.c | 13 +++----------
fs/ocfs2/xattr.c | 15 +++------------
fs/ubifs/find.c | 9 +--------
include/linux/sort.h | 2 +-
kernel/jump_label.c | 2 +-
lib/extable.c | 2 +-
lib/sort.c | 6 +++---
12 files changed, 19 insertions(+), 99 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH 2/5] powerpc: module_[32|64].c: replace swap function with built-in one
From: Andrey Abramov @ 2019-03-30 16:41 UTC (permalink / raw)
To: vgupta@synopsys.com, benh@kernel.crashing.org, paulus@samba.org,
mpe@ellerman.id.au, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, x86@kernel.org, mark@fasheh.com,
jlbec@evilplan.org, richard@nod.at, dedekind1@gmail.com,
adrian.hunter@intel.com, gregkh@linuxfoundation.org,
naveen.n.rao@linux.vnet.ibm.com, jpoimboe@redhat.com,
Dave Chinner, darrick.wong@oracle.com, ard.biesheuvel@linaro.org,
George Spelvin, linux-snps-arc@lists.infradead.org,
Linux Kernel Mailing List, linuxppc-dev@lists.ozlabs.org,
ocfs2-devel@oss.oracle.com, linux-mtd@lists.infradead.org,
sfr@canb.auug.org.au
Cc: mhocko@suse.com, gustavo@embeddedor.com, peterz@infradead.org,
amir73il@gmail.com, Rasmus Villemoes, kamalesh@linux.vnet.ibm.com,
piaojun@huawei.com, yamada.masahiro@socionext.com,
jiang.biao2@zte.com.cn, jslaby@suse.cz, yuehaibing@huawei.com,
rppt@linux.ibm.com, ge.changwei@h3c.com, keescook@chromium.org,
jannh@google.com, ashish.samant@oracle.com, npiggin@gmail.com,
jiangyiwen@huawei.com, Andy Shevchenko, lchen@suse.com,
malat@debian.org, Morton Andrew
In-Reply-To: <18626931553963861@sas1-b3ec53dbc12b.qloud-c.yandex.net>
Replace relaswap with built-in one, because of relaswap
does a simple byte to byte swap.
Signed-off-by: Andrey Abramov <st5pub@yandex.ru>
---
arch/powerpc/kernel/module_32.c | 17 +----------------
arch/powerpc/kernel/module_64.c | 17 +----------------
2 files changed, 2 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/kernel/module_32.c b/arch/powerpc/kernel/module_32.c
index 88d83771f462..c311e8575d10 100644
--- a/arch/powerpc/kernel/module_32.c
+++ b/arch/powerpc/kernel/module_32.c
@@ -79,21 +79,6 @@ static int relacmp(const void *_x, const void *_y)
return 0;
}
-static void relaswap(void *_x, void *_y, int size)
-{
- uint32_t *x, *y, tmp;
- int i;
-
- y = (uint32_t *)_x;
- x = (uint32_t *)_y;
-
- for (i = 0; i < sizeof(Elf32_Rela) / sizeof(uint32_t); i++) {
- tmp = x[i];
- x[i] = y[i];
- y[i] = tmp;
- }
-}
-
/* Get the potential trampolines size required of the init and
non-init sections */
static unsigned long get_plt_size(const Elf32_Ehdr *hdr,
@@ -130,7 +115,7 @@ static unsigned long get_plt_size(const Elf32_Ehdr *hdr,
*/
sort((void *)hdr + sechdrs[i].sh_offset,
sechdrs[i].sh_size / sizeof(Elf32_Rela),
- sizeof(Elf32_Rela), relacmp, relaswap);
+ sizeof(Elf32_Rela), relacmp, NULL);
ret += count_relocs((void *)hdr
+ sechdrs[i].sh_offset,
diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 8661eea78503..0c833d7f36f1 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -231,21 +231,6 @@ static int relacmp(const void *_x, const void *_y)
return 0;
}
-static void relaswap(void *_x, void *_y, int size)
-{
- uint64_t *x, *y, tmp;
- int i;
-
- y = (uint64_t *)_x;
- x = (uint64_t *)_y;
-
- for (i = 0; i < sizeof(Elf64_Rela) / sizeof(uint64_t); i++) {
- tmp = x[i];
- x[i] = y[i];
- y[i] = tmp;
- }
-}
-
/* Get size of potential trampolines required. */
static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
const Elf64_Shdr *sechdrs)
@@ -269,7 +254,7 @@ static unsigned long get_stubs_size(const Elf64_Ehdr *hdr,
*/
sort((void *)sechdrs[i].sh_addr,
sechdrs[i].sh_size / sizeof(Elf64_Rela),
- sizeof(Elf64_Rela), relacmp, relaswap);
+ sizeof(Elf64_Rela), relacmp, NULL);
relocs += count_relocs((void *)sechdrs[i].sh_addr,
sechdrs[i].sh_size
--
2.21.0
^ permalink raw reply related
* [PATCH 1/5] arch/arc: unwind.c: replace swap function with built-in one
From: Andrey Abramov @ 2019-03-30 16:40 UTC (permalink / raw)
To: vgupta@synopsys.com, benh@kernel.crashing.org, paulus@samba.org,
mpe@ellerman.id.au, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, x86@kernel.org, mark@fasheh.com,
jlbec@evilplan.org, richard@nod.at, dedekind1@gmail.com,
adrian.hunter@intel.com, gregkh@linuxfoundation.org,
naveen.n.rao@linux.vnet.ibm.com, jpoimboe@redhat.com,
Dave Chinner, darrick.wong@oracle.com, ard.biesheuvel@linaro.org,
George Spelvin, linux-snps-arc@lists.infradead.org,
Linux Kernel Mailing List, linuxppc-dev@lists.ozlabs.org,
ocfs2-devel@oss.oracle.com, linux-mtd@lists.infradead.org,
sfr@canb.auug.org.au
Cc: mhocko@suse.com, gustavo@embeddedor.com, peterz@infradead.org,
amir73il@gmail.com, Rasmus Villemoes, kamalesh@linux.vnet.ibm.com,
piaojun@huawei.com, yamada.masahiro@socionext.com,
jiang.biao2@zte.com.cn, jslaby@suse.cz, yuehaibing@huawei.com,
rppt@linux.ibm.com, ge.changwei@h3c.com, keescook@chromium.org,
jannh@google.com, ashish.samant@oracle.com, npiggin@gmail.com,
jiangyiwen@huawei.com, Andy Shevchenko, lchen@suse.com,
malat@debian.org, Morton Andrew
In-Reply-To: <18626931553963861@sas1-b3ec53dbc12b.qloud-c.yandex.net>
Replace swap_eh_frame_hdr_table_entries with built-in one, because
swap_eh_frame_hdr_table_entries does a simple byte to byte swap.
Signed-off-by: Andrey Abramov <st5pub@yandex.ru>
---
arch/arc/kernel/unwind.c | 20 ++------------------
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/arch/arc/kernel/unwind.c b/arch/arc/kernel/unwind.c
index 271e9fafa479..7610fe84afea 100644
--- a/arch/arc/kernel/unwind.c
+++ b/arch/arc/kernel/unwind.c
@@ -248,20 +248,6 @@ static int cmp_eh_frame_hdr_table_entries(const void *p1, const void *p2)
return (e1->start > e2->start) - (e1->start < e2->start);
}
-static void swap_eh_frame_hdr_table_entries(void *p1, void *p2, int size)
-{
- struct eh_frame_hdr_table_entry *e1 = p1;
- struct eh_frame_hdr_table_entry *e2 = p2;
- unsigned long v;
-
- v = e1->start;
- e1->start = e2->start;
- e2->start = v;
- v = e1->fde;
- e1->fde = e2->fde;
- e2->fde = v;
-}
-
static void init_unwind_hdr(struct unwind_table *table,
void *(*alloc) (unsigned long))
{
@@ -354,10 +340,8 @@ static void init_unwind_hdr(struct unwind_table *table,
}
WARN_ON(n != header->fde_count);
- sort(header->table,
- n,
- sizeof(*header->table),
- cmp_eh_frame_hdr_table_entries, swap_eh_frame_hdr_table_entries);
+ sort(header->table, n,
+ sizeof(*header->table), cmp_eh_frame_hdr_table_entries, NULL);
table->hdrsz = hdrSize;
smp_wmb();
--
2.21.0
^ permalink raw reply related
* [PATCH 3/5] ocfs2: dir, refcounttree, xattr: replace swap functions with built-in one
From: Andrey Abramov @ 2019-03-30 16:42 UTC (permalink / raw)
To: vgupta@synopsys.com, benh@kernel.crashing.org, paulus@samba.org,
mpe@ellerman.id.au, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, x86@kernel.org, mark@fasheh.com,
jlbec@evilplan.org, richard@nod.at, dedekind1@gmail.com,
adrian.hunter@intel.com, gregkh@linuxfoundation.org,
naveen.n.rao@linux.vnet.ibm.com, jpoimboe@redhat.com,
Dave Chinner, darrick.wong@oracle.com, ard.biesheuvel@linaro.org,
George Spelvin, linux-snps-arc@lists.infradead.org,
Linux Kernel Mailing List, linuxppc-dev@lists.ozlabs.org,
ocfs2-devel@oss.oracle.com, linux-mtd@lists.infradead.org,
sfr@canb.auug.org.au
Cc: mhocko@suse.com, gustavo@embeddedor.com, peterz@infradead.org,
amir73il@gmail.com, Rasmus Villemoes, kamalesh@linux.vnet.ibm.com,
piaojun@huawei.com, yamada.masahiro@socionext.com,
jiang.biao2@zte.com.cn, jslaby@suse.cz, yuehaibing@huawei.com,
rppt@linux.ibm.com, ge.changwei@h3c.com, keescook@chromium.org,
jannh@google.com, ashish.samant@oracle.com, npiggin@gmail.com,
jiangyiwen@huawei.com, Andy Shevchenko, lchen@suse.com,
malat@debian.org, Morton Andrew
In-Reply-To: <18626931553963861@sas1-b3ec53dbc12b.qloud-c.yandex.net>
Replace dx_leaf_sort_swap, swap_refcount_rec and swap_xe functions
with built-in one, because they do only a simple byte to byte swap.
Signed-off-by: Andrey Abramov <st5pub@yandex.ru>
---
fs/ocfs2/dir.c | 13 +------------
fs/ocfs2/refcounttree.c | 13 +++----------
fs/ocfs2/xattr.c | 15 +++------------
3 files changed, 7 insertions(+), 34 deletions(-)
diff --git a/fs/ocfs2/dir.c b/fs/ocfs2/dir.c
index c121abbdfc7d..4b86b181df0a 100644
--- a/fs/ocfs2/dir.c
+++ b/fs/ocfs2/dir.c
@@ -3529,16 +3529,6 @@ static int dx_leaf_sort_cmp(const void *a, const void *b)
return 0;
}
-static void dx_leaf_sort_swap(void *a, void *b, int size)
-{
- struct ocfs2_dx_entry *entry1 = a;
- struct ocfs2_dx_entry *entry2 = b;
-
- BUG_ON(size != sizeof(*entry1));
-
- swap(*entry1, *entry2);
-}
-
static int ocfs2_dx_leaf_same_major(struct ocfs2_dx_leaf *dx_leaf)
{
struct ocfs2_dx_entry_list *dl_list = &dx_leaf->dl_list;
@@ -3799,8 +3789,7 @@ static int ocfs2_dx_dir_rebalance(struct ocfs2_super *osb, struct inode *dir,
* This block is changing anyway, so we can sort it in place.
*/
sort(dx_leaf->dl_list.de_entries, num_used,
- sizeof(struct ocfs2_dx_entry), dx_leaf_sort_cmp,
- dx_leaf_sort_swap);
+ sizeof(struct ocfs2_dx_entry), dx_leaf_sort_cmp, NULL);
ocfs2_journal_dirty(handle, dx_leaf_bh);
diff --git a/fs/ocfs2/refcounttree.c b/fs/ocfs2/refcounttree.c
index 1dc9a08e8bdc..7bbc94d23a0c 100644
--- a/fs/ocfs2/refcounttree.c
+++ b/fs/ocfs2/refcounttree.c
@@ -1400,13 +1400,6 @@ static int cmp_refcount_rec_by_cpos(const void *a, const void *b)
return 0;
}
-static void swap_refcount_rec(void *a, void *b, int size)
-{
- struct ocfs2_refcount_rec *l = a, *r = b;
-
- swap(*l, *r);
-}
-
/*
* The refcount cpos are ordered by their 64bit cpos,
* But we will use the low 32 bit to be the e_cpos in the b-tree.
@@ -1482,7 +1475,7 @@ static int ocfs2_divide_leaf_refcount_block(struct buffer_head *ref_leaf_bh,
*/
sort(&rl->rl_recs, le16_to_cpu(rl->rl_used),
sizeof(struct ocfs2_refcount_rec),
- cmp_refcount_rec_by_low_cpos, swap_refcount_rec);
+ cmp_refcount_rec_by_low_cpos, NULL);
ret = ocfs2_find_refcount_split_pos(rl, &cpos, &split_index);
if (ret) {
@@ -1507,11 +1500,11 @@ static int ocfs2_divide_leaf_refcount_block(struct buffer_head *ref_leaf_bh,
sort(&rl->rl_recs, le16_to_cpu(rl->rl_used),
sizeof(struct ocfs2_refcount_rec),
- cmp_refcount_rec_by_cpos, swap_refcount_rec);
+ cmp_refcount_rec_by_cpos, NULL);
sort(&new_rl->rl_recs, le16_to_cpu(new_rl->rl_used),
sizeof(struct ocfs2_refcount_rec),
- cmp_refcount_rec_by_cpos, swap_refcount_rec);
+ cmp_refcount_rec_by_cpos, NULL);
*split_cpos = cpos;
return 0;
diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c
index 3a24ce3deb01..b3e6f42baf78 100644
--- a/fs/ocfs2/xattr.c
+++ b/fs/ocfs2/xattr.c
@@ -4175,15 +4175,6 @@ static int cmp_xe(const void *a, const void *b)
return 0;
}
-static void swap_xe(void *a, void *b, int size)
-{
- struct ocfs2_xattr_entry *l = a, *r = b, tmp;
-
- tmp = *l;
- memcpy(l, r, sizeof(struct ocfs2_xattr_entry));
- memcpy(r, &tmp, sizeof(struct ocfs2_xattr_entry));
-}
-
/*
* When the ocfs2_xattr_block is filled up, new bucket will be created
* and all the xattr entries will be moved to the new bucket.
@@ -4249,7 +4240,7 @@ static void ocfs2_cp_xattr_block_to_bucket(struct inode *inode,
trace_ocfs2_cp_xattr_block_to_bucket_end(offset, size, off_change);
sort(target + offset, count, sizeof(struct ocfs2_xattr_entry),
- cmp_xe, swap_xe);
+ cmp_xe, NULL);
}
/*
@@ -4444,7 +4435,7 @@ static int ocfs2_defrag_xattr_bucket(struct inode *inode,
*/
sort(entries, le16_to_cpu(xh->xh_count),
sizeof(struct ocfs2_xattr_entry),
- cmp_xe_offset, swap_xe);
+ cmp_xe_offset, NULL);
/* Move all name/values to the end of the bucket. */
xe = xh->xh_entries;
@@ -4486,7 +4477,7 @@ static int ocfs2_defrag_xattr_bucket(struct inode *inode,
/* sort the entries by their name_hash. */
sort(entries, le16_to_cpu(xh->xh_count),
sizeof(struct ocfs2_xattr_entry),
- cmp_xe, swap_xe);
+ cmp_xe, NULL);
buf = bucket_buf;
for (i = 0; i < bucket->bu_blocks; i++, buf += blocksize)
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 2/2] arch: add pidfd and io_uring syscalls everywhere
From: Michael Ellerman @ 2019-03-31 9:47 UTC (permalink / raw)
To: Arnd Bergmann, Andrew Morton
Cc: Rich Felker, linux-ia64, linux-sh, Heiko Carstens, linux-mips,
James E . J . Bottomley, Max Filippov, Paul Mackerras, sparclinux,
linux-s390, Helge Deller, Russell King, Geert Uytterhoeven,
Catalin Marinas, James Hogan, Firoz Khan, Matt Turner, Fenghua Yu,
Arnd Bergmann, Will Deacon, linux-m68k, Ivan Kokshaysky,
linux-arm-kernel, Richard Henderson, Michal Simek, Tony Luck,
linux-parisc, linux-kernel, Ralf Baechle, Paul Burton,
linux-alpha, Martin Schwidefsky, linuxppc-dev, David S . Miller
In-Reply-To: <20190325144737.703921-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> writes:
> Add the io_uring and pidfd_send_signal system calls to all architectures.
>
> These system calls are designed to handle both native and compat tasks,
> so all entries are the same across architectures, only arm-compat and
> the generic tale still use an old format.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/alpha/kernel/syscalls/syscall.tbl | 4 ++++
> arch/arm/tools/syscall.tbl | 4 ++++
> arch/arm64/include/asm/unistd.h | 2 +-
> arch/arm64/include/asm/unistd32.h | 8 ++++++++
> arch/ia64/kernel/syscalls/syscall.tbl | 4 ++++
> arch/m68k/kernel/syscalls/syscall.tbl | 4 ++++
> arch/microblaze/kernel/syscalls/syscall.tbl | 4 ++++
> arch/mips/kernel/syscalls/syscall_n32.tbl | 4 ++++
> arch/mips/kernel/syscalls/syscall_n64.tbl | 4 ++++
> arch/mips/kernel/syscalls/syscall_o32.tbl | 4 ++++
> arch/parisc/kernel/syscalls/syscall.tbl | 4 ++++
> arch/powerpc/kernel/syscalls/syscall.tbl | 4 ++++
Have you done any testing?
I'd rather not wire up syscalls that have never been tested at all on
powerpc.
cheers
^ permalink raw reply
* Question about Power8/9, PHB3/4 and setting of DMA mask
From: Oded Gabbay @ 2019-03-31 9:50 UTC (permalink / raw)
To: Christoph Hellwig, Russell Currey, linuxppc-dev
Hello,
I'm working in a startup called HabanaLabs, and we have an ASIC
accelerator for AI called Goya. It is assembled on a PCIe Gen4 card.
Driver is going to be in kernel 5.1
We are trying to plug the card into a Power8 machine and load the
driver, and we get a failure during the loading of the driver in
regard to the driver trying to set the DMA mask.
Due to some limitation in Goya, the driver first need to allocate a
2MB chunk in a DMA-able address under 39 bits and then we would like
to move to using up to 48 bits. Therefore, the driver first tries to
set the DMA mask to 39 bits, allocate the 2MB area and later on,
change the DMA mask to 48 bits. On x86 this works fine.
However, as I said, on Power8 we got a failure when trying to set to
39 bits. After tracking the code, I reached to this function:
pnv_pci_ioda_dma_set_mask()
In that function, there is a check (composed of 4 conditions) about
the requested dma mask, which appears that we fail and I suspect this
is due to the memory_hotplug_max() returning more then 39 bits.
My questions are:
1. Is this logic applies to Power9 as well ?
2. Why this condition is mandatory ? Is there some kind of workaround
available ?
Thanks in advance,
Oded
^ permalink raw reply
* Re: [PATCH stable v4.14 00/32] powerpc spectre backports for 4.14
From: Michael Ellerman @ 2019-03-31 9:53 UTC (permalink / raw)
To: Greg KH; +Cc: diana.craciun, linuxppc-dev, msuchanek, stable
In-Reply-To: <20190329150921.GA1002@kroah.com>
Greg KH <gregkh@linuxfoundation.org> writes:
> On Fri, Mar 29, 2019 at 03:51:16PM +0100, Greg KH wrote:
>> On Fri, Mar 29, 2019 at 10:25:48PM +1100, Michael Ellerman wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > Hi Greg,
>> >
>> > Please queue up these powerpc patches for 4.14 if you have no objections.
>>
>> Some of these also need to go to 4.19, right? Want me to add them
>> there, or are you going to provide a backported series?
Yes some of them do, but I wasn't sure if they'd go cleanly.
> Nevermind, I've queued up the missing ones to 4.19.y, and one missing
> one to 5.0.y. If I've missed anything, please let me know.
Thanks. I'll check everything's working as expected.
cheers
^ permalink raw reply
* Re: [RFC PATCH 1/3] powernv/mce: reduce mce console logs to lesser lines.
From: Michael Ellerman @ 2019-03-31 9:55 UTC (permalink / raw)
To: Mahesh Jagannath Salgaonkar, linuxppc-dev; +Cc: Paul Mackerras, Nicholas Piggin
In-Reply-To: <cdfb484e-0468-edb3-3d8f-306c50ddceca@linux.vnet.ibm.com>
Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com> writes:
> On 3/29/19 5:50 AM, Michael Ellerman wrote:
>> Hi Mahesh,
>>
>> Thanks for doing this series.
>>
>> Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> writes:
>>> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>>>
>>> Also add cpu number while displaying mce log. This will help cleaner logs
>>> when mce hits on multiple cpus simultaneously.
>>
>> Can you include some examples of the output before and after, so it's
>> easier to compare what the changes are.
...
>>
>> I also think it'd be clearer to print the NIP on the 2nd line in all
>> cases, rather than the first.
>
> Sure, and I will then put "machine check" on 1st line like below ?
>
> printk("%sMCE: CPU%d: machine check (%s) %s %s %s %s[%s]\n",
Yes that would be good. Thanks.
cheers
^ permalink raw reply
* Re: pseries/energy: Use OF accessor functions to read ibm, drc-indexes
From: Michael Ellerman @ 2019-03-31 10:13 UTC (permalink / raw)
To: Gautham R. Shenoy, Michael Bringmann, Benjamin Herrenschmidt,
Paul Mackerras, Vaidyanathan Srinivasan
Cc: Pavithra R. Prakash, linuxppc-dev, linux-kernel, stable,
Gautham R. Shenoy
In-Reply-To: <1552059204-18626-1-git-send-email-ego@linux.vnet.ibm.com>
On Fri, 2019-03-08 at 15:33:24 UTC, "Gautham R. Shenoy" wrote:
> From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
>
> In cpu_to_drc_index() in the case when FW_FEATURE_DRC_INFO is absent,
> we currently use of_read_property() to obtain the pointer to the array
> corresponding to the property "ibm,drc-indexes". The elements of this
> array are of type __be32, but are accessed without any conversion to
> the OS-endianness, which is buggy on a Little Endian OS.
>
> Fix this by using of_property_read_u32_index() accessor function to
> safely read the elements of the array.
>
> Fixes: commit e83636ac3334 ("pseries/drc-info: Search DRC properties for CPU indexes")
> Cc: <stable@vger.kernel.org> #v4.16+
> Reported-by: Pavithra R. Prakash <pavrampu@in.ibm.com>
> Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
> Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/ce9afe08e71e3f7d64f337a6e932e508
cheers
^ permalink raw reply
* Re: [v3] powerpc/64: Fix memcmp reading past the end of src/dest
From: Michael Ellerman @ 2019-03-31 10:13 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: chandan
In-Reply-To: <20190322123724.28435-1-mpe@ellerman.id.au>
On Fri, 2019-03-22 at 12:37:24 UTC, Michael Ellerman wrote:
> Chandan reported that fstests' generic/026 test hit a crash:
>
> BUG: Unable to handle kernel data access at 0xc00000062ac40000
> Faulting instruction address: 0xc000000000092240
> Oops: Kernel access of bad area, sig: 11 [#1]
> LE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries
> CPU: 0 PID: 27828 Comm: chacl Not tainted 5.0.0-rc2-next-20190115-00001-g6de6dba64dda #1
> NIP: c000000000092240 LR: c00000000066a55c CTR: 0000000000000000
> REGS: c00000062c0c3430 TRAP: 0300 Not tainted (5.0.0-rc2-next-20190115-00001-g6de6dba64dda)
> MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 44000842 XER: 20000000
> CFAR: 00007fff7f3108ac DAR: c00000062ac40000 DSISR: 40000000 IRQMASK: 0
> GPR00: 0000000000000000 c00000062c0c36c0 c0000000017f4c00 c00000000121a660
> GPR04: c00000062ac3fff9 0000000000000004 0000000000000020 00000000275b19c4
> GPR08: 000000000000000c 46494c4500000000 5347495f41434c5f c0000000026073a0
> GPR12: 0000000000000000 c0000000027a0000 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> GPR20: c00000062ea70020 c00000062c0c38d0 0000000000000002 0000000000000002
> GPR24: c00000062ac3ffe8 00000000275b19c4 0000000000000001 c00000062ac30000
> GPR28: c00000062c0c38d0 c00000062ac30050 c00000062ac30058 0000000000000000
> NIP memcmp+0x120/0x690
> LR xfs_attr3_leaf_lookup_int+0x53c/0x5b0
> Call Trace:
> xfs_attr3_leaf_lookup_int+0x78/0x5b0 (unreliable)
> xfs_da3_node_lookup_int+0x32c/0x5a0
> xfs_attr_node_addname+0x170/0x6b0
> xfs_attr_set+0x2ac/0x340
> __xfs_set_acl+0xf0/0x230
> xfs_set_acl+0xd0/0x160
> set_posix_acl+0xc0/0x130
> posix_acl_xattr_set+0x68/0x110
> __vfs_setxattr+0xa4/0x110
> __vfs_setxattr_noperm+0xac/0x240
> vfs_setxattr+0x128/0x130
> setxattr+0x248/0x600
> path_setxattr+0x108/0x120
> sys_setxattr+0x28/0x40
> system_call+0x5c/0x70
> Instruction dump:
> 7d201c28 7d402428 7c295040 38630008 38840008 408201f0 4200ffe8 2c050000
> 4182ff6c 20c50008 54c61838 7d201c28 <7d402428> 7d293436 7d4a3436 7c295040
>
> The instruction dump decodes as:
> subfic r6,r5,8
> rlwinm r6,r6,3,0,28
> ldbrx r9,0,r3
> ldbrx r10,0,r4 <-
>
> Which shows us doing an 8 byte load from c00000062ac3fff9, which
> crosses the page boundary at c00000062ac40000 and faults.
>
> It's not OK for memcmp to read past the end of the source or
> destination buffers if that would cross a page boundary, because we
> don't know that the next page is mapped.
>
> As pointed out by Segher, we can read past the end of the source or
> destination as long as we don't cross a 4K boundary, because that's
> our minimum page size on all platforms.
>
> The bug is in the code at the .Lcmp_rest_lt8bytes label. When we get
> there we know that s1 is 8-byte aligned and we have at least 1 byte to
> read, so a single 8-byte load won't read past the end of s1 and cross
> a page boundary.
>
> But we have to be more careful with s2. So check if it's within 8
> bytes of a 4K boundary and if so go to the byte-by-byte loop.
>
> Fixes: 2d9ee327adce ("powerpc/64: Align bytes before fall back to .Lshort in powerpc64 memcmp()")
> Cc: stable@vger.kernel.org # v4.19+
> Reported-by: Chandan Rajendra <chandan@linux.ibm.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
> Tested-by: Chandan Rajendra <chandan@linux.ibm.com>
> Tested-by: Chandan Rajendra <chandan@linux.ibm.com>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/d9470757398a700d9450a43508000bcf
cheers
^ permalink raw reply
* Re: powerpc/pseries/mce: fix misleading print for TLB mutlihit.
From: Michael Ellerman @ 2019-03-31 10:13 UTC (permalink / raw)
To: Mahesh J Salgaonkar, linuxppc-dev
Cc: Aneesh Kumar K.V, stable, Nicholas Piggin
In-Reply-To: <155360342407.7831.11678112859745188108.stgit@jupiter>
On Tue, 2019-03-26 at 12:30:31 UTC, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> On pseries, TLB multihit are reported as D-Cache Multihit. This is because
> the wrongly populated mc_err_types[] array. Per PAPR, TLB error type is 0x04
> and mc_err_types[4] points to "D-Cache" instead of "TLB" string. Fixup the
> mc_err_types[] array.
>
> Machine check error type per PAPR:
> 0x00 = Uncorrectable Memory Error (UE)
> 0x01 = SLB error
> 0x02 = ERAT Error
> 0x04 = TLB error
> 0x05 = D-Cache error
> 0x07 = I-Cache error
>
> Fixes: 8f0b80561f21 ("powerpc/pseries: Display machine check error details.")
> Cc: <stable@vger.kernel.org> # v4.19+
> Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/6f845ebec2706841d15831fab3ffffcf
cheers
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.1-4 tag
From: Michael Ellerman @ 2019-03-31 10:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: ego, linuxppc-dev, linux-kernel, mahesh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Linus,
Please pull some more powerpc fixes for 5.1:
The following changes since commit 8c2ffd9174779014c3fe1f96d9dc3641d9175f00:
Linux 5.1-rc2 (2019-03-24 14:02:26 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.1-4
for you to fetch changes up to 6f845ebec2706841d15831fab3ffffcfd9e676fa:
powerpc/pseries/mce: Fix misleading print for TLB mutlihit (2019-03-29 16:59:19 +1100)
- ------------------------------------------------------------------
powerpc fixes for 5.1 #4
Three non-regression fixes.
Our optimised memcmp could read past the end of one of the buffers and
potentially trigger a page fault leading to an oops.
Some of our code to read energy management data on PowerVM had an endian bug
leading to bogus results.
When reporting a machine check exception we incorrectly reported TLB multihits
as D-Cache multhits due to a missing entry in the array of causes.
Thanks to:
Chandan Rajendra, Gautham R. Shenoy, Mahesh Salgaonkar, Segher Boessenkool,
Vaidyanathan Srinivasan.
- ------------------------------------------------------------------
Gautham R. Shenoy (1):
powerpc/pseries/energy: Use OF accessor functions to read ibm,drc-indexes
Mahesh Salgaonkar (1):
powerpc/pseries/mce: Fix misleading print for TLB mutlihit
Michael Ellerman (1):
powerpc/64: Fix memcmp reading past the end of src/dest
arch/powerpc/lib/memcmp_64.S | 17 ++++++++++++----
arch/powerpc/platforms/pseries/pseries_energy.c | 27 ++++++++++++++++---------
arch/powerpc/platforms/pseries/ras.c | 1 +
3 files changed, 32 insertions(+), 13 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJcoJWZAAoJEFHr6jzI4aWAM9sQAKzbaBFGhm+08w75Cz36I5zo
3gWG24Zzj7r2/wZfSaKIRSIKm1UvNjmhDWiQprkgVsQOScSwxfnwE9lkrGfGCFX8
eiIzNJFnCOg1ZBLfJFh/9yzWwfHiR57IqcN4lD8oAMLYVHR7JKJjA5vfTt8JxtUn
Z58im6uLgSdMnwvSJ3Wg5Oq4SX88cLsCUyQ9Mm5X0HY4LUrxboN6ofQkUj4AH55V
RG3+Z5WKoK0vQEkUrRREHpmjMB2e/fdaMULEjCLnAErU3Ip2Ku6nKZMHH3pZMC6Q
2yi2bMwXdWK9CH3lW7Q88EIGI7MYixLpLdxTedcqSI6meZaGaHAQJJEQySriPOt4
ArN5nfcfewDU9G+aT9up8JcdbBBJDvJ/ZKngPpZYQVszndwP9/O6Yv8digrckYcH
RAkd1kw8jHK1t45Z4bUU63hMhHmHuKagjlarSoorQg2s9i65y+56oCryXQbn52cc
blwI3O5/6ziLPiuJ76TpvVmUk1S4qL+KkFcDN6GOBUylZtcMfFoaq2vnDKrLwgkC
h1PfYLRqtwgAtY5Y8XKCEAkcT0W+qcr0O2jLM7CdNkm46dtV00E47GskfHzLf9Pi
1QleOgkcb/Ki9S+UsxWHedFGDmlxgv8MzIfyy8lQmdV1lz6gyliYKBSbZfAltCGu
b/zixlcVsA06NbDTPsya
=LkP1
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.1-4 tag
From: pr-tracker-bot @ 2019-03-31 16:00 UTC (permalink / raw)
To: Michael Ellerman; +Cc: ego, linuxppc-dev, Linus Torvalds, linux-kernel, mahesh
In-Reply-To: <87pnq7l4qn.fsf@concordia.ellerman.id.au>
The pull request you sent on Sun, 31 Mar 2019 21:26:08 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.1-4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6536c5f2c8cf79db0d37e79afcdb227dc854509c
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
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