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
- 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
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
- 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
- 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
ax)
a: 00 00 add%al,(%rax)
c: 48 89 e5
This patch aborts further reading if address starts going backwards,
assuming we crossed sections.
Signed-off-by: Jan Stancek
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Adrian Hunter
Cc: David Ahe
Greg,
any thoughts about the patch?
Regards,
Jan
- Original Message -
> From: "Dave Young"
> To: "Jan Stancek"
> Cc: gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
> linux...@kvack.org
> Sent: Tuesday, 1 September, 2015 9:15:53 AM
>
Add -z parameter to avoid skipping zero blocks:
816704fe :
816704fe: 7b 34 jnp 81670534
...
81670501 :
81670501: 0f ba e2 03 bt $0x3,%edx
81670505: 73 11 jae 81670518
Signed-off-by: Jan Stancek
Cc
Signed-off-by: Jan Stancek
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Adrian Hunter
Cc: David Ahern
Cc: Corey Ashford
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
---
tools/perf/tests/code-reading.c | 16
1 file
,%rcx,4)
8164efb8 :
8164efb8: 4c 8b 5c 24 30 mov0x30(%rsp),%r11
8164efbd: 4c 8b 54 24 38 mov0x38(%rsp),%r10
Store objdump output to buffer according to offset calculated
from address on each line.
Signed-off-by: Jan Stancek
Cc: Arnaldo Carvalho de
crossed sections.
Signed-off-by: Jan Stancek
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Adrian Hunter
Cc: David Ahern
Cc: Corey Ashford
Cc: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Paul Mackerras
Cc: Peter Zijlstra
---
tools/perf/tests/code-reading.c | 7 ++-
1 file
Add -z parameter to avoid skipping zero blocks:
816704fe :
816704fe: 7b 34 jnp 81670534
...
81670501 :
81670501: 0f ba e2 03 bt $0x3,%edx
81670505: 73 11 jae 81670518
Signed-off-by: Jan Stancek
Cc
,%rcx,4)
8164efb8 :
8164efb8: 4c 8b 5c 24 30 mov0x30(%rsp),%r11
8164efbd: 4c 8b 54 24 38 mov0x38(%rsp),%r10
Store objdump output to buffer according to offset calculated
from address on each line.
Signed-off-by: Jan Stancek
Cc: Arnaldo Carvalho de
On 09/03/2015 05:14 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Sep 03, 2015 at 02:35:55PM +0300, Adrian Hunter escreveu:
>> On 03/09/15 14:23, Jan Stancek wrote:
>>> Add -z parameter to avoid skipping zero blocks:
>>>
>>> 816704fe :
>&
- Original Message -
> From: "Greg KH"
> To: "Jan Stancek"
> Cc: linux-kernel@vger.kernel.org, linux...@kvack.org, "Dave Young"
>
> Sent: Sunday, 4 October, 2015 2:06:39 PM
> Subject: Re: [PATCH 2/2] drivers/base/node.c: skip non-pre
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
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
- 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
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
- 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
>
- 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
: 7cba160ad789 (powernv/cpuidle: Redesign idle states management)
Signed-off-by: Jan Stancek
---
arch/powerpc/include/asm/cputhreads.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/cputhreads.h
b/arch/powerpc/include/asm/cputhreads.h
index 2bf8e93
On Wed, May 27, 2015 at 01:27:13AM -0400, Jarod Wilson wrote:
> On May 26, 2015, at 5:24 PM, Alexey Dobriyan wrote:
> >> Should have tested on more than just x86, it appears. We've started
> >> hammering on this internally across all arches, and its exploded
> >> multiple times on ppc64 now:
> >
- Original Message -
> From: "Alexey Dobriyan"
> To: a...@linux-foundation.org
> Cc: linux-kernel@vger.kernel.org, gorcu...@openvz.org, ja...@redhat.com,
> jstan...@redhat.com
> Sent: Wednesday, 27 May, 2015 11:49:53 PM
> Subject: [PATCH 2/2] proc: fix PAGE_SIZE limit of /proc/$PID/cm
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
- 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
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
- 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
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
- 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
- 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
>
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
- 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
- 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
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
ion.
Signed-off-by: Jan Stancek
---
kernel/futex.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/kernel/futex.c b/kernel/futex.c
index 67dacaf..5163899 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -284,7 +284,10 @@ static inline void hb_waiters_dec(str
- Original Message -
> From: "Linus Torvalds"
> To: "Jan Stancek"
> Cc: "Linux Kernel Mailing List" , "Srikar
> Dronamraju" ,
> "Davidlohr Bueso" , "Ingo Molnar" ,
> "Larry Woodman"
> Sent:
- Original Message -
> From: "Linus Torvalds"
> To: "Peter Zijlstra"
> Cc: "Jan Stancek" , "Linux Kernel Mailing List"
> , "Srikar
> Dronamraju" , "Davidlohr Bueso"
> , "Ingo Molnar" ,
> &qu
- Original Message -
> From: "Linus Torvalds"
> To: "Jan Stancek"
> Cc: "Peter Zijlstra" , "Linux Kernel Mailing List"
> , "Srikar
> Dronamraju" , "Davidlohr Bueso"
> , "Ingo Molnar" ,
> "
ies to access page for first pfn of this mem_blk (8192 == 32 * 256)
and crashes.
Signed-off-by: Jan Stancek
Cc: Greg Kroah-Hartman
---
drivers/base/node.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/base/node.c b/drivers/base/node.c
index 4c7423a4b5f4..e638cfde7486 100644
--- a
Split single loop going over all pfn in mem_blk into 2 loops,
where outer loop goes over all sections and inner loop goes over
pfn from that section.
This is preparatory patch for next patch:
"skip non-present sections in register_mem_sect_under_node"
Signed-off-by: Jan Stancek
Cc:
ss" is calculated
as minimum of "total" and sg limits at start of every iteration.
Fixes: 000851119e80 ("crypto: nx - Fix SHA concurrence issue and sg
limit bounds")
Signed-off-by: Jan Stancek
Cc: Leonidas Da Silva Barbosa
Hi,
"ADSP018" test from LTP[1] is triggering BUG_ON below reliably for me on
4.4.0-rc4.
I'll start a bisect - if someone already sees a suspect/culprit that could
narrow
it down, please let me know.
# ./aiodio_sparse -i 4 -a 8k -w 16384k -s 65536k -n 2
aiodio_sparse0 TINFO : Dirtying fre
On 12/07/2015 12:40 PM, Jan Stancek wrote:
> Hi,
>
> "ADSP018" test from LTP[1] is triggering BUG_ON below reliably for me on
> 4.4.0-rc4.
> I'll start a bisect - if someone already sees a suspect/culprit that could
> narrow
> it down, please let me know.
- Original Message -
> From: "Peter Zijlstra"
> To: "Jan Stancek"
> Cc: linux...@kvack.org, linux-kernel@vger.kernel.org, "Oleg Nesterov"
>
> Sent: Monday, 7 December, 2015 5:07:15 PM
> Subject: Re: kernel BUG at mm/filemap.c:238! (4.
- Original Message -
> From: "Jiri Olsa"
> To: "xiakaixu"
> Cc: "adrian hunter" , "Arnaldo Carvalho de Melo"
> , "Ingo Molnar"
> , "masami hiramatsu pt" ,
> linux-kernel@vger.kernel.org, "Wangnan
&
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
, &event, 0, -1, -1, 0);
}
Signed-off-by: Jan Stancek
---
arch/powerpc/perf/core-book3s.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 7c4f669..b101c0b 100644
--- a/arch/powerpc/perf/core-book
- Original Message -
> From: "Michael Ellerman"
> To: "Jan Stancek" , linuxppc-...@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org, pau...@samba.org, an...@samba.org,
> t...@kernel.org, c...@linux.com, jo...@redhat.com,
> jstan...@redhat.com, j
PU0
lock(ip6_fl_lock);
lock(ip6_fl_lock);
*** DEADLOCK ***
Signed-off-by: Jan Stancek
---
net/ipv6/ip6_flowlabel.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 2f780cb..f45d6db 100
- Original Message -
> From: "Nishanth Aravamudan"
> To: "John Stultz"
> Cc: "Thomas Gleixner" , "lkml"
> , jstan...@redhat.com, "Ingo Molnar"
>
> Sent: Thursday, 19 February, 2015 8:28:40 PM
> Subject: Re: time / gtod seconds value out of sync?
>
> Hi John!
>
> On 19.02.2015 [11:
Hi,
I see this testcase occasionally failing. After reproducing it with
verbose output and checking objdump output I found at least 3 scenarios
where data read from objdump output does not match:
1. same byte is repeated in objdump output
Note that byte at 815cf071 is in output twice
- 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:
>
loop_fd = open(loopdev, O_RDWR);
ioctl(loop_fd, LOOP_CLR_FD, fd);
close(loop_fd);
unlink(testfile);
if (ret)
break;
}
return 0;
}
- 8< -------------
- 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,
>
- 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
- 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
- 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
- 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
> &
- 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
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
-
- 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
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
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
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
- 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
- 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);
> >
> >
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
> > 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
- 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
- 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:
> >>>>
- 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
- 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
- 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_
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
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
- 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
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
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
- 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
- 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
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
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
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
- 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
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
(__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
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
(__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
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
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
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
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
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
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
- 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
- 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().
>
>
- 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.
>
> > 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
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
1 - 100 of 135 matches
Mail list logo
