linux/Documentation/networking, branch v3.9.1

ipvs: add backup_only flag to avoid loops

2013-03-19T12:21:51Z

Dmitry Akindinov is reporting for a problem where SYNs are looping between the master and backup server when the backup server is used as real server in DR mode and has IPVS rules to function as director. Even when the backup function is enabled we continue to forward traffic and schedule new connections when the current master is using the backup server as real server. While this is not a problem for NAT, for DR and TUN method the backup server can not determine if a request comes from client or from director. To avoid such loops add new sysctl flag backup_only. It can be needed for DR/TUN setups that do not need backup and director function at the same time. When the backup function is enabled we stop any forwarding and pass the traffic to the local stack (real server mode). The flag disables the director function when the backup function is enabled. For setups that enable backup function for some virtual services and director function for other virtual services there should be another more complex solution to support DR/TUN mode, may be to assign per-virtual service syncid value, so that we can differentiate the requests. Reported-by: Dmitry Akindinov Tested-by: German Myzovsky Signed-off-by: Julian Anastasov Signed-off-by: Simon Horman

net: docs: document multiqueue tuntap API

2013-03-06T19:56:10Z

Signed-off-by: Jason Wang Signed-off-by: David S. Miller

tcp: remove Appropriate Byte Count support

2013-02-05T19:51:16Z

TCP Appropriate Byte Count was added by me, but later disabled. There is no point in maintaining it since it is a potential source of bugs and Linux already implements other better window protection heuristics. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller

qlcnic: Updating copyright information.

2013-02-05T02:08:48Z

We recently refactored the driver source, this patch will take care of updating copyright date and adding it to newly added files. Signed-off-by: Jitendra Kalsaria Signed-off-by: David S. Miller

Merge branch 'master' of git://1984.lsi.us.es/nf-next

2013-01-27T05:56:10Z

Pablo Neira Ayuso says: ==================== This batch contains netfilter updates for you net-next tree, they are: * The new connlabel extension for x_tables, that allows us to attach labels to each conntrack flow. The kernel implementation uses a bitmask and there's a file in user-space that maps the bits with the corresponding string for each existing label. By now, you can attach up to 128 overlapping labels. From Florian Westphal. * A new round of improvements for the netns support for conntrack. Gao feng has moved many of the initialization code of each module of the netns init path. He also made several code refactoring, that code looks cleaner to me now. * Added documentation for all possible tweaks for nf_conntrack via sysctl, from Jiri Pirko. * Cisco 7941/7945 IP phone support for our SIP conntrack helper, from Kevin Cernekee. * Missing header file in the snmp helper, from Stephen Hemminger. * Finally, a couple of fixes to resolve minor issues with these changes, from myself. ==================== Signed-off-by: David S. Miller

Merge branch 'legacy-isa-delete' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux

2013-01-22T19:47:13Z

Paul Gortmaker says: ==================== The Ethernet-HowTo was maintained for roughly 10 years, from 1993 to 2003. Fortunately sane hardware probing and auto detection (via PCI and ISA/PnP) largely made the document a relic of the past, hence it being abandoned a decade ago. However, there is one last useful thing that we can extract from the effort made in maintaining that document. We can use it to guide us with respect to what rare, experimental and/or super ancient 10Mbit ISA drivers don't make sense to maintain in-tree anymore. Nobody will argue that ISA is obsolete. Availability went away at about the time Pentium3 motherboards moved from 500MHz Slot1/SECC processors to the green 500MHz Socket 370 Pentium3 chips, at the turn of the century. In theory, it is possible that someone could still be running one of these 12+ year old P3 machines and want 3.9+ bleeding edge kernels (but unlikely). In light of the above (remote) possibility, we can defer the removal of some ISA network drivers that were highly popular and well tested. Typically that means the stuff more from the mid to late '90s, some with ISA PnP support, like the 3c509, the wd/SMC 8390 based stuff, PCnet/lance etc. But a lot of other drivers, typically from the early 1990s were for rare hardware, and experimental (to the point of requiring a cron job that would do a test ping, and then ifconfig down/up and/or a rmmod/insmod!). And some of these drivers (znet, and lp486e to name two) are physically tied to platforms with on motherboard ethernet -- of 486 machines that date from the early 1990s and can only have single digit amounts of memory. What I'd like to achieve here with this series, is to get rid of those old drivers that are no longer being used. In an earlier discussion where I'd proposed deleting a single driver, Alan suggested we instead dump all the historical stuff in one go, to make it "...immediately obvious where the break point is..."[1] and that it was "perfectly reasonable it (and a pile of other ISA cards) ought to be shown the door"[2]. So that is the goal here - make a clear line in the sand where the really ancient stuff finally gets kicked to the curb. Two old parallel port drivers are considered for removal here as well, since in early 386/486 ISA machines, the parallel port was typically found with the UARTS on the multi-I/O ISA controller card. These drivers also date from the early 1990's; parallel ports are no longer found on modern boards, and their performance was not even capable of 10% of 10Mbit bandwidth. Allow me a preemptive justification against the inevitable comments from well meaning bystanders who suggest "why not just leave all this alone?". Dead drivers cost us all if they are left in tree. If you think that is false, then please first consider: -every time you type "git status", you are checking to see if modifications have been made by you to all that dead code. -every time you type "git grep " you are searching through files which contain that dead code that simply does not interest you. -every time you build a "allyesconfig" and an "allmodconfig" (don't tell me you skip this step before submitting your changes to a maintainer), you waste CPU cycles building this dead code. -every time there is a tree wide API change, or cleanup, or file relocation, we pay the cost of updating dead code, or moving dead code. -daily regression tests (take linux-next as the most transparent example) spend time building (and possibly running) this dead code. -hard working people who regularly run auditing tools looking for lurking bugs (sparse/coverity/smatch/coccinelle) are wasting time checking for, and fixing bugs in this dead code. This last one is key. Please take a look at the git history for the files that are proposed for removal here. Look at the git history for any one of them ("git whatchanged --follow drivers/net/.../driver.c") Mentally sort the changes into two bins -- (1) the robotic tree-wide changes, and (2) the "look I found a real run-time bug while using this" category. You will see that category #2 is essentially empty. Further to that, realize that drivers don't simply disappear. We are not operating in the binary-only distribution space like other OS. All these drivers remain in the git history forever. If a person is an enthusiast for extreme legacy hardware, they are probably already customizing their kernel source and building it themselves to support such systems. Also keep in mind that they could still build the 3.8 kernel exactly as-is, and run it (or a 3.8.x stable variant of it) for several more years if they were really determined to cling to these old experimental ISA drivers for some reason. In summary, I hope that folks can be pragmatic about this, and not get swept up in nostalgia. Ask yourself whether it is realistic to expect a person would have a genuine use case where they would need to build a 3.9+ modern kernel and install it on some legacy hardware that has no option but to absolutely _require_ one of the drivers that are deleted here. The following series was created with --irreversible-delete for ease of review (it skips showing the content of files that are deleted); however the complete patches can be pulled as per below. ==================== Signed-off-by: David S. Miller

neigh: Keep neighbour cache entries if number of them is small enough.

2013-01-22T19:25:28Z

Since we have removed NCE (Neighbour Cache Entry) reference from routing entries, the only refcnt holders of an NCE are its timer (if running) and its owner table, in usual cases. As a result, neigh_periodic_work() purges NCEs over and over again even for gateways. It does not make sense to purge entries, if number of them is very small, so keep them. The minimum number of entries to keep is specified by gc_thresh1. Signed-off-by: YOSHIFUJI Hideaki Signed-off-by: David S. Miller

drivers/net: delete Digital EtherWorks-3 support.

2013-01-22T15:39:55Z

This is another one that makes sense to target for obsolescence, since it (a)appeared pre-1995, and (b)was rather rare, and (c)did not really have any statistically significant active linux user base. Removing this ISA 10Mbit driver support is unlikely to be even noticed by the user base of 3.9+ linux kernels, especially when the documentation clearly indicates the vintage with this text: "...designed to work with all kernels > 1.1.33" Signed-off-by: Paul Gortmaker

drivers/net: delete old DEC depca ISA drivers support.

2013-01-22T15:39:55Z

These are old ISA 10Mbit cards from the 1st 1/2 of the 1990s and required manual jumper settings in order to configure them. Here we remove them on the premise that they are no longer used in any modern 3.9+ kernels. Signed-off-by: Paul Gortmaker

drivers/net: delete old parallel port de600/de620 drivers

2013-01-22T15:39:49Z

The parallel port is largely replaced by USB, and even in the day where these drivers were current, the documented speed was less than 100kB/s. Let us not pretend that anyone cares about these drivers anymore, or worse - pretend that anyone is using them on a modern kernel. As a side bonus, this is the end of legacy parallel port ethernet, so we get to drop the whole chunk relating to that in the legacy Space.c file containing the non-PCI unified probe dispatch. Signed-off-by: Paul Gortmaker