* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name"
From: Johannes Berg @ 2018-01-02 16:52 UTC (permalink / raw)
To: David Miller, mpe; +Cc: linux, michael, j, netdev, linuxppc-dev
In-Reply-To: <20180102.115008.2038929402603091054.davem@davemloft.net>
On Tue, 2018-01-02 at 11:50 -0500, David Miller wrote:
> From: Michael Ellerman <mpe@ellerman.id.au>
> Date: Fri, 22 Dec 2017 15:22:22 +1100
>
> >> On Tue, Dec 19 2017, Michael Ellerman <michael@concordia.ellerman.id.au> wrote:
> >>> This revert seems to have broken networking on one of my powerpc
> >>> machines, according to git bisect.
> >>>
> >>> The symptom is DHCP fails and I don't get a link, I didn't dig any
> >>> further than that. I can if it's helpful.
> >>>
> >>> I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name
> >>> is now the same as dev_alloc_name_ns") only makes sense while
> >>> d6f295e9def0 remains in the tree.
> >>
> >> I'm sorry about all of this, I really didn't think there would be such
> >> consequences of changing an errno return. Indeed, d6f29 was preparation
> >> for unifying the two functions that do the exact same thing (and how we
> >> ever got into that situation is somewhat unclear), except for
> >> their behaviour in the case the requested name already exists. So one of
> >> the two interfaces had to change its return value, and as I wrote, I
> >> thought EEXIST was the saner choice when an explicit name (no %d) had
> >> been requested.
> >
> > No worries.
> >
> >>> ie. before the entire series, dev_get_valid_name() would return EEXIST,
> >>> and that was retained when 87c320e51519 was merged, but now that
> >>> d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE.
> >>>
> >>> I can get the network up again if I also revert 87c320e51519 ("net:
> >>> core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with
> >>> the gross patch below.
> >>
> >> I don't think changing -ENFILE to -EEXIST would be right either, since
> >> dev_get_valid_name() used to be able to return both (-EEXIST in the case
> >> where there's no %d, -ENFILE in the case where we end up calling
> >> dev_alloc_name_ns()). If anything, we could do the check for the old
> >> -EEXIST condition first, and then call dev_alloc_name_ns(). But I'm also
> >> fine with reverting.
> >
> > Yeah I think a revert would be best, given it's nearly rc5.
> >
> > My userspace is not exotic AFAIK, just debian something, so presumably
> > this will affect other people too.
>
> I've just queued up the following revert, thanks!
>
> ====================
> From 5047543928139184f060c8f3bccb788b3df4c1ea Mon Sep 17 00:00:00 2001
> From: "David S. Miller" <davem@davemloft.net>
> Date: Tue, 2 Jan 2018 11:45:07 -0500
> Subject: [PATCH] Revert "net: core: dev_get_valid_name is now the same as
> dev_alloc_name_ns"
>
> This reverts commit 87c320e51519a83c496ab7bfb4e96c8f9c001e89.
>
> Changing the error return code in some situations turns out to
> be harmful in practice. In particular Michael Ellerman reports
> that DHCP fails on his powerpc machines, and this revert gets
> things working again.
>
> Johannes Berg agrees that this revert is the best course of
> action for now.
I'm not sure my voice matters much, I merely did the first revert of
these two patches ... :)
But I agree with Michael that you can't really salvage this without the
other patch, and that one caused problems in wifi ...
Thanks :)
johannes
^ permalink raw reply
* Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name"
From: David Miller @ 2018-01-02 16:50 UTC (permalink / raw)
To: mpe; +Cc: linux, michael, j, netdev, johannes, linuxppc-dev, johannes.berg
In-Reply-To: <87bmirpf29.fsf@concordia.ellerman.id.au>
From: Michael Ellerman <mpe@ellerman.id.au>
Date: Fri, 22 Dec 2017 15:22:22 +1100
>> On Tue, Dec 19 2017, Michael Ellerman <michael@concordia.ellerman.id.au> wrote:
>>> This revert seems to have broken networking on one of my powerpc
>>> machines, according to git bisect.
>>>
>>> The symptom is DHCP fails and I don't get a link, I didn't dig any
>>> further than that. I can if it's helpful.
>>>
>>> I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name
>>> is now the same as dev_alloc_name_ns") only makes sense while
>>> d6f295e9def0 remains in the tree.
>>
>> I'm sorry about all of this, I really didn't think there would be such
>> consequences of changing an errno return. Indeed, d6f29 was preparation
>> for unifying the two functions that do the exact same thing (and how we
>> ever got into that situation is somewhat unclear), except for
>> their behaviour in the case the requested name already exists. So one of
>> the two interfaces had to change its return value, and as I wrote, I
>> thought EEXIST was the saner choice when an explicit name (no %d) had
>> been requested.
>
> No worries.
>
>>> ie. before the entire series, dev_get_valid_name() would return EEXIST,
>>> and that was retained when 87c320e51519 was merged, but now that
>>> d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE.
>>>
>>> I can get the network up again if I also revert 87c320e51519 ("net:
>>> core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with
>>> the gross patch below.
>>
>> I don't think changing -ENFILE to -EEXIST would be right either, since
>> dev_get_valid_name() used to be able to return both (-EEXIST in the case
>> where there's no %d, -ENFILE in the case where we end up calling
>> dev_alloc_name_ns()). If anything, we could do the check for the old
>> -EEXIST condition first, and then call dev_alloc_name_ns(). But I'm also
>> fine with reverting.
>
> Yeah I think a revert would be best, given it's nearly rc5.
>
> My userspace is not exotic AFAIK, just debian something, so presumably
> this will affect other people too.
I've just queued up the following revert, thanks!
====================
>From 5047543928139184f060c8f3bccb788b3df4c1ea Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Tue, 2 Jan 2018 11:45:07 -0500
Subject: [PATCH] Revert "net: core: dev_get_valid_name is now the same as
dev_alloc_name_ns"
This reverts commit 87c320e51519a83c496ab7bfb4e96c8f9c001e89.
Changing the error return code in some situations turns out to
be harmful in practice. In particular Michael Ellerman reports
that DHCP fails on his powerpc machines, and this revert gets
things working again.
Johannes Berg agrees that this revert is the best course of
action for now.
Fixes: 029b6d140550 ("Revert "net: core: maybe return -EEXIST in __dev_alloc_name"")
Reported-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/core/dev.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 01ee854454a8..0e0ba36eeac9 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1146,7 +1146,19 @@ EXPORT_SYMBOL(dev_alloc_name);
int dev_get_valid_name(struct net *net, struct net_device *dev,
const char *name)
{
- return dev_alloc_name_ns(net, dev, name);
+ BUG_ON(!net);
+
+ if (!dev_valid_name(name))
+ return -EINVAL;
+
+ if (strchr(name, '%'))
+ return dev_alloc_name_ns(net, dev, name);
+ else if (__dev_get_by_name(net, name))
+ return -EEXIST;
+ else if (dev->name != name)
+ strlcpy(dev->name, name, IFNAMSIZ);
+
+ return 0;
}
EXPORT_SYMBOL(dev_get_valid_name);
--
2.14.3
^ permalink raw reply related
* [PATCH net-next] net: mdio: Only perform gpio reset for PHYs
From: Andrew Lunn @ 2018-01-02 16:40 UTC (permalink / raw)
To: David Miller
Cc: Florian Fainelli, sean.wang, sergei.shtylyov, geert+renesas,
netdev, Andrew Lunn
Ethernet switch on the MDIO bus have historically performed their own
handling of the GPIO reset line. The resent patch to have the MDIO
core handle the reset has broken the switch drivers, in that they
cannot claim the GPIO. Some switch drivers need more control over the
GPIO line than what the MDIO core provides. So restore the historical
behaviour by only performing a reset of PHYs, not switches.
Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support")
Reported-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/mdio_bus.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index a0f34c385cad..6afb1b578aec 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -47,13 +47,10 @@
#include "mdio-boardinfo.h"
-int mdiobus_register_device(struct mdio_device *mdiodev)
+static int mdiobus_register_gpiod(struct mdio_device *mdiodev)
{
struct gpio_desc *gpiod = NULL;
- if (mdiodev->bus->mdio_map[mdiodev->addr])
- return -EBUSY;
-
/* Deassert the optional reset signal */
if (mdiodev->dev.of_node)
gpiod = fwnode_get_named_gpiod(&mdiodev->dev.of_node->fwnode,
@@ -69,6 +66,22 @@ int mdiobus_register_device(struct mdio_device *mdiodev)
/* Assert the reset signal again */
mdio_device_reset(mdiodev, 1);
+ return 0;
+}
+
+int mdiobus_register_device(struct mdio_device *mdiodev)
+{
+ int err;
+
+ if (mdiodev->bus->mdio_map[mdiodev->addr])
+ return -EBUSY;
+
+ if (mdiodev->flags & MDIO_DEVICE_FLAG_PHY) {
+ err = mdiobus_register_gpiod(mdiodev);
+ if (err)
+ return err;
+ }
+
mdiodev->bus->mdio_map[mdiodev->addr] = mdiodev;
return 0;
--
2.15.1
^ permalink raw reply related
* Re: [Patch net-next] net_sched: call qdisc_reset() with qdisc lock
From: David Miller @ 2018-01-02 16:39 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, jakub.kicinski, john.fastabend
In-Reply-To: <20171222000330.29009-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 21 Dec 2017 16:03:29 -0800
> qdisc_reset() should always be called with qdisc spinlock
> and with BH disabled, otherwise qdisc ->reset() could race
> with TX BH.
>
> Fixes: 7bbde83b1860 ("net: sched: drop qdisc_reset from dev_graft_qdisc")
> Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
There doesn't seem to be agreement over whether qdisc_reset() really
needs to run with the lock held. In fact, the general consensus is
that this really shouldn't run until a grace period had occurred and
therefore parallel TX paths cannot be running any longer.
In any event, this was supposed to work towards a bug fix which
ultimately was fixed instead with the ptr_ring change from John.
So this seems unnecessary now.
If you disagree, please repost with an updated commit message which
explains things further.
Thank you.
^ permalink raw reply
* Re: [Patch net-next] net_sched: remove the unsafe __skb_array_empty()
From: David Miller @ 2018-01-02 16:37 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, jakub.kicinski, john.fastabend
In-Reply-To: <20171222000330.29009-2-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 21 Dec 2017 16:03:30 -0800
> __skb_array_empty() is only safe if array is never resized.
> pfifo_fast_dequeue() is called in TX BH context and without
> qdisc lock, so even after we disable BH on ->reset() path
> we can still race with other CPU's.
>
> Fixes: c5ad119fb6c0 ("net: sched: pfifo_fast use skb_array")
> Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Based upon the discussion over this patch, this bug is ultimately fixed
by John's patch which adds a dummy element at the end of allocated
ptr_ring queues.
And I've just applied that.
^ permalink raw reply
* [PATCH] net: ipv4: emulate READ_ONCE() on ->hdrincl bit-field in raw_sendmsg()
From: Nicolai Stange @ 2018-01-02 16:30 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: Mohamed Ghannam, Michal Kubecek, Miroslav Benes, netdev,
linux-kernel, Nicolai Stange
Commit 8f659a03a0ba ("net: ipv4: fix for a race condition in
raw_sendmsg") fixed the issue of possibly inconsistent ->hdrincl handling
due to concurrent updates by reading this bit-field member into a local
variable and using the thus stabilized value in subsequent tests.
However, aforementioned commit also adds the (correct) comment that
/* hdrincl should be READ_ONCE(inet->hdrincl)
* but READ_ONCE() doesn't work with bit fields
*/
because as it stands, the compiler is free to shortcut or even eliminate
the local variable at its will.
Note that I have not seen anything like this happening in reality and thus,
the concern is a theoretical one.
However, in order to be on the safe side, emulate a READ_ONCE() on the
bit-field by introducing an intermediate local variable and doing a
READ_ONCE() from it:
int __hdrincl = inet->hdrincl;
int hdrincl = READ_ONCE(__hdrincl);
This breaks the chain in the sense that the compiler is not allowed
to replace subsequent reads from hdrincl with reloads from inet->hdrincl.
Fixes: 8f659a03a0ba ("net: ipv4: fix for a race condition in raw_sendmsg")
Signed-off-by: Nicolai Stange <nstange@suse.de>
---
Compile-tested only (with inspection of compiler output on x86_64).
Applicable to linux-next-20180102.
net/ipv4/raw.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 5b9bd5c33d9d..e84290c28c0c 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -513,16 +513,18 @@ static int raw_sendmsg(struct sock *sk, struct msghdr *msg, size_t len)
int err;
struct ip_options_data opt_copy;
struct raw_frag_vec rfv;
- int hdrincl;
+ int hdrincl, __hdrincl;
err = -EMSGSIZE;
if (len > 0xFFFF)
goto out;
/* hdrincl should be READ_ONCE(inet->hdrincl)
- * but READ_ONCE() doesn't work with bit fields
+ * but READ_ONCE() doesn't work with bit fields.
+ * Emulate it by doing the READ_ONCE() from an intermediate int.
*/
- hdrincl = inet->hdrincl;
+ __hdrincl = inet->hdrincl;
+ hdrincl = READ_ONCE(__hdrincl);
/*
* Check the flags.
*/
--
2.13.6
^ permalink raw reply related
* Re: [RFC PATCH net-next 04/19] ipv6: Prepare to handle multiple netdev events
From: David Ahern @ 2018-01-02 16:29 UTC (permalink / raw)
To: Ido Schimmel, netdev; +Cc: davem, roopa, nicolas.dichtel, mlxsw
In-Reply-To: <20171231161513.25785-5-idosch@mellanox.com>
On 12/31/17 9:14 AM, Ido Schimmel wrote:
> To make IPv6 more in line with IPv4 we need to be able to respond
> differently to different netdev events. For example, when a netdev is
> unregistered all the routes using it as their nexthop device should be
> flushed, whereas when the netdev's carrier changes only the 'linkdown'
> flag should be toggled.
>
> Currently, this is not possible, as the function that traverses the
> routing tables is not aware of the triggering event.
>
> Propagate the triggering event down, so that it could be used in later
> patches.
>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> ---
> include/net/ip6_route.h | 1 +
> net/ipv6/addrconf.c | 4 ++--
> net/ipv6/route.c | 35 ++++++++++++++++++++---------------
> 3 files changed, 23 insertions(+), 17 deletions(-)
>
> diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
> index caad39198c2a..8205402ff3dc 100644
> --- a/include/net/ip6_route.h
> +++ b/include/net/ip6_route.h
rt6_ifdown is done with this change, so the declaration of rt6_ifdown
can be removed from this file as well.
> @@ -170,6 +170,7 @@ void rt6_mtu_change(struct net_device *dev, unsigned int mtu);
> void rt6_remove_prefsrc(struct inet6_ifaddr *ifp);
> void rt6_clean_tohost(struct net *net, struct in6_addr *gateway);
> void rt6_sync_up(struct net_device *dev, unsigned int nh_flags);
> +void rt6_disable_ip(struct net_device *dev, unsigned long event);
>
> static inline const struct rt6_info *skb_rt6_info(const struct sk_buff *skb)
> {
^ permalink raw reply
* Re: Linux ECN Handling
From: Neal Cardwell @ 2018-01-02 16:27 UTC (permalink / raw)
To: Steve Ibanez
Cc: Eric Dumazet, Yuchung Cheng, Daniel Borkmann, Netdev,
Florian Westphal, Mohammad Alizadeh, Lawrence Brakmo
In-Reply-To: <CACJspmLiYAG6Z7Zzn+J_DQ=QVs=zXp8ttBihvO8LHDsassapXg@mail.gmail.com>
On Tue, Jan 2, 2018 at 2:43 AM, Steve Ibanez <sibanez@stanford.edu> wrote:
> Hi Neal,
>
> Apologies for the delay, and happy new year!
>
> To answer your question, data is only transferred in one direction
> (from the client to the server). The SeqNo in the pkts from the server
> to the client is not incremented. So I don't think that a data pkt is
> attempted to be sent in the tcp_data_snd_check() call clearing the
> ICSK_ACK_SCHED bit. Although I think it would be helpful to include
> your new debugging field in the tcp_sock (tp->processing_cwr) so that
> I can check this field in the tcp_transmit_skb() and tcp_send_ack()
> functions. I added the new field and tried to set it at the top of the
> tcp_rcv_established(), but then when I try to check the field in the
> tcp_send_ack() function it never appears to be set. Below I'm showing
> how I set the tp->processing_cwr field in the tcp_rcv_established
> function and how I check it in the tcp_send_ack function. Is this how
> you were imagining the processing_cwr field to be used?
Happy new year to you as well, and thank you, Steve, for running this
experiment! Yes, this is basically the kind of thing I had in mind.
The connection will run the "fast path" tcp_rcv_established() code if
the connection is in the ESTABLISHED state. From the symptoms it
sounds like what's happening is that in this test the connection is
not in the ESTABLISHED state when the CWR arrives, so it's probably
running the more general tcp_rcv_state_process() function. I would
suggest adding your tp->processing_cwr instrumentation at the top of
tcp_rcv_state_process() as well, and then re-running the test. (In
tcp_v4_do_rcv() and tcp_v6_do_rcv(), for each incoming skb one of
those two functions is called).
It is interesting that the connection does not seem to be in the
ESTABLISHED state. Maybe that is an ingredient of the unexpected
behavior in this case...
Thanks!
neal
^ permalink raw reply
* Re: [RFC PATCH net-next 03/19] ipv6: Clear nexthop flags upon netdev up
From: David Ahern @ 2018-01-02 16:20 UTC (permalink / raw)
To: Ido Schimmel, netdev; +Cc: davem, roopa, nicolas.dichtel, mlxsw
In-Reply-To: <20171231161513.25785-4-idosch@mellanox.com>
On 12/31/17 9:14 AM, Ido Schimmel wrote:
> Previous patch marked nexthops with the 'dead' and 'linkdown' flags.
> Clear these flags when the netdev comes back up.
>
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> ---
> include/net/ip6_route.h | 1 +
> net/ipv6/addrconf.c | 3 +++
> net/ipv6/route.c | 29 +++++++++++++++++++++++++++++
> 3 files changed, 33 insertions(+)
>
> diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
> index 18e442ea93d8..caad39198c2a 100644
> --- a/include/net/ip6_route.h
> +++ b/include/net/ip6_route.h
> @@ -169,6 +169,7 @@ void rt6_ifdown(struct net *net, struct net_device *dev);
> void rt6_mtu_change(struct net_device *dev, unsigned int mtu);
> void rt6_remove_prefsrc(struct inet6_ifaddr *ifp);
> void rt6_clean_tohost(struct net *net, struct in6_addr *gateway);
> +void rt6_sync_up(struct net_device *dev, unsigned int nh_flags);
>
> static inline const struct rt6_info *skb_rt6_info(const struct sk_buff *skb)
> {
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index ed06b1190f05..b6405568ed7b 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -3484,6 +3484,9 @@ static int addrconf_notify(struct notifier_block *this, unsigned long event,
> if (run_pending)
> addrconf_dad_run(idev);
>
> + /* Device has an address by now */
> + rt6_sync_up(dev, RTNH_F_DEAD);
> +
Seems like this should be in the NETDEV_UP section, say after
addrconf_permanent_addr.
^ permalink raw reply
* Re: [PATCH v6 1/6] can: dev: Add support for limiting configured bitrate
From: Marc Kleine-Budde @ 2018-01-02 16:15 UTC (permalink / raw)
To: Faiz Abbas, wg, robh+dt, mark.rutland
Cc: linux-can, netdev, devicetree, linux-kernel, nsekhar, fcooper,
robh, Wenyou.Yang, sergei.shtylyov
In-Reply-To: <1513949488-13026-2-git-send-email-faiz_abbas@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 1179 bytes --]
On 12/22/2017 02:31 PM, Faiz Abbas wrote:
> From: Franklin S Cooper Jr <fcooper@ti.com>
>
> Various CAN or CAN-FD IP may be able to run at a faster rate than
> what the transceiver the CAN node is connected to. This can lead to
> unexpected errors. However, CAN transceivers typically have fixed
> limitations and provide no means to discover these limitations at
> runtime. Therefore, add support for a can-transceiver node that
> can be reused by other CAN peripheral drivers to determine for both
> CAN and CAN-FD what the max bitrate that can be used. If the user
> tries to configure CAN to pass these maximum bitrates it will throw
> an error.
Please add support to read the maximum bitrate via netlink. Have a look
at 12a6075cabc0 ("can: dev: add CAN interface termination API"). I think
you need to extend the following functions: can_get_size() and
can_fill_info().
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 5/5] net: phy: marvell10g: add support for half duplex 100M and 10M
From: Andrew Lunn @ 2018-01-02 16:13 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1eUu3f-0002Y8-5d@rmk-PC.armlinux.org.uk>
On Fri, Dec 29, 2017 at 12:46:43PM +0000, Russell King wrote:
> Add support for half-duplex 100M and 10M copper connections by parsing
> the advertisment results rather than trying to decode the negotiated
> speed from one of the PHYs "vendor" registers. This allows us to
> decode the duplex as well, which means we can support half-duplex mode
> for the slower speeds.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 4/5] net: phy: add helper to convert negotiation result to phy settings
From: Andrew Lunn @ 2018-01-02 16:11 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1eUu3a-0002Xy-2H@rmk-PC.armlinux.org.uk>
On Fri, Dec 29, 2017 at 12:46:38PM +0000, Russell King wrote:
> Add a helper to convert the result of the autonegotiation advertisment
> into the PHYs speed and duplex settings. If the result is full duplex,
> also extract the pause mode settings from the link partner advertisment.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 3/5] net: phy: marvell10g: clean up interface mode switching
From: Andrew Lunn @ 2018-01-02 16:09 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1eUu3U-0002Xr-UX@rmk-PC.armlinux.org.uk>
On Fri, Dec 29, 2017 at 12:46:32PM +0000, Russell King wrote:
> Centralise the PHY interface mode switching, rather than having it in
> two places.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/5] net: phy: marvell10g: add MDI swap reporting
From: Andrew Lunn @ 2018-01-02 16:08 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1eUu3P-0002Xj-QW@rmk-PC.armlinux.org.uk>
On Fri, Dec 29, 2017 at 12:46:27PM +0000, Russell King wrote:
> Add reporting of the MDI swap to the Marvell 10G PHY driver by providing
> a generic implementation for the standard 10GBASE-T pair swap register
> and polarity register. We also support reading the MDI swap status for
> 1G and below from a PCS register.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v6 3/6] can: m_can: Add PM Runtime
From: Marc Kleine-Budde @ 2018-01-02 16:07 UTC (permalink / raw)
To: Faiz Abbas, wg, robh+dt, mark.rutland
Cc: linux-can, netdev, devicetree, linux-kernel, nsekhar, fcooper,
robh, Wenyou.Yang, sergei.shtylyov
In-Reply-To: <1513949488-13026-4-git-send-email-faiz_abbas@ti.com>
[-- Attachment #1.1: Type: text/plain, Size: 4391 bytes --]
On 12/22/2017 02:31 PM, Faiz Abbas wrote:
> From: Franklin S Cooper Jr <fcooper@ti.com>
>
> Add support for PM Runtime which is the new way to handle managing clocks.
> However, to avoid breaking SoCs not using PM_RUNTIME leave the old clk
> management approach in place.
There is no PM_RUNTIME anymore since 464ed18ebdb6 ("PM: Eliminate
CONFIG_PM_RUNTIME")
Have a look at the discussion: https://patchwork.kernel.org/patch/9436507/ :
>> Well, I admit it would be nicer if drivers didn't have to worry about
>> whether or not CONFIG_PM was enabled. A slightly cleaner approach
>> from the one outlined above would have the probe routine do this:
>>
>> my_power_up(dev);
>> pm_runtime_set_active(dev);
>> pm_runtime_get_noresume(dev);
>> pm_runtime_enable(dev);
> PM_RUNTIME is required by OMAP based devices to handle clock management.
> Therefore, this allows future Texas Instruments SoCs that have the MCAN IP
> to work with this driver.
Who will set the SET_RUNTIME_PM_OPS in this case?
> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
> [nsekhar@ti.com: handle pm_runtime_get_sync() failure, fix some bugs]
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> ---
> drivers/net/can/m_can/m_can.c | 38 ++++++++++++++++++++++++++++++++++----
> 1 file changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
> index f72116e..53e764f 100644
> --- a/drivers/net/can/m_can/m_can.c
> +++ b/drivers/net/can/m_can/m_can.c
> @@ -23,6 +23,7 @@
> #include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> #include <linux/iopoll.h>
> #include <linux/can/dev.h>
>
> @@ -625,19 +626,33 @@ static int m_can_clk_start(struct m_can_priv *priv)
> {
> int err;
>
> + err = pm_runtime_get_sync(priv->device);
> + if (err) {
> + pm_runtime_put_noidle(priv->device);
Why do you call this in case of an error?
> + return err;
> + }
> +
> err = clk_prepare_enable(priv->hclk);
> if (err)
> - return err;
> + goto pm_runtime_put;
>
> err = clk_prepare_enable(priv->cclk);
> if (err)
> - clk_disable_unprepare(priv->hclk);
> + goto disable_hclk;
>
> return err;
> +
> +disable_hclk:
> + clk_disable_unprepare(priv->hclk);
> +pm_runtime_put:
> + pm_runtime_put_sync(priv->device);
> + return err;
> }
>
> static void m_can_clk_stop(struct m_can_priv *priv)
> {
> + pm_runtime_put_sync(priv->device);
> +
> clk_disable_unprepare(priv->cclk);
> clk_disable_unprepare(priv->hclk);
> }
> @@ -1577,13 +1592,20 @@ static int m_can_plat_probe(struct platform_device *pdev)
> /* Enable clocks. Necessary to read Core Release in order to determine
> * M_CAN version
> */
> + pm_runtime_enable(&pdev->dev);
> + ret = pm_runtime_get_sync(&pdev->dev);
> + if (ret) {
> + pm_runtime_put_noidle(&pdev->dev);
Why do you call this in case of error?
> + goto pm_runtime_fail;
> + }
> +
> ret = clk_prepare_enable(hclk);
> if (ret)
> - goto disable_hclk_ret;
> + goto pm_runtime_put;
>
> ret = clk_prepare_enable(cclk);
> if (ret)
> - goto disable_cclk_ret;
> + goto disable_hclk_ret;
>
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "m_can");
> addr = devm_ioremap_resource(&pdev->dev, res);
> @@ -1666,6 +1688,11 @@ static int m_can_plat_probe(struct platform_device *pdev)
> clk_disable_unprepare(cclk);
> disable_hclk_ret:
> clk_disable_unprepare(hclk);
> +pm_runtime_put:
> + pm_runtime_put_sync(&pdev->dev);
> +pm_runtime_fail:
> + if (ret)
> + pm_runtime_disable(&pdev->dev);
> failed_ret:
> return ret;
> }
> @@ -1723,6 +1750,9 @@ static int m_can_plat_remove(struct platform_device *pdev)
> struct net_device *dev = platform_get_drvdata(pdev);
>
> unregister_m_can_dev(dev);
> +
> + pm_runtime_disable(&pdev->dev);
> +
> platform_set_drvdata(pdev, NULL);
>
> free_m_can_dev(dev);
>
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/5] net: phy: marvell10g: update header comments
From: Andrew Lunn @ 2018-01-02 16:06 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1eUu3K-0002Xc-MY@rmk-PC.armlinux.org.uk>
On Fri, Dec 29, 2017 at 12:46:22PM +0000, Russell King wrote:
> Update header comments to indicate the newly found behaviour with XAUI
> interfaces.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 7/7] net: phy: convert read-modify-write to phy_modify()
From: Andrew Lunn @ 2018-01-02 16:05 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1eWKHa-0003j2-Kd@rmk-PC.armlinux.org.uk>
On Tue, Jan 02, 2018 at 10:58:58AM +0000, Russell King wrote:
> Convert read-modify-write sequences in at803x, Marvell and core phylib
> to use phy_modify() to ensure safety.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 6/7] net: phy: add phy_modify() accessor
From: Andrew Lunn @ 2018-01-02 16:01 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1eWKHV-0003iv-BH@rmk-PC.armlinux.org.uk>
On Tue, Jan 02, 2018 at 10:58:53AM +0000, Russell King wrote:
> Add phy_modify() convenience accessor to complement the mdiobus
> counterpart.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 5/7] net: phy: marvell: fix paged access races
From: Andrew Lunn @ 2018-01-02 16:00 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1eWKHQ-0003io-8N@rmk-PC.armlinux.org.uk>
On Tue, Jan 02, 2018 at 10:58:48AM +0000, Russell King wrote:
> For paged accesses to be truely safe, we need to hold the bus lock to
> prevent anyone else gaining access to the registers while we modify
> them.
>
> The phydev->lock mutex does not do this: userspace via the MII ioctl
> can still sneak in and read or write any register while we are on a
> different page, and the suspend/resume methods can be called by a
> thread different to the thread polling the phy status.
>
> Races have been observed with mvneta on SolidRun Clearfog with phylink,
> particularly between the phylib worker reading the PHYs status, and
> the thread resuming mvneta, calling phy_start() which then calls
> through to m88e1121_config_aneg_rgmii_delays(), which tries to
> read-modify-write the MSCR register:
>
> CPU0 CPU1
> marvell_read_status_page()
> marvell_set_page(phydev, MII_MARVELL_FIBER_PAGE)
> ...
> m88e1121_config_aneg_rgmii_delays()
> set_page(MII_MARVELL_MSCR_PAGE)
> phy_read(phydev, MII_88E1121_PHY_MSCR_REG)
> marvell_set_page(phydev, MII_MARVELL_COPPER_PAGE);
> ...
> phy_write(phydev, MII_88E1121_PHY_MSCR_REG)
>
> The result of this is we end up writing the copper page register 21,
> which causes the copper PHY to be disabled, and the link partner sees
> the link immediately go down.
>
> Solve this by taking the bus lock instead of the PHY lock, thereby
> preventing other accesses to the PHY while we are accessing other PHY
> pages.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 4/7] net: phy: add paged phy register accessors
From: Andrew Lunn @ 2018-01-02 15:52 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1eWKHL-0003ih-5E@rmk-PC.armlinux.org.uk>
On Tue, Jan 02, 2018 at 10:58:43AM +0000, Russell King wrote:
> Add a set of paged phy register accessors which are inherently safe in
> their design against other accesses interfering with the paged access.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 3/7] net: phy: add unlocked accessors
From: Andrew Lunn @ 2018-01-02 15:49 UTC (permalink / raw)
To: Russell King; +Cc: Florian Fainelli, netdev
In-Reply-To: <E1eWKHF-0003iZ-Q5@rmk-PC.armlinux.org.uk>
On Tue, Jan 02, 2018 at 10:58:37AM +0000, Russell King wrote:
> Add unlocked versions of the bus accessors, which allows access to the
> bus with all the tracing. These accessors validate that the bus mutex
> is held, which is a basic requirement for all mii bus accesses.
>
> Also added is a read-modify-write unlocked accessor with the same
> locking requirements.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: general protection fault in skb_segment
From: Willem de Bruijn @ 2018-01-02 15:48 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: syzbot, David Miller, LKML, linux-sctp, Network Development,
Neil Horman, syzkaller-bugs, Vladislav Yasevich
In-Reply-To: <CAF=yD-+KwmB+fX+4A1RiCV6ZCDQbkGGSVu8YVMrAGxfVtG7ndQ@mail.gmail.com>
> Good point. Packet sockets require CAP_NET_RAW, but this is also
> taken for virtio, so we probably want more stringent entry tests here.
That would be something like
#include <linux/if_vlan.h>
+#include <linux/skbuff.h>
#include <uapi/linux/virtio_net.h>
+#include <net/flow_dissector.h>
static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
const struct virtio_net_hdr *hdr,
@@ -12,14 +14,27 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
unsigned int gso_type = 0;
if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
+ struct flow_keys flow = { .basic = {0} };
+
+ if (!skb_flow_dissect(skb, &flow_keys_buf_dissector, &flow, 0))
+ return -EINVAL;
+
switch (hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {
case VIRTIO_NET_HDR_GSO_TCPV4:
+ if (flow.basic.n_proto != htons(ETH_P_IP) ||
+ flow.basic.ip_proto != IPPROTO_TCP)
+ return -EINVAL;
gso_type = SKB_GSO_TCPV4;
break;
case VIRTIO_NET_HDR_GSO_TCPV6:
+ if (flow.basic.n_proto != htons(ETH_P_IPV6) ||
+ flow.basic.ip_proto != IPPROTO_TCP)
+ return -EINVAL;
gso_type = SKB_GSO_TCPV6;
break;
case VIRTIO_NET_HDR_GSO_UDP:
+ if (flow.basic.ip_proto != IPPROTO_UDP)
+ return -EINVAL;
gso_type = SKB_GSO_UDP;
break;
default:
but I think we can block these packets without adding a flow dissector
call for each untrusted packet (SKB_GSO_DODGY).
> The alternative to harden the segmentation code itself with a gso_type
> sanity check in every gso callback is more work and fragile.
Actually, changes just to inet_gso_segment and ipv6_gso_segment
will suffice:
bool udpfrag = false, fixedid = false, gso_partial, encap;
struct sk_buff *segs = ERR_PTR(-EINVAL);
+ unsigned int offset = 0, gso_type;
const struct net_offload *ops;
- unsigned int offset = 0;
struct iphdr *iph;
int proto, tot_len;
int nhoff;
@@ -1258,6 +1258,22 @@ struct sk_buff *inet_gso_segment(struct sk_buff *skb,
skb_reset_transport_header(skb);
+ gso_type = skb_shinfo(skb)->gso_type;
+ if (gso_type & SKB_GSO_DODGY) {
+ switch (gso_type & (SKB_GSO_TCPV4 | SKB_GSO_UDP)) {
+ case SKB_GSO_TCPV4:
+ if (proto != IPPROTO_TCP)
+ goto out;
+ break;
+ case SKB_GSO_UDP:
+ if (proto != IPPROTO_UDP)
+ goto out;
+ break;
+ default:
+ goto out;
+ }
+ }
and analogous for IPv6. For a real patch I would deduplicate this
logic between them and move it to a separate helper function
(in a header file, then).
^ permalink raw reply
* [PATCH iproute2 3/3] link_iptnl: Open "encap" JSON object
From: Serhey Popovych @ 2018-01-02 15:29 UTC (permalink / raw)
To: netdev
In-Reply-To: <1514906959-9719-1-git-send-email-serhe.popovych@gmail.com>
It seems missing pair of open_json_object()/close_json_object()
in iptnl implementation.
Note that we open "encap" JSON object in ip6tnl.
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
ip/link_iptnl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ip/link_iptnl.c b/ip/link_iptnl.c
index afd1696..650f69b 100644
--- a/ip/link_iptnl.c
+++ b/ip/link_iptnl.c
@@ -498,6 +498,7 @@ static void iptunnel_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[
__u16 sport = rta_getattr_u16(tb[IFLA_IPTUN_ENCAP_SPORT]);
__u16 dport = rta_getattr_u16(tb[IFLA_IPTUN_ENCAP_DPORT]);
+ open_json_object("encap");
print_string(PRINT_FP, NULL, "encap ", NULL);
switch (type) {
case TUNNEL_ENCAP_FOU:
--
1.7.10.4
^ permalink raw reply related
* [PATCH iproute2 2/3] link_iptnl: Print tunnel mode
From: Serhey Popovych @ 2018-01-02 15:29 UTC (permalink / raw)
To: netdev
In-Reply-To: <1514906959-9719-1-git-send-email-serhe.popovych@gmail.com>
Tunnel mode does not appear in parameters print for iptnl
supported tunnels like ipip and sit, while printed for
ip6tnl.
Print tunnel mode with "proto" field for JSON and without
any name when printing to cli to follow ip6tnl behaviour.
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
ip/link_iptnl.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/ip/link_iptnl.c b/ip/link_iptnl.c
index d4d935b..afd1696 100644
--- a/ip/link_iptnl.c
+++ b/ip/link_iptnl.c
@@ -372,6 +372,23 @@ static void iptunnel_print_opt(struct link_util *lu, FILE *f, struct rtattr *tb[
if (tb[IFLA_IPTUN_COLLECT_METADATA])
print_bool(PRINT_ANY, "external", "external ", true);
+ if (tb[IFLA_IPTUN_PROTO]) {
+ switch (rta_getattr_u8(tb[IFLA_IPTUN_PROTO])) {
+ case IPPROTO_IPIP:
+ print_string(PRINT_ANY, "proto", "%s ", "ip4ip4");
+ break;
+ case IPPROTO_IPV6:
+ print_string(PRINT_ANY, "proto", "%s ", "ip6ip");
+ break;
+ case IPPROTO_MPLS:
+ print_string(PRINT_ANY, "proto", "%s ", "mplsip");
+ break;
+ case 0:
+ print_string(PRINT_ANY, "proto", "%s ", "any");
+ break;
+ }
+ }
+
if (tb[IFLA_IPTUN_REMOTE]) {
unsigned int addr = rta_getattr_u32(tb[IFLA_IPTUN_REMOTE]);
--
1.7.10.4
^ permalink raw reply related
* [PATCH iproute2 1/3] link_iptnl: Kill code duplication
From: Serhey Popovych @ 2018-01-02 15:29 UTC (permalink / raw)
To: netdev
In-Reply-To: <1514906959-9719-1-git-send-email-serhe.popovych@gmail.com>
Both sit and ipip "mode" parameter handling nearly the same.
Except for sit we have "ip6ip" mode: check it only when
configuring sit.
Note that there is no need strcmp(lu->id, "ipip"): if it is
not sit it is "ipip" because we have only these two link util
defined in module.
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
ip/link_iptnl.c | 27 +++++----------------------
1 file changed, 5 insertions(+), 22 deletions(-)
diff --git a/ip/link_iptnl.c b/ip/link_iptnl.c
index 8a8f5dd..d4d935b 100644
--- a/ip/link_iptnl.c
+++ b/ip/link_iptnl.c
@@ -230,11 +230,11 @@ get_failed:
} else if (strcmp(lu->id, "sit") == 0 &&
strcmp(*argv, "isatap") == 0) {
iflags |= SIT_ISATAP;
- } else if (strcmp(lu->id, "sit") == 0 &&
- strcmp(*argv, "mode") == 0) {
+ } else if (strcmp(*argv, "mode") == 0) {
NEXT_ARG();
- if (strcmp(*argv, "ipv6/ipv4") == 0 ||
- strcmp(*argv, "ip6ip") == 0)
+ if (strcmp(lu->id, "sit") == 0 &&
+ (strcmp(*argv, "ipv6/ipv4") == 0 ||
+ strcmp(*argv, "ip6ip") == 0))
proto = IPPROTO_IPV6;
else if (strcmp(*argv, "ipv4/ipv4") == 0 ||
strcmp(*argv, "ipip") == 0 ||
@@ -248,21 +248,6 @@ get_failed:
proto = 0;
else
invarg("Cannot guess tunnel mode.", *argv);
- } else if (strcmp(lu->id, "ipip") == 0 &&
- strcmp(*argv, "mode") == 0) {
- NEXT_ARG();
- if (strcmp(*argv, "ipv4/ipv4") == 0 ||
- strcmp(*argv, "ipip") == 0 ||
- strcmp(*argv, "ip4ip4") == 0)
- proto = IPPROTO_IPIP;
- else if (strcmp(*argv, "mpls/ipv4") == 0 ||
- strcmp(*argv, "mplsip") == 0)
- proto = IPPROTO_MPLS;
- else if (strcmp(*argv, "any/ipv4") == 0 ||
- strcmp(*argv, "any") == 0)
- proto = 0;
- else
- invarg("Cannot guess tunnel mode.", *argv);
} else if (strcmp(*argv, "noencap") == 0) {
encaptype = TUNNEL_ENCAP_NONE;
} else if (strcmp(*argv, "encap") == 0) {
@@ -337,6 +322,7 @@ get_failed:
exit(-1);
}
+ addattr8(n, 1024, IFLA_IPTUN_PROTO, proto);
if (metadata) {
addattr_l(n, 1024, IFLA_IPTUN_COLLECT_METADATA, NULL, 0);
return 0;
@@ -355,9 +341,6 @@ get_failed:
addattr16(n, 1024, IFLA_IPTUN_ENCAP_SPORT, htons(encapsport));
addattr16(n, 1024, IFLA_IPTUN_ENCAP_DPORT, htons(encapdport));
- if (strcmp(lu->id, "ipip") == 0 || strcmp(lu->id, "sit") == 0)
- addattr8(n, 1024, IFLA_IPTUN_PROTO, proto);
-
if (strcmp(lu->id, "sit") == 0) {
addattr16(n, 1024, IFLA_IPTUN_FLAGS, iflags);
if (ip6rdprefixlen) {
--
1.7.10.4
^ 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