* dccp-test-tree [PATCH 9/10] Userspace support for modifying the ECN bits of Data/DataAck packets
From: Gerrit Renker @ 2009-08-09 19:48 UTC (permalink / raw)
To: dccp; +Cc: netdev, Gerrit Renker
In-Reply-To: <1249847327-6792-9-git-send-email-gerrit@erg.abdn.ac.uk>
This allows to pass ECN bits as cmsg ancillary data with a cmsg_type of
DCCP_SCM_ECN_BITS for Data/DataAck packets.
The scope of this patch is for developing user-space applications that work
with, modify, or control the use of ECN bits on data packets.
RFC: This is an AF-independent alternative to using IP_TOS/IPV6_TCLASS for
modifying the ECN bits.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
Documentation/networking/dccp.txt | 12 ++++++++++--
include/linux/dccp.h | 1 +
net/dccp/output.c | 10 +++++++---
net/dccp/proto.c | 20 ++++++++++++++++++++
4 files changed, 38 insertions(+), 5 deletions(-)
--- a/Documentation/networking/dccp.txt
+++ b/Documentation/networking/dccp.txt
@@ -32,8 +32,16 @@ is at http://www.ietf.org/html.charters/dccp-charter.html
ECN Support
===========
By default, all outgoing packets are sent with ECT(0) as per RFC 3168, sec. 5.
-This can be disabled by setting the `ecn_local' sysctl to 0 (see below). The
-ECN Nonce (RFC 3540) is not supported.
+This can be disabled by setting the `ecn_local' sysctl to 0 (see below).
+
+For Data/DataAck packets, the ECN bits can be modified by passing an appropriate
+cmsg(3) value as ancillary data to sendmsg(2). The argument is an uint8_t value
+between 0..3 (corresponding to Not-ECT, ECT(1), ECT(0), and CE). Values greater
+than 3 are not accepted. Values need to be wrapped into a cmsg(3) header:
+ cmsg->cmsg_level = SOL_DCCP;
+ cmsg->cmsg_type = DCCP_SCM_ECN_BITS;
+ cmsg->cmsg_len = CMSG_LEN(sizeof(uint8_t)); /* or CMSG_LEN(1) */
+
Missing features
================
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -202,6 +202,7 @@ enum dccp_cmsg_type {
DCCP_SCM_PRIORITY = 1,
DCCP_SCM_QPOLICY_MAX = 0xFFFF,
/* ^-- Up to here reserved exclusively for qpolicy parameters */
+ DCCP_SCM_ECN_BITS,
DCCP_SCM_MAX
};
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -53,7 +53,7 @@ static int dccp_transmit_skb(struct sock *sk, struct sk_buff *skb)
const u32 dccp_header_size = sizeof(*dh) +
sizeof(struct dccp_hdr_ext) +
dccp_packet_hdr_len(dcb->dccpd_type);
- int err, set_ack = 1;
+ int err, set_ack = 1, ecn_bits = INET_ECN_ECT_0;
u64 ackno = dp->dccps_gsr;
/*
* Increment GSS here already in case the option code needs it.
@@ -66,6 +66,8 @@ static int dccp_transmit_skb(struct sock *sk, struct sk_buff *skb)
set_ack = 0;
/* fall through */
case DCCP_PKT_DATAACK:
+ /* ECN bits of Data/DataAck are set in dccp_sendmsg() */
+ ecn_bits = DCCP_SKB_CB(skb)->dccpd_ecn;
case DCCP_PKT_RESET:
break;
@@ -130,8 +132,10 @@ static int dccp_transmit_skb(struct sock *sk, struct sk_buff *skb)
break;
}
- if (dp->dccps_r_ecn_ok)
- INET_ECN_xmit(sk);
+ if (dp->dccps_r_ecn_ok) {
+ inet_sk(sk)->tos &= ~INET_ECN_MASK;
+ inet_sk(sk)->tos |= ecn_bits & INET_ECN_MASK;
+ }
icsk->icsk_af_ops->send_check(sk, 0, skb);
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -707,7 +707,17 @@ EXPORT_SYMBOL_GPL(compat_dccp_getsockopt);
static int dccp_msghdr_parse(struct msghdr *msg, struct sk_buff *skb)
{
+ const struct dccp_sock *dp = dccp_sk(skb->sk);
struct cmsghdr *cmsg = CMSG_FIRSTHDR(msg);
+ u8 val;
+
+ /*
+ * Setting ECN bits via DCCP_SCM_ECN_BITS: Data/DataAck only.
+ * See dccp_transmit_skb() where further processing takes place.
+ * By default, when no cmsg bits are supplied and when ECN is not
+ * disabled, ECT(0) is used for all outgoing packets (RFC 3168, 5.).
+ */
+ DCCP_SKB_CB(skb)->dccpd_ecn = INET_ECN_ECT_0;
/*
* Assign an (opaque) qpolicy priority value to skb->priority.
@@ -739,6 +749,16 @@ static int dccp_msghdr_parse(struct msghdr *msg, struct sk_buff *skb)
return -EINVAL;
skb->priority = *(__u32 *)CMSG_DATA(cmsg);
break;
+ case DCCP_SCM_ECN_BITS:
+ if (!dp->dccps_r_ecn_ok)
+ return -EINVAL;
+ if (cmsg->cmsg_len != CMSG_LEN(sizeof(__u8)))
+ return -EINVAL;
+ val = *(__u8 *)CMSG_DATA(cmsg);
+ if (val > INET_ECN_MASK)
+ return -EINVAL;
+ DCCP_SKB_CB(skb)->dccpd_ecn = val;
+ break;
default:
return -EINVAL;
}
--
1.6.0.rc2
^ permalink raw reply
* dccp-test-tree [PATCH 6/10] Extend the loss interval code to support ECN events
From: Gerrit Renker @ 2009-08-09 19:48 UTC (permalink / raw)
To: dccp; +Cc: netdev, Gerrit Renker
In-Reply-To: <1249847327-6792-6-git-send-email-gerrit@erg.abdn.ac.uk>
This updates the TFRC loss intervals code, which so far could only support
lost packets, to also handle the case of ECN-marked-CE packets:
* the begin and length of the loss interval are different;
* there are combinations of loss + ECN-marked-CE which the code does not
currently consider (it is not worth the complexity), comments have been
added to point this out.
Further changes:
----------------
The implementation of the "is the loss interval already closed?" check as per
RFC 4342, 10.2 has been improved to test the condition more efficiently.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/ccids/lib/loss_interval.c | 76 ++++++++++++++++++++++++++++--------
1 files changed, 59 insertions(+), 17 deletions(-)
--- a/net/dccp/ccids/lib/loss_interval.c
+++ b/net/dccp/ccids/lib/loss_interval.c
@@ -124,12 +124,12 @@ void tfrc_lh_update_i_mean(struct tfrc_loss_hist *lh, struct sk_buff *skb)
tfrc_lh_calc_i_mean(lh);
}
-/* Determine if `new_loss' does begin a new loss interval [RFC 4342, 10.2] */
-static inline u8 tfrc_lh_is_new_loss(struct tfrc_loss_interval *cur,
- struct tfrc_rx_hist_entry *new_loss)
+/* RFC 4342, 10.2: test for the existence of packet with sequence number S */
+static bool tfrc_lh_closed_check(struct tfrc_loss_interval *cur, const u8 ccval)
{
- return dccp_delta_seqno(cur->li_seqno, new_loss->tfrchrx_seqno) > 0 &&
- (cur->li_is_closed || SUB16(new_loss->tfrchrx_ccval, cur->li_ccval) > 4);
+ if (SUB16(ccval, cur->li_ccval) > 4)
+ cur->li_is_closed = true;
+ return cur->li_is_closed;
}
/** tfrc_lh_interval_add - Insert new record into the Loss Interval database
@@ -142,27 +142,69 @@ static inline u8 tfrc_lh_is_new_loss(struct tfrc_loss_interval *cur,
bool tfrc_lh_interval_add(struct tfrc_loss_hist *lh, struct tfrc_rx_hist *rh,
u32 (*calc_first_li)(struct sock *), struct sock *sk)
{
- struct tfrc_loss_interval *cur = tfrc_lh_peek(lh), *new;
+ struct tfrc_loss_interval *cur = tfrc_lh_peek(lh);
+ struct tfrc_rx_hist_entry *cong_evt;
+ u64 cong_evt_seqno;
+
+ /*
+ * Determine if the new event is caused by a lost or ECN-marked packet.
+ * Both events can coincide (e.g. if the third packet after a loss is
+ * marked as CE). We avoid the complexity caused by such mixed cases:
+ * 1) if the cause is a lost packet, we do not check whether it is
+ * also an ECN-marked packet (not necessary);
+ * 2) calling this routine with a loss_count of 0..NDUPACK-1 implies
+ * that the cause is an ECN-marked-CE packet.
+ * FIXME: if in this case the loss_count is not 0, loss tracking is
+ * reset. This is a complex corner case (see packet_history.c) and
+ * hence currently not supported.
+ */
+ if (rh->loss_count == TFRC_NDUPACK) {
+ /*
+ * The sequence number of the first packet known to be lost is
+ * the successor of the last packet received before the gap.
+ */
+ cong_evt = tfrc_rx_hist_loss_prev(rh);
+ cong_evt_seqno = ADD48(cong_evt->tfrchrx_seqno, 1);
+ } else {
+ /*
+ * ECN-marked packet. Since ECN-marks are reported as soon as a
+ * packet is delivered, it is stored in the last-received entry.
+ */
+ cong_evt = tfrc_rx_hist_last_rcv(rh);
+ cong_evt_seqno = cong_evt->tfrchrx_seqno;
+ }
- if (cur != NULL && !tfrc_lh_is_new_loss(cur, tfrc_rx_hist_loss_prev(rh)))
- return false;
+ /* Test if this event starts a new loss interval */
+ if (cur != NULL) {
+ s64 len = dccp_delta_seqno(cur->li_seqno, cong_evt_seqno);
+ if (len <= 0)
+ return false;
+
+ if (!tfrc_lh_closed_check(cur, cong_evt->tfrchrx_ccval))
+ return false;
- new = tfrc_lh_demand_next(lh);
- if (unlikely(new == NULL)) {
+ /* RFC 5348, 5.3: length between subsequent intervals */
+ cur->li_length = len;
+ }
+
+ /* Make the new interval the current one */
+ cur = tfrc_lh_demand_next(lh);
+ if (unlikely(cur == NULL)) {
DCCP_CRIT("Cannot allocate/add loss record.");
return false;
}
- new->li_seqno = tfrc_rx_hist_loss_prev(rh)->tfrchrx_seqno;
- new->li_ccval = tfrc_rx_hist_loss_prev(rh)->tfrchrx_ccval;
- new->li_is_closed = 0;
+ cur->li_seqno = cong_evt_seqno;
+ cur->li_ccval = cong_evt->tfrchrx_ccval;
+ cur->li_is_closed = false;
if (++lh->counter == 1)
- lh->i_mean = new->li_length = (*calc_first_li)(sk);
+ lh->i_mean = cur->li_length = (*calc_first_li)(sk);
else {
- cur->li_length = dccp_delta_seqno(cur->li_seqno, new->li_seqno);
- new->li_length = dccp_delta_seqno(new->li_seqno,
- tfrc_rx_hist_last_rcv(rh)->tfrchrx_seqno) + 1;
+ /* RFC 5348, 5.3: length of the open loss interval I_0 */
+ cur->li_length = dccp_delta_seqno(cur->li_seqno,
+ tfrc_rx_hist_last_rcv(rh)->tfrchrx_seqno) + 1;
+
if (lh->counter > (2*LIH_SIZE))
lh->counter -= LIH_SIZE;
--
1.6.0.rc2
^ permalink raw reply
* dccp-test-tree [PATCH 2/10] Add sysctl to toggle the local support for ECN
From: Gerrit Renker @ 2009-08-09 19:48 UTC (permalink / raw)
To: dccp; +Cc: netdev, Gerrit Renker
In-Reply-To: <1249847327-6792-2-git-send-email-gerrit@erg.abdn.ac.uk>
This sysctl disables local ECN support for interpreting ECN bits.
When set to 0, the host behaves as if it were ECN-incapable: ECN bits are
ignored and the mandatory "Change L(ECN Incapable, 1)" (RFC 4340, 12.1) is
sent during feature negotiation to signal to the other endpoint to signal
that ECN bits will not be interpreted.
The behaviour is slightly different from the tcp_ecn sysctl, since DCCP
connections are ECN-enabled per default.
Setting ECT codepoints in outgoing packets can not be controlled by this sysctl,
but is possible by setting the sysctl to 0 at the remote (receiving) end. This
signals that the remote end can not read ECN bits. Due to RFC 4340, 12.2, all
outgoing packets are then sent as ECN-incapable.
Inter-operability issues: the host does not set a preference for the remote ECN
Incapable feature. Within the existing feature-negotiation infrastructure, this
ensures that all valid values (ECN Incapable = 0 or 1) are acceptable.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
Documentation/networking/dccp.txt | 12 ++++++++++++
net/dccp/feat.c | 23 ++++++++++++++++-------
net/dccp/feat.h | 1 +
net/dccp/sysctl.c | 8 ++++++++
4 files changed, 37 insertions(+), 7 deletions(-)
--- a/Documentation/networking/dccp.txt
+++ b/Documentation/networking/dccp.txt
@@ -29,6 +29,12 @@ It has a base protocol and pluggable congestion control IDs (CCIDs).
DCCP is a Proposed Standard (RFC 2026), and the homepage for DCCP as a protocol
is at http://www.ietf.org/html.charters/dccp-charter.html
+ECN Support
+===========
+By default, all outgoing packets are sent with ECT(0) as per RFC 3168, sec. 5.
+This can be disabled by setting the `ecn_local' sysctl to 0 (see below). The
+ECN Nonce (RFC 3540) is not supported.
+
Missing features
================
@@ -163,6 +169,12 @@ seq_window = 100
The initial sequence window (sec. 7.5.2) of the sender. This influences
the local ackno validity and the remote seqno validity windows (7.5.1).
+ecn_local = 1
+ This toggles local ECN support: when set to 0, ECN Incapable (sec. 12.1)
+ is sent and ECN bits of incoming packets are ignored. Note that this is
+ different from tcp_ecn: to disable sending of ECT codepoints, the remote
+ peer needs to set this sysctl to zero.
+
tx_qlen = 5
The size of the transmit buffer in packets. A value of 0 corresponds
to an unbounded transmit buffer.
--- a/net/dccp/feat.c
+++ b/net/dccp/feat.c
@@ -29,7 +29,8 @@
/* feature-specific sysctls - initialised to the defaults from RFC 4340, 6.4 */
unsigned long sysctl_dccp_sequence_window __read_mostly = 100;
int sysctl_dccp_rx_ccid __read_mostly = 2,
- sysctl_dccp_tx_ccid __read_mostly = 2;
+ sysctl_dccp_tx_ccid __read_mostly = 2,
+ sysctl_dccp_ecn_local __read_mostly = true;
/*
* Feature activation handlers.
@@ -1111,7 +1112,8 @@ static u8 dccp_feat_change_recv(struct list_head *fn, u8 is_mandatory, u8 opt,
* No particular preferences have been registered. We deal with
* this situation by assuming that all valid values are equally
* acceptable, and apply the following checks:
- * - if the peer's list is a singleton, we accept a valid value;
+ * - if the peer's list is a singleton, we accept a valid value
+ * (allows to cope gracefully with e.g. remote ECN Incapable);
* - if we are the server, we first try to see if the peer (the
* client) advertises the default value. If yes, we use it,
* otherwise we accept the preferred value;
@@ -1430,11 +1432,18 @@ int dccp_feat_init(struct sock *sk)
rc = __feat_register_sp(fn, DCCPF_SHORT_SEQNOS, true, true, &off, 1);
if (rc)
return rc;
-
- /* RFC 4340 12.1: "If a DCCP is not ECN capable, ..." */
- rc = __feat_register_sp(fn, DCCPF_ECN_INCAPABLE, true, true, &on, 1);
- if (rc)
- return rc;
+ /*
+ * ECN Incapable Feature (RFC 4340, 12.1)
+ *
+ * We do not register preferences for the feature-remote value, so that
+ * the preference list is empty and either value is locally acceptable.
+ */
+ if (!sysctl_dccp_ecn_local) {
+ rc = __feat_register_sp(fn, DCCPF_ECN_INCAPABLE,
+ true, true, &on, 1);
+ if (rc)
+ return rc;
+ }
/*
* We advertise the available list of CCIDs and reorder according to
--- a/net/dccp/feat.h
+++ b/net/dccp/feat.h
@@ -106,6 +106,7 @@ struct ccid_dependency {
extern unsigned long sysctl_dccp_sequence_window;
extern int sysctl_dccp_rx_ccid;
extern int sysctl_dccp_tx_ccid;
+extern int sysctl_dccp_ecn_local;
extern int dccp_feat_init(struct sock *sk);
extern void dccp_feat_initialise_sysctls(void);
--- a/net/dccp/sysctl.c
+++ b/net/dccp/sysctl.c
@@ -78,6 +78,14 @@ static struct ctl_table dccp_default_table[] = {
.extra2 = &u8_max,
},
{
+ .procname = "ecn_local",
+ .data = &sysctl_dccp_ecn_local,
+ .maxlen = sizeof(sysctl_dccp_ecn_local),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ },
+ {
.procname = "tx_qlen",
.data = &sysctl_dccp_tx_qlen,
.maxlen = sizeof(sysctl_dccp_tx_qlen),
--
1.6.0.rc2
^ permalink raw reply
* [PATCH 11/14] drivers/net: use printk_once
From: Marcin Slusarz @ 2009-08-09 19:54 UTC (permalink / raw)
To: LKML; +Cc: netdev
In-Reply-To: <1249847649-11631-1-git-send-email-marcin.slusarz@gmail.com>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: netdev@vger.kernel.org
---
drivers/net/mlx4/en_main.c | 6 +-----
drivers/net/mv643xx_eth.c | 4 +---
2 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/mlx4/en_main.c b/drivers/net/mlx4/en_main.c
index 9ed4a15..18e9e4f 100644
--- a/drivers/net/mlx4/en_main.c
+++ b/drivers/net/mlx4/en_main.c
@@ -151,15 +151,11 @@ static void mlx4_en_remove(struct mlx4_dev *dev, void *endev_ptr)
static void *mlx4_en_add(struct mlx4_dev *dev)
{
- static int mlx4_en_version_printed;
struct mlx4_en_dev *mdev;
int i;
int err;
- if (!mlx4_en_version_printed) {
- printk(KERN_INFO "%s", mlx4_en_version);
- mlx4_en_version_printed++;
- }
+ printk_once(KERN_INFO "%s", mlx4_en_version);
mdev = kzalloc(sizeof *mdev, GFP_KERNEL);
if (!mdev) {
diff --git a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c
index 0f32db3..dbb1d9c 100644
--- a/drivers/net/mv643xx_eth.c
+++ b/drivers/net/mv643xx_eth.c
@@ -2622,14 +2622,12 @@ static void infer_hw_params(struct mv643xx_eth_shared_private *msp)
static int mv643xx_eth_shared_probe(struct platform_device *pdev)
{
- static int mv643xx_eth_version_printed;
struct mv643xx_eth_shared_platform_data *pd = pdev->dev.platform_data;
struct mv643xx_eth_shared_private *msp;
struct resource *res;
int ret;
- if (!mv643xx_eth_version_printed++)
- printk(KERN_NOTICE "MV-643xx 10/100/1000 ethernet "
+ printk_once(KERN_NOTICE "MV-643xx 10/100/1000 ethernet "
"driver version %s\n", mv643xx_eth_driver_version);
ret = -EINVAL;
--
1.6.3.3
^ permalink raw reply related
* [PATCH 14/14] net: use printk_once
From: Marcin Slusarz @ 2009-08-09 19:54 UTC (permalink / raw)
To: LKML; +Cc: David S. Miller, netdev
In-Reply-To: <1249847649-11631-1-git-send-email-marcin.slusarz@gmail.com>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
---
net/ax25/af_ax25.c | 6 +-----
net/dsa/dsa.c | 4 +---
net/ipv4/raw.c | 6 ++----
net/netfilter/xt_recent.c | 10 +++-------
net/socket.c | 8 ++------
5 files changed, 9 insertions(+), 25 deletions(-)
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index da0f64f..39c895b 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -1792,12 +1792,8 @@ static int ax25_ioctl(struct socket *sock, unsigned int cmd, unsigned long arg)
/* old structure? */
if (cmd == SIOCAX25GETINFOOLD) {
- static int warned = 0;
- if (!warned) {
- printk(KERN_INFO "%s uses old SIOCAX25GETINFO\n",
+ printk_once(KERN_INFO "%s uses old SIOCAX25GETINFO\n",
current->comm);
- warned=1;
- }
if (copy_to_user(argp, &ax25_info, sizeof(struct ax25_info_struct_deprecated))) {
res = -EFAULT;
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 71489f6..ecd2dfb 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -302,14 +302,12 @@ static struct net_device *dev_to_net_device(struct device *dev)
static int dsa_probe(struct platform_device *pdev)
{
- static int dsa_version_printed;
struct dsa_platform_data *pd = pdev->dev.platform_data;
struct net_device *dev;
struct dsa_switch_tree *dst;
int i;
- if (!dsa_version_printed++)
- printk(KERN_NOTICE "Distributed Switch Architecture "
+ printk_once(KERN_NOTICE "Distributed Switch Architecture "
"driver version %s\n", dsa_driver_version);
if (pd == NULL || pd->netdev == NULL)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index 2979f14..f919925 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -470,10 +470,8 @@ static int raw_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg,
if (msg->msg_namelen < sizeof(*usin))
goto out;
if (usin->sin_family != AF_INET) {
- static int complained;
- if (!complained++)
- printk(KERN_INFO "%s forgot to set AF_INET in "
- "raw sendmsg. Fix it!\n",
+ printk_once(KERN_INFO "%s forgot to set AF_INET in "
+ "raw sendmsg. Fix it!\n",
current->comm);
err = -EAFNOSUPPORT;
if (usin->sin_family)
diff --git a/net/netfilter/xt_recent.c b/net/netfilter/xt_recent.c
index eb0ceb8..d60d317 100644
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -456,13 +456,9 @@ static int recent_seq_open(struct inode *inode, struct file *file)
#ifdef CONFIG_NETFILTER_XT_MATCH_RECENT_PROC_COMPAT
static int recent_old_seq_open(struct inode *inode, struct file *filp)
{
- static bool warned_of_old;
-
- if (unlikely(!warned_of_old)) {
- printk(KERN_INFO KBUILD_MODNAME ": Use of /proc/net/ipt_recent"
- " is deprecated; use /proc/net/xt_recent.\n");
- warned_of_old = true;
- }
+ printk_once(KERN_INFO KBUILD_MODNAME ": "
+ "Use of /proc/net/ipt_recent is deprecated; "
+ "use /proc/net/xt_recent.\n");
return recent_seq_open(inode, filp);
}
diff --git a/net/socket.c b/net/socket.c
index 791d71a..1d07f69 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1161,12 +1161,8 @@ static int __sock_create(struct net *net, int family, int type, int protocol,
deadlock in module load.
*/
if (family == PF_INET && type == SOCK_PACKET) {
- static int warned;
- if (!warned) {
- warned = 1;
- printk(KERN_INFO "%s uses obsolete (PF_INET,SOCK_PACKET)\n",
- current->comm);
- }
+ printk_once(KERN_INFO "%s uses obsolete (PF_INET,SOCK_PACKET)\n",
+ current->comm);
family = PF_PACKET;
}
--
1.6.3.3
^ permalink raw reply related
* 2.6.31-rc5-git5: Reported regressions from 2.6.30
From: Rafael J. Wysocki @ 2009-08-09 20:36 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Adrian Bunk, Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.30, for which there
are no fixes in the mainline I know of. If any of them have been fixed already,
please let me know.
If you know of any other unresolved regressions from 2.6.30, please let me know
either and I'll add them to the list. Also, please let me 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
----------------------------------------
2009-08-10 89 27 24
2009-08-02 76 36 28
2009-07-27 70 51 43
2009-07-07 35 25 21
2009-06-29 22 22 15
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13950
Subject : Oops when USB Serial disconnected while in use
Submitter : Bruno Prémont <bonbons@linux-vserver.org>
Date : 2009-08-08 17:47 (2 days old)
References : http://marc.info/?l=linux-kernel&m=124975432900466&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13947
Subject : Libertas: Association request to the driver failed
Submitter : Daniel Mack <daniel@caiaq.de>
Date : 2009-08-07 19:11 (3 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=57921c312e8cef72ba35a4cfe870b376da0b1b87
References : http://marc.info/?l=linux-kernel&m=124967234311481&w=4
Handled-By : Roel Kluin <roel.kluin@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13943
Subject : WARNING: at net/mac80211/mlme.c:2292 with ath5k
Submitter : Fabio Comolli <fabio.comolli@gmail.com>
Date : 2009-08-06 20:15 (4 days old)
References : http://marc.info/?l=linux-kernel&m=124958978600600&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13942
Subject : Troubles with AoE and uninitialized object
Submitter : Bruno Prémont <bonbons@linux-vserver.org>
Date : 2009-08-04 10:12 (6 days old)
References : http://marc.info/?l=linux-kernel&m=124938117104811&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13941
Subject : x86 Geode issue
Submitter : Martin-Éric Racine <q-funk@iki.fi>
Date : 2009-08-03 12:58 (7 days old)
References : http://marc.info/?l=linux-kernel&m=124930434732481&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13940
Subject : iwlagn and sky2 stopped working, ACPI-related
Submitter : Ricardo Jorge da Fonseca Marques Ferreira <storm@sys49152.net>
Date : 2009-08-07 22:33 (3 days old)
References : http://marc.info/?l=linux-kernel&m=124968457731107&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13935
Subject : 2.6.31-rcX breaks Apple MightyMouse (Bluetooth version)
Submitter : Adrian Ulrich <kernel@blinkenlights.ch>
Date : 2009-08-08 22:08 (2 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa047e4f6fa63a6e9d0ae4d7749538830d14a343
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13914
Subject : e1000e reports invalid NVM Checksum on 82566DM-2 (bisected)
Submitter : <jsbronder@gentoo.org>
Date : 2009-08-04 18:06 (6 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13906
Subject : Huawei E169 GPRS connection causes Ooops
Submitter : Clemens Eisserer <linuxhippy@gmail.com>
Date : 2009-08-04 09:02 (6 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13899
Subject : Oops from tar, 2.6.31-rc5, 32 bit on quad core phenom.
Submitter : Gene Heskett <gene.heskett@verizon.net>
Date : 2009-08-01 13:04 (9 days old)
References : http://marc.info/?l=linux-kernel&m=124913190304149&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13895
Subject : 2.6.31-rc4 - slab entry tak_delay_info leaking ???
Submitter : Paul Rolland <rol@as2917.net>
Date : 2009-07-29 08:20 (12 days old)
References : http://marc.info/?l=linux-kernel&m=124884847925375&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13869
Subject : Radeon framebuffer (w/o KMS) corruption at boot.
Submitter : Duncan <1i5t5.duncan@cox.net>
Date : 2009-07-29 16:44 (12 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13848
Subject : iwlwifi (4965) regression since 2.6.30
Submitter : Lukas Hejtmanek <xhejtman@ics.muni.cz>
Date : 2009-07-26 7:57 (15 days old)
References : http://marc.info/?l=linux-kernel&m=124859658502866&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13846
Subject : LEDs switched off permanently by power saving with rt61pci driver
Submitter : Chris Clayton <chris2553@googlemail.com>
Date : 2009-07-13 8:27 (28 days old)
References : http://marc.info/?l=linux-kernel&m=124747418828398&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13837
Subject : Input : regression - touchpad not detected
Submitter : Dave Young <hidave.darkstar@gmail.com>
Date : 2009-07-17 07:13 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124780763701571&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13836
Subject : suspend script fails, related to stdout?
Submitter : Tomas M. <tmezzadra@gmail.com>
Date : 2009-07-17 21:24 (24 days old)
References : http://marc.info/?l=linux-kernel&m=124785853811667&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13833
Subject : Kernel Oops when trying to suspend with ubifs mounted on block2mtd mtd device
Submitter : Tobias Diedrich <ranma@tdiedrich.de>
Date : 2009-07-15 14:20 (26 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=15bce40cb3133bcc07d548013df97e4653d363c1
References : http://marc.info/?l=linux-kernel&m=124766049207807&w=4
http://marc.info/?l=linux-kernel&m=124704927819769&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13819
Subject : system freeze when switching to console
Submitter : Reinette Chatre <reinette.chatre@intel.com>
Date : 2009-07-23 17:57 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13809
Subject : oprofile: possible circular locking dependency detected
Submitter : Jerome Marchand <jmarchan@redhat.com>
Date : 2009-07-22 13:35 (19 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13740
Subject : X server crashes with 2.6.31-rc2 when options are changed
Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com>
Date : 2009-07-07 15:19 (34 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13733
Subject : 2.6.31-rc2: irq 16: nobody cared
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-07-06 18:32 (35 days old)
References : http://marc.info/?l=linux-kernel&m=124690524027166&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13716
Subject : The AIC-7892P controller does not work any more
Submitter : Andrej Podzimek <andrej@podzimek.org>
Date : 2009-07-05 19:23 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13713
Subject : [drm/i915] Possible regression due to commit "Change GEM throttling to be 20ms (...)"
Submitter : <kazikcz@gmail.com>
Date : 2009-07-05 10:49 (36 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b962442e46a9340bdbc6711982c59ff0cc2b5afb
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13645
Subject : NULL pointer dereference at (null) (level2_spare_pgt)
Submitter : poornima nayak <mpnayak@linux.vnet.ibm.com>
Date : 2009-06-17 17:56 (54 days old)
References : http://lkml.org/lkml/2009/6/17/194
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13948
Subject : ath5k broken after suspend-to-ram
Submitter : Johannes Stezenbach <js@sig21.net>
Date : 2009-08-07 21:51 (3 days old)
References : http://marc.info/?l=linux-kernel&m=124968192727854&w=4
Handled-By : Nick Kossifidis <mickflemm@gmail.com>
Patch : http://patchwork.kernel.org/patch/38550/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13946
Subject : x86 MCE malfunction on Thinkpad T42p
Submitter : Johannes Stezenbach <js@sig21.net>
Date : 2009-08-07 17:09 (3 days old)
References : http://marc.info/?l=linux-kernel&m=124966500232399&w=4
Handled-By : Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Patch : http://patchwork.kernel.org/patch/37908/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13944
Subject : MD raid regression
Submitter : Mike Snitzer <snitzer@redhat.com>
Date : 2009-08-05 15:06 (5 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=449aad3e25358812c43afc60918c5ad3819488e7
References : http://marc.info/?l=linux-kernel&m=124948481218857&w=4
Handled-By : NeilBrown <neilb@suse.de>
Patch : http://patchwork.kernel.org/patch/39521/
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 from 2.6.30,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=13615
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] macvlan: add tap device backend
From: Arnd Bergmann @ 2009-08-09 20:42 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev, Patrick McHardy, Stephen Hemminger, David S. Miller,
Herbert Xu, Or Gerlitz, Fischer, Anna, bridge, linux-kernel,
Edge Virtual Bridging
In-Reply-To: <20090809080215.GA17200@redhat.com>
On Sunday 09 August 2009 08:02:16 Michael S. Tsirkin wrote:
> On Thu, Aug 06, 2009 at 09:50:28PM +0000, Arnd Bergmann wrote:
> > * The same framework in macvlan can be used to add a third backend
> > into a future kernel based virtio-net implementation.
>
> Could you split the patches up, to make this last easier?
> patch 1 - export framework
> patch 2 - code using it
Sure, will do.
> > +/* Get packet from user space buffer */
> > +static ssize_t macvtap_get_user(struct macvtap_dev *vtap,
> > + const struct iovec *iv, size_t count,
> > + int noblock)
> > +{
> > + struct sk_buff *skb;
> > + size_t len = count;
> > +
> > + if (unlikely(len < ETH_HLEN))
> > + return -EINVAL;
> > +
> > + skb = alloc_skb(NET_IP_ALIGN + len, GFP_KERNEL);
> > +
> > + if (!skb) {
> > + vtap->m.dev->stats.rx_dropped++;
> > + return -ENOMEM;
> > + }
> > +
> > + skb_reserve(skb, NET_IP_ALIGN);
> > + skb_put(skb, count);
> > +
> > + if (skb_copy_datagram_from_iovec(skb, 0, iv, 0, len)) {
> > + vtap->m.dev->stats.rx_dropped++;
> > + kfree_skb(skb);
> > + return -EFAULT;
> > + }
> > +
> > + skb_set_network_header(skb, ETH_HLEN);
> > + skb->dev = vtap->m.lowerdev;
> > +
> > + macvlan_start_xmit(skb, vtap->m.dev);
> > +
> > + return count;
> > +}
>
> With tap, we discovered that not limiting the number of outstanding
> skbs hurts UDP performance. And the solution was to limit
> the number of outstanding packets - with hacks to work around
> the fact that userspace .
Something seems to be missing in your last sentence here.
My driver OTOH is also missing any sort of flow control in both
RX and TX direction ;) For RX, there should probably just be
a limit of frames that get buffered in the ring.
For TX, I guess there should be a way to let the packet
scheduler handle this and give us a chance to block and
unblock at the right time. I haven't found out yet how to
do that.
Would it be enough to check the dev_queue_xmit() return
code for NETDEV_TX_BUSY?
How would I get notified when it gets free again?
> > + ret = skb_copy_datagram_iovec(skb, 0, iv, len);
> > +
> > + vtap->m.dev->stats.rx_packets++;
> > + vtap->m.dev->stats.rx_bytes += len;
>
> where does atomicity guarantee for these counters come from?
AFAIK, we never do for any driver. They are statistics only and
need not be 100% correct, so the networking stack goes for
lower overhead and 99.9% correct.
> > +static ssize_t macvtap_aio_read(struct kiocb *iocb, const struct iovec *iv,
> > + unsigned long count, loff_t pos)
> > +{
> > + struct file *file = iocb->ki_filp;
> > + struct macvtap_dev *vtap = file->private_data;
> > + DECLARE_WAITQUEUE(wait, current);
> > + struct sk_buff *skb;
> > + ssize_t len, ret = 0;
> > +
> > + if (!vtap)
> > + return -EBADFD;
> > +
> > + len = iov_length(iv, count);
> > + if (len < 0) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
> > +
> > + add_wait_queue(&vtap->wait, &wait);
> > + while (len) {
> > + current->state = TASK_INTERRUPTIBLE;
> > +
> > + /* Read frames from the queue */
> > + if (!(skb=skb_dequeue(&vtap->readq))) {
> > + if (file->f_flags & O_NONBLOCK) {
> > + ret = -EAGAIN;
> > + break;
> > + }
> > + if (signal_pending(current)) {
> > + ret = -ERESTARTSYS;
> > + break;
> > + }
> > + /* Nothing to read, let's sleep */
> > + schedule();
> > + continue;
> > + }
> > + ret = macvtap_put_user(vtap, skb, (struct iovec *) iv, len);
>
> Don't cast away the constness. Instead, fix macvtap_put_user
> to used skb_copy_datagram_const_iovec which does not modify the iovec.
Ah, good catch. I had copied that from the tun driver before you
fixed it there and failed to fix it the right way when I adapted
it for the new interface.
Thanks for the review,
Arnd <><
^ permalink raw reply
* 2.6.31-rc5-git5: Reported regressions 2.6.29 -> 2.6.30
From: Rafael J. Wysocki @ 2009-08-09 21:07 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Andrew Morton, Linus Torvalds, Natalie Protasevich,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions introduced between 2.6.29 and
2.6.30, for which there are no fixes in the mainline I know of. If any of them
have been fixed already, please let me know.
If you know of any other unresolved regressions introduced between 2.6.29
and 2.6.30, please let me know either and I'll add them to the list.
Also, please let me 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
----------------------------------------
2009-08-10 148 39 37
2009-08-02 145 44 39
2009-07-27 143 48 45
2009-07-07 138 50 46
2009-06-29 133 46 43
2009-06-07 110 35 31
2009-05-31 100 32 27
2009-05-24 92 34 27
2009-05-16 81 36 33
2009-04-25 55 36 26
2009-04-17 37 35 28
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13949
Subject : XFS regression
Submitter : Justin Piszcz <jpiszcz@lucidpixels.com>
Date : 2009-08-08 8:39 (2 days old)
References : http://marc.info/?l=linux-kernel&m=124972079229959&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13945
Subject : Kernel freezes dual pentium-3 system
Submitter : Martin Rogge <marogge@onlinehome.de>
Date : 2009-08-03 16:25 (7 days old)
References : http://marc.info/?l=linux-kernel&m=124931667320530&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13898
Subject : Intel 3945ABG - problems on 2.6.30.X
Submitter : dienet <dienet@poczta.fm>
Date : 2009-07-31 15:17 (10 days old)
References : http://marc.info/?l=linux-kernel&m=124905346729959&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13797
Subject : iBook G4 doesn't suspend since 2ed8d2b3a8
Submitter : Jörg Sommer <joerg@alea.gnuu.de>
Date : 2009-07-18 20:18 (23 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13795
Subject : abnormal boot and no suspend due to 'async' (fastboot)
Submitter : Rafal Kaczynski <fscnoboot@wp.pl>
Date : 2009-07-18 17:19 (23 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13780
Subject : NULL pointer dereference loading powernowk8
Submitter : Kurt Roeckx <kurt@roeckx.be>
Date : 2009-07-15 18:00 (26 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13770
Subject : System freeze on XFS filesystem recovery on an external disk
Submitter : Jean-Luc Coulon <jean.luc.coulon@gmail.com>
Date : 2009-07-14 10:31 (27 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13739
Subject : 2.6.30 leaking keys on console switch
Submitter : Andi Kleen <andi@firstfloor.org>
Date : 2009-07-07 8:44 (34 days old)
References : http://marc.info/?l=linux-kernel&m=124695628924382&w=4
Handled-By : Jiri Kosina <jkosina@suse.cz>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13694
Subject : i915 phantom TV
Submitter : Maciek Józiewicz <mjoziew@gmail.com>
Date : 2009-07-02 12:26 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13682
Subject : The webcam stopped working when upgrading from 2.6.29 to 2.6.30
Submitter : Nathanael Schaeffer <nathanael.schaeffer@gmail.com>
Date : 2009-06-30 13:34 (41 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13660
Subject : Crashes during boot on 2.6.30 / 2.6.31-rc, random programs
Submitter : Joao Correia <joaomiguelcorreia@gmail.com>
Date : 2009-06-27 16:07 (44 days old)
References : http://lkml.org/lkml/2009/6/27/95
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13646
Subject : warn_on tty_io.c, broken bluetooth
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2009-06-19 17:05 (52 days old)
References : http://lkml.org/lkml/2009/6/19/187
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13638
Subject : rt2870 driver is broken for (some) cards
Submitter : jakob gruber <jakob.gruber@kabelnet.at>
Date : 2009-06-27 17:33 (44 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13634
Subject : [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22
Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Date : 2009-06-27 07:02 (44 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13621
Subject : xfs hangs with assertion failed
Submitter : Johannes Engel <jcnengel@googlemail.com>
Date : 2009-06-25 10:07 (46 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13620
Subject : acpi_enforce_resources broken - conflicting i2c module loaded on some EeePCs
Submitter : Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Date : 2009-06-25 08:31 (46 days old)
References : <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-June/002316.html>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13583
Subject : pdflush uses 5% CPU on otherwise idle system
Submitter : Paul Martin <pm@debian.org>
Date : 2009-06-19 13:33 (52 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13581
Subject : ath9k doesn't work with newer kernels
Submitter : Matteo <rootkit85@yahoo.it>
Date : 2009-06-19 12:04 (52 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13564
Subject : random general protection fault at boot time caused by khubd.
Submitter : Pauli <suokkos@gmail.com>
Date : 2009-06-18 12:44 (53 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13558
Subject : Tracelog during resume
Submitter : Cijoml Cijomlovic Cijomlov <cijoml@volny.cz>
Date : 2009-06-17 11:32 (54 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13514
Subject : acer_wmi causes stack corruption
Submitter : Rus <harbour@sfinx.od.ua>
Date : 2009-06-12 08:13 (59 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13512
Subject : D43 on 2.6.30 doesn't suspend anymore
Submitter : Daniel Smolik <marvin@mydatex.cz>
Date : 2009-06-11 20:12 (60 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13502
Subject : GPE storm causes polling mode, which causes /proc/acpi/battery read to take 4 seconds - MacBookPro4,1
Submitter : <sveina@gmail.com>
Date : 2009-06-10 20:04 (61 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13408
Subject : Performance regression in 2.6.30-rc7
Submitter : Diego Calleja <diegocg@gmail.com>
Date : 2009-05-30 18:51 (72 days old)
References : http://lkml.org/lkml/2009/5/30/146
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13407
Subject : adb trackpad disappears after suspend to ram
Submitter : Jan Scholz <scholz@fias.uni-frankfurt.de>
Date : 2009-05-28 7:59 (74 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2ed8d2b3a81bdbb0418301628ccdb008ac9f40b7
References : http://marc.info/?l=linux-kernel&m=124349762314976&w=4
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13401
Subject : pktcdvd writing is really slow with CFQ scheduler (bisected)
Submitter : Laurent Riffard <laurent.riffard@free.fr>
Date : 2009-05-28 18:43 (74 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13374
Subject : reiserfs blocked for more than 120secs
Submitter : Harald Dunkel <harald.dunkel@t-online.de>
Date : 2009-05-23 8:52 (79 days old)
References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4
http://lkml.org/lkml/2009/5/29/389
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13373
Subject : fbcon, intelfb, i915: INFO: possible circular locking dependency detected
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2009-05-23 5:08 (79 days old)
References : http://marc.info/?l=linux-kernel&m=124305538130702&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13362
Subject : rt2x00: slow wifi with correct basic rate bitmap
Submitter : Alejandro Riveira <ariveira@gmail.com>
Date : 2009-05-22 13:32 (80 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13351
Subject : 2.6.30 corrupts my system after suspend resume with readonly mounted hard disk
Submitter : <unggnu@googlemail.com>
Date : 2009-05-20 14:09 (82 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=78a8b35bc7abf8b8333d6f625e08c0f7cc1c3742
Handled-By : Yinghai Lu <yinghai@kernel.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13341
Subject : Random Oops at boot at loading ip6tables rules
Submitter : <patrick@ostenberg.de>
Date : 2009-05-19 09:08 (83 days old)
Handled-By : Rusty Russell <rusty@rustcorp.com.au>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter : Francis Moreau <francis.moro@gmail.com>
Date : 2009-05-03 16:22 (99 days old)
References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13318
Subject : AGP doesn't work anymore on nforce2
Submitter : Karsten Mehrhoff <kawime@gmx.de>
Date : 2009-04-30 8:51 (102 days old)
First-Bad-Commit: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
References : http://marc.info/?l=linux-kernel&m=124108156417560&w=4
Handled-By : Shaohua Li <shaohua.li@intel.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13306
Subject : hibernate slow on _second_ run
Submitter : Johannes Berg <johannes@sipsolutions.net>
Date : 2009-05-14 09:34 (88 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13219
Subject : Intel 440GX: Since kernel 2.6.30-rc1, computers hangs randomly but not with kernel <= 2.6.29.6
Submitter : David Hill <hilld@binarystorm.net>
Date : 2009-05-01 16:57 (101 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13180
Subject : 2.6.30-rc2: WARNING at i915_gem.c for i915_gem_idle
Submitter : Niel Lambrechts <niel.lambrechts@gmail.com>
Date : 2009-04-21 21:35 (111 days old)
References : http://marc.info/?l=linux-kernel&m=124034980819102&w=4
http://lkml.org/lkml/2009/4/27/290
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13109
Subject : High latency on /sys/class/thermal
Submitter : Tiago Simões Batista <tiagosbatista@gmail.com>
Date : 2009-04-11 14:56 (121 days old)
References : http://marc.info/?l=linux-kernel&m=123946182301248&w=4
Handled-By : Zhang Rui <rui.zhang@intel.com>
Alexey Starikovskiy <astarikovskiy@suse.de>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13389
Subject : Warning 'Invalid throttling state, reset' gets displayed when it should not be
Submitter : Frans Pop <elendil@planet.nl>
Date : 2009-05-26 15:24 (76 days old)
Handled-By : Frans Pop <elendil@planet.nl>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=21671
http://bugzilla.kernel.org/attachment.cgi?id=21672
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13319
Subject : Page allocation failures with b43 and p54usb
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2009-04-29 21:01 (103 days old)
References : http://marc.info/?l=linux-kernel&m=124103897101088&w=4
http://lkml.org/lkml/2009/6/7/136
http://lkml.org/lkml/2009/7/26/213
Handled-By : Johannes Berg <johannes@sipsolutions.net>
David Rientjes <rientjes@google.com>
Patch : http://patchwork.kernel.org/patch/37655/
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.29 and 2.6.30, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=13070
Please let me know if there are any Bugzilla entries that should be added to
the list in there.
Thanks,
Rafael
^ permalink raw reply
* [Bug #13328] b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
From: Rafael J. Wysocki @ 2009-08-09 21:10 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Kernel Testers List, Francis Moreau, netdev
In-Reply-To: <YCu3FOC0QrC.A.MaE.RD2fKB@chimera>
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.29 and 2.6.30.
The following bug entry is on the current list of known regressions
introduced between 2.6.29 and 2.6.30. Please verify if it still should
be listed and let me know (either way).
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=13328
Subject : b44: eth0: BUG! Timeout waiting for bit 00000002 of register 42c to clear.
Submitter : Francis Moreau <francis.moro-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2009-05-03 16:22 (99 days old)
References : http://marc.info/?l=linux-kernel&m=124136778012280&w=4
^ permalink raw reply
* Re: [PATCH 14/14] net: use printk_once
From: David Miller @ 2009-08-10 2:52 UTC (permalink / raw)
To: marcin.slusarz; +Cc: linux-kernel, netdev
In-Reply-To: <1249847649-11631-15-git-send-email-marcin.slusarz@gmail.com>
From: Marcin Slusarz <marcin.slusarz@gmail.com>
Date: Sun, 9 Aug 2009 21:54:09 +0200
> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 11/14] drivers/net: use printk_once
From: David Miller @ 2009-08-10 2:52 UTC (permalink / raw)
To: marcin.slusarz; +Cc: linux-kernel, netdev
In-Reply-To: <1249847649-11631-12-git-send-email-marcin.slusarz@gmail.com>
From: Marcin Slusarz <marcin.slusarz@gmail.com>
Date: Sun, 9 Aug 2009 21:54:06 +0200
> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-08-07
From: David Miller @ 2009-08-10 3:49 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20090807183916.GI7545@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 7 Aug 2009 14:39:17 -0400
> Here are a few more late-comers intended for 2.6.31. They are basically
> simple one-liners (or might-as-well-be-one-liners), most fixing potential
> security or crash issues or avoiding potentially obscure bugs.
Pulled, thanks a lot John.
^ permalink raw reply
* Re: [PATCH 0/8] sky2: driver update
From: David Miller @ 2009-08-10 4:09 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20090806161213.148382653@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 06 Aug 2009 09:12:13 -0700
> This undoes the prematurely committed sky2 transmit logic changes
> and applies Mike's later changes.
> Here is a corrected patch stream please apply this to 2.6.31-rc5
I have to pass on this set, too many problems:
1) You didn't provide explicit "From: " lines for patches where
you were not the author Stephen. I could guess from the
Signoff lines but I'd rather not.
2) I can almost swallow the cleanups if they make the bug fix
coming up afterwards to be understood more easily.
But I'm not going to apply patches right now that remove locking
beause it "seems safe" or "should be ok". That's absolutely not
appropriate right now unless it fixes a performance regression
explicitly listed in the formal regression list. This is in
reference to patch #5.
If this is a prerequisite for patch #6 in some way (that's my
guess), please make this more explicit, or even better change
words like "should" (that sounds like "I'm not sure") into
"is" when the commit message describes how the locks are no
longer needed at that spot.
Another idea is to combine #5 and #6 and explain the dependency
in the commit message.
Also, to be honest, this kind of commit count is way too high at this
late stage of the RC series. Nothing in here is super critical,
and none of it (to my knowledge) is in the regression list either.
And I informed you in private that the main reason I kept asking you
to be more responsive over the past month or so to sky2 patches and
bug reports was so that patches trickled in gradually, instead of
being dumped all at once way too late in the RC series.
^ permalink raw reply
* Re: [PATCH] lmc: Read outside array bounds
From: David Miller @ 2009-08-10 4:27 UTC (permalink / raw)
To: roel.kluin; +Cc: khc, netdev, akpm
In-Reply-To: <4A7C401B.7090301@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 07 Aug 2009 16:54:19 +0200
> If dev_alloc_skb() fails on the first iteration of the allocation loop, and we
> break out of the loop, then we end up writing before the start of the array.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
>> First of all, if we allocated at least one buffer we should
>> mark the last one in the code right after this loop.
>>
>> Second of all, we should purge the TX skbs in the next
>> loop even if we could not allocate even one RX buffer.
>>
>> The thing to do is probably to guard the set of "[i-1]" RX ring
>> accesses with a "if (i != 0)" check.
>
> Forgot a bit about this one, but I hope this is what you meant?
It's not correct to limit the TX ring loop by how many RX
ring buffers we've been able to successfully allocate,
that doesn't make any sense.
I'm talking about the second loop which you unexplainably
changed to "for (j = 0; j < i; ..."
I'm not applying this.
^ permalink raw reply
* Re: [patch for 2.6.31? 1/2] MAINTAINERS: update atlx contact info
From: David Miller @ 2009-08-10 4:47 UTC (permalink / raw)
To: akpm; +Cc: netdev, chris.snook, jcliburn, jie.yang
In-Reply-To: <200908062219.n76MJV8L024490@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Thu, 06 Aug 2009 15:19:31 -0700
> From: Chris Snook <chris.snook@gmail.com>
>
> Update MAINTAINERS to reflect my current (non-)affiliation. Anyone
> hiring?
>
> Signed-off-by: Chris Snook <chris.snook@gmail.com>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: additional NETWORKING [GENERAL] and NETWORKING DRIVERS patterns
From: David Miller @ 2009-08-10 4:47 UTC (permalink / raw)
To: joe; +Cc: sposelenov, linux-kernel, wd, netdev, akpm
In-Reply-To: <1249663381.3467.80.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Fri, 07 Aug 2009 09:43:01 -0700
> On Fri, 2009-08-07 at 09:03 -0700, David Miller wrote:
>> From: Sergei Poselenov <sposelenov@emcraft.com>
>> > Unfortunately, received no replies, but the problem still persists.
>> I guarantee you'll get more responses if you send networking bug
>> reports at least CC:'d to netdev@vger.kernel.org
>
> Perhaps this will help get cc's to the right places.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/2] e1000e: fix acquisition of SW/FW/HW semaphore for ICHx parts
From: David Miller @ 2009-08-10 4:47 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20090807174136.31114.96240.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 07 Aug 2009 10:41:37 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> For ICHx parts, write the EXTCNF_CTRL.SWFLAG bit once when trying to
> acquire the SW/FW/HW semaphore instead of multiple times to prevent the
> hardware from having problems (especially for systems with manageability
> enabled), and extend the timeout for the hardware to set the SWFLAG bit.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/2] e1000e: fix potential NVM corruption on ICH9 with 8K bank size
From: David Miller @ 2009-08-10 4:47 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20090807174155.31114.81083.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 07 Aug 2009 10:41:56 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> The bank offset was being incorrectly calculated on ICH9 parts with a bank
> size of 8K (instead of the more common 4K bank) which would cause any NVM
> writes to be done on the wrong address after switching from bank 1 to bank
> 0. Additionally, assume we are meant to use bank 0 if a valid bank is not
> detected, and remove the unnecessary acquisition of the SW/FW/HW semaphore
> when writing to the shadow ram version of the NVM image.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 5/6] [NET] ixp2000/enp2611: don't set non-existent member get_stats
From: David Miller @ 2009-08-10 4:49 UTC (permalink / raw)
To: u.kleine-koenig
Cc: tglx, linux-kernel, linux-rt-users, linux, dbaryshkov, kernel,
netdev
In-Reply-To: <1249677761-19470-5-git-send-email-u.kleine-koenig@pengutronix.de>
From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date: Fri, 7 Aug 2009 22:42:40 +0200
> This fixes a build failure for 2.6.31-rc5 (ARCH=arm, ixp2000_defconfig):
>
> CC drivers/net/ixp2000/enp2611.o
> drivers/net/ixp2000/enp2611.c: In function 'enp2611_init_module':
> drivers/net/ixp2000/enp2611.c:213: error: 'struct net_device' has no member named 'get_stats'
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This is far from the way to fix this, unfortunately.
We need to find a way to propagate this assignment into
the netdev_ops method vector instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] pcnet32: Read buffer overflow
From: David Miller @ 2009-08-10 4:49 UTC (permalink / raw)
To: roel.kluin; +Cc: pcnet32, netdev, akpm
In-Reply-To: <4A7C2B0B.9030508@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Fri, 07 Aug 2009 15:24:27 +0200
> An `options[cards_found]' that equals `sizeof(options_mapping)' is already beyond
> the array.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sctp: fix missing destroy of percpu counter variable in sctp_proc_exit()
From: David Miller @ 2009-08-10 4:49 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, rlaufer
In-Reply-To: <1249658237-9031-1-git-send-email-vladislav.yasevich@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 7 Aug 2009 11:17:17 -0400
> From: Rafael Laufer <rlaufer@cisco.com>
>
> Commit 1748376b6626acf59c24e9592ac67b3fe2a0e026,
> net: Use a percpu_counter for sockets_allocated
>
> added percpu_counter function calls to sctp_proc_init code path, but
> forgot to add them to sctp_proc_exit(). This resulted in a following
> Ooops when performing this test
...
> Signed-off-by: Rafael Laufer <rlaufer@cisco.com>
> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Applied.
^ permalink raw reply
* Re: [PATCH] fec: fix FEC driver packet transmission breakage
From: David Miller @ 2009-08-10 4:51 UTC (permalink / raw)
To: gerg; +Cc: netdev, gerg, s.hauer
In-Reply-To: <200908070358.n773wIxB015388@localhost.localdomain>
From: Greg Ungerer <gerg@snapgear.com>
Date: Fri, 7 Aug 2009 13:58:18 +1000
> fec: fix FEC driver packet transmission breakage
>
> Commit f0b3fbeae11a526c3d308b691684589ee37c359b
In the future, when referencing commits, please also provide the
commit message header line text, in parenthesis, and in quotes, like
this ("the commit message header line"), right after the SHA1 ID.
I've fixed up your commit message, in that way, this time. But
next time I'm going to simply shoot this back to you.
> breaks transmission of
> packets where the skb data buffer is not memory aligned according to
> FEC_ALIGNMENT. It incorrectly passes to dma_sync_single() the buffer
> address directly from the skb, instead of the address calculated for
> use (which may be the skb address or one of the bounce buffers).
>
> It seems there is no use converting the cpu address of the buffer to
> a physical either, since dma_map_single() expects the cpu address and
> will return the dma address to use in the descriptor. So remove the use
> of __pa() on the buffer address as well.
>
> This patch is against 2.6.30-rc5. This breakage is a regression over
> 2.6.30, which does not have this problem.
>
> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Applied.
^ permalink raw reply
* Re: [PATCH] Fix xfrm hash collisions by changing __xfrm4_daddr_saddr_hash to hash addresses with addition
From: David Miller @ 2009-08-10 4:52 UTC (permalink / raw)
To: joamaki; +Cc: netdev
In-Reply-To: <alpine.DEB.1.10.0908071032171.3426@sisapiiri.net.net>
From: Jussi Maki <joamaki@gmail.com>
Date: Fri, 7 Aug 2009 10:38:14 +0300 (EEST)
>
> This patch fixes hash collisions in cases where number
> of entries have incrementing IP source and destination addresses
> from single respective subnets (i.e. 192.168.0.1-172.16.0.1,
> 192.168.0.2-172.16.0.2, and so on.).
>
> Signed-off-by: Jussi Maki <joamaki@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-2.6] can: Fix raw_getname() leak
From: David Miller @ 2009-08-10 4:52 UTC (permalink / raw)
To: oliver; +Cc: eric.dumazet, netdev
In-Reply-To: <4A7BCA5F.9050102@hartkopp.net>
From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Fri, 07 Aug 2009 08:31:59 +0200
> Eric Dumazet wrote:
>> raw_getname() can leak 10 bytes of kernel memory to user
>>
>> (two bytes hole between can_family and can_ifindex,
>> 8 bytes at the end of sockaddr_can structure)
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Acked-by: Oliver Hartkopp <oliver@hartkopp.net>
Applied.
^ permalink raw reply
* Re: [RFC PATCH v1] tun: Cleanup error handling in tun_set_iff()
From: David Miller @ 2009-08-10 4:52 UTC (permalink / raw)
To: ebiederm; +Cc: herbert, paul.moore, netdev
In-Reply-To: <m1k51gqmlp.fsf@fess.ebiederm.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 06 Aug 2009 21:22:42 -0700
> David Miller <davem@davemloft.net> writes:
>
>> From: Herbert Xu <herbert@gondor.apana.org.au>
>> Date: Fri, 7 Aug 2009 10:22:44 +1000
>>
>>> tun: Extend RTNL lock coverage over whole ioctl
>>>
>>> As it is, parts of the ioctl runs under the RTNL and parts of
>>> it do not. The unlocked section is still protected by the BKL,
>>> but there can be subtle races. For example, Eric Biederman and
>>> Paul Moore observed that if two threads tried to create two tun
>>> devices on the same file descriptor, then unexpected results
>>> may occur.
>>>
>>> As there isn't anything in the ioctl that is expected to sleep
>>> indefinitely, we can prevent this from occurring by extending
>>> the RTNL lock coverage.
>>>
>>> This also allows to get rid of the BKL.
>>>
>>> Finally, I changed tun_get_iff to take a tun device in order to
>>> avoid calling tun_put which would dead-lockt as it also tries to
>>> take the RTNL lock.
>>>
>>> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>>
>> This looks good after a quick audit, Eric what say you?
>
> Looks good to me.
Applied, thanks everyone.
^ 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