All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 203317] WARNING: CPU: 2 PID: 925 at fs/ext4/inode.c:3897 ext4_set_page_dirty+0x39/0x50
Date: Wed, 14 Aug 2019 00:13:59 +0000	[thread overview]
Message-ID: <bug-203317-13602-ISTW3vyo4Y@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-203317-13602@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=203317

howaboutsynergy is abandoned account everywhere (howaboutsynergy@pm.me) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jani.nikula@intel.com

--- Comment #4 from howaboutsynergy is abandoned account everywhere (howaboutsynergy@pm.me) ---
The commit that attempts to fix this(and thus links to this issue) is causing a
system freeze (where sysctl+s,u,b still works though) when attempting to cause
a memory pressure via script `memfreeze`(ran as variant 1) which I used in
order to test
[le9g.patch](https://www.phoronix.com/forums/forum/phoronix/general-discussion/1118164-yes-linux-does-bad-in-low-ram-memory-pressure-situations-on-the-desktop?p=1119440#post1119440)
that prevents disk thrashing, but this system freeze happens without that patch
also.

```
commit aa56a292ce623734ddd30f52d73f527d1f3529b5
    drm/i915/userptr: Acquire the page lock around set_page_dirty()
```

The freeze seems to be happening right before OOM-killer is about to kill
something, apparently.

I double checked that v5.3-rc4 with this commit reverted does indeed get rid of
the system freeze.

`memfreeze` script is this:

```

#!/bin/bash

#run this multiple times consecutively, but not at once.

#this should freeze i87k for about 1-2 seconds(actually 5 seconds - try running
top of watch -n1 -d cat /proc/meminfo) while running out of memory temporarily
just before OOM triggers and kills one of the threads:
#^ old comments

#Ensure watchers are running:
ensure_this_runs_already() {
  local cmdtorun="$*"
  if ! pgrep --full "^${cmdtorun}$" >/dev/null; then
    #shellcheck disable=SC2086
    xfce4-terminal -x $cmdtorun  #XXX: unquoted! else it will fail to launch!
  fi
}
ensure_this_runs_already "watch -n.1 -d cat /proc/meminfo"
#ensure_this_runs_already watch -n.1 -d cat /proc/meminfo #yes this works too!
I even tested it.
ensure_this_runs_already "top -d 0.5"
ensure_this_runs_already "sudo iotop -d 5 -o -b"
#exit 1


#XXX tested on i87k host
systemctl --user stop psd #otherwise have to manually rename 2+1 profile dirs
from *-backup to * after the system crashes(and it does with
5.3.0-rc4-gd45331b00ddb kernel, not with 5.2.0 (git) though, or 5.2.4 (stable)
)
if test "${0##*/}" == "memfreeze2"; then
  variant=2
elif test "${0##*/}" == "memfreeze3"; then
  variant=3
else
  variant=1
fi
echo "!! Using memfreeze variant '$variant'"

if test "$1" != "keepswap"; then
  echo "! swapoff first"
  sudo swapoff -a
  threads=2
  timeout=10s
else
  threads=6
  timeout=30s
fi
sync #because possibly crash! in fact guaranteed crash in
5.3.0-rc4-gd45331b00ddb even without any le*.patch-es

if test "$variant" == "1"; then
  #this is a remnant from when I've tested this on QubesOS
  alloc="$(awk '/MemAvailable/{printf "%d\n", $2 + 4000;}' < /proc/meminfo)"
  echo "Will alloc: $alloc kB for each of the $threads concurrent threads."
  echo "MemTotal before: $(awk '/MemTotal/{printf "%d kB\n", $2;}' <
/proc/meminfo)"
  time stress --vm-bytes "${alloc}k" --vm-keep -m $threads --timeout $timeout
  echo "exit code: $?"
  awk '/MemTotal/{printf "MemTotal afterwards: %d kB\n", $2;}' < /proc/meminfo
elif test "$variant" == "2"; then
  time stress -m 220 --vm-bytes 10000000000 --timeout 20
elif test "$variant" == "3"; then
  #XXX say bye bye to Xorg, courtesy of kernel's OOM-killer FIXME: somehow
disable oom-killer or what?!
  time stress -m 3000 --vm-bytes 10M --timeout 50
else
  echo "!! memfreeze variant not implemented"
fi
```

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

  parent reply	other threads:[~2019-08-14  0:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-15  7:58 [Bug 203317] New: WARNING: CPU: 2 PID: 925 at fs/ext4/inode.c:3897 ext4_set_page_dirty+0x39/0x50 bugzilla-daemon
2019-07-08 13:50 ` [Bug 203317] " bugzilla-daemon
2019-07-08 14:16 ` bugzilla-daemon
2019-07-20 16:53 ` bugzilla-daemon
2019-08-14  0:13 ` bugzilla-daemon [this message]
2019-08-14 16:36 ` bugzilla-daemon
2019-09-09  0:01 ` bugzilla-daemon
2019-09-09  8:09 ` bugzilla-daemon
2019-09-09  8:19 ` bugzilla-daemon
2019-09-09  8:39 ` bugzilla-daemon
2019-09-09  9:25 ` bugzilla-daemon
2019-09-09  9:36 ` bugzilla-daemon
2019-09-09  9:50 ` bugzilla-daemon
2019-09-09 10:32 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-203317-13602-ISTW3vyo4Y@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.