[PATCH] mm: migrate: initialize err in do_migrate_pages

TP migrate_pages01, which calls migrate_pages() with same set for both old/new_nodes. Add 'err' initialization back. Fixes: 236c32eb1096 ("mm: migrate: clean up migrate_prep{_local}") Cc: Zi Yan Cc: Yang Shi Cc: Jan Kara Cc: Matthew Wilcox Cc: Mel Gorman Cc: Michal H

Re: [LTP] [PATCH] selftests: vdso: hash entry size on alpha, s390x is 8 bytes

- Original Message - > > - Original Message - > > Hi! > > As much as it's worth the changes looks good to me. > > > > @Jan: I guess that we can as well fix this in LTP first then we can try > > to get the kernel version fixed... > > Fine by me, I'll give it couple more da

Re: [LTP] [PATCH] selftests: vdso: hash entry size on alpha, s390x is 8 bytes

- Original Message - > Hi! > As much as it's worth the changes looks good to me. > > @Jan: I guess that we can as well fix this in LTP first then we can try > to get the kernel version fixed... Fine by me, I'll give it couple more days then push it. I did repost it with original

[PATCH RESEND] selftests: vdso: hash entry size on alpha,s390x is 8 bytes

in parse_vdso.c and treat hash entries as double word. Signed-off-by: Jan Stancek --- tools/testing/selftests/vDSO/parse_vdso.c | 48 +++ 1 file changed, 40 insertions(+), 8 deletions(-) Resend with original author CC-ed. diff --git a/tools/testing/selftests/vDSO/parse_vdso.c

Re: [PATCH] selftests: vdso: hash entry size on alpha,s390x is 8 bytes

- Original Message - > parse_vdso.c is crashing on 5.8-rc5 s390x, because it wrongly reads > nbucket as 0: > Program received signal SIGFPE, Arithmetic exception. > 0x01000f3e in vdso_sym (version=0x1001280 "LINUX_2.6", > name=0x100128a "__vdso_getcpu") at parse_vdso.c:207 >

[PATCH] selftests: vdso: hash entry size on alpha,s390x is 8 bytes

in parse_vdso.c and treat hash entries as double word. Signed-off-by: Jan Stancek --- tools/testing/selftests/vDSO/parse_vdso.c | 48 +++ 1 file changed, 40 insertions(+), 8 deletions(-) diff --git a/tools/testing/selftests/vDSO/parse_vdso.c b/tools/testing/selftests/vDSO/parse

Re: [LTP] 303cc571d1: ltp.setns01.fail

- Original Message - > I'll send a pr for this to Linus this week (or next since I'm on > vacation this week) and get this fixed. Thanks for spotting this. What's > the Reported-by: line format that LTP uses? I'm not sure we ever used one, it's usually various CI systems that reference

Re: [LTP] 303cc571d1: ltp.setns01.fail

- Original Message - > Hi! > > setns01 6 TFAIL : setns01.c:176: regular file fd exp_errno=22: > > errno=EBADF(9): Bad file descriptor > > setns01 0 TINFO : setns(12, 0x2) > > setns01 7 TFAIL : setns01.c:176: regular file fd exp_errno=22: > > errno=EBADF(9): Bad f

Re: LTP: syscalls: regression on mainline - ioctl_loop01 mknod07 setns01

- Original Message - > Following three test cases reported as regression on Linux mainline kernel > on x86_64, arm64, arm and i386 > > ltp-syscalls-tests: > * ioctl_loop01 > * mknod07 Test updated: https://github.com/linux-test-project/ltp/commit/13fcfa2d6bdd1fb71c4528b471

[bug?] LTP pt_test failing after 38bb8d77d0b9 "perf/x86/intel/pt: Split ToPA metadata and page layout"

Hi, All variants of pt_test: https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/tracing/pt_test/pt_test.c started failing after: 38bb8d77d0b9 ("perf/x86/intel/pt: Split ToPA metadata and page layout") with following error on console/dmesg: pt: ToPA ERROR encountered, tr

Re: [PATCH] fat: fix corruption in fat_alloc_new_dir()

- Original Message - > Jan Stancek writes: > > > sb_getblk does not guarantee that buffer_head is uptodate. If there is > > async read running in parallel for same buffer_head, it can overwrite > > just initialized msdos_dir_entry, leading to corruption: >

[tip: x86/urgent] x86/timer: Force PIT initialization when !X86_FEATURE_ARAT

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: afa8b475c1aec185a8e106c48b3832e0b88bc2de Gitweb: https://git.kernel.org/tip/afa8b475c1aec185a8e106c48b3832e0b88bc2de Author:Jan Stancek AuthorDate:Sun, 08 Sep 2019 00:50:40 +02:00 Committer

[tip: x86/urgent] x86/timer: Force PIT initialization when !X86_FEATURE_ARAT

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: afa8b475c1aec185a8e106c48b3832e0b88bc2de Gitweb: https://git.kernel.org/tip/afa8b475c1aec185a8e106c48b3832e0b88bc2de Author:Jan Stancek AuthorDate:Sun, 08 Sep 2019 00:50:40 +02:00 Committer

[PATCH] fat: fix corruption in fat_alloc_new_dir()

loop_fd = open(loopdev, O_RDWR); ioctl(loop_fd, LOOP_CLR_FD, fd); close(loop_fd); unlink(testfile); if (ret) break; } return 0; } - 8< -------------

Re: [PATCH v5.2 1/2] locking/rwsem: Add missing ACQUIRE to read_slowpath exit when queue is empty

- Original Message - > From: Jan Stancek > > [ Upstream commit e1b98fa316648420d0434d9ff5b92ad6609ba6c3 ] > > LTP mtest06 has been observed to occasionally hit "still mapped when > deleted" and following BUG_ON on arm64. > > The extra mapcount origin

Re: Linux-next-20190823: x86_64/i386: prot_hsymlinks.c:325: Failed to run cmd: useradd hsym

- Original Message - > On Tue, 2019-08-27 at 06:25 -0400, Jan Stancek wrote: > > That theory is probably not correct for this case, since EIO I see > > appears > > to originate from write and nfs_writeback_result(). This function > > also > > produces m

Re: Linux-next-20190823: x86_64/i386: prot_hsymlinks.c:325: Failed to run cmd: useradd hsym

- Original Message - > On Mon, 2019-08-26 at 19:12 -0400, Jan Stancek wrote: > > - Original Message - > > > On Mon, 2019-08-26 at 10:38 -0400, Jan Stancek wrote: > > > > - Original Message - > > > > > Hi Jan and Cyril, >

Re: Linux-next-20190823: x86_64/i386: prot_hsymlinks.c:325: Failed to run cmd: useradd hsym

- Original Message - > On Mon, 2019-08-26 at 10:38 -0400, Jan Stancek wrote: > > - Original Message - > > > Hi Jan and Cyril, > > > > > > On Mon, 26 Aug 2019 at 16:35, Jan Stancek > > > wrote: > > > > > > > &g

Re: Linux-next-20190823: x86_64/i386: prot_hsymlinks.c:325: Failed to run cmd: useradd hsym

- Original Message - > Hi Jan and Cyril, > > On Mon, 26 Aug 2019 at 16:35, Jan Stancek wrote: > > > > > > > > - Original Message - > > > Hi! > > > > Do you see this LTP prot_hsymlinks failure on linux next 20190823 on > &

Re: Linux-next-20190823: x86_64/i386: prot_hsymlinks.c:325: Failed to run cmd: useradd hsym

- Original Message - > Hi! > > Do you see this LTP prot_hsymlinks failure on linux next 20190823 on > > x86_64 and i386 devices? > > > > test output log, > > useradd: failure while writing changes to /etc/passwd > > useradd: /home/hsym was created, but could not be removed > > This loo

[tip:locking/core] locking/rwsem: Add missing ACQUIRE to read_slowpath exit when queue is empty

Commit-ID: e1b98fa316648420d0434d9ff5b92ad6609ba6c3 Gitweb: https://git.kernel.org/tip/e1b98fa316648420d0434d9ff5b92ad6609ba6c3 Author: Jan Stancek AuthorDate: Thu, 18 Jul 2019 10:51:25 +0200 Committer: Ingo Molnar CommitDate: Thu, 25 Jul 2019 15:39:23 +0200 locking/rwsem: Add missing

Re: [PATCH v2] locking/rwsem: add acquire barrier to read_slowpath exit when queue is empty

- Original Message - > > It's simpler like so: > > On Thu, Jul 18, 2019 at 01:04:46PM +0200, Peter Zijlstra wrote: > > X = 0; > > > > rwsem_down_read() > > for (;;) { > > set_current_state(TASK_UNINTERRUPTIBLE); > > > >

Re: [PATCH v2] locking/rwsem: add acquire barrier to read_slowpath exit when queue is empty

- Original Message - > Hi Jan, Waiman, [+Jade and Paul for the litmus test at the end] > > On Wed, Jul 17, 2019 at 09:22:00PM +0200, Jan Stancek wrote: > > On Wed, Jul 17, 2019 at 10:19:04AM -0400, Waiman Long wrote: > > > > If you add a comment to t

[PATCH v3] locking/rwsem: add acquire barrier to read_slowpath exit when queue is empty

p") Fixes: 4b486b535c33 ("locking/rwsem: Exit read lock slowpath if queue empty & no writer") Signed-off-by: Jan Stancek Reviewed-by: Will Deacon Acked-by: Waiman Long Cc: sta...@vger.kernel.org # v4.20+ Cc: Waiman Long Cc: Davidlohr Bueso Cc: Will Deacon Cc: Peter Zijlstra

Re: [PATCH v2] locking/rwsem: add acquire barrier to read_slowpath exit when queue is empty

On Wed, Jul 17, 2019 at 10:19:04AM -0400, Waiman Long wrote: If you add a comment to the code outlining the issue (preferably as a litmus test involving sem->count and some shared data which happens to be vmacache_seqnum in your test)), then: Reviewed-by: Will Deacon Thanks, Will Agreed. A

[PATCH v2] locking/rwsem: add acquire barrier to read_slowpath exit when queue is empty

ub.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/mtest06/mmap1.c Related: commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") Fixes: 4b486b535c33 ("locking/rwsem: Exit read lock slowpath if queue empty & no writer") Signed-off-by: Jan Stan

Re: [PATCH] locking/rwsem: use read_acquire in read_slowpath exit when queue is empty

- Original Message - > On 7/16/19 12:04 PM, Jan Stancek wrote: > > LTP mtest06 has been observed to rarely hit "still mapped when deleted" > > and following BUG_ON on arm64: > > page:7e02fa37e480 refcount:3 mapcount:1 mapping:f

[PATCH] locking/rwsem: use read_acquire in read_slowpath exit when queue is empty

2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") Fixes: 4b486b535c33 ("locking/rwsem: Exit read lock slowpath if queue empty & no writer") Signed-off-by: Jan Stancek Cc: Waiman Long Cc: Davidlohr Bueso Cc: Will Deacon Cc: Peter Zijlstra Cc: Ingo Molnar -

Re: [LTP] [mm] 8c7829b04c: ltp.overcommit_memory01.fail

- Original Message - > FYI, we noticed the following commit (built with gcc-7): > > commit: 8c7829b04c523cdc732cb77f59f03320e09f3386 ("mm: fix false-positive > OVERCOMMIT_GUESS failures") This matches report from Naresh: http://lists.linux.it/pipermail/ltp/2019-May/011962.html > htt

Re: [v2 PATCH] mm: mmu_gather: remove __tlb_reset_range() for force flush

- Original Message - > On Mon, May 13, 2019 at 04:01:09PM -0700, Yang Shi wrote: > > > > > > On 5/13/19 9:38 AM, Will Deacon wrote: > > > On Fri, May 10, 2019 at 07:26:54AM +0800, Yang Shi wrote: > > > > diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c > > > > index 99740e1..469492d 1006

Re: LTP: mm: overcommit_memory01, 03...06 failed

- Original Message - > ltp-mm-tests failed on Linux mainline kernel 5.1.0, > * overcommit_memory01 overcommit_memory > * overcommit_memory03 overcommit_memory -R 30 > * overcommit_memory04 overcommit_memory -R 80 > * overcommit_memory05 overcommit_memory -R 100 > * overcommit_

Re: [v2 PATCH] mm: mmu_gather: remove __tlb_reset_range() for force flush

- Original Message - > > > On May 13, 2019 4:01 PM, Yang Shi wrote: > > > On 5/13/19 9:38 AM, Will Deacon wrote: > > On Fri, May 10, 2019 at 07:26:54AM +0800, Yang Shi wrote: > >> diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c > >> index 99740e1..469492d 100644 > >> --- a/mm/mmu_gath

Re: [PATCH] mm: mmu_gather: remove __tlb_reset_range() for force flush

- Original Message - > > > On 5/9/19 2:06 PM, Jan Stancek wrote: > > - Original Message - > >> > >> On 5/9/19 11:24 AM, Peter Zijlstra wrote: > >>> On Thu, May 09, 2019 at 05:36:29PM +, Nadav Amit wrote: > >>>>

Re: [PATCH] mm: mmu_gather: remove __tlb_reset_range() for force flush

- Original Message - > > > On 5/9/19 11:24 AM, Peter Zijlstra wrote: > > On Thu, May 09, 2019 at 05:36:29PM +, Nadav Amit wrote: > >>> On May 9, 2019, at 3:38 AM, Peter Zijlstra wrote: > >>> diff --git a/mm/mmu_gather.c b/mm/mmu_gather.c > >>> index 99740e1dd273..fe768f8d612e 10064

Re: [PATCH] mm: mmu_gather: remove __tlb_reset_range() for force flush

> > I don't think we can elide the call __tlb_reset_range() entirely, since I > > think we do want to clear the freed_pXX bits to ensure that we walk the > > range with the smallest mapping granule that we have. Otherwise couldn't we > > have a problem if we hit a PMD that had been cleared, but t

[PATCH v3] mm/memory.c: do_fault: avoid usage of stale vm_area_struct

e mm_struct to avoid using potentially stale "vma". [1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/mtest06/mmap1.c Signed-off-by: Jan Stancek Reviewed-by: Andrea Arcangeli --- mm/memory.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff

Re: [PATCH v2] mm/memory.c: do_fault: avoid usage of stale vm_area_struct

- Original Message - > Hello Jan, > > On Sat, Mar 02, 2019 at 07:19:39PM +0100, Jan Stancek wrote: > > + struct mm_struct *vm_mm = READ_ONCE(vma->vm_mm); > > The vma->vm_mm cannot change under gcc there, so no need of > READ_ONCE. The release of mmap_se

[PATCH v2] mm/memory.c: do_fault: avoid usage of stale vm_area_struct

e mm_struct to avoid using potentially stale "vma". [1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/mtest06/mmap1.c Signed-off-by: Jan Stancek --- mm/memory.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mm/memory.c b/mm/memor

Re: [PATCH] mm/memory.c: do_fault: avoid usage of stale vm_area_struct

- Original Message - > On Sat, Mar 02, 2019 at 04:11:26PM +0100, Jan Stancek wrote: > > Problem is that "vmf->vma" used in do_fault() can become stale. > > Because mmap_sem may be released, other threads can come in, > > call munmap() and cause &q

[PATCH] mm/memory.c: do_fault: avoid usage of stale vm_area_struct

patch pins mm_struct and stores its value, to avoid using potentially stale "vma" when calling pte_free(). [1] https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/mem/mtest06/mmap1.c Signed-off-by: Jan Stancek --- mm/memory.c | 10 +- 1 file changed

Re: [PATCH v2] mm: page_mapped: don't assume compound page is huge or THP

- Original Message - > On Fri, Nov 30, 2018 at 1:07 PM Jan Stancek wrote: > > > > LTP proc01 testcase has been observed to rarely trigger crashes > > on arm64: > > page_mapped+0x78/0xb4 > > stable_page_flags+0x27c/0x338 > > kpageflag

[PATCH v2] mm: page_mapped: don't assume compound page is huge or THP

0x30 (_mapcount) [1] https://github.com/jstancek/reproducers/blob/master/kernel/page_mapped_crash/repro.c Fix the loop to iterate for "1 << compound_order" pages. Debugged-by: Laszlo Ersek Suggested-by: "Kirill A. Shutemov" Signed-off-by: Jan Stancek --- mm/util.c | 2 +- 1 f

[PATCH] mm: page_mapped: don't assume compound page is huge or THP

om/jstancek/reproducers/blob/master/kernel/page_mapped_crash/repro.c This patch modifies page_mapped() to check for 'normal' compound pages (COMPOUND_PAGE_DTOR). Debugged-by: Laszlo Ersek Signed-off-by: Jan Stancek --- include/linux/mm.h | 9 + mm/util.c | 2 ++ 2

Re: [LTP] [PATCH 4.17 00/67] 4.17.7-stable review

- Original Message - > On 16 July 2018 at 13:04, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.17.7 release. > > There are 67 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being app

Re: LTP CVE cve-2017-17053 test failed on x86_64 device

- Original Message - > LTP CVE cve-2017-17053 test failed on x86_64 device. > FAIL on linux-next, mainline, and stable-rc-4.17. > PASS on stable-rc 4.16, 4.14, 4.9 and 4.4 kernel. > > Test FAIL case output, > tst_test.c:1015: INFO: Timeout per run is 0h 15m 00s > tst_taint.c:88: BROK: K

Re: [LTP] [PATCH 4.4 00/24] 4.4.137-stable review

- Original Message - > On Thu, Jun 14, 2018 at 05:49:52AM -0400, Jan Stancek wrote: > > > > - Original Message - > > > On Thu, Jun 14, 2018 at 02:24:25PM +0530, Naresh Kamboju wrote: > > > > On 14 June 2018 at 12:04, Greg Kroah-Hartman >

Re: [LTP] [PATCH 4.4 00/24] 4.4.137-stable review

t; > >> The LTP CVE test is breaking in the first call to mmap(), even before > > >> trying to remap and test the security issue. That start happening in > > >> this round because of those mmap() changes and the offset used in the > > >> LTP test. Linus chang

[PATCH] virtio_balloon: fix increment of vb->num_pfns in fill_balloon()

OM") Cc: Michael S. Tsirkin Cc: Tetsuo Handa Cc: Michal Hocko Cc: Wei Wang Signed-off-by: Jan Stancek --- drivers/virtio/virtio_balloon.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c index 7960746f75

Re: [Patch V3] crypto: x86/sha1 : Fix reads beyond the number of blocks passed

; http://marc.info/?l=linux-crypto-vger&m=149373371023377 > > > > This patch makes sure that there is no overflow for any buffer length. > > > > It passes the tests written by Jan Stancek that revealed this problem: > > https://github.com/jstancek/sha1-avx2-cra

Re: [Patch V2] crypto: x86/sha1 : Fix reads beyond the number of blocks passed

> This patch makes sure that there is no overflow for any buffer length. > > It passes the tests written by Jan Stancek that revealed this problem: > https://github.com/jstancek/sha1-avx2-crash > > Jan, can you verify this fix? Hi, Looks good, my tests (below) PASS-ed. I updat

Re: [PATCH 0/2] key payload access with just rcu_read_lock()

- Original Message - > From: "David Howells" > To: "Jan Stancek" > Cc: dhowe...@redhat.com, linux-kernel@vger.kernel.org, > linux-...@vger.kernel.org, bcodd...@redhat.com, > asav...@redhat.com > Sent: Wednesday, 1 March, 2017 10:40:13 AM > Su

Re: [PATCH 0/2] key payload access with just rcu_read_lock()

- Original Message - > Here's an updated patch with fixed user_key_payload_locked() and user_read(). > That problem didn't show up with my NFS based reproducer. I re-run it again with latest version of your patch, plus also keyutils testsuite. Both completed OK for me, dmesg looks clean.

Re: [PATCH 0/2] key payload access with just rcu_read_lock()

- Original Message - > Jan Stancek wrote: > > > Looks like there are still couple users that need updating, > > I'm hitting following compilation error: > > Aargh - I remembered to grep for rcu_dereference_key() but not > user_key_payload(). > >

Re: [PATCH 0/2] key payload access with just rcu_read_lock()

- Original Message - > From: "David Howells" > To: "Jan Stancek" > Cc: dhowe...@redhat.com, linux-kernel@vger.kernel.org, > linux-...@vger.kernel.org, bcodd...@redhat.com, > asav...@redhat.com > Sent: Monday, 27 February, 2017 11:04:21 PM > Su

[PATCH 1/2] KEYS: add user_key_payload_rcu()

user_key_payload() is wrapper for rcu_dereference_protected(), and can't be used with just rcu_read_lock() held. This patch adds user_key_payload_rcu() for accessing key payload in RCU read-side section, without the need to hold key semaphore. Signed-off-by: Jan Stancek --- Document

[PATCH 2/2] NFS: use user_key_payload_rcu() in RCU read-side section

SyS_mount+0x94/0x100 system_call+0x38/0xe0 Signed-off-by: Jan Stancek --- fs/nfs/nfs4idmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/nfs/nfs4idmap.c b/fs/nfs/nfs4idmap.c index c444285bb1b1..835c163f61af 100644 --- a/fs/nfs/nfs4idmap.c +++ b/fs/nfs

[PATCH 0/2] key payload access with just rcu_read_lock()

Hi David, this is a follow-up for "suspicious RCU usage" warning described in these 2 linux-nfs threads: http://marc.info/?t=14755883033&r=1&w=2 http://marc.info/?t=14877677051&r=1&w=2 Did you have something like in mind? Thanks, Jan Ja

[tip:perf/urgent] perf header: Make build_cpu_topology skip offline/absent CPUs

Commit-ID: 43db2843a4a41cc8cdb6ab696639aeee1f4d5062 Gitweb: http://git.kernel.org/tip/43db2843a4a41cc8cdb6ab696639aeee1f4d5062 Author: Jan Stancek AuthorDate: Fri, 17 Feb 2017 12:10:25 +0100 Committer: Arnaldo Carvalho de Melo CommitDate: Fri, 17 Feb 2017 12:37:04 -0300 perf header

[tip:perf/urgent] perf cpumap: Add cpu__max_present_cpu()

Commit-ID: 92a7e1278005b6bb3459affc50b2b6e2464e7e7c Gitweb: http://git.kernel.org/tip/92a7e1278005b6bb3459affc50b2b6e2464e7e7c Author: Jan Stancek AuthorDate: Fri, 17 Feb 2017 12:10:24 +0100 Committer: Arnaldo Carvalho de Melo CommitDate: Fri, 17 Feb 2017 12:33:05 -0300 perf cpumap

[tip:perf/urgent] perf tools: Replace _SC_NPROCESSORS_CONF with max_present_cpu in cpu_topology_map

Commit-ID: da8a58b56c661681f9b2fd2fa59c6da3a5bac8d1 Gitweb: http://git.kernel.org/tip/da8a58b56c661681f9b2fd2fa59c6da3a5bac8d1 Author: Jan Stancek AuthorDate: Fri, 17 Feb 2017 12:10:26 +0100 Committer: Arnaldo Carvalho de Melo CommitDate: Fri, 17 Feb 2017 12:56:35 -0300 perf tools

[PATCH v4 3/3] perf: Replace _SC_NPROCESSORS_CONF with max_present_cpu in cpu_topology_map

1 CPU 26, core 9, socket 0 CPU 27, core 9, socket 1 test child finished with 0 end Session topology: Ok Signed-off-by: Jan Stancek --- tools/perf/builtin-stat.c | 2 +- tools/perf/tests/topology.c | 4 +++- tools/perf/util/env.c | 2 +- tools/perf/util/header

[PATCH v4 2/3] perf header: Make build_cpu_topology skip offline/absent CPUs

online CPUs. Signed-off-by: Jan Stancek --- tools/perf/util/header.c | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c index d89c9c7ef4e5..ca0f12fb5fd3 100644 --- a/tools/perf/util/header.c +++ b/tools/perf

[PATCH v4 1/3] perf cpu_map: Add cpu__max_present_cpu()

Similar to cpu__max_cpu() (which returns max possible CPU), returns max present CPU. Signed-off-by: Jan Stancek --- tools/perf/util/cpumap.c | 22 ++ tools/perf/util/cpumap.h | 1 + 2 files changed, 23 insertions(+) diff --git a/tools/perf/util/cpumap.c b/tools/perf/util

[PATCH v4 0/3] perf: topology on systems with offline/absent CPUs

core_id: 1, socket_id: 0 core_id: 1, socket_id: 1 core_id: 9, socket_id: 0 core_id: 9, socket_id: 1 Jan Stancek (3): perf cpu_map: Add cpu__max_present_cpu() perf header: Make build_cpu_topology skip offline/absent CPUs perf: Replace _SC_NPROCESSORS_CONF with max_present_cpu in

[PATCH v3 2/3] perf: make build_cpu_topology skip offline/absent CPUs

(__libc_start_main+0xf5) [0x7f4b7c3b5b35] ./perf() [0x427fb9] test child interrupted end Session topology: FAILED! This patch makes build_cpu_topology() skip offline/absent CPUs, by checking their presence against cpu_map built from online CPUs. Signed-off-by: Jan Stancek --- tools

[PATCH v3 1/3] perf: add cpu__max_present_cpu()

Similar to cpu__max_cpu() (which returns max possible CPU), returns max present CPU. Signed-off-by: Jan Stancek --- tools/perf/util/cpumap.c | 22 ++ tools/perf/util/cpumap.h | 1 + 2 files changed, 23 insertions(+) diff --git a/tools/perf/util/cpumap.c b/tools/perf/util

[PATCH v3 3/3] perf: replace _SC_NPROCESSORS_CONF with max_present_cpu in cpu_topology_map

9, socket 1 test child finished with 0 end Session topology: Ok Signed-off-by: Jan Stancek --- tools/perf/builtin-stat.c | 2 +- tools/perf/tests/topology.c | 4 +++- tools/perf/util/env.c | 2 +- tools/perf/util/header.c| 16 +--- 4 files changed, 10 inserti

Re: [PATCH v2 2/3] perf: make build_cpu_topology skip offline/absent CPUs

- Original Message - > From: "Jiri Olsa" > To: "Jan Stancek" > Cc: linux-kernel@vger.kernel.org, pet...@infradead.org, mi...@redhat.com, > a...@kernel.org, "alexander shishkin" > , jo...@kernel.org, mhira...@kernel.org > Sent: Tues

[PATCH v2 1/3] perf: add cpu__max_present_cpu()

Similar to cpu__max_cpu() (which returns max possible CPU), returns max present CPU. Signed-off-by: Jan Stancek --- tools/perf/util/cpumap.c | 22 ++ tools/perf/util/cpumap.h | 1 + 2 files changed, 23 insertions(+) diff --git a/tools/perf/util/cpumap.c b/tools/perf/util

[PATCH v2 3/3] perf: replace _SC_NPROCESSORS_CONF with max_present_cpu in cpu_topology_map

9, socket 1 test child finished with 0 end Session topology: Ok Signed-off-by: Jan Stancek --- tools/perf/builtin-stat.c | 2 +- tools/perf/tests/topology.c | 4 +++- tools/perf/util/env.c | 2 +- tools/perf/util/header.c| 16 +--- 4 files changed, 10 inserti

[PATCH v2 2/3] perf: make build_cpu_topology skip offline/absent CPUs

(__libc_start_main+0xf5) [0x7f4b7c3b5b35] ./perf() [0x427fb9] test child interrupted end Session topology: FAILED! This patch makes build_cpu_topology() skip offline/absent CPUs, by checking their presence against cpu_map built from online CPUs. Signed-off-by: Jan Stancek --- tools

Re: [PATCH] perf: fix topology test on systems with sparse CPUs

> > > When build_cpu_topo() encounters offline/absent CPUs, > > it fails to find any sysfs entries and returns failure. > > This leads to build_cpu_topology() and write_cpu_topology() > > failing as well. > > > > Because HEADER_CPU_TOPOLOGY has not been written, read leaves > > cpu_topology_map N

Re: [PATCH] perf: fix topology test on systems with sparse CPUs

00:00:00 2001 Message-Id: <9bf8ece1e397b851beedaeceeb0cd07421ff6f43.1485877985.git.jstan...@redhat.com> From: Jan Stancek Date: Tue, 31 Jan 2017 14:41:46 +0100 Subject: [PATCH 1/3 v2] perf: add cpu__max_present_cpu() Similar to cpu__max_cpu() (which returns max possible CPU), returns max present C

Re: [PATCH] perf: fix topology test on systems with sparse CPUs

- Original Message - > From: "Jiri Olsa" > To: "Jan Stancek" > Cc: linux-kernel@vger.kernel.org, pet...@infradead.org, mi...@redhat.com, > a...@kernel.org, "alexander shishkin" > , jo...@kernel.org, mhira...@kernel.org, > "rui te

[PATCH] perf: fix topology test on systems with sparse CPUs

ld contain some dummy values in topology data. Example: coreid socketid for CPU0 coreid socketid for CPU1 -1 -1 -1 -1 -1 -1 -1 -1 coreid socketid for CPU6 coreid socketid for CPU7 ... Signed-off-by: Jan Stancek --- tools/perf/tests/topology.c | 7 --- tools/perf/util/e

unable to load modules with CONFIG_MODVERSIONS=y after commit 8ab2ae655b

Hi, Starting with 4.9-rc8 / commit 8ab2ae655b ("default exported asm symbols to zero") I'm running into issue with kernel built with CONFIG_MODVERSIONS=y and (older) binutils (binutils-2.25.1-20.base.el7.ppc64le). Modules fail to load, for example: [3.163646] Found checksum 0 vs module 482

Re: [PATCH 0/1] mm/hugetlb: fix huge page reservation leak in private mapping error paths

- Original Message - > From: "Mike Kravetz" > To: linux...@kvack.org, linux-kernel@vger.kernel.org > Cc: "Aneesh Kumar K . V" , "Naoya Horiguchi" > , "Michal > Hocko" , "Kirill A . Shutemov" > , "Hillf Danton&q

Re: [bug/regression] libhugetlbfs testsuite failures and OOMs eventually kill my system

- Original Message - > Jan Stancek writes: > > Hi Mike, > > > > Revert of 67961f9db8c4 helps, I let whole suite run for 100 iterations, > > there were no issues. > > > > I cut down reproducer and removed last mmap/write/munmap as that is enou

Re: [bug/regression] libhugetlbfs testsuite failures and OOMs eventually kill my system

- Original Message - > From: "Mike Kravetz" > To: "Jan Stancek" , linux...@kvack.org, > linux-kernel@vger.kernel.org > Cc: "hillf zj" , "dave hansen" > , "kirill shutemov" > , mho...@suse.cz, n-horigu...@ah.jp.n

Re: [bug/regression] libhugetlbfs testsuite failures and OOMs eventually kill my system

On 10/14/2016 01:26 AM, Mike Kravetz wrote: > > Hi Jan, > > Any chance you can get the contents of /sys/kernel/mm/hugepages > before and after the first run of libhugetlbfs testsuite on Power? > Perhaps a script like: > > cd /sys/kernel/mm/hugepages > for f in hugepages-*/*; do > n=`cat $f

[bug/regression] libhugetlbfs testsuite failures and OOMs eventually kill my system

Hi, I'm running into ENOMEM failures with libhugetlbfs testsuite [1] on a power8 lpar system running 4.8 or latest git [2]. Repeated runs of this suite trigger multiple OOMs, that eventually kill entire system, it usually takes 3-5 runs: * Total System Memory..: 18024 MB * Shared Mem Max M

Re: [PATCH] perf powerpc: Don't call perf_event_disable from atomic context

- Original Message - > From: "Michael Ellerman" > To: "Jiri Olsa" , "Peter Zijlstra" > Cc: "lkml" , "Ingo Molnar" , > "Michael Neuling" , > "Paul Mackerras" , "Alexander Shishkin" >

[PATCH] crypto: testmgr - add guard to dst buffer for ahash_export

516085 Signed-off-by: Jan Stancek Cc: Herbert Xu Cc: Marcelo Cerri --- crypto/testmgr.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index 5c9d5a5e7b65..96343bcae01e 100644 --- a/crypto/testmgr.c +++ b/crypto/testmgr.c @@ -209,16 +20

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

> Jan, > > Can you check if the problem occurs with this patch? No issues in over-night test with this patch. > --- a/drivers/crypto/vmx/vmx.c > +++ b/drivers/crypto/vmx/vmx.c > @@ -28,6 +28,8 @@ > #include > #include > > +int p8_ghash_fallback_descsize(void); > + > extern struct shash_al

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

- Original Message - > From: "Herbert Xu" > To: "Marcelo Cerri" > Cc: "Jan Stancek" , "rui y wang" , > mhce...@linux.vnet.ibm.com, > leosi...@linux.vnet.ibm.com, pfsmor...@linux.vnet.ibm.com, > linux-cry...@vger

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

- Original Message - > From: "Herbert Xu" > To: "Marcelo Cerri" > Cc: "Jan Stancek" , "rui y wang" , > mhce...@linux.vnet.ibm.com, > leosi...@linux.vnet.ibm.com, pfsmor...@linux.vnet.ibm.com, > linux-cry...@vger

Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

- Original Message - > From: "Marcelo Cerri" > To: "Jan Stancek" > Cc: "rui y wang" , herb...@gondor.apana.org.au, > mhce...@linux.vnet.ibm.com, > leosi...@linux.vnet.ibm.com, pfsmor...@linux.vnet.ibm.com, > linux-cry...@vger.kernel.or

[bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

Hi, I'm chasing a memory corruption with 4.8-rc7 as I'm observing random Oopses on ppc BE/LE systems (lpars, KVM guests). About 30% of issues is that module list gets corrupted, and "cat /proc/modules" or "lsmod" triggers an Oops, for example: [ 88.486041] Unable to handle kernel paging request

Re: [bug] pwritev02 hang on s390x with 4.8.0-rc7

- Original Message - > From: "Al Viro" > To: "Jan Stancek" > Cc: linux-kernel@vger.kernel.org > Sent: Tuesday, 20 September, 2016 5:06:57 PM > Subject: Re: [bug] pwritev02 hang on s390x with 4.8.0-rc7 > > On Tue, Sep 20, 2016 at 02

[bug] pwritev02 hang on s390x with 4.8.0-rc7

Hi, I'm hitting a regression with LTP's pwritev02 [1] on s390x with 4.8.0-rc7. Specifically the EFAULT case, which is passing an iovec with invalid base address: #define CHUNK 64 static struct iovec wr_iovec3[] = { {(char *)-1, CHUNK}, }; hangs with 100% cpu usage and not very helpf

[tip:perf/urgent] perf tests: objdump output can contain multi byte chunks

Commit-ID: b2d0dbf09772d091368261ce95db3afce45d994d Gitweb: http://git.kernel.org/tip/b2d0dbf09772d091368261ce95db3afce45d994d Author: Jan Stancek AuthorDate: Tue, 12 Jan 2016 11:07:44 +0100 Committer: Arnaldo Carvalho de Melo CommitDate: Tue, 2 Aug 2016 16:42:51 -0300 perf tests

[PATCH] crypto: qat - make qat_asym_algs.o depend on asn1 headers

Parallel build can sporadically fail because asn1 headers may not be built yet by the time qat_asym_algs.o is compiled: drivers/crypto/qat/qat_common/qat_asym_algs.c:55:32: fatal error: qat_rsapubkey-asn1.h: No such file or directory #include "qat_rsapubkey-asn1.h" Signed-o

Re: [PATCH] mm/hugetlb: use EOPNOTSUPP in hugetlb sysctl handlers

- Original Message - > From: "Andrew Morton" > To: "Jan Stancek" > Cc: linux...@kvack.org, linux-kernel@vger.kernel.org, > n-horigu...@ah.jp.nec.com, "mike kravetz" > , "hillf zj" , "kirill > shutemov" > , &qu

[PATCH] mm/hugetlb: use EOPNOTSUPP in hugetlb sysctl handlers

Hansen Cc: Paul Gortmaker Signed-off-by: Jan Stancek --- mm/hugetlb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 01f2b48c8618..851a29928a99 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -2751,7 +2751,7 @@

Re: [BUG] scheduler doesn't balance thread to idle cpu for 3 seconds

On 01/29/2016 11:33 AM, Jan Stancek wrote: >> >> Also note that I don't think failing this test is a bug per se. >> Undesirable maybe, but within spec, since SIGALRM is process wide, so it >> being delivered to the SCHED_OTHER task is accepted, and SCHED_OTHER ha

Re: [BUG] scheduler doesn't balance thread to idle cpu for 3 seconds

- Original Message - > From: "Peter Zijlstra" > To: "Jan Stancek" > Cc: "alex shi" , "guz fnst" , > mi...@redhat.com, jo...@redhat.com, > r...@redhat.com, linux-kernel@vger.kernel.org > Sent: Friday, 29 January, 2016 11:15:2

Re: [BUG] scheduler doesn't balance thread to idle cpu for 3 seconds

- Original Message - > From: "Peter Zijlstra" > To: "Jan Stancek" > Cc: "alex shi" , "guz fnst" , > mi...@redhat.com, jo...@redhat.com, > r...@redhat.com, linux-kernel@vger.kernel.org > Sent: Thursday, 28 January, 2016 6:49:0

Re: [BUG] scheduler doesn't balance thread to idle cpu for 3 seconds

On 01/27/2016 03:52 PM, Jan Stancek wrote: > Hello, > > pthread_cond_wait_1/2 [1] is rarely failing for me on 4.5.0-rc1, > on x86_64 KVM guest with 2 CPUs. > > This test [1]: > - spawns 2 SCHED_RR threads > - first thread with higher priority sets alarm for 2 seconds an

[BUG] scheduler doesn't balance thread to idle cpu for 3 seconds

Hello, pthread_cond_wait_1/2 [1] is rarely failing for me on 4.5.0-rc1, on x86_64 KVM guest with 2 CPUs. This test [1]: - spawns 2 SCHED_RR threads - first thread with higher priority sets alarm for 2 seconds and blocks on condition - second thread with lower priority is busy looping for 5 secon

Re: [BUG] perf test 21("Test object code reading") failure on ARM64

On Sat, Dec 19, 2015 at 11:04:21AM +0800, xiakaixu wrote: > > >>>... > > > > Hi, > > > > What is your objdump version? > > Hi, > > Sorry for the late reply. > > # objdump --version > GNU objdump (GNU Binutils) 2.25. > > I am sure that the system is Little endian. > > I have attached a

  1   2   >