* Re: [RFC PATCH 1/1] fair.c: Add/Export find_idlest_perfer_cpu API
From: Shirley Ma @ 2012-08-20 22:17 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, mingo, Michael S. Tsirkin, netdev, sri, vivek
In-Reply-To: <1345464035.23018.38.camel@twins>
On Mon, 2012-08-20 at 14:00 +0200, Peter Zijlstra wrote:
> On Fri, 2012-08-17 at 12:46 -0700, Shirley Ma wrote:
> > Add/Export a new API for per-cpu thread model networking device
> driver
> > to choose a preferred idlest cpu within allowed cpumask.
> >
> > The receiving CPUs of a networking device are not under cgroup
> controls.
> > Normally the receiving work will be scheduled on the cpu on which
> the
> > interrupts are received. When such a networking device uses per-cpu
> > thread model, the cpu which is chose to process the packets might
> not be
> > part of cgroup cpusets without using such an API here.
> >
> > On NUMA system, by using the preferred cpumask from the same NUMA
> node
> > would help to reduce expensive cross memory access to/from the other
> > NUMA node.
> >
> > KVM per-cpu vhost will be the first one to use this API. Any other
> > device driver which uses per-cpu thread model and has cgroup cpuset
> > control will use this API later.
>
> How often will this be called and how do you obtain the cpumasks
> provided to the function?
It depends. It might be called pretty often if the user keeps changing
cgroups control cpuset. It might be less called if the cgroups control
cpuset is stable, and the host scheduler always schedules the work on
the same NUMA node.
The preferred cpumasks are obtained from local numa node. The allowed
cpumasks are obtained from caller's task allowed cpumasks (cgroups
control cpuset).
Thanks
Shirley
^ permalink raw reply
* Re: RFC - document network device carrier management
From: Ben Hutchings @ 2012-08-20 21:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20120815085827.2b252094@nehalam.linuxnetplumber.net>
On Wed, 2012-08-15 at 08:58 -0700, Stephen Hemminger wrote:
> Since carrier handling is often done incorrectly by new device drivers
> be explicit about carrier handling API.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> This is a meant as starting point for discussion, it's probably wrong as is.
> Since this isn't code, it could be applied for 3.6 and doesn't need for net-next.
>
>
> --- a/Documentation/networking/netdevices.txt 2012-06-22 08:27:46.729168196 -0700
> +++ b/Documentation/networking/netdevices.txt 2012-08-15 08:56:31.120429994 -0700
> @@ -45,6 +45,36 @@ drop, truncate, or pass up oversize pack
> packets is preferred.
>
>
> +CARRIER
> +=======
> +Most network devices have an operational state that the device
> +monitors. The Linux kernel uses the name "carrier" for this flag which
> +is a historical reference to old modems. Carrier is reported to
> +userspace via the IFF_RUNNING flag from SIOCGIFFLAGS ioctl.
> +Carrier is controlled in the device driver
> +by the functions netif_carrier_on and netif_carrier_off. These
> +functions trigger the necessary netlink and userspace API changes;
> +device drivers must not change netdevice->flags directly.
> +
> +The carrier defaults to ON when the device is created and registered.
> +Simple devices (such as dummy) do not need to do anything.
> +Ethernet style devices should:
> + * alloc_etherdev in probe routine
> + * call netif_carrier_off
> + * register network device
> + * start auto negotiation with phy in open routine
Auto-negotiation is only one of several stages of link setup, and of
course is not used in all Ethernet physical layers. I think the
important point is that once the ndo_open method returns the hardware
and driver should be ready to set up the link and report this state
whenever a suitable partner is physically connected.
> + * call netif_carrier_on when link is up
> +
> +More complex RFC2863 style operational state is also possible
> +but not required (see operstates.txt).
Drivers are not allowed to set operstate directly.
> +The monitoring of link state is the responsibility of the network
> +device driver. It can be done by polling, interrupt, or any other
> +mechanism. netif_carrier_on/netif_carrier_off are atomic and can
> +safely be called by an interrupt routine. Carrier events are
> +managed by the linkwatch work queue and limited to one per second
> +to avoid overwhelming management applications.
> +
> struct net_device synchronization rules
> =======================================
> ndo_open:
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH net-next] net: Set device operstate at registration time
From: Ben Hutchings @ 2012-08-20 21:16 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Ilya Shchepetkov, bjorn, Michael Marineau
The operstate of a device is initially IF_OPER_UNKNOWN and is updated
asynchronously by linkwatch after each change of carrier state
reported by the driver. The default carrier state of a net device is
on, and this will never be changed on drivers that do not support
carrier detection, thus the operstate remains IF_OPER_UNKNOWN.
For devices that do support carrier detection, the driver must set the
carrier state to off initially, then poll the hardware state when the
device is opened. However, we must not activate linkwatch for a
unregistered device, and commit b473001 ('net: Do not fire linkwatch
events until the device is registered.') ensured that we don't. But
this means that the operstate for many devices that support carrier
detection remains IF_OPER_UNKNOWN when it should be IF_OPER_DOWN.
The same issue exists with the dormant state.
The proper initialisation sequence, avoiding a race with opening of
the device, is:
rtnl_lock();
rc = register_netdevice(dev);
if (rc)
goto out_unlock;
netif_carrier_off(dev); /* or netif_dormant_on(dev) */
rtnl_unlock();
but it seems silly that this should have to be repeated in so many
drivers. Further, the operstate seen immediately after opening the
device may still be IF_OPER_UNKNOWN due to the asynchronous nature of
linkwatch.
Commit 22604c8 ('net: Fix for initial link state in 2.6.28') attempted
to fix this by setting the operstate synchronously, but it was
reverted as it could lead to deadlock.
This initialises the operstate synchronously at registration time
only.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
This seems to deal properly with the registration-time problem, but not
the case where a device is brought down and then up again. Many but not
all drivers that support carrier detection call netif_carrier_off() in
their ndo_stop method. Should the others be changed, or is there some
way we can make that automatic?
Ben.
include/linux/netdevice.h | 1 +
net/core/dev.c | 2 ++
net/core/link_watch.c | 8 ++++++++
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 1d6ab69..72ae4cf 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2224,6 +2224,7 @@ static inline void dev_hold(struct net_device *dev)
* kind of lower layer not just hardware media.
*/
+extern void linkwatch_init_dev(struct net_device *dev);
extern void linkwatch_fire_event(struct net_device *dev);
extern void linkwatch_forget_dev(struct net_device *dev);
diff --git a/net/core/dev.c b/net/core/dev.c
index ce1bccb..2baeceb 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5639,6 +5639,8 @@ int register_netdevice(struct net_device *dev)
set_bit(__LINK_STATE_PRESENT, &dev->state);
+ linkwatch_init_dev(dev);
+
dev_init_scheduler(dev);
dev_hold(dev);
list_netdevice(dev);
diff --git a/net/core/link_watch.c b/net/core/link_watch.c
index c3519c6..a019222 100644
--- a/net/core/link_watch.c
+++ b/net/core/link_watch.c
@@ -76,6 +76,14 @@ static void rfc2863_policy(struct net_device *dev)
}
+void linkwatch_init_dev(struct net_device *dev)
+{
+ /* Handle pre-registration link state changes */
+ if (!netif_carrier_ok(dev) || netif_dormant(dev))
+ rfc2863_policy(dev);
+}
+
+
static bool linkwatch_urgent_event(struct net_device *dev)
{
if (!netif_running(dev))
--
1.7.7.6
^ permalink raw reply related
* Re: 3.5.1 fib_rules_lookup oops
From: Andi Kleen @ 2012-08-20 20:35 UTC (permalink / raw)
To: Dave Jones; +Cc: Eric Dumazet, netdev, Fedora Kernel Team
In-Reply-To: <20120820172240.GA378@redhat.com>
Dave Jones <davej@redhat.com> writes:
>
> Same user reported a slew of other problems, so he may have bad hardware.
> I've asked him to run a memtest to rule that out.
Bad DIMM is unlikely to cause random ASCII in memory. That's more like a
bad DMA or a buffer overflow in some driver. I would look for a unique
driver that user is using.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply
* Re: [RFC Patch net-next] ipv6: unify conntrack reassembly expire code with standard one
From: Michal Kubecek @ 2012-08-20 20:21 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, Herbert Xu, David S. Miller, Hideaki YOSHIFUJI,
Patrick McHardy, Shan Wei, Pablo Neira Ayuso, netfilter-devel
In-Reply-To: <1345453599.22373.9.camel@cr0>
On Mon, Aug 20, 2012 at 05:06:39PM +0800, Cong Wang wrote:
> doesn't work. I think we probably can save the struct net pointer in
> struct netns_frags during inet_frags_init_net(), so that container_of()
> can be eliminated.
This would work but one would have to check carefully that the pointer
is always set to an usable value. Or we could just add a flag indicating
whether the structure is embedded (and if it is not, use init_net).
Another approach was suggested in the patchworks discussion: add a
special namespace for IPv6 conntrack fragment handling.
> Thanks for testing! I tried to test it too, but seems I can't trigger a
> defragment. Any hints?
I used netfilter on a computer between source and destination of the
packets (generated with "ping6 -s 3000"):
ip6tables -A FORWARD -o ... -m frag --fragid 0:0xFFFFFFFF --fraglast -j DROP
The --fragid condition is needed to work around a bug in iptables (if
frag module is loaded and there is no --fragid, only packets with zero
fragment id match - patch for this is already in git). On the target,
packet is defragmented automatically, by default by the "normal" code,
with nf_conntrack_ipv6 module by the conntrack code.
Setting
echo 5 >/proc/sys/net/ipv6/ip6frag_time
echo 5 >/proc/sys/net/netfilter/nf_conntrack_frag6_timeout
on target also helps.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH iproute2 2/2] em_canid: Ematch used to classify CAN frames according to their identifiers
From: Stephen Hemminger @ 2012-08-20 20:13 UTC (permalink / raw)
To: Rostislav Lisovy; +Cc: netdev, linux-can, pisa, sojkam1
In-Reply-To: <1343745981-14248-2-git-send-email-lisovy@gmail.com>
On Tue, 31 Jul 2012 16:46:21 +0200
Rostislav Lisovy <lisovy@gmail.com> wrote:
> This ematch enables effective filtering of CAN frames (AF_CAN) based
> on CAN identifiers with masking of compared bits. Implementation
> utilizes bitmap based classification for standard frame format (SFF)
> which is optimized for minimal overhead.
>
> Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
Since this doesn't have any conflicts (unlike other CAN filtering),
I applied it for 3.6 version.
^ permalink raw reply
* Re: [PATCH iproute2 v2 0/3] CAN Filter/Classifier
From: Stephen Hemminger @ 2012-08-20 20:06 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: netdev, linux-can, lartc, pisa, sojkam1, lisovy
In-Reply-To: <1343383363-6174-1-git-send-email-mkl@pengutronix.de>
On Fri, 27 Jul 2012 12:02:40 +0200
Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> Hello,
>
> I'm reposting Rostislav's iproute2 patches, as Stephen requested,
> during the v3.6 merge window with the corresponding kernel patches
> already applied.
>
> Changes since v1:
> - use can.h generated by 'make headers_install' (tnx Stephen)
> - remove some trailing whitespace
>
> Now Rostislav original introduction message:
>
> ---
>
> This classifier classifies CAN frames (AF_CAN) according to their
> identifiers. This functionality can not be easily achieved with
> existing classifiers, such as u32. This classifier can be used
> with any available qdisc and it is able to classify both SFF
> or EFF frames.
>
> The filtering rules for EFF frames are stored in an array, which
> is traversed during classification. A bitmap is used to store SFF
> rules -- one bit for each ID.
>
> More info about the project:
> http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf
>
> ---
>
> The following changes since commit fa1f7441a94670ecf5cbf8eb2ee19173437b5127:
>
> Remove reference to multipath algorithms in usage (2012-07-26 16:12:20 -0700)
>
> are available in the git repository at:
>
> git://gitorious.org/linux-can/iproute2.git for-stephen
>
If your changes work with 3.6 then please rebase your patches on current iproute2 tree.
Note: do not include changes to include/linux which now includes can.h
and matches 3.6-rc2.
^ permalink raw reply
* Re: [PATCH] iproute: Fix errno propagation from rtnl_talk
From: Stephen Hemminger @ 2012-08-20 19:55 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Stephen Hemminger, Linux Netdev List
In-Reply-To: <5031F088.1030404@parallels.com>
On Mon, 20 Aug 2012 12:08:40 +0400
Pavel Emelyanov <xemul@parallels.com> wrote:
> Callers of rtnl_talk check errno value for their needs. In particular, the addrs
> and routes restoring code validly reports success if the EEXISTS is in there.
>
> However, the errno value can be sometimes screwed up by the perror call. Thus
> we should only set it _after_ the message was emitted.
>
> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
>
> ---
>
> diff --git a/lib/libnetlink.c b/lib/libnetlink.c
> index 878911e..8e8c8b9 100644
> --- a/lib/libnetlink.c
> +++ b/lib/libnetlink.c
> @@ -360,13 +360,14 @@ int rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n, pid_t peer,
> if (l < sizeof(struct nlmsgerr)) {
> fprintf(stderr, "ERROR truncated\n");
> } else {
> - errno = -err->error;
> - if (errno == 0) {
> + if (!err->error) {
> if (answer)
> memcpy(answer, h, h->nlmsg_len);
> return 0;
> }
> - perror("RTNETLINK answers");
> +
> + fprintf(stderr, "RTNETLINK answers: %s\n", strerror(-err->error));
> + errno = -err->error;
> }
> return -1;
> }
Applied
^ permalink raw reply
* [PATCH] [v2] net/fsl: introduce Freescale 10G MDIO driver
From: Timur Tabi @ 2012-08-20 19:26 UTC (permalink / raw)
To: David Miller, netdev, Andy Fleming, romieu
Similar to fsl_pq_mdio.c, this driver is for the 10G MDIO controller on
Freescale Frame Manager Ethernet controllers.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
v2: add register polling helper functions, clean up messages
drivers/net/ethernet/freescale/Kconfig | 7 +
drivers/net/ethernet/freescale/Makefile | 1 +
drivers/net/ethernet/freescale/xgmac_mdio.c | 274 +++++++++++++++++++++++++++
3 files changed, 282 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/ethernet/freescale/xgmac_mdio.c
diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
index 3574e14..feff516 100644
--- a/drivers/net/ethernet/freescale/Kconfig
+++ b/drivers/net/ethernet/freescale/Kconfig
@@ -62,6 +62,13 @@ config FSL_PQ_MDIO
---help---
This driver supports the MDIO bus used by the gianfar and UCC drivers.
+config FSL_XGMAC_MDIO
+ tristate "Freescale XGMAC MDIO"
+ depends on FSL_SOC
+ select PHYLIB
+ ---help---
+ This driver supports the MDIO bus on the Fman 10G Ethernet MACs.
+
config UCC_GETH
tristate "Freescale QE Gigabit Ethernet"
depends on QUICC_ENGINE
diff --git a/drivers/net/ethernet/freescale/Makefile b/drivers/net/ethernet/freescale/Makefile
index 1752488..3d1839a 100644
--- a/drivers/net/ethernet/freescale/Makefile
+++ b/drivers/net/ethernet/freescale/Makefile
@@ -9,6 +9,7 @@ ifeq ($(CONFIG_FEC_MPC52xx_MDIO),y)
endif
obj-$(CONFIG_FS_ENET) += fs_enet/
obj-$(CONFIG_FSL_PQ_MDIO) += fsl_pq_mdio.o
+obj-$(CONFIG_FSL_XGMAC_MDIO) += xgmac_mdio.o
obj-$(CONFIG_GIANFAR) += gianfar_driver.o
obj-$(CONFIG_PTP_1588_CLOCK_GIANFAR) += gianfar_ptp.o
gianfar_driver-objs := gianfar.o \
diff --git a/drivers/net/ethernet/freescale/xgmac_mdio.c b/drivers/net/ethernet/freescale/xgmac_mdio.c
new file mode 100644
index 0000000..1afb5ea
--- /dev/null
+++ b/drivers/net/ethernet/freescale/xgmac_mdio.c
@@ -0,0 +1,274 @@
+/*
+ * QorIQ 10G MDIO Controller
+ *
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Authors: Andy Fleming <afleming@freescale.com>
+ * Timur Tabi <timur@freescale.com>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+#include <linux/mdio.h>
+#include <linux/of_platform.h>
+#include <linux/of_mdio.h>
+
+/* Number of microseconds to wait for a register to respond */
+#define TIMEOUT 1000
+
+struct tgec_mdio_controller {
+ __be32 reserved[12];
+ __be32 mdio_stat; /* MDIO configuration and status */
+ __be32 mdio_ctl; /* MDIO control */
+ __be32 mdio_data; /* MDIO data */
+ __be32 mdio_addr; /* MDIO address */
+} __packed;
+
+#define MDIO_STAT_CLKDIV(x) (((x>>1) & 0xff) << 8)
+#define MDIO_STAT_BSY (1 << 0)
+#define MDIO_STAT_RD_ER (1 << 1)
+#define MDIO_CTL_DEV_ADDR(x) (x & 0x1f)
+#define MDIO_CTL_PORT_ADDR(x) ((x & 0x1f) << 5)
+#define MDIO_CTL_PRE_DIS (1 << 10)
+#define MDIO_CTL_SCAN_EN (1 << 11)
+#define MDIO_CTL_POST_INC (1 << 14)
+#define MDIO_CTL_READ (1 << 15)
+
+#define MDIO_DATA(x) (x & 0xffff)
+#define MDIO_DATA_BSY (1 << 31)
+
+/*
+ * Wait untill the MDIO bus is free
+ */
+static int xgmac_wait_until_free(struct device *dev,
+ struct tgec_mdio_controller __iomem *regs)
+{
+ uint32_t status;
+
+ /* Wait till the bus is free */
+ status = spin_event_timeout(
+ !((in_be32(®s->mdio_stat)) & MDIO_STAT_BSY), TIMEOUT, 0);
+ if (!status) {
+ dev_err(dev, "timeout waiting for bus to be free\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+/*
+ * Wait till the MDIO read or write operation is complete
+ */
+static int xgmac_wait_until_done(struct device *dev,
+ struct tgec_mdio_controller __iomem *regs)
+{
+ uint32_t status;
+
+ /* Wait till the MDIO write is complete */
+ status = spin_event_timeout(
+ !((in_be32(®s->mdio_data)) & MDIO_DATA_BSY), TIMEOUT, 0);
+ if (!status) {
+ dev_err(dev, "timeout waiting for operation to complete\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+/*
+ * Write value to the PHY for this device to the register at regnum,waiting
+ * until the write is done before it returns. All PHY configuration has to be
+ * done through the TSEC1 MIIM regs.
+ */
+static int xgmac_mdio_write(struct mii_bus *bus, int phy_id, int regnum, u16 value)
+{
+ struct tgec_mdio_controller __iomem *regs = bus->priv;
+ uint16_t dev_addr = regnum >> 16;
+ int ret;
+
+ /* Setup the MII Mgmt clock speed */
+ out_be32(®s->mdio_stat, MDIO_STAT_CLKDIV(100));
+
+ ret = xgmac_wait_until_free(&bus->dev, regs);
+ if (ret)
+ return ret;
+
+ /* Set the port and dev addr */
+ out_be32(®s->mdio_ctl,
+ MDIO_CTL_PORT_ADDR(phy_id) | MDIO_CTL_DEV_ADDR(dev_addr));
+
+ /* Set the register address */
+ out_be32(®s->mdio_addr, regnum & 0xffff);
+
+ ret = xgmac_wait_until_free(&bus->dev, regs);
+ if (ret)
+ return ret;
+
+ /* Write the value to the register */
+ out_be32(®s->mdio_data, MDIO_DATA(value));
+
+ ret = xgmac_wait_until_done(&bus->dev, regs);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+/*
+ * Reads from register regnum in the PHY for device dev, returning the value.
+ * Clears miimcom first. All PHY configuration has to be done through the
+ * TSEC1 MIIM regs.
+ */
+static int xgmac_mdio_read(struct mii_bus *bus, int phy_id, int regnum)
+{
+ struct tgec_mdio_controller __iomem *regs = bus->priv;
+ uint16_t dev_addr = regnum >> 16;
+ uint32_t mdio_ctl;
+ uint16_t value;
+ int ret;
+
+ /* Setup the MII Mgmt clock speed */
+ out_be32(®s->mdio_stat, MDIO_STAT_CLKDIV(100));
+
+ ret = xgmac_wait_until_free(&bus->dev, regs);
+ if (ret)
+ return ret;
+
+ /* Set the Port and Device Addrs */
+ mdio_ctl = MDIO_CTL_PORT_ADDR(phy_id) | MDIO_CTL_DEV_ADDR(dev_addr);
+ out_be32(®s->mdio_ctl, mdio_ctl);
+
+ /* Set the register address */
+ out_be32(®s->mdio_addr, regnum & 0xffff);
+
+ ret = xgmac_wait_until_free(&bus->dev, regs);
+ if (ret)
+ return ret;
+
+ /* Initiate the read */
+ out_be32(®s->mdio_ctl, mdio_ctl | MDIO_CTL_READ);
+
+ ret = xgmac_wait_until_done(&bus->dev, regs);
+ if (ret)
+ return ret;
+
+ /* Return all Fs if nothing was there */
+ if (in_be32(®s->mdio_stat) & MDIO_STAT_RD_ER) {
+ dev_err(&bus->dev, "MDIO read error\n");
+ return 0xffff;
+ }
+
+ value = in_be32(®s->mdio_data) & 0xffff;
+ dev_dbg(&bus->dev, "read %04x\n", value);
+
+ return value;
+}
+
+/* Reset the MIIM registers, and wait for the bus to free */
+static int xgmac_mdio_reset(struct mii_bus *bus)
+{
+ struct tgec_mdio_controller __iomem *regs = bus->priv;
+ int ret;
+
+ mutex_lock(&bus->mdio_lock);
+
+ /* Setup the MII Mgmt clock speed */
+ out_be32(®s->mdio_stat, MDIO_STAT_CLKDIV(100));
+
+ ret = xgmac_wait_until_free(&bus->dev, regs);
+
+ mutex_unlock(&bus->mdio_lock);
+
+ return ret;
+}
+
+static int __devinit xgmac_mdio_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct mii_bus *bus;
+ struct resource res;
+ int ret;
+
+ ret = of_address_to_resource(np, 0, &res);
+ if (ret) {
+ dev_err(&pdev->dev, "could not obtain address\n");
+ return ret;
+ }
+
+ bus = mdiobus_alloc_size(PHY_MAX_ADDR * sizeof(int));
+ if (!bus)
+ return -ENOMEM;
+
+ bus->name = "Freescale XGMAC MDIO Bus";
+ bus->read = xgmac_mdio_read;
+ bus->write = xgmac_mdio_write;
+ bus->reset = xgmac_mdio_reset;
+ bus->irq = bus->priv;
+ bus->parent = &pdev->dev;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%llx", (unsigned long long)res.start);
+
+ /* Set the PHY base address */
+ bus->priv = of_iomap(np, 0);
+ if (!bus->priv) {
+ ret = -ENOMEM;
+ goto err_ioremap;
+ }
+
+ ret = of_mdiobus_register(bus, np);
+ if (ret) {
+ dev_err(&pdev->dev, "cannot register MDIO bus\n");
+ goto err_registration;
+ }
+
+ dev_set_drvdata(&pdev->dev, bus);
+
+ return 0;
+
+err_registration:
+ iounmap(bus->priv);
+
+err_ioremap:
+ mdiobus_free(bus);
+
+ return ret;
+}
+
+static int __devexit xgmac_mdio_remove(struct platform_device *pdev)
+{
+ struct mii_bus *bus = dev_get_drvdata(&pdev->dev);
+
+ mdiobus_unregister(bus);
+ iounmap(bus->priv);
+ mdiobus_free(bus);
+
+ return 0;
+}
+
+static struct of_device_id xgmac_mdio_match[] = {
+ {
+ .compatible = "fsl,fman-xmdio",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, xgmac_mdio_match);
+
+static struct platform_driver xgmac_mdio_driver = {
+ .driver = {
+ .name = "fsl-fman_xmdio",
+ .of_match_table = xgmac_mdio_match,
+ },
+ .probe = xgmac_mdio_probe,
+ .remove = xgmac_mdio_remove,
+};
+
+module_platform_driver(xgmac_mdio_driver);
+
+MODULE_DESCRIPTION("Freescale QorIQ 10G MDIO Controller");
+MODULE_LICENSE("GPL v2");
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 2/2] [RFC] netlink: fix possible spoofing from non-root processes
From: Pablo Neira Ayuso @ 2012-08-20 19:09 UTC (permalink / raw)
To: netdev; +Cc: davem
In-Reply-To: <20120819212327.GA14853@1984>
On Sun, Aug 19, 2012 at 11:23:27PM +0200, Pablo Neira Ayuso wrote:
> On Fri, Aug 17, 2012 at 07:22:29PM +0200, pablo@netfilter.org wrote:
> [...]
> > [ I don't know any FOSS program making use of Netlink to communicate
> > to processes, please, let me know if I'm missing anyone important ]
>
> Patrick pinged me for little reminder on NETLINK_USERSOCK. We still
> have to allow netlink-to-netlink userspace communication for it.
>
> So, please find a new version of this patch that allows non-root
> processes for that Netlink bus. For others, my patch restricts to root
> processes the ability of sending messages with dst_pid != 0.
Sorry, I just noticed that you cannot apply this to your net tree
since it depends on patch 1/2 which is not a fix.
I'll get back to you with one path that you can apply to your net
tree.
I'll resend 1/2 later to net-next once this has been sorted out.
^ permalink raw reply
* Re: [PATCH net-next] packet: Protect packet sk list with mutex
From: Eric Dumazet @ 2012-08-20 19:05 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: David Miller, Linux Netdev List
In-Reply-To: <50327D8A.5010400@parallels.com>
On Mon, 2012-08-20 at 22:10 +0400, Pavel Emelyanov wrote:
> AFAIU now this is the case for e.g. TCP sockets since they can be created in
> rx code. For packet I've found no places where these stats can be modified other
> than those two in af_packet.c
sock_prot_inuse_add() uses __this_cpu_add(), and on non x86, needs to be
safe against preemption ( or irq if applicable)
Changing spin_lock_bh() to mutex_lock() breaks this.
^ permalink raw reply
* Re: [PATCH V2 09/12] net/eipoib: Add main driver functionality
From: Michael S. Tsirkin @ 2012-08-20 18:57 UTC (permalink / raw)
To: Or Gerlitz
Cc: Eric W. Biederman, davem, roland, netdev, ali, sean.hefty,
Erez Shitrit, Doug Ledford
In-Reply-To: <20120812205457.GA14081@redhat.com>
On Sun, Aug 12, 2012 at 11:54:57PM +0300, Michael S. Tsirkin wrote:
> > and remember that
> > this code (VM through eipoib) can talk to any IPoIB element on the
> > fabric, native,
> > virtualized, HW/SW gateways, etc etc.
> >
> > Or.
>
> If you want this, then you really want a limited form of IPoIB bridging.
And to clarify that statement, here is how I would make such
IPoIB "bridging" work:
Guest side:
- Implement virtio-ipoib. This would be a device like virtio-net,
but instead of ethernet packets, it would pass packets
that consist of:
IPoIB destination address
IP packet
- this is passed to/from host without modifications, possibly with addition
of header such as virtio net header
- flags such as broadcast can also be added to header
- like virtio net get capabilities from host and expose
as netdev capabilities
Host side:
- create macvtap -passthrough like device that can sit on top of an
ipoib interface
- expose this device QPN and GID to guest as hardware address
- as we get packet forward it on UD QPN or CM as appropriate
depending on size,checksum and admin preference
- expose capabilities such as TSO
- can expose capability such as max MTU to guest too
Above means hardware address changes with migration.
So we need to notify guest when this happens.
This can be addressed from host by notifying all
neighbours.
Alternatively guest can notify all neighbours.
Notification can be done by broadcast.
This second option seems preferable.
this ipoib-vtap can support two modes
- bridge like mode:
guest to guest and guest to host packets
can be detected by macvtap and passed
to/from guest directly like macvlan bridge mode
- vepa like mode
guest to guest and guest to host packets
are sent out and looped back by IB switch
like macvlan vepa mode
As compared to the custom protocol I sent, it has -
Advantages: interoperates cleanly with ipoib
Disadvantages: no support for legacy (ethernet-only) guest
--
MST
^ permalink raw reply
* Re: Documenting UNIX domain autobind
From: Colin McCabe @ 2012-08-20 18:42 UTC (permalink / raw)
To: linux-man, netdev
> Hello Tetsuo,
>
> I'm the Linux man-pages mainatiner. I write to you because I see that
> you recently (http://kerneltrap.org/mailarchive/linux-netdev/2010/8/30/6284106/thread#mid-6284106)
> did some work patchiing Linux unix_autobind(), so you may know the
> answer to this question. But, also others on the CC may know.
>
> I recently noticed this feature in the kernel, and so added some
> documentation to the unix(7) man page. That text reads as follows:
>
> Autobind Feature
> If a bind() call specifies addrlen as sizeof(sa_family_t), or
> the SO_PASSCRED socket option was specified for a socket that
> was not explicitly bound to an address, then the socket is
> autobound to an abstract address. The address consists of a
> null byte followed by 5 bytes in the character set [0-9a-f].
> (Thus, there is a limit of 2^20 autobind addresses.)
>
> I think this text correctly documents the technical details (but let
> me know if you see errors). What is lacking is an explanation of why
> this feature exists. Is someone able to explain where this feature is
> used and why?
>
> thanks,
>
> Michael
I wasn't involved in developing this feature, but as someone who has
used UNIX domain sockets in the past, I think I can comment on this.
As you know, you have to bind every UNIX domain socket to a unique
identifier. In Linux, this can be either a path or an entry in the
abstract namespace. Either way, if you try to use an identifier that
someone is already using, it won't work. If autobind did not exist,
you could write a loop to try random identifers until you get one that
works. With autobind, you don't have to write this code and risk
getting it wrong.
Another consideration is that autobind gives you a guarantee that
you're not using an identifier that someone else has chosen. Without
this guarantee, it's possible that the random-ish identifer you chose
will conflict with another process on the system. One man's randomly
chosen string is another man's carefully-chosen identifier. Autobind
eliminates this risk completely.
It would be nice to see some discussion in the man pages about the
potential security issues of using UNIX domain sockets. For example,
if you create a UNIX domain socket under /tmp, a malicious process
could move it out of the way and create its own socket there,
effectively performing a man-in-the-middle attack on you. If you
create a socket under /tmp that is named predictably (like
/tmp/my-program-name), a malicious process could create a
denial-of-service by creating a socket or other entry in that
position. These issues can be avoided by using the abstract
namespace, or using a well-known and secure path for UNIX domain
sockets. However, a novice wouldn't necessarily know that he needed
to do that.
cheers,
Colin McCabe
^ permalink raw reply
* Re: [PATCH net-next] packet: Protect packet sk list with mutex
From: Pavel Emelyanov @ 2012-08-20 18:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1345475500.5158.321.camel@edumazet-glaptop>
On 08/20/2012 07:11 PM, Eric Dumazet wrote:
> On Mon, 2012-08-20 at 18:50 +0400, Pavel Emelyanov wrote:
>> In patch eea68e2f (packet: Report socket mclist info via diag module) I've
>> introduced a "scheduling in atomic" problem in packet diag module -- the
>> socket list is traversed under rcu_read_lock() while performed under it sk
>> mclist access requires rtnl lock (i.e. -- mutex) to be taken. Similar thing
>> was then re-introduced by further packet diag patches (fanount mutex and
>> pgvec mutex for rings) :(
>>
>> Apart from being terribly sorry for the above, I propose to change the
>> packet sk list protection from spinlock to mutex. This lock currently
>> protects only the sklist modifications (that already happen in sleeping
>> context) and nothing more.
>>
>> Am I wrong again and a fine-grained atomic locking is required for
>> everything that is reported by packet diag instead?
>>
>> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
>>
>> ---
>>
>> diff --git a/include/net/netns/packet.h b/include/net/netns/packet.h
>> index cb4e894..4780b08 100644
>> --- a/include/net/netns/packet.h
>> +++ b/include/net/netns/packet.h
>> @@ -8,7 +8,7 @@
>> #include <linux/spinlock.h>
>>
>> struct netns_packet {
>> - spinlock_t sklist_lock;
>> + struct mutex sklist_lock;
>> struct hlist_head sklist;
>> };
>>
>> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
>> index 226b2cd..5048672 100644
>> --- a/net/packet/af_packet.c
>> +++ b/net/packet/af_packet.c
>> @@ -2308,10 +2308,10 @@ static int packet_release(struct socket *sock)
>> net = sock_net(sk);
>> po = pkt_sk(sk);
>>
>> - spin_lock_bh(&net->packet.sklist_lock);
>> + mutex_lock(&net->packet.sklist_lock);
>> sk_del_node_init_rcu(sk);
>> sock_prot_inuse_add(net, sk->sk_prot, -1);
>
> Last time I checked, sock_prot_inuse_add() needed BH protection.
AFAIU now this is the case for e.g. TCP sockets since they can be created in
rx code. For packet I've found no places where these stats can be modified other
than those two in af_packet.c
> ( This could be relaxed somehow on x86 thanks to this_cpu_add() ... but
> thats another point)
>
> Could you please report the full stack trace ?
Sure:
[152363.820563] BUG: scheduling while atomic: crtools/12517/0x10000002
[152363.820573] 4 locks held by crtools/12517:
[152363.820581] #0: (sock_diag_mutex){+.+.+.}, at: [<ffffffff81a2dcb5>] sock_diag_rcv+0x1f/0x3e
[152363.820613] #1: (sock_diag_table_mutex){+.+.+.}, at: [<ffffffff81a2de70>] sock_diag_rcv_msg+0xdb/0x11a
[152363.820644] #2: (nlk->cb_mutex){+.+.+.}, at: [<ffffffff81a67d01>] netlink_dump+0x23/0x1ab
[152363.820693] #3: (rcu_read_lock){.+.+..}, at: [<ffffffff81b6a049>] packet_diag_dump+0x0/0x1af
[152363.820724] Modules linked in:
[152363.820737] Pid: 12517, comm: crtools Tainted: G W 3.6.0-rc1-46175-g07cbd24-dirty #236
[152363.820750] Call Trace:
[152363.820761] [<ffffffff810959c2>] __schedule_bug+0x6a/0x78
[152363.820772] [<ffffffff81c26cb9>] __schedule+0xb1/0x5b1
[152363.820784] [<ffffffff81098af0>] __cond_resched+0x2a/0x35
[152363.820795] [<ffffffff81c27234>] _cond_resched+0x2c/0x37
[152363.820806] [<ffffffff81c26210>] mutex_lock_nested+0x2a/0x45
[152363.820818] [<ffffffff81a2b81c>] rtnl_lock+0x17/0x19
[152363.820829] [<ffffffff81b69de0>] pdiag_put_mclist+0x4e/0xeb
[152363.820840] [<ffffffff81b6a001>] sk_diag_fill.clone.0+0x14c/0x194
[152363.820851] [<ffffffff81c28545>] ? _raw_read_unlock_bh+0x43/0x47
[152363.820863] [<ffffffff81b6a147>] packet_diag_dump+0xfe/0x1af
[152363.820874] [<ffffffff81b6a049>] ? sk_diag_fill.clone.0+0x194/0x194
[152363.820885] [<ffffffff81a67d4b>] netlink_dump+0x6d/0x1ab
[152363.820896] [<ffffffff81a6847f>] netlink_dump_start+0xed/0x114
[152363.820907] [<ffffffff81b69d89>] packet_diag_handler_dump+0x61/0x6a
[152363.820918] [<ffffffff81b6a049>] ? sk_diag_fill.clone.0+0x194/0x194
[152363.820930] [<ffffffff81a2de8b>] sock_diag_rcv_msg+0xf6/0x11a
[152363.820941] [<ffffffff81a2dd95>] ? sock_diag_register_inet_compat+0x36/0x36
[152363.820953] [<ffffffff81a690a0>] netlink_rcv_skb+0x43/0x94
[152363.820979] [<ffffffff81a2dcc4>] sock_diag_rcv+0x2e/0x3e
[152363.820990] [<ffffffff81a68e4f>] netlink_unicast+0xe9/0x16f
[152363.821002] [<ffffffff81a69601>] netlink_sendmsg+0x1e6/0x204
[152363.821129] [<ffffffff81a0ba29>] ? rcu_read_unlock+0x56/0x67
[152363.821143] [<ffffffff81a06877>] __sock_sendmsg_nosec+0x58/0x61
[152363.821155] [<ffffffff81a072b6>] sock_sendmsg+0x6e/0x87
[152363.821168] [<ffffffff8113a172>] ? might_fault+0xa5/0xac
[152363.821180] [<ffffffff81a138ae>] ? copy_from_user+0x2a/0x2c
[152363.821192] [<ffffffff81a13c9e>] ? verify_iovec+0x54/0xaa
[152363.821204] [<ffffffff81a08092>] __sys_sendmsg+0x211/0x2a7
[152363.821216] [<ffffffff810b7515>] ? lock_release_holdtime+0x2c/0xf5
[152363.821228] [<ffffffff810bba71>] ? __lock_release+0x113/0x12c
[152363.821243] [<ffffffff81c28937>] ? _raw_spin_unlock_irq+0x30/0x4a
[152363.821257] [<ffffffff810bafa6>] ? trace_hardirqs_on_caller+0x123/0x15a
[152363.821272] [<ffffffff810bafea>] ? trace_hardirqs_on+0xd/0xf
[152363.821286] [<ffffffff8116dc31>] ? fcheck_files+0xac/0xea
[152363.821297] [<ffffffff8116ddaa>] ? fget_light+0x3a/0xb9
[152363.821309] [<ffffffff81c27183>] ? __schedule+0x57b/0x5b1
[152363.821320] [<ffffffff81a082ed>] sys_sendmsg+0x42/0x60
[152363.821332] [<ffffffff81c295e9>] system_call_fastpath+0x16/0x1b
>
>
Thank,
Pavel
^ permalink raw reply
* Re: [PATCH 07/21] userns: Use kgids for sysctl_ping_group_range
From: Vasiliy Kulikov @ 2012-08-20 18:09 UTC (permalink / raw)
To: Eric W. Biederman
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <1344889115-21610-7-git-send-email-ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On Mon, Aug 13, 2012 at 13:18 -0700, Eric W. Biederman wrote:
> From: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>
> - Store sysctl_ping_group_range as a paire of kgid_t values
> instead of a pair of gid_t values.
> - Move the kgid conversion work from ping_init_sock into ipv4_ping_group_range
> - For invalid cases reset to the default disabled state.
>
> With the kgid_t conversion made part of the original value sanitation
> from userspace understand how the code will react becomes clearer
> and it becomes possible to set the sysctl ping group range from
> something other than the initial user namespace.
>
> Cc: Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Looks good.
Acked-by: Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* [PATCH] cls_cgroup: Allow classifier cgroups to have their classid reset to 0
From: Neil Horman @ 2012-08-20 17:59 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, David S. Miller
The network classifier cgroup initalizes each cgroups instance classid value to
0. However, the sock_update_classid function only updates classid's in sockets
if the tasks cgroup classid is not zero, and if it differs from the current
classid. The later check is to prevent cache line dirtying, but the former is
detrimental, as it prevents resetting a classid for a cgroup to 0. While this
is not a common action, it has administrative usefulness (if the admin wants to
disable classification of a certain group temporarily for instance).
Easy fix, just remove the zero check. Tested successfully by myself
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
---
net/core/sock.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 8f67ced..116786c 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1230,7 +1230,7 @@ void sock_update_classid(struct sock *sk)
rcu_read_lock(); /* doing current task, which cannot vanish. */
classid = task_cls_classid(current);
rcu_read_unlock();
- if (classid && classid != sk->sk_classid)
+ if (classid != sk->sk_classid)
sk->sk_classid = classid;
}
EXPORT_SYMBOL(sock_update_classid);
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH] tc-tbf.8: Add parameter range to man page.
From: Stephen Hemminger @ 2012-08-20 17:58 UTC (permalink / raw)
To: Li Wei; +Cc: netdev
In-Reply-To: <5031DADC.6060509@cn.fujitsu.com>
>
> Not very clear with "the generic documentation about qdisc parameters
> which already exists on 'tc-qdisc' man page", is there a separate man page
> that describe qdisc parameters?
>
> I'm reading the iproute2 and kernel code which related to TC and record the
> value range for each parameter, I think that would be helpful for somebody
> else.
>
Rather than putting range on each parameter on every sub-page of tc man
page. Why not put something in tc.8 under UNITS.
The following implies everything is floating-point which it isn't:
UNITS
All parameters accept a floating point number, possibly followed by a
unit.
I would like this section broken down to cover all the generic types
PARAMETERS
RATES
TIMES
SIZES
VALUES
Also needs to explain IEC units here.
^ permalink raw reply
* Re: [PATCH v0 5/5] cgroup: Assign subsystem IDs during compile time
From: Tejun Heo @ 2012-08-20 17:51 UTC (permalink / raw)
To: Daniel Wagner
Cc: Li Zefan, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Daniel Wagner, David S. Miller,
Andrew Morton, Eric Dumazet, Gao feng, Glauber Costa,
Jamal Hadi Salim, John Fastabend, Kamezawa Hiroyuki, Neil Horman
In-Reply-To: <502E0552.3080602-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
Hello, Daniel, Li.
On Fri, Aug 17, 2012 at 10:48:18AM +0200, Daniel Wagner wrote:
> >I think so.
>
> I am preparing an updated version which does not need the extra 1
> pointer. Some more preprocessor magic involved :)
Please try to refrain from macros as much as possible. Let's try to
keep things C. :)
> >I'm definitely all for simplicity, but I'm not sure if we can do better in
> >simplifying the code for modularized cgroup subsystem. (I guess you didn't
> >mean to remove this feature?)
>
> The new version should also be simpler to review because I don't
> have to touch the loops everywhere.
e.g. Why does the proposed code have different variants of
task_cls_classid() for builtin and modular cases? Why not just use
the same code path if the ID is always static anyway? Also, longer
term, maybe we can unify root cgroup initialization for built-in and
modular cases?
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] ipv4: fix ip header ident selection in __ip_make_skb()
From: Eric Dumazet @ 2012-08-20 17:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Stephen Hemminger, Christian Casteyde
From: Eric Dumazet <edumazet@google.com>
Christian Casteyde reported a kmemcheck 32-bit read from uninitialized
memory in __ip_select_ident().
It turns out that __ip_make_skb() called ip_select_ident() before
properly initializing iph->daddr.
This is a bug uncovered by commit 1d861aa4b3fb (inet: Minimize use of
cached route inetpeer.)
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=46131
Reported-by: Christian Casteyde <casteyde.christian@free.fr>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>
---
net/ipv4/ip_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index 147ccc3..c196d74 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -1338,10 +1338,10 @@ struct sk_buff *__ip_make_skb(struct sock *sk,
iph->ihl = 5;
iph->tos = inet->tos;
iph->frag_off = df;
- ip_select_ident(iph, &rt->dst, sk);
iph->ttl = ttl;
iph->protocol = sk->sk_protocol;
ip_copy_addrs(iph, fl4);
+ ip_select_ident(iph, &rt->dst, sk);
if (opt) {
iph->ihl += opt->optlen>>2;
^ permalink raw reply related
* Re: 3.5.1 fib_rules_lookup oops
From: Dave Jones @ 2012-08-20 17:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Fedora Kernel Team
In-Reply-To: <1345481979.5158.333.camel@edumazet-glaptop>
On Mon, Aug 20, 2012 at 06:59:39PM +0200, Eric Dumazet wrote:
> On Mon, 2012-08-20 at 12:44 -0400, Dave Jones wrote:
> > Just had a user report this, which I don't think I've seen reported here yet.
> > Something new, or just something missing from -stable ?
> >
> > Dave
> >
> >
> > BUG: unable to handle kernel paging request at 5f726571
> > IP: [<c0884808>] fib_rules_lookup+0x38/0x130
> > *pdpt = 000000002b8ef001 *pde = 0000000000000000
> > Oops: 0000 [#1] SMP
>
> It looks like a buffer overflow or memory reuse
>
> 5f726565 is not a valid pointer, but ASCII "eer_"
Yeah.
Same user reported a slew of other problems, so he may have bad hardware.
I've asked him to run a memtest to rule that out.
Dave
^ permalink raw reply
* Re: [PATCH v1 3/5] cgroup: Protect access to task_cls_classid() when built as module
From: Neil Horman @ 2012-08-20 17:03 UTC (permalink / raw)
To: Daniel Wagner
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Daniel Wagner, David S. Miller, Gao feng, Jamal Hadi Salim,
John Fastabend, Li Zefan, Tejun Heo
In-Reply-To: <20120820112938.GA22415-rjQKm2AMs/APuY3F5OKgMy7zKzJi9e1+kcYEyfhdaNw@public.gmane.org>
On Mon, Aug 20, 2012 at 01:29:38PM +0200, Daniel Wagner wrote:
> On Fri, Aug 17, 2012 at 02:28:55PM -0400, Neil Horman wrote:
> > On Fri, Aug 17, 2012 at 04:58:12PM +0200, Daniel Wagner wrote:
> > > From: Daniel Wagner <daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>
> > >
> > > The module version of task_cls_classid() checks if net_cls_sbusys_id
> > > is valid to indentify when it is okay to access the controller.
> > >
> > > Instead relying on the subusys_id to be set, make it explicit
> > > with a jump label.
> > >
> > > Signed-off-by: Daniel Wagner <daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>
> > > Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> > > Cc: Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
> > > Cc: Jamal Hadi Salim <jhs-jkUAjuhPggJWk0Htik3J/w@public.gmane.org>
> > > Cc: John Fastabend <john.r.fastabend-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > > Cc: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > Cc: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> > > Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > ---
> > > include/net/cls_cgroup.h | 5 ++++-
> > > net/core/sock.c | 5 +++++
> > > net/sched/cls_cgroup.c | 9 +++++++++
> > > 3 files changed, 18 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/net/cls_cgroup.h b/include/net/cls_cgroup.h
> > > index 401672c..bbbd957 100644
> > > --- a/include/net/cls_cgroup.h
> > > +++ b/include/net/cls_cgroup.h
> > > @@ -16,6 +16,7 @@
> > > #include <linux/cgroup.h>
> > > #include <linux/hardirq.h>
> > > #include <linux/rcupdate.h>
> > > +#include <linux/jump_label.h>
> > >
> > > #ifdef CONFIG_CGROUPS
> > > struct cgroup_cls_state
> > > @@ -44,6 +45,8 @@ static inline u32 task_cls_classid(struct task_struct *p)
> > > }
> > >
> > > #elif IS_MODULE(CONFIG_NET_CLS_CGROUP)
> > > +extern struct static_key cgroup_cls_enabled;
> > > +#define clscg_enabled static_key_false(&cgroup_cls_enabled)
> > >
> > > extern int net_cls_subsys_id;
> > >
> > > @@ -52,7 +55,7 @@ static inline u32 task_cls_classid(struct task_struct *p)
> > > int id;
> > > u32 classid = 0;
> > >
> > > - if (in_interrupt())
> > > + if (!clscg_enabled || in_interrupt())
> > > return 0;
> > >
> > > rcu_read_lock();
> > > diff --git a/net/core/sock.c b/net/core/sock.c
> > > index 8f67ced..8106e77 100644
> > > --- a/net/core/sock.c
> > > +++ b/net/core/sock.c
> > > @@ -327,6 +327,11 @@ int __sk_backlog_rcv(struct sock *sk, struct sk_buff *skb)
> > > EXPORT_SYMBOL(__sk_backlog_rcv);
> > >
> > > #if defined(CONFIG_CGROUPS)
> > > +#if IS_MODULE(CONFIG_NET_CLS_CGROUP)
> > > +struct static_key cgroup_cls_enabled = STATIC_KEY_INIT_FALSE;
> > > +EXPORT_SYMBOL_GPL(cgroup_cls_enabled);
> > > +#endif
> > > +
> > > #if !defined(CONFIG_NET_CLS_CGROUP)
> > > int net_cls_subsys_id = -1;
> > > EXPORT_SYMBOL_GPL(net_cls_subsys_id);
> > > diff --git a/net/sched/cls_cgroup.c b/net/sched/cls_cgroup.c
> > > index 7743ea8..0635894 100644
> > > --- a/net/sched/cls_cgroup.c
> > > +++ b/net/sched/cls_cgroup.c
> > > @@ -44,12 +44,21 @@ static struct cgroup_subsys_state *cgrp_create(struct cgroup *cgrp)
> > >
> > > if (cgrp->parent)
> > > cs->classid = cgrp_cls_state(cgrp->parent)->classid;
> > > +#if IS_MODULE(CONFIG_NET_CLS_CGROUP)
> > > + else if (!clscg_enabled)
> > > + static_key_slow_inc(&cgroup_cls_enabled);
> > This is racy I think. The read of the static key is atomic with other reads,
> > but the entire conditional is not atomic. If two cpus were creating cgroups in
> > parallel, it would be possible for both to read the static key as being zero
> > (the second cpu would read the key before the first cpu could increment it).
>
> D'oh, That is racy.
>
> > > +#endif
> > >
> > > return &cs->css;
> > > }
> > >
> > > static void cgrp_destroy(struct cgroup *cgrp)
> > > {
> > > +#if IS_MODULE(CONFIG_NET_CLS_CGROUP)
> > > + if (!cgrp->parent && clscg_enabled)
> > > + static_key_slow_dec(&cgroup_cls_enabled);
> > Ditto here with the race above. I think what you want is one of:
> >
> > 1) Use static_key_slow_[inc|dec] unconditionally
>
> While the static_key_slow_inc() case will work, I am not so sure about
> the static_key_slow_dec(), e.g. we could still access inside
> task_cls_classid() a destroyed container.
>
Possibly, yes, I think.
> > 2) Keep a separate internal counter to track the number of cgroup instances
> > so that you only inc the static key on the first create and dec it on the last
> > delete.
>
> If I got you right, than this would not be different then direclty using
> static_key_slow_[inc|dec].
>
As long as a cgroup subsystems ->destroy method is only called when the
subsystem is being removed, then I think thats correct. I'm not 100% sure thats
the case though.
> > I would think (1) would be sufficent. It looks like static_key_slow_inc uses
> > atomic_inc_not_zero to just do an inc anyway in the event that multiple inc
> > events are made.
>
> Would something like this work?
>
I think so yes, assuming that you also make the slow_inc|dec changes
> static inline u32 task_cls_classid(struct task_struct *p)
> {
> u32 classid;
> struct cgroup_cls_state *css;
>
> if (!clscg_enabled || in_interrupt())
> return 0;
>
> rcu_read_lock();
> css = container_of(task_subsys_state(p, net_cls_subsys_id),
> struct cgroup_cls_state, css);
> if (!css)
> classid = css->classid;
> else
> classid = 0;
> rcu_read_unlock();
>
> return classid;
> }
>
> Daniel
>
^ permalink raw reply
* Re: regression with poll(2)
From: Linus Torvalds @ 2012-08-20 17:02 UTC (permalink / raw)
To: Mel Gorman, Andrew Morton
Cc: Sage Weil, David Miller, netdev, linux-kernel, ceph-devel,
Neil Brown, Peter Zijlstra, michaelc, emunson, Eric Dumazet,
Christoph Lameter
In-Reply-To: <20120820090443.GA3275@suse.de>
On Mon, Aug 20, 2012 at 2:04 AM, Mel Gorman <mgorman@suse.de> wrote:
>
> Can the following patch be tested please? It is reported to fix an fio
> regression that may be similar to what you are experiencing but has not
> been picked up yet.
Andrew, is this in your queue, or should I take this directly, or
what? It seems to fix the problem for Eric and Sage, at least.
Linus
^ permalink raw reply
* Re: 3.5.1 fib_rules_lookup oops
From: Eric Dumazet @ 2012-08-20 16:59 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev, Fedora Kernel Team
In-Reply-To: <20120820164428.GA27910@redhat.com>
On Mon, 2012-08-20 at 12:44 -0400, Dave Jones wrote:
> Just had a user report this, which I don't think I've seen reported here yet.
> Something new, or just something missing from -stable ?
>
> Dave
>
>
> BUG: unable to handle kernel paging request at 5f726571
> IP: [<c0884808>] fib_rules_lookup+0x38/0x130
> *pdpt = 000000002b8ef001 *pde = 0000000000000000
> Oops: 0000 [#1] SMP
> Modules linked in: fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge stp llc ip6t_REJECT nf_conntrack_ipv4 nf_conntrack_ipv6 nf_defrag_ipv4 nf_defrag_ipv6 xt_state ip6table_filter be2iscsi nf_conntrack iscsi_boot_sysfs ip6_tables bnx2i cnic uio cxgb4i it87 hwmon_vid cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi tpm_bios snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc vhost_net ppdev tun macvtap macvlan snd_timer parport_pc kvm_amd k8temp snd kvm forcedeth soundcore nv_tco parport i2c_nforce2 nfsd nfs_acl auth_rpcgss lockd uinput binfmt_misc sunrpc btrfs libcrc32c zlib_deflate firewire_ohci firewire_core ata_generic
pata_acpi crc_itu_t sata_nv pata_amd nouveau mxm_wmi wmi video i2c_algo_bit drm_kms_helper ttm drm i2c_core [last unloaded: scsi_wait_scan]
>
> Pid: 1943, comm: transmission-gt Not tainted 3.5.1-1.fc17.i686.PAE #1 /M55S-S3
> EIP: 0060:[<c0884808>] EFLAGS: 00010a97 CPU: 0
> EIP is at fib_rules_lookup+0x38/0x130
> EAX: 5f726565 EBX: 5f726565 ECX: 00000000 EDX: c0b45a15
> ESI: eb2f1d38 EDI: c0b45a59 EBP: eb2f1c44 ESP: eb2f1c24
> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> CR0: 80050033 CR2: 5f726571 CR3: 33f3a000 CR4: 000007f0
> DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
> DR6: ffff0ff0 DR7: 00000400
> Process transmission-gt (pid: 1943, ti=eb2f0000 task=f48bf110 task.ti=eb2f0000)
> Stack:
> eb2f1c3c c0b45a59 00000000 c0b45a15 5f726565 eb2f1c90 eb2f1d38 c0be60c0
> eb2f1c64 c08dacc9 eb2f1c50 00000000 eb2f1c90 00000000 00000001 00000000
> eb2f1cb0 c089a2bc f75bc8c8 00000001 eb2f1c84 c066dd4f b4298b0e 00000001
> Call Trace:
> [<c08dacc9>] fib_lookup+0x39/0x50
> [<c089a2bc>] __ip_route_output_key+0x5cc/0x8b0
> [<c066dd4f>] ? cpumask_next_and+0x1f/0x40
> [<c089a5bf>] ip_route_output_flow+0x1f/0x70
> [<c08c49bd>] udp_sendmsg+0x73d/0x8d0
> [<c08a0010>] ? ip_copy_metadata+0x140/0x140
> [<c08cd126>] inet_sendmsg+0x66/0xa0
> [<c0622d1f>] ? selinux_socket_sendmsg+0x1f/0x30
> [<c085c230>] sock_sendmsg+0xc0/0xf0
> [<c0410e71>] ? __switch_to+0xc1/0x270
> [<c047fce2>] ? idle_balance+0x102/0x150
> [<c0679dd1>] ? _copy_from_user+0x41/0x60
> [<c085c5a3>] ? move_addr_to_kernel+0x43/0x90
> [<c085cf0d>] sys_sendto+0xfd/0x140
> [<c046aa70>] ? update_rmtp+0x90/0x90
> [<c046b956>] ? hrtimer_start_range_ns+0x26/0x30
> [<c0589afb>] ? sys_epoll_wait+0x6b/0x370
> [<c085d921>] sys_socketcall+0x1d1/0x2d0
> [<c09672df>] sysenter_do_call+0x12/0x28
> Code: 00 89 45 ec 89 d6 89 c2 8b 40 44 89 d7 83 c7 44 89 4d e8 89 45 f0 8b 5d f0 39 fb 0f 84 a3 00 00 00 89 7d e4 8d b4 26 00 00 00 00 <8b> 53 0c 85 d2 74 31 31 c0 3b 56 04 74 2a f6 43 20 02 74 08 85
> EIP: [<c0884808>] fib_rules_lookup+0x38/0x130 SS:ESP 0068:eb2f1c24
> --
It looks like a buffer overflow or memory reuse
5f726565 is not a valid pointer, but ASCII "eer_"
^ permalink raw reply
* Re: regression with poll(2)
From: Sage Weil @ 2012-08-20 16:54 UTC (permalink / raw)
To: Mel Gorman
Cc: davem, netdev, linux-kernel, ceph-devel, neilb, a.p.zijlstra,
michaelc, emunson, eric.dumazet, sebastian, cl, akpm, torvalds
In-Reply-To: <20120820090443.GA3275@suse.de>
On Mon, 20 Aug 2012, Mel Gorman wrote:
> On Sun, Aug 19, 2012 at 11:49:31AM -0700, Sage Weil wrote:
> > I've bisected and identified this commit:
> >
> > netvm: propagate page->pfmemalloc to skb
> >
> > The skb->pfmemalloc flag gets set to true iff during the slab allocation
> > of data in __alloc_skb that the the PFMEMALLOC reserves were used. If the
> > packet is fragmented, it is possible that pages will be allocated from the
> > PFMEMALLOC reserve without propagating this information to the skb. This
> > patch propagates page->pfmemalloc from pages allocated for fragments to
> > the skb.
> >
> > Signed-off-by: Mel Gorman <mgorman@suse.de>
> > Acked-by: David S. Miller <davem@davemloft.net>
> > Cc: Neil Brown <neilb@suse.de>
> > Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Cc: Mike Christie <michaelc@cs.wisc.edu>
> > Cc: Eric B Munson <emunson@mgebm.net>
> > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> > Cc: Mel Gorman <mgorman@suse.de>
> > Cc: Christoph Lameter <cl@linux.com>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> >
>
> Ok, thanks.
>
> > I've retested several times and confirmed that this change leads to the
> > breakage, and also confirmed that reverting it on top of -rc1 also fixes
> > the problem.
> >
> > I've also added some additional instrumentation to my code and confirmed
> > that the process is blocking on poll(2) while netstat is reporting
> > data available on the socket.
> >
> > What can I do to help track this down?
> >
>
> Can the following patch be tested please? It is reported to fix an fio
> regression that may be similar to what you are experiencing but has not
> been picked up yet.
This patch appears to resolve things for me as well, at least after a
couple of passes. I'll let you know if I see any further problems come up
with more testing.
Thanks!
sage
>
> ---8<---
> From: Alex Shi <alex.shi@intel.com>
> Subject: [PATCH] mm: correct page->pfmemalloc to fix deactivate_slab regression
>
> commit cfd19c5a9ec (mm: only set page->pfmemalloc when
> ALLOC_NO_WATERMARKS was used) try to narrow down page->pfmemalloc
> setting, but it missed some places the pfmemalloc should be set.
>
> So, in __slab_alloc, the unalignment pfmemalloc and ALLOC_NO_WATERMARKS
> cause incorrect deactivate_slab() on our core2 server:
>
> 64.73% fio [kernel.kallsyms] [k] _raw_spin_lock
> |
> --- _raw_spin_lock
> |
> |---0.34%-- deactivate_slab
> | __slab_alloc
> | kmem_cache_alloc
> | |
>
> That causes our fio sync write performance has 40% regression.
>
> This patch move the checking in get_page_from_freelist, that resolved
> this issue.
>
> Signed-off-by: Alex Shi <alex.shi@intel.com>
> ---
> mm/page_alloc.c | 21 +++++++++++----------
> 1 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 009ac28..07f1924 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1928,6 +1928,17 @@ this_zone_full:
> zlc_active = 0;
> goto zonelist_scan;
> }
> +
> + if (page)
> + /*
> + * page->pfmemalloc is set when ALLOC_NO_WATERMARKS was
> + * necessary to allocate the page. The expectation is
> + * that the caller is taking steps that will free more
> + * memory. The caller should avoid the page being used
> + * for !PFMEMALLOC purposes.
> + */
> + page->pfmemalloc = !!(alloc_flags & ALLOC_NO_WATERMARKS);
> +
> return page;
> }
>
> @@ -2389,14 +2400,6 @@ rebalance:
> zonelist, high_zoneidx, nodemask,
> preferred_zone, migratetype);
> if (page) {
> - /*
> - * page->pfmemalloc is set when ALLOC_NO_WATERMARKS was
> - * necessary to allocate the page. The expectation is
> - * that the caller is taking steps that will free more
> - * memory. The caller should avoid the page being used
> - * for !PFMEMALLOC purposes.
> - */
> - page->pfmemalloc = true;
> goto got_pg;
> }
> }
> @@ -2569,8 +2572,6 @@ retry_cpuset:
> page = __alloc_pages_slowpath(gfp_mask, order,
> zonelist, high_zoneidx, nodemask,
> preferred_zone, migratetype);
> - else
> - page->pfmemalloc = false;
>
> trace_mm_page_alloc(page, order, gfp_mask, migratetype);
>
> --
> 1.7.5.4
>
>
^ permalink raw reply
* 3.5.1 fib_rules_lookup oops
From: Dave Jones @ 2012-08-20 16:44 UTC (permalink / raw)
To: netdev; +Cc: Fedora Kernel Team
Just had a user report this, which I don't think I've seen reported here yet.
Something new, or just something missing from -stable ?
Dave
BUG: unable to handle kernel paging request at 5f726571
IP: [<c0884808>] fib_rules_lookup+0x38/0x130
*pdpt = 000000002b8ef001 *pde = 0000000000000000
Oops: 0000 [#1] SMP
Modules linked in: fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge stp llc ip6t_REJECT nf_conntrack_ipv4 nf_conntrack_ipv6 nf_defrag_ipv4 nf_defrag_ipv6 xt_state ip6table_filter be2iscsi nf_conntrack iscsi_boot_sysfs ip6_tables bnx2i cnic uio cxgb4i it87 hwmon_vid cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi tpm_bios snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc vhost_net ppdev tun macvtap macvlan snd_timer parport_pc kvm_amd k8temp snd kvm forcedeth soundcore nv_tco parport i2c_nforce2 nfsd nfs_acl auth_rpcgss lockd uinput binfmt_misc sunrpc btrfs libcrc32c zlib_deflate firewire_ohci firewire_core ata_generic p
ata_acpi crc_itu_t sata_nv pata_amd nouveau mxm_wmi wmi video i2c_algo_bit drm_kms_helper ttm drm i2c_core [last unloaded: scsi_wait_scan]
Pid: 1943, comm: transmission-gt Not tainted 3.5.1-1.fc17.i686.PAE #1 /M55S-S3
EIP: 0060:[<c0884808>] EFLAGS: 00010a97 CPU: 0
EIP is at fib_rules_lookup+0x38/0x130
EAX: 5f726565 EBX: 5f726565 ECX: 00000000 EDX: c0b45a15
ESI: eb2f1d38 EDI: c0b45a59 EBP: eb2f1c44 ESP: eb2f1c24
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 80050033 CR2: 5f726571 CR3: 33f3a000 CR4: 000007f0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process transmission-gt (pid: 1943, ti=eb2f0000 task=f48bf110 task.ti=eb2f0000)
Stack:
eb2f1c3c c0b45a59 00000000 c0b45a15 5f726565 eb2f1c90 eb2f1d38 c0be60c0
eb2f1c64 c08dacc9 eb2f1c50 00000000 eb2f1c90 00000000 00000001 00000000
eb2f1cb0 c089a2bc f75bc8c8 00000001 eb2f1c84 c066dd4f b4298b0e 00000001
Call Trace:
[<c08dacc9>] fib_lookup+0x39/0x50
[<c089a2bc>] __ip_route_output_key+0x5cc/0x8b0
[<c066dd4f>] ? cpumask_next_and+0x1f/0x40
[<c089a5bf>] ip_route_output_flow+0x1f/0x70
[<c08c49bd>] udp_sendmsg+0x73d/0x8d0
[<c08a0010>] ? ip_copy_metadata+0x140/0x140
[<c08cd126>] inet_sendmsg+0x66/0xa0
[<c0622d1f>] ? selinux_socket_sendmsg+0x1f/0x30
[<c085c230>] sock_sendmsg+0xc0/0xf0
[<c0410e71>] ? __switch_to+0xc1/0x270
[<c047fce2>] ? idle_balance+0x102/0x150
[<c0679dd1>] ? _copy_from_user+0x41/0x60
[<c085c5a3>] ? move_addr_to_kernel+0x43/0x90
[<c085cf0d>] sys_sendto+0xfd/0x140
[<c046aa70>] ? update_rmtp+0x90/0x90
[<c046b956>] ? hrtimer_start_range_ns+0x26/0x30
[<c0589afb>] ? sys_epoll_wait+0x6b/0x370
[<c085d921>] sys_socketcall+0x1d1/0x2d0
[<c09672df>] sysenter_do_call+0x12/0x28
Code: 00 89 45 ec 89 d6 89 c2 8b 40 44 89 d7 83 c7 44 89 4d e8 89 45 f0 8b 5d f0 39 fb 0f 84 a3 00 00 00 89 7d e4 8d b4 26 00 00 00 00 <8b> 53 0c 85 d2 74 31 31 c0 3b 56 04 74 2a f6 43 20 02 74 08 85
EIP: [<c0884808>] fib_rules_lookup+0x38/0x130 SS:ESP 0068:eb2f1c24
^ 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