[newnfs/client] SIGINFO aborts transfer and produces `permission denied'

[Rick Macklem]

On Fri, 17 Jul 2009, Anonymous wrote:

> Let's populate /blah with 50Mb files and send SIGINFO to cp(1) process while
> copying it over nfsv3.
>
> # uname -vm
> FreeBSD 8.0-BETA1 #0: Sat Jul 4 03:55:14 UTC 2009
> root at almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
>
> # mkdir /blah
> # truncate -s50m /blah/foo_1
> # truncate -s50m /blah/foo_2
> # truncate -s50m /blah/foo_3
>
> # echo /usr >/etc/exports
> # /etc/rc.d/nfsd onestart
> # mount -t newnfs -o nfsv3 0:/blah /mnt
>
> # cp -R /mnt /aaa
> [type ^T several times]
> load: 0.81  cmd: cp 2305 [runnable] 1.86r 0.00u 0.62s 9% 1304k
> /mnt/foo_1 -> /aaa/foo_1  25%
> load: 0.90  cmd: cp 2305 [runnable] 2.43r 0.00u 0.80s 9% 1304k
> /mnt/foo_1 -> /aaa/foo_1  32%
> load: 0.90  cmd: cp 2305 [runnable] 2.59r 0.00u 0.85s 19% 1304k
> /mnt/foo_1 -> /aaa/foo_1  34%
> load: 0.90  cmd: cp 2305 [runnable] 2.76r 0.01u 0.89s 19% 1304k
> /mnt/foo_1 -> /aaa/foo_1  36%
> load: 0.90  cmd: cp 2305 [runnable] 2.96r 0.02u 0.94s 19% 1304k
> /mnt/foo_1 -> /aaa/foo_1  39%
> load: 0.90  cmd: cp 2305 [runnable] 3.14r 0.02u 1.00s 19% 1304k
> /mnt/foo_1 -> /aaa/foo_1  41%
> load: 0.90  cmd: cp 2305 [newnfsreq] 3.30r 0.02u 1.05s 19% 1304k
> load: 0.90  cmd: cp 2305 [runnable] 3.47r 0.02u 1.08s 19% 1304k
> load: 0.90  cmd: cp 2305 [runnable] 3.62r 0.02u 1.11s 19% 1304k
> load: 0.90  cmd: cp 2305 [runnable] 3.81r 0.02u 1.14s 19% 1304k
> load: 0.90  cmd: cp 2305 [runnable] 3.98r 0.02u 1.17s 19% 1304k
> load: 0.90  cmd: cp 2305 [runnable] 4.29r 0.02u 1.22s 19% 1304k
> load: 1.23  cmd: cp 2305 [runnable] 4.84r 0.02u 1.35s 19% 1304k
> load: 1.23  cmd: cp 2305 [runnable] 5.19r 0.02u 1.49s 19% 1304k
> load: 1.23  cmd: cp 2305 [runnable] 5.52r 0.02u 1.63s 19% 1304k
> load: 1.23  cmd: cp 2305 [runnable] 6.12r 0.02u 1.88s 19% 1304k
> load: 1.23  cmd: cp 2305 [runnable] 6.52r 0.02u 2.05s 19% 1304k
> load: 1.23  cmd: cp 2305 [runnable] 6.89r 0.02u 2.19s 19% 1304k
> load: 1.69  cmd: cp 2305 [runnable] 7.40r 0.02u 2.40s 29% 1304k
> load: 1.69  cmd: cp 2305 [runnable] 7.76r 0.02u 2.55s 29% 1304k
> load: 1.69  cmd: cp 2305 [runnable] 8.11r 0.02u 2.70s 29% 1304k
> cp: /mnt/foo_1: Permission denied
> cp: /mnt/foo_2: Permission denied
> cp: /mnt/foo_3: Permission denied
>
> This one should be slightly harder to reproduce. And depending on timing
> between each ^T keypress error message can differ, e.g. `Bad address' or
> `Input/output error'. Of course not all files end up in /aaa
>
>    # ls -l /aaa
>    total 32912
>    -rw-r--r--  1 root  wheel  33685504 Jul 16 20:26 foo_1
> (this file is from different attempt, not that was aborted around 41%)
>
> It affects both foreground and background processes. So, to abort copying
> one can also try running
>
>    # pkill -INFO cp
>
> several times. I haven't found any other signal that affect copying
> (tried SIGURG, SIGCONT, SIGCHLD, SIGIO, SIGWINCH).
>
> Known? Or am I the only one having a bad habit typing ^T too often?
>
Kostik recently checked in some changes related to signal handling,
but I haven't yet had time to clone that for the experimental client.

If the problem doesn't occur for the regular client, then I'll guess
that cloning his changes to the experimental client will fix it.

rick