Then, start running the following loop:
$ while true; do pkill -9 -t pts/1; sleep 1; done
In this point, we don't have a pts/1 there, but keep it running.
(b) In another terminal from the ssh client, run:
$ while true; do ssh <host/test machine ip>; done
Notice it's interesting to have the following in the .ssh/config of the ssh client machine:
Host <test/host machine alias> ControlMaster auto
ControlPath ~/.ssh/%r@%h-%p ControlPersist 600
in order to keep only one ssh connection opened.
(c) While the SSH in pts/1 is opened and killed automatically (and reopened by the loop), user must keep typing things in the keyboard in that terminal to force the tty flush.
(d) After running that for some seconds, one can verify in the trace output that the functions modified by the main patch in the SRUed series are there:
Also, the pattern showed in the trace file shows that the functions are called intermixed:
[...]
kworker/u56:1-3602 [000] .... 881.779225: tty_name: (n_tty_receive_buf2+0x0/0x20) tty="pts1"
kworker/u56:1-3602 [000] .... 881.861901: tty_name: (n_tty_receive_buf2+0x0/0x20) tty="pts1"
sshd-3403 [023] .... 882.249355: tty_reopen <-tty_open
bash-4052 [008] .... 882.250432: tty_reopen <-tty_open
bash-4052 [008] .... 882.250441: tty_reopen <-tty_open
bash-4052 [008] .... 882.251935: tty_reopen <-tty_open
kworker/u56:1-3602 [000] .... 882.440866: tty_name: (n_tty_receive_buf2+0x0/0x20) tty="pts1"
kworker/u56:1-3602 [000] .... 882.482994: tty_name: (n_tty_receive_buf2+0x0/0x20) tty="pts1"
[...]
Worth to notice that I've ran the test in 4.18.0-13 before, and I've noticed a small delay in the machine while running the test after updating to the -proposed version, probably due to the lock mechanism added.
I was able to verify/test in both Bionic and Cosmic proposed kernels, respectively: 4.15.0-44.47 and 4.18.0-14.15.
I don't have a reproducer, but to exercise the paths modified by the patches, the following approach was taken:
(a) Open ssh connection to the host/test machine, and run the following there:
DIR="/sys/ kernel/ debug/tracing" ftrace_ filter
echo tty_reopen > $DIR/set_
echo function > $DIR/current_tracer
echo 'p:tty_name n_tty_receive_buf2 tty=+0x170( %di):string' > $DIR/kprobe_events kprobes/ tty_name/ enable
echo 1 > $DIR/events/
echo > trace
Then, start running the following loop:
$ while true; do pkill -9 -t pts/1; sleep 1; done
In this point, we don't have a pts/1 there, but keep it running.
(b) In another terminal from the ssh client, run:
$ while true; do ssh <host/test machine ip>; done
Notice it's interesting to have the following in the .ssh/config of the ssh client machine:
ControlMaster auto
ControlPersist 600
Host <test/host machine alias>
ControlPath ~/.ssh/%r@%h-%p
in order to keep only one ssh connection opened.
(c) While the SSH in pts/1 is opened and killed automatically (and reopened by the loop), user must keep typing things in the keyboard in that terminal to force the tty flush.
(d) After running that for some seconds, one can verify in the trace output that the functions modified by the main patch in the SRUed series are there:
$ grep "pts1\|reopen" $DIR/trace|cut -f2- -d]|cut -f2- -d:|sort |uniq -c receive_ buf2+0x0/ 0x20) tty="pts1"
66 tty_name: (n_tty_
60 tty_reopen <-tty_open
Also, the pattern showed in the trace file shows that the functions are called intermixed: receive_ buf2+0x0/ 0x20) tty="pts1" receive_ buf2+0x0/ 0x20) tty="pts1" receive_ buf2+0x0/ 0x20) tty="pts1" receive_ buf2+0x0/ 0x20) tty="pts1"
[...]
kworker/u56:1-3602 [000] .... 881.779225: tty_name: (n_tty_
kworker/u56:1-3602 [000] .... 881.861901: tty_name: (n_tty_
sshd-3403 [023] .... 882.249355: tty_reopen <-tty_open
bash-4052 [008] .... 882.250432: tty_reopen <-tty_open
bash-4052 [008] .... 882.250441: tty_reopen <-tty_open
bash-4052 [008] .... 882.251935: tty_reopen <-tty_open
kworker/u56:1-3602 [000] .... 882.440866: tty_name: (n_tty_
kworker/u56:1-3602 [000] .... 882.482994: tty_name: (n_tty_
[...]
Worth to notice that I've ran the test in 4.18.0-13 before, and I've noticed a small delay in the machine while running the test after updating to the -proposed version, probably due to the lock mechanism added.