aboutgitcodebugslistschat
path: root/pasta.c
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2023-06-04 06:51:47 +0200
committerStefano Brivio <sbrivio@redhat.com>2023-06-23 10:15:10 +0200
commitd072ac243407df464d0e0c74268631e39c5f1251 (patch)
tree3e842b2c267bf3279f3d3c242aad0e701fd47a20 /pasta.c
parent429e1a7e71ad9020f0e53bc467986c55bf5c0e38 (diff)
downloadpasst-d072ac243407df464d0e0c74268631e39c5f1251.tar
passt-d072ac243407df464d0e0c74268631e39c5f1251.tar.gz
passt-d072ac243407df464d0e0c74268631e39c5f1251.tar.bz2
passt-d072ac243407df464d0e0c74268631e39c5f1251.tar.lz
passt-d072ac243407df464d0e0c74268631e39c5f1251.tar.xz
passt-d072ac243407df464d0e0c74268631e39c5f1251.tar.zst
passt-d072ac243407df464d0e0c74268631e39c5f1251.zip
tap: With pasta, don't reset on tap errors, handle write failures
Since commit 0515adceaa8f ("passt, pasta: Namespace-based sandboxing, defer seccomp policy application"), it makes no sense to close and reopen the tap device on error: we don't have access to /dev/net/tun after the initial setup phase. If we hit ENOBUFS while writing (as reported: in one case because the kernel actually ran out of memory, with another case under investigation), or ENOSPC, we're supposed to drop whatever data we were trying to send: there's no room for it. Handle EINTR just like we handled EAGAIN/EWOULDBLOCK: there's no particular reason why sending the same data should fail again. Anything else I can think of would be an unrecoverable error: exit with failure then. While at it, drop a useless cast on the write() call: it takes a const void * anyway. Reported-by: Gianluca Stivan <me@yawnt.com> Reported-by: Chris Kuhn <kuhnchris@kuhnchris.eu> Fixes: 0515adceaa8f ("passt, pasta: Namespace-based sandboxing, defer seccomp policy application") Signed-off-by: Stefano Brivio <sbrivio@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'pasta.c')
0 files changed, 0 insertions, 0 deletions