On Wed, Jun 27, 2018 at 12:33 PM Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > > > > On 06/27/2018 11:59 AM, Cong Wang wrote: > > > > > IIRC, this skb_orphan() was introduced much earlier than TSQ, probably > > from the beginning of veth. > > Sigh > > SO_SNDBUF was invented years ago before veth. Yeah, probably when there was only one stack on one host. SO_SNDBUF is aligned to networking stack basis. > > You focus on TSQ while it is only one of the many things that are broken. > I think it is the opposite: this patchset _potentially_ breaks things, not fixes anything. > > > > Leaving the stack should be effectively equivalent to leaving the host, > > from the view of network isolation. > > > > > Having a UDP socket being able to burn a cpu and fill a qdisc is a major bug. > Very true, network isolation never isolates CPU or memory. It is cpuset's job to provide physical CPU isolation, not networking namespace. I don't want to defend this, but it is the current design. > Bu default (blocking send() syscalls) the following loop should > block the thread if socket sk_wmem_alloc hits sk_sndbuf, this is > the beauty of backpressure. > > while (1) > send(fd, ...); > > With skb_orphan(), sk_wmem_alloc will stay around 0, so the loop will burn a cpu > and fill a qdisc, eventually breaking "network isolation", since other sockets > might be unable to send a single packet. Won't the same happen when congestion on a physical connection between two hosts? Does 'host isolation' break too? > > If you have a concrete case where the skb_orphan() is needed, then you will have > to add a parameter to let the admin opt-in for this. Please see the other reply from me, where I list 3 or 4 reasons. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
