- 18 Jun, 2008 3 commits
-
-
Wang Chen authored
The comments of dev_set_allmulti/promiscuity() is that "While the count in the device remains above zero...". So negative count is useless. Fix the type of the counter from "int" to "unsigned int". Signed-off-by: Wang Chen <wangchen@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
In commits 33c732c3 ([IPV4]: Add raw drops counter) and a92aa318 ([IPV6]: Add raw drops counter), Wang Chen added raw drops counter for /proc/net/raw & /proc/net/raw6 This patch adds this capability to UDP sockets too (/proc/net/udp & /proc/net/udp6). This means that 'RcvbufErrors' errors found in /proc/net/snmp can be also be examined for each udp socket. # grep Udp: /proc/net/snmp Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors Udp: 23971006 75 899420 16390693 146348 0 # cat /proc/net/udp sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt --- uid timeout inode ref pointer drops 75: 00000000:02CB 00000000:0000 07 00000000:00000000 00:00000000 00000000 --- 0 0 2358 2 ffff81082a538c80 0 111: 00000000:006F 00000000:0000 07 00000000:00000000 00:00000000 00000000 --- 0 0 2286 2 ffff81042dd35c80 146348 In this example, only port 111 (0x006F) was flooded by messages that user program could not read fast enough. 146348 messages were lost. Signed-off-by: Eric Dumazet <dada1@cosmosbay.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bernard Pidoux authored
ROSE network is organized through nodes connected via hamradio or Internet. AX25 packet radio frames sent to a remote ROSE address destination are routed through these nodes. Without the present patch, automatic routing mechanism did not work optimally due to an improper parameter checking. rose_get_neigh() function is called either by rose_connect() or by rose_route_frame(). In the case of a call from rose_connect(), f0 timer is checked to find if a connection is already pending. In that case it returns the address of the neighbour, or returns a NULL otherwise. When called by rose_route_frame() the purpose was to route a packet AX25 frame through an adjacent node given a destination rose address. However, in that case, t0 timer checked does not indicate if the adjacent node is actually connected even if the timer is not null. Thus, for each frame sent, the function often tried to start a new connexion even if the adjacent node was already connected. The patch adds a "new" parameter that is true when the function is called by rose route_frame(). This instructs rose_get_neigh() to check node parameter "restarted". If restarted is true it means that the route to the destination address is opened via a neighbour node already connected. If "restarted" is false the function returns a NULL. In that case the calling function will initiate a new connection as before. This results in a fast routing of frames, from nodes to nodes, until destination is reached, as originaly specified by ROSE protocole. Signed-off-by: Bernard Pidoux <f6bvp@amsat.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 17 Jun, 2008 37 commits
-
-
Chas Williams authored
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Chas Williams authored
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alan Cox authored
This fixes the most obvious 64-bit problems, but it is still very very broken in other aspects. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Mitchell Blank Jr authored
From: Mitchell Blank Jr <mitch@sfgoth.com> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Chas Williams authored
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jorge Boncompte [DTI2] authored
Signed-off-by: Jorge Boncompte [DTI2] <jorge@dti2.net> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Randy Dunlap authored
Fix bridge netfilter code so that it uses CONFIG_IPV6 as needed: net/built-in.o: In function `ebt_filter_ip6': ebt_ip6.c:(.text+0x87c37): undefined reference to `ipv6_skip_exthdr' net/built-in.o: In function `ebt_log_packet': ebt_log.c:(.text+0x88dee): undefined reference to `ipv6_skip_exthdr' make[1]: *** [.tmp_vmlinux1] Error 1 Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Normally, the bridge just chooses the smallest mac address as the bridge id and mac address of bridge device. But if the administrator has explictly set the interface address then don't change it. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Any frame addressed to link-local addresses should be processed by local receive path. The earlier code would process them only if STP was enabled. Since there are other frames like LACP for bonding, we should always process them. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
After the sctp_remaddr_proc_init failed, the proper rollback is not the sctp_remaddr_proc_exit, but the sctp_assocs_proc_exit. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
In nr_release(), one code path calls sock_orphan() which will NULL out sk->sk_socket already. In the other case, handling states other than NR_STATE_{0,1,2,3}, seems to not be possible other than due to bugs. Even for an uninitialized nr->state value, that would be zero or NR_STATE_0. It might be wise to stick a WARN_ON() here. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
It doesn't grab the sk_callback_lock, it doesn't NULL out the sk->sk_sleep waitqueue pointer, etc. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
It doesn't grab the sk_callback_lock, it doesn't NULL out the sk->sk_sleep waitqueue pointer, etc. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
This is the x25 variant of changeset 9375cb8a ("ax25: Use sock_graft() and remove bogus sk_socket and sk_sleep init.") Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
This is the rose variant of changeset 9375cb8a ("ax25: Use sock_graft() and remove bogus sk_socket and sk_sleep init.") Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
This is the netrom variant of changeset 9375cb8a ("ax25: Use sock_graft() and remove bogus sk_socket and sk_sleep init.") Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
The way that listening sockets work in ax25 is that the packet input code path creates new socks via ax25_make_new() and attaches them to the incoming SKB. This SKB gets queued up into the listening socket's receive queue. When accept()'d the sock gets hooked up to the real parent socket. Alternatively, if the listening socket is closed and released, any unborn socks stuff up in the receive queue get released. So during this time period these sockets are unreachable in any other way, so no wakeup events nor references to their ->sk_socket and ->sk_sleep members can occur. And even if they do, all such paths have to make NULL checks. So do not deceptively initialize them in ax25_make_new() to the values in the listening socket. Leave them at NULL. Finally, use sock_graft() in ax25_accept(). Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Just expand the wait sequence. And as a nice side-effect the timeout is respected now. Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Conflicts: drivers/net/wireless/rt2x00/Kconfig drivers/net/wireless/rt2x00/rt2x00usb.c net/sctp/protocol.c
-
Chas Williams authored
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Robert T. Johnson authored
From: "Robert T. Johnson" <rtjohnso@eecs.berkeley.edu> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
-
Eric Kinzie authored
From: Eric Kinzie <ekinzie@cmf.nrl.navy.mil> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Chas Williams authored
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jorge Boncompte [DTI2] authored
This causes the suni driver to oops if you try to use sonetdiag to get the statistics. Also add the corresponding phy->stop call to fix another oops if you try to remove the module. Signed-off-by: Jorge Boncompte [DTI2] <jorge@dti2.net> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jorge Boncompte [DTI2] authored
Signed-off-by: Jorge Boncompte [DTI2] <jorge@dti2.net> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jorge Boncompte [DTI2] authored
It happens that if a packet arrives in a VC between the call to open it on the hardware and the call to change the backend to br2684, br2684_regvcc processes the packet and oopses dereferencing skb->dev because it is NULL before the call to br2684_push(). Signed-off-by: Jorge Boncompte [DTI2] <jorge@dti2.net> Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
-
Pavel Emelyanov authored
There are many possible ways to add this "salt", thus I made this patch to be the last in the series to change it if required. Currently I propose to use the struct net pointer itself as this salt, but since this pointer is most often cache-line aligned, shift this right to eliminate the bits, that are most often zeroed. After this, simply add this mix to prepared hashfn-s. For CONFIG_NET_NS=n case this salt is 0 and no changes in hashfn appear. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
Same as for inet_hashfn, prepare its ipv6 incarnation. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
Although this hash takes addresses into account, the ehash chains can also be too long when, for instance, communications via lo occur. So, prepare the inet_hashfn to take struct net into account. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
Listening-on-one-port sockets in many namespaces produce long chains in the listening_hash-es, so prepare the inet_lhashfn to take struct net into account. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
Binding to some port in many namespaces may create too long chains in bhash-es, so prepare the hashfn to take struct net into account. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
Every caller already has this one. The new argument is currently unused, but this will be fixed shortly. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
They both calculate the hash chain, but currently do not have a struct net pointer, so pass one there via additional argument, all the more so their callers already have such. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pavel Emelyanov authored
Currently the chain to store a UDP socket is calculated with simple (x & (UDP_HTABLE_SIZE - 1)). But taking net into account would make this calculation a bit more complex, so moving it into a function would help. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-