All of lore.kernel.org
 help / color / mirror / Atom feed
* [LTP] Holidays and LTP release
@ 2020-12-17 12:18 Cyril Hrubis
  2021-01-06 12:19 ` Cyril Hrubis
  0 siblings, 1 reply; 22+ messages in thread
From: Cyril Hrubis @ 2020-12-17 12:18 UTC (permalink / raw)
  To: ltp

Hi!
As usuall I will start my Christmas vacation tomorrow and then return
back to work after the New Year.

And as usually we are due to produce a release somewhere at the end of
January, that means that we should have our usuall git freeze and
pre-relase testing ideally somewhere at the end of the first week in
January.

I've tried to review and merge as many patches as possible during this
week, but if there is something that should definitly get in before the
release, just let me know and I will have a look.

And lastly but not least Merry Christmas and Happy New Year to everyone
who celbrates these.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2020-12-17 12:18 [LTP] Holidays and LTP release Cyril Hrubis
@ 2021-01-06 12:19 ` Cyril Hrubis
  2021-01-07 11:51   ` Cyril Hrubis
                     ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Cyril Hrubis @ 2021-01-06 12:19 UTC (permalink / raw)
  To: ltp

Hi!
As you may noticed I'm back and I'm trying to review anything that
should be considered for the release.

Please let me know if there is anything I should look into.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-06 12:19 ` Cyril Hrubis
@ 2021-01-07 11:51   ` Cyril Hrubis
  2021-01-08  1:23     ` Yang Xu
  2021-01-11 14:38     ` Cyril Hrubis
  2021-01-13  8:57   ` =?unknown-8bit?q?K=C3=B6ry?= Maincent
  2021-01-14  9:17   ` Martin Doucha
  2 siblings, 2 replies; 22+ messages in thread
From: Cyril Hrubis @ 2021-01-07 11:51 UTC (permalink / raw)
  To: ltp

Hi!
Is there anything that should be considered for the release?

If not I would like to freeze the git at the end of the week and start
the pre-relase testing on Monday next week.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-07 11:51   ` Cyril Hrubis
@ 2021-01-08  1:23     ` Yang Xu
  2021-01-08 13:28       ` Cyril Hrubis
  2021-01-11 14:38     ` Cyril Hrubis
  1 sibling, 1 reply; 22+ messages in thread
From: Yang Xu @ 2021-01-08  1:23 UTC (permalink / raw)
  To: ltp

Hi Cyril
> Hi!
> Is there anything that should be considered for the release?
We can apply patch[1] disables the test(ioctl_loop05) on overlay so that 
it's fixed for next release.

Also, please see patch[2] for cpu_inherit fix.

[1]https://patchwork.ozlabs.org/project/ltp/patch/20201215155650.6496-1-radoslav.kolev@suse.com/
[2]https://patchwork.ozlabs.org/project/ltp/patch/1606701966-1596-1-git-send-email-xuyang2018.jy@cn.fujitsu.com/

Best Regards
Yang Xu
>
> If not I would like to freeze the git at the end of the week and start
> the pre-relase testing on Monday next week.
>




^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-08  1:23     ` Yang Xu
@ 2021-01-08 13:28       ` Cyril Hrubis
  0 siblings, 0 replies; 22+ messages in thread
From: Cyril Hrubis @ 2021-01-08 13:28 UTC (permalink / raw)
  To: ltp

Hi!
> We can apply patch[1] disables the test(ioctl_loop05) on overlay so that 
> it's fixed for next release.

Agree, will you push it or should I do so?

> Also, please see patch[2] for cpu_inherit fix.

I looked at that one and acked it.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-07 11:51   ` Cyril Hrubis
  2021-01-08  1:23     ` Yang Xu
@ 2021-01-11 14:38     ` Cyril Hrubis
  2021-01-12 10:29       ` Petr Vorel
  1 sibling, 1 reply; 22+ messages in thread
From: Cyril Hrubis @ 2021-01-11 14:38 UTC (permalink / raw)
  To: ltp

Hi!
As I anounced last week please consider git frozen for anything but
important fixes now.

Also if you haven't done so yet, please test latest git head now and
report any problems you find.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-11 14:38     ` Cyril Hrubis
@ 2021-01-12 10:29       ` Petr Vorel
  0 siblings, 0 replies; 22+ messages in thread
From: Petr Vorel @ 2021-01-12 10:29 UTC (permalink / raw)
  To: ltp

Hi Cyril,

> Hi!
> As I anounced last week please consider git frozen for anything but
> important fixes now.

I was thinking about speedup if-mtu-change.sh [1], but unless Alexey ack that it
might be better to wait after the release.

I planned to merge two rewrites to new API (v2 get_mempolicy [2] and v3
multicast packed flood [3]), which are ready, but as there is a git freeze it
can wait after the release.

I'd also like to add some docs to ima_tpm.sh setup when running with
ima_policy=tcb on real HW, if I figure out what's needed.

I might have look into sigwaitinfo01 problems on MUSL.
There is a patch which needs to be rebased [4] (tests and libsigwait were
rewritten to new API). But simply remove all testcases because they does not
work on MUSL is probably no-go. I guess the problem is with using (void *)1 in
in various sigwaitinfo tests in test_bad_address{,2,3}()
(libs/libltpsigwait/sigwait.c).
Maybe use tst_get_bad_addr(NULL) here?

> Also if you haven't done so yet, please test latest git head now and
> report any problems you find.
Going to.

Kind regards,
Petr

[1] https://patchwork.ozlabs.org/project/ltp/patch/20210107120247.31465-1-pvorel@suse.cz/
[2] https://patchwork.ozlabs.org/project/ltp/patch/20210106181735.1588-1-pvorel@suse.cz/
[3] https://patchwork.ozlabs.org/project/ltp/list/?series=216562&state=*
[4] https://patchwork.ozlabs.org/project/ltp/patch/20200529014448.3815022-1-raj.khem@gmail.com/

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-06 12:19 ` Cyril Hrubis
  2021-01-07 11:51   ` Cyril Hrubis
@ 2021-01-13  8:57   ` =?unknown-8bit?q?K=C3=B6ry?= Maincent
  2021-01-14 11:12     ` Naresh Kamboju
  2021-01-14  9:17   ` Martin Doucha
  2 siblings, 1 reply; 22+ messages in thread
From: =?unknown-8bit?q?K=C3=B6ry?= Maincent @ 2021-01-13  8:57 UTC (permalink / raw)
  To: ltp

Hello Cyril,

On Wed, 6 Jan 2021 13:19:39 +0100
Cyril Hrubis <chrubis@suse.cz> wrote:

> Hi!
> As you may noticed I'm back and I'm trying to review anything that
> should be considered for the release.
> 
> Please let me know if there is anything I should look into.

I don't know if this can be useful before the release but I have made a table of
the result of my LTP test. The test was run on an iMX8 Quad with OpenEmbedded
distribution composed of Busybox and Dropbear.
https://drive.google.com/drive/folders/1fyBOCjwc_3JiJ3MmMZcWh-m_VVZIDlxv?usp=sharing


Regards,

K?ry

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-06 12:19 ` Cyril Hrubis
  2021-01-07 11:51   ` Cyril Hrubis
  2021-01-13  8:57   ` =?unknown-8bit?q?K=C3=B6ry?= Maincent
@ 2021-01-14  9:17   ` Martin Doucha
  2021-01-14 10:41     ` Cyril Hrubis
  2 siblings, 1 reply; 22+ messages in thread
From: Martin Doucha @ 2021-01-14  9:17 UTC (permalink / raw)
  To: ltp

On 06. 01. 21 13:19, Cyril Hrubis wrote:
> Hi!
> As you may noticed I'm back and I'm trying to review anything that
> should be considered for the release.
> 
> Please let me know if there is anything I should look into.

Can we add the tst_secureboot_enabled() patchset to the new release? It
fixes lockdown detection issues on some kernels and it shouldn't affect
anything except the iopl/ioperm syscall tests.
https://patchwork.ozlabs.org/project/ltp/list/?series=223859

-- 
Martin Doucha   mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-14  9:17   ` Martin Doucha
@ 2021-01-14 10:41     ` Cyril Hrubis
  0 siblings, 0 replies; 22+ messages in thread
From: Cyril Hrubis @ 2021-01-14 10:41 UTC (permalink / raw)
  To: ltp

Hi!
> Can we add the tst_secureboot_enabled() patchset to the new release? It
> fixes lockdown detection issues on some kernels and it shouldn't affect
> anything except the iopl/ioperm syscall tests.
> https://patchwork.ozlabs.org/project/ltp/list/?series=223859

I will have a look.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-13  8:57   ` =?unknown-8bit?q?K=C3=B6ry?= Maincent
@ 2021-01-14 11:12     ` Naresh Kamboju
  2021-01-14 14:14       ` Martin Doucha
  2021-01-14 14:36       ` Cyril Hrubis
  0 siblings, 2 replies; 22+ messages in thread
From: Naresh Kamboju @ 2021-01-14 11:12 UTC (permalink / raw)
  To: ltp

On Wed, 13 Jan 2021 at 14:27, K?ry Maincent <kory.maincent@bootlin.com> wrote:
>
> Hello Cyril,
>
> On Wed, 6 Jan 2021 13:19:39 +0100
> Cyril Hrubis <chrubis@suse.cz> wrote:
>
> > Hi!
> > As you may noticed I'm back and I'm trying to review anything that
> > should be considered for the release.
> >
> > Please let me know if there is anything I should look into.
>
> I don't know if this can be useful before the release but I have made a table of
> the result of my LTP test. The test was run on an iMX8 Quad with OpenEmbedded
> distribution composed of Busybox and Dropbear.

I have a similar problem for semctl09 failed on arm, arm64, i386 and x86_64.

semctl09.c:67: TINFO: Test SYS_semc[ 1067.769270] audit: type=1701
audit(1610604534.411:38): auid=4294967295 uid=0 gid=0 ses=4294967295
pid=6275 comm=\"semctl09\" exe=\"/opt/ltp/testcases/bin/semctl09\"
sig=11 res=1
tl syscall
semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user
semctl09.c:155: TPASS: SEM_INFO returned valid index 10 to semid 10
semctl09.c:164: TPASS: Counted used = 1
semctl09.c:112: TPASS: semset_cnt = 1
semctl09.c:119: TPASS: sen_cnt = 2
tst_test.c:1313: TBROK: Test killed by SIGSEGV!

And on i386,

tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s
semctl09.c:67: TINFO: Test SYS_semctl syscall
semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user
semctl09.c:155: TPASS: SEM_INFO returned valid index 11 to semid 11
semctl09.c:164: TPASS: Counted used = 1
semctl09.c:112: TPASS: semset_cnt = 1
semctl09.c:119: TPASS: sen_cnt = 2
semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user
semctl09.c:155: TPASS: SEM_INFO returned valid index 11 to semid 11
semctl09.c:164: TPASS: Counted used = 1
semctl09.c:112: TPASS: semset_cnt = 1
semctl09.c:119: TPASS: sen_cnt = 2
tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s
semctl09.c:70: TINFO: Test libc semctl()
semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user
semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified
by the caller to kernel
semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user
semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified
by the caller to kernel


only fails on the arm beagleboard-x15 device.

accept02.c:55: TBROK: setsockopt(3, 0, 42, 0xb6f4cf7c, 132) failed: ENODEV (19)

clock_gettime04.c:143: TFAIL: CLOCK_REALTIME: Time travelled backwards
(5): -1610153174499293029 ns
clock_gettime04.c:151: TFAIL: CLOCK_REALTIME_COARSE: Difference
between successive readings greater than 5 ms (4): 9
clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC: Difference between
successive readings is reasonable
clock_gettime04.c:151: TFAIL: CLOCK_MONOTONIC_COARSE: Difference
between successive readings greater than 5 ms (2): 9
clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC_RAW: Difference between
successive readings is reasonable
clock_gettime04.c:158: TPASS: CLOCK_BOOTTIME: Difference between
successive readings is reasonable

getrlimit03.c:168: TPASS: __NR_prlimit64(0) and __NR_ugetrlimit(0)
gave consistent results
tst_test.c:1313: TBROK: Test killed by SIGILL!


on x86_64:
The ioctl_sg01 test killed and reported failed.

tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s
ioctl_sg01.c:81: TINFO: Found SCSI device /dev/sg1
[  332.383394] ioctl_sg01 invoked oom-killer:
gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
[  332.393225] CPU: 0 PID: 14622 Comm: ioctl_sg01 Not tainted 5.10.6 #2
[  332.399572] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[  332.407080] Call Trace:
[  332.409543]  dump_stack+0x7d/0x9f
[  332.412861]  dump_header+0x4f/0x1f3
[  332.416351]  oom_kill_process.cold+0xb/0x10
[  332.420531]  out_of_memory+0x1bb/0x4e0
[  332.424283]  __alloc_pages_slowpath.constprop.0+0xc39/0xd00
[  332.429847]  __alloc_pages_nodemask+0x2a9/0x310
[  332.434379]  alloc_pages_current+0x87/0xe0
[  332.438470]  __page_cache_alloc+0x89/0xb0
[  332.442482]  pagecache_get_page+0xe3/0x280
[  332.446572]  filemap_fault+0x5b1/0xc90
[  332.450316]  ? page_add_file_rmap+0x16c/0x1d0
[  332.454666]  ? alloc_set_pte+0xf2/0x670
[  332.458498]  __do_fault+0x3c/0xa0
[  332.461808]  handle_mm_fault+0xf73/0x1610
[  332.465812]  ? finish_task_switch+0x74/0x230
[  332.470098]  do_user_addr_fault+0x1dc/0x3c0
[  332.474278]  exc_page_fault+0x54/0x110
[  332.478023]  ? asm_exc_page_fault+0x8/0x30
[  332.482112]  asm_exc_page_fault+0x1e/0x30
[  332.486116] RIP: 0033:0x7f7405231130
[  332.489691] Code: Unable to access opcode bytes at RIP 0x7f7405231106.
[  332.496214] RSP: 002b:00007fff9e9afe28 EFLAGS: 00010202
[  332.501430] RAX: 00007f7030e69000 RBX: 0000000000000001 RCX: 00007f7403e69000
[  332.508553] RDX: 0000000000000000 RSI: 0000000001000000 RDI: 00007f7403e69000
[  332.515677] RBP: 00007f7403e69000 R08: 0000000001000000 R09: 0000000000000000
[  332.522801] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000001000000
[  332.529926] R13: 000000000041861a R14: 000000000000003b R15: 0000000000000000
[  332.537092] Mem-Info:
[  332.539376] active_anon:144 inactive_anon:4026083 isolated_anon:0
[  332.539376]  active_file:63 inactive_file:8 isolated_file:0
[  332.539376]  unevictable:0 dirty:33 writeback:0
[  332.539376]  slab_reclaimable:4320 slab_unreclaimable:6040
[  332.539376]  mapped:136 shmem:6370 pagetables:8672 bounce:0
[  332.539376]  free:34555 free_pcp:20 free_cma:0
[  332.570972] Node 0 active_anon:576kB inactive_anon:16104332kB
active_file:180kB inactive_file:4kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB mapped:544kB dirty:132kB writeback:0kB
shmem:25480kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB
writeback_tmp:0kB kernel_stack:2400kB all_unreclaimable? yes
[  332.598731] Node 0 DMA free:15868kB min:64kB low:80kB high:96kB
reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
present:15964kB managed:15868kB mlocked:0kB pagetables:0kB bounce:0kB
free_pcp:0kB local_pcp:0kB free_cma:0kB
[  332.625036] lowmem_reserve[]: 0 2173 15940 15940
[  332.629729] Node 0 DMA32 free:64224kB min:9204kB low:11504kB
high:13804kB reserved_highatomic:0KB active_anon:0kB
inactive_anon:2156620kB active_file:0kB inactive_file:0kB
unevictable:0kB writepending:0kB present:2291100kB managed:2225564kB
mlocked:0kB pagetables:4216kB bounce:0kB free_pcp:0kB local_pcp:0kB
free_cma:0kB
[  332.658024] lowmem_reserve[]: 0 0 13766 13766
[  332.662375] Node 0 Normal free:58128kB min:58312kB low:72888kB
high:87464kB reserved_highatomic:0KB active_anon:576kB
inactive_anon:13947404kB active_file:744kB inactive_file:0kB
unevictable:0kB writepending:76kB present:14417920kB
managed:14101104kB mlocked:0kB pagetables:30472kB bounce:0kB
free_pcp:16kB local_pcp:0kB free_cma:0kB
[  332.691695] lowmem_reserve[]: 0 0 0 0
[  332.695361] Node 0 DMA: 1*4kB (U) 1*8kB (U) 1*16kB (U) 1*32kB (U)
1*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M)
3*4096kB (M) = 15868kB
[  332.709435] Node 0 DMA32: 2*4kB (UM) 3*8kB (UM) 3*16kB (UM) 2*32kB
(UM) 1*64kB (M) 2*128kB (UM) 1*256kB (M) 1*512kB (U) 0*1024kB 1*2048kB
(M) 15*4096kB (M) = 64720kB
[  332.724210] Node 0 Normal: 784*4kB (UME) 409*8kB (UME) 183*16kB
(UME) 67*32kB (UME) 38*64kB (E) 36*128kB (ME) 28*256kB (ME) 12*512kB
(ME) 4*1024kB (E) 1*2048kB (E) 5*4096kB (U) = 58456kB
[  332.740807] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=2048kB
[  332.749257] 6513 total pagecache pages
[  332.753001] 0 pages in swap cache
[  332.756338] Swap cache stats: add 0, delete 0, find 0/0
[  332.761563] Free swap  = 0kB
[  332.764441] Total swap = 0kB
[  332.767316] 4181246 pages RAM
[  332.770306] 0 pages HighMem/MovableOnly
[  332.774137] 95612 pages reserved
[  332.777363] Tasks state (memory values in pages):
[  332.782079] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes
swapents oom_score_adj name
[  332.790713] [    333]     0   333    12626      164   114688
0             0 systemd-journal
[  332.799749] [    348]     0   348    10499      275   114688
0         -1000 systemd-udevd
[  332.808615] [    372]   993   372     8666       79   114688
0             0 systemd-network
[  332.817652] [    384]   992   384     9529       77   122880
0             0 systemd-resolve
[  332.826686] [    387]   996   387     7243      154   106496
0          -900 dbus-daemon
[  332.835375] [    388]     0   388     2313       71    61440
0             0 crond
[  332.843564] [    389]     0   389     2112       19    57344
0             0 syslogd
[  332.851904] [    391]     0   391     3029      783    65536
0             0 haveged
[  332.860250] [    392]     0   392    81271      490   262144
0             0 NetworkManager
[  332.869229] [    393]     0   393     2112       20    61440
0             0 klogd
[  332.877402] [    395]     0   395     8615      107   110592
0             0 systemd-logind
[  332.886353] [    396]     0   396     1075       22    57344
0             0 acpid
[  332.894525] [    398]     0   398    34025      158   167936
0             0 thermald
[  332.902956] [    399]   995   399     9341       81   114688
0             0 avahi-daemon
[  332.911728] [    409]   995   409     9277       68   106496
0             0 avahi-daemon
[  332.920505] [    438] 65534   438     3245       38    65536
0             0 dnsmasq
[  332.928870] [    439]     0   439     3187       33    69632
0             0 agetty
[  332.937130] [    440]     0   440    14707      108   163840
0             0 login
[  332.945328] [    441]     0   441     3187       34    69632
0             0 agetty
[  332.953588] [    444]   998   444   131113      827   241664
0             0 polkitd
[  332.961932] [    461]     0   461     9532      162   118784
0             0 systemd
[  332.970270] [    462]     0   462    16166      462   163840
0             0 (sd-pam)
[  332.978719] [    466]     0   466     4538      104    77824
0             0 sh
[  332.986632] [    471]     0   471    11102       83   135168
0             0 su
[  332.994544] [    472]     0   472     4538      100    77824
0             0 sh
[  333.002455] [    517]     0   517     2396       56    61440
0             0 lava-test-runne
[  333.011487] [    527]     0   527     2396       52    65536
0             0 lava-test-shell
[  333.020525] [    528]     0   528     2396       55    69632
0             0 sh
[  333.028455] [    530]     0   530     2495      169    65536
0             0 ltp.sh
[  333.036707] [    553]     0   553     2495      169    61440
0             0 ltp.sh
[  333.044965] [    554]     0   554     2495      169    61440
0             0 ltp.sh
[  333.053224] [    555]     0   555     2495      169    61440
0             0 ltp.sh
[  333.061473] [    556]     0   556     2561      224    69632
0             0 runltp
[  333.069725] [    557]     0   557     1072       15    53248
0             0 tee
[  333.077725] [    623]     0   623     1103       66    61440
0             0 ltp-pan
[  333.086069] [  14595]     0 14595     3187       34    73728
0             0 agetty
[  333.094347] [  14621]     0 14621     1198       16    49152
0             0 ioctl_sg01
[  333.102951] [  14622]     0 14622  4015311  4014104 32231424
0             0 ioctl_sg01
[  333.111548] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=ioctl_sg01,pid=14622,uid=0
[  333.124428] Out of memory: Killed process 14622 (ioctl_sg01)
total-vm:16061244kB, anon-rss:16056416kB, file-rss:0kB, shmem-rss:0kB,
UID:0 pgtables:31476kB oom_score_adj:0
[  333.374806] oom_reaper: reaped process 14622 (ioctl_sg01), now
anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
tst_test.c:1308: TINFO: If you are running on slow machine, try
exporting LTP_TIMEOUT_MUL > 1
tst_test.c:1309: TBROK: Test killed! (timeout?)


ksm03 and ksm03_1 both failed due to,

tst_device.c:423: TINFO: No device is mounted at /tmp/cgroup_mem
tst_cgroup.c:122: TINFO: Cgroup v2 mount at /tmp/cgroup_mem success
tst_cgroup.c:301: TBROK: Failed to close FILE
'/tmp/cgroup_mem/cgroup.subtree_control': ENOENT (2)

> https://drive.google.com/drive/folders/1fyBOCjwc_3JiJ3MmMZcWh-m_VVZIDlxv?usp=sharing


- Naresh

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-14 11:12     ` Naresh Kamboju
@ 2021-01-14 14:14       ` Martin Doucha
  2021-01-20  9:31         ` Naresh Kamboju
  2021-01-14 14:36       ` Cyril Hrubis
  1 sibling, 1 reply; 22+ messages in thread
From: Martin Doucha @ 2021-01-14 14:14 UTC (permalink / raw)
  To: ltp

On 14. 01. 21 12:12, Naresh Kamboju wrote:
> on x86_64:
> The ioctl_sg01 test killed and reported failed.
> 
> tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s
> ioctl_sg01.c:81: TINFO: Found SCSI device /dev/sg1
> [  332.383394] ioctl_sg01 invoked oom-killer:

Looks like the safety margin in tst_pollute_memory() is too small. Edit
lib/tst_memutils.c and try setting the "safety" variable on line 23 to a
higher value. I'd recommend something like MAX(4096 pages, 64MB).

-- 
Martin Doucha   mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-14 11:12     ` Naresh Kamboju
  2021-01-14 14:14       ` Martin Doucha
@ 2021-01-14 14:36       ` Cyril Hrubis
  2021-01-15  8:27         ` Naresh Kamboju
  1 sibling, 1 reply; 22+ messages in thread
From: Cyril Hrubis @ 2021-01-14 14:36 UTC (permalink / raw)
  To: ltp

Hi!
> I have a similar problem for semctl09 failed on arm, arm64, i386 and x86_64.
> 
> semctl09.c:67: TINFO: Test SYS_semc[ 1067.769270] audit: type=1701
> audit(1610604534.411:38): auid=4294967295 uid=0 gid=0 ses=4294967295
> pid=6275 comm=\"semctl09\" exe=\"/opt/ltp/testcases/bin/semctl09\"
> sig=11 res=1
> tl syscall
> semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user
> semctl09.c:155: TPASS: SEM_INFO returned valid index 10 to semid 10
> semctl09.c:164: TPASS: Counted used = 1
> semctl09.c:112: TPASS: semset_cnt = 1
> semctl09.c:119: TPASS: sen_cnt = 2
> tst_test.c:1313: TBROK: Test killed by SIGSEGV!

There seems to be a part of the log missing here, if it's segfaulting in
the libc semctl() there used to be glibc bug for SEM_STAT_ANY which may
cause SIGSEGV:

https://sourceware.org/bugzilla/show_bug.cgi?id=26637

> And on i386,
> 
> tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s
> semctl09.c:67: TINFO: Test SYS_semctl syscall
> semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user
> semctl09.c:155: TPASS: SEM_INFO returned valid index 11 to semid 11
> semctl09.c:164: TPASS: Counted used = 1
> semctl09.c:112: TPASS: semset_cnt = 1
> semctl09.c:119: TPASS: sen_cnt = 2
> semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user
> semctl09.c:155: TPASS: SEM_INFO returned valid index 11 to semid 11
> semctl09.c:164: TPASS: Counted used = 1
> semctl09.c:112: TPASS: semset_cnt = 1
> semctl09.c:119: TPASS: sen_cnt = 2
> tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s
> semctl09.c:70: TINFO: Test libc semctl()
> semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user
> semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified
> by the caller to kernel
> semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user
> semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified
> by the caller to kernel

This just says that the glibc bug is present so it's likely that the
same bug is causing segfaults on the rest of the architectures.

> only fails on the arm beagleboard-x15 device.
> 
> accept02.c:55: TBROK: setsockopt(3, 0, 42, 0xb6f4cf7c, 132) failed: ENODEV (19)

Looks like muticast groups is not compiled in kernel here.

We should handle this and report TCONF instead, however this is not a
regression, the test has been like this for three years.

> clock_gettime04.c:143: TFAIL: CLOCK_REALTIME: Time travelled backwards
> (5): -1610153174499293029 ns
> clock_gettime04.c:151: TFAIL: CLOCK_REALTIME_COARSE: Difference
> between successive readings greater than 5 ms (4): 9
> clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC: Difference between
> successive readings is reasonable
> clock_gettime04.c:151: TFAIL: CLOCK_MONOTONIC_COARSE: Difference
> between successive readings greater than 5 ms (2): 9
> clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC_RAW: Difference between
> successive readings is reasonable
> clock_gettime04.c:158: TPASS: CLOCK_BOOTTIME: Difference between
> successive readings is reasonable

This shouldn't really happen, what this says is that time jumped 51
years back. That is really absurd.

> getrlimit03.c:168: TPASS: __NR_prlimit64(0) and __NR_ugetrlimit(0)
> gave consistent results
> tst_test.c:1313: TBROK: Test killed by SIGILL!

Can we have a backtrace here? It's impossible to say what happened here
without further debugging.

> on x86_64:
> The ioctl_sg01 test killed and reported failed.
> 
> tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s
> ioctl_sg01.c:81: TINFO: Found SCSI device /dev/sg1
> [  332.383394] ioctl_sg01 invoked oom-killer:

That's likely due to tst_pollutte_memory().

What are the overcommit settings on that machine?

This is probably worth fixing before the release if we manage to figure
out the cause.

> ksm03 and ksm03_1 both failed due to,
> 
> tst_device.c:423: TINFO: No device is mounted at /tmp/cgroup_mem
> tst_cgroup.c:122: TINFO: Cgroup v2 mount at /tmp/cgroup_mem success
> tst_cgroup.c:301: TBROK: Failed to close FILE
> '/tmp/cgroup_mem/cgroup.subtree_control': ENOENT (2)

That is known and reported:

https://github.com/linux-test-project/ltp/issues/734

Ritchard is trying to rewrite LTP cgroup library to solved this, it
should land in git repository in a month or two.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-14 14:36       ` Cyril Hrubis
@ 2021-01-15  8:27         ` Naresh Kamboju
  2021-01-15 14:00           ` Cyril Hrubis
  0 siblings, 1 reply; 22+ messages in thread
From: Naresh Kamboju @ 2021-01-15  8:27 UTC (permalink / raw)
  To: ltp

On Thu, 14 Jan 2021 at 20:05, Cyril Hrubis <chrubis@suse.cz> wrote:
>
> Hi!
> > I have a similar problem for semctl09 failed on arm, arm64, i386 and x86_64.
> >
> > semctl09.c:67: TINFO: Test SYS_semc[ 1067.769270] audit: type=1701
> > audit(1610604534.411:38): auid=4294967295 uid=0 gid=0 ses=4294967295
> > pid=6275 comm=\"semctl09\" exe=\"/opt/ltp/testcases/bin/semctl09\"
> > sig=11 res=1
> > tl syscall
> > semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user
> > semctl09.c:155: TPASS: SEM_INFO returned valid index 10 to semid 10
> > semctl09.c:164: TPASS: Counted used = 1
> > semctl09.c:112: TPASS: semset_cnt = 1
> > semctl09.c:119: TPASS: sen_cnt = 2
> > tst_test.c:1313: TBROK: Test killed by SIGSEGV!
>
> There seems to be a part of the log missing here, if it's segfaulting in
> the libc semctl() there used to be glibc bug for SEM_STAT_ANY which may
> cause SIGSEGV:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=26637
>
> > And on i386,
> >
> > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s
> > semctl09.c:67: TINFO: Test SYS_semctl syscall
> > semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user
> > semctl09.c:155: TPASS: SEM_INFO returned valid index 11 to semid 11
> > semctl09.c:164: TPASS: Counted used = 1
> > semctl09.c:112: TPASS: semset_cnt = 1
> > semctl09.c:119: TPASS: sen_cnt = 2
> > semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user
> > semctl09.c:155: TPASS: SEM_INFO returned valid index 11 to semid 11
> > semctl09.c:164: TPASS: Counted used = 1
> > semctl09.c:112: TPASS: semset_cnt = 1
> > semctl09.c:119: TPASS: sen_cnt = 2
> > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s
> > semctl09.c:70: TINFO: Test libc semctl()
> > semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user
> > semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified
> > by the caller to kernel
> > semctl09.c:132: TINFO: Test SEM_STAT_ANY with root user
> > semctl09.c:149: TFAIL: SEM_STAT_ANY doesn't pass the buffer specified
> > by the caller to kernel
>
> This just says that the glibc bug is present so it's likely that the
> same bug is causing segfaults on the rest of the architectures.
>
> > only fails on the arm beagleboard-x15 device.
> >
> > accept02.c:55: TBROK: setsockopt(3, 0, 42, 0xb6f4cf7c, 132) failed: ENODEV (19)
>
> Looks like muticast groups is not compiled in kernel here.

True.
We have not enabled multicast groups.
# CONFIG_IP_MULTICAST is not set


>
> We should handle this and report TCONF instead, however this is not a
> regression, the test has been like this for three years.

Reporting TCONF would be right here.

>
> > clock_gettime04.c:143: TFAIL: CLOCK_REALTIME: Time travelled backwards
> > (5): -1610153174499293029 ns
> > clock_gettime04.c:151: TFAIL: CLOCK_REALTIME_COARSE: Difference
> > between successive readings greater than 5 ms (4): 9
> > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC: Difference between
> > successive readings is reasonable
> > clock_gettime04.c:151: TFAIL: CLOCK_MONOTONIC_COARSE: Difference
> > between successive readings greater than 5 ms (2): 9
> > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC_RAW: Difference between
> > successive readings is reasonable
> > clock_gettime04.c:158: TPASS: CLOCK_BOOTTIME: Difference between
> > successive readings is reasonable
>
> This shouldn't really happen, what this says is that time jumped 51
> years back. That is really absurd.

This is always reproduced on arm beagleboard-x15, i386 32-bit qemu_i386
and qemu_arm.

clock_gettime04.c:143: TFAIL: CLOCK_REALTIME: Time travelled backwards
(5): -1610599851098100352 ns

https://lkft.validation.linaro.org/scheduler/job/2142122#L3885
https://lkft.validation.linaro.org/scheduler/job/2144548#L2534


>
> > getrlimit03.c:168: TPASS: __NR_prlimit64(0) and __NR_ugetrlimit(0)
> > gave consistent results
> > tst_test.c:1313: TBROK: Test killed by SIGILL!
>
> Can we have a backtrace here? It's impossible to say what happened here
> without further debugging.

I do not have backtrace log for this now.
Let me share strace output log in this link,
# strace -f ./getrlimit03
https://lkft.validation.linaro.org/scheduler/job/2145166#L2569

>
> > on x86_64:
> > The ioctl_sg01 test killed and reported failed.
> >
> > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s
> > ioctl_sg01.c:81: TINFO: Found SCSI device /dev/sg1
> > [  332.383394] ioctl_sg01 invoked oom-killer:
>
> That's likely due to tst_pollutte_memory().
>
> What are the overcommit settings on that machine?

overcommit_memory is 0.
After changing overcommit to 2 the test got PASS.

> This is probably worth fixing before the release if we manage to figure
> out the cause.

cat /proc/sys/vm/overcommit_memory
0
cat /proc/sys/vm/overcommit_ratio
50
./runltp -s ioctl_sg01 --> FAILED

echo 2 > /proc/sys/vm/overcommit_memory
cat /proc/sys/vm/overcommit_memory
2
./runltp -s ioctl_sg01 --> PASS

Full test run  link,
https://lkft.validation.linaro.org/scheduler/job/2142340#L8823

- Naresh

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-15  8:27         ` Naresh Kamboju
@ 2021-01-15 14:00           ` Cyril Hrubis
  2021-01-15 14:27             ` Cyril Hrubis
  0 siblings, 1 reply; 22+ messages in thread
From: Cyril Hrubis @ 2021-01-15 14:00 UTC (permalink / raw)
  To: ltp

Hi!
> > > semctl09.c:132: TINFO: Test SEM_STAT_ANY with nobody user
> > > semctl09.c:155: TPASS: SEM_INFO returned valid index 10 to semid 10
> > > semctl09.c:164: TPASS: Counted used = 1
> > > semctl09.c:112: TPASS: semset_cnt = 1
> > > semctl09.c:119: TPASS: sen_cnt = 2
> > > tst_test.c:1313: TBROK: Test killed by SIGSEGV!
> >
> > There seems to be a part of the log missing here, if it's segfaulting in
> > the libc semctl() there used to be glibc bug for SEM_STAT_ANY which may
> > cause SIGSEGV:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=26637

And it looks like there is something strange going on here, Martin
Doucha is looking into it at the moment.

> > > accept02.c:55: TBROK: setsockopt(3, 0, 42, 0xb6f4cf7c, 132) failed: ENODEV (19)
> >
> > Looks like muticast groups is not compiled in kernel here.
> 
> True.
> We have not enabled multicast groups.
> # CONFIG_IP_MULTICAST is not set
> 
> >
> > We should handle this and report TCONF instead, however this is not a
> > regression, the test has been like this for three years.
> 
> Reporting TCONF would be right here.

Sure, however since this is not a regression let's do that after the
release. Feel free to open an issue so that it's not forgotten.

> > > clock_gettime04.c:143: TFAIL: CLOCK_REALTIME: Time travelled backwards
> > > (5): -1610153174499293029 ns
> > > clock_gettime04.c:151: TFAIL: CLOCK_REALTIME_COARSE: Difference
> > > between successive readings greater than 5 ms (4): 9
> > > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC: Difference between
> > > successive readings is reasonable
> > > clock_gettime04.c:151: TFAIL: CLOCK_MONOTONIC_COARSE: Difference
> > > between successive readings greater than 5 ms (2): 9
> > > clock_gettime04.c:158: TPASS: CLOCK_MONOTONIC_RAW: Difference between
> > > successive readings is reasonable
> > > clock_gettime04.c:158: TPASS: CLOCK_BOOTTIME: Difference between
> > > successive readings is reasonable
> >
> > This shouldn't really happen, what this says is that time jumped 51
> > years back. That is really absurd.
> 
> This is always reproduced on arm beagleboard-x15, i386 32-bit qemu_i386
> and qemu_arm.
> 
> clock_gettime04.c:143: TFAIL: CLOCK_REALTIME: Time travelled backwards
> (5): -1610599851098100352 ns
> 
> https://lkft.validation.linaro.org/scheduler/job/2142122#L3885
> https://lkft.validation.linaro.org/scheduler/job/2144548#L2534

I've reproduced it here on RPI board, I will have a look.

> > > getrlimit03.c:168: TPASS: __NR_prlimit64(0) and __NR_ugetrlimit(0)
> > > gave consistent results
> > > tst_test.c:1313: TBROK: Test killed by SIGILL!
> >
> > Can we have a backtrace here? It's impossible to say what happened here
> > without further debugging.
> 
> I do not have backtrace log for this now.
> Let me share strace output log in this link,
> # strace -f ./getrlimit03
> https://lkft.validation.linaro.org/scheduler/job/2145166#L2569

Thanks.

I've managed to reproduce as well but I have no idea what happens there,
it looks like something gets corrupted and the processor attempts to
execute invalid code.

Maybe we pass wrong size of the rlim structure somewhere and kernel
writes over a stack.

> > > on x86_64:
> > > The ioctl_sg01 test killed and reported failed.
> > >
> > > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s
> > > ioctl_sg01.c:81: TINFO: Found SCSI device /dev/sg1
> > > [  332.383394] ioctl_sg01 invoked oom-killer:
> >
> > That's likely due to tst_pollutte_memory().
> >
> > What are the overcommit settings on that machine?
> 
> overcommit_memory is 0.
> After changing overcommit to 2 the test got PASS.
> 
> > This is probably worth fixing before the release if we manage to figure
> > out the cause.
> 
> cat /proc/sys/vm/overcommit_memory
> 0
> cat /proc/sys/vm/overcommit_ratio
> 50
> ./runltp -s ioctl_sg01 --> FAILED
> 
> echo 2 > /proc/sys/vm/overcommit_memory
> cat /proc/sys/vm/overcommit_memory
> 2
> ./runltp -s ioctl_sg01 --> PASS

So it looks like we need better safety margin.

Have you tried to increase the safety in the lib/tst_memutils.c as
pointed out by Martin?

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-15 14:00           ` Cyril Hrubis
@ 2021-01-15 14:27             ` Cyril Hrubis
  0 siblings, 0 replies; 22+ messages in thread
From: Cyril Hrubis @ 2021-01-15 14:27 UTC (permalink / raw)
  To: ltp

Hi!
> > > > getrlimit03.c:168: TPASS: __NR_prlimit64(0) and __NR_ugetrlimit(0)
> > > > gave consistent results
> > > > tst_test.c:1313: TBROK: Test killed by SIGILL!
> > >
> > > Can we have a backtrace here? It's impossible to say what happened here
> > > without further debugging.
> > 
> > I do not have backtrace log for this now.
> > Let me share strace output log in this link,
> > # strace -f ./getrlimit03
> > https://lkft.validation.linaro.org/scheduler/job/2145166#L2569
> 
> Thanks.
> 
> I've managed to reproduce as well but I have no idea what happens there,
> it looks like something gets corrupted and the processor attempts to
> execute invalid code.
> 
> Maybe we pass wrong size of the rlim structure somewhere and kernel
> writes over a stack.

This is really strange it looks like glibc has wrong syscall number for
getrlimit.

On 32bit ARM I do have in /usr/include/asm-generic/unistd.h

#define __NR_getrlimit 163

While the getrlimit should be 191. It looks like x86-64 syscall
definitions are installed on the system for some strange reason, even
the header says that it's for x86-64.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-14 14:14       ` Martin Doucha
@ 2021-01-20  9:31         ` Naresh Kamboju
  2021-01-20 10:26           ` Cyril Hrubis
  0 siblings, 1 reply; 22+ messages in thread
From: Naresh Kamboju @ 2021-01-20  9:31 UTC (permalink / raw)
  To: ltp

On Thu, 14 Jan 2021 at 19:44, Martin Doucha <mdoucha@suse.cz> wrote:
>
> On 14. 01. 21 12:12, Naresh Kamboju wrote:
> > on x86_64:
> > The ioctl_sg01 test killed and reported failed.
> >
> > tst_test.c:1263: TINFO: Timeout per run is 0h 15m 00s
> > ioctl_sg01.c:81: TINFO: Found SCSI device /dev/sg1
> > [  332.383394] ioctl_sg01 invoked oom-killer:
>
> Looks like the safety margin in tst_pollute_memory() is too small. Edit
> lib/tst_memutils.c and try setting the "safety" variable on line 23 to a
> higher value. I'd recommend something like MAX(4096 pages, 64MB).

do you mean something like this ?
But this change did not solve the problem (ioctl_sg01) i have reported.

diff --git a/lib/tst_memutils.c b/lib/tst_memutils.c
index f134d90c9..00bf45e9c 100644
--- a/lib/tst_memutils.c
+++ b/lib/tst_memutils.c
@@ -20,7 +20,7 @@ void tst_pollute_memory(size_t maxsize, int fillchar)
        struct sysinfo info;

        SAFE_SYSINFO(&info);
-       safety = 4096 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit;
+       safety = 8192 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit;

        if (info.freeswap > safety)
                safety = 0;


After the above change the test case ioctl_sg01 fails intermittently
when running
multiple times.
https://lkft.validation.linaro.org/scheduler/job/2170593#L1357


- Naresh

^ permalink raw reply related	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-20  9:31         ` Naresh Kamboju
@ 2021-01-20 10:26           ` Cyril Hrubis
  2021-01-20 13:33             ` Cyril Hrubis
  0 siblings, 1 reply; 22+ messages in thread
From: Cyril Hrubis @ 2021-01-20 10:26 UTC (permalink / raw)
  To: ltp

Hi!
> do you mean something like this ?
> But this change did not solve the problem (ioctl_sg01) i have reported.
> 
> diff --git a/lib/tst_memutils.c b/lib/tst_memutils.c
> index f134d90c9..00bf45e9c 100644
> --- a/lib/tst_memutils.c
> +++ b/lib/tst_memutils.c
> @@ -20,7 +20,7 @@ void tst_pollute_memory(size_t maxsize, int fillchar)
>         struct sysinfo info;
> 
>         SAFE_SYSINFO(&info);
> -       safety = 4096 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit;
> +       safety = 8192 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit;

Actually Martin sugessted a different patch that chooses the margin to
be the greater of 4096 pages or 64MB, which would effectivelly set the
safety to "16384 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit" on most
systems.

Also I've been playing with a VM and I've been able to reproduce
occasional failures with swap turned off and memory_overcommit set to 1
that Martin's patch fixed for me.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-20 10:26           ` Cyril Hrubis
@ 2021-01-20 13:33             ` Cyril Hrubis
  0 siblings, 0 replies; 22+ messages in thread
From: Cyril Hrubis @ 2021-01-20 13:33 UTC (permalink / raw)
  To: ltp

Hi!
> > do you mean something like this ?
> > But this change did not solve the problem (ioctl_sg01) i have reported.
> > 
> > diff --git a/lib/tst_memutils.c b/lib/tst_memutils.c
> > index f134d90c9..00bf45e9c 100644
> > --- a/lib/tst_memutils.c
> > +++ b/lib/tst_memutils.c
> > @@ -20,7 +20,7 @@ void tst_pollute_memory(size_t maxsize, int fillchar)
> >         struct sysinfo info;
> > 
> >         SAFE_SYSINFO(&info);
> > -       safety = 4096 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit;
> > +       safety = 8192 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit;
> 
> Actually Martin sugessted a different patch that chooses the margin to
> be the greater of 4096 pages or 64MB, which would effectivelly set the
> safety to "16384 * SAFE_SYSCONF(_SC_PAGESIZE) / info.mem_unit" on most
> systems.
> 
> Also I've been playing with a VM and I've been able to reproduce
> occasional failures with swap turned off and memory_overcommit set to 1
> that Martin's patch fixed for me.

And it looks like the patch for tst_memutils.c is the last one that
should be taken care of before the release.

It would be nice if you could check if that fixes your failures as well.

However it made the situation better, at least for me, so I will push it
tomorrow morning and proceed with the release.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
  2021-01-15 15:08 gengcixi
@ 2021-01-19 10:43 ` Cyril Hrubis
  0 siblings, 0 replies; 22+ messages in thread
From: Cyril Hrubis @ 2021-01-19 10:43 UTC (permalink / raw)
  To: ltp

Hi!
>  Recently I was forbiden to use gmail. so I hava to use this email to send you message.
> 
> And I want to know does the rtc02 patchset can merged into the release??

Sorry, it was too late for the current release. I will make sure it gets
merged right after the Jan 2021 release is done.

-- 
Cyril Hrubis
chrubis@suse.cz

^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
@ 2021-01-15 15:08 gengcixi
  2021-01-19 10:43 ` Cyril Hrubis
  0 siblings, 1 reply; 22+ messages in thread
From: gengcixi @ 2021-01-15 15:08 UTC (permalink / raw)
  To: ltp



Hi Cyril:

 Recently I was forbiden to use gmail. so I hava to use this email to send you message.

And I want to know does the rtc02 patchset can merged into the release?

 If no big errors? please help review and merged?thanks?

 [1] https://patchwork.ozlabs.org/project/ltp/patch/20210111083711.1715851-2-gengcixi@gmail.com/
 [2] https://patchwork.ozlabs.org/project/ltp/patch/20210111083711.1715851-3-gengcixi@gmail.com/
 [3] https://patchwork.ozlabs.org/project/ltp/patch/20210111083711.1715851-4-gengcixi@gmail.com/


^ permalink raw reply	[flat|nested] 22+ messages in thread

* [LTP] Holidays and LTP release
@ 2021-01-14 15:01 gengcixi
  0 siblings, 0 replies; 22+ messages in thread
From: gengcixi @ 2021-01-14 15:01 UTC (permalink / raw)
  To: ltp

An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210114/233a150b/attachment.htm>

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2021-01-20 13:33 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-17 12:18 [LTP] Holidays and LTP release Cyril Hrubis
2021-01-06 12:19 ` Cyril Hrubis
2021-01-07 11:51   ` Cyril Hrubis
2021-01-08  1:23     ` Yang Xu
2021-01-08 13:28       ` Cyril Hrubis
2021-01-11 14:38     ` Cyril Hrubis
2021-01-12 10:29       ` Petr Vorel
2021-01-13  8:57   ` =?unknown-8bit?q?K=C3=B6ry?= Maincent
2021-01-14 11:12     ` Naresh Kamboju
2021-01-14 14:14       ` Martin Doucha
2021-01-20  9:31         ` Naresh Kamboju
2021-01-20 10:26           ` Cyril Hrubis
2021-01-20 13:33             ` Cyril Hrubis
2021-01-14 14:36       ` Cyril Hrubis
2021-01-15  8:27         ` Naresh Kamboju
2021-01-15 14:00           ` Cyril Hrubis
2021-01-15 14:27             ` Cyril Hrubis
2021-01-14  9:17   ` Martin Doucha
2021-01-14 10:41     ` Cyril Hrubis
2021-01-14 15:01 gengcixi
2021-01-15 15:08 gengcixi
2021-01-19 10:43 ` Cyril Hrubis

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.