* Re: [PATCH net-next] hsr: Use ether_addr_copy
From: David Miller @ 2014-02-18 23:14 UTC (permalink / raw)
To: joe; +Cc: netdev, arvid.brodin, linux-kernel
In-Reply-To: <675e6a59ebb87d5e18633df578a62a1202f6172e.1392748500.git.joe@perches.com>
From: Joe Perches <joe@perches.com>
Date: Tue, 18 Feb 2014 10:37:20 -0800
> It's slightly smaller/faster for some architectures.
> Make sure def_multicast_addr is __aligned(2)
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: add entry for the PHY library
From: David Miller @ 2014-02-18 23:13 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, grant.likely, shaohui.xie, afleming
In-Reply-To: <1392745669-26645-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 18 Feb 2014 09:47:49 -0800
> The PHY library has been subject to some changes, new drivers and DT
> interactions over the past few months. Add myself as a maintainer for
> the core PHY library parts and drivers. Make sure the PHY library entry
> also covers the Device Tree files which have a close interaction with
> the MDIO bus, PHY connection and Ethernet PHY mode parsing.
>
> CC: Grant Likely <grant.likely@linaro.org>
> CC: Shaohui Xie <shaohui.xie@freescale.com>
> CC: Andy Fleming <afleming@gmail.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2] of_mdio: fix phy interrupt passing
From: David Miller @ 2014-02-18 23:13 UTC (permalink / raw)
To: grant.likely
Cc: ben.dooks, linux-kernel, devicetree, linux-kernel, netdev,
linux-sh, sergei.shtylyov
In-Reply-To: <20140218161551.44A52C40517@trevor.secretlab.ca>
From: Grant Likely <grant.likely@linaro.org>
Date: Tue, 18 Feb 2014 16:15:51 +0000
> On Tue, 18 Feb 2014 12:16:58 +0000, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>> The of_mdiobus_register_phy() is not setting phy->irq thus causing
>> some drivers to incorrectly assume that the PHY does not have an
>> IRQ associated with it. Not only do some drivers report no IRQ
>> they do not install an interrupt handler for the PHY.
>>
>> Simplify the code setting irq and set the phy->irq at the same
>> time so that we cover the following issues, which should cover
>> all the cases the code will find:
>>
>> - Set phy->irq if node has irq property and mdio->irq is NULL
>> - Set phy->irq if node has no irq and mdio->irq is not NULL
>> - Leave phy->irq as PHY_POLL default if none of the above
>>
>> This fixes the issue:
>> net eth0: attached PHY 1 (IRQ -1) to driver Micrel KSZ8041RNLI
>>
>> to the correct:
>> net eth0: attached PHY 1 (IRQ 416) to driver Micrel KSZ8041RNLI
>>
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>
> Looks okay to me
>
> Reviewed-by: Grant Likely <grant.likely@linaro.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH next resend] tcp: use zero-window when free_space is low
From: Eric Dumazet @ 2014-02-18 23:12 UTC (permalink / raw)
To: Florian Westphal; +Cc: David Miller, netdev, ncardwell, ycheng
In-Reply-To: <1392744616.24974.14.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, 2014-02-18 at 09:30 -0800, Eric Dumazet wrote:
> On Mon, 2014-02-17 at 21:52 +0100, Florian Westphal wrote:
> > David Miller <davem@davemloft.net> wrote:
> > > From: Florian Westphal <fw@strlen.de>
> > > Date: Thu, 13 Feb 2014 12:52:30 +0100
> > >
> > > > V1 of this patch was deferred, resending to get discussion going again.
> > > > Changes since v1:
> > > > - add reproducer to commit message
> > > >
> > > > Unfortunately I couldn't come up with something that has no magic
> > > > ('allowed >> 4') value. I chose >>4 (1/16th) because it didn't cause
> > > > tput limitations in my 'full-mss-sized, steady state' netcat tests.
> > > >
> > > > Maybe someone has better idea?
> > >
> > > I know this is going to be frustrating, but I've marked this 'deferred'
> > > again. Please resubmit after the testing and further discussions have
> > > been worked out.
> >
> > Thanks for letting me know. I understand why you are reluctant to just
> > apply this.
> >
> > I will submit another patch shortly that introduces snmp counter for zero-window
> > (what Eric suggested), perhaps it helps him or others to find a better solution
> > in the scenario.
>
> Sorry for the delay guys, I was on vacation.
>
> I started the tests this morning, results in about 2/3 hours.
No regression found, feel free to add my :
Acked-by: Eric Dumazet <edumazet@google.com>
Tested-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH net-next] ipv6: remove some unused include in flowlabel
From: David Miller @ 2014-02-18 23:11 UTC (permalink / raw)
To: florent.fourcot; +Cc: netdev
In-Reply-To: <1392731142-3840-1-git-send-email-florent.fourcot@enst-bretagne.fr>
From: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Date: Tue, 18 Feb 2014 14:45:42 +0100
> These include are here since kernel 2.2.7, but probably never used.
>
> Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ieee802154: fix faulty check in set_phy_params api
From: David Miller @ 2014-02-18 23:11 UTC (permalink / raw)
To: phoebe.buckheister; +Cc: netdev, linux-zigbee-devel
In-Reply-To: <1392730767-24858-1-git-send-email-phoebe.buckheister@itwm.fraunhofer.de>
From: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
Date: Tue, 18 Feb 2014 14:39:27 +0100
> phy_set_csma_params has a redundant (and impossible) check for
> "retries", found by smatch. The check was supposed to be for
> frame_retries, but wasn't moved during development when
> phy_set_frame_retries was introduced. Also, maxBE >= 3 as required by
> the standard is not enforced.
>
> Remove the redundant check, assure max_be >= 3 and check -1 <=
> frame_retries <= 7 in the correct function.
>
> Signed-off-by: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tipc: failed transmissions should return error
From: David Miller @ 2014-02-18 23:11 UTC (permalink / raw)
To: erik.hugne
Cc: netdev, tipc-discussion, ying.xue, paul.gortmaker, jon.maloy,
maloy
In-Reply-To: <1392730190-20050-1-git-send-email-erik.hugne@ericsson.com>
From: <erik.hugne@ericsson.com>
Date: Tue, 18 Feb 2014 14:29:50 +0100
> From: Erik Hugne <erik.hugne@ericsson.com>
>
> When a message could not be sent out because the destination
> node or link could not be found, the full message size is
> returned from sendmsg() as if it had been sent successfully.
> An application will then get a false indication that it's
> making forward progress. This problem has existed since the
> initial commit in 2.6.16.
>
> We change this to return -ENETUNREACH if the message cannot be
> delivered due to the destination node/link being unavailable.
> We also get rid of the redundant tipc_reject_msg call since
> freeing the buffer and doing a tipc_port_reject_sections
> accomplishes exactly the same thing.
>
> Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
This does not apply cleanly to net-next, please respin.
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: update dependency and help text of mvneta
From: David Miller @ 2014-02-18 23:09 UTC (permalink / raw)
To: thomas.petazzoni
Cc: netdev, jason, gregory.clement, andrew, sebastian.hesselbarth,
ezequiel.garcia, linux-arm-kernel
In-Reply-To: <1392729491-24913-1-git-send-email-thomas.petazzoni@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Tue, 18 Feb 2014 14:18:11 +0100
> With the introduction of the support for Armada 375 and Armada 38x,
> the hidden Kconfig option MACH_ARMADA_370_XP is being renamed to
> MACH_MVEBU_V7. Therefore, the dependency that was used for the mvneta
> driver can no longer work. This commit replaces this dependency by a
> dependency on PLAT_ORION, which is used similarly for the mv643xx_eth
> driver.
>
> In addition to this, it takes this opportunity to adjust the
> description and help text to indicate that the driver can is also used
> for Armada 38x. Note that Armada 375 cannot use this driver as it has
> a completely different networking unit, which will require a separate
> driver.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] igb: Fix Null-pointer dereference in igb_reset_q_vector
From: David Miller @ 2014-02-18 23:08 UTC (permalink / raw)
To: christoph.paasch
Cc: netdev, e1000-devel, jeffrey.t.kirsher, jesse.brandeburg,
carolyn.wyborny
In-Reply-To: <1392728817-21693-1-git-send-email-christoph.paasch@uclouvain.be>
From: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Tue, 18 Feb 2014 14:06:57 +0100
> When igb_set_interrupt_capability() calls
> igb_reset_interrupt_capability() (e.g., because CONFIG_PCI_MSI is unset),
> num_q_vectors has been set but no vector has yet been allocated.
>
> igb_reset_interrupt_capability() will then call igb_reset_q_vector,
> which assumes that the vector is allocated. As this is not the case, we
> are accessing a NULL-pointer.
>
> This patch fixes it by checking that q_vector is indeed different from
> NULL.
>
> Fixes: 02ef6e1d0b0023 (igb: Fix queue allocation method to accommodate changing during runtime)
> Cc: Carolyn Wyborny <carolyn.wyborny@intel.com>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Intel folks, please queue this up, thanks.
^ permalink raw reply
* Re: [PATCH] NET: fec: only enable napi if we are successful
From: David Miller @ 2014-02-18 23:07 UTC (permalink / raw)
To: rmk+kernel; +Cc: netdev, linux-arm-kernel, dmalek, gerg, phdm, fabio.estevam
In-Reply-To: <E1WFkD8-0004pj-Pr@rmk-PC.arm.linux.org.uk>
From: Russell King <rmk+kernel@arm.linux.org.uk>
Date: Tue, 18 Feb 2014 12:55:42 +0000
> If napi is left enabled after a failed attempt to bring the interface
> up, we BUG:
>
> fec 2188000.ethernet eth0: no PHY, assuming direct connection to switch
> libphy: PHY fixed-0:00 not found
> fec 2188000.ethernet eth0: could not attach to PHY
> ------------[ cut here ]------------
> kernel BUG at include/linux/netdevice.h:502!
> Internal error: Oops - BUG: 0 [#1] SMP ARM
> ...
> PC is at fec_enet_open+0x4d0/0x500
> LR is at __dev_open+0xa4/0xfc
>
> Only enable napi after we are past all the failure paths.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Applied, thanks a lot Russell.
^ permalink raw reply
* Re: [patch] af_packet: remove a stray tab in packet_set_ring()
From: David Miller @ 2014-02-18 23:02 UTC (permalink / raw)
To: dan.carpenter
Cc: dborkman, willemb, hannes, edumazet, phil, atzm, richardcochran,
netdev, kernel-janitors
In-Reply-To: <20140218122050.GB9604@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 18 Feb 2014 15:20:51 +0300
> At first glance it looks like there is a missing curly brace but
> actually the code works the same either way. I have adjusted the
> indenting but left the code the same.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thank you.
^ permalink raw reply
* [PATCH v2] net: ethoc: document OF bindings
From: Max Filippov @ 2014-02-18 22:46 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: David S. Miller, Grant Likely, Rob Herring, Sergei Shtylyov,
Florian Fainelli, Max Filippov
Signed-off-by: Max Filippov <jcmvbkbc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Changes v1->v2:
- drop local-mac-address optional property description
(described in the common ethernet.txt);
- drop optional properties for MDIO bus frequency and MAC frequency
(removed from the implementation);
- add clocks property.
.../devicetree/bindings/net/opencores-ethoc.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/opencores-ethoc.txt
diff --git a/Documentation/devicetree/bindings/net/opencores-ethoc.txt b/Documentation/devicetree/bindings/net/opencores-ethoc.txt
new file mode 100644
index 0000000..41e2675
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/opencores-ethoc.txt
@@ -0,0 +1,22 @@
+* OpenCores MAC 10/100 Mbps
+
+Required properties:
+- compatible: Should be "opencores,ethoc".
+- reg: two memory regions (address and length),
+ first region is for the device registers and descriptor rings,
+ second is for the device packet memory.
+- interrupts: interrupt for the device.
+
+Optional properties:
+- clocks: phandle to refer to the clk used as per
+ Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Examples:
+
+ enet0: ethoc@fd030000 {
+ compatible = "opencores,ethoc";
+ reg = <0xfd030000 0x4000 0xfd800000 0x4000>;
+ interrupts = <1>;
+ local-mac-address = [00 50 c2 13 6f 00];
+ clocks = <&osc>;
+ };
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH net-next v2] Documentation: broadcom-bcmgenet: fix address and cells properties
From: David Miller @ 2014-02-18 22:44 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, sergei.shtylyov
In-Reply-To: <1392762975-19132-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 18 Feb 2014 14:36:15 -0800
> This patch fixes a typo in the Device Tree binding for the
> leading '#'.
>
> Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Changes in v2:
> - rebased on top of net-next/master
Applied, thanks for the quick turnaround.
^ permalink raw reply
* Re: [PATCH net-next] bonding: Fix RTNL: assertion failed at net/core/rtnetlink.c for 802.3ad mode
From: David Miller @ 2014-02-18 22:38 UTC (permalink / raw)
To: dingtianhong
Cc: fubar, andy, vfalico, cwang, thomas, jiri, edumazet, sfeldma,
netdev
In-Reply-To: <53034312.1060203@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Tue, 18 Feb 2014 19:25:06 +0800
> The problem was introduced by the commit 1d3ee88ae0d
> (bonding: add netlink attributes to slave link dev).
> The bond_set_active_slave() and bond_set_backup_slave()
> will use rtmsg_ifinfo to send slave's states, so these
> two functions should be called in RTNL.
>
> In 802.3ad mode, acquiring RTNL for the __enable_port and
> __disable_port cases is difficult, as those calls generally
> already hold the state machine lock, and cannot unconditionally
> call rtnl_lock because either they already hold RTNL (for calls
> via bond_3ad_unbind_slave) or due to the potential for deadlock
> with bond_3ad_adapter_speed_changed, bond_3ad_adapter_duplex_changed,
> bond_3ad_link_change, or bond_3ad_update_lacp_rate. All four of
> those are called with RTNL held, and acquire the state machine lock
> second. The calling contexts for __enable_port and __disable_port
> already hold the state machine lock, and may or may not need RTNL.
>
> According to the Jay's opinion, I don't think it is a problem that
> the slave don't send notify message synchronously when the status
> changed, normally the state machine is running every 100 ms, send
> the notify message at the end of the state machine if the slave's
> state changed should be better.
>
> I fix the problem through these steps:
>
> 1). add a new function bond_set_slave_state() which could change
> the slave's state and call rtmsg_ifinfo() according to the input
> parameters called notify.
>
> 2). Add a new slave parameter which called should_notify, if the slave's state
> changed and don't notify yet, the parameter will be set to 1, and then if
> the slave's state changed again, the param will be set to 0, it indicate that
> the slave's state has been restored, no need to notify any one.
>
> 3). the __enable_port and __disable_port should not call rtmsg_ifinfo
> in the state machine lock, any change in the state of slave could
> set a flag in the slave, it will indicated that an rtmsg_ifinfo
> should be called at the end of the state machine.
>
> Cc: Jay Vosburgh <fubar@us.ibm.com>
> Cc: Veaceslav Falico <vfalico@redhat.com>
> Cc: Andy Gospodarek <andy@greyhouse.net>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
This seems more appropriately targetted at 'net' since it's a real
bug fix, do you agree?
^ permalink raw reply
* [PATCH net-next v2] Documentation: broadcom-bcmgenet: fix address and cells properties
From: Florian Fainelli @ 2014-02-18 22:36 UTC (permalink / raw)
To: netdev; +Cc: davem, sergei.shtylyov, Florian Fainelli
This patch fixes a typo in the Device Tree binding for the
leading '#'.
Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes in v2:
- rebased on top of net-next/master
Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
index 88fb958..f2febb9 100644
--- a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
+++ b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
@@ -8,8 +8,8 @@ Required properties:
interrupt line, while the second cell is the interrupt for the ring
RX and TX queues operating in ring mode
- phy-mode: see ethernet.txt file in the same directory
-- address-cells: should be 1
-- size-cells: should be 1
+- #address-cells: should be 1
+- #size-cells: should be 1
Optional properties:
- clocks: When provided, must be two phandles to the functional clocks nodes
@@ -39,8 +39,8 @@ MDIO bus node required properties:
parent node compatible property (e.g: brcm,genet-v4 pairs with
brcm,genet-mdio-v4)
- reg: address and length relative to the parent node base register address
-- address-cells: address cell for MDIO bus addressing, should be 1
-- size-cells: size of the cells for MDIO bus addressing, should be 0
+- #address-cells: address cell for MDIO bus addressing, should be 1
+- #size-cells: size of the cells for MDIO bus addressing, should be 0
Ethernet PHY node properties:
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH net-next] tipc: align tipc function names with common naming practice in the network
From: David Miller @ 2014-02-18 22:32 UTC (permalink / raw)
To: ying.xue; +Cc: jon.maloy, Paul.Gortmaker, erik.hugne, netdev, tipc-discussion
In-Reply-To: <1392710806-13831-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Tue, 18 Feb 2014 16:06:46 +0800
> Rename the following functions, which are shorter and more in line
> with common naming practice in the network subsystem.
...
> Above changes have no impact on current users of the functions.
>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] ethtool: Remove inactive code snippet in ethtool_set_rxfh_indir
From: David Miller @ 2014-02-18 22:26 UTC (permalink / raw)
To: VenkatKumar.Duvvuru; +Cc: netdev
In-Reply-To: <BF3270C86E8B1349A26C34E4EC1C44CB2C87A575@CMEXMB1.ad.emulex.com>
From: Venkata Duvvuru <VenkatKumar.Duvvuru@Emulex.Com>
Date: Tue, 18 Feb 2014 07:38:28 +0000
> ethtool_rxfh_indir_default is invoked inside ethtool_get_rxfh_indir when user_size is zero. However user_size can only be zero when dev_size is zero in which case ethtool_get_rxfh_indir itself would have returned -EOPNOTSUPP error. User_size = 0 can never occur unless a buggy ethtool sends user_size as zero beforing invoking the ioctl in which case we should return -EINVAL.
Please properly format your commit message, with newlines every ~80 columns.
> Signed-off-by: Venkat Duvvuru <VenkatKumar.Duvvuru@Emulex.com>
Also your patch was corrupted in transit, look at what happened when it hit
patchwork:
http://patchwork.ozlabs.org/patch/321313/
^ permalink raw reply
* Re: [PATCH] Documentation: broadcom-bcmgenet: fix address and cells properties
From: David Miller @ 2014-02-18 22:23 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, sergei.shtylyov
In-Reply-To: <1392683255-28136-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 17 Feb 2014 16:27:35 -0800
> This patch fixes a typo in the Device Tree binding for the
> leading '#'.
>
> Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Sergei put the phy-mode documentation to a common location, so you'll
need to respin this.
Thanks.
^ permalink raw reply
* Re: [PATCH v4] sh_eth: add device tree support
From: David Miller @ 2014-02-18 22:21 UTC (permalink / raw)
To: sergei.shtylyov
Cc: robh+dt, pawel.moll, mark.rutland, grant.likely, devicetree,
linux-sh, ijc+devicetree, galak, netdev, nobuhiro.iwamatsu.yj,
rob, linux-doc
In-Reply-To: <201402180312.44775.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Tue, 18 Feb 2014 03:12:43 +0300
> Add support of the device tree probing for the Renesas SH-Mobile SoCs
> documenting the device tree binding as necessary.
>
> This work is loosely based on the original patch by Nobuhiro Iwamatsu
> <nobuhiro.iwamatsu.yj@renesas.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Also applied, thanks.
^ permalink raw reply
* Re: socket bind to local address ::ffff:127.0.0.1 question
From: Vincent Li @ 2014-02-18 22:19 UTC (permalink / raw)
To: Vincent Li, netdev@vger.kernel.org
In-Reply-To: <CAK3+h2zXjvf_Ub9FRCqcK4gmikg_BG-+BvSxX7R-t2gT-_VNRw@mail.gmail.com>
sorry for the noise, I think I may answer my own question, since I
noticed the it is the second connect call returns "EHOSTUNREACH" and
that looks like a retransmit of SYN, so the 'EHOSTUNREACH' should come
from net/ipv4/tcp_output.c tcp_retransmit_skb
On Tue, Feb 18, 2014 at 2:14 PM, Vincent Li <vincent.mc.li@gmail.com> wrote:
> for my own education, and want to know where the code path for the
> connect returns 'EHOSTUNREACH' in kernel, I grepped ''EHOSTUNREACH' in
> ./net directory and think following might match the code path :
>
> [root@centos64-vm centos-6.2]# grep -r -w 'EHOSTUNREACH' net/*
>
> net/ipv4/fib_semantics.c: .error = -EHOSTUNREACH,
>
> net/ipv4/tcp_output.c: return -EHOSTUNREACH; /* Routing
> failure or similar. */ <------this one?
>
>
> net/ipv4/ip_input.c: if (err == -EHOSTUNREACH)
> net/ipv4/ip_output.c: return -EHOSTUNREACH;
> <------------------------------- or this one?
>
> net/ipv4/tcp_ipv4.c: err = EHOSTUNREACH;
> net/ipv4/route.c: case EHOSTUNREACH:
> net/ipv4/route.c: err = -EHOSTUNREACH;
> net/ipv4/xfrm4_policy.c: return -EHOSTUNREACH;
>
> net/ipv6/route.c: err = -EHOSTUNREACH;
> net/ipv6/xfrm6_policy.c: return -EHOSTUNREACH;
>
> net/xfrm/xfrm_output.c: err = -EHOSTUNREACH;
> net/xfrm/xfrm_policy.c: err = -EHOSTUNREACH;
>
> Could kernel expert confirm which code path the connect return comings from?
>
> thanks
>
> Vincent
>
> On Mon, Feb 17, 2014 at 10:32 AM, Vincent Li <vincent.mc.li@gmail.com> wrote:
>> sorry to respond late, I don't have code access to the program and no
>> sample code to reproduce the issue. the strace only shows connect and
>> getsockname trace. so the trouble shooting is very limited. the kernel
>> version is centos 6.2 based. (2.6.32*)
>>
>> the strace file is too large to paste here, so I extract out the
>> relevant information I think related, the connect call finally returns
>> ' EHOSTUNREACH (No route to host)'
>>
>> 6797 12:37:01.871842 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(46854), inet_pton(AF_INET6, "::ffff:172.16.17.161",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433151086333263900]) = 0
>>
>> 6797 12:37:01.872186 close(11) = 0 <---here closed descriptor 11
>>
>> ------another new connection opened for discriptor 11, this is
>> successfull one monitor instance----
>>
>> 6797 12:37:02.871031 fcntl64(11, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
>>
>> 6797 12:37:02.871121 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
>>
>> 6797 12:37:02.871229 connect(11, {sa_family=AF_INET6,
>> sin6_port=htons(8180), inet_pton(AF_INET6, "::ffff:172.16.3.166",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=875638834}, 28) = -1
>> EINPROGRESS (Operation now in progress)
>>
>> 6797 12:37:02.873006 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433145657494601756]) = 0
>>
>> 6797 12:37:02.876424 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433151292491694108]) = 0
>>
>> 6797 12:37:02.878081 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433151155052740636]) = 0
>>
>> 6797 12:37:02.878353 connect(11, {sa_family=AF_INET6,
>> sin6_port=htons(8180), inet_pton(AF_INET6, "::ffff:172.16.3.166",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=875638834}, 28) = 0
>>
>> 6797 12:37:02.878467 getsockopt(11, SOL_TCP, TCP_MAXSEG,
>> [700869393474651560], [4]) = 0
>>
>> 6797 12:37:02.878553 fcntl64(11, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
>>
>> 6797 12:37:02.878673 fcntl64(11, F_SETFL, O_RDWR|O_NONBLOCK) = 0
>>
>> 6797 12:37:02.878768 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
>>
>> 6797 12:37:02.878851 setsockopt(11, SOL_TCP, TCP_NODELAY, [1], 4) = 0
>>
>> 6797 12:37:02.880352 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433151155052740636]) = 0
>>
>> 6797 12:37:02.880884 write(11, "GET /status HTTP/1.0\r\n\r\n", 24) =
>> 24 <---monitor http request
>>
>> 6797 12:37:02.882551 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433151155052740636]) = 0
>>
>> 6797 12:37:02.886150 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433151292491694108]) = 0
>>
>> 6797 12:37:02.887843 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433151086333263900]) = 0
>>
>> 6797 12:37:02.888096 read(11, "HTTP/1.1 200 OK\r\nServer:
>> Apache-"..., 5120) = 3175 <----server response ok
>>
>> 6797 12:37:02.888214 read(11, "", 1945) = 0
>>
>> 6797 12:37:02.889833 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433151086333263900]) = 0
>>
>> 6797 12:37:02.891532 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433151086333263900]) = 0
>>
>> 6797 12:37:02.891896 close(11) = 0 <-------this sucessfull
>> monitor instance closed
>>
>> ------a failed monitor instance started on discriptor 11, no
>> getsockopt and setsockopt traced-----------
>>
>> 6797 12:37:03.790155 fcntl64(11, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
>>
>> 6797 12:37:03.790237 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
>>
>> 6797 12:37:03.790342 connect(11, {sa_family=AF_INET6,
>> sin6_port=htons(8180), inet_pton(AF_INET6, "::ffff:172.16.3.165",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=875638834}, 28) = -1
>> EINPROGRESS (Operation now in progress)
>>
>> 6797 12:37:03.791998 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(45633), inet_pton(AF_INET6, "::ffff:127.0.0.1",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433145657494601756]) = 0
>>
>> 6797 12:37:06.796980 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(45633), inet_pton(AF_INET6, "::ffff:127.0.0.1",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433151292491694108]) = 0
>>
>> 6797 12:37:06.798645 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(45633), inet_pton(AF_INET6, "::ffff:127.0.0.1",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>> [18433151155052740636]) = 0
>>
>> 6797 12:37:06.798919 connect(11, {sa_family=AF_INET6,
>> sin6_port=htons(8180), inet_pton(AF_INET6, "::ffff:172.16.3.165",
>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=875638834}, 28) = -1
>> EHOSTUNREACH (No route to host)
>>
>>
>> 6797 12:37:06.800437 getsockname(11, {sa_family=AF_INET6,
>> sin6_port=htons(45633), inet_pton(AF_INET6, "::", &sin6_addr),
>> sin6_flowinfo=0, sin6_scope_id=0}, [18433150467857973276]) = 0
>>
>> 6797 12:37:06.800777 close(11) = 0
>>
>> we have continuously ip route dump when the issue happend 'ip route
>> get 172.16.3.165', there is always default route to 172.16.3.165 and
>> the we also see the SYN packet going out on the wire sourcing from
>> 127.0.0.1, so there is no layer 2 arp issue and no icmp error packet
>> reported that is why I am looking for if there is potential kernel
>> issue here.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Feb 15, 2014 at 9:10 AM, Hannes Frederic Sowa
>> <hannes@stressinduktion.org> wrote:
>>> On Wed, Feb 12, 2014 at 12:41:21PM -0800, Vincent Li wrote:
>>>> we have a traffic path like <BIGIP monitor userland process on Linux>
>>>> <------> router<------->pool/real server
>>>>
>>>> there is a weird issue that intermittently, a socket is bound to
>>>> loopback address '::ffff:127.0.0.1' which caused issue for us because
>>>> remote end host can't SYN+ACK the SYN source from 127.0.0.1, strace
>>>> the userland process shows:
>>>>
>>>> 6797 12:36:48.815296 connect(11, {sa_family=AF_INET6,
>>>> sin6_port=htons(8180), inet_pton(AF_INET6, "::ffff:172.16.3.165",
>>>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=875638834}, 28) = -1
>>>> EINPROGRESS (Operation now in progress)
>>>
>>> Have you checked the connect operation completed successfully in this
>>> case? Error state would be interesting to see (SO_ERROR).
>>>
>>>> 6797 12:36:48.815464 gettimeofday({1391744208, 815499}, NULL) = 0
>>>> 6797 12:36:48.815552 time(NULL) = 1391744208
>>>> 6797 12:36:48.815657 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
>>>> st_size=331, ...}) = 0
>>>> ...................
>>>> 6797 12:36:48.816948 getsockname(11, {sa_family=AF_INET6,
>>>> sin6_port=htons(45621), inet_pton(AF_INET6, "::ffff:127.0.0.1",
>>>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>>>> [18433145657494601756]) = 0
>>> ^^^
>>> Urks!
>>>
>>> What kernel version are you using?
>>>
>>> Do you have a reproducer, sample code in C where this problem sometimes
>>> happens or could you expand the strace listings a bit (maybe setsockopts,
>>> bindv6only settings)?
>>>
>>> Also you seem to not initialize your struct sockaddr_in6 given to connect, as
>>> the sin6_scope_id seems bogus (uninitialized memory?). But should not
>>> matter with v4mapped addresses though.
>>>
>>> Greetings,
>>>
>>> Hannes
>>>
>>>
^ permalink raw reply
* Re: socket bind to local address ::ffff:127.0.0.1 question
From: Vincent Li @ 2014-02-18 22:14 UTC (permalink / raw)
To: Vincent Li, netdev@vger.kernel.org
In-Reply-To: <CAK3+h2yQB32tJ-VDf9v9e6dw-AN8hJ3Nb3Z+7=2Gp+m6LFCzWQ@mail.gmail.com>
for my own education, and want to know where the code path for the
connect returns 'EHOSTUNREACH' in kernel, I grepped ''EHOSTUNREACH' in
./net directory and think following might match the code path :
[root@centos64-vm centos-6.2]# grep -r -w 'EHOSTUNREACH' net/*
net/ipv4/fib_semantics.c: .error = -EHOSTUNREACH,
net/ipv4/tcp_output.c: return -EHOSTUNREACH; /* Routing
failure or similar. */ <------this one?
net/ipv4/ip_input.c: if (err == -EHOSTUNREACH)
net/ipv4/ip_output.c: return -EHOSTUNREACH;
<------------------------------- or this one?
net/ipv4/tcp_ipv4.c: err = EHOSTUNREACH;
net/ipv4/route.c: case EHOSTUNREACH:
net/ipv4/route.c: err = -EHOSTUNREACH;
net/ipv4/xfrm4_policy.c: return -EHOSTUNREACH;
net/ipv6/route.c: err = -EHOSTUNREACH;
net/ipv6/xfrm6_policy.c: return -EHOSTUNREACH;
net/xfrm/xfrm_output.c: err = -EHOSTUNREACH;
net/xfrm/xfrm_policy.c: err = -EHOSTUNREACH;
Could kernel expert confirm which code path the connect return comings from?
thanks
Vincent
On Mon, Feb 17, 2014 at 10:32 AM, Vincent Li <vincent.mc.li@gmail.com> wrote:
> sorry to respond late, I don't have code access to the program and no
> sample code to reproduce the issue. the strace only shows connect and
> getsockname trace. so the trouble shooting is very limited. the kernel
> version is centos 6.2 based. (2.6.32*)
>
> the strace file is too large to paste here, so I extract out the
> relevant information I think related, the connect call finally returns
> ' EHOSTUNREACH (No route to host)'
>
> 6797 12:37:01.871842 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(46854), inet_pton(AF_INET6, "::ffff:172.16.17.161",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433151086333263900]) = 0
>
> 6797 12:37:01.872186 close(11) = 0 <---here closed descriptor 11
>
> ------another new connection opened for discriptor 11, this is
> successfull one monitor instance----
>
> 6797 12:37:02.871031 fcntl64(11, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
>
> 6797 12:37:02.871121 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
>
> 6797 12:37:02.871229 connect(11, {sa_family=AF_INET6,
> sin6_port=htons(8180), inet_pton(AF_INET6, "::ffff:172.16.3.166",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=875638834}, 28) = -1
> EINPROGRESS (Operation now in progress)
>
> 6797 12:37:02.873006 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433145657494601756]) = 0
>
> 6797 12:37:02.876424 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433151292491694108]) = 0
>
> 6797 12:37:02.878081 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433151155052740636]) = 0
>
> 6797 12:37:02.878353 connect(11, {sa_family=AF_INET6,
> sin6_port=htons(8180), inet_pton(AF_INET6, "::ffff:172.16.3.166",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=875638834}, 28) = 0
>
> 6797 12:37:02.878467 getsockopt(11, SOL_TCP, TCP_MAXSEG,
> [700869393474651560], [4]) = 0
>
> 6797 12:37:02.878553 fcntl64(11, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
>
> 6797 12:37:02.878673 fcntl64(11, F_SETFL, O_RDWR|O_NONBLOCK) = 0
>
> 6797 12:37:02.878768 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
>
> 6797 12:37:02.878851 setsockopt(11, SOL_TCP, TCP_NODELAY, [1], 4) = 0
>
> 6797 12:37:02.880352 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433151155052740636]) = 0
>
> 6797 12:37:02.880884 write(11, "GET /status HTTP/1.0\r\n\r\n", 24) =
> 24 <---monitor http request
>
> 6797 12:37:02.882551 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433151155052740636]) = 0
>
> 6797 12:37:02.886150 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433151292491694108]) = 0
>
> 6797 12:37:02.887843 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433151086333263900]) = 0
>
> 6797 12:37:02.888096 read(11, "HTTP/1.1 200 OK\r\nServer:
> Apache-"..., 5120) = 3175 <----server response ok
>
> 6797 12:37:02.888214 read(11, "", 1945) = 0
>
> 6797 12:37:02.889833 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433151086333263900]) = 0
>
> 6797 12:37:02.891532 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(33334), inet_pton(AF_INET6, "::ffff:172.16.17.161",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433151086333263900]) = 0
>
> 6797 12:37:02.891896 close(11) = 0 <-------this sucessfull
> monitor instance closed
>
> ------a failed monitor instance started on discriptor 11, no
> getsockopt and setsockopt traced-----------
>
> 6797 12:37:03.790155 fcntl64(11, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
>
> 6797 12:37:03.790237 fcntl64(11, F_SETFD, FD_CLOEXEC) = 0
>
> 6797 12:37:03.790342 connect(11, {sa_family=AF_INET6,
> sin6_port=htons(8180), inet_pton(AF_INET6, "::ffff:172.16.3.165",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=875638834}, 28) = -1
> EINPROGRESS (Operation now in progress)
>
> 6797 12:37:03.791998 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(45633), inet_pton(AF_INET6, "::ffff:127.0.0.1",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433145657494601756]) = 0
>
> 6797 12:37:06.796980 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(45633), inet_pton(AF_INET6, "::ffff:127.0.0.1",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433151292491694108]) = 0
>
> 6797 12:37:06.798645 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(45633), inet_pton(AF_INET6, "::ffff:127.0.0.1",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
> [18433151155052740636]) = 0
>
> 6797 12:37:06.798919 connect(11, {sa_family=AF_INET6,
> sin6_port=htons(8180), inet_pton(AF_INET6, "::ffff:172.16.3.165",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=875638834}, 28) = -1
> EHOSTUNREACH (No route to host)
>
>
> 6797 12:37:06.800437 getsockname(11, {sa_family=AF_INET6,
> sin6_port=htons(45633), inet_pton(AF_INET6, "::", &sin6_addr),
> sin6_flowinfo=0, sin6_scope_id=0}, [18433150467857973276]) = 0
>
> 6797 12:37:06.800777 close(11) = 0
>
> we have continuously ip route dump when the issue happend 'ip route
> get 172.16.3.165', there is always default route to 172.16.3.165 and
> the we also see the SYN packet going out on the wire sourcing from
> 127.0.0.1, so there is no layer 2 arp issue and no icmp error packet
> reported that is why I am looking for if there is potential kernel
> issue here.
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Feb 15, 2014 at 9:10 AM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
>> On Wed, Feb 12, 2014 at 12:41:21PM -0800, Vincent Li wrote:
>>> we have a traffic path like <BIGIP monitor userland process on Linux>
>>> <------> router<------->pool/real server
>>>
>>> there is a weird issue that intermittently, a socket is bound to
>>> loopback address '::ffff:127.0.0.1' which caused issue for us because
>>> remote end host can't SYN+ACK the SYN source from 127.0.0.1, strace
>>> the userland process shows:
>>>
>>> 6797 12:36:48.815296 connect(11, {sa_family=AF_INET6,
>>> sin6_port=htons(8180), inet_pton(AF_INET6, "::ffff:172.16.3.165",
>>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=875638834}, 28) = -1
>>> EINPROGRESS (Operation now in progress)
>>
>> Have you checked the connect operation completed successfully in this
>> case? Error state would be interesting to see (SO_ERROR).
>>
>>> 6797 12:36:48.815464 gettimeofday({1391744208, 815499}, NULL) = 0
>>> 6797 12:36:48.815552 time(NULL) = 1391744208
>>> 6797 12:36:48.815657 stat64("/etc/localtime", {st_mode=S_IFREG|0644,
>>> st_size=331, ...}) = 0
>>> ...................
>>> 6797 12:36:48.816948 getsockname(11, {sa_family=AF_INET6,
>>> sin6_port=htons(45621), inet_pton(AF_INET6, "::ffff:127.0.0.1",
>>> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0},
>>> [18433145657494601756]) = 0
>> ^^^
>> Urks!
>>
>> What kernel version are you using?
>>
>> Do you have a reproducer, sample code in C where this problem sometimes
>> happens or could you expand the strace listings a bit (maybe setsockopts,
>> bindv6only settings)?
>>
>> Also you seem to not initialize your struct sockaddr_in6 given to connect, as
>> the sin6_scope_id seems bogus (uninitialized memory?). But should not
>> matter with v4mapped addresses though.
>>
>> Greetings,
>>
>> Hannes
>>
>>
^ permalink raw reply
* Re: [PATCH v5] DT: net: document Ethernet bindings in one place
From: David Miller @ 2014-02-18 22:05 UTC (permalink / raw)
To: sergei.shtylyov
Cc: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
devicetree, netdev, rob, linux-doc, jcmvbkbc, linux-sh
In-Reply-To: <201402180242.00796.sergei.shtylyov@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Tue, 18 Feb 2014 02:41:59 +0300
> This patch is an attempt to gather the Ethernet related bindings in one file,
> like it's done in the MMC and some other subsystems. It should save some of
> the trouble of documenting several properties over and over in each binding
> document, instead only making reference to the main file.
>
> I have used the Embedded Power Architecture(TM) Platform Requirements (ePAPR)
> standard as a base for the properties description, also documenting some ad-hoc
> properties that have been introduced over time despite having direct analogs in
> ePAPR.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied, thanks Sergei.
^ permalink raw reply
* Re: [PATCH] Drivers: net: ethernet: 3com: 3c589_cs fixed coding style issues
From: David Miller @ 2014-02-18 22:00 UTC (permalink / raw)
To: justinvanwijngaarden
Cc: paul.gortmaker, gregkh, hsweeten, netdev, linux-kernel
In-Reply-To: <1392677926-13219-1-git-send-email-justinvanwijngaarden@gmail.com>
From: Justin van Wijngaarden <justinvanwijngaarden@gmail.com>
Date: Mon, 17 Feb 2014 23:58:46 +0100
> checkpatch.pl clean-up, from 14 error/ 277 warnings, to 0 errors, 7 warnings
>
> Signed-off-by: Justin van Wijngaarden <justinvanwijngaarden@gmail.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: pull request: wireless 2014-02-17
From: David Miller @ 2014-02-18 21:58 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20140217223921.GA29923@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Mon, 17 Feb 2014 17:39:21 -0500
> Please pull this batch of fixes intended for the 3.14 stream...
>
> For the iwlwifi one, Emmanuel says:
>
> "As explicitly written in the commit message, we prefer to disable Tx
> AMPDU on NICs supported by iwldvm. This feature gives a big boost in
> Tx performance, but the firmware is buggy and we can't rely on it.
> Our hope is that most of the users out there want wifi to surf on
> the web which means that they care more for Rx traffic than for Tx.
> People who want to enable it can do so with the help of a module
> parameter."
>
> On top of that...
>
> Dan Carpenter fixes a typo/thinko in ath5k.
>
> Olivier Langlois fixes a couple of rtlwifi issues, one which leaves
> IRQs disabled too long (causing a variety of problems elsewhere),
> and one which fixes an incorrect return code when failing to enable
> the NIC.
>
> Russell King fixes a NULL pointer dereference in hostap.
>
> Stanislaw Gruszka fixes a DMA coherence issue in the rtl8187 driver.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
^ permalink raw reply
* Re: [patch net-next] rtnl: make ifla_policy static
From: Jiri Pirko @ 2014-02-18 21:51 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Patrick McHardy,
Stephen Hemminger, vyasevic, jbenc
In-Reply-To: <CAM_iQpUzp7xkj21dyzzXRjZgyO+z5+k4cDM9LoYkzy4OL8807w@mail.gmail.com>
Tue, Feb 18, 2014 at 10:40:55PM CET, xiyou.wangcong@gmail.com wrote:
>On Tue, Feb 18, 2014 at 11:53 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> The only place this is used outside rtnetlink.c is veth. So provide
>> wrapper function for this usage.
>
>Looks good. Or make rtnl_nla_parse_ifla() static inline?
Not possible if we want to kill ifla_policy export...
^ 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