* Re: [PATCH v4 3/3] netdev/of/phy: Add MDIO bus multiplexer driven by GPIO lines.
From: David Miller @ 2012-04-18 17:45 UTC (permalink / raw)
To: david.daney
Cc: ddaney.cavm, grant.likely, rob.herring, devicetree-discuss,
netdev, linux-kernel, linux-mips, afleming, galak
In-Reply-To: <4F8EEAD8.8050205@cavium.com>
From: David Daney <david.daney@cavium.com>
Date: Wed, 18 Apr 2012 09:24:56 -0700
> B) Regenerate the entire set with said patch rolled in?
Already regenerate patch sets with fixes incorporated into the
original patches.
^ permalink raw reply
* Re: [net-next PATCH v3] bonding: start slaves with link down for ARP monitor
From: Jay Vosburgh @ 2012-04-18 17:45 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, Andy Gospodarek, Flavio Leitner
In-Reply-To: <20120417121135.5F9A740290@alaris.suse.cz>
Michal Kubecek <mkubecek@suse.cz> wrote:
>Initialize slave device link state as down if ARP monitor is
>active and net_carrier_ok() returns zero. Also shift initial
>value of its last_arp_tx so that it doesn't immediately cause
>fake detection of "up" state.
>
>When ARP monitoring is used, initializing the slave device with
>up link state can cause ARP monitor to detect link failure
>before the device is really up (with igb driver, this can take
>more than two seconds).
>
>Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
>---
> drivers/net/bonding/bond_main.c | 33 +++++++++++++++++++++------------
> 1 files changed, 21 insertions(+), 12 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index bb92899..44e6a64 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -1726,7 +1726,8 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
>
> read_lock(&bond->lock);
>
>- new_slave->last_arp_rx = jiffies;
>+ new_slave->last_arp_rx = jiffies -
>+ (msecs_to_jiffies(bond->params.arp_interval) + 1);
>
> if (bond->params.miimon && !bond->params.use_carrier) {
> link_reporting = bond_check_dev_link(bond, slave_dev, 1);
>@@ -1751,22 +1752,30 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> }
>
> /* check for initial state */
>- if (!bond->params.miimon ||
>- (bond_check_dev_link(bond, slave_dev, 0) == BMSR_LSTATUS)) {
>- if (bond->params.updelay) {
>- pr_debug("Initial state of slave_dev is BOND_LINK_BACK\n");
>- new_slave->link = BOND_LINK_BACK;
>- new_slave->delay = bond->params.updelay;
>+ if (bond->params.miimon) {
>+ if (bond_check_dev_link(bond, slave_dev, 0) == BMSR_LSTATUS) {
>+ if (bond->params.updelay) {
>+ new_slave->link = BOND_LINK_BACK;
>+ new_slave->delay = bond->params.updelay;
>+ } else {
>+ new_slave->link = BOND_LINK_UP;
>+ }
> } else {
>- pr_debug("Initial state of slave_dev is BOND_LINK_UP\n");
>- new_slave->link = BOND_LINK_UP;
>+ new_slave->link = BOND_LINK_DOWN;
> }
>- new_slave->jiffies = jiffies;
>+ } else if (bond->params.arp_interval) {
>+ new_slave->link = (netif_carrier_ok(slave_dev) ?
>+ BOND_LINK_UP : BOND_LINK_DOWN);
> } else {
>- pr_debug("Initial state of slave_dev is BOND_LINK_DOWN\n");
>- new_slave->link = BOND_LINK_DOWN;
>+ new_slave->link = BOND_LINK_UP;
> }
>
>+ if (new_slave->link != BOND_LINK_DOWN)
>+ new_slave->jiffies = jiffies;
>+ pr_debug("Initial state of slave_dev is BOND_LINK_%s\n",
>+ new_slave->link == BOND_LINK_DOWN ? "DOWN" :
>+ (new_slave->link == BOND_LINK_UP ? "UP" : "BACK"));
>+
> bond_update_speed_duplex(new_slave);
>
> if (USES_PRIMARY(bond->params.mode) && bond->params.primary[0]) {
>--
>1.7.7
>
^ permalink raw reply
* Re: [PATCH net-next] tcp: avoid expensive pskb_expand_head() calls
From: Eric Dumazet @ 2012-04-18 17:40 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4F8EFA24.8020909@hp.com>
On Wed, 2012-04-18 at 10:30 -0700, Rick Jones wrote:
> I was thinking more about the race if any between the ACK for the last
> byte of the 64 KB skb and the transmit completion processing freeing it
> in the driver. But that may be moot.
>
No race, its done with atomic operations.
> >
> > # perf stat -r 5 -d -d -o RES.before taskset 1 netperf -H 192.168.99.1 -l 20
>
> I'm still learning about perf, and the manpage I have for it does not
> discuss the -d option but is that doing system wide, or only in the
> context of the netperf process?
In fact I used -a option and forgot to copy it in the mail I sent
perf stat -h
usage: perf stat [<options>] [<command>]
-e, --event <event> event selector. use 'perf list' to list available events
--filter <filter>
event filter
-i, --no-inherit child tasks do not inherit counters
-p, --pid <pid> stat events on existing process id
-t, --tid <tid> stat events on existing thread id
-a, --all-cpus system-wide collection from all CPUs
-g, --group put the counters into a counter group
-c, --scale scale/normalize counters
-v, --verbose be more verbose (show counter open errors, etc)
-r, --repeat <n> repeat command and print average + stddev (max: 100)
-n, --null null run - dont start any counters
-d, --detailed detailed run - start a lot of events
-S, --sync call sync() before starting a run
-B, --big-num print large numbers with thousands' separators
-C, --cpu <cpu> list of cpus to monitor in system-wide
-A, --no-aggr disable CPU count aggregation
-x, --field-separator <separator>
print counts with custom separator
-G, --cgroup <name> monitor event in cgroup name only
-o, --output <file> output file name
--append append to the output file
--log-fd <n> log output to fd, instead of stderr
^ permalink raw reply
* Re: [patch] Fix handling of overlength pathname in AF_UNIX sun_path
From: David Miller @ 2012-04-18 17:31 UTC (permalink / raw)
To: carlos-v2tUB8YBRSi3e3T8WW9gsA
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA,
penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp,
linux-api-u79uwXL29TY76Z2rM5mHXA, yoshfuji-VfPWfsRibaP+Ru+s062T9g,
jengelh-nopoi9nDyk+ELgA04lAiVw, w,
alan-qBU/x9rampVanCEyBjwyrvXRex20P6io
In-Reply-To: <CADZpyixnQMM5WFWLyvEQ=D-tvrqFGe4PC5WdUzxVtdL96NODJQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: "Carlos O'Donell" <carlos-v2tUB8YBRSi3e3T8WW9gsA@public.gmane.org>
Date: Wed, 18 Apr 2012 08:57:58 -0400
> In summary your opinion is that the API has and always will allow up
> to 108 chars to be used in sun_path?
Yes.
> In which case I will talk to the Austin group to get a good example
> added to POSIX showing safe usage.
Why would you add language to POSIX for Linux specific behavior?
Just curious :-)
^ permalink raw reply
* Re: [PATCH net-next] tcp: avoid expensive pskb_expand_head() calls
From: Rick Jones @ 2012-04-18 17:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1334769375.2472.310.camel@edumazet-glaptop>
On 04/18/2012 10:16 AM, Eric Dumazet wrote:
> On Wed, 2012-04-18 at 10:00 -0700, Rick Jones wrote:
>
>> Is the issue completely sent, or transmit completion processed? I'd
>> think it is time to the latter that matters (and includes the former) yes?
>>
>
> I dont know. Fact is we process ACKs before clone skb is freed by TX
> completion.
>
>> Does the ixgbe driver do transmit completions first when it gets a
>> receive interrupt, or is there still the chance that the receipt of the
>> last ACK for the 64KB skb will hit TCP before the driver has done the
>> free? (Or does that not matter?)
>
> It does transmit completions first, but that doesnt matter, since we
> receive ACK before skb could be drained by NIC and returned to driver
> for TX completion.
I was thinking more about the race if any between the ACK for the last
byte of the 64 KB skb and the transmit completion processing freeing it
in the driver. But that may be moot.
>>> Performance results on my Q6600 cpu and 82599EB 10-Gigabit card :
>>> About 3% less cpu used for same workload (single netperf TCP_STREAM),
>>> bounded by x4 PCI-e slots (4660 Mbits).
>>
>> Three percent less or three percentage points less? Including the
>> details of the netperf-reported service demand would make that clear.
>
> netperf results are not precise enough, since my setup is limited by PCI
> bandwidth. here are the "perf stat" ones
I'm confused - Netperf's CPU utilization measurements (-c -C) and by
extension service demand calculation should be able to see an overall
three percentage point change in CPU util, even a three percent one.
>
> Maybe someone can run the test on 20Gb/40Gb links, and NUMA machine.
>
> Before patch :
>
> # perf stat -r 5 -d -d -o RES.before taskset 1 netperf -H 192.168.99.1 -l 20
I'm still learning about perf, and the manpage I have for it does not
discuss the -d option but is that doing system wide, or only in the
context of the netperf process?
rick
^ permalink raw reply
* Re: tg3: Occassional death on 3.3
From: Ilia Mirkin @ 2012-04-18 17:30 UTC (permalink / raw)
To: Matt Carlson; +Cc: Michael Chan, netdev
In-Reply-To: <20120418171959.GA4823@mcarlson.broadcom.com>
On Wed, Apr 18, 2012 at 1:19 PM, Matt Carlson <mcarlson@broadcom.com> wrote:
> On Tue, Apr 17, 2012 at 05:55:11PM -0700, Matt Carlson wrote:
>> On Tue, Apr 17, 2012 at 08:22:31PM -0400, Ilia Mirkin wrote:
>> > Hello,
>> >
>> > I'm observing an issue where it appears that tg3 gets wedged into a
>> > bad state every so often, and never recovers. Doing a sequence of
>> >
>> > ifconfig eth0 down
>> > rmmod broadcom
>> > rmmod tg3
>> >
>> > modprobe broadcom
>> > modprobe tg3
>> >
>> > Makes everything work again. The card I have:
>> >
>> > 03:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink
>> > BCM57788 Gigabit Ethernet PCIe [14e4:1691] (rev 01)
>> > Subsystem: Dell XPS 8300 [1028:04aa]
>> > Flags: bus master, fast devsel, latency 0, IRQ 45
>> > Memory at fb100000 (64-bit, non-prefetchable) [size=64K]
>> > Capabilities: [48] Power Management version 3
>> > Capabilities: [60] Vendor Specific Information: Len=6c <?>
>> > Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
>> > Capabilities: [cc] Express Endpoint, MSI 00
>> > Capabilities: [100] Advanced Error Reporting
>> > Capabilities: [13c] Virtual Channel
>> > Capabilities: [160] Device Serial Number [the mac address]
>> > Capabilities: [16c] Power Budgeting <?>
>> > Kernel driver in use: tg3
>> > Kernel modules: tg3
>> >
>> > I'm attaching the log for the full data dump, since my mailer will
>> > wrap it horribly otherwise, but the interesting lines are:
>> >
>> > [2234380.228971] tg3 0000:03:00.0: eth0: transmit timed out, resetting
>> > ... some kind of data dump ...
>> > [2234382.216682] tg3 0000:03:00.0: eth0: 0: Host status block
>> > [00000001:00000080:(0000:01ef:0000):(01ef:00b2)]
>> > [2234382.216685] tg3 0000:03:00.0: eth0: 0: NAPI info
>> > [00000080:00000080:(00cb:00b2:01ff):01ef:(00b7:0000:0000:0000)]
>> > [2234382.319550] tg3 0000:03:00.0: tg3_stop_block timed out, ofs=1400
>> > enable_bit=2
>> > [2234382.421931] tg3 0000:03:00.0: tg3_stop_block timed out, ofs=c00
>> > enable_bit=2
>> > [2234382.427199] tg3 0000:03:00.0: eth0: Link is down
>> > [2234382.438168] tg3 0000:03:00.0: eth0: Link is down
>> >
>> > Any further attempts to use the NIC, like ifconfig down/up result in a
>> > similar error log sequence happening. Also, while it's happening, the
>> > computer feels extremely laggy for a short period of time (~1s),
>> > leading me to believe it's doing an uninterruptible sleep of some kind
>> > going on.
>> >
>> > This has happened twice, and at least the second time, there was no
>> > unusual traffic on the network. It's linked at 100M, and was probably
>> > doing 10K/s at most when the error happened. If this is insufficient
>> > information, please let me know what I should collect next time this
>> > might happen.
>> >
>> > Thanks,
>>
>> Thanks for the report Ilia. I'm guessing the lag is coming from the
>> driver as it logs the register dump to the syslog.
>>
>> The register dump shows that interrupts are enabled, but the tag value in
>> the interrupt mailbox register doesn't match the value in the status block
>> or the driver's private tag value. I'll see where that leads me.
>
> O.K. The interrupt mailbox issue I mentioned above can happen when in
> one-shot MSI mode, but it still smells strange. If the tag stored in
> the device structure matches the tag value in the status block, there
> should be no more work to do. In that case, the driver writes the new
> tag to the interrupt mailbox register.
>
> You may be encountering some type of hardware problem. PCIe register
> 0x104 is the Uncorrectable Error Status register. This register shows
> that the "Unsupported Request Error Status" bit is set. This definitely
> shouldn't happen.
>
> Do you know if there are any firmware updates available for your system?
>
I just checked on Dell's website, and I'm pretty sure I have the
latest BIOS. I'll double-check later, but the website says version
A06, as does my dmidecode. So unless they have multiple releases with
the same version number... :) In case it's of interest, the system is
a i7-2600 CPU, 18G of RAM (memtested).
Are there some PCI(e) debug options I should be turning on to perhaps
get a better picture of what's going on?
^ permalink raw reply
* Re: [PATCH 3/3] ehea: do not dereference possible NULL port
From: David Miller @ 2012-04-18 17:28 UTC (permalink / raw)
To: cascardo; +Cc: netdev, joe
In-Reply-To: <20120418124252.GA2455@oc1711230544.ibm.com>
From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Date: Wed, 18 Apr 2012 09:42:52 -0300
> However, at first, I suspected this interrupt may have come from some
> other port from ehca, for example, considering a possible firmware bug.
> After more investigation, I found out that the real problem was some
> physical ports in some odd states, that caused the IRQs before the ports
> were enabled. Note that this is not really supposed to happen.
It doesn't matter how it happens from the hardware side.
What matters is that you should not register the IRQ handler
at all until all the datastructures are properly setup.
^ permalink raw reply
* Re: pull request: batman-adv 2012-04-18
From: David Miller @ 2012-04-18 17:22 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1334743210-12338-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <ordex@autistici.org>
Date: Wed, 18 Apr 2012 11:59:57 +0200
> this is the fixed version of my previous pull request (issued on 2012-04-17).
> In this patchset the issues you reported have been fixed; moreover I'm
> also including two new patches (1/13 and 2/13) which are respectively:
>
> 1/13) a fix for Al Viro's report about the missing htons()
> 2/13) a fix for a wrongly duplicated line in a comment
>
> The following changes since commit ecffe75f934b4e3c5301fe5db278068e0efb0d6b:
>
> hippi: fix printk format in rrunner.c (2012-04-16 23:48:38 -0400)
>
> are available in the git repository at:
>
> git://git.open-mesh.org/linux-merge.git tags/batman-adv-for-davem
This looks a lot better, pulled, thanks!
^ permalink raw reply
* RE: ethtool enhancement proposal
From: Yaniv Rosner @ 2012-04-18 17:20 UTC (permalink / raw)
To: Stuart Hodgson; +Cc: netdev@vger.kernel.org, Ben Hutchings
In-Reply-To: <1334765718.2426.14.camel@bwh-desktop.uk.solarflarecom.com>
> On Wed, 2012-04-18 at 13:05 +0000, Yaniv Rosner wrote:
> > Hi Ben,
> > I want to propose new enhancement for the ethtool to display the
> > content of attached SFP+ module.
> > The format should be similar to the "-e" option, and optionally parse
> > it's content based on SFF-8472.
> > Please let me know what you think.
>
> Stuart Hodgson is working on something like this, though parsing is
> unconditional. I thought he had already posted a patch to netdev, but I
> can't see it in the archive.
>
Stuart,
Do you have an ETA for this feature ?
Yaniv
> We discussed the different module formats and came to the conclusion
> that:
>
> - Most module types in current use have a 256-byte EEPROM, format
> defined in SFF-8079.
> - SFF-8472 specifies two 256-byte EEPROMs/register files, the first
> identical to SFF-8079 and the second carrying diagnostic information.
> - The ETHTOOL_GMODULE{EEPROM,INFO} commands should effectively
> concatenate the two.
>
> The current Solarflare controller firmware only provides access to the
> SFF-8079 EEPROM on SFP+ modules, so Stuart's code does not cover the
> additional diagnostic information. But that should be easy to add on
> top.
>
> Ben.
>
> --
> Ben Hutchings, Staff Engineer, Solarflare
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
^ permalink raw reply
* Re: tg3: Occassional death on 3.3
From: Matt Carlson @ 2012-04-18 17:19 UTC (permalink / raw)
To: Matt Carlson; +Cc: Ilia Mirkin, Michael Chan, netdev
In-Reply-To: <20120418005511.GA2944@mcarlson.broadcom.com>
On Tue, Apr 17, 2012 at 05:55:11PM -0700, Matt Carlson wrote:
> On Tue, Apr 17, 2012 at 08:22:31PM -0400, Ilia Mirkin wrote:
> > Hello,
> >
> > I'm observing an issue where it appears that tg3 gets wedged into a
> > bad state every so often, and never recovers. Doing a sequence of
> >
> > ifconfig eth0 down
> > rmmod broadcom
> > rmmod tg3
> >
> > modprobe broadcom
> > modprobe tg3
> >
> > Makes everything work again. The card I have:
> >
> > 03:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink
> > BCM57788 Gigabit Ethernet PCIe [14e4:1691] (rev 01)
> > Subsystem: Dell XPS 8300 [1028:04aa]
> > Flags: bus master, fast devsel, latency 0, IRQ 45
> > Memory at fb100000 (64-bit, non-prefetchable) [size=64K]
> > Capabilities: [48] Power Management version 3
> > Capabilities: [60] Vendor Specific Information: Len=6c <?>
> > Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
> > Capabilities: [cc] Express Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Capabilities: [13c] Virtual Channel
> > Capabilities: [160] Device Serial Number [the mac address]
> > Capabilities: [16c] Power Budgeting <?>
> > Kernel driver in use: tg3
> > Kernel modules: tg3
> >
> > I'm attaching the log for the full data dump, since my mailer will
> > wrap it horribly otherwise, but the interesting lines are:
> >
> > [2234380.228971] tg3 0000:03:00.0: eth0: transmit timed out, resetting
> > ... some kind of data dump ...
> > [2234382.216682] tg3 0000:03:00.0: eth0: 0: Host status block
> > [00000001:00000080:(0000:01ef:0000):(01ef:00b2)]
> > [2234382.216685] tg3 0000:03:00.0: eth0: 0: NAPI info
> > [00000080:00000080:(00cb:00b2:01ff):01ef:(00b7:0000:0000:0000)]
> > [2234382.319550] tg3 0000:03:00.0: tg3_stop_block timed out, ofs=1400
> > enable_bit=2
> > [2234382.421931] tg3 0000:03:00.0: tg3_stop_block timed out, ofs=c00
> > enable_bit=2
> > [2234382.427199] tg3 0000:03:00.0: eth0: Link is down
> > [2234382.438168] tg3 0000:03:00.0: eth0: Link is down
> >
> > Any further attempts to use the NIC, like ifconfig down/up result in a
> > similar error log sequence happening. Also, while it's happening, the
> > computer feels extremely laggy for a short period of time (~1s),
> > leading me to believe it's doing an uninterruptible sleep of some kind
> > going on.
> >
> > This has happened twice, and at least the second time, there was no
> > unusual traffic on the network. It's linked at 100M, and was probably
> > doing 10K/s at most when the error happened. If this is insufficient
> > information, please let me know what I should collect next time this
> > might happen.
> >
> > Thanks,
>
> Thanks for the report Ilia. I'm guessing the lag is coming from the
> driver as it logs the register dump to the syslog.
>
> The register dump shows that interrupts are enabled, but the tag value in
> the interrupt mailbox register doesn't match the value in the status block
> or the driver's private tag value. I'll see where that leads me.
O.K. The interrupt mailbox issue I mentioned above can happen when in
one-shot MSI mode, but it still smells strange. If the tag stored in
the device structure matches the tag value in the status block, there
should be no more work to do. In that case, the driver writes the new
tag to the interrupt mailbox register.
You may be encountering some type of hardware problem. PCIe register
0x104 is the Uncorrectable Error Status register. This register shows
that the "Unsupported Request Error Status" bit is set. This definitely
shouldn't happen.
Do you know if there are any firmware updates available for your system?
^ permalink raw reply
* Re: [PATCH net-next] tcp: avoid expensive pskb_expand_head() calls
From: Eric Dumazet @ 2012-04-18 17:16 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4F8EF317.10504@hp.com>
On Wed, 2012-04-18 at 10:00 -0700, Rick Jones wrote:
> Is the issue completely sent, or transmit completion processed? I'd
> think it is time to the latter that matters (and includes the former) yes?
>
I dont know. Fact is we process ACKs before clone skb is freed by TX
completion.
> Does the ixgbe driver do transmit completions first when it gets a
> receive interrupt, or is there still the chance that the receipt of the
> last ACK for the 64KB skb will hit TCP before the driver has done the
> free? (Or does that not matter?)
It does transmit completions first, but that doesnt matter, since we
receive ACK before skb could be drained by NIC and returned to driver
for TX completion.
>
> > Performance results on my Q6600 cpu and 82599EB 10-Gigabit card :
> > About 3% less cpu used for same workload (single netperf TCP_STREAM),
> > bounded by x4 PCI-e slots (4660 Mbits).
>
> Three percent less or three percentage points less? Including the
> details of the netperf-reported service demand would make that clear.
netperf results are not precise enough, since my setup is limited by PCI
bandwidth. here are the "perf stat" ones
Maybe someone can run the test on 20Gb/40Gb links, and NUMA machine.
Before patch :
# perf stat -r 5 -d -d -o RES.before taskset 1 netperf -H 192.168.99.1 -l 20
Performance counter stats for 'taskset 1 netperf -H 192.168.99.1 -l 20' (5 runs):
6252,882411 task-clock # 0,312 CPUs utilized ( +- 0,51% )
5 988 context-switches # 0,958 K/sec ( +- 0,34% )
2 CPU-migrations # 0,000 K/sec ( +- 15,31% )
389 page-faults # 0,062 K/sec
9 938 280 877 cycles # 1,589 GHz ( +- 0,55% ) [21,19%]
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
11 709 374 305 instructions # 1,18 insns per cycle ( +- 0,28% ) [21,32%]
1 026 659 544 branches # 164,190 M/sec ( +- 0,40% ) [21,49%]
10 898 375 branch-misses # 1,06% of all branches ( +- 1,87% ) [21,54%]
5 238 382 991 L1-dcache-loads # 837,755 M/sec ( +- 0,21% ) [14,26%]
1 117 076 847 L1-dcache-load-misses # 21,32% of all L1-dcache hits ( +- 0,49% ) [14,19%]
166 208 073 LLC-loads # 26,581 M/sec ( +- 0,88% ) [14,33%]
3 220 627 LLC-load-misses # 1,94% of all LL-cache hits ( +- 2,39% ) [14,31%]
9 470 544 759 L1-icache-loads # 1514,589 M/sec ( +- 0,44% ) [14,41%]
23 602 610 L1-icache-load-misses # 0,25% of all L1-icache hits ( +- 3,10% ) [14,49%]
5 241 137 739 dTLB-loads # 838,195 M/sec ( +- 0,18% ) [14,20%]
4 970 360 dTLB-load-misses # 0,09% of all dTLB cache hits ( +- 1,01% ) [14,47%]
11 720 311 101 iTLB-loads # 1874,385 M/sec ( +- 0,34% ) [21,33%]
587 825 iTLB-load-misses # 0,01% of all iTLB cache hits ( +- 31,06% ) [21,52%]
20,018804246 seconds time elapsed ( +- 0,00% )
After patch :
# perf stat -r 5 -d -d -o RES.after taskset 1 netperf -H 192.168.99.1 -l 20
Performance counter stats for 'taskset 1 netperf -H 192.168.99.1 -l 20' (5 runs):
6061,208375 task-clock # 0,303 CPUs utilized ( +- 0,18% )
6 032 context-switches # 0,995 K/sec ( +- 0,22% )
2 CPU-migrations # 0,000 K/sec ( +- 52,44% )
390 page-faults # 0,064 K/sec ( +- 0,05% )
9 623 179 185 cycles # 1,588 GHz ( +- 0,16% ) [21,33%]
<not supported> stalled-cycles-frontend
<not supported> stalled-cycles-backend
11 724 650 132 instructions # 1,22 insns per cycle ( +- 0,22% ) [21,52%]
1 025 017 197 branches # 169,111 M/sec ( +- 0,29% ) [21,75%]
10 464 785 branch-misses # 1,02% of all branches ( +- 1,78% ) [21,82%]
5 230 299 185 L1-dcache-loads # 862,914 M/sec ( +- 0,20% ) [14,55%]
1 109 236 741 L1-dcache-load-misses # 21,21% of all L1-dcache hits ( +- 0,59% ) [14,59%]
161 721 826 LLC-loads # 26,681 M/sec ( +- 0,58% ) [14,25%]
2 974 990 LLC-load-misses # 1,84% of all LL-cache hits ( +- 0,95% ) [14,13%]
9 233 690 637 L1-icache-loads # 1523,408 M/sec ( +- 0,24% ) [14,14%]
17 177 769 L1-icache-load-misses # 0,19% of all L1-icache hits ( +- 0,69% ) [14,05%]
5 218 114 832 dTLB-loads # 860,903 M/sec ( +- 0,12% ) [14,23%]
4 980 060 dTLB-load-misses # 0,10% of all dTLB cache hits ( +- 1,23% ) [14,33%]
11 743 563 935 iTLB-loads # 1937,495 M/sec ( +- 0,13% ) [21,38%]
959 598 iTLB-load-misses # 0,01% of all iTLB cache hits ( +- 24,72% ) [21,33%]
20,019067285 seconds time elapsed ( +- 0,00% )
^ permalink raw reply
* Re: [PATCH] net: filter: Just In Time compiler for sparc
From: Jan Ceuleers @ 2012-04-18 16:39 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sparclinux
In-Reply-To: <20120417.154222.453472384916762847.davem@davemloft.net>
David Miller wrote:
> From: Jan Ceuleers<jan.ceuleers@computer.org>
> Date: Tue, 17 Apr 2012 19:02:22 +0200
>
>> There is inconsistent spacing in multiple places; a few examples shown
>> above.
>
> You've never written sparc assembler before, obviously.
>
> The extra space after the tabs is intentional, and indicates
> a branch delay slot instruction.
Indeed I haven't. I've written assembly for many processors, both RISC
and CISC, but not SPARC. And I've never come across this convention, so
thanks for educating and indulging me.
Jan
^ permalink raw reply
* Re: [PATCH] memcg/tcp: fix warning caused b res->usage go to negative.
From: Glauber Costa @ 2012-04-18 16:32 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: netdev, David Miller, Andrew Morton
In-Reply-To: <4F8E752E.8040906@jp.fujitsu.com>
On 04/18/2012 05:02 AM, KAMEZAWA Hiroyuki wrote:
> (2012/04/14 2:33), Glauber Costa wrote:
>
>> On 04/09/2012 11:37 PM, KAMEZAWA Hiroyuki wrote:
>>> (2012/04/07 0:49), Glauber Costa wrote:
>>>
>>>> On 03/30/2012 05:44 AM, KAMEZAWA Hiroyuki wrote:
>>>>> Maybe what we can do before lsf/mm summit will be this (avoid warning.)
>>>>> This patch is onto linus's git tree. Patch description is updated.
>>>>>
>>>>> Thanks.
>>>>> -Kame
>>>>> ==
>>>>> From 4ab80f84bbcb02a790342426c1de84aeb17fcbe9 Mon Sep 17 00:00:00 2001
>>>>> From: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com>
>>>>> Date: Thu, 29 Mar 2012 14:59:04 +0900
>>>>> Subject: [PATCH] memcg/tcp: fix warning caused b res->usage go to negative.
>>>>>
>>>>> tcp memcontrol starts accouting after res->limit is set. So, if a sockets
>>>>> starts before setting res->limit, there are already used resource.
>>>>> At setting res->limit, accounting starts. The resource will be uncharged
>>>>> and make res_counter below 0 because they are not charged.
>>>>> This causes warning.
>>>>>
>>>>
>>>> Kame,
>>>>
>>>> Please test the following patch and see if it fixes your problems (I
>>>> tested locally, and it triggers me no warnings running the test script
>>>> you provided + an inbound scp -r copy of an iso directory from a remote
>>>> machine)
>>>>
>>>> When you are reviewing, keep in mind that we're likely to have the same
>>>> problems with slab jump labels - since the slab pages will outlive the
>>>> cgroup as well, and it might be worthy to keep this in mind, and provide
>>>> a central point for the jump labels to be set of on cgroup destruction.
>>>>
>>>
>>>
>>> Hm. What happens in following sequence ?
>>>
>>> 1. a memcg is created
>>> 2. put a task into the memcg, start tcp steam
>>> 3. set tcp memory limit
>>>
>>> The resource used between 2 and 3 will cause the problem finally.
>>>
>>> Then, Dave's request
>>> ==
>>> You must either:
>>>
>>> 1) Integrate the socket's existing usage when the limit is set.
>>>
>>> 2) Avoid accounting completely for a socket that started before
>>> the limit was set.
>>> ==
>>> are not satisfied. So, we need to have a state per sockets, it's accounted
>>> or not. I'll look into this problem again, today.
>>>
>>
>> Kame,
>>
>> Let me know what you think of the attached fix.
>> I still need to compile test it in other configs to be sure it doesn't
>> break, etc. But let's agree on it first.
>
>
>
>> Subject: [PATCH] decrement static keys on real destroy time
>>
>> We call the destroy function when a cgroup starts to be removed,
>> such as by a rmdir event.
>>
>> However, because of our reference counters, some objects are still
>> inflight. Right now, we are decrementing the static_keys at destroy()
>> time, meaning that if we get rid of the last static_key reference,
>> some objects will still have charges, but the code to properly
>> uncharge them won't be run.
>>
>> This becomes a problem specially if it is ever enabled again, because
>> now new charges will be added to the staled charges making keeping
>> it pretty much impossible.
>>
>> We just need to be careful with the static branch activation:
>> since there is no particular preferred order of their activation,
>> we need to make sure that we only start using it after all
>> call sites are active. This is achieved by having a per-memcg
>> flag that is only updated after static_key_slow_inc() returns.
>> At this time, we are sure all sites are active.
>>
>> This is made per-memcg, not global, for a reason:
>> it also has the effect of making socket accounting more
>> consistent. The first memcg to be limited will trigger static_key()
>> activation, therefore, accounting. But all the others will then be
>> accounted no matter what. After this patch, only limited memcgs
>> will have its sockets accounted.
>>
>> [v2: changed a tcp limited flag for a generic proto limited flag ]
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> ---
>> include/net/sock.h | 1 +
>> mm/memcontrol.c | 20 ++++++++++++++++++--
>> net/ipv4/tcp_memcontrol.c | 12 ++++++------
>> 3 files changed, 25 insertions(+), 8 deletions(-)
>>
>> diff --git a/include/net/sock.h b/include/net/sock.h
>> index b3ebe6b..f35ff7d 100644
>> --- a/include/net/sock.h
>> +++ b/include/net/sock.h
>> @@ -913,6 +913,7 @@ struct cg_proto {
>> struct percpu_counter *sockets_allocated; /* Current number of sockets. */
>> int *memory_pressure;
>> long *sysctl_mem;
>> + bool limited;
>
>
> please add comment somewhere. Hmm, 'limited' is good name ?
I changed it to two fields in the version I am preparing:
accounted - means it was ever triggered
account - means we are currently limited.
It also addresses the problem you mention bellow.
>> /*
>> * memcg field is used to find which memcg we belong directly
>> * Each memcg struct can hold more than one cg_proto, so container_of
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 02b01d2..61f2d31 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -404,6 +404,7 @@ void sock_update_memcg(struct sock *sk)
>> {
>> if (mem_cgroup_sockets_enabled) {
>> struct mem_cgroup *memcg;
>> + struct cg_proto *cg_proto;
>>
>> BUG_ON(!sk->sk_prot->proto_cgroup);
>>
>> @@ -423,9 +424,10 @@ void sock_update_memcg(struct sock *sk)
>>
>> rcu_read_lock();
>> memcg = mem_cgroup_from_task(current);
>> - if (!mem_cgroup_is_root(memcg)) {
>> + cg_proto = sk->sk_prot->proto_cgroup(memcg);
>> + if (!mem_cgroup_is_root(memcg)&& cg_proto->limited) {
>> mem_cgroup_get(memcg);
>> - sk->sk_cgrp = sk->sk_prot->proto_cgroup(memcg);
>> + sk->sk_cgrp = cg_proto;
>> }
>
>
>
> Ok, then, sk->sk_cgroup is set only after jump_label is enabled and
> its memcg has limitation.
>
>
>
> Why we can reset this to be false ? disarm_static_keys() will not work
> at destroy()....
This is solved by the two booleans. What I want, is achieve consistency,
and account only when turned on.
Account after the first is turned on - which is what we have now - is
way more confusing.
>
>> + else if (val != RESOURCE_MAX&& !cg_proto->limited) {
>> static_key_slow_inc(&memcg_socket_limit_enabled);
>> + cg_proto->limited = true;
>> + }
>>
>
> Hmm. don't we need any mutex ?
I thought no.
But now that you pointed this out, I gave it some time...
What we can't do, is take a mutex in sock_update_memcg(). It will kill us.
I think we only need to protect against two processes writing to the
same file (tcp.limit_in_bytes) at the same time.
We don't hold cgroup_mutex for that, so we need locking only if the vfs
does not protect us against this concurrency. I will check that to be sure.
^ permalink raw reply
* Re: [PATCH v4 3/3] netdev/of/phy: Add MDIO bus multiplexer driven by GPIO lines.
From: David Daney @ 2012-04-18 16:24 UTC (permalink / raw)
To: David Miller
Cc: ddaney.cavm, grant.likely, rob.herring, devicetree-discuss,
netdev, linux-kernel, linux-mips, afleming, galak
In-Reply-To: <20120417.225308.1588669089502246200.davem@davemloft.net>
On 04/17/2012 07:53 PM, David Miller wrote:
> From: David Daney<ddaney.cavm@gmail.com>
> Date: Tue, 17 Apr 2012 10:32:46 -0700
>
>> From: David Daney<david.daney@cavium.com>
>>
>> The GPIO pins select which sub bus is connected to the master.
>>
>> Initially tested with an sn74cbtlv3253 switch device wired into the
>> MDIO bus.
>>
>> Signed-off-by: David Daney<david.daney@cavium.com>
>
> Are you sure the Kconfig dependencies are sufficient? This code seems
> to depend upon OF, and in particular the OF_MDIO stuff.
>
You are correct. Should I:
A) Create a patch to fix the dependencies it on top of the previous set?
B) Regenerate the entire set with said patch rolled in?
Thanks,
David Daney
^ permalink raw reply
* Re: ethtool enhancement proposal
From: Ben Hutchings @ 2012-04-18 16:15 UTC (permalink / raw)
To: Yaniv Rosner; +Cc: netdev@vger.kernel.org, Stuart Hodgson
In-Reply-To: <A6AA2EF896BED345B0F23520D832A4B10583EC@SJEXCHMB05.corp.ad.broadcom.com>
On Wed, 2012-04-18 at 13:05 +0000, Yaniv Rosner wrote:
> Hi Ben,
> I want to propose new enhancement for the ethtool to display the
> content of attached SFP+ module.
> The format should be similar to the "-e" option, and optionally parse
> it's content based on SFF-8472.
> Please let me know what you think.
Stuart Hodgson is working on something like this, though parsing is
unconditional. I thought he had already posted a patch to netdev, but I
can't see it in the archive.
We discussed the different module formats and came to the conclusion
that:
- Most module types in current use have a 256-byte EEPROM, format
defined in SFF-8079.
- SFF-8472 specifies two 256-byte EEPROMs/register files, the first
identical to SFF-8079 and the second carrying diagnostic information.
- The ETHTOOL_GMODULE{EEPROM,INFO} commands should effectively
concatenate the two.
The current Solarflare controller firmware only provides access to the
SFF-8079 EEPROM on SFP+ modules, so Stuart's code does not cover the
additional diagnostic information. But that should be easy to add on
top.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-next] tcp: avoid expensive pskb_expand_head() calls
From: Eric Dumazet @ 2012-04-18 15:49 UTC (permalink / raw)
To: David Miller
Cc: netdev, Tom Herbert, Neal Cardwell, Maciej Żenczykowski,
Yuchung Cheng
In-Reply-To: <1334698722.2472.71.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
While doing netperf sessions on 10Gb Intel nics (ixgbe), I noticed
unexpected profiling results, with pskb_expand_head() being in the top.
After further analysis, I found we hit badly page refcounts,
because when we transmit full size skb (64 KB), we can receive ACK for
the first segments of the frame while skb was not completely sent by
NIC.
It takes ~54 us to send a full TSO packet at 10Gb speed, but with a
close peer, we can receive TCP ACK in less than 50 us rtt.
This is also true on 1Gb links but we were limited by wire speed, not
cpu.
When we try to trim skb, tcp_trim_head() has to call pskb_expand_head(),
because the skb clone we did for transmit is still alive in TX ring
buffer.
pskb_expand_head() is really expensive : It has to make about 16+16
atomic operations on page refcounts, not counting the skb head
reallocation/copy. It increases chances of false sharing.
In fact, we dont really need to trim skb. This costly operation can be
delayed to the point it is really needed : Thats when a retransmit must
happen.
Most of the time, upcoming ACKS will ack the whole packet, and we can
free it with minimal cost (since clone was already freed by TX
completion)
Of course, this means we dont uncharge the acked part from socket limits
until retransmit, but this is hardly a concern with current autotuning
(around 4MB per socket)
Even with small cwnd limit, a single packet can not hold more than half
the window.
Performance results on my Q6600 cpu and 82599EB 10-Gigabit card :
About 3% less cpu used for same workload (single netperf TCP_STREAM),
bounded by x4 PCI-e slots (4660 Mbits).
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Maciej Żenczykowski <maze@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
---
include/net/tcp.h | 6 ++++--
net/ipv4/tcp_input.c | 24 +++++++++++++-----------
net/ipv4/tcp_output.c | 17 +++++++++++------
3 files changed, 28 insertions(+), 19 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index d5984e3..0f57706 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -477,7 +477,8 @@ extern int tcp_retransmit_skb(struct sock *, struct sk_buff *);
extern void tcp_retransmit_timer(struct sock *sk);
extern void tcp_xmit_retransmit_queue(struct sock *);
extern void tcp_simple_retransmit(struct sock *);
-extern int tcp_trim_head(struct sock *, struct sk_buff *, u32);
+extern void tcp_set_skb_tso_segs(const struct sock *sk, struct sk_buff *skb,
+ unsigned int mss_now);
extern int tcp_fragment(struct sock *, struct sk_buff *, u32, unsigned int);
extern void tcp_send_probe0(struct sock *);
@@ -640,7 +641,8 @@ struct tcp_skb_cb {
#if IS_ENABLED(CONFIG_IPV6)
struct inet6_skb_parm h6;
#endif
- } header; /* For incoming frames */
+ unsigned int offset_ack; /* part of acked data in this skb */
+ } header;
__u32 seq; /* Starting sequence number */
__u32 end_seq; /* SEQ + FIN + SYN + datalen */
__u32 when; /* used to compute rtt's */
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 99448f0..529740c 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3260,25 +3260,27 @@ static void tcp_rearm_rto(struct sock *sk)
}
}
-/* If we get here, the whole TSO packet has not been acked. */
+/* If we get here, the whole packet has not been acked.
+ * We used to call tcp_trim_head() to remove acked data from skb,
+ * but its expensive with TSO if our previous clone is still in flight.
+ * We thus maintain an offset_ack, and hope no pskb_expand_head()
+ * is needed until whole packet is acked by upcoming ACKs.
+ */
static u32 tcp_tso_acked(struct sock *sk, struct sk_buff *skb)
{
struct tcp_sock *tp = tcp_sk(sk);
- u32 packets_acked;
+ u32 prev_packets_acked;
BUG_ON(!after(TCP_SKB_CB(skb)->end_seq, tp->snd_una));
- packets_acked = tcp_skb_pcount(skb);
- if (tcp_trim_head(sk, skb, tp->snd_una - TCP_SKB_CB(skb)->seq))
- return 0;
- packets_acked -= tcp_skb_pcount(skb);
+ prev_packets_acked = tcp_skb_pcount(skb);
- if (packets_acked) {
- BUG_ON(tcp_skb_pcount(skb) == 0);
- BUG_ON(!before(TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq));
- }
+ TCP_SKB_CB(skb)->header.offset_ack = tp->snd_una - TCP_SKB_CB(skb)->seq;
+
+ if (tcp_skb_pcount(skb) > 1)
+ tcp_set_skb_tso_segs(sk, skb, tcp_skb_mss(skb));
- return packets_acked;
+ return prev_packets_acked - tcp_skb_pcount(skb);
}
/* Remove acknowledged frames from the retransmission queue. If our packet
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index de8790c..426b400 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -927,11 +927,15 @@ static void tcp_queue_skb(struct sock *sk, struct sk_buff *skb)
sk_mem_charge(sk, skb->truesize);
}
-/* Initialize TSO segments for a packet. */
-static void tcp_set_skb_tso_segs(const struct sock *sk, struct sk_buff *skb,
- unsigned int mss_now)
+/* Initialize TSO segments for a packet.
+ * Part of skb (offset_ack) might have been acked.
+ */
+void tcp_set_skb_tso_segs(const struct sock *sk, struct sk_buff *skb,
+ unsigned int mss_now)
{
- if (skb->len <= mss_now || !sk_can_gso(sk) ||
+ unsigned int len = skb->len - TCP_SKB_CB(skb)->header.offset_ack;
+
+ if (len <= mss_now || !sk_can_gso(sk) ||
skb->ip_summed == CHECKSUM_NONE) {
/* Avoid the costly divide in the normal
* non-TSO case.
@@ -940,7 +944,7 @@ static void tcp_set_skb_tso_segs(const struct sock *sk, struct sk_buff *skb,
skb_shinfo(skb)->gso_size = 0;
skb_shinfo(skb)->gso_type = 0;
} else {
- skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(skb->len, mss_now);
+ skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(len, mss_now);
skb_shinfo(skb)->gso_size = mss_now;
skb_shinfo(skb)->gso_type = sk->sk_gso_type;
}
@@ -1126,7 +1130,7 @@ static void __pskb_trim_head(struct sk_buff *skb, int len)
}
/* Remove acked data from a packet in the transmit queue. */
-int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
+static int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
{
if (skb_cloned(skb) && pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
return -ENOMEM;
@@ -1134,6 +1138,7 @@ int tcp_trim_head(struct sock *sk, struct sk_buff *skb, u32 len)
__pskb_trim_head(skb, len);
TCP_SKB_CB(skb)->seq += len;
+ TCP_SKB_CB(skb)->header.offset_ack = 0;
skb->ip_summed = CHECKSUM_PARTIAL;
skb->truesize -= len;
^ permalink raw reply related
* Re: [PATCH 4/4] net/l2tp: add support for L2TP over IPv6 UDP encap
From: James Chapman @ 2012-04-18 15:36 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: davem, netdev
In-Reply-To: <20120418134438.GA5162@kvack.org>
On 18/04/12 14:44, Benjamin LaHaise wrote:
> Now that encap_rcv() works on IPv6 UDP sockets, wire L2TP up to IPv6.
> Support has been tested with and without hardware offloading.
>
> Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
...
> diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
> index f6732b6..8cd5f4b 100644
> --- a/net/l2tp/l2tp_core.c
> +++ b/net/l2tp/l2tp_core.c
> @@ -53,6 +53,9 @@
> #include <net/inet_common.h>
> #include <net/xfrm.h>
> #include <net/protocol.h>
> +#include <net/inet6_connection_sock.h>
> +#include <net/inet_ecn.h>
> +#include <net/ip6_route.h>
>
> #include <asm/byteorder.h>
> #include <linux/atomic.h>
> @@ -446,21 +449,43 @@ static inline int l2tp_verify_udp_checksum(struct sock *sk,
> {
> struct udphdr *uh = udp_hdr(skb);
> u16 ulen = ntohs(uh->len);
> - struct inet_sock *inet;
> __wsum psum;
>
> - if (sk->sk_no_check || skb_csum_unnecessary(skb) || !uh->check)
> - return 0;
> -
> - inet = inet_sk(sk);
> - psum = csum_tcpudp_nofold(inet->inet_saddr, inet->inet_daddr, ulen,
> - IPPROTO_UDP, 0);
> -
> - if ((skb->ip_summed == CHECKSUM_COMPLETE) &&
> - !csum_fold(csum_add(psum, skb->csum)))
> + if (sk->sk_no_check || skb_csum_unnecessary(skb))
> return 0;
>
> - skb->csum = psum;
> +#if IS_ENABLED(CONFIG_IPV6)
> + if (sk->sk_family == PF_INET6) {
> + if (!uh->check) {
> + LIMIT_NETDEBUG(KERN_INFO "L2TP: IPv6: checksum is 0\n");
> + return 1;
> + }
> + if ((skb->ip_summed == CHECKSUM_COMPLETE) &&
> + !csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
> + &ipv6_hdr(skb)->daddr, ulen,
> + IPPROTO_UDP, skb->csum)) {
> + skb->ip_summed = CHECKSUM_UNNECESSARY;
> + return 0;
> + }
> + skb->csum = ~csum_unfold(csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
> + &ipv6_hdr(skb)->daddr,
> + skb->len, IPPROTO_UDP,
> + 0));
> + } else
> +#endif
> + {
> + struct inet_sock *inet;
> + if (!uh->check)
> + return 0;
> + inet = inet_sk(sk);
> + psum = csum_tcpudp_nofold(inet->inet_saddr, inet->inet_daddr,
> + ulen, IPPROTO_UDP, 0);
> +
> + if ((skb->ip_summed == CHECKSUM_COMPLETE) &&
> + !csum_fold(csum_add(psum, skb->csum)))
> + return 0;
> + skb->csum = psum;
> + }
>
> return __skb_checksum_complete(skb);
> }
I'm seeing UDP checksum errors with a loopback test. Regular
(non-loopback) sessions and loopback ipv4 sessions are fine. I retested
your previous patch and verified that it has the same problem. Although
loopback is a weird config, does it indicate a possible problem? Here is
the debug trace:
[ 223.260340] lo: hw csum failure
[ 223.260718] Pid: 1146, comm: pppd Not tainted 3.4.0-rc2+ #5
[ 223.261373] Call Trace:
[ 223.261840] [<c1247b55>] netdev_rx_csum_fault+0x29/0x30
[ 223.262467] [<c12430ac>] __skb_checksum_complete_head+0x42/0x57
[ 223.263159] [<d8a41230>] l2tp_udp_encap_recv+0x13a/0x413 [l2tp_core]
[ 223.263892] [<d8a78c46>] ? pppol2tp_recv+0x11e/0x11e [l2tp_ppp]
[ 223.265741] [<c12cb69f>] ? rcu_read_unlock+0x4d/0x4f
[ 223.266902] [<c12c0028>] ? addrconf_notify+0x5c4/0x7e2
[ 223.268066] [<c12cd2d6>] udpv6_queue_rcv_skb+0x4a/0x256
[ 223.269176] [<c12cd9c6>] __udp6_lib_rcv+0x2c8/0x400
[ 223.269733] [<c12cdb10>] udpv6_rcv+0x12/0x16
[ 223.270222] [<c12bb1d3>] ip6_input_finish+0x1be/0x346
[ 223.270793] [<c12bb015>] ? T.1206+0x4d/0x4d
[ 223.271270] [<c12bb393>] T.1207+0x38/0x3f
[ 223.271729] [<c12bafa1>] ? rcu_read_unlock+0x4f/0x4f
[ 223.272334] [<c12bb79e>] ip6_input+0x17/0x19
[ 223.272824] [<c12bb015>] ? T.1206+0x4d/0x4d
[ 223.273302] [<c12bafc5>] ip6_rcv_finish+0x24/0x27
[ 223.276246] [<c12bb393>] T.1207+0x38/0x3f
[ 223.276727] [<c12bb726>] ipv6_rcv+0x38c/0x3ed
[ 223.277242] [<c12bafa1>] ? rcu_read_unlock+0x4f/0x4f
[ 223.277833] [<c124b97b>] __netif_receive_skb+0x46c/0x4a7
[ 223.278459] [<c124ba54>] process_backlog+0x9e/0x16e
[ 223.279068] [<c124c26d>] net_rx_action+0x9d/0x1af
[ 223.279701] [<c102cadd>] __do_softirq+0xb1/0x17f
[ 223.280281] [<c102ca2c>] ? irq_enter+0x5d/0x5d
[ 223.280807] <IRQ> [<c122112d>] ? ppp_channel_push+0x62/0x93
[ 223.281489] [<c102c9a0>] ? _local_bh_enable_ip+0x8e/0xa6
[ 223.282406] [<c102c9c0>] ? local_bh_enable_ip+0x8/0xa
[ 223.283026] [<c12fe2d6>] ? _raw_spin_unlock_bh+0x25/0x28
[ 223.283655] [<c122112d>] ? ppp_channel_push+0x62/0x93
[ 223.284308] [<c1221200>] ? ppp_write+0xa2/0xac
[ 223.284855] [<c122115e>] ? ppp_channel_push+0x93/0x93
[ 223.285451] [<c10e0412>] ? vfs_write+0x80/0xde
[ 223.286059] [<c10e0d2a>] ? fget_light+0x2b/0x8f
[ 223.286593] [<c10e0507>] ? sys_write+0x3b/0x60
[ 223.287121] [<c130431f>] ? sysenter_do_call+0x12/0x38
--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development
^ permalink raw reply
* Re: net: Micrel KSZ8841/2 PCI Ethernet driver
From: Dan Carpenter @ 2012-04-18 14:51 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Tristram.Ha, netdev
In-Reply-To: <1334758394.3209.156.camel@deadeye>
On Wed, Apr 18, 2012 at 03:13:14PM +0100, Ben Hutchings wrote:
>
> The correct length is ETH_ALEN, as for the previous memcpy().
Thanks. I'll send a patch for that.
regards,
dan carpenter
^ permalink raw reply
* RE: [PATCH] net/hyperv: RX packets may keep on increasing although the NIC is down
From: Haiyang Zhang @ 2012-04-18 14:19 UTC (permalink / raw)
To: Wenqi Ma, netdev@vger.kernel.org; +Cc: davem@davemloft.net, KY Srinivasan
In-Reply-To: <1334757694-21745-1-git-send-email-wenqi_ma@trendmicro.com.cn>
> -----Original Message-----
> From: Haiyang Zhang
> Sent: Wednesday, April 18, 2012 10:11 AM
> To: 'Wenqi Ma'; netdev@vger.kernel.org
> Cc: davem@davemloft.net; KY Srinivasan
> Subject: RE: [PATCH] net/hyperv: RX packets may keep on increasing
> although the NIC is down
>
>
>
> > -----Original Message-----
> > From: Wenqi Ma [mailto:wenqi_ma@trendmicro.com.cn]
> > Sent: Wednesday, April 18, 2012 10:02 AM
> > To: netdev@vger.kernel.org
> > Cc: davem@davemloft.net; Haiyang Zhang; Wenqi Ma
> > Subject: [PATCH] net/hyperv: RX packets may keep on increasing although
> > the NIC is down
> >
> > Although the network interface is down, the RX packets number which
> > could be observed by ifconfig may keep on increasing.
> >
> > This is because the WORK scheduled in netvsc_set_multicast_list()
> > may be executed after netvsc_close(). That means the rndis filter
> > may be re-enabled by do_set_multicast() even if it was closed by
> > netvsc_close().
> >
> > By canceling possible WORK before close the rndis filter, the issue
> > could be never happened.
> >
> > Signed-off-by: Wenqi Ma <wenqi_ma@trendmicro.com.cn>
> > ---
> > drivers/net/hyperv/netvsc_drv.c | 32 +++++++++++++-------------------
> > 1 files changed, 13 insertions(+), 19 deletions(-)
>
> Thanks for patching it. I have some comments --
> The existing "struct set_multicast_work" is no longer in use, so it should be
> removed now.
> You should also add cancel_work into netvsc_change_mtu().
Also the patch subject should say what fixes/changes you made, not the bug behavior.
Recommend something like, "Adding cancellation to set promiscuous mode work".
Thanks,
- Haiyang
^ permalink raw reply
* re: net: Micrel KSZ8841/2 PCI Ethernet driver
From: Ben Hutchings @ 2012-04-18 14:13 UTC (permalink / raw)
To: Dan Carpenter; +Cc: Tristram.Ha, netdev
In-Reply-To: <20120418064723.GA12831@elgon.mountain>
On Wed, 2012-04-18 at 09:47 +0300, Dan Carpenter wrote:
> Hello Tristram,
>
> I was going through some old stuff and I had a question about ksz884x.c.
>
> The patch 8ca86fd83eae: "net: Micrel KSZ8841/2 PCI Ethernet driver"
> from Feb 8, 2010, leads to the following warning:
> drivers/net/ethernet/micrel/ksz884x.c:5678 netdev_set_mac_address()
> error: memcpy() 'mac->sa_data' too small (14 vs 32)
>
> 5663 static int netdev_set_mac_address(struct net_device *dev, void *addr)
> 5664 {
> 5665 struct dev_priv *priv = netdev_priv(dev);
> 5666 struct dev_info *hw_priv = priv->adapter;
> 5667 struct ksz_hw *hw = &hw_priv->hw;
> 5668 struct sockaddr *mac = addr;
> 5669 uint interrupt;
> 5670
> 5671 if (priv->port.first_port > 0)
> 5672 hw_del_addr(hw, dev->dev_addr);
> 5673 else {
> 5674 hw->mac_override = 1;
> 5675 memcpy(hw->override_addr, mac->sa_data, ETH_ALEN);
> 5676 }
> 5677
> 5678 memcpy(dev->dev_addr, mac->sa_data, MAX_ADDR_LEN);
> ^^^^^^^^^^^^
> This has only 14 bytes so we're copying bogus data from beyond the end
> of the struct into dev->dev_addr.
The correct length is ETH_ALEN, as for the previous memcpy().
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [PATCH] net/hyperv: RX packets may keep on increasing although the NIC is down
From: Haiyang Zhang @ 2012-04-18 14:10 UTC (permalink / raw)
To: Wenqi Ma, netdev@vger.kernel.org; +Cc: davem@davemloft.net, KY Srinivasan
In-Reply-To: <1334757694-21745-1-git-send-email-wenqi_ma@trendmicro.com.cn>
> -----Original Message-----
> From: Wenqi Ma [mailto:wenqi_ma@trendmicro.com.cn]
> Sent: Wednesday, April 18, 2012 10:02 AM
> To: netdev@vger.kernel.org
> Cc: davem@davemloft.net; Haiyang Zhang; Wenqi Ma
> Subject: [PATCH] net/hyperv: RX packets may keep on increasing although
> the NIC is down
>
> Although the network interface is down, the RX packets number which
> could be observed by ifconfig may keep on increasing.
>
> This is because the WORK scheduled in netvsc_set_multicast_list()
> may be executed after netvsc_close(). That means the rndis filter
> may be re-enabled by do_set_multicast() even if it was closed by
> netvsc_close().
>
> By canceling possible WORK before close the rndis filter, the issue
> could be never happened.
>
> Signed-off-by: Wenqi Ma <wenqi_ma@trendmicro.com.cn>
> ---
> drivers/net/hyperv/netvsc_drv.c | 32 +++++++++++++-------------------
> 1 files changed, 13 insertions(+), 19 deletions(-)
Thanks for patching it. I have some comments --
The existing "struct set_multicast_work" is no longer in use, so it should be removed now.
You should also add cancel_work into netvsc_change_mtu().
Thanks,
- Haiyang
^ permalink raw reply
* Re: [RFC PATCH 2/2] l2tp: Introduce L2TPv3 IP encapsulation support for IPv6
From: James Chapman @ 2012-04-18 13:56 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bcrl
In-Reply-To: <20120418.002820.1941255513481211357.davem@davemloft.net>
On 18/04/12 05:28, David Miller wrote:
> From: James Chapman <jchapman@katalix.com>
> Date: Tue, 17 Apr 2012 13:29:26 +0100
>
>> L2TPv3 defines an IP encapsulation packet format where data is carried
>> directly over IP (no UDP). The kernel already has support for L2TP IP
>> encapsulation over IPv4 (l2tp_ip). This patch introduces support for L2TP
>> IP encapsulation over IPv6.
>
> Either the ipv4 side should be changed to use ip4_datagram_connect()
> or the ipv6 side should duplicate just the parts of
> ip6_datagram_connect() it needs.
>
> Which is it? :-)
Ok, I'll add a patch to l2tp_ip to have it use ip4_datagram_connect(). :-)
^ permalink raw reply
* [PATCH 4/4] net/l2tp: add support for L2TP over IPv6 UDP encap
From: Benjamin LaHaise @ 2012-04-18 13:44 UTC (permalink / raw)
To: davem; +Cc: netdev, jchapman
Now that encap_rcv() works on IPv6 UDP sockets, wire L2TP up to IPv6.
Support has been tested with and without hardware offloading.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
---
include/linux/if_pppol2tp.h | 28 +++++++++++++-
include/linux/if_pppox.h | 12 ++++++
net/l2tp/l2tp_core.c | 89 +++++++++++++++++++++++++++++++++++++------
net/l2tp/l2tp_ppp.c | 42 ++++++++++++++++++++-
4 files changed, 157 insertions(+), 14 deletions(-)
diff --git a/include/linux/if_pppol2tp.h b/include/linux/if_pppol2tp.h
index 23cefa1..b477541 100644
--- a/include/linux/if_pppol2tp.h
+++ b/include/linux/if_pppol2tp.h
@@ -19,10 +19,11 @@
#ifdef __KERNEL__
#include <linux/in.h>
+#include <linux/in6.h>
#endif
/* Structure used to connect() the socket to a particular tunnel UDP
- * socket.
+ * socket over IPv4.
*/
struct pppol2tp_addr {
__kernel_pid_t pid; /* pid that owns the fd.
@@ -35,6 +36,20 @@ struct pppol2tp_addr {
__u16 d_tunnel, d_session; /* For sending outgoing packets */
};
+/* Structure used to connect() the socket to a particular tunnel UDP
+ * socket over IPv6.
+ */
+struct pppol2tpin6_addr {
+ __kernel_pid_t pid; /* pid that owns the fd.
+ * 0 => current */
+ int fd; /* FD of UDP socket to use */
+
+ __u16 s_tunnel, s_session; /* For matching incoming packets */
+ __u16 d_tunnel, d_session; /* For sending outgoing packets */
+
+ struct sockaddr_in6 addr; /* IP address and port to send to */
+};
+
/* The L2TPv3 protocol changes tunnel and session ids from 16 to 32
* bits. So we need a different sockaddr structure.
*/
@@ -49,6 +64,17 @@ struct pppol2tpv3_addr {
__u32 d_tunnel, d_session; /* For sending outgoing packets */
};
+struct pppol2tpv3in6_addr {
+ __kernel_pid_t pid; /* pid that owns the fd.
+ * 0 => current */
+ int fd; /* FD of UDP or IP socket to use */
+
+ __u32 s_tunnel, s_session; /* For matching incoming packets */
+ __u32 d_tunnel, d_session; /* For sending outgoing packets */
+
+ struct sockaddr_in6 addr; /* IP address and port to send to */
+};
+
/* Socket options:
* DEBUG - bitmask of debug message categories
* SENDSEQ - 0 => don't send packets with sequence numbers
diff --git a/include/linux/if_pppox.h b/include/linux/if_pppox.h
index b5f927f..6720d57 100644
--- a/include/linux/if_pppox.h
+++ b/include/linux/if_pppox.h
@@ -83,6 +83,12 @@ struct sockaddr_pppol2tp {
struct pppol2tp_addr pppol2tp;
} __attribute__((packed));
+struct sockaddr_pppol2tpin6 {
+ __kernel_sa_family_t sa_family; /* address family, AF_PPPOX */
+ unsigned int sa_protocol; /* protocol identifier */
+ struct pppol2tpin6_addr pppol2tp;
+} __attribute__((packed));
+
/* The L2TPv3 protocol changes tunnel and session ids from 16 to 32
* bits. So we need a different sockaddr structure.
*/
@@ -92,6 +98,12 @@ struct sockaddr_pppol2tpv3 {
struct pppol2tpv3_addr pppol2tp;
} __attribute__((packed));
+struct sockaddr_pppol2tpv3in6 {
+ __kernel_sa_family_t sa_family; /* address family, AF_PPPOX */
+ unsigned int sa_protocol; /* protocol identifier */
+ struct pppol2tpv3in6_addr pppol2tp;
+} __attribute__((packed));
+
/*********************************************************************
*
* ioctl interface for defining forwarding of connections
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index f6732b6..8cd5f4b 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -53,6 +53,9 @@
#include <net/inet_common.h>
#include <net/xfrm.h>
#include <net/protocol.h>
+#include <net/inet6_connection_sock.h>
+#include <net/inet_ecn.h>
+#include <net/ip6_route.h>
#include <asm/byteorder.h>
#include <linux/atomic.h>
@@ -446,21 +449,43 @@ static inline int l2tp_verify_udp_checksum(struct sock *sk,
{
struct udphdr *uh = udp_hdr(skb);
u16 ulen = ntohs(uh->len);
- struct inet_sock *inet;
__wsum psum;
- if (sk->sk_no_check || skb_csum_unnecessary(skb) || !uh->check)
- return 0;
-
- inet = inet_sk(sk);
- psum = csum_tcpudp_nofold(inet->inet_saddr, inet->inet_daddr, ulen,
- IPPROTO_UDP, 0);
-
- if ((skb->ip_summed == CHECKSUM_COMPLETE) &&
- !csum_fold(csum_add(psum, skb->csum)))
+ if (sk->sk_no_check || skb_csum_unnecessary(skb))
return 0;
- skb->csum = psum;
+#if IS_ENABLED(CONFIG_IPV6)
+ if (sk->sk_family == PF_INET6) {
+ if (!uh->check) {
+ LIMIT_NETDEBUG(KERN_INFO "L2TP: IPv6: checksum is 0\n");
+ return 1;
+ }
+ if ((skb->ip_summed == CHECKSUM_COMPLETE) &&
+ !csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
+ &ipv6_hdr(skb)->daddr, ulen,
+ IPPROTO_UDP, skb->csum)) {
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
+ return 0;
+ }
+ skb->csum = ~csum_unfold(csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
+ &ipv6_hdr(skb)->daddr,
+ skb->len, IPPROTO_UDP,
+ 0));
+ } else
+#endif
+ {
+ struct inet_sock *inet;
+ if (!uh->check)
+ return 0;
+ inet = inet_sk(sk);
+ psum = csum_tcpudp_nofold(inet->inet_saddr, inet->inet_daddr,
+ ulen, IPPROTO_UDP, 0);
+
+ if ((skb->ip_summed == CHECKSUM_COMPLETE) &&
+ !csum_fold(csum_add(psum, skb->csum)))
+ return 0;
+ skb->csum = psum;
+ }
return __skb_checksum_complete(skb);
}
@@ -988,7 +1013,12 @@ static int l2tp_xmit_core(struct l2tp_session *session, struct sk_buff *skb,
/* Queue the packet to IP for output */
skb->local_df = 1;
- error = ip_queue_xmit(skb, fl);
+#if IS_ENABLED(CONFIG_IPV6)
+ if (skb->sk->sk_family == PF_INET6)
+ error = inet6_csk_xmit(skb, NULL);
+ else
+#endif
+ error = ip_queue_xmit(skb, fl);
/* Update stats */
if (error >= 0) {
@@ -1021,6 +1051,31 @@ static inline void l2tp_skb_set_owner_w(struct sk_buff *skb, struct sock *sk)
skb->destructor = l2tp_sock_wfree;
}
+#if IS_ENABLED(CONFIG_IPV6)
+static void l2tp_xmit_ipv6_csum(struct sock *sk, struct sk_buff *skb,
+ int udp_len)
+{
+ struct ipv6_pinfo *np = inet6_sk(sk);
+ struct udphdr *uh = udp_hdr(skb);
+
+ if (!skb_dst(skb) || !skb_dst(skb)->dev ||
+ !(skb_dst(skb)->dev->features & NETIF_F_IPV6_CSUM)) {
+ skb->ip_summed = CHECKSUM_COMPLETE;
+ skb->csum = skb_checksum(skb, 0, udp_len, 0);
+ uh->check = csum_ipv6_magic(&np->saddr, &np->daddr, udp_len,
+ IPPROTO_UDP, skb->csum);
+ if (uh->check == 0)
+ uh->check = CSUM_MANGLED_0;
+ } else {
+ skb->ip_summed = CHECKSUM_PARTIAL;
+ skb->csum_start = skb_transport_header(skb) - skb->head;
+ skb->csum_offset = offsetof(struct udphdr, check);
+ uh->check = ~csum_ipv6_magic(&np->saddr, &np->daddr,
+ udp_len, IPPROTO_UDP, 0);
+ }
+}
+#endif
+
/* If caller requires the skb to have a ppp header, the header must be
* inserted in the skb data before calling this function.
*/
@@ -1089,6 +1144,11 @@ int l2tp_xmit_skb(struct l2tp_session *session, struct sk_buff *skb, int hdr_len
uh->check = 0;
/* Calculate UDP checksum if configured to do so */
+#if IS_ENABLED(CONFIG_IPV6)
+ if (sk->sk_family == PF_INET6)
+ l2tp_xmit_ipv6_csum(sk, skb, udp_len);
+ else
+#endif
if (sk->sk_no_check == UDP_CSUM_NOXMIT)
skb->ip_summed = CHECKSUM_NONE;
else if ((skb_dst(skb) && skb_dst(skb)->dev) &&
@@ -1424,6 +1484,11 @@ int l2tp_tunnel_create(struct net *net, int fd, int version, u32 tunnel_id, u32
/* Mark socket as an encapsulation socket. See net/ipv4/udp.c */
udp_sk(sk)->encap_type = UDP_ENCAP_L2TPINUDP;
udp_sk(sk)->encap_rcv = l2tp_udp_encap_recv;
+#if IS_ENABLED(CONFIG_IPV6)
+ if (sk->sk_family == PF_INET6)
+ udpv6_encap_enable();
+ else
+#endif
udp_encap_enable();
}
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 1addd9f..27b9dec 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -916,7 +916,7 @@ static int pppol2tp_getname(struct socket *sock, struct sockaddr *uaddr,
}
inet = inet_sk(tunnel->sock);
- if (tunnel->version == 2) {
+ if ((tunnel->version == 2) && (tunnel->sock->sk_family == AF_INET)) {
struct sockaddr_pppol2tp sp;
len = sizeof(sp);
memset(&sp, 0, len);
@@ -932,6 +932,46 @@ static int pppol2tp_getname(struct socket *sock, struct sockaddr *uaddr,
sp.pppol2tp.addr.sin_port = inet->inet_dport;
sp.pppol2tp.addr.sin_addr.s_addr = inet->inet_daddr;
memcpy(uaddr, &sp, len);
+#if IS_ENABLED(CONFIG_IPV6)
+ } else if ((tunnel->version == 2) &&
+ (tunnel->sock->sk_family == AF_INET6)) {
+ struct ipv6_pinfo *np = inet6_sk(tunnel->sock);
+ struct sockaddr_pppol2tpin6 sp;
+ len = sizeof(sp);
+ memset(&sp, 0, len);
+ sp.sa_family = AF_PPPOX;
+ sp.sa_protocol = PX_PROTO_OL2TP;
+ sp.pppol2tp.fd = tunnel->fd;
+ sp.pppol2tp.pid = pls->owner;
+ sp.pppol2tp.s_tunnel = tunnel->tunnel_id;
+ sp.pppol2tp.d_tunnel = tunnel->peer_tunnel_id;
+ sp.pppol2tp.s_session = session->session_id;
+ sp.pppol2tp.d_session = session->peer_session_id;
+ sp.pppol2tp.addr.sin6_family = AF_INET6;
+ sp.pppol2tp.addr.sin6_port = inet->inet_dport;
+ memcpy(&sp.pppol2tp.addr.sin6_addr, &np->daddr,
+ sizeof(np->daddr));
+ memcpy(uaddr, &sp, len);
+ } else if ((tunnel->version == 3) &&
+ (tunnel->sock->sk_family == AF_INET6)) {
+ struct ipv6_pinfo *np = inet6_sk(tunnel->sock);
+ struct sockaddr_pppol2tpv3in6 sp;
+ len = sizeof(sp);
+ memset(&sp, 0, len);
+ sp.sa_family = AF_PPPOX;
+ sp.sa_protocol = PX_PROTO_OL2TP;
+ sp.pppol2tp.fd = tunnel->fd;
+ sp.pppol2tp.pid = pls->owner;
+ sp.pppol2tp.s_tunnel = tunnel->tunnel_id;
+ sp.pppol2tp.d_tunnel = tunnel->peer_tunnel_id;
+ sp.pppol2tp.s_session = session->session_id;
+ sp.pppol2tp.d_session = session->peer_session_id;
+ sp.pppol2tp.addr.sin6_family = AF_INET6;
+ sp.pppol2tp.addr.sin6_port = inet->inet_dport;
+ memcpy(&sp.pppol2tp.addr.sin6_addr, &np->daddr,
+ sizeof(np->daddr));
+ memcpy(uaddr, &sp, len);
+#endif
} else if (tunnel->version == 3) {
struct sockaddr_pppol2tpv3 sp;
len = sizeof(sp);
--
1.7.4.1
--
"Thought is the essence of where you are now."
^ permalink raw reply related
* Re: [PATCH net-next] netfilter: nf_conntrack.h: use this_cpu_inc()
From: Christoph Lameter @ 2012-04-18 13:44 UTC (permalink / raw)
To: Eric Dumazet
Cc: Pablo Neira Ayuso, linux-kernel, netdev, Tejun Heo,
Patrick McHardy
In-Reply-To: <1334723800.2472.88.camel@edumazet-glaptop>
Ok.
Reviewed-by: Christoph Lameter <cl@linux.com>
^ permalink raw reply
* [PATCH 3/4] net/ipv6/udp: introduce encap_rcv hook into IPv6
From: Benjamin LaHaise @ 2012-04-18 13:44 UTC (permalink / raw)
To: David S. Miller, James Chapman; +Cc: netdev
Now that the sematics of udpv6_queue_rcv_skb() match IPv4's
udp_queue_rcv_skb(), introduce the UDP encap_rcv() hook for IPv6.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
---
include/net/udp.h | 3 +++
net/ipv6/udp.c | 39 +++++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/include/net/udp.h b/include/net/udp.h
index e66fc29..065f379 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -268,4 +268,7 @@ extern int udp4_ufo_send_check(struct sk_buff *skb);
extern struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,
netdev_features_t features);
extern void udp_encap_enable(void);
+#if IS_ENABLED(CONFIG_IPV6)
+extern void udpv6_encap_enable(void);
+#endif
#endif /* _UDP_H */
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index e507654..d3a486b 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -525,6 +525,14 @@ static __inline__ void udpv6_err(struct sk_buff *skb,
__udp6_lib_err(skb, opt, type, code, offset, info, &udp_table);
}
+static struct static_key udpv6_encap_needed __read_mostly;
+void udpv6_encap_enable(void)
+{
+ if (!static_key_enabled(&udpv6_encap_needed))
+ static_key_slow_inc(&udpv6_encap_needed);
+}
+EXPORT_SYMBOL(udpv6_encap_enable);
+
int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
{
struct udp_sock *up = udp_sk(sk);
@@ -534,6 +542,37 @@ int udpv6_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto drop;
+ if (static_key_false(&udpv6_encap_needed) && up->encap_type) {
+ int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
+
+ /*
+ * This is an encapsulation socket so pass the skb to
+ * the socket's udp_encap_rcv() hook. Otherwise, just
+ * fall through and pass this up the UDP socket.
+ * up->encap_rcv() returns the following value:
+ * =0 if skb was successfully passed to the encap
+ * handler or was discarded by it.
+ * >0 if skb should be passed on to UDP.
+ * <0 if skb should be resubmitted as proto -N
+ */
+
+ /* if we're overly short, let UDP handle it */
+ encap_rcv = ACCESS_ONCE(up->encap_rcv);
+ if (skb->len > sizeof(struct udphdr) && encap_rcv != NULL) {
+ int ret;
+
+ ret = encap_rcv(sk, skb);
+ if (ret <= 0) {
+ UDP_INC_STATS_BH(sock_net(sk),
+ UDP_MIB_INDATAGRAMS,
+ is_udplite);
+ return -ret;
+ }
+ }
+
+ /* FALLTHROUGH -- it's a UDP Packet */
+ }
+
/*
* UDP-Lite specific tests, ignored on UDP sockets (see net/ipv4/udp.c).
*/
--
1.7.4.1
--
"Thought is the essence of where you are now."
^ permalink raw reply related
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