- May 21, 2009
-
-
Eric W. Biederman authored
Stephen Rothwell <sfr@canb.auug.org.au> writes: > Today's linux-next build of at least some av32 and arm configs failed like this: > > arch/avr32/kernel/signal.c:216: error: conflicting types for 'restart_syscall' > include/linux/sched.h:2184: error: previous definition of 'restart_syscall' was here > > Caused by commit 690cc3ff ("syscall: > Implement a convinience function restart_syscall") from the net tree. Grrr. Some days it feels like all of the good names are already taken. Let's just rename the two static users in arm and avr32 to get this sorted out. Signed-off-by:
Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- May 20, 2009
-
-
Ben Hutchings authored
GRO/LRO can be controlled through ethtool so this is unnecessary. Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sascha Hlusiak authored
be sent periodically. The rs_delay can be speficied when adding the PRL entry and defaults to 15 minutes. The RS is sent from every link local adress that's assigned to the tunnel interface. It's directed to the (guessed) linklocal address of the router and is sent through the tunnel. Better: send to ff02::2 encapsuled in unicast directed to router-v4. Signed-off-by:
Sascha Hlusiak <contact@saschahlusiak.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sascha Hlusiak authored
A tunnel with no local ipv4 endpoint would otherwise use the ISATAP linklocal address fe80::5efe:0:0, which is invalid. Rather not add a linklocal address at all. Signed-off-by:
Sascha Hlusiak <contact@saschahlusiak.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sascha Hlusiak authored
Typo. When deleting a PRL entry, return status to userspace instead of success. Signed-off-by:
Sascha Hlusiak <contact@saschahlusiak.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sascha Hlusiak authored
Check link device when looking up a tunnel. When a tunnel is linked to a interface, traffic from a different interface must not reach the tunnel. This also allows creating of multiple tunnels with the same endpoints, if the link device differs. Signed-off-by:
Sascha Hlusiak <contact@saschahlusiak.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sascha Hlusiak authored
When locating the tunnel, do not continue if it is found. Otherwise a different tunnel with similar configuration would be returned and parts could be overwritten. Signed-off-by:
Sascha Hlusiak <contact@saschahlusiak.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Chris Friesen authored
The DHCP spec allows the server to specify the MTU. This can be useful for netbooting with UDP-based NFS-root on a network using jumbo frames. This patch allows the kernel IP autoconfiguration to handle this option correctly. It would be possible to use initramfs and add a script to set the MTU, but that seems like a complicated solution if no initramfs is otherwise necessary, and would bloat the kernel image more than this code would. This patch was originally submitted to LKML in 2003 by Hans-Peter Jansen. Signed-off-by:
Chris Friesen <cfriesen@nortel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Pablo Neira Ayuso authored
nlmsg_new() adds the size of the netlink header to the value that has been passed as parameter. If NLMSG_GOODSIZE is selected, we request an allocation of one memory page plus the size of the header. Instead, NLMSG_DEFAULT_SIZE should be used since it already substracts the size of the Netlink header. I have the impression that the similar naming in both constant is error prone when using it with nlmsg_new(). This is already documented in include/net/netlink.h Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Brice Goglin authored
Update myri10ge driver version to 1.5.0-1.415. Signed-off-by:
Brice Goglin <brice@myri.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Brice Goglin authored
Allow myri10ge LRO to be enabled/disabled via ethtool (and by the stack for packet forwarding). Signed-off-by:
Brice Goglin <brice@myri.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
We can slightly reduce size of teqlN structure, not duplicating stats structure in teql_master but using stats field from net_device.stats for tx_errors and from netdev_queue for tx_bytes/tx_packets/tx_dropped values. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jesse Brandeburg authored
This is purely a cleanup patch. This collapses some of the code required when we configure our Tx and Rx feature sets, and makes the code more readable and maintainable. Signed-off-by:
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Peter P Waskiewicz Jr authored
The SFF specification for Direct Attach cable detection has now been ratified. Previously, DA cable detect was looking at the Twinaxial bit in byte 9 of the SFP+ EEPROM. The spec now defines active and passive DA cables in byte 8 of the SFP+ EEPROM. This patch changes the cable detection for both 82598 and 82599 SFP+ adapters to conform to the new spec. Signed-off-by:
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Peter P Waskiewicz Jr authored
The SFP+ NIC (device id 0x10fb) needs a semaphore to serialize PHY access, so our PHY init code must honor that same semaphore. Signed-off-by:
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
françois romieu authored
Due to mostly historic reasons, including a lack of reliability of the link handling (especially with the older 8169), the current r8169 driver emulates forced mode setting by limiting the advertised modes. With this change the driver allows real 10/100 forced mode settings on the 8169 and 8101/8102. Original idea by Vincent Steenhoute. The RTL_GIGA_MAC_VER_03 tweak was extracted from Realtek's r8169 v6.010.00 driver. Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Tested-by:
Jean Delvare <jdelvare@suse.de> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
françois romieu authored
Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Cc: Edward Hsu <edward_hsu@realtek.com.tw> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Jarek pointed pppoe can call back dev_queue_xmit(), and might need skb->dst, so its safer to unset IFF_XMIT_DST_RELEASE on ppp devices. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- May 19, 2009
-
-
Eric Dumazet authored
One point of contention in high network loads is the dst_release() performed when a transmited skb is freed. This is because NIC tx completion calls dev_kree_skb() long after original call to dev_queue_xmit(skb). CPU cache is cold and the atomic op in dst_release() stalls. On SMP, this is quite visible if one CPU is 100% handling softirqs for a network device, since dst_clone() is done by other cpus, involving cache line ping pongs. It seems right place to release dst is in dev_hard_start_xmit(), for most devices but ones that are virtual, and some exceptions. David Miller suggested to define a new device flag, set in alloc_netdev_mq() (so that most devices set it at init time), and carefuly unset in devices which dont want a NULL skb->dst in their ndo_start_xmit(). List of devices that must clear this flag is : - loopback device, because it calls netif_rx() and quoting Patrick : "ip_route_input() doesn't accept loopback addresses, so loopback packets already need to have a dst_entry attached." - appletalk/ipddp.c : needs skb->dst in its xmit function - And all devices that call again dev_queue_xmit() from their xmit function (as some classifiers need skb->dst) : bonding, vlan, macvlan, eql, ifb, hdlc_fr Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric W. Biederman authored
Sysfs files for a network device can not unconditionally take the rtnl_lock as the bonding sysfs files do. If someone accesses those sysfs files while the network device is being unregistered with the rtnl_lock held we will deadlock. So use trylock and restart_syscall to avoid this problem. Signed-off-by:
Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric W. Biederman authored
Network device sysfs files that grab the rtnl_lock unconditionally will deadlock if accessed when the network device is being unregistered. So use trylock and syscall_restart to avoid this deadlock. Signed-off-by:
Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric W. Biederman authored
Holding rtnl_lock when we are unregistering the sysfs files can deadlock if we unconditionally take rtnl_lock in a sysfs file. So fix it with the now familiar patter of: rtnl_trylock and syscall_restart() Signed-off-by:
Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric W. Biederman authored
sysctls are unregistered with the rntl_lock held making it unsafe to unconditionally grab the the rtnl_lock. Instead we need to call rtnl_trylock and restart the system call if we can not grab it. Otherwise we could deadlock at unregistration time. Signed-off-by:
Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric W. Biederman authored
Just returning -ERESTARTSYS without a signal pending is not good that will just leak it to userspace. We need return -ERESTARTNOINTR so we always restart and set signal pending so that we fall of the fast path of syscall return and setup the system call restart. So use restart_syscall() which does all of this for us. Signed-off-by:
Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric W. Biederman authored
The earlier patch to fix the deadlock between a network device going away and writing to sysfs attributes was incomplete. - It did not set signal_pending so we would leak ERSTARTSYS to user space. - It used ERESTARTSYS which only restarts if sigaction configures it to. - It did not cover store and show for ifalias. So fix all of these up and use the new helper restart_syscall so we get the details correct on what it takes. Signed-off-by:
Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric W. Biederman authored
Currently when we have a signal pending we have the functionality to restart that the current system call. There are other cases such as nasty lock ordering issues where it makes sense to have a simple fix that uses try lock and restarts the system call. Buying time to figure out how to rework the locking strategy. Signed-off-by:
Eric W. Biederman <ebiederm@aristanetworks.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Johann Baudy authored
New packet socket feature that makes packet socket more efficient for transmission. - It reduces number of system call through a PACKET_TX_RING mechanism, based on PACKET_RX_RING (Circular buffer allocated in kernel space which is mmapped from user space). - It minimizes CPU copy using fragmented SKB (almost zero copy). Signed-off-by:
Johann Baudy <johann.baudy@gnu-log.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Dhananjay Phadke authored
The pdev->irq was not saved in netxen_adapter, causing request_irq() with invalid irq number. This was broken in commit be339aee ("netxen: fix irq tear down and msix leak."). Signed-off-by:
Dhananjay Phadke <dhananjay@netxen.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Conflicts: drivers/scsi/fcoe/fcoe.c
-
Eric Dumazet authored
gen_estimator can overflow bps (bytes per second) with Gb links, while it was designed with a u32 API, with a theorical limit of 34360Mbit (2^32 bytes) Using 64 bit intermediate avbps/brate counters can allow us to reach this theorical limit. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
Jarek Poplawski <jarkao2@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wolfgang Grandegger authored
The patch adds support for the PCI cards: PCIcan and PCIcanx (1, 2 or 4 channel) from Kvaser (http://www.kvaser.com ). Signed-off-by:
Per Dalen <per.dalen@cnw.se> Signed-off-by:
Wolfgang Grandegger <wg@grandegger.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wolfgang Grandegger authored
The patch adds support for the one or two channel CPC-PCI and CPC-PCIe cards from EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de ). Signed-off-by:
Sebastian Haas <haas@ems-wuensche.com> Signed-off-by:
Markus Plessing <plessing@ems-wuensche.com> Signed-off-by:
Wolfgang Grandegger <wg@grandegger.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wolfgang Grandegger authored
This driver adds support for the SJA1000 chips connected to the "platform bus", which can be found on various embedded systems. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Wolfgang Grandegger <wg@grandegger.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wolfgang Grandegger authored
This patch adds the generic Socket-CAN driver for the Philips SJA1000 full CAN controller. Signed-off-by:
Wolfgang Grandegger <wg@grandegger.com> Signed-off-by:
Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wolfgang Grandegger authored
The CAN network device driver interface provides a generic interface to setup, configure and monitor CAN network devices. It exports a set of common data structures and functions, which all real CAN network device drivers should use. Please have a look to the SJA1000 or MSCAN driver to understand how to use them. The name of the module is can-dev.ko. Furthermore, it adds a Netlink interface allowing to configure the CAN device using the program "ip" from the iproute2 utility suite. For further information please check "Documentation/networking/can.txt" Signed-off-by:
Wolfgang Grandegger <wg@grandegger.com> Signed-off-by:
Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wolfgang Grandegger authored
Signed-off-by:
Wolfgang Grandegger <wg@grandegger.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Wolfgang Grandegger authored
This patch documents the CAN netowrk device drivers interface, removes obsolete documentation and adds some useful links to CAN resources. Signed-off-by:
Wolfgang Grandegger <wg@grandegger.com> Signed-off-by:
Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Ajit Khaparde authored
Signed-off-by:
Ajit Khaparde <ajitk@serverengines.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Anant Gole authored
Add support for TI DaVinci EMAC driver. TI DaVinci Ethernet Media Access Controller module is based upon TI CPPI 3.0 DMA engine and supports 10/100 Mbps on all and Gigabit modes on some TI devices. It supports MII/RMII and has up to 8Kbytes of internal descriptor memory. This driver has been working on several TI devices including DM644x, DM646x and DA830 platforms. The specs of this device are available at: http://www.ti.com/litv/pdf/sprue24a Signed-off-by:
Anant Gole <anantgole@ti.com> Signed-off-by:
Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by:
Chaithrika U S <chaithrika@ti.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Rami Rosen authored
There is no need for net/icmp.h header in net/ipv4/fib_frontend.c. This patch removes the #include net/icmp.h from it. Signed-off-by:
Rami Rosen <ramirose@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-