* Re: [net-next v2 35/71] skge/sky2/mv643xx/pxa168: Move the Marvell Ethernet drivers
From: Jeff Kirsher @ 2011-08-01 2:35 UTC (permalink / raw)
To: Joe Perches
Cc: Stephen Hemminger, Sachin Sanap, davem@davemloft.net,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
Zhangfei Gao, Philip Rakity, Mark Brown, Lennert Buytenhek
In-Reply-To: <1312151237.11635.5.camel@Joe-Laptop>
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
On Sun, 2011-07-31 at 15:27 -0700, Joe Perches wrote:
> On Sun, 2011-07-31 at 15:11 -0700, Stephen Hemminger wrote:
> > On Sat, 30 Jul 2011 20:26:54 -0700
> > Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > > MARVELL MWIFIEX WIRELESS DRIVER
> > > @@ -5816,8 +5816,7 @@ SKGE, SKY2 10/100/1000 GIGABIT ETHERNET DRIVERS
> > > M: Stephen Hemminger <shemminger@linux-foundation.org>
> > > L: netdev@vger.kernel.org
> > > S: Maintained
> > > -F: drivers/net/skge.*
> > > -F: drivers/net/sky2.*
> > > +F: drivers/net/ethernet/marvell/sk*
> > The old SysKonnect fddi driver should probably be moved in there
> > as well. It is called skfp.c
>
> fddi isn't ethernet so I think skfp.c should not be moved there.
>
>
Joe is right, the skfp (fddi) driver would go in driver/net/fddi/, which
is the next set of follow on patches I am working on.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
From: Amit Salecha @ 2011-08-01 6:09 UTC (permalink / raw)
To: Jeff Kirsher, David Miller
Cc: netdev, gospo@redhat.com, sassmann@redhat.com, Nicolas Pitre,
Donald Becker, Erik Stahlman, Dustin McIntire, Steve Glendinning,
David Hinds
In-Reply-To: <1312082850-24914-10-git-send-email-jeffrey.t.kirsher@intel.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Jeff Kirsher
> Sent: Sunday, July 31, 2011 8:56 AM
> Subject: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
>
> Moves the SMC (SMSC) drivers into drivers/net/ethernet/smsc/ and the
> necessary Kconfig and Makefile changes. Also did some cleanup
> of NET_VENDOR_SMC Kconfig tag for the 8390 based drivers.
>
> CC: Nicolas Pitre <nico@fluxnic.net>
> CC: Donald Becker <becker@scyld.com>
> CC: Erik Stahlman <erik@vt.edu>
> CC: Dustin McIntire <dustin@sensoria.com>
> CC: Steve Glendinning <steve.glendinning@smsc.com>
> CC: David Hinds <dahinds@users.sourceforge.net>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> -config NETXEN_NIC
> - tristate "NetXen Multi port (1/10) Gigabit Ethernet NIC"
> - depends on PCI
> - select FW_LOADER
> - help
> - This enables the support for NetXen's Gigabit Ethernet card.
> -
>
> -obj-$(CONFIG_NETXEN_NIC) += netxen/
> obj-$(CONFIG_NIU) += niu.o
> obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
> obj-$(CONFIG_SFC) += sfc/
I didn't get reason for above netxen_nic changes.
-Amit
^ permalink raw reply
* RE: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
From: Jeff Kirsher @ 2011-08-01 6:16 UTC (permalink / raw)
To: Amit Salecha
Cc: David Miller, netdev, gospo@redhat.com, sassmann@redhat.com,
Nicolas Pitre, Donald Becker, Erik Stahlman, Dustin McIntire,
Steve Glendinning, David Hinds
In-Reply-To: <99737F4847ED0A48AECC9F4A1974A4B80FE464E9E5@MNEXMB2.qlogic.org>
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
On Sun, 2011-07-31 at 23:09 -0700, Amit Salecha wrote:
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org] On Behalf Of Jeff Kirsher
> > Sent: Sunday, July 31, 2011 8:56 AM
> > Subject: [net-next v2 09/71] smsc: Move the SMC (SMSC) drivers
> >
> > Moves the SMC (SMSC) drivers into drivers/net/ethernet/smsc/ and the
> > necessary Kconfig and Makefile changes. Also did some cleanup
> > of NET_VENDOR_SMC Kconfig tag for the 8390 based drivers.
> >
> > CC: Nicolas Pitre <nico@fluxnic.net>
> > CC: Donald Becker <becker@scyld.com>
> > CC: Erik Stahlman <erik@vt.edu>
> > CC: Dustin McIntire <dustin@sensoria.com>
> > CC: Steve Glendinning <steve.glendinning@smsc.com>
> > CC: David Hinds <dahinds@users.sourceforge.net>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > -config NETXEN_NIC
> > - tristate "NetXen Multi port (1/10) Gigabit Ethernet NIC"
> > - depends on PCI
> > - select FW_LOADER
> > - help
> > - This enables the support for NetXen's Gigabit Ethernet card.
> > -
> >
> > -obj-$(CONFIG_NETXEN_NIC) += netxen/
> > obj-$(CONFIG_NIU) += niu.o
> > obj-$(CONFIG_VIRTIO_NET) += virtio_net.o
> > obj-$(CONFIG_SFC) += sfc/
>
> I didn't get reason for above netxen_nic changes.
>
> -Amit
>
Hmm, it looks like changes destined for the previous patch (the QLogic
patch) got applied to this patch. I will clean this up.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] net: add Documentation/networking/scaling.txt
From: Tom Herbert @ 2011-08-01 6:56 UTC (permalink / raw)
To: rdunlap, linux-doc, davem, netdev; +Cc: willemb
[-- Attachment #1: Type: TEXT/PLAIN, Size: 17646 bytes --]
Describes RSS, RPS, RFS, accelerated RFS, and XPS.
Signed-off-by: Tom Herbert <therbert@google.com>
---
Documentation/networking/scaling.txt | 346 ++++++++++++++++++++++++++++++++++
1 files changed, 346 insertions(+), 0 deletions(-)
create mode 100644 Documentation/networking/scaling.txt
diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt
new file mode 100644
index 0000000..aa51f0f
--- /dev/null
+++ b/Documentation/networking/scaling.txt
@@ -0,0 +1,346 @@
+Scaling in the Linux Networking Stack
+
+
+Introduction
+============
+
+This document describes a set of complementary techniques in the Linux
+networking stack to increase parallelism and improve performance (in
+throughput, latency, CPU utilization, etc.) for multi-processor systems.
+
+The following technologies are described:
+
+ RSS: Receive Side Scaling
+ RPS: Receive Packet Steering
+ RFS: Receive Flow Steering
+ Accelerated Receive Flow Steering
+ XPS: Transmit Packet Steering
+
+
+RSS: Receive Side Scaling
+=========================
+
+Contemporary NICs support multiple receive queues (multi-queue), which
+can be used to distribute packets amongst CPUs for processing. The NIC
+distributes packets by applying a filter to each packet to assign it to
+one of a small number of logical flows. Packets for each flow are
+steered to a separate receive queue, which in turn can be processed by
+separate CPUs. This mechanism is generally known as “Receive-side
+Scaling” (RSS).
+
+The filter used in RSS is typically a hash function over the network or
+transport layer headers-- for example, a 4-tuple hash over IP addresses
+and TCP ports of a packet. The most common hardware implementation of
+RSS uses a 128 entry indirection table where each entry stores a queue
+number. The receive queue for a packet is determined by masking out the
+low order seven bits of the computed hash for the packet (usually a
+Toeplitz hash), taking this number as a key into the indirection table
+and reading the corresponding value.
+
+Some advanced NICs allow steering packets to queues based on
+programmable filters. For example, webserver bound TCP port 80 packets
+can be directed to their own receive queue. Such “n-tuple” filters can
+be configured from ethtool (--config-ntuple).
+
+== RSS Configuration
+
+The driver for a multi-queue capable NIC typically provides a module
+parameter specifying the number of hardware queues to configure. In the
+bnx2x driver, for instance, this parameter is called num_queues. A
+typical RSS configuration would be to have one receive queue for each
+CPU if the device supports enough queues, or otherwise at least one for
+each cache domain at a particular cache level (L1, L2, etc.).
+
+The indirection table of an RSS device, which resolves a queue by masked
+hash, is usually programmed by the driver at initialization. The
+default mapping is to distribute the queues evenly in the table, but the
+indirection table can be retrieved and modified at runtime using ethtool
+commands (--show-rxfh-indir and --set-rxfh-indir). Modifying the
+indirection table could be done to to give different queues different
+relative weights.
+
+== RSS IRQ Configuration
+
+Each receive queue has a separate IRQ associated with it. The NIC
+triggers this to notify a CPU when new packets arrive on the given
+queue. The signaling path for PCIe devices uses message signaled
+interrupts (MSI-X), that can route each interrupt to a particular CPU.
+The active mapping of queues to IRQs can be determined from
+/proc/interrupts. By default, all IRQs are routed to CPU0. Because a
+non-negligible part of packet processing takes place in receive
+interrupt handling, it is advantageous to spread receive interrupts
+between CPUs. To manually adjust the IRQ affinity of each interrupt see
+Documentation/IRQ-affinity. On some systems, the irqbalance daemon is
+running and will try to dynamically optimize this setting.
+
+
+RPS: Receive Packet Steering
+============================
+
+Receive Packet Steering (RPS) is logically a software implementation of
+RSS. Being in software, it is necessarily called later in the datapath.
+Whereas RSS selects the queue and hence CPU that will run the hardware
+interrupt handler, RPS selects the CPU to perform protocol processing
+above the interrupt handler. This is accomplished by placing the packet
+on the desired CPU’s backlog queue and waking up the CPU for processing.
+RPS has some advantages over RSS: 1) it can be used with any NIC, 2)
+software filters can easily be added to handle new protocols, 3) it does
+not increase hardware device interrupt rate (but does use IPIs).
+
+RPS is called during bottom half of the receive interrupt handler, when
+a driver sends a packet up the network stack with netif_rx() or
+netif_receive_skb(). These call the get_rps_cpu() function, which
+selects the queue that should process a packet.
+
+The first step in determining the target CPU for RPS is to calculate a
+flow hash over the packet’s addresses or ports (2-tuple or 4-tuple hash
+depending on the protocol). This serves as a consistent hash of the
+associated flow of the packet. The hash is either provided by hardware
+or will be computed in the stack. Capable hardware can pass the hash in
+the receive descriptor for the packet, this would usually be the same
+hash used for RSS (e.g. computed Toeplitz hash). The hash is saved in
+skb->rx_hash and can be used elsewhere in the stack as a hash of the
+packet’s flow.
+
+Each receive hardware qeueue has associated list of CPUs which can
+process packets received on the queue for RPS. For each received
+packet, an index into the list is computed from the flow hash modulo the
+size of the list. The indexed CPU is the target for processing the
+packet, and the packet is queued to the tail of that CPU’s backlog
+queue. At the end of the bottom half routine, inter-processor interrupts
+(IPIs) are sent to any CPUs for which packets have been queued to their
+backlog queue. The IPI wakes backlog processing on the remote CPU, and
+any queued packets are then processed up the networking stack. Note that
+the list of CPUs can be configured separately for each hardware receive
+queue.
+
+== RPS Configuration
+
+RPS requires a kernel compiled with the CONFIG_RPS flag (on by default
+for smp). Even when compiled in, it is disabled without any
+configuration. The list of CPUs to which RPS may forward traffic can be
+configured for each receive queue using the sysfs file entry:
+
+ /sys/class/net/<dev>/queues/rx-<n>/rps_cpus
+
+This file implements a bitmap of CPUs. RPS is disabled when it is zero
+(the default), in which case packets are processed on the interrupting
+CPU. IRQ-affinity.txt explains how CPUs are assigned to the bitmap.
+
+For a single queue device, a typical RPS configuration would be to set
+the rps_cpus to the CPUs in the same cache domain of the interrupting
+CPU for a queue. If NUMA locality is not an issue, this could also be
+all CPUs in the system. At high interrupt rate, it might wise to exclude
+the interrupting CPU from the map since that already performs much work.
+
+For a multi-queue system, if RSS is configured so that a receive queue
+is mapped to each CPU, then RPS is probably redundant and unnecessary.
+If there are fewer queues than CPUs, then RPS might be beneficial if the
+rps_cpus for each queue are the ones that share the same cache domain as
+the interrupting CPU for the queue.
+
+RFS: Receive Flow Steering
+==========================
+
+While RPS steers packet solely based on hash, and thus generally
+provides good load distribution, it does not take into account
+application locality. This is accomplished by Receive Flow Steering
+(RFS). The goal of RFS is to increase datacache hitrate by steering
+kernel processing of packets to the CPU where the application thread
+consuming the packet is running. RFS relies on the same RPS mechanisms
+to enqueue packets onto the backlog of another CPU and to wake that CPU.
+
+In RFS, packets are not forwarded directly by the value of their hash,
+but the hash is used as index into a flow lookup table. This table maps
+flows to the CPUs where those flows are being processed. The flow hash
+(see RPS section above) is used to calculate the index into this table.
+The CPU recorded in each entry is the one which last processed the flow,
+and if there is not a valid CPU for an entry, then packets mapped to
+that entry are steered using plain RPS.
+
+To avoid out of order packets (ie. when scheduler moves a thread with
+outstanding receive packets on) there are two levels of flow tables used
+by RFS: rps_sock_flow_table and rps_dev_flow_table.
+
+rps_sock_table is a global flow table. Each table value is a CPU index
+and is populated by recvmsg and sendmsg (specifically, inet_recvmsg(),
+inet_sendmsg(), inet_sendpage() and tcp_splice_read()). This table
+contains the *desired* CPUs for flows.
+
+rps_dev_flow_table is specific to each hardware receive queue of each
+device. Each table value stores a CPU index and a counter. The CPU
+index represents the *current* CPU that is assigned to processing the
+matching flows.
+
+The counter records the length of this CPU's backlog when a packet in
+this flow was last enqueued. Each backlog queue has a head counter that
+is incremented on dequeue. A tail counter is computed as head counter +
+queue length. In other words, the counter in rps_dev_flow_table[i]
+records the last element in flow i that has been enqueued onto the
+currently designated CPU for flow i (of course, entry i is actually
+selected by hash and multiple flows may hash to the same entry i).
+
+And now the trick for avoiding out of order packets: when selecting the
+CPU for packet processing (from get_rps_cpu()) the rps_sock_flow table
+and the rps_dev_flow table of the queue that the packet was received on
+are compared. If the desired CPU for the flow (found in the
+rps_sock_flow table) matches the current CPU (found in the rps_dev_flow
+table), the packet is enqueud onto that CPU’s backlog. If they differ,
+the current cpu is updated to match the desired CPU if one of the
+following is true:
+
+- The current CPU's queue head counter >= the recorded tail counter
+ value in rps_dev_flow[i]
+- The current CPU is unset (equal to NR_CPUS)
+- The current CPU is offline
+
+After this check, the packet is sent to the (possibly updated) current
+CPU. These rules aim to ensure that a flow only moves to a new CPU when
+there are no packets outstanding on the old CPU, as the outstanding
+packets could arrive later than those about to be processed on the new
+CPU.
+
+== RFS Configuration
+
+RFS is only available if the kernel flag CONFIG_RFS is enabled (on by
+default for smp). The functionality is disabled without any
+configuration. The number of entries in the global flow table is set
+through:
+
+ /proc/sys/net/core/rps_sock_flow_entries
+
+The number of entries in the per queue flow table are set through:
+
+ /sys/class/net/<dev>/queues/tx-<n>/rps_flow_cnt
+
+Both of these need to be set before RFS is enabled for a receive queue.
+Values for both of these are rounded up to the nearest power of two. The
+suggested flow count depends on the expected number active connections
+at any given time, which may be significantly less than the number of
+open connections. We have found that a value of 32768 for
+rps_sock_flow_entries works fairly well on a moderately loaded server.
+
+For a single queue device, the rps_flow_cnt value for the single queue
+would normally be configured to the same value as rps_sock_flow_entries.
+For a multi-queue device, the rps_flow_cnt for each queue might be
+configured as rps_sock_flow_entries / N, where N is the number of
+queues. So for instance, if rps_flow_entries is set to 32768 and there
+are 16 configured receive queues, rps_flow_cnt for each queue might be
+configured as 2048.
+
+
+Accelerated RFS
+===============
+
+Accelerated RFS is to RFS what RSS is to RPS: a hardware-accelerated
+load balancing mechanism that uses soft state to steer flows based on
+where the thread consuming the packets of each flow is running.
+Accelerated RFS should perform better than RFS since packets are sent
+directly to a CPU local to the thread consuming the data. The target CPU
+will either be the same CPU where the application runs, or at least a
+CPU which is local to the application thread’s CPU in the cache
+hierarchy.
+
+To enable accelerated RFS, the networking stack calls the
+ndo_rx_flow_steer driver function to communicate the desired hardware
+queue for packets matching a particular flow. The network stack
+automatically calls this function every time a flow entry in
+rps_dev_flow_table is updated. The driver in turn uses a device specific
+method to program the NIC to steer the packets.
+
+The hardware queue for a flow is derived from the CPU recorded in
+rps_dev_flow_table. The stack consults a CPU to hardware queue map which
+is maintained by the NIC driver. This is an autogenerated reverse map of
+the IRQ affinity table shown by /proc/interrupts. Drivers can use
+functions in the cpu_rmap (“cpu affinitiy reverse map”) kernel library
+to populate the map. For each CPU, the corresponding queue in the map is
+set to be one whose processing CPU is closest in cache locality.
+
+== Accelerated RFS Configuration
+
+Accelerated RFS is only available if the kernel is compiled with
+CONFIG_RFS_ACCEL and support is provided by the NIC device and driver.
+It also requires that ntuple filtering is enabled via ethtool. The map
+of CPU to queues is automatically deduced from the IRQ affinities
+configured for each receive queue by the driver, so no additional
+configuration should be necessary.
+
+XPS: Transmit Packet Steering
+=============================
+
+Transmit Packet Steering is a mechanism for intelligently selecting
+which transmit queue to use when transmitting a packet on a multi-queue
+device. To accomplish this, a mapping from CPU to hardware queue(s) is
+recorded. The goal of this mapping is usually to assign queues
+exclusively to a subset of CPUs, where the transmit completions for
+these queues are processed on a CPU within this set. This choice
+provides two benefits. First, contention on the device queue lock is
+significantly reduced since fewer CPUs contend for the same queue
+(contention can be eliminated completely if each CPU has its own
+transmit queue). Secondly, cache miss rate on transmit completion is
+reduced, in particular for data cache lines that hold the sk_buff
+structures.
+
+XPS is configured per transmit queue by setting a bitmap of CPUs that
+may use that queue to transmit. The reverse mapping, from CPUs to
+transmit queues, is computed and maintained for each network device.
+When transmitting the first packet in a flow, the function
+get_xps_queue() is called to select a queue. This function uses the ID
+of the running CPU as a key into the CPU to queue lookup table. If the
+ID matches a single queue, that is used for transmission. If multiple
+queues match, one is selected by using the flow hash to compute an index
+into the set.
+
+The queue chosen for transmitting a particular flow is saved in the
+corresponding socket structure for the flow (e.g. a TCP connection).
+This transmit queue is used for subsequent packets sent on the flow to
+prevent out of order (ooo) packets. The choice also amortizes the cost
+of calling get_xps_queues() over all packets in the connection. To avoid
+ooo packets, the queue for a flow can subsequently only be changed if
+skb->ooo_okay is set for a packet in the flow. This flag indicates that
+there are no outstanding packets in the flow, so the transmit queue can
+change without the risk of generating out of order packets. The
+transport layer is responsible for setting ooo_okay appropriately. TCP,
+for instance, sets the flag when all data for a connection has been
+acknowledged.
+
+
+== XPS Configuration
+
+XPS is only available if the kernel flag CONFIG_XPS is enabled (on by
+default for smp). The functionality is disabled without any
+configuration, in which case the the transmit queue for a packet is
+selected by using a flow hash as an index into the set of all transmit
+queues for the device. To enable XPS, the bitmap of CPUs that may use a
+transmit queue is configured using the sysfs file entry:
+
+/sys/class/net/<dev>/queues/tx-<n>/xps_cpus
+
+XPS is disabled when it is zero (the default). IRQ-affinity.txt explains
+how CPUs are assigned to the bitmap.
+
+For a network device with a single transmission queue, XPS configuration
+has no effect, since there is no choice in this case. In a multi-queue
+system, XPS is usually configured so that each CPU maps onto one queue.
+If there are as many queues as there are CPUs in the system, then each
+queue can also map onto one CPU, resulting in exclusive pairings that
+experience no contention. If there are fewer queues than CPUs, then the
+best CPUs to share a given queue are probably those that share the cache
+with the CPU that processes transmit completions for that queue
+(transmit interrupts).
+
+
+Further Information
+===================
+RPS and RFS were introduced in kernel 2.6.35. XPS was incorporated into
+2.6.38. Original patches were submitted by Tom Herbert
+(therbert@google.com)
+
+
+Accelerated RFS was introduced in 2.6.35. Original patches were
+submitted by Ben Hutchings (bhutchings@solarflare.com)
+
+Authors:
+Tom Herbert (therbert@google.com)
+Willem de Bruijn (willemb@google.com)
+
--
1.7.3.1
^ permalink raw reply related
* Re: net-next-2.6 [PATCH 0/7] dccp: add support for dynamic parameter updates
From: David Miller @ 2011-08-01 7:10 UTC (permalink / raw)
To: gerrit; +Cc: dccp, netdev
In-Reply-To: <1311600996-6712-1-git-send-email-gerrit@erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Mon, 25 Jul 2011 07:36:29 -0600
> I have also placed this in into a fresh (today's) copy of net-next-2.6, on
>
> git://eden-feed.erg.abdn.ac.uk/net-next-2.6 [subtree 'dccp']
I did a test pull and this URL doesn't work:
[davem@dokdo net-next]$ git pull git://eden-feed.erg.abdn.ac.uk/net-next-2.6 dccp
fatal: The remote end hung up unexpectedly
[davem@dokdo net-next]$ git pull git://eden-feed.erg.abdn.ac.uk/net-next-2.6
fatal: The remote end hung up unexpectedly
[davem@dokdo net-next]$
^ permalink raw reply
* Re: [PATCH net-next-2.6 1/2] be2net: cleanup and refactor stats code
From: David Miller @ 2011-08-01 8:54 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1311657015-23465-2-git-send-email-sathya.perla@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Tue, 26 Jul 2011 10:40:14 +0530
> In preparation for 64-bit stats interface, the following cleanups help
> streamline the code:
> 1) made some more rx/tx stats stored by driver 64 bit
> 2) made some HW stas (err/drop counters) stored in be_drv_stats 32 bit to
> keep the code simple as BE provides 32-bit counters only.
> 3) removed duplication of netdev stats in ethtool
> 4) removed some un-necessary stats and fixed some names
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH net-next-2.6 2/2] be2net: use stats-sync to read/write 64-bit stats
From: David Miller @ 2011-08-01 8:55 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <1311657015-23465-3-git-send-email-sathya.perla@emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Tue, 26 Jul 2011 10:40:15 +0530
> 64-bit stats in be2net are written/read as follows using the stats-sync
> interface for safe access in 32-bit archs:
>
> 64-bit sync writer reader
> stats
> ------------------------------------------------------------------------------
> tx_stats tx_stats->sync be_xmit be_get_stats64,
> ethtool
> tx-compl tx_stats->sync_compl tx-compl-processing ethtool
> rx-stats rx_stats->sync rx-compl-processing be_get_stats64,
> ethtool,
> eqd-update
>
> This patch is based on Stephen Hemminger's earlier patch on the same issue...
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH] ipv6: some RCU conversions
From: David Miller @ 2011-08-01 8:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311837183.2697.37.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Jul 2011 09:13:03 +0200
> ICMP and ND are not fast path, but still we can avoid changing idev
> refcount, using RCU.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH] ipv6: use RCU in inet6_csk_xmit()
From: David Miller @ 2011-08-01 8:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311860627.2346.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Jul 2011 15:43:47 +0200
> Use RCU to avoid changing dst_entry refcount in fast path.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH] ipv6: avoid a dst_entry refcount change in ipv6_destopt_rcv()
From: David Miller @ 2011-08-01 8:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311861635.2346.14.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Jul 2011 16:00:35 +0200
> ipv6_destopt_rcv() runs with rcu_read_lock(), so there is no need to
> take a temporay reference on dst_entry, even if skb is freed by
> ip6_parse_tlv()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH] ip6tnl: avoid touching dst refcount in ip6_tnl_xmit2()
From: David Miller @ 2011-08-01 8:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1311863545.2346.21.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Jul 2011 16:32:25 +0200
> Even using percpu stats, we still hit tunnel dst_entry refcount in
> ip6_tnl_xmit2()
>
> Since we are in RCU locked section, we can use skb_dst_set_noref() and
> avoid these atomic operations, leaving dst shared on cpus.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH net-next 0/5] qlcnic: Fixes and debug support
From: David Miller @ 2011-08-01 8:57 UTC (permalink / raw)
To: anirban.chakraborty; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <1311982230-10543-6-git-send-email-anirban.chakraborty@qlogic.com>
From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Date: Fri, 29 Jul 2011 16:30:30 -0700
> Please apply the series to net-next. Thanks.
Queued up for net-next
^ permalink raw reply
* Re: [PATCH 1/2] bna: Remove Unnecessary CNA Check
From: David Miller @ 2011-08-01 8:56 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <1311889767-9848-1-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Thu, 28 Jul 2011 14:49:26 -0700
> Change details:
> - ioc->cna is always set to 1 for eth functions, remove the check that
> asserts IOC is in CNA mode in bfa_ioc_firmware_lock() and
> bfa_ioc_firmware_unlock() in bfa_ioc_ct.c.
>
> Signed-off-by: Rasesh Mody <rmody@brocade.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH 1/2] ipg: Use current logging styles
From: David Miller @ 2011-08-01 8:57 UTC (permalink / raw)
To: joe; +Cc: romieu, sorbica, netdev, linux-kernel
In-Reply-To: <2ee87bfccbbb5cf1776df6751b65e4a3110019f4.1311993468.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 29 Jul 2011 19:38:14 -0700
> Add and use pr_fmt, pr_<level> and netdev_<level>.
> Convert printks with %[n].[n]x to %nx to be shorter
> and clearer.
> Consolidate printks to use a single printk rather
> than continued printks without KERN_CONT.
> Removed unnecessary trailing periods.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH 2/2] bna: HW Interface Init Update
From: David Miller @ 2011-08-01 8:56 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team
In-Reply-To: <1311889767-9848-2-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Thu, 28 Jul 2011 14:49:27 -0700
> Change details:
> - Split the hw interface into common and asic specific to support new asic
> in the future.
> - Fix bfa_ioc_ct_isr_mode_set() to also include the case that we are already
> in the desired msix mode.
>
> Signed-off-by: Rasesh Mody <rmody@brocade.com>
Queued up for net-next
^ permalink raw reply
* Re: [PATCH 2/2] ipg: Use const
From: David Miller @ 2011-08-01 8:57 UTC (permalink / raw)
To: joe; +Cc: romieu, sorbica, netdev, linux-kernel
In-Reply-To: <5311ff3fa329c4551cfdec5960162d3d490509f1.1311993468.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 29 Jul 2011 19:38:15 -0700
> Make a couple of declarations const to save some data space.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Queued up for net-next
^ permalink raw reply
* Re: PROBLEM: BUG (NULL ptr dereference in ipv4_dst_check)
From: synapse @ 2011-08-01 8:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1312002053.2873.41.camel@edumazet-laptop>
Hello
Sorry, I wasn't home on the weekend. Exactly to which tree should I
apply this?
It doesn't apply cleanly to 3.0.0. Am I missing something?
Gergely Kalman
On 07/30/11 07:00, Eric Dumazet wrote:
> Le vendredi 29 juillet 2011 à 17:43 +0200, Eric Dumazet a écrit :
>
>> Oh well, we already use RCU in neigh_destroy(), so adding rcu would need
>> to change all dst_get_neighbour() callers to be in one rcu_read_lock()
>> section.
>>
>> I'll take a look, I suspect its mostly already done.
>>
>>
> Here is the patch I finally cooked and tested.
>
> Could you please test it as well Gergely ?
>
> Thanks !
>
> [PATCH] net: fix NULL dereferences in check_peer_redir()
>
> Gergely Kalman reported crashes in check_peer_redir().
>
> It appears commit f39925dbde778 (ipv4: Cache learned redirect
> information in inetpeer.) added a race, leading to possible NULL ptr
> dereference.
>
> Since we can now change dst neighbour, we should make sure a reader can
> safely use a neighbour.
>
> Add RCU protection to dst neighbour, and make sure check_peer_redir()
> can be called safely by different cpus in parallel.
>
> As neighbours are already freed after one RCU grace period, this patch
> should not add typical RCU penalty (cache cold effects)
>
> Many thanks to Gergely for providing a pretty report pointing to the
> bug.
>
> Reported-by: Gergely Kalman<synapse@hippy.csoma.elte.hu>
> Signed-off-by: Eric Dumazet<eric.dumazet@gmail.com>
> ---
> include/net/dst.h | 17 +++++++++++++----
> net/ipv4/ip_output.c | 10 ++++++++--
> net/ipv4/route.c | 14 ++++++++------
> net/ipv6/addrconf.c | 2 +-
> net/ipv6/ip6_fib.c | 2 +-
> net/ipv6/ip6_output.c | 13 +++++++++++--
> net/ipv6/route.c | 35 +++++++++++++++++++++++++----------
> 7 files changed, 67 insertions(+), 26 deletions(-)
>
> diff --git a/include/net/dst.h b/include/net/dst.h
> index 29e2557..13d507d 100644
> --- a/include/net/dst.h
> +++ b/include/net/dst.h
> @@ -37,7 +37,7 @@ struct dst_entry {
> unsigned long _metrics;
> unsigned long expires;
> struct dst_entry *path;
> - struct neighbour *_neighbour;
> + struct neighbour __rcu *_neighbour;
> #ifdef CONFIG_XFRM
> struct xfrm_state *xfrm;
> #else
> @@ -88,12 +88,17 @@ struct dst_entry {
>
> static inline struct neighbour *dst_get_neighbour(struct dst_entry *dst)
> {
> - return dst->_neighbour;
> + return rcu_dereference(dst->_neighbour);
> +}
> +
> +static inline struct neighbour *dst_get_neighbour_raw(struct dst_entry *dst)
> +{
> + return rcu_dereference_raw(dst->_neighbour);
> }
>
> static inline void dst_set_neighbour(struct dst_entry *dst, struct neighbour *neigh)
> {
> - dst->_neighbour = neigh;
> + rcu_assign_pointer(dst->_neighbour, neigh);
> }
>
> extern u32 *dst_cow_metrics_generic(struct dst_entry *dst, unsigned long old);
> @@ -382,8 +387,12 @@ static inline void dst_rcu_free(struct rcu_head *head)
> static inline void dst_confirm(struct dst_entry *dst)
> {
> if (dst) {
> - struct neighbour *n = dst_get_neighbour(dst);
> + struct neighbour *n;
> +
> + rcu_read_lock();
> + n = dst_get_neighbour(dst);
> neigh_confirm(n);
> + rcu_read_unlock();
> }
> }
>
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index ccaaa85..77d3ede 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -204,9 +204,15 @@ static inline int ip_finish_output2(struct sk_buff *skb)
> skb = skb2;
> }
>
> + rcu_read_lock();
> neigh = dst_get_neighbour(dst);
> - if (neigh)
> - return neigh_output(neigh, skb);
> + if (neigh) {
> + int res = neigh_output(neigh, skb);
> +
> + rcu_read_unlock();
> + return res;
> + }
> + rcu_read_unlock();
>
> if (net_ratelimit())
> printk(KERN_DEBUG "ip_finish_output2: No header cache and no neighbour!\n");
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 1730689..6afc4eb 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -1628,16 +1628,18 @@ static int check_peer_redir(struct dst_entry *dst, struct inet_peer *peer)
> {
> struct rtable *rt = (struct rtable *) dst;
> __be32 orig_gw = rt->rt_gateway;
> - struct neighbour *n;
> + struct neighbour *n, *old_n;
>
> dst_confirm(&rt->dst);
>
> - neigh_release(dst_get_neighbour(&rt->dst));
> - dst_set_neighbour(&rt->dst, NULL);
> -
> rt->rt_gateway = peer->redirect_learned.a4;
> - rt_bind_neighbour(rt);
> - n = dst_get_neighbour(&rt->dst);
> +
> + n = ipv4_neigh_lookup(&rt->dst,&rt->rt_gateway);
> + if (IS_ERR(n))
> + return PTR_ERR(n);
> + old_n = xchg(&rt->dst._neighbour, n);
> + if (old_n)
> + neigh_release(old_n);
> if (!n || !(n->nud_state& NUD_VALID)) {
> if (n)
> neigh_event_send(n, NULL);
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index a55500c..f012ebd 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -656,7 +656,7 @@ ipv6_add_addr(struct inet6_dev *idev, const struct in6_addr *addr, int pfxlen,
> * layer address of our nexhop router
> */
>
> - if (dst_get_neighbour(&rt->dst) == NULL)
> + if (dst_get_neighbour_raw(&rt->dst) == NULL)
> ifa->flags&= ~IFA_F_OPTIMISTIC;
>
> ifa->idev = idev;
> diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
> index 54a4678..320d91d 100644
> --- a/net/ipv6/ip6_fib.c
> +++ b/net/ipv6/ip6_fib.c
> @@ -1455,7 +1455,7 @@ static int fib6_age(struct rt6_info *rt, void *arg)
> RT6_TRACE("aging clone %p\n", rt);
> return -1;
> } else if ((rt->rt6i_flags& RTF_GATEWAY)&&
> - (!(dst_get_neighbour(&rt->dst)->flags& NTF_ROUTER))) {
> + (!(dst_get_neighbour_raw(&rt->dst)->flags& NTF_ROUTER))) {
> RT6_TRACE("purging route %p via non-router but gateway\n",
> rt);
> return -1;
> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
> index 32e5339..4c882cf 100644
> --- a/net/ipv6/ip6_output.c
> +++ b/net/ipv6/ip6_output.c
> @@ -135,10 +135,15 @@ static int ip6_finish_output2(struct sk_buff *skb)
> skb->len);
> }
>
> + rcu_read_lock();
> neigh = dst_get_neighbour(dst);
> - if (neigh)
> - return neigh_output(neigh, skb);
> + if (neigh) {
> + int res = neigh_output(neigh, skb);
>
> + rcu_read_unlock();
> + return res;
> + }
> + rcu_read_unlock();
> IP6_INC_STATS_BH(dev_net(dst->dev),
> ip6_dst_idev(dst), IPSTATS_MIB_OUTNOROUTES);
> kfree_skb(skb);
> @@ -975,12 +980,14 @@ static int ip6_dst_lookup_tail(struct sock *sk,
> * dst entry and replace it instead with the
> * dst entry of the nexthop router
> */
> + rcu_read_lock();
> n = dst_get_neighbour(*dst);
> if (n&& !(n->nud_state& NUD_VALID)) {
> struct inet6_ifaddr *ifp;
> struct flowi6 fl_gw6;
> int redirect;
>
> + rcu_read_unlock();
> ifp = ipv6_get_ifaddr(net,&fl6->saddr,
> (*dst)->dev, 1);
>
> @@ -1000,6 +1007,8 @@ static int ip6_dst_lookup_tail(struct sock *sk,
> if ((err = (*dst)->error))
> goto out_err_release;
> }
> + } else {
> + rcu_read_unlock();
> }
> #endif
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index e8987da..9e69eb0 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -364,7 +364,7 @@ out:
> #ifdef CONFIG_IPV6_ROUTER_PREF
> static void rt6_probe(struct rt6_info *rt)
> {
> - struct neighbour *neigh = rt ? dst_get_neighbour(&rt->dst) : NULL;
> + struct neighbour *neigh;
> /*
> * Okay, this does not seem to be appropriate
> * for now, however, we need to check if it
> @@ -373,8 +373,10 @@ static void rt6_probe(struct rt6_info *rt)
> * Router Reachability Probe MUST be rate-limited
> * to no more than one per minute.
> */
> + rcu_read_lock();
> + neigh = rt ? dst_get_neighbour(&rt->dst) : NULL;
> if (!neigh || (neigh->nud_state& NUD_VALID))
> - return;
> + goto out;
> read_lock_bh(&neigh->lock);
> if (!(neigh->nud_state& NUD_VALID)&&
> time_after(jiffies, neigh->updated + rt->rt6i_idev->cnf.rtr_probe_interval)) {
> @@ -387,8 +389,11 @@ static void rt6_probe(struct rt6_info *rt)
> target = (struct in6_addr *)&neigh->primary_key;
> addrconf_addr_solict_mult(target,&mcaddr);
> ndisc_send_ns(rt->rt6i_dev, NULL, target,&mcaddr, NULL);
> - } else
> + } else {
> read_unlock_bh(&neigh->lock);
> + }
> +out:
> + rcu_read_unlock();
> }
> #else
> static inline void rt6_probe(struct rt6_info *rt)
> @@ -412,8 +417,11 @@ static inline int rt6_check_dev(struct rt6_info *rt, int oif)
>
> static inline int rt6_check_neigh(struct rt6_info *rt)
> {
> - struct neighbour *neigh = dst_get_neighbour(&rt->dst);
> + struct neighbour *neigh;
> int m;
> +
> + rcu_read_lock();
> + neigh = dst_get_neighbour(&rt->dst);
> if (rt->rt6i_flags& RTF_NONEXTHOP ||
> !(rt->rt6i_flags& RTF_GATEWAY))
> m = 1;
> @@ -430,6 +438,7 @@ static inline int rt6_check_neigh(struct rt6_info *rt)
> read_unlock_bh(&neigh->lock);
> } else
> m = 0;
> + rcu_read_unlock();
> return m;
> }
>
> @@ -769,7 +778,7 @@ static struct rt6_info *rt6_alloc_clone(struct rt6_info *ort,
> rt->rt6i_dst.plen = 128;
> rt->rt6i_flags |= RTF_CACHE;
> rt->dst.flags |= DST_HOST;
> - dst_set_neighbour(&rt->dst, neigh_clone(dst_get_neighbour(&ort->dst)));
> + dst_set_neighbour(&rt->dst, neigh_clone(dst_get_neighbour_raw(&ort->dst)));
> }
> return rt;
> }
> @@ -803,7 +812,7 @@ restart:
> dst_hold(&rt->dst);
> read_unlock_bh(&table->tb6_lock);
>
> - if (!dst_get_neighbour(&rt->dst)&& !(rt->rt6i_flags& RTF_NONEXTHOP))
> + if (!dst_get_neighbour_raw(&rt->dst)&& !(rt->rt6i_flags& RTF_NONEXTHOP))
> nrt = rt6_alloc_cow(rt,&fl6->daddr,&fl6->saddr);
> else if (!(rt->dst.flags& DST_HOST))
> nrt = rt6_alloc_clone(rt,&fl6->daddr);
> @@ -1587,7 +1596,7 @@ void rt6_redirect(const struct in6_addr *dest, const struct in6_addr *src,
> dst_confirm(&rt->dst);
>
> /* Duplicate redirect: silently ignore. */
> - if (neigh == dst_get_neighbour(&rt->dst))
> + if (neigh == dst_get_neighbour_raw(&rt->dst))
> goto out;
>
> nrt = ip6_rt_copy(rt, dest);
> @@ -1682,7 +1691,7 @@ again:
> 1. It is connected route. Action: COW
> 2. It is gatewayed route or NONEXTHOP route. Action: clone it.
> */
> - if (!dst_get_neighbour(&rt->dst)&& !(rt->rt6i_flags& RTF_NONEXTHOP))
> + if (!dst_get_neighbour_raw(&rt->dst)&& !(rt->rt6i_flags& RTF_NONEXTHOP))
> nrt = rt6_alloc_cow(rt, daddr, saddr);
> else
> nrt = rt6_alloc_clone(rt, daddr);
> @@ -2326,6 +2335,7 @@ static int rt6_fill_node(struct net *net,
> struct nlmsghdr *nlh;
> long expires;
> u32 table;
> + struct neighbour *n;
>
> if (prefix) { /* user wants prefix routes only */
> if (!(rt->rt6i_flags& RTF_PREFIX_RT)) {
> @@ -2414,8 +2424,11 @@ static int rt6_fill_node(struct net *net,
> if (rtnetlink_put_metrics(skb, dst_metrics_ptr(&rt->dst))< 0)
> goto nla_put_failure;
>
> - if (dst_get_neighbour(&rt->dst))
> - NLA_PUT(skb, RTA_GATEWAY, 16,&dst_get_neighbour(&rt->dst)->primary_key);
> + rcu_read_lock();
> + n = dst_get_neighbour(&rt->dst);
> + if (n)
> + NLA_PUT(skb, RTA_GATEWAY, 16,&n->primary_key);
> + rcu_read_unlock();
>
> if (rt->dst.dev)
> NLA_PUT_U32(skb, RTA_OIF, rt->rt6i_dev->ifindex);
> @@ -2608,12 +2621,14 @@ static int rt6_info_route(struct rt6_info *rt, void *p_arg)
> #else
> seq_puts(m, "00000000000000000000000000000000 00 ");
> #endif
> + rcu_read_lock();
> n = dst_get_neighbour(&rt->dst);
> if (n) {
> seq_printf(m, "%pi6", n->primary_key);
> } else {
> seq_puts(m, "00000000000000000000000000000000");
> }
> + rcu_read_unlock();
> seq_printf(m, " %08x %08x %08x %08x %8s\n",
> rt->rt6i_metric, atomic_read(&rt->dst.__refcnt),
> rt->dst.__use, rt->rt6i_flags,
>
^ permalink raw reply
* Re: [net-next v2 02/71] 3c*/acenic/typhoon: Move 3Com Ethernet drivers
From: Alan Cox @ 2011-08-01 9:03 UTC (permalink / raw)
To: Jeff Kirsher
Cc: davem, netdev, gospo, sassmann, Philip Blundell, Steffen Klassert,
David Dillow, Jes Sorensen, Donald Becker, Craig Southeren,
David Hinds
In-Reply-To: <1312082850-24914-3-git-send-email-jeffrey.t.kirsher@intel.com>
On Sat, 30 Jul 2011 20:26:21 -0700
Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> Moves the 3Com drivers into drivers/net/ethernet/3com/ and the
> necessary Kconfig and Makefile changes.
This still seems crazy
The 3c503 is not being moved (as its 8390 based)
But the 3c505/3c523/3c527/3c507 by that logic also shouldn't be moved
as really they all belong with the rest of the Intel devices they are
basically variants of (the 3c527 is weirder, in fact you can probably
run CP/M 86 on it if you were mad enough)
> drivers/net/{pcmcia => ethernet/3com}/3c574_cs.c | 0
> drivers/net/{pcmcia => ethernet/3com}/3c589_cs.c | 0
These are currently sensibly where they belong - with the pcmcia
adapters.
> drivers/net/{ => ethernet/3com}/3c59x.c | 0
> drivers/net/ethernet/3com/Kconfig | 200
> ++++++++++++++++++++++
> drivers/net/ethernet/3com/Makefile | 16 ++
> drivers/net/{ => ethernet/3com}/acenic.c | 0
> drivers/net/{ => ethernet/3com}/acenic.h | 0
And most Acenic devices are probably branded Netgear not 3COM and may
also claim to be from Farallon, SGI, Alteon or DEC. Again not a 3Com
originated part.
So I still think this patch is utter nonsense and just noise.
There isn't any sense in trying to line the network drivers up by
whatever is written on the box that was thrown away years before. The
reality is that most cards do not bear anything relevant to the chipset
vendors name, even by the early 1990s.
Architectually it makes more sense to keep tidy by bus type and by
chipset, not by vendor name
NAK
And even if you wanted to make Kconfig simpler - you don't need to move
files around.
Alan
^ permalink raw reply
* Re: PROBLEM: BUG (NULL ptr dereference in ipv4_dst_check)
From: Eric Dumazet @ 2011-08-01 9:15 UTC (permalink / raw)
To: synapse; +Cc: David Miller, netdev
In-Reply-To: <4E366A8F.201@hippy.csoma.elte.hu>
Le lundi 01 août 2011 à 10:57 +0200, synapse a écrit :
> Hello
>
> Sorry, I wasn't home on the weekend. Exactly to which tree should I
> apply this?
> It doesn't apply cleanly to 3.0.0. Am I missing something?
>
Could you try latest linux tree ?
We first validate patches on current tree, then backport them if needed
to previous kernels.
Thanks
^ permalink raw reply
* PLEASE REPLY, ITS A BUSINESS PROPOSAL
From: Weixin.Zheng.15 @ 2011-08-01 8:46 UTC (permalink / raw)
This is a business proposal for you, it is an oil exportation proposition
contract for you and this is a highly prospective crude oil sales
venture; This
involves the shipment of over 2.5 Million barrels of Light Crude Oil from Iraq
to Turkey, this project is genuine, legal and highly lucrative. For more
details, please reply to this email address: bahhahfeaz@hotmail.com
Sincerely
Bahhah Faez Saleh
^ permalink raw reply
* Re: [net-next v2 02/71] 3c*/acenic/typhoon: Move 3Com Ethernet drivers
From: David Miller @ 2011-08-01 9:21 UTC (permalink / raw)
To: alan
Cc: jeffrey.t.kirsher, netdev, gospo, sassmann, philb, klassert, dave,
jes, becker, craigs, dahinds
In-Reply-To: <20110801100303.48ed75f7@bob.linux.org.uk>
From: Alan Cox <alan@linux.intel.com>
Date: Mon, 1 Aug 2011 10:03:03 +0100
> And even if you wanted to make Kconfig simpler - you don't need to move
> files around.
The point is to move the files around, so that drivers/net/ isn't
a turd pond.
I agree with some of your feedback, but I disagree with a wholesale
rejecting the idea of untangling the mess under drivers/net/ as that's
the main reason why I want Jeff's work to be done
^ permalink raw reply
* [PATCH] MAINTAINERS: Remove Pekka Savola from ipv6.
From: David Miller @ 2011-08-01 9:23 UTC (permalink / raw)
To: netdev; +Cc: pekkas
Signed-off-by: David S. Miller <davem@davemloft.net>
---
MAINTAINERS | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a99fed1..5d4ceba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4443,7 +4443,6 @@ F: include/linux/netdevice.h
NETWORKING [IPv4/IPv6]
M: "David S. Miller" <davem@davemloft.net>
M: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
-M: "Pekka Savola (ipv6)" <pekkas@netcore.fi>
M: James Morris <jmorris@namei.org>
M: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
M: Patrick McHardy <kaber@trash.net>
--
1.7.6
^ permalink raw reply related
* Re: [PATCH 3/6] drivers/net/niu.c: adjust array index
From: David Miller @ 2011-08-01 9:27 UTC (permalink / raw)
To: julia-dAYI7NvHqcQ
Cc: eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
mirq-linux-CoA6ZxLDdyEEUmgCuDUIdw,
bhutchings-s/n/eUQHGBpZroRs9YW3xA,
shemminger-ZtmgI6mnKB3QT0dZR+AlfA
In-Reply-To: <1311857165-14780-4-git-send-email-julia-dAYI7NvHqcQ@public.gmane.org>
From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
Date: Thu, 28 Jul 2011 14:46:03 +0200
> From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
>
> Convert array index from the loop bound to the loop index.
>
> A simplified version of the semantic patch that fixes this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression e1,e2,ar;
> @@
>
> for(e1 = 0; e1 < e2; e1++) { <...
> ar[
> - e2
> + e1
> ]
> ...> }
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [Bugme-new] [Bug 39372] New: Problems with HFSC Scheduler
From: David Miller @ 2011-08-01 9:27 UTC (permalink / raw)
To: eric.dumazet
Cc: kaber, soltys, akpm, netdev, bugme-daemon, hadi, lucas.bocchi,
631945, 00bormoj, fdelawarde
In-Reply-To: <1312003362.2873.54.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 30 Jul 2011 07:22:42 +0200
> [PATCH] sch_sfq: fix sfq_enqueue()
>
> commit 8efa88540635 (sch_sfq: avoid giving spurious NET_XMIT_CN signals)
> forgot to call qdisc_tree_decrease_qlen() to signal upper levels that a
> packet (from another flow) was dropped, leading to various problems.
>
> With help from Michal Soltys and Michal Pokrywka, who did a bisection.
>
> Bugzilla ref: https://bugzilla.kernel.org/show_bug.cgi?id=39372
> Debian ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631945
>
> Reported-by: Lucas Bocchi <lucas.bocchi@gmail.com>
> Reported-and-bisected-by: Michal Pokrywka <wolfmoon@o2.pl>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Michal Soltys <soltys@ziu.info>
> Acked-by: Patrick McHardy <kaber@trash.net>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/6] net: adjust array index
From: David Miller @ 2011-08-01 9:27 UTC (permalink / raw)
To: julia
Cc: kernel-janitors, kuznet, pekkas, jmorris, yoshfuji, kaber, netdev,
linux-kernel
In-Reply-To: <1311857165-14780-2-git-send-email-julia@diku.dk>
From: Julia Lawall <julia@diku.dk>
Date: Thu, 28 Jul 2011 14:46:01 +0200
> From: Julia Lawall <julia@diku.dk>
>
> Convert array index from the loop bound to the loop index.
>
> A simplified version of the semantic patch that fixes this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @@
> expression e1,e2,ar;
> @@
>
> for(e1 = 0; e1 < e2; e1++) { <...
> ar[
> - e2
> + e1
> ]
> ...> }
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox