* Re: [PATCH net-2.6 0/4] bnx2x fixes
From: David Miller @ 2011-03-07 2:12 UTC (permalink / raw)
To: dmitry; +Cc: netdev, eilong
In-Reply-To: <1299444887.13442.11.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Sun, 6 Mar 2011 22:54:47 +0200
> Please consider applying these, Multi-function related, fixes to
> net-2.6.
All applied, thanks Dmitry.
^ permalink raw reply
* Re: [Patch] ariadne: fix possible null dereference
From: David Miller @ 2011-03-07 2:07 UTC (permalink / raw)
To: geert; +Cc: rdunlap, j223yang, netdev, linux-kernel
In-Reply-To: <AANLkTiko+HzYMnGEtvb63Fzi2eNge6_iWPmk7EfjFma7@mail.gmail.com>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Sun, 6 Mar 2011 21:00:13 +0100
> On Sun, Mar 6, 2011 at 20:11, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> On Sun, 6 Mar 2011 02:08:32 -0500 j223yang@asset.uwaterloo.ca wrote:
>>
>>> Hi Randy,
>>> I have tested my patch, and it is ok now.
>>> Could you please try patching again? Sorry for previous trouble.
>>> Thank you!
>>
>> Acked-by: Randy Dunlap <rdunlap@xenotime.net>
>
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
People really don't actually read patches, I think.
Show me how dev can even be NULL here, it simply can't.
So the correct fix is to remove the dev==NULL check altogether.
^ permalink raw reply
* Re: [PATCH] vhost: copy_from_user -> __copy_from_user
From: David Miller @ 2011-03-07 2:03 UTC (permalink / raw)
To: mst; +Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20110306113349.GA24333@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 6 Mar 2011 13:33:49 +0200
> copy_from_user is pretty high on perf top profile,
> replacing it with __copy_from_user helps.
> It's also safe because we do access_ok checks during setup.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Is Rusty going to take this or should I?
^ permalink raw reply
* Re: [PATCH 1/2] Issue NETDEV_CHANGE notification when bridge changes state
From: Adam Majer @ 2011-03-07 0:25 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, bridge, netdev
In-Reply-To: <20110306094541.53390b55@nehalam>
On Sun, Mar 06, 2011 at 09:45:41AM -0800, Stephen Hemminger wrote:
> Since this a generic problem, it needs a better solution.
> Sending NETDEV_CHANGE impacts lots of other pieces, and even
> user space has similar problems.
It does seem a little broad notification type. I've checked over
all the currently defined NETDEV notifiers, and it seems that
NETDEV_NOTIFY_PEERS may be a better option to use when bridge
has a potential topology change.
Currently it is only used in ipv4/devinet.c: where it is used to issue
a gratuitous ARP.
--
Adam Majer
adamm@zombino.com
^ permalink raw reply
* [PATCH net-2.6 0/4] bnx2x fixes
From: Dmitry Kravkov @ 2011-03-06 20:54 UTC (permalink / raw)
To: davem, netdev; +Cc: Eilon Greenstein
Hello Dave,
Please consider applying these, Multi-function related, fixes to
net-2.6.
Thank you,
Dmitry
^ permalink raw reply
* [PATCH net-2.6 4/4] bnx2x: fix MaxBW configuration
From: Dmitry Kravkov @ 2011-03-06 20:51 UTC (permalink / raw)
To: davem, netdev; +Cc: Eilon Greenstein
Increase resolution of MaxBW algorithm to suit
Min Bandwidth configuration.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 2ac4e3c..8849699 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -1617,8 +1617,8 @@ static inline u32 reg_poll(struct bnx2x *bp, u32 reg, u32 expected, int ms,
/* CMNG constants, as derived from system spec calculations */
/* default MIN rate in case VNIC min rate is configured to zero - 100Mbps */
#define DEF_MIN_RATE 100
-/* resolution of the rate shaping timer - 100 usec */
-#define RS_PERIODIC_TIMEOUT_USEC 100
+/* resolution of the rate shaping timer - 400 usec */
+#define RS_PERIODIC_TIMEOUT_USEC 400
/* number of bytes in single QM arbitration cycle -
* coefficient for calculating the fairness timer */
#define QM_ARB_BYTES 160000
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-2.6 3/4] bnx2x: (NPAR) prevent HW access in D3 state
From: Dmitry Kravkov @ 2011-03-06 20:50 UTC (permalink / raw)
To: davem, netdev; +Cc: Eilon Greenstein
Changing speed setting in NPAR requires HW access, this patch
delays the access to D0 state when performed in D3.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x.h | 1 +
drivers/net/bnx2x/bnx2x_cmn.c | 22 ++++++++++++++++++++++
drivers/net/bnx2x/bnx2x_cmn.h | 9 +++++++++
drivers/net/bnx2x/bnx2x_ethtool.c | 18 ++++++++----------
4 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 7897d11..2ac4e3c 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -1211,6 +1211,7 @@ struct bnx2x {
/* DCBX Negotation results */
struct dcbx_features dcbx_local_feat;
u32 dcbx_error;
+ u32 pending_max;
};
/**
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index 9379812..a71b329 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -996,6 +996,23 @@ void bnx2x_free_skbs(struct bnx2x *bp)
bnx2x_free_rx_skbs(bp);
}
+void bnx2x_update_max_mf_config(struct bnx2x *bp, u32 value)
+{
+ /* load old values */
+ u32 mf_cfg = bp->mf_config[BP_VN(bp)];
+
+ if (value != bnx2x_extract_max_cfg(bp, mf_cfg)) {
+ /* leave all but MAX value */
+ mf_cfg &= ~FUNC_MF_CFG_MAX_BW_MASK;
+
+ /* set new MAX value */
+ mf_cfg |= (value << FUNC_MF_CFG_MAX_BW_SHIFT)
+ & FUNC_MF_CFG_MAX_BW_MASK;
+
+ bnx2x_fw_command(bp, DRV_MSG_CODE_SET_MF_BW, mf_cfg);
+ }
+}
+
static void bnx2x_free_msix_irqs(struct bnx2x *bp)
{
int i, offset = 1;
@@ -1464,6 +1481,11 @@ int bnx2x_nic_load(struct bnx2x *bp, int load_mode)
bnx2x_set_eth_mac(bp, 1);
+ if (bp->pending_max) {
+ bnx2x_update_max_mf_config(bp, bp->pending_max);
+ bp->pending_max = 0;
+ }
+
if (bp->port.pmf)
bnx2x_initial_phy_init(bp, load_mode);
diff --git a/drivers/net/bnx2x/bnx2x_cmn.h b/drivers/net/bnx2x/bnx2x_cmn.h
index 326ba44..85ea7f2 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/bnx2x/bnx2x_cmn.h
@@ -341,6 +341,15 @@ void bnx2x_dcbx_init(struct bnx2x *bp);
*/
int bnx2x_set_power_state(struct bnx2x *bp, pci_power_t state);
+/**
+ * Updates MAX part of MF configuration in HW
+ * (if required)
+ *
+ * @param bp
+ * @param value
+ */
+void bnx2x_update_max_mf_config(struct bnx2x *bp, u32 value);
+
/* dev_close main block */
int bnx2x_nic_unload(struct bnx2x *bp, int unload_mode);
diff --git a/drivers/net/bnx2x/bnx2x_ethtool.c b/drivers/net/bnx2x/bnx2x_ethtool.c
index ef29199..7e92f9d 100644
--- a/drivers/net/bnx2x/bnx2x_ethtool.c
+++ b/drivers/net/bnx2x/bnx2x_ethtool.c
@@ -238,7 +238,7 @@ static int bnx2x_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
speed |= (cmd->speed_hi << 16);
if (IS_MF_SI(bp)) {
- u32 param = 0, part;
+ u32 part;
u32 line_speed = bp->link_vars.line_speed;
/* use 10G if no link detected */
@@ -251,24 +251,22 @@ static int bnx2x_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
REQ_BC_VER_4_SET_MF_BW);
return -EINVAL;
}
+
part = (speed * 100) / line_speed;
+
if (line_speed < speed || !part) {
BNX2X_DEV_INFO("Speed setting should be in a range "
"from 1%% to 100%% "
"of actual line speed\n");
return -EINVAL;
}
- /* load old values */
- param = bp->mf_config[BP_VN(bp)];
- /* leave only MIN value */
- param &= FUNC_MF_CFG_MIN_BW_MASK;
-
- /* set new MAX value */
- param |= (part << FUNC_MF_CFG_MAX_BW_SHIFT)
- & FUNC_MF_CFG_MAX_BW_MASK;
+ if (bp->state != BNX2X_STATE_OPEN)
+ /* store value for following "load" */
+ bp->pending_max = part;
+ else
+ bnx2x_update_max_mf_config(bp, part);
- bnx2x_fw_command(bp, DRV_MSG_CODE_SET_MF_BW, param);
return 0;
}
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-2.6 1/4] bnx2x: fix non-pmf device load flow
From: Dmitry Kravkov @ 2011-03-06 20:49 UTC (permalink / raw)
To: davem, netdev; +Cc: Eilon Greenstein
Remove port MAX BW configuration from non-pmf functions,
which caused reconfigure of HW according to 10G (fake) link.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 032ae18..469ca60 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -2092,8 +2092,9 @@ static void bnx2x_cmng_fns_init(struct bnx2x *bp, u8 read_cfg, u8 cmng_type)
bnx2x_calc_vn_weight_sum(bp);
/* calculate and set min-max rate for each vn */
- for (vn = VN_0; vn < E1HVN_MAX; vn++)
- bnx2x_init_vn_minmax(bp, vn);
+ if (bp->port.pmf)
+ for (vn = VN_0; vn < E1HVN_MAX; vn++)
+ bnx2x_init_vn_minmax(bp, vn);
/* always enable rate shaping and fairness */
bp->cmng.flags.cmng_enables |=
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-2.6 2/4] bnx2x: fix link notification
From: Dmitry Kravkov @ 2011-03-06 20:49 UTC (permalink / raw)
To: davem, netdev; +Cc: Eilon Greenstein
Report link to OS and other PFs after HW is fully reconfigured
according to new link parameters. (Affected only Multi Function modes).
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_main.c | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
index 469ca60..aa03233 100644
--- a/drivers/net/bnx2x/bnx2x_main.c
+++ b/drivers/net/bnx2x/bnx2x_main.c
@@ -2163,13 +2163,6 @@ static void bnx2x_link_attn(struct bnx2x *bp)
bnx2x_stats_handle(bp, STATS_EVENT_LINK_UP);
}
- /* indicate link status only if link status actually changed */
- if (prev_link_status != bp->link_vars.link_status)
- bnx2x_link_report(bp);
-
- if (IS_MF(bp))
- bnx2x_link_sync_notify(bp);
-
if (bp->link_vars.link_up && bp->link_vars.line_speed) {
int cmng_fns = bnx2x_get_cmng_fns_mode(bp);
@@ -2181,6 +2174,13 @@ static void bnx2x_link_attn(struct bnx2x *bp)
DP(NETIF_MSG_IFUP,
"single function mode without fairness\n");
}
+
+ if (IS_MF(bp))
+ bnx2x_link_sync_notify(bp);
+
+ /* indicate link status only if link status actually changed */
+ if (prev_link_status != bp->link_vars.link_status)
+ bnx2x_link_report(bp);
}
void bnx2x__link_status_update(struct bnx2x *bp)
--
1.7.2.2
^ permalink raw reply related
* [PATCH net-next-2.6] net: enhance the documentation for rx_handler.
From: Nicolas de Pesloüan @ 2011-03-06 20:00 UTC (permalink / raw)
To: netdev
Cc: davem, shemminger, eric.dumazet, kaber, fubar, andy,
Nicolas de Pesloüan
In-Reply-To: <4D725BD9.6000706@gmail.com>
Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
---
This apply on top of Jiri's last patch serie, including the last one that
commented the RX_HANDLER_* values.
include/linux/netdevice.h | 53 ++++++++++++++++++++++++++++++++++++++------
net/core/dev.c | 2 +
2 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 26e03f9..0c9dc93 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -390,15 +390,52 @@ enum gro_result {
};
typedef enum gro_result gro_result_t;
+/**
+ * enum rx_handler_result - Possible return values for rx_handlers.
+ * @RX_HANDLER_CONSUMED: skb was consumed by rx_handler, do not process it
+ * further.
+ * @RX_HANDLER_ANOTHER: Do another round in receive path. This is indicated in
+ * case skb->dev was changed by rx_handler.
+ * @RX_HANDLER_EXACT: Force exact delivery, no wildcard.
+ * @RX_HANDLER_PASS: Do nothing, passe the skb as if no rx_handler was called.
+ *
+ * rx_handlers are functions called from inside __netif_receive_skb(), to do
+ * special processing of the skb, prior to delivery to protocol handlers.
+ *
+ * Currently, a net_device can only have a single rx_handler registered. Trying
+ * to register a second rx_handler will return -EBUSY.
+ *
+ * To register a rx_handler on a net_device, use netdev_rx_handler_register().
+ * To unregister a rx_handler on a net_device, use
+ * netdev_rx_handler_unregister().
+ *
+ * Upon return, rx_handler is expected to tell __netif_receive_skb() what to
+ * do with the skb.
+ *
+ * If the rx_handler consumed to skb in some way, it should return
+ * RX_HANDLER_CONSUMED. This is appropriate when the rx_handler arranged for
+ * the skb to be delivered in some other ways.
+ *
+ * If the rx_handler changed skb->dev, to divert the skb to another
+ * net_device, it should return RX_HANDLER_ANOTHER. The rx_handler for the
+ * new device will be called if it exists.
+ *
+ * If the rx_handler consider the skb should be ignored, it should return
+ * RX_HANDLER_EXACT. The skb will only be delivered to protocol handlers that
+ * are registred on exact device (ptype->dev == skb->dev).
+ *
+ * If the rx_handler didn't changed skb->dev, but want the skb to be normally
+ * delivered, it should return RX_HANDLER_PASS.
+ *
+ * A device without a registered rx_handler will behave as if rx_handler
+ * returned RX_HANDLER_PASS.
+ */
+
enum rx_handler_result {
- RX_HANDLER_CONSUMED, /* skb was consumed by rx_handler,
- do not process it further. */
- RX_HANDLER_ANOTHER, /* Do another round in receive path.
- This is indicated in case skb->dev
- was changed by rx_handler */
- RX_HANDLER_EXACT, /* Force exact delivery, no wildcard */
- RX_HANDLER_PASS, /* Do nothing, pass the skb as if
- no rx_handler was called */
+ RX_HANDLER_CONSUMED,
+ RX_HANDLER_ANOTHER,
+ RX_HANDLER_EXACT,
+ RX_HANDLER_PASS,
};
typedef enum rx_handler_result rx_handler_result_t;
typedef rx_handler_result_t rx_handler_func_t(struct sk_buff **pskb);
diff --git a/net/core/dev.c b/net/core/dev.c
index a368223..3630722 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3060,6 +3060,8 @@ out:
* on a failure.
*
* The caller must hold the rtnl_mutex.
+ *
+ * For a general description of rx_handler, see enum rx_handler_result.
*/
int netdev_rx_handler_register(struct net_device *dev,
rx_handler_func_t *rx_handler,
--
1.7.2.3
^ permalink raw reply related
* Re: [Patch] ariadne: fix possible null dereference
From: Geert Uytterhoeven @ 2011-03-06 20:00 UTC (permalink / raw)
To: Randy Dunlap; +Cc: j223yang, netdev, linux-kernel
In-Reply-To: <20110306111141.9cc51306.rdunlap@xenotime.net>
On Sun, Mar 6, 2011 at 20:11, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On Sun, 6 Mar 2011 02:08:32 -0500 j223yang@asset.uwaterloo.ca wrote:
>
>> Hi Randy,
>> I have tested my patch, and it is ok now.
>> Could you please try patching again? Sorry for previous trouble.
>> Thank you!
>
> Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
>> ------------------------------------------------------
>> This patch fixes bugzilla #13853:
>> https://bugzilla.kernel.org/show_bug.cgi?id=13853
>>
>> The patch removes dereference of 'dev' after testing for NULL.
>>
>> Signed-off-by: Jinqiu Yang<crindy646@gmail.com>
>> ---
>> ariadne.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ariadne.c b/drivers/net/ariadne.c
>> --- a/drivers/net/ariadne.c 2011-03-04 11:16:42.332164362 -0500
>> +++ b/drivers/net/ariadne.c 2011-03-05 21:11:52.949164759 -0500
>> @@ -420,7 +420,7 @@ static inline void ariadne_reset(struct
>> static irqreturn_t ariadne_interrupt(int irq, void *data)
>> {
>> struct net_device *dev = (struct net_device *)data;
>> - volatile struct Am79C960 *lance = (struct Am79C960*)dev->base_addr;
>> + volatile struct Am79C960 *lance;
>> struct ariadne_private *priv;
>> int csr0, boguscnt;
>> int handled = 0;
>> @@ -430,6 +430,7 @@ static irqreturn_t ariadne_interrupt(int
>> return IRQ_NONE;
>> }
>>
>> + lance = (struct Am79C960 *)dev->base_addr;
>> lance->RAP = CSR0; /* PCnet-ISA Controller Status */
>>
>> if (!(lance->RDP & INTR)) /* Check if any interrupt has been */
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3] tcp: ioctl type SIOCOUTQNSD returns amount of data not sent
From: Steffen Sledz @ 2011-03-06 19:59 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Alan Cox, David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI, Patrick McHardy,
Mario Schuknecht, Steffen Sledz
In-Reply-To: <20110304123950.2c91ebd9@lxorguk.ukuu.org.uk>
From: Mario Schuknecht <m.schuknecht@dresearch.de>
In contrast to SIOCOUTQ which returns the amount of data sent
but not yet acknowledged plus data not yet sent this patch only
returns the data not sent.
For various methods of live streaming bitrate control it may
be helpful to know how much data are in the tcp outqueue are
not sent yet.
Signed-off-by: Mario Schuknecht <m.schuknecht@dresearch.de>
Signed-off-by: Steffen Sledz <sledz@dresearch.de>
---
include/linux/sockios.h | 4 +++-
net/ipv4/tcp.c | 9 +++++++++
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/include/linux/sockios.h b/include/linux/sockios.h
index 241f179..7997a50 100644
--- a/include/linux/sockios.h
+++ b/include/linux/sockios.h
@@ -22,7 +22,7 @@
/* Linux-specific socket ioctls */
#define SIOCINQ FIONREAD
-#define SIOCOUTQ TIOCOUTQ
+#define SIOCOUTQ TIOCOUTQ /* output queue size (not sent + not acked) */
/* Routing table calls. */
#define SIOCADDRT 0x890B /* add routing table entry */
@@ -83,6 +83,8 @@
#define SIOCWANDEV 0x894A /* get/set netdev parameters */
+#define SIOCOUTQNSD 0x894B /* output queue size (not sent only) */
+
/* ARP cache control calls. */
/* 0x8950 - 0x8952 * obsolete calls, don't re-use */
#define SIOCDARP 0x8953 /* delete ARP table entry */
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index a17a5a7..b22d450 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -505,6 +505,15 @@ int tcp_ioctl(struct sock *sk, int cmd, unsigned long arg)
else
answ = tp->write_seq - tp->snd_una;
break;
+ case SIOCOUTQNSD:
+ if (sk->sk_state == TCP_LISTEN)
+ return -EINVAL;
+
+ if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV))
+ answ = 0;
+ else
+ answ = tp->write_seq - tp->snd_nxt;
+ break;
default:
return -ENOIOCTLCMD;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 2/4] slub,rcu: don't assume the size of struct rcu_head
From: Hugh Dickins @ 2011-03-06 19:39 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Lai Jiangshan, Ingo Molnar, Paul E. McKenney,
Eric Dumazet, David S. Miller, Matt Mackall, linux-mm,
linux-kernel, netdev
In-Reply-To: <alpine.DEB.2.00.1103020625290.10180@router.home>
On Wed, Mar 2, 2011 at 4:32 AM, Christoph Lameter <cl@linux.com> wrote:
> On Tue, 1 Mar 2011, Hugh Dickins wrote:
>
>> > Struct page may be larger for debugging purposes already because of the
>> > need for extended spinlock data.
>>
>> That was so for a long time, but I stopped it just over a year ago
>> with commit a70caa8ba48f21f46d3b4e71b6b8d14080bbd57a, stop ptlock
>> enlarging struct page.
>
> Strange. I just played around with in in January and the page struct size
> changes when I build kernels with full debugging. I have some
> cmpxchg_double patches here that depend on certain alignment in the page
> struct. Debugging causes all that stuff to get out of whack so that I had
> to do some special patches to make sure fields following the spinlock are
> properly aligned when the sizes change.
That puzzles me, it's not my experience and I don't have an
explanation: do you have time to investigate?
Uh oh, you're going to tell me you're working on an out-of-tree
architecture with a million cpus ;) In that case, yes, I'm afraid
I'll have to update the SPLIT_PTLOCK_CPUS defaulting (for a million -
1 even).
>
>> If a union leads to "random junk" overwriting the page->mapping field
>> when the page is reused, and that junk could resemble the pointer in
>> question, then KSM would mistakenly think it still owned the page.
>> Very remote chance, and maybe it amounts to no more than a leak. But
>> I'd still prefer we keep page->mapping for pointers (sometimes with
>> lower bits set as flags).
>
> DESTROY BY RCU uses the lru field which follows the mapping field in page
> struct. Why would random junk overwrite the mapping field?
Random junk does not overwrite the mapping field with the current
implementation of DESTROY_BY_RCU. But you and Jiangshan were
discussing how to change it, so I was warning of this issue with
page->mapping.
But I would anyway agree with Jiangshan, that it's preferable not to
bloat struct page size just for this DESTROY_BY_RCU issue, even if it
is only an issue when debugging.
Hugh
^ permalink raw reply
* Re: [Patch] ariadne: fix possible null dereference
From: Randy Dunlap @ 2011-03-06 19:11 UTC (permalink / raw)
To: j223yang; +Cc: netdev, linux-kernel
In-Reply-To: <20110306070832.GA26188@asset.uwaterloo.ca>
On Sun, 6 Mar 2011 02:08:32 -0500 j223yang@asset.uwaterloo.ca wrote:
> Hi Randy,
> I have tested my patch, and it is ok now.
> Could you please try patching again? Sorry for previous trouble.
> Thank you!
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Thanks.
> Jinqiu
> ------------------------------------------------------
> This patch fixes bugzilla #13853:
> https://bugzilla.kernel.org/show_bug.cgi?id=13853
>
> The patch removes dereference of 'dev' after testing for NULL.
>
> Signed-off-by: Jinqiu Yang<crindy646@gmail.com>
> ---
> ariadne.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ariadne.c b/drivers/net/ariadne.c
> --- a/drivers/net/ariadne.c 2011-03-04 11:16:42.332164362 -0500
> +++ b/drivers/net/ariadne.c 2011-03-05 21:11:52.949164759 -0500
> @@ -420,7 +420,7 @@ static inline void ariadne_reset(struct
> static irqreturn_t ariadne_interrupt(int irq, void *data)
> {
> struct net_device *dev = (struct net_device *)data;
> - volatile struct Am79C960 *lance = (struct Am79C960*)dev->base_addr;
> + volatile struct Am79C960 *lance;
> struct ariadne_private *priv;
> int csr0, boguscnt;
> int handled = 0;
> @@ -430,6 +430,7 @@ static irqreturn_t ariadne_interrupt(int
> return IRQ_NONE;
> }
>
> + lance = (struct Am79C960 *)dev->base_addr;
> lance->RAP = CSR0; /* PCnet-ISA Controller Status */
>
> if (!(lance->RDP & INTR)) /* Check if any interrupt has been */
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 1/2] Issue NETDEV_CHANGE notification when bridge changes state
From: Jan Ceuleers @ 2011-03-06 18:01 UTC (permalink / raw)
To: Adam Majer
Cc: Stephen Hemminger, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, bridge, netdev
In-Reply-To: <20110306080328.GA3850@mira.lan.galacticasoftware.com>
On 06/03/11 09:03, Adam Majer wrote:
> On Sat, Mar 05, 2011 at 10:43:03PM -0800, Stephen Hemminger wrote:
>> Why not set forwarding delay to zero? I don't think you are using STP?
>
> No, I'm not relying on STP. I think setting learning->forwarding delay
> to 0 could cause problems with STP like loops until the loop is
> detected.
I don't think that Stephen is saying that you should hard-code the
forwarding delay as zero (i.e. to remove the delay from the kernel
completely), but rather use brctl to set the forwarding delay to zero on
bridge instances in which you're not using STP.
HTH, Jan
^ permalink raw reply
* Re: [PATCH 1/2] Issue NETDEV_CHANGE notification when bridge changes state
From: Stephen Hemminger @ 2011-03-06 17:45 UTC (permalink / raw)
To: Adam Majer
Cc: Stephen Hemminger, David S. Miller, Alexey Kuznetsov,
Pekka Savola (ipv6), James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, bridge, netdev
In-Reply-To: <20110306080328.GA3850@mira.lan.galacticasoftware.com>
On Sun, 6 Mar 2011 02:03:28 -0600
Adam Majer <adamm@zombino.com> wrote:
> On Sat, Mar 05, 2011 at 10:43:03PM -0800, Stephen Hemminger wrote:
> > Why not set forwarding delay to zero? I don't think you are using STP?
> >
> > P.s: removing linux-kernel mailing list, since there is no point
> > in copying the whole world on this thread.
>
> I just sent patches where MAINTAINERS file told me to send it. ;)
>
> No, I'm not relying on STP. I think setting learning->forwarding delay
> to 0 could cause problems with STP like loops until the loop is
> detected.
>
> There may be a better spot where to insert the notification that the
> bridge is forwarding data, though I'm not exactly certain where. The
> patch will cause bridge to issue NETDEV_CHANGE notification for all
> topology changes. This may or may not be useful but shouldn't be
> harmful (I can't imagine these occur very often?) The IPv6 autoconf
> patch will only act on this if it doesn't have IPv6 address configured
> manually or via autoconf.
>
Since this a generic problem, it needs a better solution.
Sending NETDEV_CHANGE impacts lots of other pieces, and even
user space has similar problems.
--
^ permalink raw reply
* Re: [patch net-next-2.6 6/8] bonding: move processing of recv handlers into handle_frame()
From: Nicolas de Pesloüan @ 2011-03-06 17:37 UTC (permalink / raw)
To: Michał Mirosław
Cc: Jiri Pirko, netdev, davem, shemminger, kaber, fubar, eric.dumazet,
andy
In-Reply-To: <AANLkTi=Gt_ArqOVPJjnrAExO8Fihu8WzUhYSb_O6URQ_@mail.gmail.com>
Le 06/03/2011 17:32, Michał Mirosław a écrit :
[snip]
> Is there a particular reason why this ARP monitoring can't be done in
> userspace (e.g. on AF_PACKET with suitable filter)? Marking slaves
> up/down as their link goes in that direction is easy, but as more and
> more link-state detecting methods/algorithms get added this is
> becoming more of a mess.
Moving as much as possible of bonding into userspace is a long standing target.
I think we currently lack a good way to notify the bonding driver that a given slave is available or
not. Bringing the slave down on link failure is not appropriate, because it would prevent userspace
from receiving the ARP packets that would bring the slave up again upon link return.
The only thing we can do is writing into /sys/class/net/bond0/bonding/active_slave, to force the
active_slave. And this is strictly limited to active-backup mode.
I will let Jay / Andy comment on the general problem.
Nicolas.
^ permalink raw reply
* Re: [patch net-next-2.6 6/8] bonding: move processing of recv handlers into handle_frame()
From: Michał Mirosław @ 2011-03-06 16:32 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: Jiri Pirko, netdev, davem, shemminger, kaber, fubar, eric.dumazet,
andy
In-Reply-To: <4D739947.6040603@gmail.com>
2011/3/6 Nicolas de Pesloüan <nicolas.2p.debian@gmail.com>:
> Le 06/03/2011 14:34, Jiri Pirko a écrit :
>> Sun, Mar 06, 2011 at 01:24:32PM CET, nicolas.2p.debian@gmail.com wrote:
[...]
>>> That being said, the current vlan_on_bond_hook() hack already suffer
>>> other troubles and for example won't support the following setup:
>>>
>>> eth0 -> bond0 -> br0 -> br0.100.
>>
>> blah. Well correct me if my thinking is wrong but I cannot imagine
>> a scenario where there's not other way how to do arp monitoring than
>> over vlan.
>
> If you are connected to a switch smart enough to allow non tagged delivery
> for one vlan and all you arp_ip_targets are reachable through that vlan,
> then, yes, this hack might been useless...
>
> But...
>
> In real life, you may be connected to any kind of switch, including the most
> stupid one... or you may have trouble explaining to the network team the
> reason why you need all packets to be tagged expect for one vlan... or
> simply, some of your arp_ip_targets will be reachable through a router in
> another vlan.
>
>> So how about to just remove the vlan_on_bond_hook and forbid the
>> possibility. IMHO it should have never been introduced in the first
>> place.
>
> If it was never introduced, we would have been able to simply forbid it, but
> the feature exist since December 14th 2009, so I'm afraid we must keep it...
> :-/
>
> And as a more general rule, I think we should support "all possible"
> interface stacking setups, because this would force us to think generic,
> instead of adding special hacks for special stacking setups.
>
>>> I think we need to fix this stacking issue in a more general way.
>>
>> Well this issue is more or less out of the concept and breaks layering.
>> I cannot think of how to resolve this nicely atm.
>
> The only way I can imagine atm is something I described a few days ago:
>
> 1/ Add a late_delivery property to packet_type:
>
> struct packet_type {
> __be16 type; /* This is really
> htons(ether_type). */
> struct net_device *dev; /* NULL is wildcarded here
> */
> int (*func) (struct sk_buff *,
> struct net_device *,
> struct packet_type *);
> struct sk_buff *(*gso_segment)(struct sk_buff *skb,
> u32 features);
> int (*gso_send_check)(struct sk_buff
> *skb);
> struct sk_buff **(*gro_receive)(struct sk_buff
> **head,
> struct sk_buff *skb);
> int (*gro_complete)(struct sk_buff *skb);
> void *af_packet_priv;
> + bool late_delivery;
> struct list_head list;
> };
>
> 2/ Use the late_delivery property inside the ptype_all and ptype_base loops
> in __netif_receive_skb(), to skip the protocol handlers whose late_delivery
> property is false, while we walk the rx_handler path.
>
> 3/ At the end of __netif_receive_skb(), deliver the final skb to those
> ptype_all and ptype_base handlers whose late_delivery property is true.
>
> 4/ And revert back the bonding ARP monitoring to a normal protocol handler,
> having late_delivery == true.
>
> This would work with eth0 -> bond0 -> bond0.100 and eth0 -> bond0 -> br0 ->
> br0.100.
>
> This would also be reasonably generic, from my point of view. No reference
> to vlan, bonding, bridge or whatever...
Is there a particular reason why this ARP monitoring can't be done in
userspace (e.g. on AF_PACKET with suitable filter)? Marking slaves
up/down as their link goes in that direction is easy, but as more and
more link-state detecting methods/algorithms get added this is
becoming more of a mess.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [patch net-next-2.6 6/8] bonding: move processing of recv handlers into handle_frame()
From: Nicolas de Pesloüan @ 2011-03-06 14:25 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <20110306133413.GB2795@psychotron.redhat.com>
Le 06/03/2011 14:34, Jiri Pirko a écrit :
> Sun, Mar 06, 2011 at 01:24:32PM CET, nicolas.2p.debian@gmail.com wrote:
>> Le 05/03/2011 15:50, Nicolas de Pesloüan a écrit :
>>> Le 05/03/2011 15:43, Jiri Pirko a écrit :
>>>> Sat, Mar 05, 2011 at 03:33:30PM CET, nicolas.2p.debian@gmail.com wrote:
>>>>> Le 05/03/2011 11:29, Jiri Pirko a écrit :
>>>>>> Since now when bonding uses rx_handler, all traffic going into bond
>>>>>> device goes thru bond_handle_frame. So there's no need to go back into
>>>>>> bonding code later via ptype handlers. This patch converts
>>>>>> original ptype handlers into "bonding receive probes". These functions
>>>>>> are called from bond_handle_frame and they are registered per-mode.
>>>>>
>>>>> Does this still support having the arp_ip_target on a vlan?
>>>>>
>>>>> (eth0 -> bond0 -> bond0.100, with arp_ip_target only reachable
>>>>> through bond0.100).
>>>>
>>>> This case is still covered with vlan_on_bond_hook
>>>> eth0->
>>>> bond_handle_frame
>>>> bond0->
>>>> vlan_hwaccel_do_receive
>>>> bond0.5->
>>>> vlan_on_bond_hook -> reinject into bond0
>>>> -> bond_handle_frame (here it is processed)
>>>
>>> Sound good to me.
>>>
>>> Reviewed-by: Nicolas de Pesloüan<nicolas.2p.debian@free.fr>
>>
>> After another review, I think it won't work.
>>
>> vlan_on_bond() will reinject into bond0, but bond_handle_frame() is
>> registered as the rx_handler for the slaves (eth0 in the above
>> setup), not as the rx_handler for the master (bond0 in the above
>> setup). So, bond_handlee_frame() will never see the untagged ARP
>> request/reply and bonding ARP monitoring will fail.
>
> Damn, you are right. I mislooked.
So do I :-D
>> That being said, the current vlan_on_bond_hook() hack already suffer
>> other troubles and for example won't support the following setup:
>>
>> eth0 -> bond0 -> br0 -> br0.100.
>
> blah. Well correct me if my thinking is wrong but I cannot imagine
> a scenario where there's not other way how to do arp monitoring than
> over vlan.
If you are connected to a switch smart enough to allow non tagged delivery for one vlan and all you
arp_ip_targets are reachable through that vlan, then, yes, this hack might been useless...
But...
In real life, you may be connected to any kind of switch, including the most stupid one... or you
may have trouble explaining to the network team the reason why you need all packets to be tagged
expect for one vlan... or simply, some of your arp_ip_targets will be reachable through a router in
another vlan.
> So how about to just remove the vlan_on_bond_hook and forbid the
> possibility. IMHO it should have never been introduced in the first
> place.
If it was never introduced, we would have been able to simply forbid it, but the feature exist since
December 14th 2009, so I'm afraid we must keep it... :-/
And as a more general rule, I think we should support "all possible" interface stacking setups,
because this would force us to think generic, instead of adding special hacks for special stacking
setups.
>> I think we need to fix this stacking issue in a more general way.
>
> Well this issue is more or less out of the concept and breaks layering.
> I cannot think of how to resolve this nicely atm.
The only way I can imagine atm is something I described a few days ago:
1/ Add a late_delivery property to packet_type:
struct packet_type {
__be16 type; /* This is really htons(ether_type). */
struct net_device *dev; /* NULL is wildcarded here */
int (*func) (struct sk_buff *,
struct net_device *,
struct packet_type *);
struct sk_buff *(*gso_segment)(struct sk_buff *skb,
u32 features);
int (*gso_send_check)(struct sk_buff *skb);
struct sk_buff **(*gro_receive)(struct sk_buff **head,
struct sk_buff *skb);
int (*gro_complete)(struct sk_buff *skb);
void *af_packet_priv;
+ bool late_delivery;
struct list_head list;
};
2/ Use the late_delivery property inside the ptype_all and ptype_base loops in
__netif_receive_skb(), to skip the protocol handlers whose late_delivery property is false, while we
walk the rx_handler path.
3/ At the end of __netif_receive_skb(), deliver the final skb to those ptype_all and ptype_base
handlers whose late_delivery property is true.
4/ And revert back the bonding ARP monitoring to a normal protocol handler, having late_delivery ==
true.
This would work with eth0 -> bond0 -> bond0.100 and eth0 -> bond0 -> br0 -> br0.100.
This would also be reasonably generic, from my point of view. No reference to vlan, bonding, bridge
or whatever...
Nicolas.
^ permalink raw reply
* Re: [patch net-next-2.6 6/8] bonding: move processing of recv handlers into handle_frame()
From: Jiri Pirko @ 2011-03-06 13:34 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <4D737D00.20406@gmail.com>
Sun, Mar 06, 2011 at 01:24:32PM CET, nicolas.2p.debian@gmail.com wrote:
>Le 05/03/2011 15:50, Nicolas de Pesloüan a écrit :
>>Le 05/03/2011 15:43, Jiri Pirko a écrit :
>>>Sat, Mar 05, 2011 at 03:33:30PM CET, nicolas.2p.debian@gmail.com wrote:
>>>>Le 05/03/2011 11:29, Jiri Pirko a écrit :
>>>>>Since now when bonding uses rx_handler, all traffic going into bond
>>>>>device goes thru bond_handle_frame. So there's no need to go back into
>>>>>bonding code later via ptype handlers. This patch converts
>>>>>original ptype handlers into "bonding receive probes". These functions
>>>>>are called from bond_handle_frame and they are registered per-mode.
>>>>
>>>>Does this still support having the arp_ip_target on a vlan?
>>>>
>>>>(eth0 -> bond0 -> bond0.100, with arp_ip_target only reachable
>>>>through bond0.100).
>>>
>>>This case is still covered with vlan_on_bond_hook
>>>eth0->
>>>bond_handle_frame
>>>bond0->
>>>vlan_hwaccel_do_receive
>>>bond0.5->
>>>vlan_on_bond_hook -> reinject into bond0
>>>-> bond_handle_frame (here it is processed)
>>
>>Sound good to me.
>>
>>Reviewed-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
>
>After another review, I think it won't work.
>
>vlan_on_bond() will reinject into bond0, but bond_handle_frame() is
>registered as the rx_handler for the slaves (eth0 in the above
>setup), not as the rx_handler for the master (bond0 in the above
>setup). So, bond_handlee_frame() will never see the untagged ARP
>request/reply and bonding ARP monitoring will fail.
Damn, you are right. I mislooked.
>
>That being said, the current vlan_on_bond_hook() hack already suffer
>other troubles and for example won't support the following setup:
>
>eth0 -> bond0 -> br0 -> br0.100.
blah. Well correct me if my thinking is wrong but I cannot imagine
a scenario where there's not other way how to do arp monitoring than
over vlan.
So how about to just remove the vlan_on_bond_hook and forbid the
possibility. IMHO it should have never been introduced in the first
place.
>
>I think we need to fix this stacking issue in a more general way.
Well this issue is more or less out of the concept and breaks layering.
I cannot think of how to resolve this nicely atm.
>
> Nicolas.
^ permalink raw reply
* [PATCH net-next-2.6] net: harmonize the call to ptype_all and ptype_base handlers.
From: Nicolas de Pesloüan @ 2011-03-06 13:25 UTC (permalink / raw)
To: netdev
Cc: davem, shemminger, eric.dumazet, kaber, fubar, andy,
Nicolas de Pesloüan
In-Reply-To: <4D738751.6050209@gmail.com>
Until now, ptype_all and ptype_base delivery in __netif_receive_skb() is
inconsistent.
- For ptype_all, we deliver to every device crossed while walking the
rx_handler path (inside the another_round loop), and there is no way to stop
wildcard delivery (no exact match logic).
- For ptype_base, we deliver to the lowest device (orig_dev) and to the highest
(skb->dev) and we can ask for exact match delivery.
This patch try and fix this, by:
1/ Doing exact match delivery for both ptype_all and ptype_base, while walking
the rx_handler path.
2/ Doing wildcard match delivery at the end of __netif_receive_skb(), if not
asked to do exact match delivery only.
Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
---
This apply on top of the last batch of patch from Jiri Pirko.
---
net/core/dev.c | 32 ++++++++++++++++++++++++--------
1 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index c71bd18..a368223 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3117,8 +3117,6 @@ static int __netif_receive_skb(struct sk_buff *skb)
{
struct packet_type *ptype, *pt_prev;
rx_handler_func_t *rx_handler;
- struct net_device *orig_dev;
- struct net_device *null_or_dev;
bool deliver_exact = false;
int ret = NET_RX_DROP;
__be16 type;
@@ -3134,7 +3132,6 @@ static int __netif_receive_skb(struct sk_buff *skb)
if (!skb->skb_iif)
skb->skb_iif = skb->dev->ifindex;
- orig_dev = skb->dev;
skb_reset_network_header(skb);
skb_reset_transport_header(skb);
@@ -3156,7 +3153,17 @@ another_round:
#endif
list_for_each_entry_rcu(ptype, &ptype_all, list) {
- if (!ptype->dev || ptype->dev == skb->dev) {
+ if (ptype->dev == skb->dev) {
+ if (pt_prev)
+ ret = deliver_skb(skb, pt_prev);
+ pt_prev = ptype;
+ }
+ }
+
+ type = skb->protocol;
+ list_for_each_entry_rcu(ptype,
+ &ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
+ if (ptype->type == type && ptype->dev == skb->dev) {
if (pt_prev)
ret = deliver_skb(skb, pt_prev);
pt_prev = ptype;
@@ -3205,20 +3212,29 @@ ncls:
vlan_on_bond_hook(skb);
/* deliver only exact match when indicated */
- null_or_dev = deliver_exact ? skb->dev : NULL;
+ if (deliver_exact)
+ goto skip_wildcard_delivery;
+
+ list_for_each_entry_rcu(ptype, &ptype_all, list) {
+ if (!ptype->dev) {
+ if (pt_prev)
+ ret = deliver_skb(skb, pt_prev);
+ pt_prev = ptype;
+ }
+ }
type = skb->protocol;
list_for_each_entry_rcu(ptype,
&ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
- if (ptype->type == type &&
- (ptype->dev == null_or_dev || ptype->dev == skb->dev ||
- ptype->dev == orig_dev)) {
+ if (ptype->type == type && !ptype->dev) {
if (pt_prev)
ret = deliver_skb(skb, pt_prev);
pt_prev = ptype;
}
}
+skip_wildcard_delivery:
+
if (pt_prev) {
ret = pt_prev->func(skb, skb->dev, pt_prev);
} else {
--
1.7.2.3
^ permalink raw reply related
* Re: Possible regression in __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6
From: Nicolas de Pesloüan @ 2011-03-06 13:08 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev@vger.kernel.org, David Miller, Stephen Hemminger,
Jay Vosburgh, Patrick Mc Hardy, Eric Dumazet, Andy Gospodarek
In-Reply-To: <20110305220938.GK8573@psychotron.redhat.com>
Le 05/03/2011 23:09, Jiri Pirko a écrit :
> Sat, Mar 05, 2011 at 10:30:33PM CET, nicolas.2p.debian@gmail.com wrote:
>> Hi,
>>
>> Comparing __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6,
>> I noticed an important difference: The ptype_base loop used to
>> deliver to orig_dev and this is not true anymore.
>
> I believe this is adressed by submitted patch " net: allow handlers to
> be processed for orig_dev"
I wonder whether we should address it that way (which is the former way to address it).
There are still a difference between ptype_all and ptype_base delivery:
- For ptype_all, we deliver to every device crossed while walking the rx_handler path (inside the
another_round loop). (And there is no way to force exact match delivery).
- For ptype_base, we deliver to the lowest device (orig_dev) and to the highest (skb->dev) and we
can ask for exact match delivery.
This sounds very inconsistent. The only difference between ptype_all and ptype_base is the fact that
ptype->type is NULL (wildcard) for the first and not NULL (a particular protocol) for the second.
I think we should:
1/ deliver to both ptype_all and ptype_base while walking the rx_handler path, but only exact match
(ptype->dev == skb->dev).
2/ deliver to both ptype_all and ptype_base at the end of __netif_receive_skb(), but only wildcard
match (ptype->dev == NULL), skipping this part if the last rx_handler returned RX_HANDLER_EXACT.
Nicolas.
>> Imagine the following simple setup:
>>
>> eth0 -> bond0
>>
>> - A packet handler registered on eth0, with ptype->type == NULL will
>> receive the packet, because it will be delivered in the ptype_all
>> loop, which is inside the another_round loop.
>> - The same packet handler, registered on eth0, but with ptype->type
>> != NULL won't receive the packet, because the ptype_base loop doesn't
>> deliver to orig_dev anymore.
>>
>> I think this can lead to a regression for user space: an application
>> using af_packet to listen to eth0 will receive the packet flow if the
>> registered protocol is NULL, but won't receive anything if the
>> registered protocol is not NULL.
>>
>> Can someone confirm?
>>
>> Nicolas.
>
^ permalink raw reply
* modprobe gets stuck on a e1000e driver mutex wile trying to load the it
From: Edy H. @ 2011-03-06 12:34 UTC (permalink / raw)
To: e1000-devel, linux-net, netdev
Hello,
I have an Intel® Server Board S5500BC which started to cause problems
during boot, mainly with the e1000e driver, raising the server without
any NIC/s. A reboot ususally recovers the NIC/s.
The following trace is seen from the unit boot, showing an
inconsistent problem while trying to load the e1000e driver.
Looking at the sources, it looks like it is stuck in a critical
section. But I frankly do not understand how it is possible, as there
is no real reason for it to hang on the mutex lock.
At the moment, except memory curroption/leak I cannot think of
anything else... I see it on several machines, so I assume it is not a
specific HW problem.
I will apriciate if someone could point me into some direction.
Note, the pasted message below repeats in a loop, always hangling on
the same lock. In addition, these units also hang from time to time on
initramfs shell, with an avarage of 3 times less frequent than the NIC
issue.
I'm using the following Kernel version:
Linux version 2.6.32-29-generic-pae (buildd@roseapple) (gcc version
4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #58-Ubuntu SMP Fri Feb 11 19:15:25 UTC
2011 (Ubuntu 2.6.32-29.58-generic-pae 2.6.32.28+drm33.13)
Thanks,
Edy.
This is the relevant trace from the dmesg output:
[ 5.732070] lp: driver loaded but no devices found
[ 6.002709] Console: switching to colour frame buffer device 80x30
[ 6.023688] type=1505 audit(1299198224.576:5):
operation="profile_load" pid=820 name="/usr/sbin/tcpdump"
[ 6.023858] type=1505 audit(1299198224.576:6):
operation="profile_replace" pid=819 name="/sbin/dhclient3"
[ 6.024301] type=1505 audit(1299198224.576:7):
operation="profile_replace" pid=819
name="/usr/lib/NetworkManager/nm-dhcp-client.action"
[ 6.024550] type=1505 audit(1299198224.576:8):
operation="profile_replace" pid=819
name="/usr/lib/connman/scripts/dhclient-script"
[ 6.134782] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 6.177099] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 6.177269] CONFIG_NF_CT_ACCT is deprecated and will be removed
soon. Please use
[ 6.177271] nf_conntrack.acct=1 kernel parameter, acct=1
nf_conntrack module option or
[ 6.177273] sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
[ 240.190031] INFO: task modprobe:178 blocked for more than 120 seconds.
[ 240.190534] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 240.191160] modprobe D 00183416 0 178 1 0x00000000
[ 240.191169] f6e8fd44 00000086 f829b248 00183416 00000000 c088f4c0
f6f85be4 c088f4c0
[ 240.191186] 6c1f8881 00000000 c088f4c0 c088f4c0 f6f85be4 c088f4c0
c088f4c0 f6e3ea00
[ 240.191202] 6a3827bd 00000000 f6f85940 f829b238 f829b23c ffffffff
f6e8fd70 c05b3bb6
[ 240.191216] Call Trace:
[ 240.191231] [<c05b3bb6>] __mutex_lock_slowpath+0xd6/0x140
[ 240.191239] [<c05b3ac5>] mutex_lock+0x25/0x40
[ 240.191255] [<f8285be1>] e1000_acquire_swflag_ich8lan+0x21/0xa0 [e1000e]
[ 240.191270] [<f8286aea>] e1000_reset_hw_ich8lan+0x7a/0x250 [e1000e]
[ 240.191287] [<f82940bd>] e1000e_reset+0xfd/0x330 [e1000e]
[ 240.191302] [<f82984e8>] e1000_probe+0x7b7/0xa09 [e1000e]
[ 240.191309] [<c0227745>] ? iput+0x25/0x60
[ 240.191316] [<c026af3b>] ? sysfs_addrm_finish+0x3b/0xf0
[ 240.191325] [<c0370043>] local_pci_probe+0x13/0x20
[ 240.191331] [<c0370e48>] pci_device_probe+0x68/0x90
[ 240.191339] [<c03fceed>] really_probe+0x4d/0x140
[ 240.191347] [<c040380e>] ? pm_runtime_barrier+0x4e/0xc0
[ 240.191354] [<c03fd01c>] driver_probe_device+0x3c/0x60
[ 240.191361] [<c03fd0c1>] __driver_attach+0x81/0x90
[ 240.191368] [<c03fc503>] bus_for_each_dev+0x53/0x80
[ 240.191375] [<c03fcdbe>] driver_attach+0x1e/0x20
[ 240.191382] [<c03fd040>] ? __driver_attach+0x0/0x90
[ 240.191389] [<c03fc785>] bus_add_driver+0xd5/0x280
[ 240.191396] [<c0370d80>] ? pci_device_remove+0x0/0x40
[ 240.191403] [<c03fd3ba>] driver_register+0x6a/0x130
[ 240.191410] [<c0371085>] __pci_register_driver+0x45/0xb0
[ 240.191423] [<f82a304b>] e1000_init_module+0x4b/0x67 [e1000e]
[ 240.191430] [<c0103041>] do_one_initcall+0x31/0x190
[ 240.191443] [<f82a3000>] ? e1000_init_module+0x0/0x67 [e1000e]
[ 240.191452] [<c018acb0>] sys_init_module+0xb0/0x210
[ 240.191458] [<c01097ac>] syscall_call+0x7/0xb
lshw network output:
*-network
description: Ethernet interface
product: 82574L Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:01:00.0
logical name: eth1
version: 00
serial: 00:1b:21:57:0a:54
size: 100MB/s
capacity: 1GB/s
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list rom
ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd
autonegotiation
configuration: autonegotiation=off broadcast=yes driver=e1000e
driverversion=1.0.2-k2 duplex=full firmware=1.8-0 ip=127.0.1.1
latency=0 link=yes multicast=yes port=twisted pair speed=100MB/s
resources: irq:16 memory:b1a80000-b1a9ffff
memory:b1a00000-b1a7ffff ioport:2000(size=32) memory:b1aa0000-b1aa3fff
memory:b1c00000-b1c3ffff(prefetchable)
*-network
description: Ethernet interface
product: 82578DM Gigabit Network Connection
vendor: Intel Corporation
physical id: 19
bus info: pci@0000:00:19.0
logical name: eth0
version: 05
serial: 00:15:17:c8:0a:3d
size: 100MB/s
capacity: 1GB/s
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list ethernet physical tp
10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=off broadcast=yes driver=e1000e
driverversion=1.0.2-k2 duplex=full firmware=0.9-2 ip=127.0.0.1
latency=0 link=yes multicast=yes port=twisted pair speed=100MB/s
resources: irq:34 memory:b1b00000-b1b1ffff
memory:b1b24000-b1b24fff ioport:3020(size=32)
*-network
description: Ethernet interface
product: 82574L Gigabit Network Connection
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:03:00.0
logical name: eth2
version: 00
serial: 00:15:17:c8:0a:3c
size: 100MB/s
capacity: 1GB/s
width: 32 bits
clock: 33MHz
capabilities: pm msi pciexpress msix bus_master cap_list
ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd
autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e
driverversion=1.0.2-k2 duplex=full firmware=1.9-0 ip=172.17.6.2
latency=0 link=yes multicast=yes port=twisted pair speed=100MB/s
resources: irq:16 memory:b1900000-b191ffff ioport:1000(size=32)
memory:b1920000-b1923fff
*-network:0 DISABLED
description: Ethernet interface
physical id: 1
logical name: eth1.24
serial: 00:1b:21:57:0a:54
size: 100MB/s
capacity: 1GB/s
capabilities: ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd
1000bt-fd autonegotiation
configuration: autonegotiation=off broadcast=yes driver=802.1Q
VLAN Support driverversion=1.8 duplex=full firmware=N/A link=yes
multicast=yes port=twisted pair speed=100MB/s
*-network:1
description: Ethernet interface
physical id: 2
logical name: vlan24
serial: 00:15:17:c8:0a:3d
size: 100MB/s
capacity: 1GB/s
capabilities: ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd
1000bt-fd autonegotiation
configuration: autonegotiation=off broadcast=yes driver=802.1Q
VLAN Support driverversion=1.8 duplex=full firmware=N/A
ip=172.24.4.182 link=yes multicast=yes port=twisted pair speed=100MB/s
^ permalink raw reply
* 2.6.38-rc7-git4: Reported regressions 2.6.36 -> 2.6.37
From: Rafael J. Wysocki @ 2011-03-06 12:34 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, DRI, Florian Mickler, Andrew Morton,
Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki
This message contains a list of some post-2.6.36 regressions introduced before
2.6.37, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.36 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2011-03-06 132 28 23
2011-02-21 128 35 26
2011-02-13 126 36 30
2011-02-03 118 36 31
2010-12-30 85 32 26
2010-12-19 73 28 24
2010-12-03 55 25 19
2010-11-19 39 29 25
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28812
Subject : DVI attached monitor is turned off while booting linux 2.6.37 and higher
Submitter : Markus Heinz <markus.heinz@uni-dortmund.de>
Date : 2011-02-10 19:33 (25 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28772
Subject : oops in nfs_revalidate_mapping
Submitter : Daniel Poelzleithner <bugzilla.kernel.org@poelzi.org>
Date : 2011-02-10 13:59 (25 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28662
Subject : i915 in kernel 2.6.38-rc4, high number of wakeups
Submitter : Kan-Ru Chen <kanru@kanru.info>
Date : 2011-02-09 07:06 (26 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28622
Subject : radeon video lockup
Submitter : Daniel Poelzleithner <bugzilla.kernel.org@poelzi.org>
Date : 2011-02-08 17:48 (27 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28612
Subject : regular soft lockup
Submitter : Alexandre Demers <alexandre.f.demers@gmail.com>
Date : 2011-02-08 16:39 (27 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28582
Subject : whole system hang when start X
Submitter : Gu Rui <chaos.proton@gmail.com>
Date : 2011-02-08 08:33 (27 days old)
First-Bad-Commit: http://git.kernel.org/linus/d5bb081b027b520f9e59b4fb8faea83a136ec15e
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=28332
Subject : [RV620] Can not re-enable LVDS after using HDMI only
Submitter : Rafał Miłecki <zajec5@gmail.com>
Date : 2011-02-05 22:42 (30 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27892
Subject : SNB: GPU hang with Slip xscreensaver
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2011-01-31 12:06 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27842
Subject : [regression?] hang with 2.6.37 on a BTRFS test machine
Submitter : Martin Steigerwald <Martin@lichtvoll.de>
Date : 2011-01-23 12:06 (43 days old)
Message-ID : <<201101231306.23069.Martin@lichtvoll.de>>
References : http://marc.info/?l=linux-kernel&m=129578445613283&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27642
Subject : 2.6.37 says WARNING: at arch/x86/kernel/apic/apic.c:1287 setup_local_APIC+0x18f/0x263()
Submitter : Rob Landley <rlandley@parallels.com>
Date : 2011-01-18 13:11 (48 days old)
Message-ID : <4D359188.3040408@parallels.com>
References : http://marc.info/?l=linux-kernel&m=129535632319892&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27152
Subject : VGA output broken at cold boot
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2011-01-20 13:26 (46 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27132
Subject : flush-btrfs gets into an infinite loop
Submitter : Artem Anisimov <aanisimov@inbox.ru>
Date : 2011-01-20 11:51 (46 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26802
Subject : b43: Suspend failed
Submitter : Patrick Matthäi <patrick@linux-dev.org>
Date : 2011-01-15 18:56 (51 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26612
Subject : BUG in fs/inode.c:429
Submitter : Florian Kriener <florian@kriener.org>
Date : 2011-01-06 16:35 (60 days old)
Message-ID : <201101061735.40060.florian@kriener.org>
References : http://marc.info/?l=linux-kernel&m=129433235223735&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26582
Subject : NULL pointer dereference on pipe creation
Submitter : Ferenc Wágner <wferi@niif.hu>
Date : 2011-01-12 13:30 (54 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26112
Subject : [LogFS] [2.6.37-rc8+] Kernel BUG at logfs/readwrite.c:297!
Submitter : Prasad Joshi <prasadjoshi124@gmail.com>
Date : 2011-01-02 21:22 (64 days old)
Message-ID : <AANLkTinpoM8FuG8UkF88xs_V37dz_wgE8t-s0JPzaS-w@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129400335910652&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26102
Subject : [2.6.37-rc8] BUG kmalloc-256: Poison overwritten.
Submitter : Pawel Sikora <pluto@agmk.net>
Date : 2010-12-30 15:08 (67 days old)
Message-ID : <201012301608.40859.pluto@agmk.net>
References : http://marc.info/?l=linux-kernel&m=129372388925679&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=26042
Subject : BUG: NULL pointer dereference at shrink_dcache_parent
Submitter : Ferenc Wágner <wferi@niif.hu>
Date : 2011-01-03 10:49 (63 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25832
Subject : kernel crashes upon resume if usb devices are removed when suspended
Submitter : rocko <rockorequin@hotmail.com>
Date : 2010-12-29 11:47 (68 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25732
Subject : i915 turns picture green when display switched off-on
Submitter : Tõnu Raitviir <jussuf@linux.ee>
Date : 2010-12-27 22:14 (70 days old)
First-Bad-Commit: http://git.kernel.org/linus/3c17fe4b8f40a112a85758a9ab2aebf772bdd647
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24822
Subject : Embedded DisplayPort is detected wrongly on HP ProBook 5320m
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2010-12-13 11:09 (84 days old)
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22942
Subject : [2.6.37-rc1, OOM] virtblk: OOM in do_virtblk_request()
Submitter : Dave Chinner <david@fromorbit.com>
Date : 2010-11-05 1:30 (122 days old)
Message-ID : <20101105013003.GE13830@dastard>
References : http://marc.info/?l=linux-kernel&m=128892062917641&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22642
Subject : 2.6.37-rc1: Disk takes 10 seconds to resume - MacBook2,1
Submitter : Tobias <devnull@plzk.org>
Date : 2010-11-10 19:33 (117 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=30322
Subject : BUG in xs_tcp_setup_socket
Submitter : Ben Hutchings <bhutchings@solarflare.com>
Date : 2011-03-01 20:34 (6 days old)
Patch : http://article.gmane.org/gmane.linux.nfs/38949
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=29722
Subject : kworker consumes ~100% CPU on HP Elitebook 8540w after resume
Submitter : Ortwin Glück <odi@odi.ch>
Date : 2011-02-23 11:49 (12 days old)
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Patch : https://patchwork.kernel.org/patch/604371/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27202
Subject : Remote control of saa7134-based tv card "ASUSTeK P7131 Hybrid" stopped working in 2.6.37
Submitter : <acaizzo@gmail.com>
Date : 2011-01-20 17:23 (46 days old)
First-Bad-Commit: http://git.kernel.org/linus/4651918a4afdd49bdea21d2f919b189ef17a6399
Handled-By : Mauro Carvalho Chehab <mchehab@redhat.com>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=44532
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25922
Subject : IdeaPad Y530 brightness keys not functioning
Submitter : Tomasz <tm.temp@gmx.com>
Date : 2010-12-30 12:48 (67 days old)
Handled-By : Ike Panhc <ikepanhc@gmail.com>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=48702
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24982
Subject : Inconsistent DPMS handling with 2.6.37 DRM
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2010-12-16 16:32 (81 days old)
Handled-By : Takashi Iwai <tiwai@suse.de>
Keith Packard <keithp@keithp.com>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=40392
https://patchwork.kernel.org/patch/530921/
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.36 and 2.6.37, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=21782
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [patch net-next-2.6 6/8] bonding: move processing of recv handlers into handle_frame()
From: Nicolas de Pesloüan @ 2011-03-06 12:24 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet, andy
In-Reply-To: <4D724DB4.9020207@gmail.com>
Le 05/03/2011 15:50, Nicolas de Pesloüan a écrit :
> Le 05/03/2011 15:43, Jiri Pirko a écrit :
>> Sat, Mar 05, 2011 at 03:33:30PM CET, nicolas.2p.debian@gmail.com wrote:
>>> Le 05/03/2011 11:29, Jiri Pirko a écrit :
>>>> Since now when bonding uses rx_handler, all traffic going into bond
>>>> device goes thru bond_handle_frame. So there's no need to go back into
>>>> bonding code later via ptype handlers. This patch converts
>>>> original ptype handlers into "bonding receive probes". These functions
>>>> are called from bond_handle_frame and they are registered per-mode.
>>>
>>> Does this still support having the arp_ip_target on a vlan?
>>>
>>> (eth0 -> bond0 -> bond0.100, with arp_ip_target only reachable
>>> through bond0.100).
>>
>> This case is still covered with vlan_on_bond_hook
>> eth0->
>> bond_handle_frame
>> bond0->
>> vlan_hwaccel_do_receive
>> bond0.5->
>> vlan_on_bond_hook -> reinject into bond0
>> -> bond_handle_frame (here it is processed)
>
> Sound good to me.
>
> Reviewed-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
After another review, I think it won't work.
vlan_on_bond() will reinject into bond0, but bond_handle_frame() is registered as the rx_handler for
the slaves (eth0 in the above setup), not as the rx_handler for the master (bond0 in the above
setup). So, bond_handlee_frame() will never see the untagged ARP request/reply and bonding ARP
monitoring will fail.
That being said, the current vlan_on_bond_hook() hack already suffer other troubles and for example
won't support the following setup:
eth0 -> bond0 -> br0 -> br0.100.
I think we need to fix this stacking issue in a more general way.
Nicolas.
^ 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