[PATCH] mm: migrate: initialize err in do_migrate_pages

rate_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 Hocko Cc: Song Liu Cc: Andrew Morton Signed

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

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

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:

[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,

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

[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

em: 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 Cc: Ingo Molnar --- kernel/locking/rwsem.c | 7

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

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 Stancek Cc: sta...@vger.kernel.org # v4.20+ Cc: W

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

ap_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 --- kernel/locking/rwsem.c | 2 +- 1 file

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 >

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

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 > *

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 > >> ---

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

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

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

ct 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 --git a/m

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 mma

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

ct 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/memory.c index

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 cau

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

ns 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, 9 insertions(+),

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

ithub.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 file changed, 1 inserti

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

ithub.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 file changed, 1 inserti

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

cers/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 files changed, 11 insertions(+) d

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

cers/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 files changed, 11 insertions(+) d

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

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

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:

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:

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

- 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

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

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

OM") Cc: Michael S. Tsirkin <m...@redhat.com> Cc: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Cc: Michal Hocko <mho...@suse.com> Cc: Wei Wang <wei.w.w...@intel.com> Signed-off-by: Jan Stancek <jstan...@redhat.com> --- drivers/virtio/virtio_balloon.c | 3 +--

[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=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-crash &

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

; http://marc.info/?l=linux-crypto-vger=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-crash &

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 updated r

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 updated r

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

- Original Message - > From: "David Howells" <dhowe...@redhat.com> > To: "Jan Stancek" <jstan...@redhat.com> > Cc: dhowe...@redhat.com, linux-kernel@vger.kernel.org, > linux-...@vger.kernel.org, bcodd...@redhat.com, > asav...@redhat.c

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

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

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

- Original Message - > Jan Stancek <jstan...@redhat.com> 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 > u

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(). > > How

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

- Original Message - > From: "David Howells" <dhowe...@redhat.com> > To: "Jan Stancek" <jstan...@redhat.com> > Cc: dhowe...@redhat.com, linux-kernel@vger.kernel.org, > linux-...@vger.kernel.org, bcodd...@redhat.com, > asav...@redhat.co

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 <jstan...@redhat.

[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 --- Documentation

[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 <jstan...@redhat.com> --- 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/nfs4i

[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=1=2 http://marc.info/?t=14877677051=1=2 Did you have something like in mind? Thanks, Jan Jan Stancek (2): KEYS: add user_key_p

[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=1=2 http://marc.info/?t=14877677051=1=2 Did you have something like in mind? Thanks, Jan Jan Stancek (2): KEYS: add user_key_p

[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 <jstan...@redhat.com> AuthorDate: Fri, 17 Feb 2017 12:10:25 +0100 Committer: Arnaldo Carvalho de Melo <a...@redhat.com> CommitD

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

Commit-ID: 92a7e1278005b6bb3459affc50b2b6e2464e7e7c Gitweb: http://git.kernel.org/tip/92a7e1278005b6bb3459affc50b2b6e2464e7e7c Author: Jan Stancek <jstan...@redhat.com> AuthorDate: Fri, 17 Feb 2017 12:10:24 +0100 Committer: Arnaldo Carvalho de Melo <a...@redhat.com> CommitD

[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 <jstan...@redhat.com> AuthorDate: Fri, 17 Feb 2017 12:10:26 +0100 Committer: Arnaldo Carvalho de Melo <a...@redhat.com> CommitD

[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 <jstan...@redhat.com> --- tools/perf/builtin-stat.c | 2 +- tools/perf/tests/topology.c | 4 +++- tools/perf/util/env.c | 2 +-

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

online CPUs. Signed-off-by: Jan Stancek <jstan...@redhat.com> --- 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/per

[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 <jstan...@redhat.com> --- tools/perf/util/cpumap.c | 22 ++ tools/perf/util/cpumap.h | 1 + 2 files changed, 23 insertions(+) diff --git a/tools/per

[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

[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

[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 <js

[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 <jstan...@redhat.com> --- tools/perf/util/cpumap.c | 22 ++ tools/perf/util/cpumap.h | 1 + 2 files changed, 23 insertions(+) diff --git a/tools/per

[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 <jstan...@redhat.com> --- tools/perf/builtin-stat.c | 2 +- tools/perf/tests/topology.c | 4 +++- tools/perf/util/env.c | 2 +- tools/perf/util/header.c| 16 +---

[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" <jo...@redhat.com> > To: "Jan Stancek" <jstan...@redhat.com> > Cc: linux-kernel@vger.kernel.org, pet...@infradead.org, mi...@redhat.com, > a...@kernel.org, "alexander shishkin" > <

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 <jstan...@redhat.com> --- tools/perf/util/cpumap.c | 22 ++ tools/perf/util/cpumap.h | 1 + 2 files changed, 23 insertions(+) diff --git a/tools/per

[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 <jstan...@redhat.com> --- tools/perf/builtin-stat.c | 2 +- tools/perf/tests/topology.c | 4 +++- tools/perf/util/env.c | 2 +- tools/perf/util/header.c| 16 +---

[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 <js

[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

  1   2   3   >