Re: [git pull] vfs.git sysv pile

["Fabio M. De Francesco" <fmdefrancesco@gmail.com>]

On mercoledì 8 marzo 2023 18:40:44 CET Fabio M. De Francesco wrote:
> On giovedì 2 marzo 2023 20:35:59 CET Al Viro wrote:
> 
> [...]
> 
> > Frankly, ext2 patchset had been more along the lines of "here's what
> > untangling the calling conventions in ext2 would probably look like" than
> > anything else. If you are willing to test (and review) that sucker and it
> > turns out to be OK, I'll be happy to slap your tested-by on those during
> > rebase and feed them to Jan...
> 
> I git-clone(d) and built your "vfs" tree, branch #work.ext2, without and 
with
> the following commits:
> 
> f5b399373756 ("ext2: use offset_in_page() instead of open-coding it as
> subtraction")
> 
> c7248e221fb5 ("ext2_get_page(): saner type")
> 
> 470e54a09898 ("ext2_put_page(): accept any pointer within the page")
> 
> 15abcc147cf7 ("ext2_{set_link,delete_entry}(): don't bother with page_addr")
> 
> 16a5ee2027b7 ("ext2_find_entry()/ext2_dotdot(): callers don't need page_addr
> anymore")
> 
> Then I read the code and FWIW the five patches look good to me. I think they
> can work properly.
> 
> Therefore, if you want to, please feel free to add my "Reviewed-by" tag (OK, 
I
> know that you don't need my reviews, since you are the one who taught me how
> to write patches like yours for sysv and ufs :-)).
> 
> As a personal preference, in ext2_get_page() I'd move the two lines of code
> from the "fail" label to the same 'if' block where you have the "goto 
fail;",
> mainly because that label is only reachable from there. However, it does not
> matter at all because I'm only expressing my personal preference.
> 
> I ran `./check -g quick` without your patches in a QEMU/KVM x86_32 VM, 6GB
> RAM, running a Kernel with HIGHMEM64GB enabled. I ran it three or four times
> because it kept on hanging at random tests' numbers.
> 
> I'm noticing the same pattern due to the oom killer kicking in several times
> to kill processes until xfstests its is dead.
> 
> [ 1171.795551] Out of memory: Killed process 1669 (xdg-desktop-por) total-
vm:
> 105068kB, anon-rss:9792kB, file-rss:10972kB, shmem-rss:0kB, UID:1000 
pgtables:
> 136kB oom_score_adj:200
> [ 1172.339920] systemd invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL),
> order=0, oom_score_adj=100
> [ 1172.339927] CPU: 3 PID: 1413 Comm: systemd Tainted: G S      W   E
> 6.3.0-rc1-x86-32-debug+ #1
> [ 1172.339929] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> rel-1.16.0-0-gd239552-rebuilt.opensuse.org 04/01/2014
> [ 1172.339931] Call Trace:
> [ 1172.339934]  dump_stack_lvl+0x92/0xd4
> [ 1172.339939]  dump_stack+0xd/0x10
> [ 1172.339941]  dump_header+0x42/0x454
> [ 1172.339945]  ? ___ratelimit+0x6f/0x140
> [ 1172.339948]  oom_kill_process+0xe9/0x244
> [ 1172.339950]  out_of_memory+0xf6/0x424
> 
> I have not enough experience to understand why we get to that out-of-memory
> condition, so that several processes get killed. I can send the whole 
decoded
> stack trace and other information to whoever can look at this issue to 
figure
> out how to fix this big issue. I can try to bisect this issue too, but I 
need
> time because of other commitments and a slow system for building the 
necessary
> kernels.
> 
> I want to stress that it does not depend on the above-mentioned patches. 
Yes,
> I'm running Al's "vfs" tree, #work.ext2 branch, but with one only patch 
beyond
> the merge with Linus' tree:
> 
> 522dad1 ext2_rename(): set_link and delete_entry may fail
> 
> I have no means to test this tree. However, I think that I'd have the same
> issue with Linus' tree too, unless this issue is due to the only commit not
> yet there (I strongly doubt about this possibility).
> 
> Thanks,
> 
> Fabio

I want to confirm that running xfstests on the most recent SUSE Kernel doesn't 
trigger the OOM Killer. It only fails 16 of 597 tests. I suppose that those 16 
failures are expected to happen.

The kernel provided by openSUSE Tumbleweed is...

uname -a
Linux tweed32 6.2.1-1-pae #1 SMP PREEMPT_DYNAMIC Mon Feb 27 11:39:51 UTC 2023 
(69e0e95) i686 athlon i386 GNU/Linux

I'll try a bisection as soon as possible.

Fabio