Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral
From: Florian Fainelli @ 2017-05-18 18:25 UTC (permalink / raw)
  To: Geert Uytterhoeven, Andrew Lunn, Rob Herring, Frank Rowand
  Cc: Thomas Petazzoni, Sergei Shtylyov, netdev, devicetree,
	linux-renesas-soc, linux-kernel
In-Reply-To: <1495112345-24795-1-git-send-email-geert+renesas@glider.be>

On 05/18/2017 05:59 AM, Geert Uytterhoeven wrote:
> If an Ethernet PHY is initialized before the interrupt controller it is
> connected to, a message like the following is printed:
> 
>     irq: no irq domain found for /interrupt-controller@e61c0000 !
> 
> However, the actual error is ignored, leading to a non-functional (-1)
> PHY interrupt later:
> 
>     Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY driver [Micrel KSZ8041RNLI] (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=-1)
> 
> Depending on whether the PHY driver will fall back to polling, Ethernet
> may or may not work.
> 
> To fix this:
>   1. Switch of_mdiobus_register_phy() from irq_of_parse_and_map() to
>      of_irq_get().
>      Unlike the former, the latter returns -EPROBE_DEFER if the
>      interrupt controller is not yet available, so this condition can be
>      detected.
>      Other errors are handled the same as before, i.e. use the passed
>      mdio->irq[addr] as interrupt.
>   2. Propagate and handle errors from of_mdiobus_register_phy() and
>      of_mdiobus_register_device().

This most certainly works fine in the simple case where you have one PHY
hanging off the MDIO bus, now what happens if you have several?

Presumably, the first PHY that returns EPROBE_DEFER will make the entire
bus registration return EPROB_DEFER as well, and so on, and so forth,
but I am not sure if we will be properly unwinding the successful
registration of PHYs that either don't have an interrupt, or did not
return EPROBE_DEFER.

It should be possible to mimic this behavior by using the fixed PHY, and
possibly the dsa_loop.c driver which would create 4 ports, expecting 4
fixed PHYs to be present.

> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Seen on r8a7791/koelsch when using the new CPG/MSSR clock driver.
> I assume it always happened on RZ/G1 in mainline.
> ---
>  drivers/of/of_mdio.c | 39 +++++++++++++++++++++++++++------------
>  1 file changed, 27 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
> index 7e4c80f9b6cda0d3..f9ac2893f56184be 100644
> --- a/drivers/of/of_mdio.c
> +++ b/drivers/of/of_mdio.c
> @@ -44,7 +44,7 @@ static int of_get_phy_id(struct device_node *device, u32 *phy_id)
>  	return -EINVAL;
>  }
>  
> -static void of_mdiobus_register_phy(struct mii_bus *mdio,
> +static int of_mdiobus_register_phy(struct mii_bus *mdio,
>  				    struct device_node *child, u32 addr)
>  {
>  	struct phy_device *phy;
> @@ -60,9 +60,13 @@ static void of_mdiobus_register_phy(struct mii_bus *mdio,
>  	else
>  		phy = get_phy_device(mdio, addr, is_c45);
>  	if (IS_ERR(phy))
> -		return;
> +		return PTR_ERR(phy);
>  
> -	rc = irq_of_parse_and_map(child, 0);
> +	rc = of_irq_get(child, 0);
> +	if (rc == -EPROBE_DEFER) {
> +		phy_device_free(phy);
> +		return rc;
> +	}
>  	if (rc > 0) {
>  		phy->irq = rc;
>  		mdio->irq[addr] = rc;
> @@ -84,22 +88,23 @@ static void of_mdiobus_register_phy(struct mii_bus *mdio,
>  	if (rc) {
>  		phy_device_free(phy);
>  		of_node_put(child);
> -		return;
> +		return rc;
>  	}
>  
>  	dev_dbg(&mdio->dev, "registered phy %s at address %i\n",
>  		child->name, addr);
> +	return 0;
>  }
>  
> -static void of_mdiobus_register_device(struct mii_bus *mdio,
> -				       struct device_node *child, u32 addr)
> +static int of_mdiobus_register_device(struct mii_bus *mdio,
> +				      struct device_node *child, u32 addr)
>  {
>  	struct mdio_device *mdiodev;
>  	int rc;
>  
>  	mdiodev = mdio_device_create(mdio, addr);
>  	if (IS_ERR(mdiodev))
> -		return;
> +		return PTR_ERR(mdiodev);
>  
>  	/* Associate the OF node with the device structure so it
>  	 * can be looked up later.
> @@ -112,11 +117,12 @@ static void of_mdiobus_register_device(struct mii_bus *mdio,
>  	if (rc) {
>  		mdio_device_free(mdiodev);
>  		of_node_put(child);
> -		return;
> +		return rc;
>  	}
>  
>  	dev_dbg(&mdio->dev, "registered mdio device %s at address %i\n",
>  		child->name, addr);
> +	return 0;
>  }
>  
>  int of_mdio_parse_addr(struct device *dev, const struct device_node *np)
> @@ -242,9 +248,11 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
>  		}
>  
>  		if (of_mdiobus_child_is_phy(child))
> -			of_mdiobus_register_phy(mdio, child, addr);
> +			rc = of_mdiobus_register_phy(mdio, child, addr);
>  		else
> -			of_mdiobus_register_device(mdio, child, addr);
> +			rc = of_mdiobus_register_device(mdio, child, addr);
> +		if (rc)
> +			goto unregister;
>  	}
>  
>  	if (!scanphys)
> @@ -265,12 +273,19 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
>  			dev_info(&mdio->dev, "scan phy %s at address %i\n",
>  				 child->name, addr);
>  
> -			if (of_mdiobus_child_is_phy(child))
> -				of_mdiobus_register_phy(mdio, child, addr);
> +			if (of_mdiobus_child_is_phy(child)) {
> +				rc = of_mdiobus_register_phy(mdio, child, addr);
> +				if (rc)
> +					goto unregister;
> +			}
>  		}
>  	}
>  
>  	return 0;
> +
> +unregister:
> +	mdiobus_unregister(mdio);
> +	return rc;
>  }
>  EXPORT_SYMBOL(of_mdiobus_register);
>  
> 


-- 
Florian

^ permalink raw reply

* Re: [PATCH net-next] xen/9pfs: p9_trans_xen_init and p9_trans_xen_exit can be static
From: Stefano Stabellini @ 2017-05-18 18:40 UTC (permalink / raw)
  To: Wei Yongjun
  Cc: Eric Van Hensbergen, Ron Minnich, Latchesar Ionkov,
	Stefano Stabellini, Juergen Gross, Wei Yongjun, v9fs-developer,
	netdev, boris.ostrovsky, jgross
In-Reply-To: <20170518152241.4830-1-weiyj.lk@gmail.com>

On Thu, 18 May 2017, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
> 
> Fixes the following sparse warnings:
> 
> net/9p/trans_xen.c:528:5: warning:
>  symbol 'p9_trans_xen_init' was not declared. Should it be static?
> net/9p/trans_xen.c:540:6: warning:
>  symbol 'p9_trans_xen_exit' was not declared. Should it be static?
> 
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

If that's OK for everybody we'll queue this fix and
20170516142247.12301-1-weiyj.lk@gmail.com to the xentip tree.


> ---
>  net/9p/trans_xen.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
> index 71e8564..3deb17f 100644
> --- a/net/9p/trans_xen.c
> +++ b/net/9p/trans_xen.c
> @@ -525,7 +525,7 @@ static struct xenbus_driver xen_9pfs_front_driver = {
>  	.otherend_changed = xen_9pfs_front_changed,
>  };
>  
> -int p9_trans_xen_init(void)
> +static int p9_trans_xen_init(void)
>  {
>  	if (!xen_domain())
>  		return -ENODEV;
> @@ -537,7 +537,7 @@ int p9_trans_xen_init(void)
>  }
>  module_init(p9_trans_xen_init);
>  
> -void p9_trans_xen_exit(void)
> +static void p9_trans_xen_exit(void)
>  {
>  	v9fs_unregister_trans(&p9_xen_trans);
>  	return xenbus_unregister_driver(&xen_9pfs_front_driver);
> 

^ permalink raw reply

* Re: [PATCH v2 1/3] bpf: Use 1<<16 as ceiling for immediate alignment in verifier.
From: Edward Cree @ 2017-05-18 18:41 UTC (permalink / raw)
  To: Alexei Starovoitov, David Miller, Daniel Borkmann
  Cc: alexei.starovoitov, netdev
In-Reply-To: <739ef342-728c-de57-c2a2-03fa85b3a246@solarflare.com>

Implementations (still in Python for now) at
https://gist.github.com/ecree-solarflare/0665d5b46c2d8d08de2377fbd527de8d
(I left out division, because it's so weak.)

I still can't prove + and - are correct, but they've passed every test
 case I've come up with so far.  * seems pretty obviously correct as long
 as the + it uses is.  Bitwise ops and shifts are trivial to prove.

-Ed

^ permalink raw reply

* Re: [PATCH] r8152: Remove unused function usb_ocp_read()
From: David Miller @ 2017-05-18 18:46 UTC (permalink / raw)
  To: mka; +Cc: hayeswang, linux-usb, netdev, linux-kernel
In-Reply-To: <20170518174533.79413-1-mka@chromium.org>

From: Matthias Kaehlcke <mka@chromium.org>
Date: Thu, 18 May 2017 10:45:33 -0700

> The function is not used, removing it fixes the following warning when
> building with clang:
> 
> drivers/net/usb/r8152.c:825:5: error: unused function 'usb_ocp_read'
>     [-Werror,-Wunused-function]
> 
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

Applied to net-next.

^ permalink raw reply

* Re: [PATCH] net1080: Remove unused function nc_dump_ttl()
From: David Miller @ 2017-05-18 18:46 UTC (permalink / raw)
  To: mka; +Cc: linux-usb, netdev, linux-kernel
In-Reply-To: <20170518175719.103143-1-mka@chromium.org>

From: Matthias Kaehlcke <mka@chromium.org>
Date: Thu, 18 May 2017 10:57:19 -0700

> The function is not used, removing it fixes the following warning when
> building with clang:
> 
> drivers/net/usb/net1080.c:271:20: error: unused function
>     'nc_dump_ttl' [-Werror,-Wunused-function]
> 
> Also remove the definition of TTL_THIS, which is only used in
> nc_dump_ttl()
> 
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

Applied to net-next.

^ permalink raw reply

* Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral
From: Geert Uytterhoeven @ 2017-05-18 18:48 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Geert Uytterhoeven, Andrew Lunn, Rob Herring, Frank Rowand,
	Thomas Petazzoni, Sergei Shtylyov, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, Linux-Renesas,
	linux-kernel@vger.kernel.org
In-Reply-To: <f0ed61c3-062b-cec6-fe19-7412231e8ef1@gmail.com>

Hi Florian,

On Thu, May 18, 2017 at 8:25 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 05/18/2017 05:59 AM, Geert Uytterhoeven wrote:
>> If an Ethernet PHY is initialized before the interrupt controller it is
>> connected to, a message like the following is printed:
>>
>>     irq: no irq domain found for /interrupt-controller@e61c0000 !
>>
>> However, the actual error is ignored, leading to a non-functional (-1)
>> PHY interrupt later:
>>
>>     Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY driver [Micrel KSZ8041RNLI] (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=-1)
>>
>> Depending on whether the PHY driver will fall back to polling, Ethernet
>> may or may not work.
>>
>> To fix this:
>>   1. Switch of_mdiobus_register_phy() from irq_of_parse_and_map() to
>>      of_irq_get().
>>      Unlike the former, the latter returns -EPROBE_DEFER if the
>>      interrupt controller is not yet available, so this condition can be
>>      detected.
>>      Other errors are handled the same as before, i.e. use the passed
>>      mdio->irq[addr] as interrupt.
>>   2. Propagate and handle errors from of_mdiobus_register_phy() and
>>      of_mdiobus_register_device().
>
> This most certainly works fine in the simple case where you have one PHY
> hanging off the MDIO bus, now what happens if you have several?
>
> Presumably, the first PHY that returns EPROBE_DEFER will make the entire
> bus registration return EPROB_DEFER as well, and so on, and so forth,
> but I am not sure if we will be properly unwinding the successful
> registration of PHYs that either don't have an interrupt, or did not
> return EPROBE_DEFER.
>
> It should be possible to mimic this behavior by using the fixed PHY, and
> possibly the dsa_loop.c driver which would create 4 ports, expecting 4
> fixed PHYs to be present.

mdiobus_unregister(), called from of_mdiobus_register() on failure,
should do the unwinding, right?

And when the driver is reprobed, all PHYs are reprobed, until they all
succeed.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* Paper: A Comparison of TCP Implementations, Linux vs. lwIP
From: Richard Siegfried @ 2017-05-18 19:13 UTC (permalink / raw)
  To: lwip-devel, netdev


[-- Attachment #1.1.1: Type: text/plain, Size: 528 bytes --]

Hello,

Some months ago I wrote a paper on a Comparison of TCP Implementations.
(Features, Code Quality, Data Structures, etc.)

https://github.com/richi235/A-Comparison-of-TCP-Implementations

It's finished and the corresponding exam successfully passed.
But I thought perhaps this could be interesting for some people here, too.

And since im still interested in and reading about TCP Implementations
I'm thankfull for any feedback, corrections or opinions about the
conclusions I found.

Thanks,
-- Richard


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 529 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
lwip-devel mailing list
lwip-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel

^ permalink raw reply

* Re: [PATCH net-next] ibmvnic: fix missing unlock on error in __ibmvnic_reset()
From: David Miller @ 2017-05-18 19:18 UTC (permalink / raw)
  To: weiyj.lk
  Cc: benh, paulus, mpe, tlfalcon, jallen, nfont, weiyongjun1,
	linuxppc-dev, netdev
In-Reply-To: <20170518152452.8606-1-weiyj.lk@gmail.com>

From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Thu, 18 May 2017 15:24:52 +0000

> From: Wei Yongjun <weiyongjun1@huawei.com>
> 
> Add the missing unlock before return from function __ibmvnic_reset()
> in the error handling case.
> 
> Fixes: ed651a10875f ("ibmvnic: Updated reset handling")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] qed: Remove unused including <linux/version.h>
From: David Miller @ 2017-05-18 19:19 UTC (permalink / raw)
  To: weiyj.lk; +Cc: Yuval.Mintz, Ariel.Elior, weiyongjun1, everest-linux-l2, netdev
In-Reply-To: <20170518152629.12503-1-weiyj.lk@gmail.com>

From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Thu, 18 May 2017 15:26:29 +0000

> From: Wei Yongjun <weiyongjun1@huawei.com>
> 
> Remove including <linux/version.h> that is not needed.
> 
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] net/mlx5e: Fix possible memory leak
From: David Miller @ 2017-05-18 19:19 UTC (permalink / raw)
  To: weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w
  Cc: saeedm-VPRAkNaXOzVWk0Htik3J/w, matanb-VPRAkNaXOzVWk0Htik3J/w,
	leonro-VPRAkNaXOzVWk0Htik3J/w, hadarh-VPRAkNaXOzVWk0Htik3J/w,
	weiyongjun1-hv44wF8Li93QT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-rdma-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170518153441.24398-1-weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

From: Wei Yongjun <weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 18 May 2017 15:34:41 +0000

> From: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> 
> 'encap_header' is malloced and should be freed before leaving from
> the error handling cases, otherwise it will cause memory leak.
> 
> Fixes: 232c001398ae ("net/mlx5e: Add support to neighbour update flow")
> Signed-off-by: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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

* Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral
From: Andrew Lunn @ 2017-05-18 19:34 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Florian Fainelli, Geert Uytterhoeven, Rob Herring, Frank Rowand,
	Thomas Petazzoni, Sergei Shtylyov, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, Linux-Renesas,
	linux-kernel@vger.kernel.org
In-Reply-To: <CAMuHMdWYeSzofU57LmT_M3KkcHhvjfJy7nkHvcXkKzOYmvhqqA@mail.gmail.com>

> > This most certainly works fine in the simple case where you have one PHY
> > hanging off the MDIO bus, now what happens if you have several?
> >
> > Presumably, the first PHY that returns EPROBE_DEFER will make the entire
> > bus registration return EPROB_DEFER as well, and so on, and so forth,
> > but I am not sure if we will be properly unwinding the successful
> > registration of PHYs that either don't have an interrupt, or did not
> > return EPROBE_DEFER.
> >
> > It should be possible to mimic this behavior by using the fixed PHY, and
> > possibly the dsa_loop.c driver which would create 4 ports, expecting 4
> > fixed PHYs to be present.
> 
> mdiobus_unregister(), called from of_mdiobus_register() on failure,
> should do the unwinding, right?
> 
> And when the driver is reprobed, all PHYs are reprobed, until they all
> succeed.

That is the theory. I looked at that while reviewing the patch. But
this has probably not been tested in anger. It would be good to test
this properly, with not just the first PHY returning -EPROBE_DEFER, to
really test the unwind.

    Andrew

^ permalink raw reply

* Re: [PATCH v5 net-next 5/7] net: fix documentation of struct scm_timestamping
From: Willem de Bruijn @ 2017-05-18 19:38 UTC (permalink / raw)
  To: Miroslav Lichvar; +Cc: Network Development, Richard Cochran, Willem de Bruijn
In-Reply-To: <20170518140738.19617-6-mlichvar@redhat.com>

On Thu, May 18, 2017 at 10:07 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> The scm_timestamping struct may return multiple non-zero fields, e.g.
> when both software and hardware RX timestamping is enabled, or when the
> SO_TIMESTAMP(NS) option is combined with SCM_TIMESTAMPING and a false
> software timestamp is generated in the recvmsg() call in order to always
> return a SCM_TIMESTAMP(NS) message.
>
> CC: Richard Cochran <richardcochran@gmail.com>
> CC: Willem de Bruijn <willemb@google.com>
> Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>

Thanks for adding this!

> +Note that if the SO_TIMESTAMP or SO_TIMESTAMPNS option is enabled
> +together with SO_TIMESTAMPING using SOF_TIMESTAMPING_SOFTWARE, a false
> +software timestamp will be generated in the recvmsg() call and passed
> +in ts[0] when a real software timestamp is missing.

With receive software timestamping this is expected behavior? I would make
explicit that this happens even on tx timestamps.

> For this reason it
> +is not recommended to combine SO_TIMESTAMP(NS) with SO_TIMESTAMPING.

And I'd remove this. The extra timestamp is harmless, and we may be missing
other reasons why someone would want to enable both on the same socket.

^ permalink raw reply

* [PATCH v2 0/4] arp: always override existing neigh entries with gratuitous ARP
From: Ihar Hrachyshka @ 2017-05-18 19:41 UTC (permalink / raw)
  To: davem, ja; +Cc: Ihar Hrachyshka, netdev

This patchset is spurred by discussion started at
https://patchwork.ozlabs.org/patch/760372/ where we figured that there is no
real reason for enforcing override by gratuitous ARP packets only when
arp_accept is 1. Same should happen when it's 0 (the default value).

changelog v2: handled review comments by Julian Anastasov
- fixed a mistake in a comment;
- postponed addr_type calculation to as late as possible.

Ihar Hrachyshka (4):
  arp: fixed error in a comment
  arp: decompose is_garp logic into a separate function
  arp: postpone addr_type calculation to as late as possible
  arp: always override existing neigh entries with gratuitous ARP

 net/ipv4/arp.c | 56 +++++++++++++++++++++++++++++++++++++++-----------------
 1 file changed, 39 insertions(+), 17 deletions(-)

-- 
2.9.3

^ permalink raw reply

* [PATCH v2 1/4] arp: fixed error in a comment
From: Ihar Hrachyshka @ 2017-05-18 19:41 UTC (permalink / raw)
  To: davem, ja; +Cc: Ihar Hrachyshka, netdev
In-Reply-To: <cover.1495136258.git.ihrachys@redhat.com>

the is_garp code deals just with gratuitous ARP packets, not every
unsolicited packet.

This patch is a result of a discussion in netdev:
http://marc.info/?l=linux-netdev&m=149506354216994

Suggested-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>
---
 net/ipv4/arp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index d54345a..053492a 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -846,7 +846,7 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
 		 */
 		is_garp = tip == sip && addr_type == RTN_UNICAST;
 
-		/* Unsolicited ARP _replies_ also require target hwaddr to be
+		/* Gratuitous ARP _replies_ also require target hwaddr to be
 		 * the same as source.
 		 */
 		if (is_garp && arp->ar_op == htons(ARPOP_REPLY))
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 2/4] arp: decompose is_garp logic into a separate function
From: Ihar Hrachyshka @ 2017-05-18 19:41 UTC (permalink / raw)
  To: davem, ja; +Cc: Ihar Hrachyshka, netdev
In-Reply-To: <cover.1495136258.git.ihrachys@redhat.com>

The code is quite involving already to earn a separate function for
itself. If anything, it helps arp_process readability.

Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>
---
 net/ipv4/arp.c | 35 +++++++++++++++++++++++------------
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 053492a..ca6e1e6 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -641,6 +641,27 @@ void arp_xmit(struct sk_buff *skb)
 }
 EXPORT_SYMBOL(arp_xmit);
 
+static bool arp_is_garp(struct net_device *dev, int addr_type,
+			__be16 ar_op,
+			__be32 sip, __be32 tip,
+			unsigned char *sha, unsigned char *tha)
+{
+	bool is_garp = tip == sip && addr_type == RTN_UNICAST;
+
+	/* Gratuitous ARP _replies_ also require target hwaddr to be
+	 * the same as source.
+	 */
+	if (is_garp && ar_op == htons(ARPOP_REPLY))
+		is_garp =
+			/* IPv4 over IEEE 1394 doesn't provide target
+			 * hardware address field in its ARP payload.
+			 */
+			tha &&
+			!memcmp(tha, sha, dev->addr_len);
+
+	return is_garp;
+}
+
 /*
  *	Process an arp request.
  */
@@ -844,18 +865,8 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
 		   It is possible, that this option should be enabled for some
 		   devices (strip is candidate)
 		 */
-		is_garp = tip == sip && addr_type == RTN_UNICAST;
-
-		/* Gratuitous ARP _replies_ also require target hwaddr to be
-		 * the same as source.
-		 */
-		if (is_garp && arp->ar_op == htons(ARPOP_REPLY))
-			is_garp =
-				/* IPv4 over IEEE 1394 doesn't provide target
-				 * hardware address field in its ARP payload.
-				 */
-				tha &&
-				!memcmp(tha, sha, dev->addr_len);
+		is_garp = arp_is_garp(dev, addr_type, arp->ar_op,
+				      sip, tip, sha, tha);
 
 		if (!n &&
 		    ((arp->ar_op == htons(ARPOP_REPLY)  &&
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 3/4] arp: postpone addr_type calculation to as late as possible
From: Ihar Hrachyshka @ 2017-05-18 19:41 UTC (permalink / raw)
  To: davem, ja; +Cc: Ihar Hrachyshka, netdev
In-Reply-To: <cover.1495136258.git.ihrachys@redhat.com>

The addr_type retrieval can be costly, so it's worth trying to avoid its
calculation as much as possible. This patch makes it calculated only
for gratuitous ARP packets. This is especially important since later we
may want to move is_garp calculation outside of arp_accept block, at
which point the costly operation will be executed for all setups.

The patch is the result of a discussion in net-dev:
http://marc.info/?l=linux-netdev&m=149506354216994

Suggested-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>
---
 net/ipv4/arp.c | 24 +++++++++++++++++-------
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index ca6e1e6..c22103c 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -641,12 +641,12 @@ void arp_xmit(struct sk_buff *skb)
 }
 EXPORT_SYMBOL(arp_xmit);
 
-static bool arp_is_garp(struct net_device *dev, int addr_type,
-			__be16 ar_op,
+static bool arp_is_garp(struct net *net, struct net_device *dev,
+			int *addr_type, __be16 ar_op,
 			__be32 sip, __be32 tip,
 			unsigned char *sha, unsigned char *tha)
 {
-	bool is_garp = tip == sip && addr_type == RTN_UNICAST;
+	bool is_garp = tip == sip;
 
 	/* Gratuitous ARP _replies_ also require target hwaddr to be
 	 * the same as source.
@@ -659,6 +659,11 @@ static bool arp_is_garp(struct net_device *dev, int addr_type,
 			tha &&
 			!memcmp(tha, sha, dev->addr_len);
 
+	if (is_garp) {
+		*addr_type = inet_addr_type_dev_table(net, dev, sip);
+		if (*addr_type != RTN_UNICAST)
+			is_garp = false;
+	}
 	return is_garp;
 }
 
@@ -859,18 +864,23 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
 	n = __neigh_lookup(&arp_tbl, &sip, dev, 0);
 
 	if (IN_DEV_ARP_ACCEPT(in_dev)) {
-		unsigned int addr_type = inet_addr_type_dev_table(net, dev, sip);
+		addr_type = -1;
 
 		/* Unsolicited ARP is not accepted by default.
 		   It is possible, that this option should be enabled for some
 		   devices (strip is candidate)
 		 */
-		is_garp = arp_is_garp(dev, addr_type, arp->ar_op,
+		is_garp = arp_is_garp(net, dev, &addr_type, arp->ar_op,
 				      sip, tip, sha, tha);
 
 		if (!n &&
-		    ((arp->ar_op == htons(ARPOP_REPLY)  &&
-				addr_type == RTN_UNICAST) || is_garp))
+		    (is_garp ||
+		     (arp->ar_op == htons(ARPOP_REPLY) &&
+		      (addr_type == RTN_UNICAST ||
+		       (addr_type < 0 &&
+			/* postpone calculation to as late as possible */
+			inet_addr_type_dev_table(net, dev, sip) ==
+				RTN_UNICAST)))))
 			n = __neigh_lookup(&arp_tbl, &sip, dev, 1);
 	}
 
-- 
2.9.3

^ permalink raw reply related

* [PATCH v2 4/4] arp: always override existing neigh entries with gratuitous ARP
From: Ihar Hrachyshka @ 2017-05-18 19:41 UTC (permalink / raw)
  To: davem, ja; +Cc: Ihar Hrachyshka, netdev
In-Reply-To: <cover.1495136258.git.ihrachys@redhat.com>

Currently, when arp_accept is 1, we always override existing neigh
entries with incoming gratuitous ARP replies. Otherwise, we override
them only if new replies satisfy _locktime_ conditional (packets arrive
not earlier than _locktime_ seconds since the last update to the neigh
entry).

The idea behind locktime is to pick the very first (=> close) reply
received in a unicast burst when ARP proxies are used. This helps to
avoid ARP thrashing where Linux would switch back and forth from one
proxy to another.

This logic has nothing to do with gratuitous ARP replies that are
generally not aligned in time when multiple IP address carriers send
them into network.

This patch enforces overriding of existing neigh entries by all incoming
gratuitous ARP packets, irrespective of their time of arrival. This will
make the kernel honour all incoming gratuitous ARP packets.

Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>
---
 net/ipv4/arp.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index c22103c..ae96e6f 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -863,16 +863,17 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb)
 
 	n = __neigh_lookup(&arp_tbl, &sip, dev, 0);
 
-	if (IN_DEV_ARP_ACCEPT(in_dev)) {
+	if (n || IN_DEV_ARP_ACCEPT(in_dev)) {
 		addr_type = -1;
+		is_garp = arp_is_garp(net, dev, &addr_type, arp->ar_op,
+				      sip, tip, sha, tha);
+	}
 
+	if (IN_DEV_ARP_ACCEPT(in_dev)) {
 		/* Unsolicited ARP is not accepted by default.
 		   It is possible, that this option should be enabled for some
 		   devices (strip is candidate)
 		 */
-		is_garp = arp_is_garp(net, dev, &addr_type, arp->ar_op,
-				      sip, tip, sha, tha);
-
 		if (!n &&
 		    (is_garp ||
 		     (arp->ar_op == htons(ARPOP_REPLY) &&
-- 
2.9.3

^ permalink raw reply related

* [PATCH net-next] geneve: always fill CSUM6_RX configuration
From: Eric Garver @ 2017-05-18 19:59 UTC (permalink / raw)
  To: netdev; +Cc: pravin shelar

CSMU6_RX is relevant for collect_metadata as well. As such leave it
outside of the dev's IPv4/IPv6 checks.

Fixes: 9b4437a5b870 ("geneve: Unify LWT and netdev handling.")
Signed-off-by: Eric Garver <e@erig.me>
---
 drivers/net/geneve.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index dec5d563ab19..f557d1dc3f9b 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -1311,13 +1311,13 @@ static int geneve_fill_info(struct sk_buff *skb, const struct net_device *dev)
 		if (nla_put_u8(skb, IFLA_GENEVE_UDP_ZERO_CSUM6_TX,
 			       !(info->key.tun_flags & TUNNEL_CSUM)))
 			goto nla_put_failure;
-
-		if (nla_put_u8(skb, IFLA_GENEVE_UDP_ZERO_CSUM6_RX,
-			       !geneve->use_udp6_rx_checksums))
-			goto nla_put_failure;
 #endif
 	}
 
+	if (nla_put_u8(skb, IFLA_GENEVE_UDP_ZERO_CSUM6_RX,
+		       !geneve->use_udp6_rx_checksums))
+		goto nla_put_failure;
+
 	if (nla_put_u8(skb, IFLA_GENEVE_TTL, info->key.ttl) ||
 	    nla_put_u8(skb, IFLA_GENEVE_TOS, info->key.tos) ||
 	    nla_put_be32(skb, IFLA_GENEVE_LABEL, info->key.label))
-- 
2.12.0

^ permalink raw reply related

* Re: [PATCH v1] samples/bpf: Add a .gitignore for binaries
From: David Ahern @ 2017-05-18 20:03 UTC (permalink / raw)
  To: Alexander Alemayhu
  Cc: Mickaël Salaün, Alexei Starovoitov, Daniel Borkmann,
	linux-kernel, Arnaldo Carvalho de Melo, Wang Nan, netdev
In-Reply-To: <20170517081844.GA4447@gmail.com>

On 5/17/17 1:18 AM, Alexander Alemayhu wrote:
> I have looked into this but found it to be not easy and all attempts to
> change the Makefile has resulted in obscure errors :/
> 
> Getting clang to output in a different directory was easy[0], but I guess
> this is not the right approach either. Have you tried making the change?

spent an hour so a few weeks back. It is not trivial, but someone needs
to find to fix it now.

perf is the example to use: you can build it from both top level kernel
directory (e.g, make -C tools/perf O=/tmp/perf) and the perf directory
(cd tools/perf; make O=/tmp/perf). Both are wanted for samples/bpf and
it would be nice to keep the O= option as well.

I don't have the time for the next few weeks. Perhaps mid-June I can
take a look.

^ permalink raw reply

* Re: [PATCH v4 net-next 6/7] net: allow simultaneous SW and HW transmit timestamping
From: Willem de Bruijn @ 2017-05-18 20:16 UTC (permalink / raw)
  To: Miroslav Lichvar; +Cc: Network Development, Richard Cochran, Willem de Bruijn
In-Reply-To: <20170518130656.24163-7-mlichvar@redhat.com>

On Thu, May 18, 2017 at 9:06 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> Add SOF_TIMESTAMPING_OPT_TX_SWHW option to allow an outgoing packet to
> be looped to the socket's error queue with a software timestamp even
> when a hardware transmit timestamp is expected to be provided by the
> driver.
>
> Applications using this option will receive two separate messages from
> the error queue, one with a software timestamp and the other with a
> hardware timestamp. As the hardware timestamp is saved to the shared skb
> info, which may happen before the first message with software timestamp
> is received by the application, the hardware timestamp is copied to the
> SCM_TIMESTAMPING control message only when the skb has no software
> timestamp or it is an incoming packet.
>
> While changing sw_tx_timestamp(), inline it in skb_tx_timestamp() as
> there are no other users.
>
> CC: Richard Cochran <richardcochran@gmail.com>
> CC: Willem de Bruijn <willemb@google.com>
> Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>
> ---

> +/* On transmit, software and hardware timestamps are returned independently.
> + * As the two skb clones share the hardware timestamp, which may be updated
> + * before the software timestamp is received, a hardware TX timestamp may be
> + * returned only if there is no software TX timestamp. A false software
> + * timestamp made for SOCK_RCVTSTAMP when a real timestamp is missing must
> + * be ignored.

Please expand on why this case can be ignored. It is quite subtle. How about
something like

*
* A false software timestamp is one made inside the __sock_recv_timestamp
* call itself. These are generated whenever SO_TIMESTAMP(NS) is enabled
* on the socket, even when the timestamp reported is for another option, such
* as hardware tx timestamp.
*
* Ignore these when deciding whether a timestamp source is hw or sw.
*/

And perhaps move the comment to the branch itself.

> + */
> +static bool skb_is_swtx_tstamp(const struct sk_buff *skb,
> +                              const struct sock *sk, int false_tstamp)
> +{
> +       if (false_tstamp && sk->sk_tsflags & SOF_TIMESTAMPING_OPT_TX_SWHW)

Also, why is it ignored only for the new mode?

> +               return 0;
> +
> +       return skb->tstamp && skb_is_err_queue(skb);
> +}

^ permalink raw reply

* Re: [PATCH v5 net-next 4/7] net: add new control message for incoming HW-timestamped packets
From: Willem de Bruijn @ 2017-05-18 20:20 UTC (permalink / raw)
  To: Miroslav Lichvar; +Cc: Network Development, Richard Cochran, Willem de Bruijn
In-Reply-To: <20170518140738.19617-5-mlichvar@redhat.com>

On Thu, May 18, 2017 at 10:07 AM, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> Add SOF_TIMESTAMPING_OPT_PKTINFO option to request a new control message
> for incoming packets with hardware timestamps. It contains the index of
> the real interface which received the packet and the length of the
> packet at layer 2.
>
> The index is useful with bonding, bridges and other interfaces, where
> IP_PKTINFO doesn't allow applications to determine which PHC made the
> timestamp. With the L2 length (and link speed) it is possible to
> transpose preamble timestamps to trailer timestamps, which are used in
> the NTP protocol.
>
> While this information could be provided by two new socket options
> independently from timestamping, it doesn't look like they would be very
> useful. With this option any performance impact is limited to hardware
> timestamping.
>
> Use dev_get_by_napi_id() to get the device and its index. On kernels
> with disabled CONFIG_NET_RX_BUSY_POLL or drivers not using NAPI, a zero
> index will be returned in the control message.
>
> CC: Richard Cochran <richardcochran@gmail.com>
> CC: Willem de Bruijn <willemb@google.com>
> Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com>

Acked-by: Willem de Bruijn <willemb@google.com>

> +SOF_TIMESTAMPING_OPT_PKTINFO:
> +
> +  Enable the SCM_TIMESTAMPING_PKTINFO control message for incoming
> +  packets with hardware timestamps. The message contains struct
> +  scm_ts_pktinfo, which supplies the index of the real interface which
> +  received the packet and its length at layer 2. A valid (non-zero)
> +  interface index will be returned only if CONFIG_NET_RX_BUSY_POLL is
> +  enabled and the driver is using NAPI.

It is probably good to explicitly call out that the remaining two fields
are reserved and undefined. To stress that applications cannot be
overly pedantic and start failing if these become non-zero.

^ permalink raw reply

* Re: [PATCH] of_mdio: Fix broken PHY IRQ in case of probe deferral
From: Geert Uytterhoeven @ 2017-05-18 20:36 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Florian Fainelli, Geert Uytterhoeven, Rob Herring, Frank Rowand,
	Thomas Petazzoni, Sergei Shtylyov, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, Linux-Renesas,
	linux-kernel@vger.kernel.org
In-Reply-To: <20170518193453.GB13759@lunn.ch>

Hi Andrew,

On Thu, May 18, 2017 at 9:34 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > This most certainly works fine in the simple case where you have one PHY
>> > hanging off the MDIO bus, now what happens if you have several?
>> >
>> > Presumably, the first PHY that returns EPROBE_DEFER will make the entire
>> > bus registration return EPROB_DEFER as well, and so on, and so forth,
>> > but I am not sure if we will be properly unwinding the successful
>> > registration of PHYs that either don't have an interrupt, or did not
>> > return EPROBE_DEFER.
>> >
>> > It should be possible to mimic this behavior by using the fixed PHY, and
>> > possibly the dsa_loop.c driver which would create 4 ports, expecting 4
>> > fixed PHYs to be present.
>>
>> mdiobus_unregister(), called from of_mdiobus_register() on failure,
>> should do the unwinding, right?
>>
>> And when the driver is reprobed, all PHYs are reprobed, until they all
>> succeed.
>
> That is the theory. I looked at that while reviewing the patch. But
> this has probably not been tested in anger. It would be good to test
> this properly, with not just the first PHY returning -EPROBE_DEFER, to
> really test the unwind.

Unfortunately I don't have a board with multiple PHYs, so I cannot test
that case.

Does unbinding/rebinding a network driver with multiple PHYs currently
work? Or module unload/reload?

That should exercise a similar code path.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* Re: [PATCH v2 2/4] arp: decompose is_garp logic into a separate function
From: Julian Anastasov @ 2017-05-18 20:49 UTC (permalink / raw)
  To: Ihar Hrachyshka; +Cc: davem, netdev
In-Reply-To: <481737abe7a375a7efe125f4e76a998dd670a2df.1495136258.git.ihrachys@redhat.com>


	Hello,

On Thu, 18 May 2017, Ihar Hrachyshka wrote:

> The code is quite involving already to earn a separate function for
> itself. If anything, it helps arp_process readability.
> 
> Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>
> ---
>  net/ipv4/arp.c | 35 +++++++++++++++++++++++------------
>  1 file changed, 23 insertions(+), 12 deletions(-)
> 
> diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
> index 053492a..ca6e1e6 100644
> --- a/net/ipv4/arp.c
> +++ b/net/ipv4/arp.c
> @@ -641,6 +641,27 @@ void arp_xmit(struct sk_buff *skb)
>  }
>  EXPORT_SYMBOL(arp_xmit);
>  
> +static bool arp_is_garp(struct net_device *dev, int addr_type,
> +			__be16 ar_op,
> +			__be32 sip, __be32 tip,
> +			unsigned char *sha, unsigned char *tha)
> +{
> +	bool is_garp = tip == sip && addr_type == RTN_UNICAST;
> +
> +	/* Gratuitous ARP _replies_ also require target hwaddr to be
> +	 * the same as source.
> +	 */
> +	if (is_garp && ar_op == htons(ARPOP_REPLY))
> +		is_garp =
> +			/* IPv4 over IEEE 1394 doesn't provide target
> +			 * hardware address field in its ARP payload.
> +			 */
> +			tha &&

	All 4 patches look ok to me with only a small problem
which comes from patch already included in kernel. I see
that GARP replies can not work for 1394, is_garp will be
cleared. May be 'tha' check should be moved in if expression,
for example:

	if (is_garp && ar_op == htons(ARPOP_REPLY) && tha)
		is_garp = !memcmp(tha, sha, dev->addr_len);

> +			!memcmp(tha, sha, dev->addr_len);
> +
> +	return is_garp;
> +}

Regards

^ permalink raw reply

* [PATCH v2 net-next 0/2] Check all RGMII phy mode variants
From: Iyappan Subramanian @ 2017-05-18 22:13 UTC (permalink / raw)
  To: davem, netdev
  Cc: f.fainelli, andrew, linux-arm-kernel, patches,
	Iyappan Subramanian

This patch set,
     - adds phy_interface_mode_is_rgmii() helper function
     - addresses review comment from previous patch set, by calling
       phy_interface_mode_is_rgmii() to address all RGMII variants

Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
---
v2: Address review comments from v1
     - adds phy_interface_mode_is_rgmii() helper function
     - addresses review comment from previous patch set, by calling
       phy_interface_mode_is_rgmii() to address all RGMII variants
v1:
     - Initial version
---

Iyappan Subramanian (2):
  include: linux: Add helper function to check phy interface mode
  drivers: net: xgene: Check all RGMII phy mode variants

 drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c |  6 +++---
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c      | 12 ++++++------
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c    | 15 +++++++++------
 include/linux/phy.h                                 | 14 ++++++++++++--
 4 files changed, 30 insertions(+), 17 deletions(-)

-- 
1.9.1

^ permalink raw reply

* [PATCH v2 net-next 1/2] include: linux: Add helper function to check phy interface mode
From: Iyappan Subramanian @ 2017-05-18 22:13 UTC (permalink / raw)
  To: davem, netdev
  Cc: f.fainelli, andrew, linux-arm-kernel, patches,
	Iyappan Subramanian
In-Reply-To: <1495145624-29463-1-git-send-email-isubramanian@apm.com>

Added helper function that checks phy_mode is RGMII (all variants)
'bool phy_interface_mode_is_rgmii(phy_interface_t mode)'

Changed the following function, to use the above.
'bool phy_interface_is_rgmii(struct phy_device *phydev)'

Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
---
 include/linux/phy.h | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/linux/phy.h b/include/linux/phy.h
index 54ef458..5a808a2 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -716,14 +716,24 @@ static inline bool phy_is_internal(struct phy_device *phydev)
 }
 
 /**
+ * phy_interface_mode_is_rgmii - Convenience function for testing if a
+ * PHY interface mode is RGMII (all variants)
+ * @mode: the phy_interface_t enum
+ */
+static inline bool phy_interface_mode_is_rgmii(phy_interface_t mode)
+{
+	return mode >= PHY_INTERFACE_MODE_RGMII &&
+		mode <= PHY_INTERFACE_MODE_RGMII_TXID;
+};
+
+/**
  * phy_interface_is_rgmii - Convenience function for testing if a PHY interface
  * is RGMII (all variants)
  * @phydev: the phy_device struct
  */
 static inline bool phy_interface_is_rgmii(struct phy_device *phydev)
 {
-	return phydev->interface >= PHY_INTERFACE_MODE_RGMII &&
-		phydev->interface <= PHY_INTERFACE_MODE_RGMII_TXID;
+	return phy_interface_mode_is_rgmii(phydev->interface);
 };
 
 /*
-- 
1.9.1

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox