Re: so_rerror

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 4 Nov 2018 01:40:10 +0000
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <058dd223-f0f1-4294-cea5-0b99913d462e%marples.name@localhost>

  | AFAIK TCP doesn't call so_roverflow and the reporter mentions using UDP 
  | as a workaround so I doubt this is the case.

I haven't looked into it, and it could be as hinted, a driver bug, but the
ENOBUFS error (recently occurring) is kind of a red flag.

I know a normal TCP would not (should not) be affected by this, but the
in-kernel NFS has access (whether it should or not) to data not normally
exposed to TCP clients.

The UDP workaround was reported as still seeing the errors, they were
just not causing a hang ... which is not unexpected, udp packets are
lost all the time, and the code needs to be able to retry and cope.
TCP on the other hand normallys ees no errrors, other than connection
lost, and it is not beyond all possibility that if NFS detects an error,
and TCP has no way to "fix" it, than things could hang.

mrg - can you apply Christos patch, and see if it helps your tcp NFS
mounts (and perhaps makes the error reports in the UDP case go away) ?

kre