| Message ID | 1267598111-12503-8-git-send-email-yi.zhu@intel.com |
|---|---|
| State | Superseded, archived |
| Delegated to: | David Miller |
| Headers | show |
Le mercredi 03 mars 2010 à 14:35 +0800, Zhu Yi a écrit : > Make x25 adapt to the limited socket backlog change. > > Cc: Andrew Hendry <andrew.hendry@gmail.com> > Signed-off-by: Zhu Yi <yi.zhu@intel.com> > --- > net/x25/x25_dev.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/net/x25/x25_dev.c b/net/x25/x25_dev.c > index 3e1efe5..5688123 100644 > --- a/net/x25/x25_dev.c > +++ b/net/x25/x25_dev.c > @@ -53,7 +53,7 @@ static int x25_receive_data(struct sk_buff *skb, struct x25_neigh *nb) > if (!sock_owned_by_user(sk)) { > queued = x25_process_rx_frame(sk, skb); > } else { > - sk_add_backlog(sk, skb); > + __sk_add_backlog(sk, skb); > } > bh_unlock_sock(sk); > sock_put(sk); Please respin your patch the other way Ie: let sk_add_backlog(sk, skb) do its previous job (not leaking skbs, and returning a void status) Add a new function able to no limit backlog, and returns an error code, so that caller can free skb and increment SNMP counters accordingly. Callers MUST test return value, or use another helper that can free the skb for them. Name it sk_move_backlog() for example This will permit you to split the work as you tried. sk_add_backlog() could be redefined as the helper : void sk_add_backlog(sk, skb) { if (sk_move_backlog(sk, skb)) { kfree_skb(skb); atomic_inc(&sk->sk_drops); } } Thanks -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Will wait for the next spin and in the meantime think if there is way to test it. x25 with no loopback and being so slow probably cant generate the same as your UDP case. Andrew. On Wed, Mar 3, 2010 at 6:08 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > Le mercredi 03 mars 2010 à 14:35 +0800, Zhu Yi a écrit : >> Make x25 adapt to the limited socket backlog change. >> >> Cc: Andrew Hendry <andrew.hendry@gmail.com> >> Signed-off-by: Zhu Yi <yi.zhu@intel.com> >> --- >> net/x25/x25_dev.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/net/x25/x25_dev.c b/net/x25/x25_dev.c >> index 3e1efe5..5688123 100644 >> --- a/net/x25/x25_dev.c >> +++ b/net/x25/x25_dev.c >> @@ -53,7 +53,7 @@ static int x25_receive_data(struct sk_buff *skb, struct x25_neigh *nb) >> if (!sock_owned_by_user(sk)) { >> queued = x25_process_rx_frame(sk, skb); >> } else { >> - sk_add_backlog(sk, skb); >> + __sk_add_backlog(sk, skb); >> } >> bh_unlock_sock(sk); >> sock_put(sk); > > Please respin your patch the other way > > Ie: let sk_add_backlog(sk, skb) do its previous job (not leaking skbs, > and returning a void status) > > Add a new function able to no limit backlog, and returns an error code, > so that caller can free skb and increment SNMP counters accordingly. > > Callers MUST test return value, or use another helper that can free the > skb for them. > > Name it sk_move_backlog() for example > > This will permit you to split the work as you tried. > > sk_add_backlog() could be redefined as the helper : > > void sk_add_backlog(sk, skb) > { > if (sk_move_backlog(sk, skb)) { > kfree_skb(skb); > atomic_inc(&sk->sk_drops); > } > > } > > Thanks > > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
andrew hendry <andrew.hendry@gmail.com> wrote: > Will wait for the next spin and in the meantime think if there is way > to test it. x25 with no loopback and being so slow probably cant generate the same > as your UDP case. I didn't find a way to drop the packet correctly. So I didn't change any behavior in this patch. Nor did I do in the second spin. It will be fine if you also think x25 doesn't need to limit its backlog size. Thanks, -yi -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Le mercredi 03 mars 2010 à 22:00 +0800, Zhu, Yi a écrit : > andrew hendry <andrew.hendry@gmail.com> wrote: > > > Will wait for the next spin and in the meantime think if there is way > > to test it. x25 with no loopback and being so slow probably cant generate the same > > as your UDP case. > > I didn't find a way to drop the packet correctly. So I didn't change any behavior in > this patch. Nor did I do in the second spin. It will be fine if you also think x25 doesn't > need to limit its backlog size. So are we sure we cant flood X25 backlog, using X25 over IP ? You discovered a _fatal_ flaw in backlog processing, we should close all holes, not only UDP case. You can be sure many bad guys will inspect all possibilities to bring down Linux hosts. If you feel uncomfortable with a small limit, just stick a big one, like 256 packets, and you are 100% sure you wont break a protocol. If this limit happens to be too small, we can change it later. (No need to count bytes, since truesize includes kernel overhead, and this overhead depends on 32/64 wide of host and kernel versions) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Thinking like someone trying to break it, it may be possible for X25 to flood backlog. With specific environments, enough circuits XoT/XoE may be able to. Also tun + TUNSETLINK and some userspace code it might be possible. A limit should be set just in case, and to cover X25 normal use it doesn't need to be very big. 256 seems reasonable to start. I'll look at setting up a fast virtual x.25 environment to test its backlog behavior. I think resolve issue for common protocols first, I don't know if X25=m would be used widely. Andrew. On Thu, Mar 4, 2010 at 1:33 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote: > Le mercredi 03 mars 2010 à 22:00 +0800, Zhu, Yi a écrit : >> andrew hendry <andrew.hendry@gmail.com> wrote: >> >> > Will wait for the next spin and in the meantime think if there is way >> > to test it. x25 with no loopback and being so slow probably cant generate the same >> > as your UDP case. >> >> I didn't find a way to drop the packet correctly. So I didn't change any behavior in >> this patch. Nor did I do in the second spin. It will be fine if you also think x25 doesn't >> need to limit its backlog size. > > So are we sure we cant flood X25 backlog, using X25 over IP ? > > You discovered a _fatal_ flaw in backlog processing, we should close all > holes, not only UDP case. You can be sure many bad guys will inspect all > possibilities to bring down Linux hosts. > > If you feel uncomfortable with a small limit, just stick a big one, like > 256 packets, and you are 100% sure you wont break a protocol. If this > limit happens to be too small, we can change it later. > > (No need to count bytes, since truesize includes kernel overhead, and > this overhead depends on 32/64 wide of host and kernel versions) > > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/x25/x25_dev.c b/net/x25/x25_dev.c index 3e1efe5..5688123 100644 --- a/net/x25/x25_dev.c +++ b/net/x25/x25_dev.c @@ -53,7 +53,7 @@ static int x25_receive_data(struct sk_buff *skb, struct x25_neigh *nb) if (!sock_owned_by_user(sk)) { queued = x25_process_rx_frame(sk, skb); } else { - sk_add_backlog(sk, skb); + __sk_add_backlog(sk, skb); } bh_unlock_sock(sk); sock_put(sk);
Make x25 adapt to the limited socket backlog change. Cc: Andrew Hendry <andrew.hendry@gmail.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> --- net/x25/x25_dev.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)