Re: [PATCH V4 1/3] virtio: don't prompt CONFIG_VIRTIO_PCI_MODERN

2021-02-23 Thread Daniel Díaz
Hello!

If I may add to the nit-picking...

On Tue, 23 Feb 2021 at 09:23, Guenter Roeck  wrote:
> On 2/22/21 10:19 PM, Jason Wang wrote:
> > We used to prompt CONFIG_VIRTIO_PCI_MODERN to user which may bring a
> > lot of confusion. E.g it may break various default configs which want
> > virtio devices.
> >
> > So this patch fixes this by hiding the prompot and documenting the

*prompt

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH] scripts: Fix linking extract-cert against libcrypto

2021-02-16 Thread Daniel Díaz
Hello!


On Fri, 12 Feb 2021 at 01:44, Rolf Eike Beer  wrote:
>
> Am Donnerstag, 11. Februar 2021, 11:29:33 CET schrieb Rolf Eike Beer:
>
> > I'm just guessing, but your build error looks like you are also
> > cross-building the tools, which is wrong. You want them to be host-tools.
> > So don't export PKG_CONFIG_SYSROOT_DIR, it would then try to link target
> > libraries into a host binary.
>
> I have looked again how I do it:
>
> # this is for additional _host_ .pc files
> export PKG_CONFIG_PATH=${prefix}/lib/pkgconfig
>
> Then have a target-pkg-config, so this code inside several kernel Makefiles
> will work:
>
> PKG_CONFIG ?= $(CROSS_COMPILE)pkg-config
>
> And then export your PKG_CONFIG_SYSROOT_DIR and the like inside that. I bet
> you have all of this already in place, so just remove the SYSROOT_DIR from
> your kernel build script and things should work.

Thank you for your comments! I will try this in our environment in the
upcoming days.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH] scripts: Fix linking extract-cert against libcrypto

2021-02-16 Thread Daniel Díaz
Hello!

Apologies for the delay -- Currently experiencing power/connectivity issues.


On Thu, 11 Feb 2021 at 01:12, Masahiro Yamada  wrote:
> I am wondering how "HOSTLDFLAGS_sign-file" and
> "HOSTLDFLAGS_extract-cert" worked for you.
> Kbuild supports HOSTLDLIBS_ syntax,
> but not HOSTLDFLAGS_.

Thanks for the insight! The pointer you have provided are very
valuable to try to fix our problem.

What effectively happened was that LDFLAGS was removed, and therefore
the gcc line did not include one -L path that's proving difficult to
use under OpenEmbedded cross-compilations. This discussion has
provided much light in areas that are unknown to me, but so far it
looks like the fix will need to happen in the OE recipe and not in the
kernel itself.

Thanks and greetings!

Daniel Díaz
daniel.d...@linaro.org



> I see $(HOSTLDLIBS_$(target-stem) in scripts/Makefile.host
> but failed to find $(HOSTLDFLAGS_$(target-stem)).
>
> So, presumably you will get the same result
> (OE build error will be fixed)
> even without HOSTLDFLAGS_sign-file
> or HOSTLDFLAGS_extract-cert.
>
>
>
> But, I am still wondering what the correct approach is.
>
>
>
> Basically, there are two ways to link libraries
> in non-standard paths.
>
>
>
> [1] Give linker flags via HOSTLDFLAGS
>
>This is documented in Documentation/kbuild/kbuild.rst
>
>HOSTLDFLAGS
>---
>Additional flags to be passed when linking host programs.
>
>
>
>
> [2] Use pkg-config
>
>
>
>
>
>
> OE already adopted [1].
>
> I think the following long lines came from HOSTLDFLAGS.
>
> 
> -isystem/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/include
> \
> -O2 -pipe 
> -L/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/lib
> \
> 
> -L/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/lib
> \
> 
> -Wl,-rpath-link,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/lib
> \
> 
> -Wl,-rpath-link,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/lib
> \
> 
> -Wl,-rpath,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/lib
> \
> 
> -Wl,-rpath,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/lib
> \
> -Wl,-O1 
> -I/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/include
> \
> -I ./scripts -o scripts/extract-cert \
>
>
>
>
> But, some people are not satisfied with [1] (or do not notice it)?
>
>
> Then, 2cea4a7a1885 introduced the second one [2].
>
> Mixing [1] and [2] perhaps confuses the build system somehow?
>
>
>
>
> So, 2cea4a7a1885 was a problem, but
> I do not think this patch is the right one either.
>
> (At least, HOSTLDFLAGS_* additions are pointless)
>
>
>
>
> --
> Best Regards
> Masahiro Yamada


[PATCH] scripts: Fix linking extract-cert against libcrypto

2021-02-08 Thread Daniel Díaz
When compiling under OpenEmbedded, the following error is seen
as of recently:

  /srv/oe/build/tmp/hosttools/ld: cannot find /lib/libc.so.6 inside /
  /srv/oe/build/tmp/hosttools/ld: cannot find /usr/lib/libc_nonshared.a inside /
  /srv/oe/build/tmp/hosttools/ld: cannot find /lib/ld-linux-x86-64.so.2 inside /
  collect2: error: ld returned 1 exit status
  make[2]: *** [scripts/Makefile.host:95: scripts/extract-cert] Error 1

This is because 2cea4a7a1885 ("scripts: use pkg-config to
locate libcrypto") now calls for `pkg-config --libs libcrypto`
and inserts that into the Makefile rules as LDLIBS when
building extract-cert.c.

The problem is that --libs will include both -l and -L, which
will be out of order when compiling/linking.

This (very ugly) command is what's produced with OpenEmbedded:

  gcc -Wp,-MMD,scripts/.extract-cert.d -Wall -Wmissing-prototypes 
-Wstrict-prototypes \
-O2 -fomit-frame-pointer -std=gnu89 \

-isystem/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/include
 \
-O2 -pipe 
-L/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/lib
 \

-L/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/lib
 \

-Wl,-rpath-link,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/lib
 \

-Wl,-rpath-link,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/lib
 \

-Wl,-rpath,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/lib
 \

-Wl,-rpath,/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/lib
 \
-Wl,-O1 
-I/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot-native/usr/include
 \
-I ./scripts -o scripts/extract-cert \

/oe/build/tmp/work-shared/intel-corei7-64/kernel-source/scripts/extract-cert.c \

-L/oe/build/tmp/work/MACHINE/linux/5.10+gitAUTOINC+b01f250d83-r0/recipe-sysroot/usr//lib
 \
-lcrypto

As per `make`'s documentation:

  LDFLAGS
Extra flags to give to compilers when they are supposed to
invoke the linker, ‘ld’, such as -L. Libraries (-lfoo)
should be added to the LDLIBS variable instead.

  LDLIBS
Library flags or names given to compilers when they are
supposed to invoke the linker, ‘ld’. LOADLIBES is a
deprecated (but still supported) alternative to LDLIBS.
Non-library linker flags, such as -L, should go in the
LDFLAGS variable.

Fixes: 2cea4a7a1885 ("scripts: use pkg-config to locate libcrypto")
Cc: sta...@vger.kernel.org # 5.6.x
Reported-by: Naresh Kamboju 
Signed-off-by: Daniel Díaz 
---
 scripts/Makefile | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/scripts/Makefile b/scripts/Makefile
index 9de3c03b94aa..4b4e938b4ba7 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -3,7 +3,8 @@
 # scripts contains sources for various helper programs used throughout
 # the kernel for the build process.
 
-CRYPTO_LIBS = $(shell pkg-config --libs libcrypto 2> /dev/null || echo 
-lcrypto)
+CRYPTO_LDFLAGS = $(shell pkg-config --libs-only-L libcrypto 2> /dev/null)
+CRYPTO_LDLIBS = $(shell pkg-config --libs-only-l libcrypto 2> /dev/null || 
echo -lcrypto)
 CRYPTO_CFLAGS = $(shell pkg-config --cflags libcrypto 2> /dev/null)
 
 hostprogs-always-$(CONFIG_BUILD_BIN2C) += bin2c
@@ -17,9 +18,11 @@ hostprogs-always-$(CONFIG_SYSTEM_EXTRA_CERTIFICATE)  += 
insert-sys-cert
 
 HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include
 HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include
-HOSTLDLIBS_sign-file = $(CRYPTO_LIBS)
+HOSTLDFLAGS_sign-file = $(CRYPTO_LDFLAGS)
+HOSTLDLIBS_sign-file = $(CRYPTO_LDLIBS)
 HOSTCFLAGS_extract-cert.o = $(CRYPTO_CFLAGS)
-HOSTLDLIBS_extract-cert = $(CRYPTO_LIBS)
+HOSTLDFLAGS_extract-cert = $(CRYPTO_LDFLAGS)
+HOSTLDLIBS_extract-cert = $(CRYPTO_LDLIBS)
 
 ifdef CONFIG_UNWINDER_ORC
 ifeq ($(ARCH),x86_64)
-- 
2.25.1



Re: [PATCH 5.10 000/199] 5.10.11-rc1 review

2021-01-25 Thread Daniel Díaz

Hello!


On 1/25/21 12:37 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.10.11 release.
There are 199 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed, 27 Jan 2021 18:31:44 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.11-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.10.y
and the diffstat can be found below.

thanks,

greg k-h


Sanity results from Linaro’s test farm.
Regressions detected.

Summary


kernel: 5.10.11-rc1
git repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
git branch: linux-5.10.y
git commit: efec2624e657b370b1621e8514a1fa6d65eb20a0
git describe: v5.10.10-200-gefec2624e657
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y-sanity/build/v5.10.10-200-gefec2624e657

Regressions (compared to build v5.10.10)


x86_64:
  build:
* clang-10-allnoconfig
* clang-10-tinyconfig
* gcc-8-allnoconfig
* gcc-8-tinyconfig
* gcc-9-allnoconfig
* gcc-9-tinyconfig
* gcc-10-allnoconfig
* gcc-10-tinyconfig

i386:
  build:
* clang-10-allnoconfig
* clang-10-tinyconfig
* clang-11-allnoconfig
* clang-11-tinyconfig
* gcc-8-allnoconfig
* gcc-8-tinyconfig
* gcc-9-allnoconfig
* gcc-9-tinyconfig
* gcc-10-allnoconfig
* gcc-10-tinyconfig


No fixes (compared to build v5.10.10)

Ran 704 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- i386
- juno-r2
- mips
- parisc
- powerpc
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86_64

Test Suites
---
* build
* linux-log-parser
* ltp-smoketest-tests


Errors look like the following:

  make --silent --keep-going --jobs=8 
O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=x86_64 
CROSS_COMPILE=x86_64-linux-gnu- 'CC=sccache x86_64-linux-gnu-gcc' 
'HOSTCC=sccache gcc'
  /builds/1nZbYji0zW0SkEnWMrDznWWzerI/arch/x86/kernel/cpu/amd.c: In function 
'bsp_init_amd':
  /builds/1nZbYji0zW0SkEnWMrDznWWzerI/arch/x86/kernel/cpu/amd.c:572:3: error: 
'__max_die_per_package' undeclared (first use in this function); did you mean 
'topology_max_die_per_package'?
572 |   __max_die_per_package = nodes_per_socket = ((ecx >> 8) & 7) + 1;
|   ^
|   topology_max_die_per_package

Will find out more soon.

Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 5.4 00/86] 5.4.93-rc1 review

2021-01-25 Thread Daniel Díaz

Hello!

On 1/25/21 12:38 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.4.93 release.
There are 86 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed, 27 Jan 2021 18:31:44 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.93-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.4.y
and the diffstat can be found below.

thanks,

greg k-h


Sanity results from Linaro’s test farm.
Regressions detected.

Summary


kernel: 5.4.93-rc1
git repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
git branch: linux-5.4.y
git commit: 3deaa28e41d9780b3b462686a676fa1d21f55ad3
git describe: v5.4.92-87-g3deaa28e41d9
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y-sanity/build/v5.4.92-87-g3deaa28e41d9

Regressions (compared to build v5.4.92)


x86_64:
  build:
* clang-10-allnoconfig
* clang-10-tinyconfig
* gcc-8-allnoconfig
* gcc-8-tinyconfig
* gcc-9-allnoconfig
* gcc-9-tinyconfig
* gcc-10-allnoconfig
* gcc-10-tinyconfig

riscv:
  build:
* clang-10-defconfig
* clang-11-defconfig
* gcc-8-defconfig
* gcc-9-defconfig
* gcc-10-defconfig

i386:
  build:
* gcc-8-allnoconfig
* gcc-8-tinyconfig
* gcc-9-allnoconfig
* gcc-9-tinyconfig
* gcc-10-allnoconfig
* gcc-10-tinyconfig


No fixes (compared to build v5.4.92)

Ran 665 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- i386
- juno-r2
- mips
- parisc
- powerpc
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86_64

Test Suites
---
* build
* linux-log-parser
* ltp-smoketest-tests


i386 and x86_64 errors as reported on 5.10. Additionally, RISC-V errors look 
like this:

  make --silent --keep-going --jobs=8 
O=/home/tuxbuild/.cache/tuxmake/builds/1/tmp ARCH=riscv 
CROSS_COMPILE=riscv64-linux-gnu- 'CC=sccache riscv64-linux-gnu-gcc' 
'HOSTCC=sccache gcc'
  Error: 
/builds/1nZcZgrKHH9C31BJVZOjOhHXH0s/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts:88.27-28
 syntax error
  FATAL ERROR: Unable to parse input tree
  make[3]: *** [scripts/Makefile.lib:285: 
arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb] Error 1
  make[3]: Target '__build' not remade because of errors.
  make[2]: *** [/builds/1nZcZgrKHH9C31BJVZOjOhHXH0s/scripts/Makefile.build:496: 
arch/riscv/boot/dts/sifive] Error 2
  make[2]: Target '__build' not remade because of errors.
  make[1]: *** [/builds/1nZcZgrKHH9C31BJVZOjOhHXH0s/Makefile:1272: dtbs] Error 2

We'll try to get more info.

Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.19 00/29] 4.19.165-rc2 review

2021-01-05 Thread Daniel Díaz

Hello!

On 1/5/21 3:28 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.19.165 release.
There are 29 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu, 07 Jan 2021 09:08:03 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.165-rc2.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 4.19.165-rc2
git repo: 
['https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git', 
'https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc']
git branch: linux-4.19.y
git commit: 40a2b34effd3cc1b96cad6ef78e18879d4145c09
git describe: v4.19.164-30-g40a2b34effd3
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.164-30-g40a2b34effd3


No regressions (compared to build v4.19.164)

No fixes (compared to build v4.19.164)

Ran 40433 total tests in the following environments and test suites.

Environments
--
- arm
- arm64
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- mips
- nxp-ls2088
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- s390
- sparc
- x15 - arm
- x86_64
- x86-kasan

Test Suites
---
* build
* fwts
* install-android-platform-tools-r2600
* kselftest
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance

Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 5.4 00/47] 5.4.87-rc1 review

2021-01-04 Thread Daniel Díaz

Hello!

On 1/4/21 9:56 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.4.87 release.
There are 47 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed, 06 Jan 2021 15:56:52 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.87-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.4.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions detected.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 5.4.87-rc1
git repo: 
['https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git', 
'https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc']
git branch: linux-5.4.y
git commit: 01678c93fa9e3da85a53deb1510c25fdcd2e5d6d
git describe: v5.4.86-48-g01678c93fa9e
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.86-48-g01678c93fa9e

No regressions (compared to build v5.4.86)

No fixes (compared to build v5.4.86)

Ran 48522 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan

Test Suites
---
* build
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance


Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 5.10 00/63] 5.10.5-rc1 review

2021-01-04 Thread Daniel Díaz

Hello!

On 1/4/21 9:56 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.10.5 release.
There are 63 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed, 06 Jan 2021 15:56:52 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.5-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.10.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions detected.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 5.10.5-rc1
git repo: 
['https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git', 
'https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc']
git branch: linux-5.10.y
git commit: 18347c4f07814f2fef15f3b1518b6b8a88bae75a
git describe: v5.10.4-64-g18347c4f0781
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.4-64-g18347c4f0781

No regressions (compared to build v5.10.4)

No fixes (compared to build v5.10.4)

Ran 53801 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan

Test Suites
---
* build
* fwts
* igt-gpu-tools
* install-android-platform-tools-r2600
* kselftest
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance


Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.19 00/35] 4.19.165-rc1 review

2021-01-04 Thread Daniel Díaz
Hello!

On Mon, 4 Jan 2021 at 09:58, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.19.165 release.
> There are 35 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed, 06 Jan 2021 15:56:52 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.165-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman 
> Linux 4.19.165-rc1
[...]
> Peter Zijlstra 
> mm/mmu_gather: invalidate TLB correctly on batch allocation failure and 
> flush
[...]

This one fails to compile on the X15 (arm 32-bits) with:
| /srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/mm/memory.c:
In function 'tlb_table_invalidate':
| 
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/mm/memory.c:342:6:
error: implicit declaration of function 'tlb_needs_table_invalidate';
did you mean 'tlb_table_invalidate'?
[-Werror=implicit-function-declaration]
|   if (tlb_needs_table_invalidate()) {
|   ^~
|   tlb_table_invalidate

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH 5.4 000/450] 5.4.86-rc2 review

2020-12-29 Thread Daniel Díaz

Hello!

On 12/29/20 4:53 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.4.86 release.
There are 450 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu, 31 Dec 2020 10:36:29 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.86-rc2.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.4.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions detected.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 5.4.86-rc2
git repo: 
['https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git', 
'https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc']
git branch: linux-5.4.y
git commit: d797ea26c4313e38eb3eaddba53ae3316eae7a98
git describe: v5.4.85-451-gd797ea26c431
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.85-451-gd797ea26c431

No regressions (compared to build v5.4.85)

No fixes (compared to build v5.4.85)

Ran 43508 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-kasan
- mips
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan

Test Suites
---
* build
* fwts
* install-android-platform-tools-r2600
* kselftest
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance


Happy new year, greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 5.10 000/716] 5.10.4-rc2 review

2020-12-29 Thread Daniel Díaz

Hello!

On 12/29/20 4:52 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.10.4 release.
There are 716 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu, 31 Dec 2020 10:36:33 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.4-rc2.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.10.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions detected.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 5.10.4-rc2
git repo: 
['https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git', 
'https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc']
git branch: linux-5.10.y
git commit: 5069132d06b7c5d706b4ef9147aba5f6de422a9b
git describe: v5.10.3-717-g5069132d06b7
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.3-717-g5069132d06b7

No regressions (compared to build v5.10.3)

No fixes (compared to build v5.10.3)

Ran 53358 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan

Test Suites
---
* build
* fwts
* install-android-platform-tools-r2600
* kselftest
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance


Happy new year, greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 5.10 00/40] 5.10.3-rc1 review

2020-12-23 Thread Daniel Díaz

Hello!

On 12/23/20 9:33 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.10.3 release.
There are 40 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Fri, 25 Dec 2020 15:05:02 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.3-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.10.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing 

Summary


kernel: 5.10.3-rc1
git repo: 
['https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git', 
'https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc']
git branch: linux-5.10.y
git commit: a5ba578b52286e2a855f6b172c851d7afbf68e60
git describe: v5.10.2-41-ga5ba578b5228
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.2-41-ga5ba578b5228

No regressions (compared to build v5.10.2)

No fixes (compared to build v5.10.2)

Ran 50032 total tests in the following environments and test suites.

Environments
--
- arc
- arm
- arm64
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- mips
- parisc
- powerpc
- qemu-arm-clang
- qemu-arm64-clang
- qemu-arm64-kasan
- qemu-i386-clang
- qemu-x86_64-clang
- qemu-x86_64-kasan
- qemu-x86_64-kcsan
- qemu_arm
- qemu_arm64
- qemu_arm64-compat
- qemu_i386
- qemu_x86_64
- qemu_x86_64-compat
- riscv
- s390
- sh
- sparc
- x15
- x86
- x86-kasan

Test Suites
---
* build
* fwts
* install-android-platform-tools-r2600
* kselftest
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* kunit
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* perf
* rcutorture
* v4l2-compliance

Happy holidays, greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.4 000/112] 4.4.241-rc1 review

2020-10-28 Thread Daniel Díaz
Hello!

On Wed, 28 Oct 2020 at 13:46, Guenter Roeck  wrote:
> On Wed, Oct 28, 2020 at 10:06:21AM -0700, Guenter Roeck wrote:
> > On Tue, Oct 27, 2020 at 02:48:30PM +0100, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.4.241 release.
> > > There are 112 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Thu, 29 Oct 2020 13:48:36 +.
> > > Anything received after that time might be too late.
> > >
> >
> > Build results:
> >   total: 165 pass: 165 fail: 0
> > Qemu test results:
> >   total: 332 pass: 332 fail: 0
> >
>
> Did anyone receive the original e-mail ? Looks like I have been tagged as
> spammer, and I am having trouble sending e-mails.

If the original is from 3.5 hours ago, yeah, we got it. I'm not seeing
lore updated, but that's probably another issue.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


kvm: x86-32 fails to link with tdp_mmu

2020-10-23 Thread Daniel Díaz
Hello!

We found the following problem building torvalds/master, which
recently merged the for-linus tag from the KVM tree, when building
with gcc 7.3.0 and glibc 2.27 for x86 32-bits under OpenEmbedded:

|   LD  vmlinux.o
|   MODPOST vmlinux.symvers
|   MODINFO modules.builtin.modinfo
|   GEN modules.builtin
|   LD  .tmp_vmlinux.kallsyms1
| arch/x86/kvm/mmu/tdp_mmu.o: In function `__handle_changed_spte':
| tdp_mmu.c:(.text+0x78a): undefined reference to `__umoddi3'
| 
/srv/oe/build/tmp-lkft-glibc/work-shared/intel-core2-32/kernel-source/Makefile:1164:
recipe for target 'vmlinux' failed
| make[1]: *** [vmlinux] Error 1
| 
/srv/oe/build/tmp-lkft-glibc/work-shared/intel-core2-32/kernel-source/Makefile:185:
recipe for target '__sub-make' failed
| make: *** [__sub-make] Error 2

This builds fine for x86 (64 bits) and arm (32/64 bits) with the same
toolchain. This also builds correctly (outside OpenEmbedded) with
gcc-8, gcc-9 and gcc-10 for: x86 (32/64 bits), arm (32/64 bits), MIPS,
and RISCV; and gcc-8 and gcc-9 for ARC.

We first noticed this when 0adc313c4f20 was pushed, but reverting
f9a705ad1c07 ("Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/virt/kvm/kvm") brought it back into
building.

A follow-up bisection led to faaf05b00aec ("kvm: x86/mmu: Support
zapping SPTEs in the TDP MMU"). In that commit, the problematic code
was:

handle_changed_spte(kvm, as_id, iter->gfn, iter->old_spte, new_spte,
iter->level);

which was later changed by f8e144971c68 ("kvm: x86/mmu: Add access
tracking for tdp_mmu") to:

__handle_changed_spte(kvm, as_id, iter->gfn, iter->old_spte, new_spte,
      iter->level);

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [LTP] mmstress[1309]: segfault at 7f3d71a36ee8 ip 00007f3d77132bdf sp 00007f3d71a36ee8 error 4 in libc-2.27.so[7f3d77058000+1aa000]

2020-10-22 Thread Daniel Díaz
Hello!

On Thu, 22 Oct 2020 at 19:11, Linus Torvalds
 wrote:
> On Thu, Oct 22, 2020 at 4:43 PM Linus Torvalds
> Would you mind sending me the problematic vmlinux file in private (or,
> likely better - a pointer to some place I can download it, it's going
> to be huge).

The kernel Naresh originally referred to is here:
  https://builds.tuxbuild.com/SCI7Xyjb7V2NbfQ2lbKBZw/

Greetings!

Daniel Díaz
daniel.d...@linaro.org


[tip: x86/urgent] x86/defconfigs: Explicitly unset CONFIG_64BIT in i386_defconfig

2020-09-09 Thread tip-bot2 for Daniel Díaz
The following commit has been merged into the x86/urgent branch of tip:

Commit-ID: 76366050eb1b3151c4b4110c76538ff14dffb74c
Gitweb:
https://git.kernel.org/tip/76366050eb1b3151c4b4110c76538ff14dffb74c
Author:Daniel Díaz 
AuthorDate:Wed, 19 Aug 2020 12:32:24 -05:00
Committer: Ingo Molnar 
CommitterDate: Wed, 09 Sep 2020 10:03:37 +02:00

x86/defconfigs: Explicitly unset CONFIG_64BIT in i386_defconfig

A recent refresh of the defconfigs got rid of the following
(unset) config:

  # CONFIG_64BIT is not set

Innocuous as it seems, when the config file is saved again the
behavior is changed so that CONFIG_64BIT=y.

Currently,

  $ make i386_defconfig
  $ grep CONFIG_64BIT .config
  CONFIG_64BIT=y

whereas previously (and with this patch):

  $ make i386_defconfig
  $ grep CONFIG_64BIT .config
  # CONFIG_64BIT is not set

( This was found with weird compiler errors on OpenEmbedded
  builds, as the compiler was unable to cope with 64-bits data
  types. )

Fixes: 1d0e12fd3a84 ("x86/defconfigs: Refresh defconfig files")
Reported-by: Jarkko Nikula 
Reported-by: Andy Shevchenko 
Tested-by: Sedat Dilek 
Signed-off-by: Daniel Díaz 
Signed-off-by: Ingo Molnar 
---
 arch/x86/configs/i386_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index d7577fe..4cfdf57 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -19,6 +19,7 @@ CONFIG_CGROUP_CPUACCT=y
 CONFIG_BLK_DEV_INITRD=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_PROFILING=y
+# CONFIG_64BIT is not set
 CONFIG_SMP=y
 CONFIG_X86_GENERIC=y
 CONFIG_HPET_TIMER=y


[PATCH v2] x86/defconfigs: Explicitly unset CONFIG_64BIT in i386_defconfig

2020-08-19 Thread Daniel Díaz
A recent refresh of the defconfigs got rid of the following
(unset) config:

  # CONFIG_64BIT is not set

Innocuous as it seems, when the config file is saved again the
behavior is changed so that CONFIG_64BIT=y.

Currently,

  $ make i386_defconfig
  $ grep CONFIG_64BIT .config
  CONFIG_64BIT=y

whereas previously (and with this patch):

  $ make i386_defconfig
  $ grep CONFIG_64BIT .config
  # CONFIG_64BIT is not set

This was found with weird compiler errors on OpenEmbedded
builds, as the compiler was unable to cope with 64-bits data
types:

  NOTE: make -j1 bzImage CC=i686-linaro-linux-gcc  -fuse-ld=bfd 
-fdebug-prefix-map=/oe/build/tmp/work/intel_core2_32-linaro-linux/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0=/usr/src/debug/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0
 
-fdebug-prefix-map=/oe/build/tmp/work/intel_core2_32-linaro-linux/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0/recipe-sysroot=
 
-fdebug-prefix-map=/oe/build/tmp/work/intel_core2_32-linaro-linux/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0/recipe-sysroot-native=
  
-fdebug-prefix-map=/oe/build/tmp/work-shared/intel-core2-32/kernel-source=/usr/src/kernel
 
-ffile-prefix-map=/oe/build/tmp/work/intel_core2_32-linaro-linux/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0/git=/kernel-source/
  LD=i686-linaro-linux-ld.bfd
GEN Makefile
CC  scripts/mod/empty.o
  cc1: error: code model 'kernel' not supported in the 32 bit mode
  cc1: sorry, unimplemented: 64-bit mode not compiled in
  
/oe/build/tmp/work-shared/intel-core2-32/kernel-source/scripts/Makefile.build:280:
 recipe for target 'scripts/mod/empty.o' failed
  make[2]: *** [scripts/mod/empty.o] Error 1
  /oe/build/tmp/work-shared/intel-core2-32/kernel-source/Makefile:1174: recipe 
for target 'prepare0' failed
  make[1]: *** [prepare0] Error 2
  /oe/build/tmp/work-shared/intel-core2-32/kernel-source/Makefile:185: recipe 
for target '__sub-make' failed
  make: *** [__sub-make] Error 2

Fixes: 1d0e12fd3a84 ("x86/defconfigs: Refresh defconfig files")

Signed-off-by: Daniel Díaz 
---
v1 -> v2: Clarify subject

 arch/x86/configs/i386_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index d7577fece9eb..4cfdf5755ab5 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -19,6 +19,7 @@ CONFIG_CGROUP_CPUACCT=y
 CONFIG_BLK_DEV_INITRD=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_PROFILING=y
+# CONFIG_64BIT is not set
 CONFIG_SMP=y
 CONFIG_X86_GENERIC=y
 CONFIG_HPET_TIMER=y
-- 
2.25.1



[PATCH] tools build feature: Quote CC and CXX for their arguments

2020-08-12 Thread Daniel Díaz
When using a cross-compilation environment, such as OpenEmbedded,
the CC an CXX variables are set to something more than just a
command: there are arguments (such as --sysroot) that need to be
passed on to the compiler so that the right set of headers and
libraries are used.

For the particular case that our systems detected, CC is set to
the following:

  export CC="aarch64-linaro-linux-gcc  
--sysroot=/oe/build/tmp/work/machine/perf/1.0-r9/recipe-sysroot"

Without quotes, detection is as follows:

  Auto-detecting system features:
  ... dwarf: [ OFF ]
  ...dwarf_getlocations: [ OFF ]
  ... glibc: [ OFF ]
  ...  gtk2: [ OFF ]
  ...libbfd: [ OFF ]
  ...libcap: [ OFF ]
  ...libelf: [ OFF ]
  ...   libnuma: [ OFF ]
  ...numa_num_possible_cpus: [ OFF ]
  ...   libperl: [ OFF ]
  ... libpython: [ OFF ]
  ... libcrypto: [ OFF ]
  ... libunwind: [ OFF ]
  ...libdw-dwarf-unwind: [ OFF ]
  ...  zlib: [ OFF ]
  ...  lzma: [ OFF ]
  ... get_cpuid: [ OFF ]
  ...   bpf: [ OFF ]
  ...libaio: [ OFF ]
  ...   libzstd: [ OFF ]
  ...disassembler-four-args: [ OFF ]

  Makefile.config:414: *** No gnu/libc-version.h found, please install 
glibc-dev[el].  Stop.
  Makefile.perf:230: recipe for target 'sub-make' failed
  make[1]: *** [sub-make] Error 2
  Makefile:69: recipe for target 'all' failed
  make: *** [all] Error 2

With CC and CXX quoted, some of those features are now detected.

Fixes: e3232c2f39ac ("tools build feature: Use CC and CXX from parent")

Signed-off-by: Daniel Díaz 
---
 tools/build/Makefile.feature | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 774f0b0ca28a..e7818b44b48e 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -8,7 +8,7 @@ endif
 
 feature_check = $(eval $(feature_check_code))
 define feature_check_code
-  feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CC=$(CC) 
CXX=$(CXX) CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" 
CXXFLAGS="$(EXTRA_CXXFLAGS) $(FEATURE_CHECK_CXXFLAGS-$(1))" LDFLAGS="$(LDFLAGS) 
$(FEATURE_CHECK_LDFLAGS-$(1))" -C $(feature_dir) $(OUTPUT_FEATURES)test-$1.bin 
>/dev/null 2>/dev/null && echo 1 || echo 0)
+  feature-$(1) := $(shell $(MAKE) OUTPUT=$(OUTPUT_FEATURES) CC="$(CC)" 
CXX="$(CXX)" CFLAGS="$(EXTRA_CFLAGS) $(FEATURE_CHECK_CFLAGS-$(1))" 
CXXFLAGS="$(EXTRA_CXXFLAGS) $(FEATURE_CHECK_CXXFLAGS-$(1))" LDFLAGS="$(LDFLAGS) 
$(FEATURE_CHECK_LDFLAGS-$(1))" -C $(feature_dir) $(OUTPUT_FEATURES)test-$1.bin 
>/dev/null 2>/dev/null && echo 1 || echo 0)
 endef
 
 feature_set = $(eval $(feature_set_code))
-- 
2.25.1



[PATCH] x86/defconfigs/32: Unset 64BIT

2020-08-10 Thread Daniel Díaz
A recent refresh of the defconfigs got rid of the following
(unset) config:

  # CONFIG_64BIT is not set

Innocuous as it seems, when the config file is saved again the
behavior is changed so that CONFIG_64BIT=y.

Currently,

  $ make i386_defconfig
  $ grep CONFIG_64BIT .config
  CONFIG_64BIT=y

whereas previously (and with this patch now):

  $ make i386_defconfig
  $ grep CONFIG_64BIT .config
  # CONFIG_64BIT is not set

This was found with weird compiler errors on OpenEmbedded
builds, as the compiler was unable to cope with 64-bits data
types:

  NOTE: make -j1 bzImage CC=i686-linaro-linux-gcc  -fuse-ld=bfd 
-fdebug-prefix-map=/oe/build/tmp/work/intel_core2_32-linaro-linux/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0=/usr/src/debug/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0
 
-fdebug-prefix-map=/oe/build/tmp/work/intel_core2_32-linaro-linux/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0/recipe-sysroot=
 
-fdebug-prefix-map=/oe/build/tmp/work/intel_core2_32-linaro-linux/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0/recipe-sysroot-native=
  
-fdebug-prefix-map=/oe/build/tmp/work-shared/intel-core2-32/kernel-source=/usr/src/kernel
 
-ffile-prefix-map=/oe/build/tmp/work/intel_core2_32-linaro-linux/linux-generic-mainline/5.8+gitAUTOINC+1d0e12fd3a-r0/git=/kernel-source/
  LD=i686-linaro-linux-ld.bfd
GEN Makefile
CC  scripts/mod/empty.o
  cc1: error: code model 'kernel' not supported in the 32 bit mode
  cc1: sorry, unimplemented: 64-bit mode not compiled in
  
/oe/build/tmp/work-shared/intel-core2-32/kernel-source/scripts/Makefile.build:280:
 recipe for target 'scripts/mod/empty.o' failed
  make[2]: *** [scripts/mod/empty.o] Error 1
  /oe/build/tmp/work-shared/intel-core2-32/kernel-source/Makefile:1174: recipe 
for target 'prepare0' failed
  make[1]: *** [prepare0] Error 2
  /oe/build/tmp/work-shared/intel-core2-32/kernel-source/Makefile:185: recipe 
for target '__sub-make' failed
  make: *** [__sub-make] Error 2

Fixes: 1d0e12fd3a84 ("x86/defconfigs: Refresh defconfig files")

Signed-off-by: Daniel Díaz 
---
 arch/x86/configs/i386_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index d7577fece9eb..4cfdf5755ab5 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -19,6 +19,7 @@ CONFIG_CGROUP_CPUACCT=y
 CONFIG_BLK_DEV_INITRD=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_PROFILING=y
+# CONFIG_64BIT is not set
 CONFIG_SMP=y
 CONFIG_X86_GENERIC=y
 CONFIG_HPET_TIMER=y
-- 
2.25.1



Re: [PATCH 5.7 0/6] 5.7.14-rc1 review

2020-08-05 Thread Daniel Díaz
Hello!

On Wed, 5 Aug 2020 at 13:37, Linus Torvalds
 wrote:
> On Wed, Aug 5, 2020 at 11:24 AM Guenter Roeck  wrote:
> >
> > Same with older versions of gcc. I don't see the problem with the
> > mainline kernel.
>
>   https://www.youtube.com/watch?v=-b5aW08ivHU
>
> > I think this is caused by more recursive includes.
> > arch/arm64/include/asm/archrandom.h includes include/linux/random.h
> > which includes arch/arm64/include/asm/archrandom.h to get the definition
> > of arch_get_random_seed_long_early (which it won't get because of
> > the recursion).
> >
> > What I don't really understand is how this works with new versions
> > of gcc.
>
> Is that the only place it triggers?

Yes

> Because the trivial fix would be something like the appended, which is
> the right thing to do anyway.
>
>   Linus
>
> diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
> index 07c4c8cc4a67..9ded4237e1c1 100644
> --- a/arch/arm64/kernel/kaslr.c
> +++ b/arch/arm64/kernel/kaslr.c
> @@ -11,8 +11,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
> -#include 
>  #include 
>  #include 
>  #include 

Tested-by: Daniel Díaz 

This patch works fine. Built with gcc 7.3.0 and glibc 2.27.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH 2/2] kvm: mmu: page_track: Fix RCU list API usage

2020-07-17 Thread Daniel Díaz
The sender of this email would like to recall the message. And drink
more coffee. The sender will also avoid making any more commits on
Friday.

On Fri, 17 Jul 2020 at 13:03, Daniel Díaz  wrote:
>
> Hello!
>
> On Fri, 17 Jul 2020 at 12:07, Paul E. McKenney  wrote:
> >
> > On Thu, Jul 16, 2020 at 05:19:52PM -0700, Dexuan-Linux Cui wrote:
> > > On Thu, Jul 16, 2020 at 7:47 AM Naresh Kamboju
> > >  wrote:
> > > >
> > > > On Sun, 12 Jul 2020 at 21:39, Paul E. McKenney  
> > > > wrote:
> > > > >
> > > > > On Sun, Jul 12, 2020 at 06:40:03PM +0530, 
> > > > > madhuparnabhowmi...@gmail.com wrote:
> > > > > > From: Madhuparna Bhowmik 
> > > > > >
> > > > > > Use hlist_for_each_entry_srcu() instead of 
> > > > > > hlist_for_each_entry_rcu()
> > > > > > as it also checkes if the right lock is held.
> > > > > > Using hlist_for_each_entry_rcu() with a condition argument will not
> > > > > > report the cases where a SRCU protected list is traversed using
> > > > > > rcu_read_lock(). Hence, use hlist_for_each_entry_srcu().
> > > > > >
> > > > > > Signed-off-by: Madhuparna Bhowmik 
> > > > >
> > > > > I queued both for testing and review, thank you!
> > > > >
> > > > > In particular, this one needs an ack by the maintainer.
> > > > >
> > > > > Thanx, Paul
> > > > >
> > > > > >  arch/x86/kvm/mmu/page_track.c | 6 --
> > > > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/x86/kvm/mmu/page_track.c 
> > > > > > b/arch/x86/kvm/mmu/page_track.c
> > > > > > index a7bcde34d1f2..a9cd17625950 100644
> > > > > > --- a/arch/x86/kvm/mmu/page_track.c
> > > > > > +++ b/arch/x86/kvm/mmu/page_track.c
> > > > > > @@ -229,7 +229,8 @@ void kvm_page_track_write(struct kvm_vcpu 
> > > > > > *vcpu, gpa_t gpa, const u8 *new,
> > > > > >   return;
> > > > > >
> > > > > >   idx = srcu_read_lock(>track_srcu);
> > > > > > - hlist_for_each_entry_rcu(n, >track_notifier_list, node)
> > > > > > + hlist_for_each_entry_srcu(n, >track_notifier_list, node,
> > > > > > + 
> > > > > > srcu_read_lock_held(>track_srcu))
> > > >
> > > > x86 build failed on linux -next 20200716.
> > > >
> > > > arch/x86/kvm/mmu/page_track.c: In function 'kvm_page_track_write':
> > > > include/linux/rculist.h:727:30: error: left-hand operand of comma
> > > > expression has no effect [-Werror=unused-value]
> > > >   for (__list_check_srcu(cond), \
> > > >   ^
> > > > arch/x86/kvm/mmu/page_track.c:232:2: note: in expansion of macro
> > > > 'hlist_for_each_entry_srcu'
> > > >   hlist_for_each_entry_srcu(n, >track_notifier_list, node,
> > > >   ^
> > > > arch/x86/kvm/mmu/page_track.c: In function 'kvm_page_track_flush_slot':
> > > > include/linux/rculist.h:727:30: error: left-hand operand of comma
> > > > expression has no effect [-Werror=unused-value]
> > > >   for (__list_check_srcu(cond), \
> > > >   ^
> > > > arch/x86/kvm/mmu/page_track.c:258:2: note: in expansion of macro
> > > > 'hlist_for_each_entry_srcu'
> > > >   hlist_for_each_entry_srcu(n, >track_notifier_list, node,
> > > >   ^
> > > > cc1: all warnings being treated as errors
> > > > make[3]: *** [arch/x86/kvm/mmu/page_track.o] Error 1
> > > >
> > > > build link,
> > > > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-next/DISTRO=lkft,MACHINE=intel-corei7-64,label=docker-lkft/815/consoleText
> > > >
> > >
> > > Hi, we're seeing the same building failure with the latest linux-next 
> > > tree.
> >
> > I am not seeing this here.  Could you please let us know what compiler
> > and command-line options you are using to generate this?

Please disregard anything below.

Thanks and greetings!

Daniel Díaz
daniel.d...@linaro.org


> It fails with gcc-8 and gcc-9, but it builds with gcc-10. Quick way to
> reproduce:
>   [host] docker run --rm -it -v /linux:/linux -w /linux
> tuxbuild/build-gcc-9_mips
>   [docker] make ARCH=mips CROSS_COMPILE=mips-linux-gnu- defconfig
>   [docker] make ARCH=mips CROSS_COMPILE=mips-linux-gnu- mm
>
> You can use these other Docker containers: tuxbuild/build-gcc-8_mips
> and tuxbuild/build-gcc-10_mips.
>
> Logs for those builds (and allnoconfig, tinyconfig, with gcc-8, gcc-9
> and gcc-10) can also be found here:
>   https://gitlab.com/Linaro/lkft/kernel-runs/-/jobs/643978135
>
> Greetings!
>
> Daniel Díaz
> daniel.d...@linaro.org


Re: [PATCH 2/2] kvm: mmu: page_track: Fix RCU list API usage

2020-07-17 Thread Daniel Díaz
Hello!

On Fri, 17 Jul 2020 at 12:07, Paul E. McKenney  wrote:
>
> On Thu, Jul 16, 2020 at 05:19:52PM -0700, Dexuan-Linux Cui wrote:
> > On Thu, Jul 16, 2020 at 7:47 AM Naresh Kamboju
> >  wrote:
> > >
> > > On Sun, 12 Jul 2020 at 21:39, Paul E. McKenney  wrote:
> > > >
> > > > On Sun, Jul 12, 2020 at 06:40:03PM +0530, madhuparnabhowmi...@gmail.com 
> > > > wrote:
> > > > > From: Madhuparna Bhowmik 
> > > > >
> > > > > Use hlist_for_each_entry_srcu() instead of hlist_for_each_entry_rcu()
> > > > > as it also checkes if the right lock is held.
> > > > > Using hlist_for_each_entry_rcu() with a condition argument will not
> > > > > report the cases where a SRCU protected list is traversed using
> > > > > rcu_read_lock(). Hence, use hlist_for_each_entry_srcu().
> > > > >
> > > > > Signed-off-by: Madhuparna Bhowmik 
> > > >
> > > > I queued both for testing and review, thank you!
> > > >
> > > > In particular, this one needs an ack by the maintainer.
> > > >
> > > > Thanx, Paul
> > > >
> > > > >  arch/x86/kvm/mmu/page_track.c | 6 --
> > > > >  1 file changed, 4 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/arch/x86/kvm/mmu/page_track.c 
> > > > > b/arch/x86/kvm/mmu/page_track.c
> > > > > index a7bcde34d1f2..a9cd17625950 100644
> > > > > --- a/arch/x86/kvm/mmu/page_track.c
> > > > > +++ b/arch/x86/kvm/mmu/page_track.c
> > > > > @@ -229,7 +229,8 @@ void kvm_page_track_write(struct kvm_vcpu *vcpu, 
> > > > > gpa_t gpa, const u8 *new,
> > > > >   return;
> > > > >
> > > > >   idx = srcu_read_lock(>track_srcu);
> > > > > - hlist_for_each_entry_rcu(n, >track_notifier_list, node)
> > > > > + hlist_for_each_entry_srcu(n, >track_notifier_list, node,
> > > > > + srcu_read_lock_held(>track_srcu))
> > >
> > > x86 build failed on linux -next 20200716.
> > >
> > > arch/x86/kvm/mmu/page_track.c: In function 'kvm_page_track_write':
> > > include/linux/rculist.h:727:30: error: left-hand operand of comma
> > > expression has no effect [-Werror=unused-value]
> > >   for (__list_check_srcu(cond), \
> > >   ^
> > > arch/x86/kvm/mmu/page_track.c:232:2: note: in expansion of macro
> > > 'hlist_for_each_entry_srcu'
> > >   hlist_for_each_entry_srcu(n, >track_notifier_list, node,
> > >   ^
> > > arch/x86/kvm/mmu/page_track.c: In function 'kvm_page_track_flush_slot':
> > > include/linux/rculist.h:727:30: error: left-hand operand of comma
> > > expression has no effect [-Werror=unused-value]
> > >   for (__list_check_srcu(cond), \
> > >   ^
> > > arch/x86/kvm/mmu/page_track.c:258:2: note: in expansion of macro
> > > 'hlist_for_each_entry_srcu'
> > >   hlist_for_each_entry_srcu(n, >track_notifier_list, node,
> > >   ^
> > > cc1: all warnings being treated as errors
> > > make[3]: *** [arch/x86/kvm/mmu/page_track.o] Error 1
> > >
> > > build link,
> > > https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-next/DISTRO=lkft,MACHINE=intel-corei7-64,label=docker-lkft/815/consoleText
> > >
> >
> > Hi, we're seeing the same building failure with the latest linux-next tree.
>
> I am not seeing this here.  Could you please let us know what compiler
> and command-line options you are using to generate this?

It fails with gcc-8 and gcc-9, but it builds with gcc-10. Quick way to
reproduce:
  [host] docker run --rm -it -v /linux:/linux -w /linux
tuxbuild/build-gcc-9_mips
  [docker] make ARCH=mips CROSS_COMPILE=mips-linux-gnu- defconfig
  [docker] make ARCH=mips CROSS_COMPILE=mips-linux-gnu- mm

You can use these other Docker containers: tuxbuild/build-gcc-8_mips
and tuxbuild/build-gcc-10_mips.

Logs for those builds (and allnoconfig, tinyconfig, with gcc-8, gcc-9
and gcc-10) can also be found here:
  https://gitlab.com/Linaro/lkft/kernel-runs/-/jobs/643978135

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH 5.7 000/265] 5.7.7-rc1 review

2020-06-30 Thread Daniel Díaz
Hello!

On Tue, 30 Jun 2020 at 10:12, Sasha Levin  wrote:
>
> On Tue, Jun 30, 2020 at 10:38:45AM +0200, Greg Kroah-Hartman wrote:
> >On Mon, Jun 29, 2020 at 07:18:26PM -0400, Sasha Levin wrote:
> >> On Mon, Jun 29, 2020 at 02:37:53PM -0600, Shuah Khan wrote:
> >> > Hi Sasha,
> >> >
> >> > On 6/29/20 9:13 AM, Sasha Levin wrote:
> >> > >
> >> > > This is the start of the stable review cycle for the 5.7.7 release.
> >> > > There are 265 patches in this series, all will be posted as a response
> >> > > to this one.  If anyone has any issues with these being applied, please
> >> > > let me know.
> >> > >
> >> > > Responses should be made by Wed 01 Jul 2020 03:14:48 PM UTC.
> >> > > Anything received after that time might be too late.
> >> > >
> >> > > The whole patch series can be found in one patch at:
> >> > >  
> >> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/patch/?id=linux-5.7.y=v5.7.6
> >> > >
> >> >
> >> > Looks like patch naming convention has changed. My scripts look
> >> > for the following convention Greg uses. Are you planning to use
> >> > the above going forward? My scripts failed looking for the usual
> >> > naming convention.
> >> >
> >> > The whole patch series can be found in one patch at:
> >> >
> >> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.6-rc1.gz
> >> > or in the git tree and branch at:
> >> >
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> >> > linux-5.7.y
> >> > and the diffstat can be found below.
> >>
> >> Sorry for that. I was hoping to avoid using the signed upload mechanism
> >> Greg was using by simply pointing the links to automatically generated
> >> patches on cgit (the git.kernel.org interface).
> >>
> >> Would it be ok to change the pattern matching here? Something like this
> >> should work for both Greg's format and my own (and whatever may come
> >> next):
> >>
> >>  grep -A1 "The whole patch series can be found in one patch at:" | 
> >> tail -n1 | sed 's/\t//'
> >
> >If those don't work, I can still push out -rc1 patches.
> >
> >It might be best given that the above -rc.git tree is unstable and can,
> >and will, change, and patches stored on kernel.org will not.
>
> That's a good point. Maybe we should push tags for -rc releases too?

That would be GREAT for those CI's or processes looking for a definite
trigger to use.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH 4.9 000/128] 4.9.228-rc1 review

2020-06-19 Thread Daniel Díaz

Hello!

On 6/19/20 9:31 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.9.228 release.
There are 128 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun, 21 Jun 2020 14:15:50 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.228-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.9.228-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: d0cfa25033bfd364a10be2446d64517b9deb0691
git describe: v4.9.227-129-gd0cfa25033bf
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.227-129-gd0cfa25033bf

No regressions (compared to build v4.9.227)

No fixes (compared to build v4.9.227)

Ran 30512 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan

Test Suites
---
* build
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* v4l2-compliance

Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.14 000/190] 4.14.185-rc1 review

2020-06-19 Thread Daniel Díaz

Hello!

On 6/19/20 9:30 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.14.185 release.
There are 190 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun, 21 Jun 2020 14:15:50 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.185-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.14.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.14.185-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: e26bcff6a5af4b6e19e350a39e88637307e07eb8
git describe: v4.14.184-191-ge26bcff6a5af
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.184-191-ge26bcff6a5af

No regressions (compared to build v4.14.184)

No fixes (compared to build v4.14.184)

Ran 34182 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan

Test Suites
---
* build
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* v4l2-compliance

Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.19 000/267] 4.19.129-rc1 review

2020-06-19 Thread Daniel Díaz

Hello!

On 6/19/20 9:29 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.19.129 release.
There are 267 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun, 21 Jun 2020 14:15:50 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.129-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.19.129-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: a00c59b6375644f707a3554536d03d4ecaf17c05
git describe: v4.19.128-268-ga00c59b63756
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.128-268-ga00c59b63756

No regressions (compared to build v4.19.128)

No fixes (compared to build v4.19.128)

Ran 34131 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan

Test Suites
---
* build
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* v4l2-compliance

Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 5.7 000/376] 5.7.5-rc1 review

2020-06-19 Thread Daniel Díaz

Hello!

On 6/19/20 9:28 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.7.5 release.
There are 376 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun, 21 Jun 2020 14:15:50 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.7.5-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.7.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 5.7.5-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.7.y
git commit: 19411dc6b06179bc55c542f1be520764cdcd3aac
git describe: v5.7.2-542-g19411dc6b061
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.7-oe/build/v5.7.2-542-g19411dc6b061

No regressions (compared to build v5.7.3)

No fixes (compared to build v5.7.3)

Ran 37628 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
- x86-kasan

Test Suites
---
* build
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* network-basic-tests
* perf
* v4l2-compliance

Greetings!

Daniel Díaz
daniel.d...@linaro.org


--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 5.4 000/261] 5.4.48-rc1 review

2020-06-19 Thread Daniel Díaz

Hello!

On 6/19/20 9:30 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.4.48 release.
There are 261 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun, 21 Jun 2020 14:15:50 +.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.48-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.4.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 5.4.48-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: 1b895c62ebf44a0852908c0f7ce05f53006fddf0
git describe: v5.4.46-394-g1b895c62ebf4
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.46-394-g1b895c62ebf4

No regressions (compared to build v5.4.47)

No fixes (compared to build v5.4.47)

Ran 32839 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
- x86-kasan

Test Suites
---
* build
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fs-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* perf
* v4l2-compliance


Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [GIT PULL] perf/core improvements and fixes

2020-05-05 Thread Daniel Díaz
Hello!

On Tue, 5 May 2020 at 11:37, Arnaldo Carvalho de Melo
 wrote:
>
> Em Mon, May 04, 2020 at 02:07:56PM -0500, Daniel Díaz escreveu:
> > Hello!
> >
> > On Fri, 24 Apr 2020 at 09:10, Andreas Gerstmayr  
> > wrote:
> > >
> > > On 24.04.20 15:07, Arnaldo Carvalho de Melo wrote:
> > > > Em Thu, Apr 23, 2020 at 04:28:46PM -0500, Daniel Díaz escreveu:
> > > >> On Wed, 22 Apr 2020 at 07:09, Ingo Molnar  wrote:
> > > >>>>   85 files changed, 1851 insertions(+), 513 deletions(-)
> > > >
> > > >>> Pulled, thanks a lot Arnaldo!
> > > >
> > > >> Our OpenEmbedded builds detected an issue with 5287f9269206 ("perf
> > > >> script: Add flamegraph.py script"):
> > > >>ERROR: perf-1.0-r9 do_package_qa: QA Issue:
> > > >> /usr/libexec/perf-core/scripts/python/bin/flamegraph-report contained
> > > >> in package perf-python requires /usr/bin/sh, but no providers found in
> > > >> RDEPENDS_perf-python? [file-rdeps]
> > > >
> > > >
> > > > yeah, the flamegraph scripts are the outliers, there, everything else is
> > > > using /bin/bash, so I'll switch to that, ok Andreas?
> > >
> > > Sure, no problem. Thanks!
> >
> > Just a gentle reminder that this can still be fixed in today's
> > linux-next tree (next-20200504).
>
> Thanks for the reminder, I've just added this to my tree:
>
> commit c74ab13a30d3bec443c116e25b611255c58f32c0
> Author: Arnaldo Carvalho de Melo 
> Date:   Tue May 5 13:33:12 2020 -0300
>
> perf flamegraph: Use /bin/bash for report script
>
> As all the other tools/perf/scripts/python/bin/*-report scripts, fixing
> the this problem reported by Daniel Diaz:
>
>   Our OpenEmbedded builds detected an issue with 5287f9269206 ("perf
>   script: Add flamegraph.py script"):
> ERROR: perf-1.0-r9 do_package_qa: QA Issue:
>   /usr/libexec/perf-core/scripts/python/bin/flamegraph-report contained
>   in package perf-python requires /usr/bin/sh, but no providers found in
>   RDEPENDS_perf-python? [file-rdeps]
>
>   This means that there is a new binary pulled in in the shebang line
>   which was unaccounted for: `/usr/bin/sh`. I don't see any other usage
>   of /usr/bin/sh in the kernel tree (does not even exist on my Ubuntu
>   dev machine) but plenty of /bin/sh. This patch is needed:
>   -8<--8<--8<-
>   diff --git a/tools/perf/scripts/python/bin/flamegraph-record
>   b/tools/perf/scripts/python/bin/flamegraph-record
>   index 725d66e71570..a2f3fa25ef81 100755
>   --- a/tools/perf/scripts/python/bin/flamegraph-record
>   +++ b/tools/perf/scripts/python/bin/flamegraph-record
>   @@ -1,2 +1,2 @@
>   -#!/usr/bin/sh
>   +#!/bin/sh
>perf record -g "$@"
>   diff --git a/tools/perf/scripts/python/bin/flamegraph-report
>   b/tools/perf/scripts/python/bin/flamegraph-report
>   index b1a79afd903b..b0177355619b 100755
>   --- a/tools/perf/scripts/python/bin/flamegraph-report
>   +++ b/tools/perf/scripts/python/bin/flamegraph-report
>   @@ -1,3 +1,3 @@
>   -#!/usr/bin/sh
>   +#!/bin/sh
># description: create flame graphs
>perf script -s "$PERF_EXEC_PATH"/scripts/python/flamegraph.py -- "$@"
>   ->8-->8-->8-
>
> Fixes: 5287f9269206 ("perf script: Add flamegraph.py script")
> Reported-by: Daniel Díaz 
> Cc: Adrian Hunter 
> Cc: Andreas Gerstmayr 
> Cc: Jiri Olsa 
> Cc: lkft-tri...@lists.linaro.org
> Cc: Namhyung Kim 
> Link: 
> http://lore.kernel.org/lkml/caeuse7_wmks361mkltb1eybzyxckkxdu26bx5bojdkrz8mf...@mail.gmail.com
> Signed-off-by: Arnaldo Carvalho de Melo 
>
> diff --git a/tools/perf/scripts/python/bin/flamegraph-report 
> b/tools/perf/scripts/python/bin/flamegraph-report
> index b1a79afd903b..53c5dc90c87e 100755
> --- a/tools/perf/scripts/python/bin/flamegraph-report
> +++ b/tools/perf/scripts/python/bin/flamegraph-report
> @@ -1,3 +1,3 @@
> -#!/usr/bin/sh
> +#!/bin/bash
>  # description: create flame graphs
>  perf script -s "$PERF_EXEC_PATH"/scripts/python/flamegraph.py -- "$@"

What about flamegraph-record?

Thanks and greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [GIT PULL] perf/core improvements and fixes

2020-05-04 Thread Daniel Díaz
Hello!

On Fri, 24 Apr 2020 at 09:10, Andreas Gerstmayr  wrote:
>
> On 24.04.20 15:07, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Apr 23, 2020 at 04:28:46PM -0500, Daniel Díaz escreveu:
> >> On Wed, 22 Apr 2020 at 07:09, Ingo Molnar  wrote:
> >>>>   85 files changed, 1851 insertions(+), 513 deletions(-)
> >
> >>> Pulled, thanks a lot Arnaldo!
> >
> >> Our OpenEmbedded builds detected an issue with 5287f9269206 ("perf
> >> script: Add flamegraph.py script"):
> >>ERROR: perf-1.0-r9 do_package_qa: QA Issue:
> >> /usr/libexec/perf-core/scripts/python/bin/flamegraph-report contained
> >> in package perf-python requires /usr/bin/sh, but no providers found in
> >> RDEPENDS_perf-python? [file-rdeps]
> >
> >
> > yeah, the flamegraph scripts are the outliers, there, everything else is
> > using /bin/bash, so I'll switch to that, ok Andreas?
>
> Sure, no problem. Thanks!

Just a gentle reminder that this can still be fixed in today's
linux-next tree (next-20200504).

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH 5.3 000/166] 5.3.5-stable review

2019-10-07 Thread Daniel Díaz
Hello!

On Mon, 7 Oct 2019 at 11:25, Daniel Díaz  wrote:
> Results from Linaro’s test farm.
> Regressions detected.

My bad. Should read: "No regressions detected" here, in line with the
other reports.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


> As mentioned, we found a problem with the mismatch of kselftests 5.3.1 and 
> net/udpgso.sh, but everything is fine.
>
> Summary
> 
>
> kernel: 5.3.5-rc1
> git repo: 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> git branch: linux-5.3.y
> git commit: a2703e78c28a6166f8796b4733620c6d0b8f479a
> git describe: v5.3.4-167-ga2703e78c28a
> Test details: 
> https://qa-reports.linaro.org/lkft/linux-stable-rc-5.3-oe/build/v5.3.4-167-ga2703e78c28a
>
> No regressions (compared to build v5.3.4)
>
> No fixes (compared to build v5.3.4)
>
> Ran 25519 total tests in the following environments and test suites.
>
> Environments
> --
> - dragonboard-410c
> - hi6220-hikey
> - i386
> - juno-r2
> - qemu_arm
> - qemu_arm64
> - qemu_i386
> - qemu_x86_64
> - x15
> - x86
>
> Test Suites
> ---
> * build
> * install-android-platform-tools-r2600
> * kselftest
> * libgpiod
> * libhugetlbfs
> * ltp-cap_bounds-tests
> * ltp-commands-tests
> * ltp-containers-tests
> * ltp-cpuhotplug-tests
> * ltp-cve-tests
> * ltp-dio-tests
> * ltp-fcntl-locktests-tests
> * ltp-filecaps-tests
> * ltp-fs_bind-tests
> * ltp-fs_perms_simple-tests
> * ltp-fsx-tests
> * ltp-hugetlb-tests
> * ltp-io-tests
> * ltp-ipc-tests
> * ltp-math-tests
> * ltp-mm-tests
> * ltp-nptl-tests
> * ltp-pty-tests
> * ltp-sched-tests
> * ltp-securebits-tests
> * ltp-syscalls-tests
> * ltp-timers-tests
> * perf
> * spectre-meltdown-checker-test
> * v4l2-compliance
> * ltp-fs-tests
> * network-basic-tests
> * ltp-open-posix-tests
> * kvm-unit-tests
> * kselftest-vsyscall-mode-native
> * kselftest-vsyscall-mode-none
> * ssuite
>
>
> Greetings!
>
> Daniel Díaz
> daniel.d...@linaro.org
>
>
> --
> Linaro LKFT
> https://lkft.linaro.org


Re: [PATCH 4.4 00/36] 4.4.196-stable review

2019-10-07 Thread Daniel Díaz

Hello!


On 10/6/19 12:18 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.4.196 release.
There are 36 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.196-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.4.196-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 13cac61d31df3572c7a2c88f2f40c59e0a92baf2
git describe: v4.4.195-37-g13cac61d31df
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.195-37-g13cac61d31df


No regressions (compared to build v4.4.195)

No fixes (compared to build v4.4.195)

Ran 18597 total tests in the following environments and test suites.

Environments
--
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-timers-tests
* network-basic-tests
* prep-tmp-disk
* spectre-meltdown-checker-test
* kvm-unit-tests
* ltp-syscalls-tests
* perf
* v4l2-compliance
* install-android-platform-tools-r2600
* kselftest-vsyscall-mode-native
* ssuite

Summary


kernel: 4.4.196-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.196-rc1-hikey-20191006-575
git commit: 49d2751d5f3cdb81b162d5c1f7ffb0fe210f005c
git describe: 4.4.196-rc1-hikey-20191006-575
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.196-rc1-hikey-20191006-575


No regressions (compared to build 4.4.195-rc1-hikey-20191003-572)

No fixes (compared to build 4.4.195-rc1-hikey-20191003-572)

Ran 1520 total tests in the following environments and test suites.

Environments
--
- hi6220-hikey - arm64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance


Greetings!

Daniel Díaz
daniel.d...@linaro.org


--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 5.3 000/166] 5.3.5-stable review

2019-10-07 Thread Daniel Díaz

Hello!


On 10/6/19 12:19 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.3.5 release.
There are 166 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.3.5-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.3.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
Regressions detected.

As mentioned, we found a problem with the mismatch of kselftests 5.3.1 and 
net/udpgso.sh, but everything is fine.

Summary


kernel: 5.3.5-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.3.y
git commit: a2703e78c28a6166f8796b4733620c6d0b8f479a
git describe: v5.3.4-167-ga2703e78c28a
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.3-oe/build/v5.3.4-167-ga2703e78c28a

No regressions (compared to build v5.3.4)

No fixes (compared to build v5.3.4)

Ran 25519 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-fs-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite


Greetings!

Daniel Díaz
daniel.d...@linaro.org


--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 5.2 000/137] 5.2.20-stable review

2019-10-07 Thread Daniel Díaz

Hello!


On 10/6/19 12:19 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.2.20 release.
There are 137 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.20-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.2.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

As mentioned, we found a problem with the mismatch of kselftests 5.3.1 and 
net/udpgso.sh, but everything is fine.

Summary


kernel: 5.2.20-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.2.y
git commit: c7a8121be8ef67066e07c79b2204dea12511b17b
git describe: v5.2.19-138-gc7a8121be8ef
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.2-oe/build/v5.2.19-138-gc7a8121be8ef

No regressions (compared to build v5.2.19)

No fixes (compared to build v5.2.19)

Ran 25451 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-fs-tests
* ltp-open-posix-tests
* network-basic-tests
* kvm-unit-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none


Greetings!

Daniel Díaz
daniel.d...@linaro.org


--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.19 000/106] 4.19.78-stable review

2019-10-07 Thread Daniel Díaz

Hello!


On 10/6/19 12:20 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.19.78 release.
There are 106 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.78-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h



Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Patch "udp: only do GSO if # of segs > 1" updated net/ipv[46]/udp.c and the 
kselftest that goes with it. The system detected a failure in net/udpgso.sh this time as we 
are running kselftests 5.3.1, which currently includes a now-outdated version of this test. 
As soon as 5.3.5 is released, we'll upgrade kselftests and this test will pass again.

Because there's no regression (i.e. it passes with the updated test), there is 
nothing to worry about here. The same can be said of the 5.2 and 5.3 release 
candidates.


Summary


kernel: 4.19.78-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 61e72e79b84d3a2519ad88c10964d7e4fa11ef1d
git describe: v4.19.77-107-g61e72e79b84d
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.77-107-g61e72e79b84d

No regressions (compared to build v4.19.77)

No fixes (compared to build v4.19.77)

Ran 21962 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-fs-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none


Greetings!

Daniel Díaz
daniel.d...@linaro.org


--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.14 00/68] 4.14.148-stable review

2019-10-07 Thread Daniel Díaz

Hello!


On 10/6/19 12:20 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.14.148 release.
There are 68 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue 08 Oct 2019 05:07:10 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.148-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.14.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.14.148-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: b970b501da0bee5eba4e61ea7d424adab428a165
git describe: v4.14.147-69-gb970b501da0b
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.147-69-gb970b501da0b

No regressions (compared to build v4.14.147)

No fixes (compared to build v4.14.147)

Ran 23798 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-fs-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none


Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.9 00/47] 4.9.196-stable review

2019-10-07 Thread Daniel Díaz

Hello!


On 10/6/19 12:20 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.9.196 release.
There are 47 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Tue 08 Oct 2019 05:19:59 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.196-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h



Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.9.196-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: ce2cf4ffcd946bd02d4afd26f17f425dc921448e
git describe: v4.9.195-48-gce2cf4ffcd94
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.195-48-gce2cf4ffcd94

No regressions (compared to build v4.9.195)

No fixes (compared to build v4.9.195)

Ran 21656 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* network-basic-tests
* ltp-open-posix-tests
* prep-tmp-disk
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite


Greetings!

Daniel Díaz
daniel.d...@linaro.org


--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 5.2 000/143] 5.2.12-stable review

2019-09-05 Thread Daniel Díaz

Hello!

On 9/4/19 12:52 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 5.2.12 release.
There are 143 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Fri 06 Sep 2019 05:50:23 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.12-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-5.2.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 5.2.12-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.2.y
git commit: b6eedcb8cf6670234e137d277a5ae1cdf5cd141c
git describe: v5.2.11-144-gb6eedcb8cf66
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.2-oe/build/v5.2.11-144-gb6eedcb8cf66


No regressions (compared to build v5.2.11)

No fixes (compared to build v5.2.11)

Ran 22474 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* network-basic-tests
* ltp-fs-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite


Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.19 00/93] 4.19.70-stable review

2019-09-05 Thread Daniel Díaz

Hello!

On 9/4/19 12:53 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.19.70 release.
There are 93 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Fri 06 Sep 2019 05:50:23 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.70-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.19.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.19.70-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: b755ab5041366b954c39bd97caa982539e0d1223
git describe: v4.19.69-94-gb755ab504136
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.69-94-gb755ab504136


No regressions (compared to build v4.19.69)

No fixes (compared to build v4.19.69)

Ran 25004 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* spectre-meltdown-checker-test
* ltp-fs-tests
* network-basic-tests
* perf
* v4l2-compliance
* ltp-open-posix-tests
* kvm-unit-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none


Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.14 00/57] 4.14.142-stable review

2019-09-05 Thread Daniel Díaz

Hello!

On 9/4/19 12:53 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.14.142 release.
There are 57 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Fri 06 Sep 2019 05:50:23 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.142-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.14.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.14.142-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 39a17ab1edd4adb3fb732726a36cb54a21cc570d
git describe: v4.14.141-58-g39a17ab1edd4
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.141-58-g39a17ab1edd4


No regressions (compared to build v4.14.141)

No fixes (compared to build v4.14.141)

Ran 23684 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* ltp-commands-tests
* ltp-math-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* ssuite
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none


Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.9 00/83] 4.9.191-stable review

2019-09-05 Thread Daniel Díaz

Hello!

On 9/4/19 12:52 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.9.191 release.
There are 83 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Fri 06 Sep 2019 05:50:23 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.191-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.9.191-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: a232f5b3e31224799f7506f9e9d4257d3d357d1b
git describe: v4.9.190-84-ga232f5b3e312
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.190-84-ga232f5b3e312


No regressions (compared to build v4.9.190)

No fixes (compared to build v4.9.190)

Ran 23512 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* network-basic-tests
* ltp-open-posix-tests
* prep-tmp-disk
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite


Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.4 00/77] 4.4.191-stable review

2019-09-05 Thread Daniel Díaz

Hello!

On 9/4/19 12:52 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.4.191 release.
There are 77 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Fri 06 Sep 2019 05:50:23 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.191-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.4.191-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: fab7823b08aae873a7ab1918c9a0a5125dc89754
git describe: v4.4.190-78-gfab7823b08aa
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.190-78-gfab7823b08aa


No regressions (compared to build v4.4.190)

No fixes (compared to build v4.4.190)

Ran 20009 total tests in the following environments and test suites.

Environments
--
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* network-basic-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* kvm-unit-tests
* install-android-platform-tools-r2600
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* prep-tmp-disk
* ssuite

Summary


kernel: 4.4.191-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.191-rc1-hikey-20190904-546
git commit: 0f182005f060ccc4fa2d14084c4a207aaa2207e4
git describe: 4.4.191-rc1-hikey-20190904-546
Test details: 
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.191-rc1-hikey-20190904-546


No regressions (compared to build 4.4.191-rc1-hikey-20190827-544)

No fixes (compared to build 4.4.191-rc1-hikey-20190827-544)

Ran 1533 total tests in the following environments and test suites.

Environments
--
- hi6220-hikey - arm64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance


Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.19 00/91] 4.19.67-stable review

2019-08-15 Thread Daniel Díaz
Hello!

On Thu, 15 Aug 2019 at 08:29, Guenter Roeck  wrote:
>
> On 8/14/19 10:00 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.67 release.
> > There are 91 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri 16 Aug 2019 04:55:34 PM UTC.
> > Anything received after that time might be too late.
> >
>
> Building x86_64:tools/perf ... failed
> --
> Error log:
> Warning: arch/x86/include/asm/cpufeatures.h differs from kernel
> Warning: arch/x86/include/uapi/asm/kvm.h differs from kernel
>PERF_VERSION = 4.9.189.ge000f87
> util/machine.c: In function ‘machine__create_module’:
> util/machine.c:1088:43: error: ‘size’ undeclared (first use in this 
> function); did you mean ‘die’?
>if (arch__fix_module_text_start(, , name) < 0)
> ^~~~
> die
> util/machine.c:1088:43: note: each undeclared identifier is reported only 
> once for each function it appears in

We noticed this exact failure but not on 4.19. For us, 4.19's perf builds fine.

On 4.9, perf failed with the error you described, as it looks like
it's missing 9ad4652b66f1 ("perf record: Fix wrong size in
perf_record_mmap for last kernel module"), though I have not verified
yet.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH 4.9 00/32] 4.9.189-stable review

2019-08-09 Thread Daniel Díaz

Hello!

On 8/9/19 8:45 AM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.9.189 release.
There are 32 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun 11 Aug 2019 01:38:45 PM UTC.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.189-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h


Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.9.189-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 260869840af4f3d7b3b46c4047642a931535c196
git describe: v4.9.187-76-g260869840af4
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.187-76-g260869840af4


No regressions (compared to build v4.9.188)

No fixes (compared to build v4.9.188)

Ran 23630 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* network-basic-tests
* ltp-open-posix-tests
* prep-tmp-disk
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* ssuite


Greetings!

Daniel Díaz
daniel.d...@linaro.org

--
Linaro LKFT
https://lkft.linaro.org


Re: [PATCH 4.4 0/1] 4.4.184-stable review

2019-06-26 Thread Daniel Díaz
Hello!

On 6/26/19 3:45 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.184 release.
> There are 1 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri 28 Jun 2019 08:35:42 AM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.184-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.4.184-rc1
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: 5f1824292521531d662f05e2e24275767d18c0c4
git describe: v4.4.183-2-g5f1824292521
Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.183-2-g5f1824292521


No regressions (compared to build v4.4.183)

No fixes (compared to build v4.4.183)


Ran 20117 total tests in the following environments and test suites.

Environments
--
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* build
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* network-basic-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance
* kvm-unit-tests
* install-android-platform-tools-r2600
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
* prep-tmp-disk

Summary


kernel: 4.4.184-rc1
git repo: https://git.linaro.org/lkft/arm64-stable-rc.git
git branch: 4.4.184-rc1-hikey-20190626-477
git commit: de92183312a3d85ab8b3516096a61210a4e9f458
git describe: 4.4.184-rc1-hikey-20190626-477
Test details:
https://qa-reports.linaro.org/lkft/linaro-hikey-stable-rc-4.4-oe/build/4.4.184-rc1-hikey-20190626-477


No regressions (compared to build 4.4.184-rc1-hikey-20190624-475)


No fixes (compared to build 4.4.184-rc1-hikey-20190624-475)

Ran 1549 total tests in the following environments and test suites.

Environments
--
- hi6220-hikey - arm64

Test Suites
---
* build
* install-android-platform-tools-r2600
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* perf
* spectre-meltdown-checker-test
* v4l2-compliance


Greetings!

Daniel Díaz
daniel.d...@linaro.org

-- 
Linaro LKFT
https://lkft.linaro.org


[PATCH] selftests/tpm2: Install run-time Python modules

2019-06-20 Thread Daniel Díaz
When ordinarily running the tests, upon `make install', the
following error is encountered:
  ImportError: No module named tpm2_tests
because the Python files are not installed at the moment.

Fix this by adding both Python modules as accompanying
TEST_FILES in the Makefile.

Signed-off-by: Daniel Díaz 
---
 tools/testing/selftests/tpm2/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/tpm2/Makefile 
b/tools/testing/selftests/tpm2/Makefile
index 9dd848427a7b..bf401f725eef 100644
--- a/tools/testing/selftests/tpm2/Makefile
+++ b/tools/testing/selftests/tpm2/Makefile
@@ -2,3 +2,4 @@
 include ../lib.mk
 
 TEST_PROGS := test_smoke.sh test_space.sh
+TEST_FILES := tpm2.py tpm2_tests.py
-- 
2.20.1



[PATCH v4.4.y] perf bench: Copy kernel files needed to build mem{cpy,set} x86_64 benchmarks

2019-03-20 Thread Daniel Díaz
From: Arnaldo Carvalho de Melo 

commit 7d7d1bf1d1dabe435ef50efb051724b8664749cb upstream.

We can't access kernel files directly from tools/, so copy the required
bits, and make sure that we detect when the original files, in the
kernel, gets modified.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-z7e76274ch5j4nugv048q...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Daniel Díaz 
---
 tools/arch/x86/include/asm/cpufeatures.h  | 336 ++
 .../arch/x86/include/asm/disabled-features.h  |  65 
 .../arch/x86/include/asm/required-features.h  | 106 ++
 tools/arch/x86/lib/memcpy_64.S| 179 ++
 tools/arch/x86/lib/memset_64.S| 138 +++
 .../util => }/include/asm/alternative-asm.h   |   4 +-
 tools/perf/MANIFEST   |   8 +-
 tools/perf/Makefile.perf  |  15 +
 tools/perf/bench/mem-memcpy-x86-64-asm.S  |   2 +-
 tools/perf/bench/mem-memset-x86-64-asm.S  |   2 +-
 10 files changed, 849 insertions(+), 6 deletions(-)
 create mode 100644 tools/arch/x86/include/asm/cpufeatures.h
 create mode 100644 tools/arch/x86/include/asm/disabled-features.h
 create mode 100644 tools/arch/x86/include/asm/required-features.h
 create mode 100644 tools/arch/x86/lib/memcpy_64.S
 create mode 100644 tools/arch/x86/lib/memset_64.S
 rename tools/{perf/util => }/include/asm/alternative-asm.h (66%)

diff --git a/tools/arch/x86/include/asm/cpufeatures.h 
b/tools/arch/x86/include/asm/cpufeatures.h
new file mode 100644
index ..a5fa3195a230
--- /dev/null
+++ b/tools/arch/x86/include/asm/cpufeatures.h
@@ -0,0 +1,336 @@
+#ifndef _ASM_X86_CPUFEATURES_H
+#define _ASM_X86_CPUFEATURES_H
+
+#ifndef _ASM_X86_REQUIRED_FEATURES_H
+#include 
+#endif
+
+#ifndef _ASM_X86_DISABLED_FEATURES_H
+#include 
+#endif
+
+/*
+ * Defines x86 CPU feature bits
+ */
+#define NCAPINTS   19  /* N 32-bit words worth of info */
+#define NBUGINTS   1   /* N 32-bit bug flags */
+
+/*
+ * Note: If the comment begins with a quoted string, that string is used
+ * in /proc/cpuinfo instead of the macro name.  If the string is "",
+ * this feature bit is not displayed in /proc/cpuinfo at all.
+ */
+
+/* Intel-defined CPU features, CPUID level 0x0001 (edx), word 0 */
+#define X86_FEATURE_FPU( 0*32+ 0) /* Onboard FPU */
+#define X86_FEATURE_VME( 0*32+ 1) /* Virtual Mode Extensions */
+#define X86_FEATURE_DE ( 0*32+ 2) /* Debugging Extensions */
+#define X86_FEATURE_PSE( 0*32+ 3) /* Page Size Extensions */
+#define X86_FEATURE_TSC( 0*32+ 4) /* Time Stamp Counter */
+#define X86_FEATURE_MSR( 0*32+ 5) /* Model-Specific Registers 
*/
+#define X86_FEATURE_PAE( 0*32+ 6) /* Physical Address 
Extensions */
+#define X86_FEATURE_MCE( 0*32+ 7) /* Machine Check Exception */
+#define X86_FEATURE_CX8( 0*32+ 8) /* CMPXCHG8 instruction */
+#define X86_FEATURE_APIC   ( 0*32+ 9) /* Onboard APIC */
+#define X86_FEATURE_SEP( 0*32+11) /* SYSENTER/SYSEXIT */
+#define X86_FEATURE_MTRR   ( 0*32+12) /* Memory Type Range Registers */
+#define X86_FEATURE_PGE( 0*32+13) /* Page Global Enable */
+#define X86_FEATURE_MCA( 0*32+14) /* Machine Check 
Architecture */
+#define X86_FEATURE_CMOV   ( 0*32+15) /* CMOV instructions */
+ /* (plus FCMOVcc, FCOMI with FPU) */
+#define X86_FEATURE_PAT( 0*32+16) /* Page Attribute Table */
+#define X86_FEATURE_PSE36  ( 0*32+17) /* 36-bit PSEs */
+#define X86_FEATURE_PN ( 0*32+18) /* Processor serial number */
+#define X86_FEATURE_CLFLUSH( 0*32+19) /* CLFLUSH instruction */
+#define X86_FEATURE_DS ( 0*32+21) /* "dts" Debug Store */
+#define X86_FEATURE_ACPI   ( 0*32+22) /* ACPI via MSR */
+#define X86_FEATURE_MMX( 0*32+23) /* Multimedia Extensions */
+#define X86_FEATURE_FXSR   ( 0*32+24) /* FXSAVE/FXRSTOR, CR4.OSFXSR */
+#define X86_FEATURE_XMM( 0*32+25) /* "sse" */
+#define X86_FEATURE_XMM2   ( 0*32+26) /* "sse2" */
+#define X86_FEATURE_SELFSNOOP  ( 0*32+27) /* "ss" CPU self snoop */
+#define X86_FEATURE_HT ( 0*32+28) /* Hyper-Threading */
+#define X86_FEATURE_ACC( 0*32+29) /* "tm" Automatic clock 
control */
+#define X86_FEATURE_IA64   ( 0*32+30) /* IA-64 processor */
+#define X86_FEATURE_PBE( 0*32+31) /* Pending Break Enable */
+
+/* AMD-defined CPU features, CPUID level 0x8001, word 1 */
+/* Don't duplicate feature flags which are redundant with Intel! */
+#define X86_FEATURE_SYSCALL( 1*32+11) /* SYSCALL/SYSRET */
+#define X86_FEATURE_MP ( 1*32+19) /* MP Capable. */
+#define X86_FEATURE_NX   

Re: [PATCH 4.9 00/96] 4.9.163-stable review

2019-03-13 Thread Daniel Díaz
Hello!

On Wed, 13 Mar 2019 at 11:58, Greg Kroah-Hartman
 wrote:
>
> On Wed, Mar 13, 2019 at 08:14:29AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Mar 13, 2019 at 07:44:34AM -0700, Guenter Roeck wrote:
> > > On Tue, Mar 12, 2019 at 10:09:18AM -0700, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 4.9.163 release.
> > > > There are 96 patches in this series, all will be posted as a response
> > > > to this one.  If anyone has any issues with these being applied, please
> > > > let me know.
> > > >
> > > > Responses should be made by Thu Mar 14 17:10:06 UTC 2019.
> > > > Anything received after that time might be too late.
> > > >
> > >
> > > Early results:
> > >
> > > Building x86_64:tools/perf ... failed
> > > --
> > > Error log:
> > > Warning: arch/x86/include/asm/cpufeatures.h differs from kernel
> > > Warning: arch/x86/include/uapi/asm/kvm.h differs from kernel
> > >   PERF_VERSION = 4.9.162.g605129
> > > builtin-trace.c: In function ‘perf_evlist__add_vfs_getname’:
> > > builtin-trace.c:2071:8: error: implicit declaration of function 
> > > ‘strstarts’ [-Werror=implicit-function-declaration]
> > > builtin-trace.c:2071:3: error: nested extern declaration of ‘strstarts’ 
> > > [-Werror=nested-externs]
> > >
> > > Also affects v4.4.y-queue.
> >
> > Hm, at first I was worried about my backport, but if it hit 4.4 as well,
> > that's not my fault :)
> >
> > I'll look at this after breakfast, thanks!
>
> I can't even get perf to build without any stable queue patches for
> 4.9.y at the moment, nor for 4.4.y, so something is odd, or I just have
> too "new" of a system.  Let me go dig up a debian box to see if I can at
> least find a way to start to reproduce this...

Interesting. To add to the fun, just yesterday I tried building the
Perf recipe from OpenEmbedded and it failed for these combinations:
* 4.4.176 and x86_64:
|   CC   
/srv/oe/build/tmp-lkft-glibc/work/intel_corei7_64-linaro-linux/perf/1.0-r9/perf-1.0/bench/mem-memcpy-x86-64-asm.o
| bench/mem-memcpy-x86-64-asm.S:4:10: fatal error:
../../../arch/x86/lib/memcpy_64.S: No such file or directory
|  #include "../../../arch/x86/lib/memcpy_64.S"
|   ^~~
| compilation terminated.

* 4.14.105 and i386:
| In file included from util/libunwind/x86_32.c:33:0:
| util/libunwind/../../arch/x86/util/unwind-libunwind.c: In function
'libunwind__x86_reg_id':
| util/libunwind/../../arch/x86/util/unwind-libunwind.c:110:11: error:
'EINVAL' undeclared (first use in this function); did you mean
'UNW_EINVAL'?
|return -EINVAL;
|^~
|UNW_EINVAL

Other combinations that worked:
* 4.4.176 with arm, arm64, i386
* 4.9.162 with arm, arm64, i386, x86_64
* 4.14.105 with arm, arm64, x86_64
* 4.19.28 with arm, arm64, i386, x86_64
* 4.20.15 with arm, arm64, i386, x86_64
* 5.0.1 with arm, arm64, i386, x86_64

I'll try again the failing combos to discard a problem with the OE build itself.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH 1/4] selftests: lib: allow to override CC in the top-level Makefile

2019-01-28 Thread Daniel Díaz
Hello!

On Mon, 28 Jan 2019 at 10:28, shuah  wrote:
> On 1/28/19 8:42 AM, Denys Dmytriyenko wrote:
> > On Mon, Jan 28, 2019 at 08:01:15AM -0700, shuah wrote:
> >> Hi Daniel,
> >>
> >> On 1/18/19 10:54 AM, Daniel Díaz wrote:
> >>> Hello!
> >>>
> >>> On Wed, 16 Jan 2019 at 15:56, shuah  wrote:
> >>>>
> >>>> On 1/16/19 10:43 AM, Daniel Díaz wrote:
> >>>>> From: Fathi Boudra 
>
> This is the problem. It says, it came from Fathi Boudra
> 

Denys, apologies for sending this patch as Fathi's. In our Git
repository [1] he's marked as author, probably as it got copied from
repo to repo.

Would you mind sending this patch yourself?

Thanks and greetings!

Daniel Díaz
daniel.d...@linaro.org

[1] 
https://github.com/96boards/meta-rpb/blob/master/recipes-overlayed/kselftests/files/0001-selftests-lib-allow-to-override-CC-in-the-top-level-Makefile.patch


> >>>>> Relax CC assignment to allow to override CC in the top-level Makefile.
> >>>>>
> >>>>> Signed-off-by: Denys Dmytriyenko 
> >
> > ^^^ I am the original author of the patch and this is my signed-off line.
> >
>
> thanks,
> -- Shuah


Re: [PATCH 1/4] selftests: lib: allow to override CC in the top-level Makefile

2019-01-18 Thread Daniel Díaz
Hello!

On Wed, 16 Jan 2019 at 15:56, shuah  wrote:
>
> On 1/16/19 10:43 AM, Daniel Díaz wrote:
> > From: Fathi Boudra 
> >
> > Relax CC assignment to allow to override CC in the top-level Makefile.
> >
> > Signed-off-by: Denys Dmytriyenko 
> > ---
> >   tools/testing/selftests/lib.mk | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
> > index 8b0f16409ed7..0f9c47eaaa6f 100644
> > --- a/tools/testing/selftests/lib.mk
> > +++ b/tools/testing/selftests/lib.mk
> > @@ -1,6 +1,6 @@
> >   # This mimics the top-level Makefile. We do it explicitly here so that 
> > this
> >   # Makefile can operate with or without the kbuild infrastructure.
> > -CC := $(CROSS_COMPILE)gcc
> > +CC ?= $(CROSS_COMPILE)gcc
> >
> >   ifeq (0,$(MAKELEVEL))
> >   OUTPUT := $(shell pwd)
> >
>
> What problem does this fix?

Sometimes "$(CROSS_COMPILE)gcc" is not enough: For instance, we need
to pass --sysroot to CC:
  CC="aarch64-linaro-linux-gcc
--sysroot=/oe/build/tmp-lkft-glibc/work/hikey-linaro-linux/kselftests-mainline/4.19-r0/recipe-sysroot"

Greetings!

Daniel Díaz
daniel.d...@linaro.org


[PATCH 2/4] selftests: net: use LDLIBS instead of LDFLAGS

2019-01-16 Thread Daniel Díaz
From: Fathi Boudra 

reuseport_bpf_numa fails to build due to undefined reference errors:

 aarch64-linaro-linux-gcc
 --sysroot=/build/tmp-rpb-glibc/sysroots/hikey -Wall
 -Wl,--no-as-needed -O2 -g -I../../../../usr/include/  -Wl,-O1
 -Wl,--hash-style=gnu -Wl,--as-needed -lnuma  reuseport_bpf_numa.c
 -o
 
/build/tmp-rpb-glibc/work/hikey-linaro-linux/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/net/reuseport_bpf_numa
 /tmp/ccfUuExT.o: In function `send_from_node':
 
/build/tmp-rpb-glibc/work/hikey-linaro-linux/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/net/reuseport_bpf_numa.c:138:
 undefined reference to `numa_run_on_node'
 /tmp/ccfUuExT.o: In function `main':
 
/build/tmp-rpb-glibc/work/hikey-linaro-linux/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/net/reuseport_bpf_numa.c:230:
 undefined reference to `numa_available'
 
/build/tmp-rpb-glibc/work/hikey-linaro-linux/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/net/reuseport_bpf_numa.c:233:
 undefined reference to `numa_max_node'

It's GNU Make and linker specific.

The default Makefile rule looks like:

$(CC) $(CFLAGS) $(LDFLAGS) $@ $^ $(LDLIBS)

When linking is done by gcc itself, no issue, but when it needs to be passed
to proper ld, only LDLIBS follows and then ld cannot know what libs to link
with.

More detail:
https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html

LDFLAGS
Extra flags to give to compilers when they are supposed to invoke the linker,
‘ld’, such as -L. Libraries (-lfoo) should be added to the LDLIBS variable
instead.

LDLIBS
Library flags or names given to compilers when they are supposed to invoke the
linker, ‘ld’. LOADLIBES is a deprecated (but still supported) alternative to
LDLIBS. Non-library linker flags, such as -L, should go in the LDFLAGS
variable.

https://lkml.org/lkml/2010/2/10/362

tools/perf: libraries must come after objects

Link order matters, use LDLIBS instead of LDFLAGS to properly link against
libnuma.

Signed-off-by: Fathi Boudra 
---
 tools/testing/selftests/net/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/net/Makefile 
b/tools/testing/selftests/net/Makefile
index f8f3e90700c0..1e6d14d2825c 100644
--- a/tools/testing/selftests/net/Makefile
+++ b/tools/testing/selftests/net/Makefile
@@ -21,6 +21,6 @@ TEST_GEN_PROGS += reuseport_dualstack reuseaddr_conflict tls
 KSFT_KHDR_INSTALL := 1
 include ../lib.mk
 
-$(OUTPUT)/reuseport_bpf_numa: LDFLAGS += -lnuma
+$(OUTPUT)/reuseport_bpf_numa: LDLIBS += -lnuma
 $(OUTPUT)/tcp_mmap: LDFLAGS += -lpthread
 $(OUTPUT)/tcp_inq: LDFLAGS += -lpthread
-- 
2.17.1



[PATCH 3/4] selftests: seccomp: use LDLIBS instead of LDFLAGS

2019-01-16 Thread Daniel Díaz
From: Fathi Boudra 

seccomp_bpf fails to build due to undefined reference errors:

 aarch64-linaro-linux-gcc --sysroot=/build/tmp-rpb-glibc/sysroots/hikey
 -O2 -pipe -g -feliminate-unused-debug-types -Wl,-no-as-needed -Wall
 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -lpthread seccomp_bpf.c -o
 
/build/tmp-rpb-glibc/work/hikey-linaro-linux/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf
 /tmp/ccrlR3MW.o: In function `tsync_sibling':
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1920:
 undefined reference to `sem_post'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1920:
 undefined reference to `sem_post'
 /tmp/ccrlR3MW.o: In function `TSYNC_setup':
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1863:
 undefined reference to `sem_init'
 /tmp/ccrlR3MW.o: In function `TSYNC_teardown':
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1904:
 undefined reference to `sem_destroy'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1897:
 undefined reference to `pthread_kill'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1898:
 undefined reference to `pthread_cancel'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1899:
 undefined reference to `pthread_join'
 /tmp/ccrlR3MW.o: In function `tsync_start_sibling':
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941:
 undefined reference to `pthread_create'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941:
 undefined reference to `pthread_create'
 /tmp/ccrlR3MW.o: In function `TSYNC_siblings_fail_prctl':
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1978:
 undefined reference to `sem_wait'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1990:
 undefined reference to `pthread_join'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1992:
 undefined reference to `pthread_join'
 /tmp/ccrlR3MW.o: In function `tsync_start_sibling':
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941:
 undefined reference to `pthread_create'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941:
 undefined reference to `pthread_create'
 /tmp/ccrlR3MW.o: In function `TSYNC_two_siblings_with_ancestor':
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2016:
 undefined reference to `sem_wait'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2032:
 undefined reference to `pthread_join'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2034:
 undefined reference to `pthread_join'
 /tmp/ccrlR3MW.o: In function `tsync_start_sibling':
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941:
 undefined reference to `pthread_create'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941:
 undefined reference to `pthread_create'
 /tmp/ccrlR3MW.o: In function `TSYNC_two_sibling_want_nnp':
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2046:
 undefined reference to `sem_wait'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2058:
 undefined reference to `pthread_join'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2060:
 undefined reference to `pthread_join'
 /tmp/ccrlR3MW.o: In function `tsync_start_sibling':
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941:
 undefined reference to `pthread_create'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:1941:
 undefined reference to `pthread_create'
 /tmp/ccrlR3MW.o: In function `TSYNC_two_siblings_with_no_filter':
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2073:
 undefined reference to `sem_wait'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2098:
 undefined reference to `pthread_join'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/seccomp/seccomp_bpf.c:2100:
 undefined reference to `pthread_join'
 /tmp/ccrlR3MW.o: In function `tsync_start_sibling':
 

[PATCH 4/4] selftests: timers: use LDLIBS instead of LDFLAGS

2019-01-16 Thread Daniel Díaz
From: Fathi Boudra 

posix_timers fails to build due to undefined reference errors:

 aarch64-linaro-linux-gcc --sysroot=/build/tmp-rpb-glibc/sysroots/hikey
 -O2 -pipe -g -feliminate-unused-debug-types -O3 -Wl,-no-as-needed -Wall
 -DKTEST  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -lrt -lpthread
 posix_timers.c
 -o 
/build/tmp-rpb-glibc/work/hikey-linaro-linux/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/timers/posix_timers
 /tmp/cc1FTZzT.o: In function `check_timer_create':
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/timers/posix_timers.c:157:
 undefined reference to `timer_create'
 
/usr/src/debug/kselftests/4.12-r0/linux-4.12-rc7/tools/testing/selftests/timers/posix_timers.c:170:
 undefined reference to `timer_settime'
 collect2: error: ld returned 1 exit status

It's GNU Make and linker specific.

The default Makefile rule looks like:

$(CC) $(CFLAGS) $(LDFLAGS) $@ $^ $(LDLIBS)

When linking is done by gcc itself, no issue, but when it needs to be passed
to proper ld, only LDLIBS follows and then ld cannot know what libs to link
with.

More detail:
https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html

LDFLAGS
Extra flags to give to compilers when they are supposed to invoke the linker,
‘ld’, such as -L. Libraries (-lfoo) should be added to the LDLIBS variable
instead.

LDLIBS
Library flags or names given to compilers when they are supposed to invoke the
linker, ‘ld’. LOADLIBES is a deprecated (but still supported) alternative to
LDLIBS. Non-library linker flags, such as -L, should go in the LDFLAGS
variable.

https://lkml.org/lkml/2010/2/10/362

tools/perf: libraries must come after objects

Link order matters, use LDLIBS instead of LDFLAGS to properly link against
libpthread.

Signed-off-by: Denys Dmytriyenko 
Signed-off-by: Fathi Boudra 
---
 tools/testing/selftests/timers/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/timers/Makefile 
b/tools/testing/selftests/timers/Makefile
index c02683cfb6c9..7656c7ce79d9 100644
--- a/tools/testing/selftests/timers/Makefile
+++ b/tools/testing/selftests/timers/Makefile
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 CFLAGS += -O3 -Wl,-no-as-needed -Wall
-LDFLAGS += -lrt -lpthread -lm
+LDLIBS += -lrt -lpthread -lm
 
 # these are all "safe" tests that don't modify
 # system time or require escalated privileges
-- 
2.17.1



[PATCH 1/4] selftests: lib: allow to override CC in the top-level Makefile

2019-01-16 Thread Daniel Díaz
From: Fathi Boudra 

Relax CC assignment to allow to override CC in the top-level Makefile.

Signed-off-by: Denys Dmytriyenko 
---
 tools/testing/selftests/lib.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index 8b0f16409ed7..0f9c47eaaa6f 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -1,6 +1,6 @@
 # This mimics the top-level Makefile. We do it explicitly here so that this
 # Makefile can operate with or without the kbuild infrastructure.
-CC := $(CROSS_COMPILE)gcc
+CC ?= $(CROSS_COMPILE)gcc
 
 ifeq (0,$(MAKELEVEL))
 OUTPUT := $(shell pwd)
-- 
2.17.1



Re: [PATCH 4.9 00/71] 4.9.149-stable review

2019-01-07 Thread Daniel Díaz
Hello!

On Mon, 7 Jan 2019 at 07:06, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.9.149 release.
> There are 71 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.

With 4.9, we get this build error:
| 
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/fs/ext4/inode.c:
In function 'ext4_write_inode':
| 
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/fs/ext4/inode.c:5018:6:
error: implicit declaration of function 'sb_rdonly'
[-Werror=implicit-function-declaration]
|   sb_rdonly(inode->i_sb))
|   ^
|   CC  drivers/char/virtio_console.o
| In file included from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/linkage.h:4:0,
|  from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/fs.h:4,
|  from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/fs/ext4/inode.c:21:
| 
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/fs/ext4/inode.c:5021:15:
error: implicit declaration of function 'ext4_forced_shutdown'; did
you mean 'ext4_force_commit'? [-Werror=implicit-function-declaration]
|   if (unlikely(ext4_forced_shutdown(EXT4_SB(inode->i_sb
|^
| 
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/compiler.h:168:42:
note: in definition of macro 'unlikely'
|  # define unlikely(x) __builtin_expect(!!(x), 0)
|   ^

Greetings!

Daniel Díaz
daniel.d...@linaro.org



> Responses should be made by Wed Jan  9 10:53:04 UTC 2019.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.149-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman 
> Linux 4.9.149-rc1
>
> Tomas Winkler 
> tpm: tpm_i2c_nuvoton: use correct command duration for TPM 2.x
>
> Maciej W. Rozycki 
> rtc: m41t80: Correct alarm month range with RTC reads
>
> Will Deacon 
> arm64: KVM: Avoid setting the upper 32 bits of VTCR_EL2 to 1
>
> Vitaly Kuznetsov 
> x86/kvm/vmx: do not use vm-exit instruction length for fast MMIO when 
> running nested
>
> Georgy A Bystrenin 
> CIFS: Fix error mapping for SMB2_LOCK command which caused OFD lock 
> problem
>
> Aaro Koskinen 
> MIPS: OCTEON: mark RGMII interface disabled on OCTEON III
>
> Huacai Chen 
> MIPS: Align kernel load address to 64KB
>
> Huacai Chen 
> MIPS: Ensure pmd_present() returns false after pmd_mknotpresent()
>
> Hans Verkuil 
> media: v4l2-tpg: array index could become negative
>
> Hans Verkuil 
> media: vivid: free bitmap_cap when updating std/timings/etc.
>
> Nava kishore Manne 
> serial: uartps: Fix interrupt mask issue to handle the RX interrupts 
> properly
>
> Martin Blumenstingl 
> f2fs: fix validation of the block count in sanity_check_raw_super
>
> Breno Leitao 
> powerpc/tm: Set MSR[TS] just prior to recheckpoint
>
> Josef Bacik 
> btrfs: run delayed items before dropping the snapshot
>
> Filipe Manana 
> Btrfs: fix fsync of files with multiple hard links in new directories
>
> Macpaul Lin 
> cdc-acm: fix abnormal DATA RX issue for Mediatek Preloader.
>
> Johan Jonker 
> clk: rockchip: fix typo in rk3188 spdif_frac parent
>
> Lukas Wunner 
> spi: bcm2835: Avoid finishing transfer prematurely in IRQ mode
>
> Lukas Wunner 
> spi: bcm2835: Fix book-keeping of DMA termination
>
> Lukas Wunner 
> spi: bcm2835: Fix race on DMA termination
>
> Theodore Ts'o 
> ext4: check for shutdown and r/o file system in ext4_write_inode()
>
> Theodore Ts'o 
> ext4: force inode writes when nfsd calls commit_metadata()
>
> Theodore Ts'o 
> ext4: include terminating u32 in size of xattr entries when expanding 
> inodes
>
> ruippan (潘睿) 
> ext4: fix EXT4_IOC_GROUP_ADD ioctl
>
> Maurizio Lombardi 
> ext4: missing unlock/put_page() in ext4_try_to_write_inline_data()
>
> Pan Bian 
> ext4: fix possible use after free in ext4_quota_enable
>
> Ben Hutchings 
> perf pmu: Suppress potential format-truncation warning
>
> Miquel Raynal 
> platform-msi: Free descriptors in platform_msi_domain_free()
>
> Sean Christopher

Re: [PATCH 4.14 000/101] 4.14.92-stable review

2019-01-07 Thread Daniel Díaz
Hello!

On Mon, 7 Jan 2019 at 06:59, Greg Kroah-Hartman
 wrote:
> This is the start of the stable review cycle for the 4.14.92 release.
> There are 101 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.

We see these build errors with 4.14:
| 
/srv/oe/build/tmp-lkft-glibc/work-shared/juno/kernel-source/fs/btrfs/extent-tree.c:
In function 'btrfs_drop_snapshot':
| 
/srv/oe/build/tmp-lkft-glibc/work-shared/juno/kernel-source/fs/btrfs/extent-tree.c:9186:8:
error: too few arguments to function 'btrfs_run_delayed_items'
|   err = btrfs_run_delayed_items(trans);
| ^~~
| In file included from
/srv/oe/build/tmp-lkft-glibc/work-shared/juno/kernel-source/fs/btrfs/btrfs_inode.h:26:0,
|  from
/srv/oe/build/tmp-lkft-glibc/work-shared/juno/kernel-source/fs/btrfs/transaction.h:23,
|  from
/srv/oe/build/tmp-lkft-glibc/work-shared/juno/kernel-source/fs/btrfs/tree-log.h:23,
|  from
/srv/oe/build/tmp-lkft-glibc/work-shared/juno/kernel-source/fs/btrfs/extent-tree.c:30:
| 
/srv/oe/build/tmp-lkft-glibc/work-shared/juno/kernel-source/fs/btrfs/delayed-inode.h:114:5:
note: declared here
|  int btrfs_run_delayed_items(struct btrfs_trans_handle *trans,
|  ^~~

Greetings!

Daniel Díaz
daniel.d...@linaro.org



> Responses should be made by Wed Jan  9 10:53:00 UTC 2019.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.92-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
> -
> Pseudo-Shortlog of commits:
>
> Greg Kroah-Hartman 
> Linux 4.14.92-rc1
>
> Tomas Winkler 
> tpm: tpm_i2c_nuvoton: use correct command duration for TPM 2.x
>
> Tomas Winkler 
> tpm: tpm_try_transmit() refactor error flow.
>
> Maciej W. Rozycki 
> rtc: m41t80: Correct alarm month range with RTC reads
>
> Marc Zyngier 
> arm/arm64: KVM: vgic: Force VM halt when changing the active state of 
> GICv3 PPIs/SGIs
>
> Will Deacon 
> arm64: KVM: Avoid setting the upper 32 bits of VTCR_EL2 to 1
>
> Georgy A Bystrenin 
> CIFS: Fix error mapping for SMB2_LOCK command which caused OFD lock 
> problem
>
> Aaro Koskinen 
> MIPS: OCTEON: mark RGMII interface disabled on OCTEON III
>
> Paul Burton 
> MIPS: Expand MIPS32 ASIDs to 64 bits
>
> Huacai Chen 
> MIPS: Align kernel load address to 64KB
>
> Huacai Chen 
> MIPS: Ensure pmd_present() returns false after pmd_mknotpresent()
>
> Huacai Chen 
> MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3
>
> Paul Burton 
> MIPS: math-emu: Write-protect delay slot emulation pages
>
> Hans Verkuil 
> media: v4l2-tpg: array index could become negative
>
> Hans Verkuil 
> media: vivid: free bitmap_cap when updating std/timings/etc.
>
> Nava kishore Manne 
> serial: uartps: Fix interrupt mask issue to handle the RX interrupts 
> properly
>
> Martin Blumenstingl 
> f2fs: fix validation of the block count in sanity_check_raw_super
>
> Florian Westphal 
> netfilter: nf_conncount: don't skip eviction when age is negative
>
> Florian Westphal 
> netfilter: nf_conncount: fix garbage collection confirm race
>
> Yi-Hung Wei 
> netfilter: nf_conncount: Fix garbage collection with zones
>
> Pablo Neira Ayuso 
> netfilter: nf_conncount: expose connection list interface
>
> Florian Westphal 
> netfilter: xt_connlimit: don't store address in the conn nodes
>
> Breno Leitao 
> powerpc/tm: Set MSR[TS] just prior to recheckpoint
>
> Josef Bacik 
> btrfs: run delayed items before dropping the snapshot
>
> Filipe Manana 
> Btrfs: fix fsync of files with multiple hard links in new directories
>
> Macpaul Lin 
> cdc-acm: fix abnormal DATA RX issue for Mediatek Preloader.
>
> Tejun Heo 
> cgroup: fix CSS_TASK_ITER_PROCS
>
> Dmitry Eremin-Solenikov 
> crypto: testmgr - add AES-CFB tests
>
> Wenwen Wang 
> crypto: cavium/nitrox - fix a DMA pool free failure
>
> Johan Jonker 
> clk: rockchip: fix typo in rk3188 spdif_frac parent
>
> Lukas Wunner 
> spi: bcm2835: Avoid finishing transfer prematurely in IRQ mode
>
> Lukas Wunner 
> spi: bcm2835: Fix book-keeping of DMA termination
>
> Lukas Wunner 
> spi: bcm2835: Fix race on DMA termination
>
> Theodor

[PATCH] selftests: gpio: Find libmount with pkg-config if available

2018-10-16 Thread Daniel Díaz
If pkg-config is available, use it to define the CFLAGS and
LDLIBS needed for libmount; else, use the current hard-coded
paths and options.

Using pkg-config is very helpful for cross-compilation
environments, and is sometimes readily available on developer
boxes to ensure we get the right compiler/linker options for
the given package.

Signed-off-by: Daniel Díaz 
---
 tools/testing/selftests/gpio/Makefile | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index 46648427d537..f22b22aef7bf 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -1,7 +1,13 @@
 # SPDX-License-Identifier: GPL-2.0
 
-CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
-LDLIBS += -lmount -I/usr/include/libmount
+MOUNT_CFLAGS := $(shell pkg-config --cflags mount 2>/dev/null)
+MOUNT_LDLIBS := $(shell pkg-config --libs mount 2>/dev/null)
+ifeq ($(MOUNT_LDLIBS),)
+MOUNT_LDLIBS := -lmount -I/usr/include/libmount
+endif
+
+CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ $(MOUNT_CFLAGS)
+LDLIBS += $(MOUNT_LDLIBS)
 
 TEST_PROGS := gpio-mockup.sh
 TEST_FILES := gpio-mockup-sysfs.sh
-- 
2.17.1



[PATCH] selftests: gpio: Find libmount with pkg-config if available

2018-10-16 Thread Daniel Díaz
If pkg-config is available, use it to define the CFLAGS and
LDLIBS needed for libmount; else, use the current hard-coded
paths and options.

Using pkg-config is very helpful for cross-compilation
environments, and is sometimes readily available on developer
boxes to ensure we get the right compiler/linker options for
the given package.

Signed-off-by: Daniel Díaz 
---
 tools/testing/selftests/gpio/Makefile | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index 46648427d537..f22b22aef7bf 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -1,7 +1,13 @@
 # SPDX-License-Identifier: GPL-2.0
 
-CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
-LDLIBS += -lmount -I/usr/include/libmount
+MOUNT_CFLAGS := $(shell pkg-config --cflags mount 2>/dev/null)
+MOUNT_LDLIBS := $(shell pkg-config --libs mount 2>/dev/null)
+ifeq ($(MOUNT_LDLIBS),)
+MOUNT_LDLIBS := -lmount -I/usr/include/libmount
+endif
+
+CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ $(MOUNT_CFLAGS)
+LDLIBS += $(MOUNT_LDLIBS)
 
 TEST_PROGS := gpio-mockup.sh
 TEST_FILES := gpio-mockup-sysfs.sh
-- 
2.17.1



Re: [PATCH] selftests/ftrace: Use colored output when available

2018-10-16 Thread Daniel Díaz
Hello!

On Tue, 16 Oct 2018 at 12:43, Shuah Khan  wrote:
> On 10/16/2018 11:02 AM, Daniel Díaz wrote:
> > If test is being directly executed (with stdout opened on the
> > terminal) and the terminal capabilities indicate enough
> > colors, then use the existing scheme of green, red, and blue
> > to show when tests pass, fail or end in a different way.
> >
> > When running the tests redirecting the stdout, for instance,
> > to a file, then colors are not shown, thus producing a more
> > readable output.
> >
> > Signed-off-by: Daniel Díaz 
> > ---
>
> Hi Daniel,
> Thanks for the patch. Steve is working on adding this functionality. Please
> see the latest linux-kselftest next for the patch.

I hadn't seen today's discussion until after Steve replied to this
patch. Mine is based on your next branch, building upon Steve's patch.

These changes here are somewhat different, in that color is enabled
only if color is available in the terminal in the first place! And if
the standard output is redirected to a file (which is what Masami
reported today), then colors are avoided even if available.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


> Steve just sent an update to the patch to fix an issue. Please test and see
> if that solves the problem you are trying address with this patch.
>
> thanks,
> -- Shuah


Re: [PATCH] selftests/ftrace: Use colored output when available

2018-10-16 Thread Daniel Díaz
Hello!

On Tue, 16 Oct 2018 at 12:43, Shuah Khan  wrote:
> On 10/16/2018 11:02 AM, Daniel Díaz wrote:
> > If test is being directly executed (with stdout opened on the
> > terminal) and the terminal capabilities indicate enough
> > colors, then use the existing scheme of green, red, and blue
> > to show when tests pass, fail or end in a different way.
> >
> > When running the tests redirecting the stdout, for instance,
> > to a file, then colors are not shown, thus producing a more
> > readable output.
> >
> > Signed-off-by: Daniel Díaz 
> > ---
>
> Hi Daniel,
> Thanks for the patch. Steve is working on adding this functionality. Please
> see the latest linux-kselftest next for the patch.

I hadn't seen today's discussion until after Steve replied to this
patch. Mine is based on your next branch, building upon Steve's patch.

These changes here are somewhat different, in that color is enabled
only if color is available in the terminal in the first place! And if
the standard output is redirected to a file (which is what Masami
reported today), then colors are avoided even if available.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


> Steve just sent an update to the patch to fix an issue. Please test and see
> if that solves the problem you are trying address with this patch.
>
> thanks,
> -- Shuah


[PATCH] selftests/ftrace: Use colored output when available

2018-10-16 Thread Daniel Díaz
If test is being directly executed (with stdout opened on the
terminal) and the terminal capabilities indicate enough
colors, then use the existing scheme of green, red, and blue
to show when tests pass, fail or end in a different way.

When running the tests redirecting the stdout, for instance,
to a file, then colors are not shown, thus producing a more
readable output.

Signed-off-by: Daniel Díaz 
---
 tools/testing/selftests/ftrace/ftracetest | 29 +--
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index 4946b2edfcff..d987bbec675f 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -152,6 +152,21 @@ else
   date > $LOG_FILE
 fi
 
+# Define text colors
+# Check available colors on the terminal, if any
+ncolors=`tput colors 2>/dev/null`
+color_reset=
+color_red=
+color_green=
+color_blue=
+# If stdout exists and number of colors is eight or more, use them
+if [ -t 1 -a "$ncolors" -a "$ncolors" -ge 8 ]; then
+  color_reset="\e[0m"
+  color_red="\e[31m"
+  color_green="\e[32m"
+  color_blue="\e[34m"
+fi
+
 prlog() { # messages
   [ -z "$LOG_FILE" ] && echo -e "$@" || echo -e "$@" | tee -a $LOG_FILE
 }
@@ -195,37 +210,37 @@ test_on_instance() { # testfile
 eval_result() { # sigval
   case $1 in
 $PASS)
-  prlog "  [\e[32mPASS\e[30m]"
+  prlog "  [${color_green}PASS${color_reset}]"
   PASSED_CASES="$PASSED_CASES $CASENO"
   return 0
 ;;
 $FAIL)
-  prlog "  [\e[31mFAIL\e[30m]"
+  prlog "  [${color_red}FAIL${color_reset}]"
   FAILED_CASES="$FAILED_CASES $CASENO"
   return 1 # this is a bug.
 ;;
 $UNRESOLVED)
-  prlog "  [\e[34mUNRESOLVED\e[30m]"
+  prlog "  [${color_blue}UNRESOLVED${color_reset}]"
   UNRESOLVED_CASES="$UNRESOLVED_CASES $CASENO"
   return 1 # this is a kind of bug.. something happened.
 ;;
 $UNTESTED)
-  prlog "  [\e[34mUNTESTED\e[30m]"
+  prlog "  [${color_blue}UNTESTED${color_reset}]"
   UNTESTED_CASES="$UNTESTED_CASES $CASENO"
   return 0
 ;;
 $UNSUPPORTED)
-  prlog "  [\e[34mUNSUPPORTED\e[30m]"
+  prlog "  [${color_blue}UNSUPPORTED${color_reset}]"
   UNSUPPORTED_CASES="$UNSUPPORTED_CASES $CASENO"
   return $UNSUPPORTED_RESULT # depends on use case
 ;;
 $XFAIL)
-  prlog "  [\e[31mXFAIL\e[30m]"
+  prlog "  [${color_red}XFAIL${color_reset}]"
   XFAILED_CASES="$XFAILED_CASES $CASENO"
   return 0
 ;;
 *)
-  prlog "  [\e[34mUNDEFINED\e[30m]"
+  prlog "  [${color_blue}UNDEFINED${color_reset}]"
   UNDEFINED_CASES="$UNDEFINED_CASES $CASENO"
   return 1 # this must be a test bug
 ;;
-- 
2.17.1



[PATCH] selftests/ftrace: Use colored output when available

2018-10-16 Thread Daniel Díaz
If test is being directly executed (with stdout opened on the
terminal) and the terminal capabilities indicate enough
colors, then use the existing scheme of green, red, and blue
to show when tests pass, fail or end in a different way.

When running the tests redirecting the stdout, for instance,
to a file, then colors are not shown, thus producing a more
readable output.

Signed-off-by: Daniel Díaz 
---
 tools/testing/selftests/ftrace/ftracetest | 29 +--
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/tools/testing/selftests/ftrace/ftracetest 
b/tools/testing/selftests/ftrace/ftracetest
index 4946b2edfcff..d987bbec675f 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -152,6 +152,21 @@ else
   date > $LOG_FILE
 fi
 
+# Define text colors
+# Check available colors on the terminal, if any
+ncolors=`tput colors 2>/dev/null`
+color_reset=
+color_red=
+color_green=
+color_blue=
+# If stdout exists and number of colors is eight or more, use them
+if [ -t 1 -a "$ncolors" -a "$ncolors" -ge 8 ]; then
+  color_reset="\e[0m"
+  color_red="\e[31m"
+  color_green="\e[32m"
+  color_blue="\e[34m"
+fi
+
 prlog() { # messages
   [ -z "$LOG_FILE" ] && echo -e "$@" || echo -e "$@" | tee -a $LOG_FILE
 }
@@ -195,37 +210,37 @@ test_on_instance() { # testfile
 eval_result() { # sigval
   case $1 in
 $PASS)
-  prlog "  [\e[32mPASS\e[30m]"
+  prlog "  [${color_green}PASS${color_reset}]"
   PASSED_CASES="$PASSED_CASES $CASENO"
   return 0
 ;;
 $FAIL)
-  prlog "  [\e[31mFAIL\e[30m]"
+  prlog "  [${color_red}FAIL${color_reset}]"
   FAILED_CASES="$FAILED_CASES $CASENO"
   return 1 # this is a bug.
 ;;
 $UNRESOLVED)
-  prlog "  [\e[34mUNRESOLVED\e[30m]"
+  prlog "  [${color_blue}UNRESOLVED${color_reset}]"
   UNRESOLVED_CASES="$UNRESOLVED_CASES $CASENO"
   return 1 # this is a kind of bug.. something happened.
 ;;
 $UNTESTED)
-  prlog "  [\e[34mUNTESTED\e[30m]"
+  prlog "  [${color_blue}UNTESTED${color_reset}]"
   UNTESTED_CASES="$UNTESTED_CASES $CASENO"
   return 0
 ;;
 $UNSUPPORTED)
-  prlog "  [\e[34mUNSUPPORTED\e[30m]"
+  prlog "  [${color_blue}UNSUPPORTED${color_reset}]"
   UNSUPPORTED_CASES="$UNSUPPORTED_CASES $CASENO"
   return $UNSUPPORTED_RESULT # depends on use case
 ;;
 $XFAIL)
-  prlog "  [\e[31mXFAIL\e[30m]"
+  prlog "  [${color_red}XFAIL${color_reset}]"
   XFAILED_CASES="$XFAILED_CASES $CASENO"
   return 0
 ;;
 *)
-  prlog "  [\e[34mUNDEFINED\e[30m]"
+  prlog "  [${color_blue}UNDEFINED${color_reset}]"
   UNDEFINED_CASES="$UNDEFINED_CASES $CASENO"
   return 1 # this must be a test bug
 ;;
-- 
2.17.1



Re: [PATCH v3 1/2] selftests: gpio: restructure Makefile

2018-10-02 Thread Daniel Díaz
Hello!

On Fri, 7 Sep 2018 at 09:35, Daniel Díaz  wrote:
> From: Fathi Boudra 
>
> This patch cleans up the Makefile by restructuring a couple of
> things, namely:
> 1) change explicit paths in targets for variables
> 2) substitute a variable (BINARIES) for another, part of the
>selftests build system (TEST_PROGS_EXTENDED)
> 3) proper cleaning up of the EXTRA objects
>
> The resulting Makefile is much more readable and manageable.
>
> Signed-off-by: Fathi Boudra 
> Signed-off-by: Daniel Díaz 
> ---
>  tools/testing/selftests/gpio/Makefile | 32 +++-
>  1 file changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/tools/testing/selftests/gpio/Makefile 
> b/tools/testing/selftests/gpio/Makefile
> index 4665cdb..a4a01ec8 100644
> --- a/tools/testing/selftests/gpio/Makefile
> +++ b/tools/testing/selftests/gpio/Makefile
> @@ -1,28 +1,26 @@
>  # SPDX-License-Identifier: GPL-2.0
>
> +CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
> +LDLIBS += -lmount -I/usr/include/libmount
> +
>  TEST_PROGS := gpio-mockup.sh
> -TEST_FILES := gpio-mockup-sysfs.sh $(BINARIES)
> -BINARIES := gpio-mockup-chardev
> -EXTRA_PROGS := ../gpiogpio-event-mon ../gpiogpio-hammer ../gpiolsgpio
> -EXTRA_DIRS := ../gpioinclude/
> -EXTRA_OBJS := ../gpiogpio-event-mon-in.o ../gpiogpio-event-mon.o
> -EXTRA_OBJS += ../gpiogpio-hammer-in.o ../gpiogpio-utils.o ../gpiolsgpio-in.o
> -EXTRA_OBJS += ../gpiolsgpio.o
> +TEST_FILES := gpio-mockup-sysfs.sh
> +TEST_PROGS_EXTENDED := gpio-mockup-chardev
> +
> +GPIODIR := ../../../gpio
> +GPIOOBJ := gpio-utils.o
>
>  include ../lib.mk
>
> -all: $(BINARIES)
> +all: $(TEST_PROGS_EXTENDED)
>
>  override define CLEAN
> -   $(RM) $(BINARIES) $(EXTRA_PROGS) $(EXTRA_OBJS)
> -   $(RM) -r $(EXTRA_DIRS)
> +   $(RM) $(TEST_PROGS_EXTENDED)
> +   $(MAKE) -C $(GPIODIR) clean
>  endef
>
> -CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
> -LDLIBS += -lmount -I/usr/include/libmount
> -
> -$(BINARIES):| khdr
> -$(BINARIES): ../../../gpio/gpio-utils.o
> +$(TEST_PROGS_EXTENDED):| khdr
> +$(TEST_PROGS_EXTENDED): $(GPIODIR)/$(GPIOOBJ)
>
> -../../../gpio/gpio-utils.o:
> -   make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C ../../../gpio
> +$(GPIODIR)/$(GPIOOBJ):
> +   $(MAKE) -C $(GPIODIR)
> --
> 2.7.4

Ping on this series.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH v3 1/2] selftests: gpio: restructure Makefile

2018-10-02 Thread Daniel Díaz
Hello!

On Fri, 7 Sep 2018 at 09:35, Daniel Díaz  wrote:
> From: Fathi Boudra 
>
> This patch cleans up the Makefile by restructuring a couple of
> things, namely:
> 1) change explicit paths in targets for variables
> 2) substitute a variable (BINARIES) for another, part of the
>selftests build system (TEST_PROGS_EXTENDED)
> 3) proper cleaning up of the EXTRA objects
>
> The resulting Makefile is much more readable and manageable.
>
> Signed-off-by: Fathi Boudra 
> Signed-off-by: Daniel Díaz 
> ---
>  tools/testing/selftests/gpio/Makefile | 32 +++-
>  1 file changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/tools/testing/selftests/gpio/Makefile 
> b/tools/testing/selftests/gpio/Makefile
> index 4665cdb..a4a01ec8 100644
> --- a/tools/testing/selftests/gpio/Makefile
> +++ b/tools/testing/selftests/gpio/Makefile
> @@ -1,28 +1,26 @@
>  # SPDX-License-Identifier: GPL-2.0
>
> +CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
> +LDLIBS += -lmount -I/usr/include/libmount
> +
>  TEST_PROGS := gpio-mockup.sh
> -TEST_FILES := gpio-mockup-sysfs.sh $(BINARIES)
> -BINARIES := gpio-mockup-chardev
> -EXTRA_PROGS := ../gpiogpio-event-mon ../gpiogpio-hammer ../gpiolsgpio
> -EXTRA_DIRS := ../gpioinclude/
> -EXTRA_OBJS := ../gpiogpio-event-mon-in.o ../gpiogpio-event-mon.o
> -EXTRA_OBJS += ../gpiogpio-hammer-in.o ../gpiogpio-utils.o ../gpiolsgpio-in.o
> -EXTRA_OBJS += ../gpiolsgpio.o
> +TEST_FILES := gpio-mockup-sysfs.sh
> +TEST_PROGS_EXTENDED := gpio-mockup-chardev
> +
> +GPIODIR := ../../../gpio
> +GPIOOBJ := gpio-utils.o
>
>  include ../lib.mk
>
> -all: $(BINARIES)
> +all: $(TEST_PROGS_EXTENDED)
>
>  override define CLEAN
> -   $(RM) $(BINARIES) $(EXTRA_PROGS) $(EXTRA_OBJS)
> -   $(RM) -r $(EXTRA_DIRS)
> +   $(RM) $(TEST_PROGS_EXTENDED)
> +   $(MAKE) -C $(GPIODIR) clean
>  endef
>
> -CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
> -LDLIBS += -lmount -I/usr/include/libmount
> -
> -$(BINARIES):| khdr
> -$(BINARIES): ../../../gpio/gpio-utils.o
> +$(TEST_PROGS_EXTENDED):| khdr
> +$(TEST_PROGS_EXTENDED): $(GPIODIR)/$(GPIOOBJ)
>
> -../../../gpio/gpio-utils.o:
> -   make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C ../../../gpio
> +$(GPIODIR)/$(GPIOOBJ):
> +   $(MAKE) -C $(GPIODIR)
> --
> 2.7.4

Ping on this series.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


[PATCH v3 2/2] selftests: gpio: Fix OUTPUT directory in Makefile

2018-09-07 Thread Daniel Díaz
When simply running `make' from the selftests top dir, this
error shows up:

  cc -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/uuidgpio-mockup-chardev.c 
../../../gpio/gpio-utils.o  -lmount -o gpio-mockup-chardev
  cc: error: ../../../gpio/gpio-utils.o: No such file or directory
  : recipe for target 'gpio-mockup-chardev' failed
  make[1]: *** [gpio-mockup-chardev] Error 1

because the output directory is set to "selftests/gpio" and
all binaries built from ../../../gpio/ end up there. In fact,
they appear as, exempli gratia:
* gpiogpio-event-mon
* gpiogpio-hammer
* gpioinclude/
* gpiolsgpio
which is wrong, as it's missing a directory separator
somewhere.

This patch sets straight the output directory when building
../../../gpio/ so that binaries don't cross paths.

Signed-off-by: Daniel Díaz 
---
 tools/testing/selftests/gpio/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index a4a01ec8..4664842 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -7,7 +7,7 @@ TEST_PROGS := gpio-mockup.sh
 TEST_FILES := gpio-mockup-sysfs.sh
 TEST_PROGS_EXTENDED := gpio-mockup-chardev
 
-GPIODIR := ../../../gpio
+GPIODIR := $(realpath ../../../gpio)
 GPIOOBJ := gpio-utils.o
 
 include ../lib.mk
@@ -16,11 +16,11 @@ all: $(TEST_PROGS_EXTENDED)
 
 override define CLEAN
$(RM) $(TEST_PROGS_EXTENDED)
-   $(MAKE) -C $(GPIODIR) clean
+   $(MAKE) -C $(GPIODIR) OUTPUT=$(GPIODIR)/ clean
 endef
 
 $(TEST_PROGS_EXTENDED):| khdr
 $(TEST_PROGS_EXTENDED): $(GPIODIR)/$(GPIOOBJ)
 
 $(GPIODIR)/$(GPIOOBJ):
-   $(MAKE) -C $(GPIODIR)
+   $(MAKE) OUTPUT=$(GPIODIR)/ -C $(GPIODIR)
-- 
2.7.4



[PATCH v3 2/2] selftests: gpio: Fix OUTPUT directory in Makefile

2018-09-07 Thread Daniel Díaz
When simply running `make' from the selftests top dir, this
error shows up:

  cc -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/uuidgpio-mockup-chardev.c 
../../../gpio/gpio-utils.o  -lmount -o gpio-mockup-chardev
  cc: error: ../../../gpio/gpio-utils.o: No such file or directory
  : recipe for target 'gpio-mockup-chardev' failed
  make[1]: *** [gpio-mockup-chardev] Error 1

because the output directory is set to "selftests/gpio" and
all binaries built from ../../../gpio/ end up there. In fact,
they appear as, exempli gratia:
* gpiogpio-event-mon
* gpiogpio-hammer
* gpioinclude/
* gpiolsgpio
which is wrong, as it's missing a directory separator
somewhere.

This patch sets straight the output directory when building
../../../gpio/ so that binaries don't cross paths.

Signed-off-by: Daniel Díaz 
---
 tools/testing/selftests/gpio/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index a4a01ec8..4664842 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -7,7 +7,7 @@ TEST_PROGS := gpio-mockup.sh
 TEST_FILES := gpio-mockup-sysfs.sh
 TEST_PROGS_EXTENDED := gpio-mockup-chardev
 
-GPIODIR := ../../../gpio
+GPIODIR := $(realpath ../../../gpio)
 GPIOOBJ := gpio-utils.o
 
 include ../lib.mk
@@ -16,11 +16,11 @@ all: $(TEST_PROGS_EXTENDED)
 
 override define CLEAN
$(RM) $(TEST_PROGS_EXTENDED)
-   $(MAKE) -C $(GPIODIR) clean
+   $(MAKE) -C $(GPIODIR) OUTPUT=$(GPIODIR)/ clean
 endef
 
 $(TEST_PROGS_EXTENDED):| khdr
 $(TEST_PROGS_EXTENDED): $(GPIODIR)/$(GPIOOBJ)
 
 $(GPIODIR)/$(GPIOOBJ):
-   $(MAKE) -C $(GPIODIR)
+   $(MAKE) OUTPUT=$(GPIODIR)/ -C $(GPIODIR)
-- 
2.7.4



[PATCH v3 1/2] selftests: gpio: restructure Makefile

2018-09-07 Thread Daniel Díaz
From: Fathi Boudra 

This patch cleans up the Makefile by restructuring a couple of
things, namely:
1) change explicit paths in targets for variables
2) substitute a variable (BINARIES) for another, part of the
   selftests build system (TEST_PROGS_EXTENDED)
3) proper cleaning up of the EXTRA objects

The resulting Makefile is much more readable and manageable.

Signed-off-by: Fathi Boudra 
Signed-off-by: Daniel Díaz 
---
 tools/testing/selftests/gpio/Makefile | 32 +++-
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index 4665cdb..a4a01ec8 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -1,28 +1,26 @@
 # SPDX-License-Identifier: GPL-2.0
 
+CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
+LDLIBS += -lmount -I/usr/include/libmount
+
 TEST_PROGS := gpio-mockup.sh
-TEST_FILES := gpio-mockup-sysfs.sh $(BINARIES)
-BINARIES := gpio-mockup-chardev
-EXTRA_PROGS := ../gpiogpio-event-mon ../gpiogpio-hammer ../gpiolsgpio
-EXTRA_DIRS := ../gpioinclude/
-EXTRA_OBJS := ../gpiogpio-event-mon-in.o ../gpiogpio-event-mon.o
-EXTRA_OBJS += ../gpiogpio-hammer-in.o ../gpiogpio-utils.o ../gpiolsgpio-in.o
-EXTRA_OBJS += ../gpiolsgpio.o
+TEST_FILES := gpio-mockup-sysfs.sh
+TEST_PROGS_EXTENDED := gpio-mockup-chardev
+
+GPIODIR := ../../../gpio
+GPIOOBJ := gpio-utils.o
 
 include ../lib.mk
 
-all: $(BINARIES)
+all: $(TEST_PROGS_EXTENDED)
 
 override define CLEAN
-   $(RM) $(BINARIES) $(EXTRA_PROGS) $(EXTRA_OBJS)
-   $(RM) -r $(EXTRA_DIRS)
+   $(RM) $(TEST_PROGS_EXTENDED)
+   $(MAKE) -C $(GPIODIR) clean
 endef
 
-CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
-LDLIBS += -lmount -I/usr/include/libmount
-
-$(BINARIES):| khdr
-$(BINARIES): ../../../gpio/gpio-utils.o
+$(TEST_PROGS_EXTENDED):| khdr
+$(TEST_PROGS_EXTENDED): $(GPIODIR)/$(GPIOOBJ)
 
-../../../gpio/gpio-utils.o:
-   make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C ../../../gpio
+$(GPIODIR)/$(GPIOOBJ):
+   $(MAKE) -C $(GPIODIR)
-- 
2.7.4



[PATCH v3 1/2] selftests: gpio: restructure Makefile

2018-09-07 Thread Daniel Díaz
From: Fathi Boudra 

This patch cleans up the Makefile by restructuring a couple of
things, namely:
1) change explicit paths in targets for variables
2) substitute a variable (BINARIES) for another, part of the
   selftests build system (TEST_PROGS_EXTENDED)
3) proper cleaning up of the EXTRA objects

The resulting Makefile is much more readable and manageable.

Signed-off-by: Fathi Boudra 
Signed-off-by: Daniel Díaz 
---
 tools/testing/selftests/gpio/Makefile | 32 +++-
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index 4665cdb..a4a01ec8 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -1,28 +1,26 @@
 # SPDX-License-Identifier: GPL-2.0
 
+CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
+LDLIBS += -lmount -I/usr/include/libmount
+
 TEST_PROGS := gpio-mockup.sh
-TEST_FILES := gpio-mockup-sysfs.sh $(BINARIES)
-BINARIES := gpio-mockup-chardev
-EXTRA_PROGS := ../gpiogpio-event-mon ../gpiogpio-hammer ../gpiolsgpio
-EXTRA_DIRS := ../gpioinclude/
-EXTRA_OBJS := ../gpiogpio-event-mon-in.o ../gpiogpio-event-mon.o
-EXTRA_OBJS += ../gpiogpio-hammer-in.o ../gpiogpio-utils.o ../gpiolsgpio-in.o
-EXTRA_OBJS += ../gpiolsgpio.o
+TEST_FILES := gpio-mockup-sysfs.sh
+TEST_PROGS_EXTENDED := gpio-mockup-chardev
+
+GPIODIR := ../../../gpio
+GPIOOBJ := gpio-utils.o
 
 include ../lib.mk
 
-all: $(BINARIES)
+all: $(TEST_PROGS_EXTENDED)
 
 override define CLEAN
-   $(RM) $(BINARIES) $(EXTRA_PROGS) $(EXTRA_OBJS)
-   $(RM) -r $(EXTRA_DIRS)
+   $(RM) $(TEST_PROGS_EXTENDED)
+   $(MAKE) -C $(GPIODIR) clean
 endef
 
-CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
-LDLIBS += -lmount -I/usr/include/libmount
-
-$(BINARIES):| khdr
-$(BINARIES): ../../../gpio/gpio-utils.o
+$(TEST_PROGS_EXTENDED):| khdr
+$(TEST_PROGS_EXTENDED): $(GPIODIR)/$(GPIOOBJ)
 
-../../../gpio/gpio-utils.o:
-   make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C ../../../gpio
+$(GPIODIR)/$(GPIOOBJ):
+   $(MAKE) -C $(GPIODIR)
-- 
2.7.4



Re: [PATCH 18/18] cpupower: change strncpy+truncation to strlcpy

2018-08-14 Thread Daniel Díaz
Hello!


On 12 July 2018 at 20:26, Dominique Martinet  wrote:
> Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
>
> Signed-off-by: Dominique Martinet 
> ---
>
> Please see https://marc.info/?l=linux-kernel=153144450722324=2 (the
> first patch of the serie) for the motivation behind this patch
>
>  tools/power/cpupower/bench/parse.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/tools/power/cpupower/bench/parse.c 
> b/tools/power/cpupower/bench/parse.c
> index 9ba8a44ad2a7..1566b89989b2 100644
> --- a/tools/power/cpupower/bench/parse.c
> +++ b/tools/power/cpupower/bench/parse.c
> @@ -221,9 +221,8 @@ int prepare_config(const char *path, struct config 
> *config)
> sscanf(val, "%u", >cpu);
>
> else if (strcmp("governor", opt) == 0) {
> -   strncpy(config->governor, val,
> +   strlcpy(config->governor, val,
> sizeof(config->governor));
> -   config->governor[sizeof(config->governor) - 1] = '\0';
> }
>
> else if (strcmp("priority", opt) == 0) {
> --
> 2.17.1

I can't get cpupower to compile anymore now that it made its way to linux-next:
  [/linux/tools/power/cpupower]$ make
CC   lib/cpufreq.o
  [...]
  make[1]: Entering directory '/linux/tools/power/cpupower/bench'
CC   main.o
CC   parse.o
  parse.c: In function ‘prepare_config’:
  parse.c:224:4: warning: implicit declaration of function ‘strlcpy’
[-Wimplicit-function-declaration]
  strlcpy(config->governor, val,
  ^
CC   system.o
CC   benchmark.o
CC   cpufreq-bench
  .//parse.o: In function `prepare_config':
  /linux/tools/power/cpupower/bench/parse.c:224: undefined reference
to `strlcpy'
  collect2: error: ld returned 1 exit status
  Makefile:25: recipe for target 'cpufreq-bench' failed
  make[1]: *** [cpufreq-bench] Error 1
  make[1]: Leaving directory '/linux/tools/power/cpupower/bench'
  Makefile:258: recipe for target 'compile-bench' failed
  make: *** [compile-bench] Error 2

Does it need anything special to make?

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH 18/18] cpupower: change strncpy+truncation to strlcpy

2018-08-14 Thread Daniel Díaz
Hello!


On 12 July 2018 at 20:26, Dominique Martinet  wrote:
> Generated by scripts/coccinelle/misc/strncpy_truncation.cocci
>
> Signed-off-by: Dominique Martinet 
> ---
>
> Please see https://marc.info/?l=linux-kernel=153144450722324=2 (the
> first patch of the serie) for the motivation behind this patch
>
>  tools/power/cpupower/bench/parse.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/tools/power/cpupower/bench/parse.c 
> b/tools/power/cpupower/bench/parse.c
> index 9ba8a44ad2a7..1566b89989b2 100644
> --- a/tools/power/cpupower/bench/parse.c
> +++ b/tools/power/cpupower/bench/parse.c
> @@ -221,9 +221,8 @@ int prepare_config(const char *path, struct config 
> *config)
> sscanf(val, "%u", >cpu);
>
> else if (strcmp("governor", opt) == 0) {
> -   strncpy(config->governor, val,
> +   strlcpy(config->governor, val,
> sizeof(config->governor));
> -   config->governor[sizeof(config->governor) - 1] = '\0';
> }
>
> else if (strcmp("priority", opt) == 0) {
> --
> 2.17.1

I can't get cpupower to compile anymore now that it made its way to linux-next:
  [/linux/tools/power/cpupower]$ make
CC   lib/cpufreq.o
  [...]
  make[1]: Entering directory '/linux/tools/power/cpupower/bench'
CC   main.o
CC   parse.o
  parse.c: In function ‘prepare_config’:
  parse.c:224:4: warning: implicit declaration of function ‘strlcpy’
[-Wimplicit-function-declaration]
  strlcpy(config->governor, val,
  ^
CC   system.o
CC   benchmark.o
CC   cpufreq-bench
  .//parse.o: In function `prepare_config':
  /linux/tools/power/cpupower/bench/parse.c:224: undefined reference
to `strlcpy'
  collect2: error: ld returned 1 exit status
  Makefile:25: recipe for target 'cpufreq-bench' failed
  make[1]: *** [cpufreq-bench] Error 1
  make[1]: Leaving directory '/linux/tools/power/cpupower/bench'
  Makefile:258: recipe for target 'compile-bench' failed
  make: *** [compile-bench] Error 2

Does it need anything special to make?

Greetings!

Daniel Díaz
daniel.d...@linaro.org


[PATCH 2/2] arm: multi_v7_defconfig: Enable KSM.

2018-06-14 Thread Daniel Díaz
As per the documentation, Kernel Samepage Merging (available
since 2.6.32) is a memory-saving de-duplication feature,
enabled by CONFIG_KSM=y and activated via sysfs. More
information can be found here:
  https://www.kernel.org/doc/Documentation/vm/ksm.txt

When enabled in the kernel, the default is to not do anything
at all, until it is activated at run-time with:
  echo 1 > /sys/kernel/mm/ksm/run

Signed-off-by: Daniel Díaz 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 7e1c543..79eedf4d 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -133,6 +133,7 @@ CONFIG_SMP=y
 CONFIG_NR_CPUS=16
 CONFIG_HIGHPTE=y
 CONFIG_CMA=y
+CONFIG_KSM=y
 CONFIG_SECCOMP=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
-- 
2.7.4



[PATCH 2/2] arm: multi_v7_defconfig: Enable KSM.

2018-06-14 Thread Daniel Díaz
As per the documentation, Kernel Samepage Merging (available
since 2.6.32) is a memory-saving de-duplication feature,
enabled by CONFIG_KSM=y and activated via sysfs. More
information can be found here:
  https://www.kernel.org/doc/Documentation/vm/ksm.txt

When enabled in the kernel, the default is to not do anything
at all, until it is activated at run-time with:
  echo 1 > /sys/kernel/mm/ksm/run

Signed-off-by: Daniel Díaz 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 7e1c543..79eedf4d 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -133,6 +133,7 @@ CONFIG_SMP=y
 CONFIG_NR_CPUS=16
 CONFIG_HIGHPTE=y
 CONFIG_CMA=y
+CONFIG_KSM=y
 CONFIG_SECCOMP=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
-- 
2.7.4



[PATCH 1/2] x86: x86_64_defconfig: Enable KSM.

2018-06-14 Thread Daniel Díaz
As per the documentation, Kernel Samepage Merging (available
since 2.6.32) is a memory-saving de-duplication feature,
enabled by CONFIG_KSM=y and activated via sysfs. More
information can be found here:
  https://www.kernel.org/doc/Documentation/vm/ksm.txt

When enabled in the kernel, the default is to not do anything
at all, until it is activated at run-time with:
  echo 1 > /sys/kernel/mm/ksm/run

Signed-off-by: Daniel Díaz 
---
 arch/x86/configs/x86_64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/configs/x86_64_defconfig 
b/arch/x86/configs/x86_64_defconfig
index e32fc1f..8fd7396 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -48,6 +48,7 @@ CONFIG_MICROCODE_AMD=y
 CONFIG_X86_MSR=y
 CONFIG_X86_CPUID=y
 CONFIG_NUMA=y
+CONFIG_KSM=y
 CONFIG_X86_CHECK_BIOS_CORRUPTION=y
 # CONFIG_MTRR_SANITIZER is not set
 CONFIG_EFI=y
-- 
2.7.4



[PATCH 1/2] x86: x86_64_defconfig: Enable KSM.

2018-06-14 Thread Daniel Díaz
As per the documentation, Kernel Samepage Merging (available
since 2.6.32) is a memory-saving de-duplication feature,
enabled by CONFIG_KSM=y and activated via sysfs. More
information can be found here:
  https://www.kernel.org/doc/Documentation/vm/ksm.txt

When enabled in the kernel, the default is to not do anything
at all, until it is activated at run-time with:
  echo 1 > /sys/kernel/mm/ksm/run

Signed-off-by: Daniel Díaz 
---
 arch/x86/configs/x86_64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/configs/x86_64_defconfig 
b/arch/x86/configs/x86_64_defconfig
index e32fc1f..8fd7396 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -48,6 +48,7 @@ CONFIG_MICROCODE_AMD=y
 CONFIG_X86_MSR=y
 CONFIG_X86_CPUID=y
 CONFIG_NUMA=y
+CONFIG_KSM=y
 CONFIG_X86_CHECK_BIOS_CORRUPTION=y
 # CONFIG_MTRR_SANITIZER is not set
 CONFIG_EFI=y
-- 
2.7.4



Re: [PATCH] selftests: intel_pstate: Fix a condition which does not notify user that root permission is useful

2018-05-09 Thread Daniel Díaz
Hello!


On 05/09/2018 12:38 PM, Jeffrin Jose T wrote:
> aperf program uses /dev/cpu which is normally a root only
> access area. so in that case to successfully run thet test,
> root permissions are required.This patch is in the file run.sh.
> 
> Signed-off-by: Jeffrin Jose T <jeff...@rajagiritech.edu.in>
> ---
>  tools/testing/selftests/intel_pstate/run.sh | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/tools/testing/selftests/intel_pstate/run.sh 
> b/tools/testing/selftests/intel_pstate/run.sh
> index 23a2e4e9880e..05d35392dcfd 100755
> --- a/tools/testing/selftests/intel_pstate/run.sh
> +++ b/tools/testing/selftests/intel_pstate/run.sh
> @@ -31,6 +31,14 @@
>  
>  EVALUATE_ONLY=0
>  
> +uid=$(id -u)
> +if [ $uid -ne 0 ]; then
> +echo "---"
> +echo $msg please run this as root >&2
> +echo "---"
> +exit 0
> +fi
> +

Other tests simply use $UID. See:
  cpufreq/main.sh
  cpu-hotplug/cpu-on-off-test.sh
  efivarfs/efivarfs.sh
  gpio/gpio-mockup.sh
  memory-hotplug/mem-on-off-test.sh

This doesn't take into account the conditions for EVALUATE_ONLY: When
it's set non-zero, neither aperf nor cpupower run at all.

While this is under review, you might want to base your change on
Shuah's patch for skipping:

https://lists.linaro.org/pipermail/linux-kselftest-mirror/2018-May/001074.html


>  if ! uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ | grep -q x86; then
>   echo "$0 # Skipped: Test can only run on x86 architectures."
>   exit 0

I'd leave this check at the forefront, as this "hurdle" is
insurmountable in other architectures, whereas becoming root is attainable.

Thanks and greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH] selftests: intel_pstate: Fix a condition which does not notify user that root permission is useful

2018-05-09 Thread Daniel Díaz
Hello!


On 05/09/2018 12:38 PM, Jeffrin Jose T wrote:
> aperf program uses /dev/cpu which is normally a root only
> access area. so in that case to successfully run thet test,
> root permissions are required.This patch is in the file run.sh.
> 
> Signed-off-by: Jeffrin Jose T 
> ---
>  tools/testing/selftests/intel_pstate/run.sh | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/tools/testing/selftests/intel_pstate/run.sh 
> b/tools/testing/selftests/intel_pstate/run.sh
> index 23a2e4e9880e..05d35392dcfd 100755
> --- a/tools/testing/selftests/intel_pstate/run.sh
> +++ b/tools/testing/selftests/intel_pstate/run.sh
> @@ -31,6 +31,14 @@
>  
>  EVALUATE_ONLY=0
>  
> +uid=$(id -u)
> +if [ $uid -ne 0 ]; then
> +echo "---"
> +echo $msg please run this as root >&2
> +echo "---"
> +exit 0
> +fi
> +

Other tests simply use $UID. See:
  cpufreq/main.sh
  cpu-hotplug/cpu-on-off-test.sh
  efivarfs/efivarfs.sh
  gpio/gpio-mockup.sh
  memory-hotplug/mem-on-off-test.sh

This doesn't take into account the conditions for EVALUATE_ONLY: When
it's set non-zero, neither aperf nor cpupower run at all.

While this is under review, you might want to base your change on
Shuah's patch for skipping:

https://lists.linaro.org/pipermail/linux-kselftest-mirror/2018-May/001074.html


>  if ! uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ | grep -q x86; then
>   echo "$0 # Skipped: Test can only run on x86 architectures."
>   exit 0

I'd leave this check at the forefront, as this "hurdle" is
insurmountable in other architectures, whereas becoming root is attainable.

Thanks and greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: kselftest archives etc.

2018-04-27 Thread Daniel Díaz Rodríguez
Hello!


On 27 April 2018 at 19:17, Randy Dunlap <rdun...@infradead.org> wrote:
[...]
> so I looked for an archive of linux-kselft...@vger.kernel.org.
> http://vger.kernel.org/vger-lists.html lists all mailing lists and
> (some of) their archives, but none for linux-kselftest.

For what it's worth, as of last November Linaro is also hosting a
mirror of this mailing list:
  https://lists.linaro.org/pipermail/linux-kselftest-mirror/

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: kselftest archives etc.

2018-04-27 Thread Daniel Díaz Rodríguez
Hello!


On 27 April 2018 at 19:17, Randy Dunlap  wrote:
[...]
> so I looked for an archive of linux-kselft...@vger.kernel.org.
> http://vger.kernel.org/vger-lists.html lists all mailing lists and
> (some of) their archives, but none for linux-kselftest.

For what it's worth, as of last November Linaro is also hosting a
mirror of this mailing list:
  https://lists.linaro.org/pipermail/linux-kselftest-mirror/

Greetings!

Daniel Díaz
daniel.d...@linaro.org


[PATCH] selftests/intel_pstate: Enhance table printing

2018-04-12 Thread Daniel Díaz
Using coreutils' pr, a nicer table is printed out with the
results.

Signed-off-by: Daniel Díaz <daniel.d...@linaro.org>
---
 tools/testing/selftests/intel_pstate/run.sh | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/intel_pstate/run.sh 
b/tools/testing/selftests/intel_pstate/run.sh
index bde31a0..a40068b 100755
--- a/tools/testing/selftests/intel_pstate/run.sh
+++ b/tools/testing/selftests/intel_pstate/run.sh
@@ -92,18 +92,28 @@ done
 
 [ $EVALUATE_ONLY -eq 0 ] && cpupower frequency-set -g powersave 
--max=${max_freq}MHz >& /dev/null
 
-echo 
"=="
+echo ""
 echo "The marketing frequency of the cpu is $mkt_freq MHz"
 echo "The maximum frequency of the cpu is $max_freq MHz"
 echo "The minimum frequency of the cpu is $min_freq MHz"
 
 # make a pretty table
-echo "Target  Actual  Difference MSR(0x199) max_perf_pct"
+echo "Target Actual Difference MSR(0x199) max_perf_pct" | tr " " "\n" > 
/tmp/result.tab
 for freq in `seq $max_freq -100 $min_freq`
 do
result_freq=$(cat /tmp/result.${freq} | grep "cpu MHz" | awk ' { print 
$4 } ' | awk -F "." ' { print $1 } ')
msr=$(cat /tmp/result.${freq} | grep "msr" | awk ' { print $3 } ')
max_perf_pct=$(cat /tmp/result.${freq} | grep "max_perf_pct" | awk ' { 
print $2 } ' )
-   echo " $freq$result_freq  $(($result_freq-$freq))   
   $msr  $(($max_perf_pct*$max_freq))"
+   cat >> /tmp/result.tab << EOF
+$freq
+$result_freq
+$((result_freq - freq))
+$msr
+$((max_perf_pct * max_freq))
+EOF
 done
+
+# print the table
+pr -aTt -5 < /tmp/result.tab
+
 exit 0
-- 
2.7.4



[PATCH] selftests/intel_pstate: Enhance table printing

2018-04-12 Thread Daniel Díaz
Using coreutils' pr, a nicer table is printed out with the
results.

Signed-off-by: Daniel Díaz 
---
 tools/testing/selftests/intel_pstate/run.sh | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/intel_pstate/run.sh 
b/tools/testing/selftests/intel_pstate/run.sh
index bde31a0..a40068b 100755
--- a/tools/testing/selftests/intel_pstate/run.sh
+++ b/tools/testing/selftests/intel_pstate/run.sh
@@ -92,18 +92,28 @@ done
 
 [ $EVALUATE_ONLY -eq 0 ] && cpupower frequency-set -g powersave 
--max=${max_freq}MHz >& /dev/null
 
-echo 
"=="
+echo ""
 echo "The marketing frequency of the cpu is $mkt_freq MHz"
 echo "The maximum frequency of the cpu is $max_freq MHz"
 echo "The minimum frequency of the cpu is $min_freq MHz"
 
 # make a pretty table
-echo "Target  Actual  Difference MSR(0x199) max_perf_pct"
+echo "Target Actual Difference MSR(0x199) max_perf_pct" | tr " " "\n" > 
/tmp/result.tab
 for freq in `seq $max_freq -100 $min_freq`
 do
result_freq=$(cat /tmp/result.${freq} | grep "cpu MHz" | awk ' { print 
$4 } ' | awk -F "." ' { print $1 } ')
msr=$(cat /tmp/result.${freq} | grep "msr" | awk ' { print $3 } ')
max_perf_pct=$(cat /tmp/result.${freq} | grep "max_perf_pct" | awk ' { 
print $2 } ' )
-   echo " $freq$result_freq  $(($result_freq-$freq))   
   $msr  $(($max_perf_pct*$max_freq))"
+   cat >> /tmp/result.tab << EOF
+$freq
+$result_freq
+$((result_freq - freq))
+$msr
+$((max_perf_pct * max_freq))
+EOF
 done
+
+# print the table
+pr -aTt -5 < /tmp/result.tab
+
 exit 0
-- 
2.7.4



[PATCH] selftests/intel_pstate: Improve test, minor fixes

2018-04-10 Thread Daniel Díaz
A few changes improve the overall usability of the test:
* fix a hard-coded maximum frequency (3300),
* don't adjust the CPU frequency if only evaluating results,
* fix a comparison for multiple frequencies.

A symptom of that last issue looked like this:
  ./run.sh: line 107: [: too many arguments
  ./run.sh: line 110: 3099
  3099
  3100-3100: syntax error in expression (error token is \"3099
  3100-3100\")

Because a check will count how many differente frequencies
there are among the CPUs of the system, and after they are
tallied another read is performed, which might produce
different results.

Signed-off-by: Daniel Díaz <daniel.d...@linaro.org>
---
 tools/testing/selftests/intel_pstate/run.sh | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/tools/testing/selftests/intel_pstate/run.sh 
b/tools/testing/selftests/intel_pstate/run.sh
index c670359..bde31a0 100755
--- a/tools/testing/selftests/intel_pstate/run.sh
+++ b/tools/testing/selftests/intel_pstate/run.sh
@@ -48,11 +48,12 @@ function run_test () {
 
echo "sleeping for 5 seconds"
sleep 5
-   num_freqs=$(cat /proc/cpuinfo | grep MHz | sort -u | wc -l)
-   if [ $num_freqs -le 2 ]; then
-   cat /proc/cpuinfo | grep MHz | sort -u | tail -1 > 
/tmp/result.$1
+   grep MHz /proc/cpuinfo | sort -u > /tmp/result.freqs
+   num_freqs=$(wc -l /tmp/result.freqs | awk ' { print $1 } ')
+   if [ $num_freqs -ge 2 ]; then
+   tail -n 1 /tmp/result.freqs > /tmp/result.$1
else
-   cat /proc/cpuinfo | grep MHz | sort -u > /tmp/result.$1
+   cp /tmp/result.freqs /tmp/result.$1
fi
./msr 0 >> /tmp/result.$1
 
@@ -82,21 +83,20 @@ _max_freq=$(cpupower frequency-info -l | tail -1 | awk ' { 
print $2 } ')
 max_freq=$(($_max_freq / 1000))
 
 
-for freq in `seq $max_freq -100 $min_freq`
+[ $EVALUATE_ONLY -eq 0 ] && for freq in `seq $max_freq -100 $min_freq`
 do
echo "Setting maximum frequency to $freq"
cpupower frequency-set -g powersave --max=${freq}MHz >& /dev/null
-   [ $EVALUATE_ONLY -eq 0 ] && run_test $freq
+   run_test $freq
 done
 
-echo 
"=="
+[ $EVALUATE_ONLY -eq 0 ] && cpupower frequency-set -g powersave 
--max=${max_freq}MHz >& /dev/null
 
+echo 
"=="
 echo "The marketing frequency of the cpu is $mkt_freq MHz"
 echo "The maximum frequency of the cpu is $max_freq MHz"
 echo "The minimum frequency of the cpu is $min_freq MHz"
 
-cpupower frequency-set -g powersave --max=${max_freq}MHz >& /dev/null
-
 # make a pretty table
 echo "Target  Actual  Difference MSR(0x199) max_perf_pct"
 for freq in `seq $max_freq -100 $min_freq`
@@ -104,10 +104,6 @@ do
result_freq=$(cat /tmp/result.${freq} | grep "cpu MHz" | awk ' { print 
$4 } ' | awk -F "." ' { print $1 } ')
msr=$(cat /tmp/result.${freq} | grep "msr" | awk ' { print $3 } ')
max_perf_pct=$(cat /tmp/result.${freq} | grep "max_perf_pct" | awk ' { 
print $2 } ' )
-   if [ $result_freq -eq $freq ]; then
-   echo " $freq$result_freq 0  $msr
 $(($max_perf_pct*3300))"
-   else
-   echo " $freq$result_freq  
$(($result_freq-$freq))  $msr  $(($max_perf_pct*$max_freq))"
-   fi
+   echo " $freq$result_freq  $(($result_freq-$freq))   
   $msr  $(($max_perf_pct*$max_freq))"
 done
 exit 0
-- 
2.7.4



[PATCH] selftests/intel_pstate: Improve test, minor fixes

2018-04-10 Thread Daniel Díaz
A few changes improve the overall usability of the test:
* fix a hard-coded maximum frequency (3300),
* don't adjust the CPU frequency if only evaluating results,
* fix a comparison for multiple frequencies.

A symptom of that last issue looked like this:
  ./run.sh: line 107: [: too many arguments
  ./run.sh: line 110: 3099
  3099
  3100-3100: syntax error in expression (error token is \"3099
  3100-3100\")

Because a check will count how many differente frequencies
there are among the CPUs of the system, and after they are
tallied another read is performed, which might produce
different results.

Signed-off-by: Daniel Díaz 
---
 tools/testing/selftests/intel_pstate/run.sh | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/tools/testing/selftests/intel_pstate/run.sh 
b/tools/testing/selftests/intel_pstate/run.sh
index c670359..bde31a0 100755
--- a/tools/testing/selftests/intel_pstate/run.sh
+++ b/tools/testing/selftests/intel_pstate/run.sh
@@ -48,11 +48,12 @@ function run_test () {
 
echo "sleeping for 5 seconds"
sleep 5
-   num_freqs=$(cat /proc/cpuinfo | grep MHz | sort -u | wc -l)
-   if [ $num_freqs -le 2 ]; then
-   cat /proc/cpuinfo | grep MHz | sort -u | tail -1 > 
/tmp/result.$1
+   grep MHz /proc/cpuinfo | sort -u > /tmp/result.freqs
+   num_freqs=$(wc -l /tmp/result.freqs | awk ' { print $1 } ')
+   if [ $num_freqs -ge 2 ]; then
+   tail -n 1 /tmp/result.freqs > /tmp/result.$1
else
-   cat /proc/cpuinfo | grep MHz | sort -u > /tmp/result.$1
+   cp /tmp/result.freqs /tmp/result.$1
fi
./msr 0 >> /tmp/result.$1
 
@@ -82,21 +83,20 @@ _max_freq=$(cpupower frequency-info -l | tail -1 | awk ' { 
print $2 } ')
 max_freq=$(($_max_freq / 1000))
 
 
-for freq in `seq $max_freq -100 $min_freq`
+[ $EVALUATE_ONLY -eq 0 ] && for freq in `seq $max_freq -100 $min_freq`
 do
echo "Setting maximum frequency to $freq"
cpupower frequency-set -g powersave --max=${freq}MHz >& /dev/null
-   [ $EVALUATE_ONLY -eq 0 ] && run_test $freq
+   run_test $freq
 done
 
-echo 
"=="
+[ $EVALUATE_ONLY -eq 0 ] && cpupower frequency-set -g powersave 
--max=${max_freq}MHz >& /dev/null
 
+echo 
"=="
 echo "The marketing frequency of the cpu is $mkt_freq MHz"
 echo "The maximum frequency of the cpu is $max_freq MHz"
 echo "The minimum frequency of the cpu is $min_freq MHz"
 
-cpupower frequency-set -g powersave --max=${max_freq}MHz >& /dev/null
-
 # make a pretty table
 echo "Target  Actual  Difference MSR(0x199) max_perf_pct"
 for freq in `seq $max_freq -100 $min_freq`
@@ -104,10 +104,6 @@ do
result_freq=$(cat /tmp/result.${freq} | grep "cpu MHz" | awk ' { print 
$4 } ' | awk -F "." ' { print $1 } ')
msr=$(cat /tmp/result.${freq} | grep "msr" | awk ' { print $3 } ')
max_perf_pct=$(cat /tmp/result.${freq} | grep "max_perf_pct" | awk ' { 
print $2 } ' )
-   if [ $result_freq -eq $freq ]; then
-   echo " $freq$result_freq 0  $msr
 $(($max_perf_pct*3300))"
-   else
-   echo " $freq$result_freq  
$(($result_freq-$freq))  $msr  $(($max_perf_pct*$max_freq))"
-   fi
+   echo " $freq$result_freq  $(($result_freq-$freq))   
   $msr  $(($max_perf_pct*$max_freq))"
 done
 exit 0
-- 
2.7.4



[PATCH v2] selftests: gpio: restructure Makefile

2018-02-21 Thread Daniel Díaz
From: Fathi Boudra <fathi.bou...@linaro.org>

This patch cleans up the Makefile by restructuring a couple of
things, namely:
1) change explicit paths in targets for variables
2) substitute a variable (BINARIES) for another, part of the
   selftests build system (TEST_PROGS_EXTENDED)
3) proper cleaning up of the EXTRA objects

The resulting Makefile is much more readable and manageable.

Signed-off-by: Fathi Boudra <fathi.bou...@linaro.org>
Signed-off-by: Daniel Díaz <daniel.d...@linaro.org>
---
v2: Add commit description

 tools/testing/selftests/gpio/Makefile | 36 +--
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index 1bbb475..6890f61 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -1,31 +1,29 @@
 # SPDX-License-Identifier: GPL-2.0
 
+CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
+LDLIBS += -lmount -I/usr/include/libmount
+
 TEST_PROGS := gpio-mockup.sh
-TEST_FILES := gpio-mockup-sysfs.sh $(BINARIES)
-BINARIES := gpio-mockup-chardev
-EXTRA_PROGS := ../gpiogpio-event-mon ../gpiogpio-hammer ../gpiolsgpio
-EXTRA_DIRS := ../gpioinclude/
-EXTRA_OBJS := ../gpiogpio-event-mon-in.o ../gpiogpio-event-mon.o
-EXTRA_OBJS += ../gpiogpio-hammer-in.o ../gpiogpio-utils.o ../gpiolsgpio-in.o
-EXTRA_OBJS += ../gpiolsgpio.o
+TEST_FILES := gpio-mockup-sysfs.sh
+TEST_PROGS_EXTENDED := gpio-mockup-chardev
 
-include ../lib.mk
+GPIODIR := ../../../gpio
+GPIOOBJ := gpio-utils.o
+GPIOINC := gpio.h
 
-all: $(BINARIES)
+all: $(GPIOINC) $(TEST_PROGS_EXTENDED)
 
 override define CLEAN
-   $(RM) $(BINARIES) $(EXTRA_PROGS) $(EXTRA_OBJS)
-   $(RM) -r $(EXTRA_DIRS)
+   $(RM) $(TEST_PROGS_EXTENDED)
+   $(MAKE) -C $(GPIODIR) clean
 endef
 
-CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
-LDLIBS += -lmount -I/usr/include/libmount
-
-$(BINARIES): ../../../gpio/gpio-utils.o ../../../../usr/include/linux/gpio.h
+include ../lib.mk
 
-../../../gpio/gpio-utils.o:
-   make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C ../../../gpio
+$(TEST_PROGS_EXTENDED): $(GPIODIR)/$(GPIOOBJ)
 
-../../../../usr/include/linux/gpio.h:
-   make -C ../../../.. headers_install INSTALL_HDR_PATH=$(shell 
pwd)/../../../../usr/
+$(GPIODIR)/$(GPIOOBJ):
+   $(MAKE) -C $(GPIODIR)
 
+$(GPIOINC):
+   $(MAKE) -C ../../../.. headers_install
-- 
2.7.4



[PATCH v2] selftests: gpio: restructure Makefile

2018-02-21 Thread Daniel Díaz
From: Fathi Boudra 

This patch cleans up the Makefile by restructuring a couple of
things, namely:
1) change explicit paths in targets for variables
2) substitute a variable (BINARIES) for another, part of the
   selftests build system (TEST_PROGS_EXTENDED)
3) proper cleaning up of the EXTRA objects

The resulting Makefile is much more readable and manageable.

Signed-off-by: Fathi Boudra 
Signed-off-by: Daniel Díaz 
---
v2: Add commit description

 tools/testing/selftests/gpio/Makefile | 36 +--
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index 1bbb475..6890f61 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -1,31 +1,29 @@
 # SPDX-License-Identifier: GPL-2.0
 
+CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
+LDLIBS += -lmount -I/usr/include/libmount
+
 TEST_PROGS := gpio-mockup.sh
-TEST_FILES := gpio-mockup-sysfs.sh $(BINARIES)
-BINARIES := gpio-mockup-chardev
-EXTRA_PROGS := ../gpiogpio-event-mon ../gpiogpio-hammer ../gpiolsgpio
-EXTRA_DIRS := ../gpioinclude/
-EXTRA_OBJS := ../gpiogpio-event-mon-in.o ../gpiogpio-event-mon.o
-EXTRA_OBJS += ../gpiogpio-hammer-in.o ../gpiogpio-utils.o ../gpiolsgpio-in.o
-EXTRA_OBJS += ../gpiolsgpio.o
+TEST_FILES := gpio-mockup-sysfs.sh
+TEST_PROGS_EXTENDED := gpio-mockup-chardev
 
-include ../lib.mk
+GPIODIR := ../../../gpio
+GPIOOBJ := gpio-utils.o
+GPIOINC := gpio.h
 
-all: $(BINARIES)
+all: $(GPIOINC) $(TEST_PROGS_EXTENDED)
 
 override define CLEAN
-   $(RM) $(BINARIES) $(EXTRA_PROGS) $(EXTRA_OBJS)
-   $(RM) -r $(EXTRA_DIRS)
+   $(RM) $(TEST_PROGS_EXTENDED)
+   $(MAKE) -C $(GPIODIR) clean
 endef
 
-CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
-LDLIBS += -lmount -I/usr/include/libmount
-
-$(BINARIES): ../../../gpio/gpio-utils.o ../../../../usr/include/linux/gpio.h
+include ../lib.mk
 
-../../../gpio/gpio-utils.o:
-   make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C ../../../gpio
+$(TEST_PROGS_EXTENDED): $(GPIODIR)/$(GPIOOBJ)
 
-../../../../usr/include/linux/gpio.h:
-   make -C ../../../.. headers_install INSTALL_HDR_PATH=$(shell 
pwd)/../../../../usr/
+$(GPIODIR)/$(GPIOOBJ):
+   $(MAKE) -C $(GPIODIR)
 
+$(GPIOINC):
+   $(MAKE) -C ../../../.. headers_install
-- 
2.7.4



Re: [PATCH 2/2] selftests/gpio: Fix OUTPUT directory in Makefile

2018-02-21 Thread Daniel Díaz
Hello!


On 02/21/2018 04:09 PM, Andy Shevchenko wrote:
> On Wed, Feb 21, 2018 at 11:52 PM, Daniel Díaz <daniel.d...@linaro.org> wrote:
>> When simply running `make' from the selftests top dir, this
>> error shows up:
>>
>>   cc -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ 
>> -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuid
>> gpio-mockup-chardev.c ../../../gpio/gpio-utils.o  -lmount -o 
>> gpio-mockup-chardev
>>   cc: error: ../../../gpio/gpio-utils.o: No such file or directory
>>   : recipe for target 'gpio-mockup-chardev' failed
>>   make[1]: *** [gpio-mockup-chardev] Error 1
>>
>> because the output directory is set to "selftests/gpio" and
>> all binaries built from ../../../gpio/ end up there. In fact,
>> they appear as, exempli gratia:
>> * gpiogpio-event-mon
>> * gpiogpio-hammer
>> * gpioinclude/
>> * gpiolsgpio
>> which is wrong, as it's missing directory separator somewhere.
>>
>> This patch sets straight the output directory when building
>> ../../../gpio/ so that binaries don't cross paths.
> 
> This patch doesn't sound right like previous one.
> Does selftest infrastructure have it's own build system like tools?

Yes. See linux/Documentation/dev-tools/kselftest.rst § "Contributing new
tests (details)" or linux/tools/testing/selftests/lib.mk itself, which
starts saying:
# This mimics the top-level Makefile. We do it explicitly here so that this
# Makefile can operate with or without the kbuild infrastructure.


> Does it use tools' one?

No, as far as I can tell. If anything, it uses it only to build inside
tools/gpio/ whatever is needed.


> What's wrong with the current approach?

When building from the tools/testing/selftests/ directory, binaries end
up in the current directory (and with an improper name), which is
undesirable. The gpio/ selftest fails to build when make'ing from there.

This is with current master:
  /linux/tools/testing/selftests$ make
  make[1]: Entering directory '/linux/tools/testing/selftests/gpio'
  [...]
  gcc -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
gpio-mockup-chardev.c ../../../gpio/gpio-utils.o
../../../../usr/include/linux/gpio.h  -lmount -I/usr/include/libmount -o
gpio-mockup-chardev
  gcc: error: ../../../gpio/gpio-utils.o: No such file or directory
  : recipe for target 'gpio-mockup-chardev' failed
  make[1]: *** [gpio-mockup-chardev] Error 1
  make[1]: Leaving directory '/linux/tools/testing/selftests/gpio'
  Makefile:32: recipe for target 'all' failed
  make: *** [all] Error 2


> Why do you need tools in selftests?

I'll leave that to the test author to answer, as this is only a fix in
the Makefile, but the only part of tools needed here is tools/gpio/*,
for make'ing the object files this test will be built against.

Thanks and greetings!

Daniel Díaz
daniel.d...@linaro.org



Re: [PATCH 2/2] selftests/gpio: Fix OUTPUT directory in Makefile

2018-02-21 Thread Daniel Díaz
Hello!


On 02/21/2018 04:09 PM, Andy Shevchenko wrote:
> On Wed, Feb 21, 2018 at 11:52 PM, Daniel Díaz  wrote:
>> When simply running `make' from the selftests top dir, this
>> error shows up:
>>
>>   cc -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ 
>> -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuid
>> gpio-mockup-chardev.c ../../../gpio/gpio-utils.o  -lmount -o 
>> gpio-mockup-chardev
>>   cc: error: ../../../gpio/gpio-utils.o: No such file or directory
>>   : recipe for target 'gpio-mockup-chardev' failed
>>   make[1]: *** [gpio-mockup-chardev] Error 1
>>
>> because the output directory is set to "selftests/gpio" and
>> all binaries built from ../../../gpio/ end up there. In fact,
>> they appear as, exempli gratia:
>> * gpiogpio-event-mon
>> * gpiogpio-hammer
>> * gpioinclude/
>> * gpiolsgpio
>> which is wrong, as it's missing directory separator somewhere.
>>
>> This patch sets straight the output directory when building
>> ../../../gpio/ so that binaries don't cross paths.
> 
> This patch doesn't sound right like previous one.
> Does selftest infrastructure have it's own build system like tools?

Yes. See linux/Documentation/dev-tools/kselftest.rst § "Contributing new
tests (details)" or linux/tools/testing/selftests/lib.mk itself, which
starts saying:
# This mimics the top-level Makefile. We do it explicitly here so that this
# Makefile can operate with or without the kbuild infrastructure.


> Does it use tools' one?

No, as far as I can tell. If anything, it uses it only to build inside
tools/gpio/ whatever is needed.


> What's wrong with the current approach?

When building from the tools/testing/selftests/ directory, binaries end
up in the current directory (and with an improper name), which is
undesirable. The gpio/ selftest fails to build when make'ing from there.

This is with current master:
  /linux/tools/testing/selftests$ make
  make[1]: Entering directory '/linux/tools/testing/selftests/gpio'
  [...]
  gcc -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
gpio-mockup-chardev.c ../../../gpio/gpio-utils.o
../../../../usr/include/linux/gpio.h  -lmount -I/usr/include/libmount -o
gpio-mockup-chardev
  gcc: error: ../../../gpio/gpio-utils.o: No such file or directory
  : recipe for target 'gpio-mockup-chardev' failed
  make[1]: *** [gpio-mockup-chardev] Error 1
  make[1]: Leaving directory '/linux/tools/testing/selftests/gpio'
  Makefile:32: recipe for target 'all' failed
  make: *** [all] Error 2


> Why do you need tools in selftests?

I'll leave that to the test author to answer, as this is only a fix in
the Makefile, but the only part of tools needed here is tools/gpio/*,
for make'ing the object files this test will be built against.

Thanks and greetings!

Daniel Díaz
daniel.d...@linaro.org



Re: [PATCH 1/2] selftests: gpio: restructure Makefile

2018-02-21 Thread Daniel Díaz
Hello!


On 02/21/2018 04:06 PM, Andy Shevchenko wrote:
> On Wed, Feb 21, 2018 at 11:52 PM, Daniel Díaz <daniel.d...@linaro.org> wrote:
>> From: Fathi Boudra <fathi.bou...@linaro.org>
> 
> What are you doing here?
> Why?
> What is the benefit of it?

Thanks for looking into this. I will resend with description.

The purpose of the patch is to clean up the Makefile by restructuring
explicit paths in targets for variables, substituting a variable
(BINARIES) for one of the build system (TEST_PROGS_EXTENDED), and proper
cleaning up of the EXTRA objects.

The resulting Makefile is much more readable and manageable.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


Re: [PATCH 1/2] selftests: gpio: restructure Makefile

2018-02-21 Thread Daniel Díaz
Hello!


On 02/21/2018 04:06 PM, Andy Shevchenko wrote:
> On Wed, Feb 21, 2018 at 11:52 PM, Daniel Díaz  wrote:
>> From: Fathi Boudra 
> 
> What are you doing here?
> Why?
> What is the benefit of it?

Thanks for looking into this. I will resend with description.

The purpose of the patch is to clean up the Makefile by restructuring
explicit paths in targets for variables, substituting a variable
(BINARIES) for one of the build system (TEST_PROGS_EXTENDED), and proper
cleaning up of the EXTRA objects.

The resulting Makefile is much more readable and manageable.

Greetings!

Daniel Díaz
daniel.d...@linaro.org


[PATCH 2/2] selftests/gpio: Fix OUTPUT directory in Makefile

2018-02-21 Thread Daniel Díaz
When simply running `make' from the selftests top dir, this
error shows up:

  cc -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/uuidgpio-mockup-chardev.c 
../../../gpio/gpio-utils.o  -lmount -o gpio-mockup-chardev
  cc: error: ../../../gpio/gpio-utils.o: No such file or directory
  : recipe for target 'gpio-mockup-chardev' failed
  make[1]: *** [gpio-mockup-chardev] Error 1

because the output directory is set to "selftests/gpio" and
all binaries built from ../../../gpio/ end up there. In fact,
they appear as, exempli gratia:
* gpiogpio-event-mon
* gpiogpio-hammer
* gpioinclude/
* gpiolsgpio
which is wrong, as it's missing directory separator somewhere.

This patch sets straight the output directory when building
../../../gpio/ so that binaries don't cross paths.

Signed-off-by: Daniel Díaz <daniel.d...@linaro.org>
---
 tools/testing/selftests/gpio/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index 6890f61..46a131a 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -7,7 +7,7 @@ TEST_PROGS := gpio-mockup.sh
 TEST_FILES := gpio-mockup-sysfs.sh
 TEST_PROGS_EXTENDED := gpio-mockup-chardev
 
-GPIODIR := ../../../gpio
+GPIODIR := $(realpath ../../../gpio)
 GPIOOBJ := gpio-utils.o
 GPIOINC := gpio.h
 
@@ -15,7 +15,7 @@ all: $(GPIOINC) $(TEST_PROGS_EXTENDED)
 
 override define CLEAN
$(RM) $(TEST_PROGS_EXTENDED)
-   $(MAKE) -C $(GPIODIR) clean
+   $(MAKE) -C $(GPIODIR) OUTPUT=$(GPIODIR)/ clean
 endef
 
 include ../lib.mk
@@ -23,7 +23,7 @@ include ../lib.mk
 $(TEST_PROGS_EXTENDED): $(GPIODIR)/$(GPIOOBJ)
 
 $(GPIODIR)/$(GPIOOBJ):
-   $(MAKE) -C $(GPIODIR)
+   $(MAKE) OUTPUT=$(GPIODIR)/ -C $(GPIODIR)
 
 $(GPIOINC):
$(MAKE) -C ../../../.. headers_install
-- 
2.7.4



[PATCH 2/2] selftests/gpio: Fix OUTPUT directory in Makefile

2018-02-21 Thread Daniel Díaz
When simply running `make' from the selftests top dir, this
error shows up:

  cc -O2 -g -std=gnu99 -Wall -I../../../../usr/include/ -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/uuidgpio-mockup-chardev.c 
../../../gpio/gpio-utils.o  -lmount -o gpio-mockup-chardev
  cc: error: ../../../gpio/gpio-utils.o: No such file or directory
  : recipe for target 'gpio-mockup-chardev' failed
  make[1]: *** [gpio-mockup-chardev] Error 1

because the output directory is set to "selftests/gpio" and
all binaries built from ../../../gpio/ end up there. In fact,
they appear as, exempli gratia:
* gpiogpio-event-mon
* gpiogpio-hammer
* gpioinclude/
* gpiolsgpio
which is wrong, as it's missing directory separator somewhere.

This patch sets straight the output directory when building
../../../gpio/ so that binaries don't cross paths.

Signed-off-by: Daniel Díaz 
---
 tools/testing/selftests/gpio/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index 6890f61..46a131a 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -7,7 +7,7 @@ TEST_PROGS := gpio-mockup.sh
 TEST_FILES := gpio-mockup-sysfs.sh
 TEST_PROGS_EXTENDED := gpio-mockup-chardev
 
-GPIODIR := ../../../gpio
+GPIODIR := $(realpath ../../../gpio)
 GPIOOBJ := gpio-utils.o
 GPIOINC := gpio.h
 
@@ -15,7 +15,7 @@ all: $(GPIOINC) $(TEST_PROGS_EXTENDED)
 
 override define CLEAN
$(RM) $(TEST_PROGS_EXTENDED)
-   $(MAKE) -C $(GPIODIR) clean
+   $(MAKE) -C $(GPIODIR) OUTPUT=$(GPIODIR)/ clean
 endef
 
 include ../lib.mk
@@ -23,7 +23,7 @@ include ../lib.mk
 $(TEST_PROGS_EXTENDED): $(GPIODIR)/$(GPIOOBJ)
 
 $(GPIODIR)/$(GPIOOBJ):
-   $(MAKE) -C $(GPIODIR)
+   $(MAKE) OUTPUT=$(GPIODIR)/ -C $(GPIODIR)
 
 $(GPIOINC):
$(MAKE) -C ../../../.. headers_install
-- 
2.7.4



[PATCH 1/2] selftests: gpio: restructure Makefile

2018-02-21 Thread Daniel Díaz
From: Fathi Boudra 

Signed-off-by: Fathi Boudra 
---
 tools/testing/selftests/gpio/Makefile | 36 +--
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index 1bbb475..6890f61 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -1,31 +1,29 @@
 # SPDX-License-Identifier: GPL-2.0
 
+CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
+LDLIBS += -lmount -I/usr/include/libmount
+
 TEST_PROGS := gpio-mockup.sh
-TEST_FILES := gpio-mockup-sysfs.sh $(BINARIES)
-BINARIES := gpio-mockup-chardev
-EXTRA_PROGS := ../gpiogpio-event-mon ../gpiogpio-hammer ../gpiolsgpio
-EXTRA_DIRS := ../gpioinclude/
-EXTRA_OBJS := ../gpiogpio-event-mon-in.o ../gpiogpio-event-mon.o
-EXTRA_OBJS += ../gpiogpio-hammer-in.o ../gpiogpio-utils.o ../gpiolsgpio-in.o
-EXTRA_OBJS += ../gpiolsgpio.o
+TEST_FILES := gpio-mockup-sysfs.sh
+TEST_PROGS_EXTENDED := gpio-mockup-chardev
 
-include ../lib.mk
+GPIODIR := ../../../gpio
+GPIOOBJ := gpio-utils.o
+GPIOINC := gpio.h
 
-all: $(BINARIES)
+all: $(GPIOINC) $(TEST_PROGS_EXTENDED)
 
 override define CLEAN
-   $(RM) $(BINARIES) $(EXTRA_PROGS) $(EXTRA_OBJS)
-   $(RM) -r $(EXTRA_DIRS)
+   $(RM) $(TEST_PROGS_EXTENDED)
+   $(MAKE) -C $(GPIODIR) clean
 endef
 
-CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
-LDLIBS += -lmount -I/usr/include/libmount
-
-$(BINARIES): ../../../gpio/gpio-utils.o ../../../../usr/include/linux/gpio.h
+include ../lib.mk
 
-../../../gpio/gpio-utils.o:
-   make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C ../../../gpio
+$(TEST_PROGS_EXTENDED): $(GPIODIR)/$(GPIOOBJ)
 
-../../../../usr/include/linux/gpio.h:
-   make -C ../../../.. headers_install INSTALL_HDR_PATH=$(shell 
pwd)/../../../../usr/
+$(GPIODIR)/$(GPIOOBJ):
+   $(MAKE) -C $(GPIODIR)
 
+$(GPIOINC):
+   $(MAKE) -C ../../../.. headers_install
-- 
2.7.4



[PATCH 1/2] selftests: gpio: restructure Makefile

2018-02-21 Thread Daniel Díaz
From: Fathi Boudra 

Signed-off-by: Fathi Boudra 
---
 tools/testing/selftests/gpio/Makefile | 36 +--
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/tools/testing/selftests/gpio/Makefile 
b/tools/testing/selftests/gpio/Makefile
index 1bbb475..6890f61 100644
--- a/tools/testing/selftests/gpio/Makefile
+++ b/tools/testing/selftests/gpio/Makefile
@@ -1,31 +1,29 @@
 # SPDX-License-Identifier: GPL-2.0
 
+CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
+LDLIBS += -lmount -I/usr/include/libmount
+
 TEST_PROGS := gpio-mockup.sh
-TEST_FILES := gpio-mockup-sysfs.sh $(BINARIES)
-BINARIES := gpio-mockup-chardev
-EXTRA_PROGS := ../gpiogpio-event-mon ../gpiogpio-hammer ../gpiolsgpio
-EXTRA_DIRS := ../gpioinclude/
-EXTRA_OBJS := ../gpiogpio-event-mon-in.o ../gpiogpio-event-mon.o
-EXTRA_OBJS += ../gpiogpio-hammer-in.o ../gpiogpio-utils.o ../gpiolsgpio-in.o
-EXTRA_OBJS += ../gpiolsgpio.o
+TEST_FILES := gpio-mockup-sysfs.sh
+TEST_PROGS_EXTENDED := gpio-mockup-chardev
 
-include ../lib.mk
+GPIODIR := ../../../gpio
+GPIOOBJ := gpio-utils.o
+GPIOINC := gpio.h
 
-all: $(BINARIES)
+all: $(GPIOINC) $(TEST_PROGS_EXTENDED)
 
 override define CLEAN
-   $(RM) $(BINARIES) $(EXTRA_PROGS) $(EXTRA_OBJS)
-   $(RM) -r $(EXTRA_DIRS)
+   $(RM) $(TEST_PROGS_EXTENDED)
+   $(MAKE) -C $(GPIODIR) clean
 endef
 
-CFLAGS += -O2 -g -std=gnu99 -Wall -I../../../../usr/include/
-LDLIBS += -lmount -I/usr/include/libmount
-
-$(BINARIES): ../../../gpio/gpio-utils.o ../../../../usr/include/linux/gpio.h
+include ../lib.mk
 
-../../../gpio/gpio-utils.o:
-   make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C ../../../gpio
+$(TEST_PROGS_EXTENDED): $(GPIODIR)/$(GPIOOBJ)
 
-../../../../usr/include/linux/gpio.h:
-   make -C ../../../.. headers_install INSTALL_HDR_PATH=$(shell 
pwd)/../../../../usr/
+$(GPIODIR)/$(GPIOOBJ):
+   $(MAKE) -C $(GPIODIR)
 
+$(GPIOINC):
+   $(MAKE) -C ../../../.. headers_install
-- 
2.7.4



Re: [PATCH] tools/gpio/gpio-event-mon: fix warning

2018-02-21 Thread Daniel Díaz Rodríguez
On 21 February 2018 at 15:33, Anders Roxell <anders.rox...@linaro.org> wrote:
> PRIu64 is defined in user space to match libc's uint64_t definition.
> However, gpioevent_data structure in the kernel is defined using the
> kernel's own __u64 type.
>
> gpio-event-mon.c: In function ‘monitor_device’:
> gpio-event-mon.c:102:19: warning: format ‘%lu’ expects argument of type
> ‘long unsigned int’, but argument 3 has type ‘__u64 {aka long long
> unsigned int}’ [-Wformat=]
>fprintf(stdout, "GPIO EVENT %" PRIu64 ": ", event.timestamp);
>^~
>   LD   /tmp/kselftest/gpiogpio-event-mon-in.o
>   LINK /tmp/kselftest/gpiogpio-event-mon
>
> Fix is to replace PRIu64 with llu, which we know is what the kernel uses
> for __u64.
>
> Signed-off-by: Anders Roxell <anders.rox...@linaro.org>

Tested-by: Daniel Díaz <daniel.d...@linaro.org>


> ---
>  tools/gpio/gpio-event-mon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/gpio/gpio-event-mon.c b/tools/gpio/gpio-event-mon.c
> index dac4d4131d9b..c864544efe05 100644
> --- a/tools/gpio/gpio-event-mon.c
> +++ b/tools/gpio/gpio-event-mon.c
> @@ -99,7 +99,7 @@ int monitor_device(const char *device_name,
> ret = -EIO;
> break;
> }
> -   fprintf(stdout, "GPIO EVENT %" PRIu64 ": ", event.timestamp);
> +   fprintf(stdout, "GPIO EVENT %llu: ", event.timestamp);
> switch (event.id) {
> case GPIOEVENT_EVENT_RISING_EDGE:
> fprintf(stdout, "rising edge");
> --
> 2.11.0


Re: [PATCH] tools/gpio/gpio-event-mon: fix warning

2018-02-21 Thread Daniel Díaz Rodríguez
On 21 February 2018 at 15:33, Anders Roxell  wrote:
> PRIu64 is defined in user space to match libc's uint64_t definition.
> However, gpioevent_data structure in the kernel is defined using the
> kernel's own __u64 type.
>
> gpio-event-mon.c: In function ‘monitor_device’:
> gpio-event-mon.c:102:19: warning: format ‘%lu’ expects argument of type
> ‘long unsigned int’, but argument 3 has type ‘__u64 {aka long long
> unsigned int}’ [-Wformat=]
>fprintf(stdout, "GPIO EVENT %" PRIu64 ": ", event.timestamp);
>^~
>   LD   /tmp/kselftest/gpiogpio-event-mon-in.o
>   LINK /tmp/kselftest/gpiogpio-event-mon
>
> Fix is to replace PRIu64 with llu, which we know is what the kernel uses
> for __u64.
>
> Signed-off-by: Anders Roxell 

Tested-by: Daniel Díaz 


> ---
>  tools/gpio/gpio-event-mon.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/gpio/gpio-event-mon.c b/tools/gpio/gpio-event-mon.c
> index dac4d4131d9b..c864544efe05 100644
> --- a/tools/gpio/gpio-event-mon.c
> +++ b/tools/gpio/gpio-event-mon.c
> @@ -99,7 +99,7 @@ int monitor_device(const char *device_name,
> ret = -EIO;
> break;
> }
> -   fprintf(stdout, "GPIO EVENT %" PRIu64 ": ", event.timestamp);
> +   fprintf(stdout, "GPIO EVENT %llu: ", event.timestamp);
> switch (event.id) {
> case GPIOEVENT_EVENT_RISING_EDGE:
> fprintf(stdout, "rising edge");
> --
> 2.11.0


Re: [PATCH] selftests/bpf: tcpbpf_kern: use in6_* macros from glibc

2018-02-21 Thread Daniel Díaz
On 02/21/2018 10:51 AM, Anders Roxell wrote:
> Both glibc and the kernel have in6_* macros definitions. Build fails
> because it picks up wrong in6_* macro from the kernel header and not the
> header from glibc.
> 
> Fixes build error below:
> clang -I. -I./include/uapi -I../../../include/uapi
>  -Wno-compare-distinct-pointer-types \
>  -O2 -target bpf -emit-llvm -c test_tcpbpf_kern.c -o - |  \
> llc -march=bpf -mcpu=generic -filetype=obj
>  -o .../tools/testing/selftests/bpf/test_tcpbpf_kern.o
> In file included from test_tcpbpf_kern.c:12:
> .../netinet/in.h:101:5: error: expected identifier
> IPPROTO_HOPOPTS = 0,   /* IPv6 Hop-by-Hop options.  */
> ^
> .../linux/in6.h:131:26: note: expanded from macro 'IPPROTO_HOPOPTS'
> ^
> In file included from test_tcpbpf_kern.c:12:
> /usr/include/netinet/in.h:103:5: error: expected identifier
> IPPROTO_ROUTING = 43,  /* IPv6 routing header.  */
> ^
> .../linux/in6.h:132:26: note: expanded from macro 'IPPROTO_ROUTING'
> ^
> In file included from test_tcpbpf_kern.c:12:
> .../netinet/in.h:105:5: error: expected identifier
> IPPROTO_FRAGMENT = 44, /* IPv6 fragmentation header.  */
> ^
> 
> Since both glibc and the kernel have in6_* macros definitions, use the
> one from glibc.  Kernel headers will check for previous libc definitions
> by including include/linux/libc-compat.h.
> 
> Reported-by: Daniel Díaz <daniel.d...@linaro.org>
> Signed-off-by: Anders Roxell <anders.rox...@linaro.org>

FWIW, this was
Tested-by: Daniel Díaz <daniel.d...@linaro.org>

> ---
>  tools/testing/selftests/bpf/test_tcpbpf_kern.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/bpf/test_tcpbpf_kern.c 
> b/tools/testing/selftests/bpf/test_tcpbpf_kern.c
> index 57119ad57a3f..3e645ee41ed5 100644
> --- a/tools/testing/selftests/bpf/test_tcpbpf_kern.c
> +++ b/tools/testing/selftests/bpf/test_tcpbpf_kern.c
> @@ -5,7 +5,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 


Re: [PATCH] selftests/bpf: tcpbpf_kern: use in6_* macros from glibc

2018-02-21 Thread Daniel Díaz
On 02/21/2018 10:51 AM, Anders Roxell wrote:
> Both glibc and the kernel have in6_* macros definitions. Build fails
> because it picks up wrong in6_* macro from the kernel header and not the
> header from glibc.
> 
> Fixes build error below:
> clang -I. -I./include/uapi -I../../../include/uapi
>  -Wno-compare-distinct-pointer-types \
>  -O2 -target bpf -emit-llvm -c test_tcpbpf_kern.c -o - |  \
> llc -march=bpf -mcpu=generic -filetype=obj
>  -o .../tools/testing/selftests/bpf/test_tcpbpf_kern.o
> In file included from test_tcpbpf_kern.c:12:
> .../netinet/in.h:101:5: error: expected identifier
> IPPROTO_HOPOPTS = 0,   /* IPv6 Hop-by-Hop options.  */
> ^
> .../linux/in6.h:131:26: note: expanded from macro 'IPPROTO_HOPOPTS'
> ^
> In file included from test_tcpbpf_kern.c:12:
> /usr/include/netinet/in.h:103:5: error: expected identifier
> IPPROTO_ROUTING = 43,  /* IPv6 routing header.  */
> ^
> .../linux/in6.h:132:26: note: expanded from macro 'IPPROTO_ROUTING'
> ^
> In file included from test_tcpbpf_kern.c:12:
> .../netinet/in.h:105:5: error: expected identifier
> IPPROTO_FRAGMENT = 44, /* IPv6 fragmentation header.  */
> ^
> 
> Since both glibc and the kernel have in6_* macros definitions, use the
> one from glibc.  Kernel headers will check for previous libc definitions
> by including include/linux/libc-compat.h.
> 
> Reported-by: Daniel Díaz 
> Signed-off-by: Anders Roxell 

FWIW, this was
Tested-by: Daniel Díaz 

> ---
>  tools/testing/selftests/bpf/test_tcpbpf_kern.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/bpf/test_tcpbpf_kern.c 
> b/tools/testing/selftests/bpf/test_tcpbpf_kern.c
> index 57119ad57a3f..3e645ee41ed5 100644
> --- a/tools/testing/selftests/bpf/test_tcpbpf_kern.c
> +++ b/tools/testing/selftests/bpf/test_tcpbpf_kern.c
> @@ -5,7 +5,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 


Re: [PATCH] selftests/bpf: update gitignore with test_libbpf_open

2018-02-21 Thread Daniel Díaz
On 02/21/2018 03:30 PM, Anders Roxell wrote:
> bpf builds a test program for loading BPF ELF files. Add the executable
> to the .gitignore list.
> 
> Signed-off-by: Anders Roxell <anders.rox...@linaro.org>

Tested-by: Daniel Díaz <daniel.d...@linaro.org>

> ---
>  tools/testing/selftests/bpf/.gitignore | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/testing/selftests/bpf/.gitignore 
> b/tools/testing/selftests/bpf/.gitignore
> index cc15af2e54fe..9cf83f895d98 100644
> --- a/tools/testing/selftests/bpf/.gitignore
> +++ b/tools/testing/selftests/bpf/.gitignore
> @@ -11,3 +11,4 @@ test_progs
>  test_tcpbpf_user
>  test_verifier_log
>  feature
> +test_libbpf_open


Re: [PATCH] selftests/bpf: update gitignore with test_libbpf_open

2018-02-21 Thread Daniel Díaz
On 02/21/2018 03:30 PM, Anders Roxell wrote:
> bpf builds a test program for loading BPF ELF files. Add the executable
> to the .gitignore list.
> 
> Signed-off-by: Anders Roxell 

Tested-by: Daniel Díaz 

> ---
>  tools/testing/selftests/bpf/.gitignore | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/testing/selftests/bpf/.gitignore 
> b/tools/testing/selftests/bpf/.gitignore
> index cc15af2e54fe..9cf83f895d98 100644
> --- a/tools/testing/selftests/bpf/.gitignore
> +++ b/tools/testing/selftests/bpf/.gitignore
> @@ -11,3 +11,4 @@ test_progs
>  test_tcpbpf_user
>  test_verifier_log
>  feature
> +test_libbpf_open


[PATCH] selftests/intel_pstate: Fix build rule for x86

2018-02-21 Thread Daniel Díaz
Ensure that ARCH is defined and that this only builds for
x86 architectures.

It is possible to build from the root of the Linux tree, which
will define ARCH, or to run make from the selftests/ directory
itself, which has no provision for defining ARCH, so this
change is to use the current definition (if any), or to check
uname -m if undefined.

Signed-off-by: Daniel Díaz <daniel.d...@linaro.org>
---
 tools/testing/selftests/intel_pstate/Makefile | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/intel_pstate/Makefile 
b/tools/testing/selftests/intel_pstate/Makefile
index 5a3f7d37..7340fd6 100644
--- a/tools/testing/selftests/intel_pstate/Makefile
+++ b/tools/testing/selftests/intel_pstate/Makefile
@@ -2,7 +2,10 @@
 CFLAGS := $(CFLAGS) -Wall -D_GNU_SOURCE
 LDLIBS := $(LDLIBS) -lm
 
-ifeq (,$(filter $(ARCH),x86))
+uname_M := $(shell uname -m 2>/dev/null || echo not)
+ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/)
+
+ifeq (x86,$(ARCH))
 TEST_GEN_FILES := msr aperf
 endif
 
-- 
2.7.4



  1   2   >