Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1225167 > unrolled thread

[PATCH 3.12 01/33] mfd: lpc_ich: Assign subdevice ids automatically

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 3.12 01/33] mfd: lpc_ich: Assign subdevice ids automatically Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 06/33] ip_tunnel: fix ipv4 pmtu check to honor inner ip header df Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 27/33] bio: fix argument of __bio_add_page() for max_sectors > 0xffff Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 23/33] rds: fix an integer overflow test in rds_info_getsockopt() Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 09/33] net: pktgen: fix race between pktgen_thread_worker() and kthread_stop() Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 15/33] bridge: mdb: fix double add notification Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 03/33] ipv6: Make MLD packets to only be processed locally Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 21/33] netlink: don't hold mutex in rcu callback when releasing mmapd ring Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 25/33] cifs: Send a logoff request before removing a smb session Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 30/33] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 33/33] PCI: Add VPD function 0 quirk for Intel Ethernet devices Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 28/33] dm cache mq: fix memory allocation failure for large cache devices Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 26/33] lpfc: Fix scsi prep dma buf error. Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 31/33] netfilter: nf_conntrack: don't release a conntrack with non-zero refcnt Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 29/33] aio: fix reqs_available handling Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 32/33] PCI: Add dev_flags bit to access VPD through function 0 Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 24/33] mtip32xx: dynamically allocate buffer in debugfs functions Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:30 +0200
    [PATCH 3.12 18/33] bonding: fix destruction of bond with devices different from arphrd_ether Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 19/33] bonding: correct the MAC address for "follow" fail_over_mac policy Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 11/33] net: call rcu_read_lock early in process_backlog Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 20/33] inet: frags: fix defragmented packet's IP header for af_packet Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 05/33] rtnetlink: verify IFLA_VF_INFO attributes before passing them to driver Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 10/33] net: do not process device backlog during unregistration Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 07/33] net/tipc: initialize security state for new connection socket Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 12/33] net: Clone skb before setting peeked flag Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 04/33] net: graceful exit from netif_alloc_netdev_queues() Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 08/33] bridge: mdb: zero out the local br_ip variable before use Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 14/33] net: Fix skb_set_peeked use-after-free bug Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 13/33] net: Fix skb csum races when peeking Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 17/33] ipv6: lock socket in ip6_datagram_connect() Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
      Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Tilman Schmidt <tilman@imap.cc> - 2015-09-16 02:40 +0200
        Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Peter Hurley <peter@hurleysoftware.com> - 2015-09-16 03:20 +0200
          Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Tilman Schmidt <tilman@imap.cc> - 2015-09-16 13:30 +0200
            Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Peter Hurley <peter@hurleysoftware.com> - 2015-09-17 20:20 +0200
              Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Tilman Schmidt <tilman@imap.cc> - 2015-09-18 14:40 +0200
                Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Peter Hurley <peter@hurleysoftware.com> - 2015-09-21 15:20 +0200
                  Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Tilman Schmidt <tilman@imap.cc> - 2015-09-21 15:40 +0200
                    Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Peter Hurley <peter@hurleysoftware.com> - 2015-09-21 19:00 +0200
                      Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Tilman Schmidt <tilman@imap.cc> - 2015-09-21 19:40 +0200
                  Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when  attaching ser_gigaset Tilman Schmidt <tilman@imap.cc> - 2015-09-21 18:10 +0200
    [PATCH 3.12 22/33] net/mlx4_core: Fix wrong index in propagating port change event to VFs Jiri Slaby <jslaby@suse.cz> - 2015-09-15 16:50 +0200
    [PATCH 3.12 02/33] drm/radeon: fix hotplug race at startup Jiri Slaby <jslaby@suse.cz> - 2015-09-15 17:00 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1225243 — [PATCH 3.12 20/33] inet: frags: fix defragmented packet's IP header for af_packet

From: Edward Hyunkoo Jee <edjee@google.com>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

[ Upstream commit 0848f6428ba3a2e42db124d41ac6f548655735bf ]

When ip_frag_queue() computes positions, it assumes that the passed
sk_buff does not contain L2 headers.

However, when PACKET_FANOUT_FLAG_DEFRAG is used, IP reassembly
functions can be called on outgoing packets that contain L2 headers.

Also, IPv4 checksum is not corrected after reassembly.

Fixes: 7736d33f4262 ("packet: Add pre-defragmentation support for ipv4 fanouts.")
Signed-off-by: Edward Hyunkoo Jee <edjee@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Cc: Jerry Chu <hkchu@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/ipv4/ip_fragment.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 4c1884fed548..4d98a6b80b04 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -356,7 +356,7 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb)
 	ihl = ip_hdrlen(skb);
 
 	/* Determine the position of this fragment. */
-	end = offset + skb->len - ihl;
+	end = offset + skb->len - skb_network_offset(skb) - ihl;
 	err = -EINVAL;
 
 	/* Is this the final fragment? */
@@ -386,7 +386,7 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb)
 		goto err;
 
 	err = -ENOMEM;
-	if (pskb_pull(skb, ihl) == NULL)
+	if (!pskb_pull(skb, skb_network_offset(skb) + ihl))
 		goto err;
 
 	err = pskb_trim_rcsum(skb, end - offset);
@@ -627,6 +627,9 @@ static int ip_frag_reasm(struct ipq *qp, struct sk_buff *prev,
 	iph->frag_off = qp->q.max_size ? htons(IP_DF) : 0;
 	iph->tot_len = htons(len);
 	iph->tos |= ecn;
+
+	ip_send_check(iph);
+
 	IP_INC_STATS_BH(net, IPSTATS_MIB_REASMOKS);
 	qp->q.fragments = NULL;
 	qp->q.fragments_tail = NULL;
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225244 — [PATCH 3.12 05/33] rtnetlink: verify IFLA_VF_INFO attributes before passing them to driver

From: Daniel Borkmann <daniel@iogearbox.net>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

[ Upstream commit 4f7d2cdfdde71ffe962399b7020c674050329423 ]

Jason Gunthorpe reported that since commit c02db8c6290b ("rtnetlink: make
SR-IOV VF interface symmetric"), we don't verify IFLA_VF_INFO attributes
anymore with respect to their policy, that is, ifla_vfinfo_policy[].

Before, they were part of ifla_policy[], but they have been nested since
placed under IFLA_VFINFO_LIST, that contains the attribute IFLA_VF_INFO,
which is another nested attribute for the actual VF attributes such as
IFLA_VF_MAC, IFLA_VF_VLAN, etc.

Despite the policy being split out from ifla_policy[] in this commit,
it's never applied anywhere. nla_for_each_nested() only does basic nla_ok()
testing for struct nlattr, but it doesn't know about the data context and
their requirements.

Fix, on top of Jason's initial work, does 1) parsing of the attributes
with the right policy, and 2) using the resulting parsed attribute table
from 1) instead of the nla_for_each_nested() loop (just like we used to
do when still part of ifla_policy[]).

Reference: http://thread.gmane.org/gmane.linux.network/368913
Fixes: c02db8c6290b ("rtnetlink: make SR-IOV VF interface symmetric")
Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
Cc: Greg Rose <gregory.v.rose@intel.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Rony Efraim <ronye@mellanox.com>
Cc: Vlad Zolotarov <vladz@cloudius-systems.com>
Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Cc: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Vlad Zolotarov <vladz@cloudius-systems.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/core/rtnetlink.c | 128 ++++++++++++++++++++++++++-------------------------
 1 file changed, 65 insertions(+), 63 deletions(-)

diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 76cc27f3f991..fd3a16e45dd9 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1197,10 +1197,6 @@ static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
 	[IFLA_INFO_DATA]	= { .type = NLA_NESTED },
 };
 
-static const struct nla_policy ifla_vfinfo_policy[IFLA_VF_INFO_MAX+1] = {
-	[IFLA_VF_INFO]		= { .type = NLA_NESTED },
-};
-
 static const struct nla_policy ifla_vf_policy[IFLA_VF_MAX+1] = {
 	[IFLA_VF_MAC]		= { .len = sizeof(struct ifla_vf_mac) },
 	[IFLA_VF_VLAN]		= { .len = sizeof(struct ifla_vf_vlan) },
@@ -1274,67 +1270,66 @@ static int validate_linkmsg(struct net_device *dev, struct nlattr *tb[])
 	return 0;
 }
 
-static int do_setvfinfo(struct net_device *dev, struct nlattr *attr)
+static int do_setvfinfo(struct net_device *dev, struct nlattr **tb)
 {
-	int rem, err = -EINVAL;
-	struct nlattr *vf;
 	const struct net_device_ops *ops = dev->netdev_ops;
+	int err = -EINVAL;
 
-	nla_for_each_nested(vf, attr, rem) {
-		switch (nla_type(vf)) {
-		case IFLA_VF_MAC: {
-			struct ifla_vf_mac *ivm;
-			ivm = nla_data(vf);
-			err = -EOPNOTSUPP;
-			if (ops->ndo_set_vf_mac)
-				err = ops->ndo_set_vf_mac(dev, ivm->vf,
-							  ivm->mac);
-			break;
-		}
-		case IFLA_VF_VLAN: {
-			struct ifla_vf_vlan *ivv;
-			ivv = nla_data(vf);
-			err = -EOPNOTSUPP;
-			if (ops->ndo_set_vf_vlan)
-				err = ops->ndo_set_vf_vlan(dev, ivv->vf,
-							   ivv->vlan,
-							   ivv->qos);
-			break;
-		}
-		case IFLA_VF_TX_RATE: {
-			struct ifla_vf_tx_rate *ivt;
-			ivt = nla_data(vf);
-			err = -EOPNOTSUPP;
-			if (ops->ndo_set_vf_tx_rate)
-				err = ops->ndo_set_vf_tx_rate(dev, ivt->vf,
-							      ivt->rate);
-			break;
-		}
-		case IFLA_VF_SPOOFCHK: {
-			struct ifla_vf_spoofchk *ivs;
-			ivs = nla_data(vf);
-			err = -EOPNOTSUPP;
-			if (ops->ndo_set_vf_spoofchk)
-				err = ops->ndo_set_vf_spoofchk(dev, ivs->vf,
-							       ivs->setting);
-			break;
-		}
-		case IFLA_VF_LINK_STATE: {
-			struct ifla_vf_link_state *ivl;
-			ivl = nla_data(vf);
-			err = -EOPNOTSUPP;
-			if (ops->ndo_set_vf_link_state)
-				err = ops->ndo_set_vf_link_state(dev, ivl->vf,
-								 ivl->link_state);
-			break;
-		}
-		default:
-			err = -EINVAL;
-			break;
-		}
-		if (err)
-			break;
+	if (tb[IFLA_VF_MAC]) {
+		struct ifla_vf_mac *ivm = nla_data(tb[IFLA_VF_MAC]);
+
+		err = -EOPNOTSUPP;
+		if (ops->ndo_set_vf_mac)
+			err = ops->ndo_set_vf_mac(dev, ivm->vf,
+						  ivm->mac);
+		if (err < 0)
+			return err;
+	}
+
+	if (tb[IFLA_VF_VLAN]) {
+		struct ifla_vf_vlan *ivv = nla_data(tb[IFLA_VF_VLAN]);
+
+		err = -EOPNOTSUPP;
+		if (ops->ndo_set_vf_vlan)
+			err = ops->ndo_set_vf_vlan(dev, ivv->vf, ivv->vlan,
+						   ivv->qos);
+		if (err < 0)
+			return err;
+	}
+
+	if (tb[IFLA_VF_TX_RATE]) {
+		struct ifla_vf_tx_rate *ivt = nla_data(tb[IFLA_VF_TX_RATE]);
+
+		err = -EOPNOTSUPP;
+		if (ops->ndo_set_vf_tx_rate)
+			err = ops->ndo_set_vf_tx_rate(dev, ivt->vf,
+						      ivt->rate);
+		if (err < 0)
+			return err;
 	}
+
+	if (tb[IFLA_VF_SPOOFCHK]) {
+		struct ifla_vf_spoofchk *ivs = nla_data(tb[IFLA_VF_SPOOFCHK]);
+
+		err = -EOPNOTSUPP;
+		if (ops->ndo_set_vf_spoofchk)
+			err = ops->ndo_set_vf_spoofchk(dev, ivs->vf,
+						       ivs->setting);
+		if (err < 0)
+			return err;
+	}
+
+	if (tb[IFLA_VF_LINK_STATE]) {
+		struct ifla_vf_link_state *ivl = nla_data(tb[IFLA_VF_LINK_STATE]);
+
+		err = -EOPNOTSUPP;
+		if (ops->ndo_set_vf_link_state)
+			err = ops->ndo_set_vf_link_state(dev, ivl->vf,
+							 ivl->link_state);
+		if (err < 0)
+			return err;
+	}
+
 	return err;
 }
 
@@ -1517,14 +1512,21 @@ static int do_setlink(const struct sk_buff *skb,
 	}
 
 	if (tb[IFLA_VFINFO_LIST]) {
+		struct nlattr *vfinfo[IFLA_VF_MAX + 1];
 		struct nlattr *attr;
 		int rem;
+
 		nla_for_each_nested(attr, tb[IFLA_VFINFO_LIST], rem) {
-			if (nla_type(attr) != IFLA_VF_INFO) {
+			if (nla_type(attr) != IFLA_VF_INFO ||
+			    nla_len(attr) < NLA_HDRLEN) {
 				err = -EINVAL;
 				goto errout;
 			}
-			err = do_setvfinfo(dev, attr);
+			err = nla_parse_nested(vfinfo, IFLA_VF_MAX, attr,
+					       ifla_vf_policy);
+			if (err < 0)
+				goto errout;
+			err = do_setvfinfo(dev, vfinfo);
 			if (err < 0)
 				goto errout;
 			modified = 1;
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225247 — [PATCH 3.12 10/33] net: do not process device backlog during unregistration

From: Julian Anastasov <ja@ssi.bg>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

[ Upstream commit e9e4dd3267d0c5234c5c0f47440456b10875dec9 ]

commit 381c759d9916 ("ipv4: Avoid crashing in ip_error")
fixes a problem where processed packet comes from device
with destroyed inetdev (dev->ip_ptr). This is not expected
because inetdev_destroy is called in NETDEV_UNREGISTER
phase and packets should not be processed after
dev_close_many() and synchronize_net(). Above fix is still
required because inetdev_destroy can be called for other
reasons. But it shows the real problem: backlog can keep
packets for long time and they do not hold reference to
device. Such packets are then delivered to upper levels
at the same time when device is unregistered.
Calling flush_backlog after NETDEV_UNREGISTER_FINAL still
accounts all packets from backlog but before that some packets
continue to be delivered to upper levels long after the
synchronize_net call which is supposed to wait the last
ones. Also, as Eric pointed out, processed packets, mostly
from other devices, can continue to add new packets to backlog.

Fix the problem by moving flush_backlog early, after the
device driver is stopped and before the synchronize_net() call.
Then use netif_running check to make sure we do not add more
packets to backlog. We have to do it in enqueue_to_backlog
context when the local IRQ is disabled. As result, after the
flush_backlog and synchronize_net sequence all packets
should be accounted.

Thanks to Eric W. Biederman for the test script and his
valuable feedback!

Reported-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Fixes: 6e583ce5242f ("net: eliminate refcounting in backlog queue")
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/core/dev.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 5a407f0f1c2d..89c6134a979d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3193,6 +3193,8 @@ static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
 	local_irq_save(flags);
 
 	rps_lock(sd);
+	if (!netif_running(skb->dev))
+		goto drop;
 	qlen = skb_queue_len(&sd->input_pkt_queue);
 	if (qlen <= netdev_max_backlog && !skb_flow_limit(skb, qlen)) {
 		if (skb_queue_len(&sd->input_pkt_queue)) {
@@ -3214,6 +3216,7 @@ enqueue:
 		goto enqueue;
 	}
 
+drop:
 	sd->dropped++;
 	rps_unlock(sd);
 
@@ -5302,6 +5305,7 @@ static void rollback_registered_many(struct list_head *head)
 		unlist_netdevice(dev);
 
 		dev->reg_state = NETREG_UNREGISTERING;
+		on_each_cpu(flush_backlog, dev, 1);
 	}
 
 	synchronize_net();
@@ -5918,8 +5922,6 @@ void netdev_run_todo(void)
 
 		dev->reg_state = NETREG_UNREGISTERED;
 
-		on_each_cpu(flush_backlog, dev, 1);
-
 		netdev_wait_allrefs(dev);
 
 		/* paranoia */
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225248 — [PATCH 3.12 07/33] net/tipc: initialize security state for new connection socket

From: Stephen Smalley <sds@tycho.nsa.gov>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

[ Upstream commit fdd75ea8df370f206a8163786e7470c1277a5064 ]

Calling connect() with an AF_TIPC socket would trigger a series
of error messages from SELinux along the lines of:
SELinux: Invalid class 0
type=AVC msg=audit(1434126658.487:34500): avc:  denied  { <unprintable> }
  for pid=292 comm="kworker/u16:5" scontext=system_u:system_r:kernel_t:s0
  tcontext=system_u:object_r:unlabeled_t:s0 tclass=<unprintable>
  permissive=0

This was due to a failure to initialize the security state of the new
connection sock by the tipc code, leaving it with junk in the security
class field and an unlabeled secid.  Add a call to security_sk_clone()
to inherit the security state from the parent socket.

Reported-by: Tim Shearer <tim.shearer@overturenetworks.com>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: Paul Moore <paul@paul-moore.com>
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/tipc/socket.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index dffdbeac18ca..d1233088f953 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
@@ -1607,6 +1607,7 @@ static int accept(struct socket *sock, struct socket *new_sock, int flags)
 	res = tipc_sk_create(sock_net(sock->sk), new_sock, 0, 1);
 	if (res)
 		goto exit;
+	security_sk_clone(sock->sk, new_sock->sk);
 
 	new_sk = new_sock->sk;
 	new_tsock = tipc_sk(new_sk);
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225249 — [PATCH 3.12 12/33] net: Clone skb before setting peeked flag

From: Herbert Xu <herbert@gondor.apana.org.au>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

[ Upstream commit 738ac1ebb96d02e0d23bc320302a6ea94c612dec ]

Shared skbs must not be modified and this is crucial for broadcast
and/or multicast paths where we use it as an optimisation to avoid
unnecessary cloning.

The function skb_recv_datagram breaks this rule by setting peeked
without cloning the skb first.  This causes funky races which leads
to double-free.

This patch fixes this by cloning the skb and replacing the skb
in the list when setting skb->peeked.

Fixes: a59322be07c9 ("[UDP]: Only increment counter on first peek/recv")
Reported-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/core/datagram.c | 41 ++++++++++++++++++++++++++++++++++++++---
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/net/core/datagram.c b/net/core/datagram.c
index af814e764206..005131e3ff4c 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -130,6 +130,35 @@ out_noerr:
 	goto out;
 }
 
+static int skb_set_peeked(struct sk_buff *skb)
+{
+	struct sk_buff *nskb;
+
+	if (skb->peeked)
+		return 0;
+
+	/* We have to unshare an skb before modifying it. */
+	if (!skb_shared(skb))
+		goto done;
+
+	nskb = skb_clone(skb, GFP_ATOMIC);
+	if (!nskb)
+		return -ENOMEM;
+
+	skb->prev->next = nskb;
+	skb->next->prev = nskb;
+	nskb->prev = skb->prev;
+	nskb->next = skb->next;
+
+	consume_skb(skb);
+	skb = nskb;
+
+done:
+	skb->peeked = 1;
+
+	return 0;
+}
+
 /**
  *	__skb_recv_datagram - Receive a datagram skbuff
  *	@sk: socket
@@ -164,7 +193,9 @@ out_noerr:
 struct sk_buff *__skb_recv_datagram(struct sock *sk, unsigned int flags,
 				    int *peeked, int *off, int *err)
 {
+	struct sk_buff_head *queue = &sk->sk_receive_queue;
 	struct sk_buff *skb, *last;
+	unsigned long cpu_flags;
 	long timeo;
 	/*
 	 * Caller is allowed not to check sk->sk_err before skb_recv_datagram()
@@ -183,8 +214,6 @@ struct sk_buff *__skb_recv_datagram(struct sock *sk, unsigned int flags,
 		 * Look at current nfs client by the way...
 		 * However, this function was correct in any case. 8)
 		 */
-		unsigned long cpu_flags;
-		struct sk_buff_head *queue = &sk->sk_receive_queue;
 		int _off = *off;
 
 		last = (struct sk_buff *)queue;
@@ -198,7 +227,11 @@ struct sk_buff *__skb_recv_datagram(struct sock *sk, unsigned int flags,
 					_off -= skb->len;
 					continue;
 				}
-				skb->peeked = 1;
+
+				error = skb_set_peeked(skb);
+				if (error)
+					goto unlock_err;
+
 				atomic_inc(&skb->users);
 			} else
 				__skb_unlink(skb, queue);
@@ -222,6 +255,8 @@ struct sk_buff *__skb_recv_datagram(struct sock *sk, unsigned int flags,
 
 	return NULL;
 
+unlock_err:
+	spin_unlock_irqrestore(&queue->lock, cpu_flags);
 no_packet:
 	*err = error;
 	return NULL;
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225250 — [PATCH 3.12 04/33] net: graceful exit from netif_alloc_netdev_queues()

From: Eric Dumazet <edumazet@google.com>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

[ Upstream commit d339727c2b1a10f25e6636670ab6e1841170e328 ]

User space can crash kernel with

ip link add ifb10 numtxqueues 100000 type ifb

We must replace a BUG_ON() by proper test and return -EINVAL for
crazy values.

Fixes: 60877a32bce00 ("net: allow large number of tx queues")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/core/dev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 3ca487e14080..5a407f0f1c2d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5559,7 +5559,8 @@ static int netif_alloc_netdev_queues(struct net_device *dev)
 	struct netdev_queue *tx;
 	size_t sz = count * sizeof(*tx);
 
-	BUG_ON(count < 1 || count > 0xffff);
+	if (count < 1 || count > 0xffff)
+		return -EINVAL;
 
 	tx = kzalloc(sz, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
 	if (!tx) {
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225253 — [PATCH 3.12 08/33] bridge: mdb: zero out the local br_ip variable before use

From: Nikolay Aleksandrov <razor@blackwall.org>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

[ Upstream commit f1158b74e54f2e2462ba5e2f45a118246d9d5b43 ]

Since commit b0e9a30dd669 ("bridge: Add vlan id to multicast groups")
there's a check in br_ip_equal() for a matching vlan id, but the mdb
functions were not modified to use (or at least zero it) so when an
entry was added it would have a garbage vlan id (from the local br_ip
variable in __br_mdb_add/del) and this would prevent it from being
matched and also deleted. So zero out the whole local ip var to protect
ourselves from future changes and also to fix the current bug, since
there's no vlan id support in the mdb uapi - use always vlan id 0.
Example before patch:
root@debian:~# bridge mdb add dev br0 port eth1 grp 239.0.0.1 permanent
root@debian:~# bridge mdb
dev br0 port eth1 grp 239.0.0.1 permanent
root@debian:~# bridge mdb del dev br0 port eth1 grp 239.0.0.1 permanent
RTNETLINK answers: Invalid argument

After patch:
root@debian:~# bridge mdb add dev br0 port eth1 grp 239.0.0.1 permanent
root@debian:~# bridge mdb
dev br0 port eth1 grp 239.0.0.1 permanent
root@debian:~# bridge mdb del dev br0 port eth1 grp 239.0.0.1 permanent
root@debian:~# bridge mdb

Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Fixes: b0e9a30dd669 ("bridge: Add vlan id to multicast groups")
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/bridge/br_mdb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c
index b7b1914dfa25..13421bf464c0 100644
--- a/net/bridge/br_mdb.c
+++ b/net/bridge/br_mdb.c
@@ -370,6 +370,7 @@ static int __br_mdb_add(struct net *net, struct net_bridge *br,
 	if (!p || p->br != br || p->state == BR_STATE_DISABLED)
 		return -EINVAL;
 
+	memset(&ip, 0, sizeof(ip));
 	ip.proto = entry->addr.proto;
 	if (ip.proto == htons(ETH_P_IP))
 		ip.u.ip4 = entry->addr.u.ip4;
@@ -416,6 +417,7 @@ static int __br_mdb_del(struct net_bridge *br, struct br_mdb_entry *entry)
 	if (!netif_running(br->dev) || br->multicast_disabled)
 		return -EINVAL;
 
+	memset(&ip, 0, sizeof(ip));
 	ip.proto = entry->addr.proto;
 	if (ip.proto == htons(ETH_P_IP)) {
 		if (timer_pending(&br->ip4_querier.timer))
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225255 — [PATCH 3.12 14/33] net: Fix skb_set_peeked use-after-free bug

From: Herbert Xu <herbert@gondor.apana.org.au>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

[ Upstream commit a0a2a6602496a45ae838a96db8b8173794b5d398 ]

The commit 738ac1ebb96d02e0d23bc320302a6ea94c612dec ("net: Clone
skb before setting peeked flag") introduced a use-after-free bug
in skb_recv_datagram.  This is because skb_set_peeked may create
a new skb and free the existing one.  As it stands the caller will
continue to use the old freed skb.

This patch fixes it by making skb_set_peeked return the new skb
(or the old one if unchanged).

Fixes: 738ac1ebb96d ("net: Clone skb before setting peeked flag")
Reported-by: Brenden Blanco <bblanco@plumgrid.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Brenden Blanco <bblanco@plumgrid.com>
Reviewed-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/core/datagram.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/net/core/datagram.c b/net/core/datagram.c
index a22ec6a763fc..98e3d61e7476 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -130,12 +130,12 @@ out_noerr:
 	goto out;
 }
 
-static int skb_set_peeked(struct sk_buff *skb)
+static struct sk_buff *skb_set_peeked(struct sk_buff *skb)
 {
 	struct sk_buff *nskb;
 
 	if (skb->peeked)
-		return 0;
+		return skb;
 
 	/* We have to unshare an skb before modifying it. */
 	if (!skb_shared(skb))
@@ -143,7 +143,7 @@ static int skb_set_peeked(struct sk_buff *skb)
 
 	nskb = skb_clone(skb, GFP_ATOMIC);
 	if (!nskb)
-		return -ENOMEM;
+		return ERR_PTR(-ENOMEM);
 
 	skb->prev->next = nskb;
 	skb->next->prev = nskb;
@@ -156,7 +156,7 @@ static int skb_set_peeked(struct sk_buff *skb)
 done:
 	skb->peeked = 1;
 
-	return 0;
+	return skb;
 }
 
 /**
@@ -228,8 +228,9 @@ struct sk_buff *__skb_recv_datagram(struct sock *sk, unsigned int flags,
 					continue;
 				}
 
-				error = skb_set_peeked(skb);
-				if (error)
+				skb = skb_set_peeked(skb);
+				error = PTR_ERR(skb);
+				if (IS_ERR(skb))
 					goto unlock_err;
 
 				atomic_inc(&skb->users);
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225256 — [PATCH 3.12 13/33] net: Fix skb csum races when peeking

From: Herbert Xu <herbert@gondor.apana.org.au>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

[ Upstream commit 89c22d8c3b278212eef6a8cc66b570bc840a6f5a ]

When we calculate the checksum on the recv path, we store the
result in the skb as an optimisation in case we need the checksum
again down the line.

This is in fact bogus for the MSG_PEEK case as this is done without
any locking.  So multiple threads can peek and then store the result
to the same skb, potentially resulting in bogus skb states.

This patch fixes this by only storing the result if the skb is not
shared.  This preserves the optimisations for the few cases where
it can be done safely due to locking or other reasons, e.g., SIOCINQ.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/core/datagram.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/core/datagram.c b/net/core/datagram.c
index 005131e3ff4c..a22ec6a763fc 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -777,7 +777,8 @@ __sum16 __skb_checksum_complete_head(struct sk_buff *skb, int len)
 	if (likely(!sum)) {
 		if (unlikely(skb->ip_summed == CHECKSUM_COMPLETE))
 			netdev_rx_csum_fault(skb->dev);
-		skb->ip_summed = CHECKSUM_UNNECESSARY;
+		if (!skb_shared(skb))
+			skb->ip_summed = CHECKSUM_UNNECESSARY;
 	}
 	return sum;
 }
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225262 — [PATCH 3.12 17/33] ipv6: lock socket in ip6_datagram_connect()

From: Eric Dumazet <edumazet@google.com>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

[ Upstream commit 03645a11a570d52e70631838cb786eb4253eb463 ]

ip6_datagram_connect() is doing a lot of socket changes without
socket being locked.

This looks wrong, at least for udp_lib_rehash() which could corrupt
lists because of concurrent udp_sk(sk)->udp_portaddr_hash accesses.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 include/net/ip.h    |  1 +
 net/ipv4/datagram.c | 16 ++++++++++++----
 net/ipv6/datagram.c | 20 +++++++++++++++-----
 3 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/include/net/ip.h b/include/net/ip.h
index 1b1269e13596..553c07514a05 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -141,6 +141,7 @@ static inline struct sk_buff *ip_finish_skb(struct sock *sk, struct flowi4 *fl4)
 }
 
 /* datagram.c */
+int __ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len);
 extern int		ip4_datagram_connect(struct sock *sk, 
 					     struct sockaddr *uaddr, int addr_len);
 
diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
index 5f3dc1df04bf..291b0821d1ac 100644
--- a/net/ipv4/datagram.c
+++ b/net/ipv4/datagram.c
@@ -20,7 +20,7 @@
 #include <net/route.h>
 #include <net/tcp_states.h>
 
-int ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
+int __ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
 {
 	struct inet_sock *inet = inet_sk(sk);
 	struct sockaddr_in *usin = (struct sockaddr_in *) uaddr;
@@ -39,8 +39,6 @@ int ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
 
 	sk_dst_reset(sk);
 
-	lock_sock(sk);
-
 	oif = sk->sk_bound_dev_if;
 	saddr = inet->inet_saddr;
 	if (ipv4_is_multicast(usin->sin_addr.s_addr)) {
@@ -81,9 +79,19 @@ int ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
 	sk_dst_set(sk, &rt->dst);
 	err = 0;
 out:
-	release_sock(sk);
 	return err;
 }
+EXPORT_SYMBOL(__ip4_datagram_connect);
+
+int ip4_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
+{
+	int res;
+
+	lock_sock(sk);
+	res = __ip4_datagram_connect(sk, uaddr, addr_len);
+	release_sock(sk);
+	return res;
+}
 EXPORT_SYMBOL(ip4_datagram_connect);
 
 /* Because UDP xmit path can manipulate sk_dst_cache without holding
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 9f9ad99fcfdd..da44cb4f51d1 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -40,7 +40,7 @@ static bool ipv6_mapped_addr_any(const struct in6_addr *a)
 	return ipv6_addr_v4mapped(a) && (a->s6_addr32[3] == 0);
 }
 
-int ip6_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
+static int __ip6_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
 {
 	struct sockaddr_in6	*usin = (struct sockaddr_in6 *) uaddr;
 	struct inet_sock      	*inet = inet_sk(sk);
@@ -56,7 +56,7 @@ int ip6_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
 	if (usin->sin6_family == AF_INET) {
 		if (__ipv6_only_sock(sk))
 			return -EAFNOSUPPORT;
-		err = ip4_datagram_connect(sk, uaddr, addr_len);
+		err = __ip4_datagram_connect(sk, uaddr, addr_len);
 		goto ipv4_connected;
 	}
 
@@ -99,9 +99,9 @@ int ip6_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
 		sin.sin_addr.s_addr = daddr->s6_addr32[3];
 		sin.sin_port = usin->sin6_port;
 
-		err = ip4_datagram_connect(sk,
-					   (struct sockaddr *) &sin,
-					   sizeof(sin));
+		err = __ip4_datagram_connect(sk,
+					     (struct sockaddr *) &sin,
+					     sizeof(sin));
 
 ipv4_connected:
 		if (err)
@@ -204,6 +204,16 @@ out:
 	fl6_sock_release(flowlabel);
 	return err;
 }
+
+int ip6_datagram_connect(struct sock *sk, struct sockaddr *uaddr, int addr_len)
+{
+	int res;
+
+	lock_sock(sk);
+	res = __ip6_datagram_connect(sk, uaddr, addr_len);
+	release_sock(sk);
+	return res;
+}
 EXPORT_SYMBOL_GPL(ip6_datagram_connect);
 
 void ipv6_icmp_error(struct sock *sk, struct sk_buff *skb, int err,
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225263 — [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

From: Tilman Schmidt <tilman@imap.cc>

3.12-stable review patch.  If anyone has any objections, please let me know.

===============

[ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ]

Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
first merged in kernel release 3.10, caused the following regression
in the Gigaset M101 driver:

Before that commit, when closing the N_TTY line discipline in
preparation to switching to N_GIGASET_M101, receive_room would be
reset to a non-zero value by the call to n_tty_flush_buffer() in
n_tty's close method. With the removal of that call, receive_room
might be left at zero, blocking data reception on the serial line.

The present patch fixes that regression by setting receive_room
to an appropriate value in the ldisc open method.

Fixes: 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc")
Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/isdn/gigaset/ser-gigaset.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/isdn/gigaset/ser-gigaset.c b/drivers/isdn/gigaset/ser-gigaset.c
index 8c91fd5eb6fd..3ac9c4194814 100644
--- a/drivers/isdn/gigaset/ser-gigaset.c
+++ b/drivers/isdn/gigaset/ser-gigaset.c
@@ -524,9 +524,18 @@ gigaset_tty_open(struct tty_struct *tty)
 	cs->hw.ser->tty = tty;
 	atomic_set(&cs->hw.ser->refcnt, 1);
 	init_completion(&cs->hw.ser->dead_cmp);
-
 	tty->disc_data = cs;
 
+	/* Set the amount of data we're willing to receive per call
+	 * from the hardware driver to half of the input buffer size
+	 * to leave some reserve.
+	 * Note: We don't do flow control towards the hardware driver.
+	 * If more data is received than will fit into the input buffer,
+	 * it will be dropped and an error will be logged. This should
+	 * never happen as the device is slow and the buffer size ample.
+	 */
+	tty->receive_room = RBUFSIZE/2;
+
 	/* OK.. Initialization of the datastructures and the HW is done.. Now
 	 * startup system and notify the LL that we are ready to run
 	 */
-- 
2.5.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225633 — Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

[Multipart message — attachments visible in raw view] — view raw

Am 16.09.2015 um 01:08 schrieb Peter Hurley:
> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby <jslaby@suse.cz
> <mailto:jslaby@suse.cz>> wrote:
> 
>     From: Tilman Schmidt <tilman@imap.cc>
> 
>     3.12-stable review patch.  If anyone has any objections, please let
>     me know.
> 
>     ===============
> 
>     [ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ]
> 
>     Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
>     first merged in kernel release 3.10, caused the following regression
>     in the Gigaset M101 driver:
> 
> 
> Again, I'll just note my objection to this commit log.
> 
> This driver was always broken because it never initialized
> tty->receive_room,
> but rather relied on common but not guaranteed circumstances to
> function.
> 
> The commit noted simply made the underlying bug more evident, but the
> root cause was from the original merge commit of this driver.

I must admit I still don't understand that objection. The meaning of the
term "regression" is simply that something which previously worked
stopped working. It doesn't imply any statement about the root cause.

The ser-gigaset driver worked before the introduction of commit
79901317ce80. It didn't work anymore after the introduction of that
commit. So it is correct, and does not contradict your statements above
in any way, to state that commit introduced the described regression.

-- 
Tilman Schmidt                              E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

[toc] | [prev] | [next] | [standalone]

#1225652 — Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

On Tue, Sep 15, 2015 at 8:37 PM, Tilman Schmidt <tilman@imap.cc> wrote:
> Am 16.09.2015 um 01:08 schrieb Peter Hurley:
>> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby <jslaby@suse.cz
>> <mailto:jslaby@suse.cz>> wrote:
>>
>>     From: Tilman Schmidt <tilman@imap.cc>
>>
>>     3.12-stable review patch.  If anyone has any objections, please let
>>     me know.
>>
>>     ===============
>>
>>     [ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ]
>>
>>     Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
>>     first merged in kernel release 3.10, caused the following regression
>>     in the Gigaset M101 driver:
>>
>>
>> Again, I'll just note my objection to this commit log.
>>
>> This driver was always broken because it never initialized
>> tty->receive_room,
>> but rather relied on common but not guaranteed circumstances to
>> function.
>>
>> The commit noted simply made the underlying bug more evident, but the
>> root cause was from the original merge commit of this driver.
>
> I must admit I still don't understand that objection. The meaning of the
> term "regression" is simply that something which previously worked
> stopped working. It doesn't imply any statement about the root cause.
>
> The ser-gigaset driver worked before the introduction of commit
> 79901317ce80. It didn't work anymore after the introduction of that
> commit. So it is correct, and does not contradict your statements above
> in any way, to state that commit introduced the described regression.

By asserting that commit 79901317ce80 caused the regression, you're
claiming that this fix is unnecessary for kernel versions prior to 3.10

Are you certain that no other sequence of state leads to the same
condition (and thus requiring the same fix) in earlier kernel versions?

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1226019 — Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

[Multipart message — attachments visible in raw view] — view raw

Am 16.09.2015 um 03:18 schrieb Peter Hurley:
> On Tue, Sep 15, 2015 at 8:37 PM, Tilman Schmidt <tilman@imap.cc> wrote:
>> Am 16.09.2015 um 01:08 schrieb Peter Hurley:
>>> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>>>
>>>     From: Tilman Schmidt <tilman@imap.cc>
>>>
>>>     3.12-stable review patch.  If anyone has any objections, please let
>>>     me know.
>>>
>>>     ===============
>>>
>>>     [ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ]
>>>
>>>     Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
>>>     first merged in kernel release 3.10, caused the following regression
>>>     in the Gigaset M101 driver:
>>>
>>>
>>> Again, I'll just note my objection to this commit log.
>>>
>>> This driver was always broken because it never initialized
>>> tty->receive_room,
>>> but rather relied on common but not guaranteed circumstances to
>>> function.
>>>
>>> The commit noted simply made the underlying bug more evident, but the
>>> root cause was from the original merge commit of this driver.
>>
>> I must admit I still don't understand that objection. The meaning of the
>> term "regression" is simply that something which previously worked
>> stopped working. It doesn't imply any statement about the root cause.
>>
>> The ser-gigaset driver worked before the introduction of commit
>> 79901317ce80. It didn't work anymore after the introduction of that
>> commit. So it is correct, and does not contradict your statements above
>> in any way, to state that commit introduced the described regression.
> 
> By asserting that commit 79901317ce80 caused the regression, you're
> claiming that this fix is unnecessary for kernel versions prior to 3.10

Correct.

> Are you certain that no other sequence of state leads to the same
> condition (and thus requiring the same fix) in earlier kernel versions?

Reasonably certain, yes, for three reasons:
- There where no reports of that problem before 3.10.
- My own tests did never encounter that condition, and even after being
made aware of it I was not able to come up with a test that would
provoke it with a kernel version before 3.10.
- The requirement for line disciplines to set receive_room wasn't (and
btw still isn't) documented anywhere, so it's unlikely anything actively
relied on it.

But if you want to propose that patch for inclusion in earlier stable
releases I won't oppose it.

-- 
Tilman Schmidt                              E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

[toc] | [prev] | [next] | [standalone]

#1227292 — Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

On Wed, Sep 16, 2015 at 7:26 AM, Tilman Schmidt <tilman@imap.cc> wrote:
> Am 16.09.2015 um 03:18 schrieb Peter Hurley:
>> On Tue, Sep 15, 2015 at 8:37 PM, Tilman Schmidt <tilman@imap.cc> wrote:
>>> Am 16.09.2015 um 01:08 schrieb Peter Hurley:
>>>> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>>>>
>>>>     From: Tilman Schmidt <tilman@imap.cc>
>>>>
>>>>     3.12-stable review patch.  If anyone has any objections, please let
>>>>     me know.
>>>>
>>>>     ===============
>>>>
>>>>     [ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ]
>>>>
>>>>     Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
>>>>     first merged in kernel release 3.10, caused the following regression
>>>>     in the Gigaset M101 driver:
>>>>
>>>>
>>>> Again, I'll just note my objection to this commit log.
>>>>
>>>> This driver was always broken because it never initialized
>>>> tty->receive_room,
>>>> but rather relied on common but not guaranteed circumstances to
>>>> function.
>>>>
>>>> The commit noted simply made the underlying bug more evident, but the
>>>> root cause was from the original merge commit of this driver.
>>>
>>> I must admit I still don't understand that objection. The meaning of the
>>> term "regression" is simply that something which previously worked
>>> stopped working. It doesn't imply any statement about the root cause.
>>>
>>> The ser-gigaset driver worked before the introduction of commit
>>> 79901317ce80. It didn't work anymore after the introduction of that
>>> commit. So it is correct, and does not contradict your statements above
>>> in any way, to state that commit introduced the described regression.
>>
>> By asserting that commit 79901317ce80 caused the regression, you're
>> claiming that this fix is unnecessary for kernel versions prior to 3.10
>
> Correct.
>
>> Are you certain that no other sequence of state leads to the same
>> condition (and thus requiring the same fix) in earlier kernel versions?
>
> Reasonably certain, yes, for three reasons:
> - There where no reports of that problem before 3.10.



> - My own tests did never encounter that condition, and even after being
> made aware of it I was not able to come up with a test that would
> provoke it with a kernel version before 3.10.

Do any of your tests switch to this line discipline from any other than N_TTY?
Because if so, you would realize that whatever _that_ line discipline sets
tty->receive_room to when it initializes, is what your line discipline will use
without this fix.

So for example, if you manually set N_PPP (as if by user error) and then
set this line discipline, tty->receive_room will be 64K, not 4K.

> - The requirement for line disciplines to set receive_room wasn't (and
> btw still isn't) documented anywhere, so it's unlikely anything actively
> relied on it.

Nevertheless, that is the requirement, and what every other in-tree line
discipline does.

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1227827 — Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

[Multipart message — attachments visible in raw view] — view raw

Am 17.09.2015 um 20:13 schrieb Peter Hurley:
> On Wed, Sep 16, 2015 at 7:26 AM, Tilman Schmidt <tilman@imap.cc> wrote:
>> Am 16.09.2015 um 03:18 schrieb Peter Hurley:
>>> On Tue, Sep 15, 2015 at 8:37 PM, Tilman Schmidt <tilman@imap.cc> wrote:
>>>> Am 16.09.2015 um 01:08 schrieb Peter Hurley:
>>>>> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>>>>>
>>>>>     From: Tilman Schmidt <tilman@imap.cc>
>>>>>
>>>>>     3.12-stable review patch.  If anyone has any objections, please let
>>>>>     me know.
>>>>>
>>>>>     ===============
>>>>>
>>>>>     [ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ]
>>>>>
>>>>>     Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
>>>>>     first merged in kernel release 3.10, caused the following regression
>>>>>     in the Gigaset M101 driver:
>>>>>
>>>>>
>>>>> Again, I'll just note my objection to this commit log.
>>>>>
>>>>> This driver was always broken because it never initialized
>>>>> tty->receive_room,
>>>>> but rather relied on common but not guaranteed circumstances to
>>>>> function.
>>>>>
>>>>> The commit noted simply made the underlying bug more evident, but the
>>>>> root cause was from the original merge commit of this driver.
>>>>
>>>> I must admit I still don't understand that objection. The meaning of the
>>>> term "regression" is simply that something which previously worked
>>>> stopped working. It doesn't imply any statement about the root cause.
>>>>
>>>> The ser-gigaset driver worked before the introduction of commit
>>>> 79901317ce80. It didn't work anymore after the introduction of that
>>>> commit. So it is correct, and does not contradict your statements above
>>>> in any way, to state that commit introduced the described regression.
>>>
>>> By asserting that commit 79901317ce80 caused the regression, you're
>>> claiming that this fix is unnecessary for kernel versions prior to 3.10
>>
>> Correct.
>>
>>> Are you certain that no other sequence of state leads to the same
>>> condition (and thus requiring the same fix) in earlier kernel versions?
>>
>> Reasonably certain, yes, for three reasons:
>> - There where no reports of that problem before 3.10.
> 
> 
> 
>> - My own tests did never encounter that condition, and even after being
>> made aware of it I was not able to come up with a test that would
>> provoke it with a kernel version before 3.10.
> 
> Do any of your tests switch to this line discipline from any other than N_TTY?

Of course not. That wouldn't make any sense.

> So for example, if you manually set N_PPP (as if by user error)

User error wouldn't suffice, as the LD would get reset to N_TTY when the
serial device is closed. You would have to write a program that
deliberately switched the LD first to N_PPP and then to N_GIGASET_M101
without closing the device in between.

> and then set this line discipline, tty->receive_room will be 64K, not 4K.

That wouldn't affect the operation of ser_gigaset, so even if I had set
up such a contrived test scenario it wouldn't have exposed any problem.
Only setting tty->receive_room to 0 causes the problem, and N_TTY with
commit 79901317ce80 is the only LD which does that.

>> - The requirement for line disciplines to set receive_room wasn't (and
>> btw still isn't) documented anywhere, so it's unlikely anything actively
>> relied on it.
> 
> Nevertheless, that is the requirement, and what every other in-tree line
> discipline does.

Your word for it. Still I don't understand the curious resistance to
documenting it. If it is the requirement, why keep it secret?

Regards,
Tilman

-- 
Tilman Schmidt                              E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

[toc] | [prev] | [next] | [standalone]

#1229301 — Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

On 09/18/2015 08:38 AM, Tilman Schmidt wrote:
> Am 17.09.2015 um 20:13 schrieb Peter Hurley:
>> On Wed, Sep 16, 2015 at 7:26 AM, Tilman Schmidt <tilman@imap.cc> wrote:
>>> Am 16.09.2015 um 03:18 schrieb Peter Hurley:
>>>> On Tue, Sep 15, 2015 at 8:37 PM, Tilman Schmidt <tilman@imap.cc> wrote:
>>>>> Am 16.09.2015 um 01:08 schrieb Peter Hurley:
>>>>>> On Tue, Sep 15, 2015 at 10:22 AM, Jiri Slaby <jslaby@suse.cz> wrote:
>>>>>>
>>>>>>     From: Tilman Schmidt <tilman@imap.cc>
>>>>>>
>>>>>>     3.12-stable review patch.  If anyone has any objections, please let
>>>>>>     me know.
>>>>>>
>>>>>>     ===============
>>>>>>
>>>>>>     [ Upstream commit fd98e9419d8d622a4de91f76b306af6aa627aa9c ]
>>>>>>
>>>>>>     Commit 79901317ce80 ("n_tty: Don't flush buffer when closing ldisc"),
>>>>>>     first merged in kernel release 3.10, caused the following regression
>>>>>>     in the Gigaset M101 driver:
>>>>>>
>>>>>>
>>>>>> Again, I'll just note my objection to this commit log.
>>>>>>
>>>>>> This driver was always broken because it never initialized
>>>>>> tty->receive_room,
>>>>>> but rather relied on common but not guaranteed circumstances to
>>>>>> function.
>>>>>>
>>>>>> The commit noted simply made the underlying bug more evident, but the
>>>>>> root cause was from the original merge commit of this driver.
>>>>>
>>>>> I must admit I still don't understand that objection. The meaning of the
>>>>> term "regression" is simply that something which previously worked
>>>>> stopped working. It doesn't imply any statement about the root cause.
>>>>>
>>>>> The ser-gigaset driver worked before the introduction of commit
>>>>> 79901317ce80. It didn't work anymore after the introduction of that
>>>>> commit. So it is correct, and does not contradict your statements above
>>>>> in any way, to state that commit introduced the described regression.
>>>>
>>>> By asserting that commit 79901317ce80 caused the regression, you're
>>>> claiming that this fix is unnecessary for kernel versions prior to 3.10
>>>
>>> Correct.
>>>
>>>> Are you certain that no other sequence of state leads to the same
>>>> condition (and thus requiring the same fix) in earlier kernel versions?
>>>
>>> Reasonably certain, yes, for three reasons:
>>> - There where no reports of that problem before 3.10.
>>
>>
>>
>>> - My own tests did never encounter that condition, and even after being
>>> made aware of it I was not able to come up with a test that would
>>> provoke it with a kernel version before 3.10.
>>
>> Do any of your tests switch to this line discipline from any other than N_TTY?
> 
> Of course not. That wouldn't make any sense.
> 
>> So for example, if you manually set N_PPP (as if by user error)
> 
> User error wouldn't suffice, as the LD would get reset to N_TTY when the
> serial device is closed. You would have to write a program that
> deliberately switched the LD first to N_PPP and then to N_GIGASET_M101
> without closing the device in between.

???

The tool you authored will do it from the command line

$ ldattach PPP /dev/ttyS1
$ ldattach GIGASET_M101 /dev/ttyS1

Note that nothing here closes the serial device 'in between', and
the tty core has switched directly from PPP to GIGASET_M101.
n_tty->receive_room is now 64K.

Please add switching from line disciplines other than N_TTY to your
regression testing.

>> and then set this line discipline, tty->receive_room will be 64K, not 4K.
> 
> That wouldn't affect the operation of ser_gigaset,

I've explained this before to you, but here it is again:

tty->receive_room announces the maximum amt of data the line discipline
can accept from tty core with each call to its receive_buf() method (for
line disciplines that don't provide flow control).

If the line discipline sets ->receive_room to 64K but can only handle
8K (as in the case of GIGASET_M101), then data loss should be the expected
result.


> so even if I had set
> up such a contrived test scenario it wouldn't have exposed any problem.
> Only setting tty->receive_room to 0 causes the problem, and N_TTY with
> commit 79901317ce80 is the only LD which does that.
> 
>>> - The requirement for line disciplines to set receive_room wasn't (and
>>> btw still isn't) documented anywhere, so it's unlikely anything actively
>>> relied on it.
>>
>> Nevertheless, that is the requirement, and what every other in-tree line
>> discipline does.
> 
> Your word for it. Still I don't understand the curious resistance to
> documenting it. If it is the requirement, why keep it secret?

Nothing sinister here :)

Feel free to submit documentation patches.

Regards,
Peter Hurley 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1229330 — Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

[Multipart message — attachments visible in raw view] — view raw

Am 21.09.2015 um 15:13 schrieb Peter Hurley:
> On 09/18/2015 08:38 AM, Tilman Schmidt wrote:
>> Am 17.09.2015 um 20:13 schrieb Peter Hurley:
>>> On Wed, Sep 16, 2015 at 7:26 AM, Tilman Schmidt <tilman@imap.cc> wrote:
[...]
>>>> - The requirement for line disciplines to set receive_room wasn't (and
>>>> btw still isn't) documented anywhere, so it's unlikely anything actively
>>>> relied on it.
>>>
>>> Nevertheless, that is the requirement, and what every other in-tree line
>>> discipline does.
>>
>> Your word for it. Still I don't understand the curious resistance to
>> documenting it. If it is the requirement, why keep it secret?
> 
> Nothing sinister here :)
> 
> Feel free to submit documentation patches.

I already did. For some unknown reason nobody wants to merge them.

-- 
Tilman Schmidt                              E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

[toc] | [prev] | [next] | [standalone]

#1229564 — Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

On 09/21/2015 09:38 AM, Tilman Schmidt wrote:
> Am 21.09.2015 um 15:13 schrieb Peter Hurley:
>> On 09/18/2015 08:38 AM, Tilman Schmidt wrote:
>>> Am 17.09.2015 um 20:13 schrieb Peter Hurley:
>>>> On Wed, Sep 16, 2015 at 7:26 AM, Tilman Schmidt <tilman@imap.cc> wrote:
> [...]
>>>>> - The requirement for line disciplines to set receive_room wasn't (and
>>>>> btw still isn't) documented anywhere, so it's unlikely anything actively
>>>>> relied on it.
>>>>
>>>> Nevertheless, that is the requirement, and what every other in-tree line
>>>> discipline does.
>>>
>>> Your word for it. Still I don't understand the curious resistance to
>>> documenting it. If it is the requirement, why keep it secret?
>>
>> Nothing sinister here :)
>>
>> Feel free to submit documentation patches.
> 
> I already did. For some unknown reason nobody wants to merge them.

I vaguely recall that. A quick search reminded me there were unaddressed
comments wrt that patch:  https://lkml.org/lkml/2015/7/14/608

Regards,
Peter Hurley

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1229598 — Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

[Multipart message — attachments visible in raw view] — view raw

Am 21.09.2015 um 18:54 schrieb Peter Hurley:
> On 09/21/2015 09:38 AM, Tilman Schmidt wrote:
>> Am 21.09.2015 um 15:13 schrieb Peter Hurley:
>>> On 09/18/2015 08:38 AM, Tilman Schmidt wrote:
>>>> Am 17.09.2015 um 20:13 schrieb Peter Hurley:
>>>>> On Wed, Sep 16, 2015 at 7:26 AM, Tilman Schmidt <tilman@imap.cc> wrote:
>> [...]
>>>>>> - The requirement for line disciplines to set receive_room wasn't (and
>>>>>> btw still isn't) documented anywhere, so it's unlikely anything actively
>>>>>> relied on it.
>>>>>
>>>>> Nevertheless, that is the requirement, and what every other in-tree line
>>>>> discipline does.
>>>>
>>>> Your word for it. Still I don't understand the curious resistance to
>>>> documenting it. If it is the requirement, why keep it secret?
>>>
>>> Nothing sinister here :)
>>>
>>> Feel free to submit documentation patches.
>>
>> I already did. For some unknown reason nobody wants to merge them.
> 
> I vaguely recall that. A quick search reminded me there were unaddressed
> comments wrt that patch:  https://lkml.org/lkml/2015/7/14/608

Ah, so that's the blocking condition? How can I address that comment in
order to unblock that patch?

-- 
Tilman Schmidt                              E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web