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

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

[Jiri Slaby]

From: Mika Westerberg <mika.westerberg@linux.intel.com>

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

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

commit 1abf25a25b86dcfe28d243a5af71bd1c9d6de1ef upstream.

Using -1 as platform device id means that the platform driver core will not
assign any id to the device (the device name will not have id at all). This
results problems on systems that have multiple PCHs (Platform Controller
HUBs) because all of them also include their own copy of LPC device.

All the subsequent device creations will fail because there already exists
platform device with the same name.

Fix this by passing PLATFORM_DEVID_AUTO as platform device id. This makes
the platform device core to allocate new ids automatically.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/mfd/lpc_ich.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
index e775bfbc5e6e..5f187294c85a 100644
--- a/drivers/mfd/lpc_ich.c
+++ b/drivers/mfd/lpc_ich.c
@@ -872,8 +872,8 @@ gpe0_done:
 	lpc_ich_enable_gpio_space(dev);
 
 	lpc_ich_finalize_cell(dev, &lpc_ich_cells[LPC_GPIO]);
-	ret = mfd_add_devices(&dev->dev, -1, &lpc_ich_cells[LPC_GPIO],
-			      1, NULL, 0, NULL);
+	ret = mfd_add_devices(&dev->dev, PLATFORM_DEVID_AUTO,
+			      &lpc_ich_cells[LPC_GPIO], 1, NULL, 0, NULL);
 
 gpio_done:
 	if (acpi_conflict)
@@ -932,8 +932,8 @@ static int lpc_ich_init_wdt(struct pci_dev *dev)
 	}
 
 	lpc_ich_finalize_cell(dev, &lpc_ich_cells[LPC_WDT]);
-	ret = mfd_add_devices(&dev->dev, -1, &lpc_ich_cells[LPC_WDT],
-			      1, NULL, 0, NULL);
+	ret = mfd_add_devices(&dev->dev, PLATFORM_DEVID_AUTO,
+			      &lpc_ich_cells[LPC_WDT], 1, NULL, 0, NULL);
 
 wdt_done:
 	return ret;
-- 
2.5.2

[PATCH 3.12 02/33] drm/radeon: fix hotplug race at startup

[Jiri Slaby]

From: Dave Airlie <airlied@redhat.com>

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

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

commit 7f98ca454ad373fc1b76be804fa7138ff68c1d27 upstream.

We apparantly get a hotplug irq before we've initialised
modesetting,

[drm] Loading R100 Microcode
BUG: unable to handle kernel NULL pointer dereference at   (null)
IP: [<c125f56f>] __mutex_lock_slowpath+0x23/0x91
*pde = 00000000
Oops: 0002 [#1]
Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys
CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf67402 #111
Hardware name: MicroLink                               /D850MV                         , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003
Workqueue: events radeon_hotplug_work_func [radeon]
task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000
EIP: 0060:[<c125f56f>] EFLAGS: 00010282 CPU: 0
EIP is at __mutex_lock_slowpath+0x23/0x91
EAX: 00000000 EBX: f5e900fc ECX: 00000000 EDX: fffffffe
ESI: f6ca5900 EDI: f5e90100 EBP: f5e90000 ESP: f6d3ff0c
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
CR0: 8005003b CR2: 00000000 CR3: 36f61000 CR4: 000006d0
Stack:
 f5e90100 00000000 c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca
 f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d40000 00000000 f6d2a5a0
 c138ca00 f6d2a5b8 c138ca10 c1034b58 00000001 f6d40000 f6ca5900 f6d0c940
Call Trace:
 [<c103c4c1>] ? dequeue_task_fair+0xa4/0xb7
 [<c125f162>] ? mutex_lock+0x9/0xa
 [<f8b0faca>] ? radeon_hotplug_work_func+0x17/0x57 [radeon]
 [<c1034741>] ? process_one_work+0xfc/0x194
 [<c1034b58>] ? worker_thread+0x18d/0x218
 [<c10349cb>] ? rescuer_thread+0x1d5/0x1d5
 [<c103742a>] ? kthread+0x7b/0x80
 [<c12601c0>] ? ret_from_kernel_thread+0x20/0x30
 [<c10373af>] ? init_completion+0x18/0x18
Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 1a 89 c3 8d 78 04 8b 40 08 89 63

Reported-and-Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/gpu/drm/radeon/radeon_irq_kms.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 4a2d91536a8d..c843cf0aa623 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -73,6 +73,11 @@ static void radeon_hotplug_work_func(struct work_struct *work)
 	struct drm_mode_config *mode_config = &dev->mode_config;
 	struct drm_connector *connector;
 
+	/* we can race here at startup, some boards seem to trigger
+	 * hotplug irqs when they shouldn't. */
+	if (!rdev->mode_info.mode_config_initialized)
+		return;
+
 	mutex_lock(&mode_config->mutex);
 	if (mode_config->num_connector) {
 		list_for_each_entry(connector, &mode_config->connector_list, head)
-- 
2.5.2

[PATCH 3.12 03/33] ipv6: Make MLD packets to only be processed locally

[Jiri Slaby]

From: Angga <Hermin.Anggawijaya@alliedtelesis.co.nz>

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

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

[ Upstream commit 4c938d22c88a9ddccc8c55a85e0430e9c62b1ac5 ]

Before commit daad151263cf ("ipv6: Make ipv6_is_mld() inline and use it
from ip6_mc_input().") MLD packets were only processed locally. After the
change, a copy of MLD packet goes through ip6_mr_input, causing
MRT6MSG_NOCACHE message to be generated to user space.

Make MLD packet only processed locally.

Fixes: daad151263cf ("ipv6: Make ipv6_is_mld() inline and use it from ip6_mc_input().")
Signed-off-by: Hermin Anggawijaya <hermin.anggawijaya@alliedtelesis.co.nz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/ipv6/ip6_input.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 51d54dc376f3..05c94d9c3776 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -329,10 +329,10 @@ int ip6_mc_input(struct sk_buff *skb)
 				if (offset < 0)
 					goto out;
 
-				if (!ipv6_is_mld(skb, nexthdr, offset))
-					goto out;
+				if (ipv6_is_mld(skb, nexthdr, offset))
+					deliver = true;
 
-				deliver = true;
+				goto out;
 			}
 			/* unknown RA - process it normally */
 		}
-- 
2.5.2

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

[Jiri Slaby]

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

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

[Jiri Slaby]

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

[PATCH 3.12 06/33] ip_tunnel: fix ipv4 pmtu check to honor inner ip header df

[Jiri Slaby]

From: Timo Teräs <timo.teras@iki.fi>

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

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

[ Upstream commit fc24f2b2094366da8786f59f2606307e934cea17 ]

Frag needed should be sent only if the inner header asked
to not fragment. Currently fragmentation is broken if the
tunnel has df set, but df was not asked in the original
packet. The tunnel's df needs to be still checked to update
internally the pmtu cache.

Commit 23a3647bc4f93bac broke it, and this commit fixes
the ipv4 df check back to the way it was.

Fixes: 23a3647bc4f93bac ("ip_tunnels: Use skb-len to PMTU check.")
Cc: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/ipv4/ip_tunnel.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index edd5a8171357..6913e2fdc12c 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -476,7 +476,8 @@ drop:
 EXPORT_SYMBOL_GPL(ip_tunnel_rcv);
 
 static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
-			    struct rtable *rt, __be16 df)
+			    struct rtable *rt, __be16 df,
+			    const struct iphdr *inner_iph)
 {
 	struct ip_tunnel *tunnel = netdev_priv(dev);
 	int pkt_size = skb->len - tunnel->hlen - dev->hard_header_len;
@@ -493,7 +494,8 @@ static int tnl_update_pmtu(struct net_device *dev, struct sk_buff *skb,
 
 	if (skb->protocol == htons(ETH_P_IP)) {
 		if (!skb_is_gso(skb) &&
-		    (df & htons(IP_DF)) && mtu < pkt_size) {
+		    (inner_iph->frag_off & htons(IP_DF)) &&
+		    mtu < pkt_size) {
 			memset(IPCB(skb), 0, sizeof(*IPCB(skb)));
 			icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu));
 			return -E2BIG;
@@ -611,7 +613,7 @@ void ip_tunnel_xmit(struct sk_buff *skb, struct net_device *dev,
 		goto tx_error;
 	}
 
-	if (tnl_update_pmtu(dev, skb, rt, tnl_params->frag_off)) {
+	if (tnl_update_pmtu(dev, skb, rt, tnl_params->frag_off, inner_iph)) {
 		ip_rt_put(rt);
 		goto tx_error;
 	}
-- 
2.5.2

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

[Jiri Slaby]

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

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

[Jiri Slaby]

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

[PATCH 3.12 09/33] net: pktgen: fix race between pktgen_thread_worker() and kthread_stop()

[Jiri Slaby]

From: Oleg Nesterov <oleg@redhat.com>

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

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

[ Upstream commit fecdf8be2d91e04b0a9a4f79ff06499a36f5d14f ]

pktgen_thread_worker() is obviously racy, kthread_stop() can come
between the kthread_should_stop() check and set_current_state().

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Jan Stancek <jstancek@redhat.com>
Reported-by: Marcelo Leitner <mleitner@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/core/pktgen.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index a104ba3c5768..cea47344d535 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -3423,8 +3423,10 @@ static int pktgen_thread_worker(void *arg)
 	pktgen_rem_thread(t);
 
 	/* Wait for kthread_stop */
-	while (!kthread_should_stop()) {
+	for (;;) {
 		set_current_state(TASK_INTERRUPTIBLE);
+		if (kthread_should_stop())
+			break;
 		schedule();
 	}
 	__set_current_state(TASK_RUNNING);
-- 
2.5.2

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

[Jiri Slaby]

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

[PATCH 3.12 11/33] net: call rcu_read_lock early in process_backlog

[Jiri Slaby]

From: Julian Anastasov <ja@ssi.bg>

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

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

[ Upstream commit 2c17d27c36dcce2b6bf689f41a46b9e909877c21 ]

Incoming packet should be either in backlog queue or
in RCU read-side section. Otherwise, the final sequence of
flush_backlog() and synchronize_net() may miss packets
that can run without device reference:

CPU 1                  CPU 2
                       skb->dev: no reference
                       process_backlog:__skb_dequeue
                       process_backlog:local_irq_enable

on_each_cpu for
flush_backlog =>       IPI(hardirq): flush_backlog
                       - packet not found in backlog

                       CPU delayed ...
synchronize_net
- no ongoing RCU
read-side sections

netdev_run_todo,
rcu_barrier: no
ongoing callbacks
                       __netif_receive_skb_core:rcu_read_lock
                       - too late
free dev
                       process packet for freed dev

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 | 29 ++++++++++++++---------------
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 89c6134a979d..f991f5d3371d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3521,8 +3521,6 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
 
 	pt_prev = NULL;
 
-	rcu_read_lock();
-
 another_round:
 	skb->skb_iif = skb->dev->ifindex;
 
@@ -3532,7 +3530,7 @@ another_round:
 	    skb->protocol == cpu_to_be16(ETH_P_8021AD)) {
 		skb = skb_vlan_untag(skb);
 		if (unlikely(!skb))
-			goto unlock;
+			goto out;
 	}
 
 #ifdef CONFIG_NET_CLS_ACT
@@ -3557,7 +3555,7 @@ skip_taps:
 #ifdef CONFIG_NET_CLS_ACT
 	skb = handle_ing(skb, &pt_prev, &ret, orig_dev);
 	if (!skb)
-		goto unlock;
+		goto out;
 ncls:
 #endif
 
@@ -3572,7 +3570,7 @@ ncls:
 		if (vlan_do_receive(&skb))
 			goto another_round;
 		else if (unlikely(!skb))
-			goto unlock;
+			goto out;
 	}
 
 	rx_handler = rcu_dereference(skb->dev->rx_handler);
@@ -3584,7 +3582,7 @@ ncls:
 		switch (rx_handler(&skb)) {
 		case RX_HANDLER_CONSUMED:
 			ret = NET_RX_SUCCESS;
-			goto unlock;
+			goto out;
 		case RX_HANDLER_ANOTHER:
 			goto another_round;
 		case RX_HANDLER_EXACT:
@@ -3636,8 +3634,6 @@ drop:
 		ret = NET_RX_DROP;
 	}
 
-unlock:
-	rcu_read_unlock();
 out:
 	return ret;
 }
@@ -3684,29 +3680,30 @@ static int __netif_receive_skb(struct sk_buff *skb)
  */
 int netif_receive_skb(struct sk_buff *skb)
 {
+	int ret;
+
 	net_timestamp_check(netdev_tstamp_prequeue, skb);
 
 	if (skb_defer_rx_timestamp(skb))
 		return NET_RX_SUCCESS;
 
+	rcu_read_lock();
+
 #ifdef CONFIG_RPS
 	if (static_key_false(&rps_needed)) {
 		struct rps_dev_flow voidflow, *rflow = &voidflow;
-		int cpu, ret;
-
-		rcu_read_lock();
-
-		cpu = get_rps_cpu(skb->dev, skb, &rflow);
+		int cpu = get_rps_cpu(skb->dev, skb, &rflow);
 
 		if (cpu >= 0) {
 			ret = enqueue_to_backlog(skb, cpu, &rflow->last_qtail);
 			rcu_read_unlock();
 			return ret;
 		}
-		rcu_read_unlock();
 	}
 #endif
-	return __netif_receive_skb(skb);
+	ret = __netif_receive_skb(skb);
+	rcu_read_unlock();
+	return ret;
 }
 EXPORT_SYMBOL(netif_receive_skb);
 
@@ -4116,8 +4113,10 @@ static int process_backlog(struct napi_struct *napi, int quota)
 		unsigned int qlen;
 
 		while ((skb = __skb_dequeue(&sd->process_queue))) {
+			rcu_read_lock();
 			local_irq_enable();
 			__netif_receive_skb(skb);
+			rcu_read_unlock();
 			local_irq_disable();
 			input_queue_head_incr(sd);
 			if (++work >= quota) {
-- 
2.5.2

[PATCH 3.12 00/33] 3.12.48-stable review

[Jiri Slaby]

This is the start of the stable review cycle for the 3.12.48 release.
There are 33 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Sep 17 16:20:25 CEST 2015.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.48-rc1.xz
and the diffstat can be found below.

thanks,
js

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


Akinobu Mita (1):
  bio: fix argument of __bio_add_page() for max_sectors > 0xffff

Andrey Vagin (1):
  netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get

Angga (1):
  ipv6: Make MLD packets to only be processed locally

Benjamin LaHaise (1):
  aio: fix reqs_available handling

Dan Carpenter (1):
  rds: fix an integer overflow test in rds_info_getsockopt()

Daniel Borkmann (1):
  rtnetlink: verify IFLA_VF_INFO attributes before passing them to
    driver

Dave Airlie (1):
  drm/radeon: fix hotplug race at startup

David Milburn (1):
  mtip32xx: dynamically allocate buffer in debugfs functions

Edward Hyunkoo Jee (1):
  inet: frags: fix defragmented packet's IP header for af_packet

Eric Dumazet (2):
  net: graceful exit from netif_alloc_netdev_queues()
  ipv6: lock socket in ip6_datagram_connect()

Florian Westphal (1):
  netlink: don't hold mutex in rcu callback when releasing mmapd ring

Heinz Mauelshagen (1):
  dm cache mq: fix memory allocation failure for large cache devices

Herbert Xu (3):
  net: Clone skb before setting peeked flag
  net: Fix skb csum races when peeking
  net: Fix skb_set_peeked use-after-free bug

Jack Morgenstein (1):
  net/mlx4_core: Fix wrong index in propagating port change event to VFs

James Smart (1):
  lpfc: Fix scsi prep dma buf error.

Julian Anastasov (2):
  net: do not process device backlog during unregistration
  net: call rcu_read_lock early in process_backlog

Mark Rustad (2):
  PCI: Add dev_flags bit to access VPD through function 0
  PCI: Add VPD function 0 quirk for Intel Ethernet devices

Mika Westerberg (1):
  mfd: lpc_ich: Assign subdevice ids automatically

Nikolay Aleksandrov (3):
  bridge: mdb: zero out the local br_ip variable before use
  bridge: mdb: fix double add notification
  bonding: fix destruction of bond with devices different from
    arphrd_ether

Oleg Nesterov (1):
  net: pktgen: fix race between pktgen_thread_worker() and
    kthread_stop()

Pablo Neira Ayuso (1):
  netfilter: nf_conntrack: don't release a conntrack with non-zero
    refcnt

Shirish Pargaonkar (1):
  cifs: Send a logoff request before removing a smb session

Stephen Smalley (1):
  net/tipc: initialize security state for new connection socket

Tilman Schmidt (1):
  isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

Timo Teräs (1):
  ip_tunnel: fix ipv4 pmtu check to honor inner ip header df

dingtianhong (1):
  bonding: correct the MAC address for "follow" fail_over_mac policy

 drivers/block/mtip32xx/mtip32xx.c       |  47 +++++++++---
 drivers/gpu/drm/radeon/radeon_irq_kms.c |   5 ++
 drivers/isdn/gigaset/ser-gigaset.c      |  11 ++-
 drivers/md/dm-cache-policy-mq.c         |   4 +-
 drivers/mfd/lpc_ich.c                   |   8 +-
 drivers/net/bonding/bond_main.c         |  20 +++++
 drivers/net/ethernet/mellanox/mlx4/eq.c |   4 +-
 drivers/pci/access.c                    |  61 ++++++++++++++-
 drivers/pci/quirks.c                    |   9 +++
 drivers/scsi/lpfc/lpfc_scsi.c           |   2 +-
 fs/aio.c                                |  77 ++++++++++++++++++-
 fs/bio.c                                |   2 +-
 fs/cifs/connect.c                       |  25 +++++--
 fs/cifs/smb2transport.c                 |  10 ++-
 fs/cifs/transport.c                     |  11 ++-
 include/linux/pci.h                     |   2 +
 include/net/ip.h                        |   1 +
 include/net/netfilter/nf_conntrack.h    |   2 +
 net/bridge/br_mdb.c                     |   3 +-
 net/core/datagram.c                     |  45 ++++++++++-
 net/core/dev.c                          |  38 +++++-----
 net/core/pktgen.c                       |   4 +-
 net/core/rtnetlink.c                    | 128 ++++++++++++++++----------------
 net/ipv4/datagram.c                     |  16 +++-
 net/ipv4/ip_fragment.c                  |   7 +-
 net/ipv4/ip_tunnel.c                    |   8 +-
 net/ipv6/datagram.c                     |  20 +++--
 net/ipv6/ip6_input.c                    |   6 +-
 net/netfilter/nf_conntrack_core.c       |  55 +++++++++++---
 net/netfilter/nf_synproxy_core.c        |   5 +-
 net/netfilter/xt_CT.c                   |   7 +-
 net/netlink/af_netlink.c                |  79 ++++++++++++--------
 net/rds/info.c                          |   2 +-
 net/tipc/socket.c                       |   1 +
 34 files changed, 535 insertions(+), 190 deletions(-)

-- 
2.5.2

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

[Jiri Slaby]

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

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

[Jiri Slaby]

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

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

[Jiri Slaby]

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

[PATCH 3.12 15/33] bridge: mdb: fix double add notification

[Jiri Slaby]

From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>

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

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

[ Upstream commit 5ebc784625ea68a9570d1f70557e7932988cd1b4 ]

Since the mdb add/del code was introduced there have been 2 br_mdb_notify
calls when doing br_mdb_add() resulting in 2 notifications on each add.

Example:
 Command: bridge mdb add dev br0 port eth1 grp 239.0.0.1 permanent
 Before patch:
 root@debian:~# bridge monitor all
 [MDB]dev br0 port eth1 grp 239.0.0.1 permanent
 [MDB]dev br0 port eth1 grp 239.0.0.1 permanent

 After patch:
 root@debian:~# bridge monitor all
 [MDB]dev br0 port eth1 grp 239.0.0.1 permanent

Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Fixes: cfd567543590 ("bridge: add support of adding and deleting mdb entries")
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/bridge/br_mdb.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c
index 13421bf464c0..27cf128ebc15 100644
--- a/net/bridge/br_mdb.c
+++ b/net/bridge/br_mdb.c
@@ -347,7 +347,6 @@ static int br_mdb_add_group(struct net_bridge *br, struct net_bridge_port *port,
 		return -ENOMEM;
 	rcu_assign_pointer(*pp, p);
 
-	br_mdb_notify(br->dev, port, group, RTM_NEWMDB);
 	return 0;
 }
 
-- 
2.5.2

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

[Jiri Slaby]

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

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

[Jiri Slaby]

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

[PATCH 3.12 18/33] bonding: fix destruction of bond with devices different from arphrd_ether

[Jiri Slaby]

From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>

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

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

[ Upstream commit 06f6d1094aa0992432b1e2a0920b0ee86ccd83bf ]

When the bonding is being unloaded and the netdevice notifier is
unregistered it executes NETDEV_UNREGISTER for each device which should
remove the bond's proc entry but if the device enslaved is not of
ARPHRD_ETHER type and is in front of the bonding, it may execute
bond_release_and_destroy() first which would release the last slave and
destroy the bond device leaving the proc entry and thus we will get the
following error (with dynamic debug on for bond_netdev_event to see the
events order):
[  908.963051] eql: event: 9
[  908.963052] eql: IFF_SLAVE
[  908.963054] eql: event: 2
[  908.963056] eql: IFF_SLAVE
[  908.963058] eql: event: 6
[  908.963059] eql: IFF_SLAVE
[  908.963110] bond0: Releasing active interface eql
[  908.976168] bond0: Destroying bond bond0
[  908.976266] bond0 (unregistering): Released all slaves
[  908.984097] ------------[ cut here ]------------
[  908.984107] WARNING: CPU: 0 PID: 1787 at fs/proc/generic.c:575
remove_proc_entry+0x112/0x160()
[  908.984110] remove_proc_entry: removing non-empty directory
'net/bonding', leaking at least 'bond0'
[  908.984111] Modules linked in: bonding(-) eql(O) 9p nfsd auth_rpcgss
oid_registry nfs_acl nfs lockd grace fscache sunrpc crct10dif_pclmul
crc32_pclmul crc32c_intel ghash_clmulni_intel ppdev qxl drm_kms_helper
snd_hda_codec_generic aesni_intel ttm aes_x86_64 glue_helper pcspkr lrw
gf128mul ablk_helper cryptd snd_hda_intel virtio_console snd_hda_codec
psmouse serio_raw snd_hwdep snd_hda_core 9pnet_virtio 9pnet evdev joydev
drm virtio_balloon snd_pcm snd_timer snd soundcore i2c_piix4 i2c_core
pvpanic acpi_cpufreq parport_pc parport processor thermal_sys button
autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid hid sg sr_mod cdrom
ata_generic virtio_blk virtio_net floppy ata_piix e1000 libata ehci_pci
virtio_pci scsi_mod uhci_hcd ehci_hcd virtio_ring virtio usbcore
usb_common [last unloaded: bonding]

[  908.984168] CPU: 0 PID: 1787 Comm: rmmod Tainted: G        W  O
4.2.0-rc2+ #8
[  908.984170] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  908.984172]  0000000000000000 ffffffff81732d41 ffffffff81525b34
ffff8800358dfda8
[  908.984175]  ffffffff8106c521 ffff88003595af78 ffff88003595af40
ffff88003e3a4280
[  908.984178]  ffffffffa058d040 0000000000000000 ffffffff8106c59a
ffffffff8172ebd0
[  908.984181] Call Trace:
[  908.984188]  [<ffffffff81525b34>] ? dump_stack+0x40/0x50
[  908.984193]  [<ffffffff8106c521>] ? warn_slowpath_common+0x81/0xb0
[  908.984196]  [<ffffffff8106c59a>] ? warn_slowpath_fmt+0x4a/0x50
[  908.984199]  [<ffffffff81218352>] ? remove_proc_entry+0x112/0x160
[  908.984205]  [<ffffffffa05850e6>] ? bond_destroy_proc_dir+0x26/0x30
[bonding]
[  908.984208]  [<ffffffffa057540e>] ? bond_net_exit+0x8e/0xa0 [bonding]
[  908.984217]  [<ffffffff8142f407>] ? ops_exit_list.isra.4+0x37/0x70
[  908.984225]  [<ffffffff8142f52d>] ?
unregister_pernet_operations+0x8d/0xd0
[  908.984228]  [<ffffffff8142f58d>] ?
unregister_pernet_subsys+0x1d/0x30
[  908.984232]  [<ffffffffa0585269>] ? bonding_exit+0x23/0xdba [bonding]
[  908.984236]  [<ffffffff810e28ba>] ? SyS_delete_module+0x18a/0x250
[  908.984241]  [<ffffffff81086f99>] ? task_work_run+0x89/0xc0
[  908.984244]  [<ffffffff8152b732>] ?
entry_SYSCALL_64_fastpath+0x16/0x75
[  908.984247] ---[ end trace 7c006ed4abbef24b ]---

Thus remove the proc entry manually if bond_release_and_destroy() is
used. Because of the checks in bond_remove_proc_entry() it's not a
problem for a bond device to change namespaces (the bug fixed by the
Fixes commit) but since commit
f9399814927ad ("bonding: Don't allow bond devices to change network
namespaces.") that can't happen anyway.

Reported-by: Carol Soto <clsoto@linux.vnet.ibm.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Fixes: a64d49c3dd50 ("bonding: Manage /proc/net/bonding/ entries from
                      the netdev events")
Tested-by: Carol L Soto <clsoto@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/net/bonding/bond_main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 5f95537d4896..806ada973b9f 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1917,6 +1917,7 @@ static int  bond_release_and_destroy(struct net_device *bond_dev,
 		bond_dev->priv_flags |= IFF_DISABLE_NETPOLL;
 		pr_info("%s: destroying bond %s.\n",
 			bond_dev->name, bond_dev->name);
+		bond_remove_proc_entry(bond);
 		unregister_netdevice(bond_dev);
 	}
 	return ret;
-- 
2.5.2

[PATCH 3.12 19/33] bonding: correct the MAC address for "follow" fail_over_mac policy

[Jiri Slaby]

From: dingtianhong <dingtianhong@huawei.com>

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

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

[ Upstream commit a951bc1e6ba58f11df5ed5ddc41311e10f5fd20b ]

The "follow" fail_over_mac policy is useful for multiport devices that
either become confused or incur a performance penalty when multiple
ports are programmed with the same MAC address, but the same MAC
address still may happened by this steps for this policy:

1) echo +eth0 > /sys/class/net/bond0/bonding/slaves
   bond0 has the same mac address with eth0, it is MAC1.

2) echo +eth1 > /sys/class/net/bond0/bonding/slaves
   eth1 is backup, eth1 has MAC2.

3) ifconfig eth0 down
   eth1 became active slave, bond will swap MAC for eth0 and eth1,
   so eth1 has MAC1, and eth0 has MAC2.

4) ifconfig eth1 down
   there is no active slave, and eth1 still has MAC1, eth2 has MAC2.

5) ifconfig eth0 up
   the eth0 became active slave again, the bond set eth0 to MAC1.

Something wrong here, then if you set eth1 up, the eth0 and eth1 will have the same
MAC address, it will break this policy for ACTIVE_BACKUP mode.

This patch will fix this problem by finding the old active slave and
swap them MAC address before change active slave.

Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
Tested-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/net/bonding/bond_main.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 806ada973b9f..b3892b0d2e61 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -671,6 +671,22 @@ static void bond_set_dev_addr(struct net_device *bond_dev,
 	call_netdevice_notifiers(NETDEV_CHANGEADDR, bond_dev);
 }
 
+static struct slave *bond_get_old_active(struct bonding *bond,
+					 struct slave *new_active)
+{
+	struct slave *slave;
+
+	bond_for_each_slave(bond, slave) {
+		if (slave == new_active)
+			continue;
+
+		if (ether_addr_equal(bond->dev->dev_addr, slave->dev->dev_addr))
+			return slave;
+	}
+
+	return NULL;
+}
+
 /*
  * bond_do_fail_over_mac
  *
@@ -712,6 +728,9 @@ static void bond_do_fail_over_mac(struct bonding *bond,
 		write_unlock_bh(&bond->curr_slave_lock);
 		read_unlock(&bond->lock);
 
+		if (!old_active)
+			old_active = bond_get_old_active(bond, new_active);
+
 		if (old_active) {
 			memcpy(tmp_mac, new_active->dev->dev_addr, ETH_ALEN);
 			memcpy(saddr.sa_data, old_active->dev->dev_addr,
-- 
2.5.2

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

[Jiri Slaby]

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

[PATCH 3.12 21/33] netlink: don't hold mutex in rcu callback when releasing mmapd ring

[Jiri Slaby]

From: Florian Westphal <fw@strlen.de>

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

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

[ Upstream commit 0470eb99b4721586ccac954faac3fa4472da0845 ]

Kirill A. Shutemov says:

This simple test-case trigers few locking asserts in kernel:

int main(int argc, char **argv)
{
        unsigned int block_size = 16 * 4096;
        struct nl_mmap_req req = {
                .nm_block_size          = block_size,
                .nm_block_nr            = 64,
                .nm_frame_size          = 16384,
                .nm_frame_nr            = 64 * block_size / 16384,
        };
        unsigned int ring_size;
	int fd;

	fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_GENERIC);
        if (setsockopt(fd, SOL_NETLINK, NETLINK_RX_RING, &req, sizeof(req)) < 0)
                exit(1);
        if (setsockopt(fd, SOL_NETLINK, NETLINK_TX_RING, &req, sizeof(req)) < 0)
                exit(1);

	ring_size = req.nm_block_nr * req.nm_block_size;
	mmap(NULL, 2 * ring_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
	return 0;
}

+++ exited with 0 +++
BUG: sleeping function called from invalid context at /home/kas/git/public/linux-mm/kernel/locking/mutex.c:616
in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: init
3 locks held by init/1:
 #0:  (reboot_mutex){+.+...}, at: [<ffffffff81080959>] SyS_reboot+0xa9/0x220
 #1:  ((reboot_notifier_list).rwsem){.+.+..}, at: [<ffffffff8107f379>] __blocking_notifier_call_chain+0x39/0x70
 #2:  (rcu_callback){......}, at: [<ffffffff810d32e0>] rcu_do_batch.isra.49+0x160/0x10c0
Preemption disabled at:[<ffffffff8145365f>] __delay+0xf/0x20

CPU: 1 PID: 1 Comm: init Not tainted 4.1.0-00009-gbddf4c4818e0 #253
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Debian-1.8.2-1 04/01/2014
 ffff88017b3d8000 ffff88027bc03c38 ffffffff81929ceb 0000000000000102
 0000000000000000 ffff88027bc03c68 ffffffff81085a9d 0000000000000002
 ffffffff81ca2a20 0000000000000268 0000000000000000 ffff88027bc03c98
Call Trace:
 <IRQ>  [<ffffffff81929ceb>] dump_stack+0x4f/0x7b
 [<ffffffff81085a9d>] ___might_sleep+0x16d/0x270
 [<ffffffff81085bed>] __might_sleep+0x4d/0x90
 [<ffffffff8192e96f>] mutex_lock_nested+0x2f/0x430
 [<ffffffff81932fed>] ? _raw_spin_unlock_irqrestore+0x5d/0x80
 [<ffffffff81464143>] ? __this_cpu_preempt_check+0x13/0x20
 [<ffffffff8182fc3d>] netlink_set_ring+0x1ed/0x350
 [<ffffffff8182e000>] ? netlink_undo_bind+0x70/0x70
 [<ffffffff8182fe20>] netlink_sock_destruct+0x80/0x150
 [<ffffffff817e484d>] __sk_free+0x1d/0x160
 [<ffffffff817e49a9>] sk_free+0x19/0x20
[..]

Cong Wang says:

We can't hold mutex lock in a rcu callback, [..]

Thomas Graf says:

The socket should be dead at this point. It might be simpler to
add a netlink_release_ring() function which doesn't require
locking at all.

Reported-by: "Kirill A. Shutemov" <kirill@shutemov.name>
Diagnosed-by: Cong Wang <cwang@twopensource.com>
Suggested-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/netlink/af_netlink.c | 79 ++++++++++++++++++++++++++++--------------------
 1 file changed, 47 insertions(+), 32 deletions(-)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 5a75a1eb3ae7..22e0f478a2a3 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -342,25 +342,52 @@ err1:
 	return NULL;
 }
 
+
+static void
+__netlink_set_ring(struct sock *sk, struct nl_mmap_req *req, bool tx_ring, void **pg_vec,
+		   unsigned int order)
+{
+	struct netlink_sock *nlk = nlk_sk(sk);
+	struct sk_buff_head *queue;
+	struct netlink_ring *ring;
+
+	queue = tx_ring ? &sk->sk_write_queue : &sk->sk_receive_queue;
+	ring  = tx_ring ? &nlk->tx_ring : &nlk->rx_ring;
+
+	spin_lock_bh(&queue->lock);
+
+	ring->frame_max		= req->nm_frame_nr - 1;
+	ring->head		= 0;
+	ring->frame_size	= req->nm_frame_size;
+	ring->pg_vec_pages	= req->nm_block_size / PAGE_SIZE;
+
+	swap(ring->pg_vec_len, req->nm_block_nr);
+	swap(ring->pg_vec_order, order);
+	swap(ring->pg_vec, pg_vec);
+
+	__skb_queue_purge(queue);
+	spin_unlock_bh(&queue->lock);
+
+	WARN_ON(atomic_read(&nlk->mapped));
+
+	if (pg_vec)
+		free_pg_vec(pg_vec, order, req->nm_block_nr);
+}
+
 static int netlink_set_ring(struct sock *sk, struct nl_mmap_req *req,
-			    bool closing, bool tx_ring)
+			    bool tx_ring)
 {
 	struct netlink_sock *nlk = nlk_sk(sk);
 	struct netlink_ring *ring;
-	struct sk_buff_head *queue;
 	void **pg_vec = NULL;
 	unsigned int order = 0;
-	int err;
 
 	ring  = tx_ring ? &nlk->tx_ring : &nlk->rx_ring;
-	queue = tx_ring ? &sk->sk_write_queue : &sk->sk_receive_queue;
 
-	if (!closing) {
-		if (atomic_read(&nlk->mapped))
-			return -EBUSY;
-		if (atomic_read(&ring->pending))
-			return -EBUSY;
-	}
+	if (atomic_read(&nlk->mapped))
+		return -EBUSY;
+	if (atomic_read(&ring->pending))
+		return -EBUSY;
 
 	if (req->nm_block_nr) {
 		if (ring->pg_vec != NULL)
@@ -392,31 +419,19 @@ static int netlink_set_ring(struct sock *sk, struct nl_mmap_req *req,
 			return -EINVAL;
 	}
 
-	err = -EBUSY;
 	mutex_lock(&nlk->pg_vec_lock);
-	if (closing || atomic_read(&nlk->mapped) == 0) {
-		err = 0;
-		spin_lock_bh(&queue->lock);
-
-		ring->frame_max		= req->nm_frame_nr - 1;
-		ring->head		= 0;
-		ring->frame_size	= req->nm_frame_size;
-		ring->pg_vec_pages	= req->nm_block_size / PAGE_SIZE;
-
-		swap(ring->pg_vec_len, req->nm_block_nr);
-		swap(ring->pg_vec_order, order);
-		swap(ring->pg_vec, pg_vec);
-
-		__skb_queue_purge(queue);
-		spin_unlock_bh(&queue->lock);
-
-		WARN_ON(atomic_read(&nlk->mapped));
+	if (atomic_read(&nlk->mapped) == 0) {
+		__netlink_set_ring(sk, req, tx_ring, pg_vec, order);
+		mutex_unlock(&nlk->pg_vec_lock);
+		return 0;
 	}
+
 	mutex_unlock(&nlk->pg_vec_lock);
 
 	if (pg_vec)
 		free_pg_vec(pg_vec, order, req->nm_block_nr);
-	return err;
+
+	return -EBUSY;
 }
 
 static void netlink_mm_open(struct vm_area_struct *vma)
@@ -885,10 +900,10 @@ static void netlink_sock_destruct(struct sock *sk)
 
 		memset(&req, 0, sizeof(req));
 		if (nlk->rx_ring.pg_vec)
-			netlink_set_ring(sk, &req, true, false);
+			__netlink_set_ring(sk, &req, false, NULL, 0);
 		memset(&req, 0, sizeof(req));
 		if (nlk->tx_ring.pg_vec)
-			netlink_set_ring(sk, &req, true, true);
+			__netlink_set_ring(sk, &req, true, NULL, 0);
 	}
 #endif /* CONFIG_NETLINK_MMAP */
 
@@ -2182,7 +2197,7 @@ static int netlink_setsockopt(struct socket *sock, int level, int optname,
 			return -EINVAL;
 		if (copy_from_user(&req, optval, sizeof(req)))
 			return -EFAULT;
-		err = netlink_set_ring(sk, &req, false,
+		err = netlink_set_ring(sk, &req,
 				       optname == NETLINK_TX_RING);
 		break;
 	}
-- 
2.5.2

[PATCH 3.12 22/33] net/mlx4_core: Fix wrong index in propagating port change event to VFs

[Jiri Slaby]

From: Jack Morgenstein <jackm@dev.mellanox.co.il>

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

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

[ Upstream commit 1c1bf34951e8d17941bf708d1901c47e81b15d55 ]

The port-change event processing in procedure mlx4_eq_int() uses "slave"
as the vf_oper array index. Since the value of "slave" is the PF function
index, the result is that the PF link state is used for deciding to
propagate the event for all the VFs. The VF link state should be used,
so the VF function index should be used here.

Fixes: 948e306d7d64 ('net/mlx4: Add VF link state support')
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/net/ethernet/mellanox/mlx4/eq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/eq.c b/drivers/net/ethernet/mellanox/mlx4/eq.c
index 0416c5b3b35c..3990b435a081 100644
--- a/drivers/net/ethernet/mellanox/mlx4/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/eq.c
@@ -558,7 +558,7 @@ static int mlx4_eq_int(struct mlx4_dev *dev, struct mlx4_eq *eq)
 						mlx4_dbg(dev, "%s: Sending MLX4_PORT_CHANGE_SUBTYPE_DOWN"
 							 " to slave: %d, port:%d\n",
 							 __func__, i, port);
-						s_info = &priv->mfunc.master.vf_oper[slave].vport[port].state;
+						s_info = &priv->mfunc.master.vf_oper[i].vport[port].state;
 						if (IFLA_VF_LINK_STATE_AUTO == s_info->link_state)
 							mlx4_slave_event(dev, i, eqe);
 					} else {  /* IB port */
@@ -584,7 +584,7 @@ static int mlx4_eq_int(struct mlx4_dev *dev, struct mlx4_eq *eq)
 					for (i = 0; i < dev->num_slaves; i++) {
 						if (i == mlx4_master_func_num(dev))
 							continue;
-						s_info = &priv->mfunc.master.vf_oper[slave].vport[port].state;
+						s_info = &priv->mfunc.master.vf_oper[i].vport[port].state;
 						if (IFLA_VF_LINK_STATE_AUTO == s_info->link_state)
 							mlx4_slave_event(dev, i, eqe);
 					}
-- 
2.5.2

[PATCH 3.12 23/33] rds: fix an integer overflow test in rds_info_getsockopt()

[Jiri Slaby]

From: Dan Carpenter <dan.carpenter@oracle.com>

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

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

[ Upstream commit 468b732b6f76b138c0926eadf38ac88467dcd271 ]

"len" is a signed integer.  We check that len is not negative, so it
goes from zero to INT_MAX.  PAGE_SIZE is unsigned long so the comparison
is type promoted to unsigned long.  ULONG_MAX - 4095 is a higher than
INT_MAX so the condition can never be true.

I don't know if this is harmful but it seems safe to limit "len" to
INT_MAX - 4095.

Fixes: a8c879a7ee98 ('RDS: Info and stats')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/rds/info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rds/info.c b/net/rds/info.c
index 9a6b4f66187c..140a44a5f7b7 100644
--- a/net/rds/info.c
+++ b/net/rds/info.c
@@ -176,7 +176,7 @@ int rds_info_getsockopt(struct socket *sock, int optname, char __user *optval,
 
 	/* check for all kinds of wrapping and the like */
 	start = (unsigned long)optval;
-	if (len < 0 || len + PAGE_SIZE - 1 < len || start + len < start) {
+	if (len < 0 || len > INT_MAX - PAGE_SIZE + 1 || start + len < start) {
 		ret = -EINVAL;
 		goto out;
 	}
-- 
2.5.2

[PATCH 3.12 24/33] mtip32xx: dynamically allocate buffer in debugfs functions

[Jiri Slaby]

From: David Milburn <dmilburn@redhat.com>

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

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

commit c8afd0dcbd14e2352258f2e2d359b36d0edd459f upstream.

Dynamically allocate buf to prevent warnings:

drivers/block/mtip32xx/mtip32xx.c: In function ‘mtip_hw_read_device_status’:
drivers/block/mtip32xx/mtip32xx.c:2823: warning: the frame size of 1056 bytes is larger than 1024 bytes
drivers/block/mtip32xx/mtip32xx.c: In function ‘mtip_hw_read_registers’:
drivers/block/mtip32xx/mtip32xx.c:2894: warning: the frame size of 1056 bytes is larger than 1024 bytes
drivers/block/mtip32xx/mtip32xx.c: In function ‘mtip_hw_read_flags’:
drivers/block/mtip32xx/mtip32xx.c:2917: warning: the frame size of 1056 bytes is larger than 1024 bytes

Signed-off-by: David Milburn <dmilburn@redhat.com>
Acked-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/block/mtip32xx/mtip32xx.c | 47 ++++++++++++++++++++++++++++++---------
 1 file changed, 37 insertions(+), 10 deletions(-)

diff --git a/drivers/block/mtip32xx/mtip32xx.c b/drivers/block/mtip32xx/mtip32xx.c
index 560227b817fe..01c7270b5e84 100644
--- a/drivers/block/mtip32xx/mtip32xx.c
+++ b/drivers/block/mtip32xx/mtip32xx.c
@@ -2810,34 +2810,51 @@ static ssize_t show_device_status(struct device_driver *drv, char *buf)
 static ssize_t mtip_hw_read_device_status(struct file *f, char __user *ubuf,
 						size_t len, loff_t *offset)
 {
+	struct driver_data *dd =  (struct driver_data *)f->private_data;
 	int size = *offset;
-	char buf[MTIP_DFS_MAX_BUF_SIZE];
+	char *buf;
+	int rv = 0;
 
 	if (!len || *offset)
 		return 0;
 
+	buf = kzalloc(MTIP_DFS_MAX_BUF_SIZE, GFP_KERNEL);
+	if (!buf) {
+		dev_err(&dd->pdev->dev,
+			"Memory allocation: status buffer\n");
+		return -ENOMEM;
+	}
+
 	size += show_device_status(NULL, buf);
 
 	*offset = size <= len ? size : len;
 	size = copy_to_user(ubuf, buf, *offset);
 	if (size)
-		return -EFAULT;
+		rv = -EFAULT;
 
-	return *offset;
+	kfree(buf);
+	return rv ? rv : *offset;
 }
 
 static ssize_t mtip_hw_read_registers(struct file *f, char __user *ubuf,
 				  size_t len, loff_t *offset)
 {
 	struct driver_data *dd =  (struct driver_data *)f->private_data;
-	char buf[MTIP_DFS_MAX_BUF_SIZE];
+	char *buf;
 	u32 group_allocated;
 	int size = *offset;
-	int n;
+	int n, rv = 0;
 
 	if (!len || size)
 		return 0;
 
+	buf = kzalloc(MTIP_DFS_MAX_BUF_SIZE, GFP_KERNEL);
+	if (!buf) {
+		dev_err(&dd->pdev->dev,
+			"Memory allocation: register buffer\n");
+		return -ENOMEM;
+	}
+
 	size += sprintf(&buf[size], "H/ S ACTive      : [ 0x");
 
 	for (n = dd->slot_groups-1; n >= 0; n--)
@@ -2892,21 +2909,30 @@ static ssize_t mtip_hw_read_registers(struct file *f, char __user *ubuf,
 	*offset = size <= len ? size : len;
 	size = copy_to_user(ubuf, buf, *offset);
 	if (size)
-		return -EFAULT;
+		rv = -EFAULT;
 
-	return *offset;
+	kfree(buf);
+	return rv ? rv : *offset;
 }
 
 static ssize_t mtip_hw_read_flags(struct file *f, char __user *ubuf,
 				  size_t len, loff_t *offset)
 {
 	struct driver_data *dd =  (struct driver_data *)f->private_data;
-	char buf[MTIP_DFS_MAX_BUF_SIZE];
+	char *buf;
 	int size = *offset;
+	int rv = 0;
 
 	if (!len || size)
 		return 0;
 
+	buf = kzalloc(MTIP_DFS_MAX_BUF_SIZE, GFP_KERNEL);
+	if (!buf) {
+		dev_err(&dd->pdev->dev,
+			"Memory allocation: flag buffer\n");
+		return -ENOMEM;
+	}
+
 	size += sprintf(&buf[size], "Flag-port : [ %08lX ]\n",
 							dd->port->flags);
 	size += sprintf(&buf[size], "Flag-dd   : [ %08lX ]\n",
@@ -2915,9 +2941,10 @@ static ssize_t mtip_hw_read_flags(struct file *f, char __user *ubuf,
 	*offset = size <= len ? size : len;
 	size = copy_to_user(ubuf, buf, *offset);
 	if (size)
-		return -EFAULT;
+		rv = -EFAULT;
 
-	return *offset;
+	kfree(buf);
+	return rv ? rv : *offset;
 }
 
 static const struct file_operations mtip_device_status_fops = {
-- 
2.5.2

[PATCH 3.12 25/33] cifs: Send a logoff request before removing a smb session

[Jiri Slaby]

From: Shirish Pargaonkar <shirishpargaonkar@gmail.com>

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

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

commit 7f48558e6489d032b1584b0cc9ac4bb11072c034 upstream.

Send a smb session logoff request before removing smb session off of the list.
On a signed smb session, remvoing a session off of the list before sending
a logoff request results in server returning an error for lack of
smb signature.

Never seen an error during smb logoff, so as per MS-SMB2 3.2.5.1,
not sure how an error during logoff should be retried. So for now,
if a server returns an error to a logoff request, log the error and
remove the session off of the list.

Signed-off-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 fs/cifs/connect.c       | 25 ++++++++++++++++++++-----
 fs/cifs/smb2transport.c | 10 ++++++++--
 fs/cifs/transport.c     | 11 +++++++++--
 3 files changed, 37 insertions(+), 9 deletions(-)

diff --git a/fs/cifs/connect.c b/fs/cifs/connect.c
index 89b5519085c2..ebad721656f3 100644
--- a/fs/cifs/connect.c
+++ b/fs/cifs/connect.c
@@ -2245,6 +2245,8 @@ cifs_find_smb_ses(struct TCP_Server_Info *server, struct smb_vol *vol)
 
 	spin_lock(&cifs_tcp_ses_lock);
 	list_for_each_entry(ses, &server->smb_ses_list, smb_ses_list) {
+		if (ses->status == CifsExiting)
+			continue;
 		if (!match_session(ses, vol))
 			continue;
 		++ses->ses_count;
@@ -2258,24 +2260,37 @@ cifs_find_smb_ses(struct TCP_Server_Info *server, struct smb_vol *vol)
 static void
 cifs_put_smb_ses(struct cifs_ses *ses)
 {
-	unsigned int xid;
+	unsigned int rc, xid;
 	struct TCP_Server_Info *server = ses->server;
 
 	cifs_dbg(FYI, "%s: ses_count=%d\n", __func__, ses->ses_count);
+
 	spin_lock(&cifs_tcp_ses_lock);
+	if (ses->status == CifsExiting) {
+		spin_unlock(&cifs_tcp_ses_lock);
+		return;
+	}
 	if (--ses->ses_count > 0) {
 		spin_unlock(&cifs_tcp_ses_lock);
 		return;
 	}
-
-	list_del_init(&ses->smb_ses_list);
+	if (ses->status == CifsGood)
+		ses->status = CifsExiting;
 	spin_unlock(&cifs_tcp_ses_lock);
 
-	if (ses->status == CifsGood && server->ops->logoff) {
+	if (ses->status == CifsExiting && server->ops->logoff) {
 		xid = get_xid();
-		server->ops->logoff(xid, ses);
+		rc = server->ops->logoff(xid, ses);
+		if (rc)
+			cifs_dbg(VFS, "%s: Session Logoff failure rc=%d\n",
+				__func__, rc);
 		_free_xid(xid);
 	}
+
+	spin_lock(&cifs_tcp_ses_lock);
+	list_del_init(&ses->smb_ses_list);
+	spin_unlock(&cifs_tcp_ses_lock);
+
 	sesInfoFree(ses);
 	cifs_put_tcp_session(server);
 }
diff --git a/fs/cifs/smb2transport.c b/fs/cifs/smb2transport.c
index 340abca3aa52..ee1963b2e5a7 100644
--- a/fs/cifs/smb2transport.c
+++ b/fs/cifs/smb2transport.c
@@ -516,13 +516,19 @@ smb2_get_mid_entry(struct cifs_ses *ses, struct smb2_hdr *buf,
 		return -EAGAIN;
 	}
 
-	if (ses->status != CifsGood) {
-		/* check if SMB2 session is bad because we are setting it up */
+	if (ses->status == CifsNew) {
 		if ((buf->Command != SMB2_SESSION_SETUP) &&
 		    (buf->Command != SMB2_NEGOTIATE))
 			return -EAGAIN;
 		/* else ok - we are setting up session */
 	}
+
+	if (ses->status == CifsExiting) {
+		if (buf->Command != SMB2_LOGOFF)
+			return -EAGAIN;
+		/* else ok - we are shutting down the session */
+	}
+
 	*mid = smb2_mid_entry_alloc(buf, ses->server);
 	if (*mid == NULL)
 		return -ENOMEM;
diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c
index 800b938e4061..ebb46e311e0b 100644
--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
@@ -431,13 +431,20 @@ static int allocate_mid(struct cifs_ses *ses, struct smb_hdr *in_buf,
 		return -EAGAIN;
 	}
 
-	if (ses->status != CifsGood) {
-		/* check if SMB session is bad because we are setting it up */
+	if (ses->status == CifsNew) {
 		if ((in_buf->Command != SMB_COM_SESSION_SETUP_ANDX) &&
 			(in_buf->Command != SMB_COM_NEGOTIATE))
 			return -EAGAIN;
 		/* else ok - we are setting up session */
 	}
+
+	if (ses->status == CifsExiting) {
+		/* check if SMB session is bad because we are setting it up */
+		if (in_buf->Command != SMB_COM_LOGOFF_ANDX)
+			return -EAGAIN;
+		/* else ok - we are shutting down session */
+	}
+
 	*ppmidQ = AllocMidQEntry(in_buf, ses->server);
 	if (*ppmidQ == NULL)
 		return -ENOMEM;
-- 
2.5.2

[PATCH 3.12 26/33] lpfc: Fix scsi prep dma buf error.

[Jiri Slaby]

From: James Smart <james.smart@avagotech.com>

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

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

commit 5116fbf136ea21b8678a85eee5c03508736ada9f upstream.

Didn't check for less-than-or-equal zero. Means we may later call
scsi_dma_unmap() even though we don't have valid mappings.

Signed-off-by: Dick Kennedy <dick.kennedy@avagotech.com>
Signed-off-by: James Smart <james.smart@avagotech.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/scsi/lpfc/lpfc_scsi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c
index c913e8cc3b26..ed7759980c47 100644
--- a/drivers/scsi/lpfc/lpfc_scsi.c
+++ b/drivers/scsi/lpfc/lpfc_scsi.c
@@ -3423,7 +3423,7 @@ lpfc_scsi_prep_dma_buf_s4(struct lpfc_hba *phba, struct lpfc_scsi_buf *lpfc_cmd)
 		 */
 
 		nseg = scsi_dma_map(scsi_cmnd);
-		if (unlikely(!nseg))
+		if (unlikely(nseg <= 0))
 			return 1;
 		sgl += 1;
 		/* clear the last flag in the fcp_rsp map entry */
-- 
2.5.2

[PATCH 3.12 27/33] bio: fix argument of __bio_add_page() for max_sectors > 0xffff

[Jiri Slaby]

From: Akinobu Mita <akinobu.mita@gmail.com>

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

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

commit 34f2fd8dfe6185b0eaaf7d661281713a6170b077 upstream.

The data type of max_sectors and max_hw_sectors in queue settings are
unsigned int.  But these values are passed to __bio_add_page() as an
argument whose data type is unsigned short.  In the worst case such as
max_sectors is 0x10000, bio_add_page() can't add a page and IOs can't
proceed.

Cc: Jens Axboe <axboe@kernel.dk>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 fs/bio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/bio.c b/fs/bio.c
index ea5035da4d9a..e7fb3f82f5f5 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -601,7 +601,7 @@ EXPORT_SYMBOL(bio_get_nr_vecs);
 
 static int __bio_add_page(struct request_queue *q, struct bio *bio, struct page
 			  *page, unsigned int len, unsigned int offset,
-			  unsigned short max_sectors)
+			  unsigned int max_sectors)
 {
 	int retried_segments = 0;
 	struct bio_vec *bvec;
-- 
2.5.2

[PATCH 3.12 28/33] dm cache mq: fix memory allocation failure for large cache devices

[Jiri Slaby]

From: Heinz Mauelshagen <heinzm@redhat.com>

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

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

commit 14f398ca2f26a2ed6236aec54395e0fa06ec8a82 upstream.

The memory allocated for the multiqueue policy's hash table doesn't need
to be physically contiguous.  Use vzalloc() instead of kzalloc().
Fedora has been carrying this fix since 10/10/2013.

Failure seen during creation of a 10TB cached device with a 2048 sector
block size and 411GB cache size:

 dmsetup: page allocation failure: order:9, mode:0x10c0d0
 CPU: 11 PID: 29235 Comm: dmsetup Not tainted 3.10.4 #3
 Hardware name: Supermicro X8DTL/X8DTL, BIOS 2.1a       12/30/2011
  000000000010c0d0 ffff880090941898 ffffffff81387ab4 ffff880090941928
  ffffffff810bb26f 0000000000000009 000000000010c0d0 ffff880090941928
  ffffffff81385dbc ffffffff815f3840 ffffffff00000000 000002000010c0d0
 Call Trace:
  [<ffffffff81387ab4>] dump_stack+0x19/0x1b
  [<ffffffff810bb26f>] warn_alloc_failed+0x110/0x124
  [<ffffffff81385dbc>] ? __alloc_pages_direct_compact+0x17c/0x18e
  [<ffffffff810bda2e>] __alloc_pages_nodemask+0x6c7/0x75e
  [<ffffffff810bdad7>] __get_free_pages+0x12/0x3f
  [<ffffffff810ea148>] kmalloc_order_trace+0x29/0x88
  [<ffffffff810ec1fd>] __kmalloc+0x36/0x11b
  [<ffffffffa031eeed>] ? mq_create+0x1dc/0x2cf [dm_cache_mq]
  [<ffffffffa031efc0>] mq_create+0x2af/0x2cf [dm_cache_mq]
  [<ffffffffa0314605>] dm_cache_policy_create+0xa7/0xd2 [dm_cache]
  [<ffffffffa0312530>] ? cache_ctr+0x245/0xa13 [dm_cache]
  [<ffffffffa031263e>] cache_ctr+0x353/0xa13 [dm_cache]
  [<ffffffffa012b916>] dm_table_add_target+0x227/0x2ce [dm_mod]
  [<ffffffffa012e8e4>] table_load+0x286/0x2ac [dm_mod]
  [<ffffffffa012e65e>] ? dev_wait+0x8a/0x8a [dm_mod]
  [<ffffffffa012e324>] ctl_ioctl+0x39a/0x3c2 [dm_mod]
  [<ffffffffa012e35a>] dm_ctl_ioctl+0xe/0x12 [dm_mod]
  [<ffffffff81101181>] vfs_ioctl+0x21/0x34
  [<ffffffff811019d3>] do_vfs_ioctl+0x3b1/0x3f4
  [<ffffffff810f4d2e>] ? ____fput+0x9/0xb
  [<ffffffff81050b6c>] ? task_work_run+0x7e/0x92
  [<ffffffff81101a68>] SyS_ioctl+0x52/0x82
  [<ffffffff81391d92>] system_call_fastpath+0x16/0x1b

Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/md/dm-cache-policy-mq.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/md/dm-cache-policy-mq.c b/drivers/md/dm-cache-policy-mq.c
index 4296155090b2..afcd18428945 100644
--- a/drivers/md/dm-cache-policy-mq.c
+++ b/drivers/md/dm-cache-policy-mq.c
@@ -855,7 +855,7 @@ static void mq_destroy(struct dm_cache_policy *p)
 	struct mq_policy *mq = to_mq_policy(p);
 
 	free_bitset(mq->allocation_bitset);
-	kfree(mq->table);
+	vfree(mq->table);
 	free_entries(mq);
 	kfree(mq);
 }
@@ -1106,7 +1106,7 @@ static struct dm_cache_policy *mq_create(dm_cblock_t cache_size,
 
 	mq->nr_buckets = next_power(from_cblock(cache_size) / 2, 16);
 	mq->hash_bits = ffs(mq->nr_buckets) - 1;
-	mq->table = kzalloc(sizeof(*mq->table) * mq->nr_buckets, GFP_KERNEL);
+	mq->table = vzalloc(sizeof(*mq->table) * mq->nr_buckets);
 	if (!mq->table)
 		goto bad_alloc_table;
 
-- 
2.5.2

[PATCH 3.12 29/33] aio: fix reqs_available handling

[Jiri Slaby]

From: Benjamin LaHaise <bcrl@kvack.org>

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

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

commit d856f32a86b2b015ab180ab7a55e455ed8d3ccc5 upstream.

As reported by Dan Aloni, commit f8567a3845ac ("aio: fix aio request
leak when events are reaped by userspace") introduces a regression when
user code attempts to perform io_submit() with more events than are
available in the ring buffer.  Reverting that commit would reintroduce a
regression when user space event reaping is used.

Fixing this bug is a bit more involved than the previous attempts to fix
this regression.  Since we do not have a single point at which we can
count events as being reaped by user space and io_getevents(), we have
to track event completion by looking at the number of events left in the
event ring.  So long as there are as many events in the ring buffer as
there have been completion events generate, we cannot call
put_reqs_available().  The code to check for this is now placed in
refill_reqs_available().

A test program from Dan and modified by me for verifying this bug is available
at http://www.kvack.org/~bcrl/20140824-aio_bug.c .

Reported-by: Dan Aloni <dan@kernelim.com>
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Acked-by: Dan Aloni <dan@kernelim.com>
Cc: Kent Overstreet <kmo@daterainc.com>
Cc: Mateusz Guzik <mguzik@redhat.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 fs/aio.c | 77 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 73 insertions(+), 4 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index 329e6c1f3a43..31a5cb74ae1f 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -146,6 +146,7 @@ struct kioctx {
 
 	struct {
 		unsigned	tail;
+		unsigned	completed_events;
 		spinlock_t	completion_lock;
 	} ____cacheline_aligned_in_smp;
 
@@ -899,6 +900,68 @@ out:
 	return ret;
 }
 
+/* refill_reqs_available
+ *	Updates the reqs_available reference counts used for tracking the
+ *	number of free slots in the completion ring.  This can be called
+ *	from aio_complete() (to optimistically update reqs_available) or
+ *	from aio_get_req() (the we're out of events case).  It must be
+ *	called holding ctx->completion_lock.
+ */
+static void refill_reqs_available(struct kioctx *ctx, unsigned head,
+                                  unsigned tail)
+{
+	unsigned events_in_ring, completed;
+
+	/* Clamp head since userland can write to it. */
+	head %= ctx->nr_events;
+	if (head <= tail)
+		events_in_ring = tail - head;
+	else
+		events_in_ring = ctx->nr_events - (head - tail);
+
+	completed = ctx->completed_events;
+	if (events_in_ring < completed)
+		completed -= events_in_ring;
+	else
+		completed = 0;
+
+	if (!completed)
+		return;
+
+	ctx->completed_events -= completed;
+	put_reqs_available(ctx, completed);
+}
+
+/* user_refill_reqs_available
+ *	Called to refill reqs_available when aio_get_req() encounters an
+ *	out of space in the completion ring.
+ */
+static void user_refill_reqs_available(struct kioctx *ctx)
+{
+	spin_lock_irq(&ctx->completion_lock);
+	if (ctx->completed_events) {
+		struct aio_ring *ring;
+		unsigned head;
+
+		/* Access of ring->head may race with aio_read_events_ring()
+		 * here, but that's okay since whether we read the old version
+		 * or the new version, and either will be valid.  The important
+		 * part is that head cannot pass tail since we prevent
+		 * aio_complete() from updating tail by holding
+		 * ctx->completion_lock.  Even if head is invalid, the check
+		 * against ctx->completed_events below will make sure we do the
+		 * safe/right thing.
+		 */
+		ring = kmap_atomic(ctx->ring_pages[0]);
+		head = ring->head;
+		kunmap_atomic(ring);
+
+		refill_reqs_available(ctx, head, ctx->tail);
+	}
+
+	spin_unlock_irq(&ctx->completion_lock);
+}
+
 /* aio_get_req
  *	Allocate a slot for an aio request.
  * Returns NULL if no requests are free.
@@ -907,8 +970,11 @@ static inline struct kiocb *aio_get_req(struct kioctx *ctx)
 {
 	struct kiocb *req;
 
-	if (!get_reqs_available(ctx))
-		return NULL;
+	if (!get_reqs_available(ctx)) {
+		user_refill_reqs_available(ctx);
+		if (!get_reqs_available(ctx))
+			return NULL;
+	}
 
 	req = kmem_cache_alloc(kiocb_cachep, GFP_KERNEL|__GFP_ZERO);
 	if (unlikely(!req))
@@ -967,8 +1033,8 @@ void aio_complete(struct kiocb *iocb, long res, long res2)
 	struct kioctx	*ctx = iocb->ki_ctx;
 	struct aio_ring	*ring;
 	struct io_event	*ev_page, *event;
+	unsigned tail, pos, head;
 	unsigned long	flags;
-	unsigned tail, pos;
 
 	/*
 	 * Special case handling for sync iocbs:
@@ -1029,10 +1095,14 @@ void aio_complete(struct kiocb *iocb, long res, long res2)
 	ctx->tail = tail;
 
 	ring = kmap_atomic(ctx->ring_pages[0]);
+	head = ring->head;
 	ring->tail = tail;
 	kunmap_atomic(ring);
 	flush_dcache_page(ctx->ring_pages[0]);
 
+	ctx->completed_events++;
+	if (ctx->completed_events > 1)
+		refill_reqs_available(ctx, head, tail);
 	spin_unlock_irqrestore(&ctx->completion_lock, flags);
 
 	pr_debug("added to ring %p at [%u]\n", iocb, tail);
@@ -1047,7 +1117,6 @@ void aio_complete(struct kiocb *iocb, long res, long res2)
 
 	/* everything turned out well, dispose of the aiocb. */
 	kiocb_free(iocb);
-	put_reqs_available(ctx, 1);
 
 	/*
 	 * We have to order our ring_info tail store above and test
-- 
2.5.2

[PATCH 3.12 30/33] netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get

[Jiri Slaby]

From: Andrey Vagin <avagin@openvz.org>

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

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

[ Upstream commit c6825c0976fa7893692e0e43b09740b419b23c09 ]

Lets look at destroy_conntrack:

hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode);
...
nf_conntrack_free(ct)
	kmem_cache_free(net->ct.nf_conntrack_cachep, ct);

net->ct.nf_conntrack_cachep is created with SLAB_DESTROY_BY_RCU.

The hash is protected by rcu, so readers look up conntracks without
locks.
A conntrack is removed from the hash, but in this moment a few readers
still can use the conntrack. Then this conntrack is released and another
thread creates conntrack with the same address and the equal tuple.
After this a reader starts to validate the conntrack:
* It's not dying, because a new conntrack was created
* nf_ct_tuple_equal() returns true.

But this conntrack is not initialized yet, so it can not be used by two
threads concurrently. In this case BUG_ON may be triggered from
nf_nat_setup_info().

Florian Westphal suggested to check the confirm bit too. I think it's
right.

task 1			task 2			task 3
			nf_conntrack_find_get
			 ____nf_conntrack_find
destroy_conntrack
 hlist_nulls_del_rcu
 nf_conntrack_free
 kmem_cache_free
						__nf_conntrack_alloc
						 kmem_cache_alloc
						 memset(&ct->tuplehash[IP_CT_DIR_MAX],
			 if (nf_ct_is_dying(ct))
			 if (!nf_ct_tuple_equal()

I'm not sure, that I have ever seen this race condition in a real life.
Currently we are investigating a bug, which is reproduced on a few nodes.
In our case one conntrack is initialized from a few tasks concurrently,
we don't have any other explanation for this.

<2>[46267.083061] kernel BUG at net/ipv4/netfilter/nf_nat_core.c:322!
...
<4>[46267.083951] RIP: 0010:[<ffffffffa01e00a4>]  [<ffffffffa01e00a4>] nf_nat_setup_info+0x564/0x590 [nf_nat]
...
<4>[46267.085549] Call Trace:
<4>[46267.085622]  [<ffffffffa023421b>] alloc_null_binding+0x5b/0xa0 [iptable_nat]
<4>[46267.085697]  [<ffffffffa02342bc>] nf_nat_rule_find+0x5c/0x80 [iptable_nat]
<4>[46267.085770]  [<ffffffffa0234521>] nf_nat_fn+0x111/0x260 [iptable_nat]
<4>[46267.085843]  [<ffffffffa0234798>] nf_nat_out+0x48/0xd0 [iptable_nat]
<4>[46267.085919]  [<ffffffff814841b9>] nf_iterate+0x69/0xb0
<4>[46267.085991]  [<ffffffff81494e70>] ? ip_finish_output+0x0/0x2f0
<4>[46267.086063]  [<ffffffff81484374>] nf_hook_slow+0x74/0x110
<4>[46267.086133]  [<ffffffff81494e70>] ? ip_finish_output+0x0/0x2f0
<4>[46267.086207]  [<ffffffff814b5890>] ? dst_output+0x0/0x20
<4>[46267.086277]  [<ffffffff81495204>] ip_output+0xa4/0xc0
<4>[46267.086346]  [<ffffffff814b65a4>] raw_sendmsg+0x8b4/0x910
<4>[46267.086419]  [<ffffffff814c10fa>] inet_sendmsg+0x4a/0xb0
<4>[46267.086491]  [<ffffffff814459aa>] ? sock_update_classid+0x3a/0x50
<4>[46267.086562]  [<ffffffff81444d67>] sock_sendmsg+0x117/0x140
<4>[46267.086638]  [<ffffffff8151997b>] ? _spin_unlock_bh+0x1b/0x20
<4>[46267.086712]  [<ffffffff8109d370>] ? autoremove_wake_function+0x0/0x40
<4>[46267.086785]  [<ffffffff81495e80>] ? do_ip_setsockopt+0x90/0xd80
<4>[46267.086858]  [<ffffffff8100be0e>] ? call_function_interrupt+0xe/0x20
<4>[46267.086936]  [<ffffffff8118cb10>] ? ub_slab_ptr+0x20/0x90
<4>[46267.087006]  [<ffffffff8118cb10>] ? ub_slab_ptr+0x20/0x90
<4>[46267.087081]  [<ffffffff8118f2e8>] ? kmem_cache_alloc+0xd8/0x1e0
<4>[46267.087151]  [<ffffffff81445599>] sys_sendto+0x139/0x190
<4>[46267.087229]  [<ffffffff81448c0d>] ? sock_setsockopt+0x16d/0x6f0
<4>[46267.087303]  [<ffffffff810efa47>] ? audit_syscall_entry+0x1d7/0x200
<4>[46267.087378]  [<ffffffff810ef795>] ? __audit_syscall_exit+0x265/0x290
<4>[46267.087454]  [<ffffffff81474885>] ? compat_sys_setsockopt+0x75/0x210
<4>[46267.087531]  [<ffffffff81474b5f>] compat_sys_socketcall+0x13f/0x210
<4>[46267.087607]  [<ffffffff8104dea3>] ia32_sysret+0x0/0x5
<4>[46267.087676] Code: 91 20 e2 01 75 29 48 89 de 4c 89 f7 e8 56 fa ff ff 85 c0 0f 84 68 fc ff ff 0f b6 4d c6 41 8b 45 00 e9 4d fb ff ff e8 7c 19 e9 e0 <0f> 0b eb fe f6 05 17 91 20 e2 80 74 ce 80 3d 5f 2e 00 00 00 74
<1>[46267.088023] RIP  [<ffffffffa01e00a4>] nf_nat_setup_info+0x564/0x590

Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Florian Westphal <fw@strlen.de>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 net/netfilter/nf_conntrack_core.c | 21 +++++++++++++++++----
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 5d892febd64c..da541b78b88e 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -318,6 +318,21 @@ static void death_by_timeout(unsigned long ul_conntrack)
 	nf_ct_delete((struct nf_conn *)ul_conntrack, 0, 0);
 }
 
+static inline bool
+nf_ct_key_equal(struct nf_conntrack_tuple_hash *h,
+			const struct nf_conntrack_tuple *tuple,
+			u16 zone)
+{
+	struct nf_conn *ct = nf_ct_tuplehash_to_ctrack(h);
+
+	/* A conntrack can be recreated with the equal tuple,
+	 * so we need to check that the conntrack is confirmed
+	 */
+	return nf_ct_tuple_equal(tuple, &h->tuple) &&
+		nf_ct_zone(ct) == zone &&
+		nf_ct_is_confirmed(ct);
+}
+
 /*
  * Warning :
  * - Caller must take a reference on returned object
@@ -339,8 +354,7 @@ ____nf_conntrack_find(struct net *net, u16 zone,
 	local_bh_disable();
 begin:
 	hlist_nulls_for_each_entry_rcu(h, n, &net->ct.hash[bucket], hnnode) {
-		if (nf_ct_tuple_equal(tuple, &h->tuple) &&
-		    nf_ct_zone(nf_ct_tuplehash_to_ctrack(h)) == zone) {
+		if (nf_ct_key_equal(h, tuple, zone)) {
 			NF_CT_STAT_INC(net, found);
 			local_bh_enable();
 			return h;
@@ -387,8 +401,7 @@ begin:
 			     !atomic_inc_not_zero(&ct->ct_general.use)))
 			h = NULL;
 		else {
-			if (unlikely(!nf_ct_tuple_equal(tuple, &h->tuple) ||
-				     nf_ct_zone(ct) != zone)) {
+			if (unlikely(!nf_ct_key_equal(h, tuple, zone))) {
 				nf_ct_put(ct);
 				goto begin;
 			}
-- 
2.5.2

[PATCH 3.12 31/33] netfilter: nf_conntrack: don't release a conntrack with non-zero refcnt

[Jiri Slaby]

From: Pablo Neira Ayuso <pablo@netfilter.org>

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

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

[ Upstream commit e53376bef2cd97d3e3f61fdc677fb8da7d03d0da ]

With this patch, the conntrack refcount is initially set to zero and
it is bumped once it is added to any of the list, so we fulfill
Eric's golden rule which is that all released objects always have a
refcount that equals zero.

Andrey Vagin reports that nf_conntrack_free can't be called for a
conntrack with non-zero ref-counter, because it can race with
nf_conntrack_find_get().

A conntrack slab is created with SLAB_DESTROY_BY_RCU. Non-zero
ref-counter says that this conntrack is used. So when we release
a conntrack with non-zero counter, we break this assumption.

CPU1                                    CPU2
____nf_conntrack_find()
                                        nf_ct_put()
                                         destroy_conntrack()
                                        ...
                                        init_conntrack
                                         __nf_conntrack_alloc (set use = 1)
atomic_inc_not_zero(&ct->use) (use = 2)
                                         if (!l4proto->new(ct, skb, dataoff, timeouts))
                                          nf_conntrack_free(ct); (use = 2 !!!)
                                        ...
                                        __nf_conntrack_alloc (set use = 1)
 if (!nf_ct_key_equal(h, tuple, zone))
  nf_ct_put(ct); (use = 0)
   destroy_conntrack()
                                        /* continue to work with CT */

After applying the path "[PATCH] netfilter: nf_conntrack: fix RCU
race in nf_conntrack_find_get" another bug was triggered in
destroy_conntrack():

<4>[67096.759334] ------------[ cut here ]------------
<2>[67096.759353] kernel BUG at net/netfilter/nf_conntrack_core.c:211!
...
<4>[67096.759837] Pid: 498649, comm: atdd veid: 666 Tainted: G         C ---------------    2.6.32-042stab084.18 #1 042stab084_18 /DQ45CB
<4>[67096.759932] RIP: 0010:[<ffffffffa03d99ac>]  [<ffffffffa03d99ac>] destroy_conntrack+0x15c/0x190 [nf_conntrack]
<4>[67096.760255] Call Trace:
<4>[67096.760255]  [<ffffffff814844a7>] nf_conntrack_destroy+0x17/0x30
<4>[67096.760255]  [<ffffffffa03d9bb5>] nf_conntrack_find_get+0x85/0x130 [nf_conntrack]
<4>[67096.760255]  [<ffffffffa03d9fb2>] nf_conntrack_in+0x352/0xb60 [nf_conntrack]
<4>[67096.760255]  [<ffffffffa048c771>] ipv4_conntrack_local+0x51/0x60 [nf_conntrack_ipv4]
<4>[67096.760255]  [<ffffffff81484419>] nf_iterate+0x69/0xb0
<4>[67096.760255]  [<ffffffff814b5b00>] ? dst_output+0x0/0x20
<4>[67096.760255]  [<ffffffff814845d4>] nf_hook_slow+0x74/0x110
<4>[67096.760255]  [<ffffffff814b5b00>] ? dst_output+0x0/0x20
<4>[67096.760255]  [<ffffffff814b66d5>] raw_sendmsg+0x775/0x910
<4>[67096.760255]  [<ffffffff8104c5a8>] ? flush_tlb_others_ipi+0x128/0x130
<4>[67096.760255]  [<ffffffff8100bc4e>] ? apic_timer_interrupt+0xe/0x20
<4>[67096.760255]  [<ffffffff8100bc4e>] ? apic_timer_interrupt+0xe/0x20
<4>[67096.760255]  [<ffffffff814c136a>] inet_sendmsg+0x4a/0xb0
<4>[67096.760255]  [<ffffffff81444e93>] ? sock_sendmsg+0x13/0x140
<4>[67096.760255]  [<ffffffff81444f97>] sock_sendmsg+0x117/0x140
<4>[67096.760255]  [<ffffffff8102e299>] ? native_smp_send_reschedule+0x49/0x60
<4>[67096.760255]  [<ffffffff81519beb>] ? _spin_unlock_bh+0x1b/0x20
<4>[67096.760255]  [<ffffffff8109d930>] ? autoremove_wake_function+0x0/0x40
<4>[67096.760255]  [<ffffffff814960f0>] ? do_ip_setsockopt+0x90/0xd80
<4>[67096.760255]  [<ffffffff8100bc4e>] ? apic_timer_interrupt+0xe/0x20
<4>[67096.760255]  [<ffffffff8100bc4e>] ? apic_timer_interrupt+0xe/0x20
<4>[67096.760255]  [<ffffffff814457c9>] sys_sendto+0x139/0x190
<4>[67096.760255]  [<ffffffff810efa77>] ? audit_syscall_entry+0x1d7/0x200
<4>[67096.760255]  [<ffffffff810ef7c5>] ? __audit_syscall_exit+0x265/0x290
<4>[67096.760255]  [<ffffffff81474daf>] compat_sys_socketcall+0x13f/0x210
<4>[67096.760255]  [<ffffffff8104dea3>] ia32_sysret+0x0/0x5

I have reused the original title for the RFC patch that Andrey posted and
most of the original patch description.

Cc: Eric Dumazet <edumazet@google.com>
Cc: Andrew Vagin <avagin@parallels.com>
Cc: Florian Westphal <fw@strlen.de>
Reported-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Andrew Vagin <avagin@parallels.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 include/net/netfilter/nf_conntrack.h |  2 ++
 net/netfilter/nf_conntrack_core.c    | 34 +++++++++++++++++++++++++++++-----
 net/netfilter/nf_synproxy_core.c     |  5 ++---
 net/netfilter/xt_CT.c                |  7 +------
 4 files changed, 34 insertions(+), 14 deletions(-)

diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
index 0c1288a50e8b..a68a061882f4 100644
--- a/include/net/netfilter/nf_conntrack.h
+++ b/include/net/netfilter/nf_conntrack.h
@@ -293,6 +293,8 @@ extern unsigned int nf_conntrack_max;
 extern unsigned int nf_conntrack_hash_rnd;
 void init_nf_conntrack_hash_rnd(void);
 
+void nf_conntrack_tmpl_insert(struct net *net, struct nf_conn *tmpl);
+
 #define NF_CT_STAT_INC(net, count)	  __this_cpu_inc((net)->ct.stat->count)
 #define NF_CT_STAT_INC_ATOMIC(net, count) this_cpu_inc((net)->ct.stat->count)
 
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index da541b78b88e..cf9bfc5ddb34 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -463,7 +463,9 @@ nf_conntrack_hash_check_insert(struct nf_conn *ct)
 			goto out;
 
 	add_timer(&ct->timeout);
-	nf_conntrack_get(&ct->ct_general);
+	smp_wmb();
+	/* The caller holds a reference to this object */
+	atomic_set(&ct->ct_general.use, 2);
 	__nf_conntrack_hash_insert(ct, hash, repl_hash);
 	NF_CT_STAT_INC(net, insert);
 	spin_unlock_bh(&nf_conntrack_lock);
@@ -477,6 +479,21 @@ out:
 }
 EXPORT_SYMBOL_GPL(nf_conntrack_hash_check_insert);
 
+/* deletion from this larval template list happens via nf_ct_put() */
+void nf_conntrack_tmpl_insert(struct net *net, struct nf_conn *tmpl)
+{
+	__set_bit(IPS_TEMPLATE_BIT, &tmpl->status);
+	__set_bit(IPS_CONFIRMED_BIT, &tmpl->status);
+	nf_conntrack_get(&tmpl->ct_general);
+
+	spin_lock_bh(&nf_conntrack_lock);
+	/* Overload tuple linked list to put us in template list. */
+	hlist_nulls_add_head_rcu(&tmpl->tuplehash[IP_CT_DIR_ORIGINAL].hnnode,
+				 &net->ct.tmpl);
+	spin_unlock_bh(&nf_conntrack_lock);
+}
+EXPORT_SYMBOL_GPL(nf_conntrack_tmpl_insert);
+
 /* Confirm a connection given skb; places it in hash table */
 int
 __nf_conntrack_confirm(struct sk_buff *skb)
@@ -748,11 +765,10 @@ __nf_conntrack_alloc(struct net *net, u16 zone,
 		nf_ct_zone->id = zone;
 	}
 #endif
-	/*
-	 * changes to lookup keys must be done before setting refcnt to 1
+	/* Because we use RCU lookups, we set ct_general.use to zero before
+	 * this is inserted in any list.
 	 */
-	smp_wmb();
-	atomic_set(&ct->ct_general.use, 1);
+	atomic_set(&ct->ct_general.use, 0);
 	return ct;
 
 #ifdef CONFIG_NF_CONNTRACK_ZONES
@@ -776,6 +792,11 @@ void nf_conntrack_free(struct nf_conn *ct)
 {
 	struct net *net = nf_ct_net(ct);
 
+	/* A freed object has refcnt == 0, that's
+	 * the golden rule for SLAB_DESTROY_BY_RCU
+	 */
+	NF_CT_ASSERT(atomic_read(&ct->ct_general.use) == 0);
+
 	nf_ct_ext_destroy(ct);
 	atomic_dec(&net->ct.count);
 	nf_ct_ext_free(ct);
@@ -870,6 +891,9 @@ init_conntrack(struct net *net, struct nf_conn *tmpl,
 		NF_CT_STAT_INC(net, new);
 	}
 
+	/* Now it is inserted into the unconfirmed list, bump refcount */
+	nf_conntrack_get(&ct->ct_general);
+
 	/* Overload tuple linked list to put us in unconfirmed list. */
 	hlist_nulls_add_head_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode,
 		       &net->ct.unconfirmed);
diff --git a/net/netfilter/nf_synproxy_core.c b/net/netfilter/nf_synproxy_core.c
index cdf4567ba9b3..bf6e9a144dac 100644
--- a/net/netfilter/nf_synproxy_core.c
+++ b/net/netfilter/nf_synproxy_core.c
@@ -362,9 +362,8 @@ static int __net_init synproxy_net_init(struct net *net)
 		goto err2;
 	if (!nfct_synproxy_ext_add(ct))
 		goto err2;
-	__set_bit(IPS_TEMPLATE_BIT, &ct->status);
-	__set_bit(IPS_CONFIRMED_BIT, &ct->status);
 
+	nf_conntrack_tmpl_insert(net, ct);
 	snet->tmpl = ct;
 
 	snet->stats = alloc_percpu(struct synproxy_stats);
@@ -389,7 +388,7 @@ static void __net_exit synproxy_net_exit(struct net *net)
 {
 	struct synproxy_net *snet = synproxy_pernet(net);
 
-	nf_conntrack_free(snet->tmpl);
+	nf_ct_put(snet->tmpl);
 	synproxy_proc_exit(net);
 	free_percpu(snet->stats);
 }
diff --git a/net/netfilter/xt_CT.c b/net/netfilter/xt_CT.c
index da35ac06a975..889960193544 100644
--- a/net/netfilter/xt_CT.c
+++ b/net/netfilter/xt_CT.c
@@ -226,12 +226,7 @@ static int xt_ct_tg_check(const struct xt_tgchk_param *par,
 			goto err3;
 	}
 
-	__set_bit(IPS_TEMPLATE_BIT, &ct->status);
-	__set_bit(IPS_CONFIRMED_BIT, &ct->status);
-
-	/* Overload tuple linked list to put us in template list. */
-	hlist_nulls_add_head_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode,
-				 &par->net->ct.tmpl);
+	nf_conntrack_tmpl_insert(par->net, ct);
 out:
 	info->ct = ct;
 	return 0;
-- 
2.5.2

[PATCH 3.12 32/33] PCI: Add dev_flags bit to access VPD through function 0

[Jiri Slaby]

From: Mark Rustad <mark.d.rustad@intel.com>

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

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

commit 932c435caba8a2ce473a91753bad0173269ef334 upstream.

Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through
function 0 to provide VPD access on other functions.  This is for hardware
devices that provide copies of the same VPD capability registers in
multiple functions.  Because the kernel expects that each function has its
own registers, both the locking and the state tracking are affected by VPD
accesses to different functions.

On such devices for example, if a VPD write is performed on function 0,
*any* later attempt to read VPD from any other function of that device will
hang.  This has to do with how the kernel tracks the expected value of the
F bit per function.

Concurrent accesses to different functions of the same device can not only
hang but also corrupt both read and write VPD data.

When hangs occur, typically the error message:

  vpd r/w failed.  This is likely a firmware bug on this device.

will be seen.

Never set this bit on function 0 or there will be an infinite recursion.

Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/pci/access.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++-
 include/linux/pci.h  |  2 ++
 2 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 0857ca981fae..6bc9b12ba42a 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -359,6 +359,56 @@ static const struct pci_vpd_ops pci_vpd_pci22_ops = {
 	.release = pci_vpd_pci22_release,
 };
 
+static ssize_t pci_vpd_f0_read(struct pci_dev *dev, loff_t pos, size_t count,
+			       void *arg)
+{
+	struct pci_dev *tdev = pci_get_slot(dev->bus, PCI_SLOT(dev->devfn));
+	ssize_t ret;
+
+	if (!tdev)
+		return -ENODEV;
+
+	ret = pci_read_vpd(tdev, pos, count, arg);
+	pci_dev_put(tdev);
+	return ret;
+}
+
+static ssize_t pci_vpd_f0_write(struct pci_dev *dev, loff_t pos, size_t count,
+				const void *arg)
+{
+	struct pci_dev *tdev = pci_get_slot(dev->bus, PCI_SLOT(dev->devfn));
+	ssize_t ret;
+
+	if (!tdev)
+		return -ENODEV;
+
+	ret = pci_write_vpd(tdev, pos, count, arg);
+	pci_dev_put(tdev);
+	return ret;
+}
+
+static const struct pci_vpd_ops pci_vpd_f0_ops = {
+	.read = pci_vpd_f0_read,
+	.write = pci_vpd_f0_write,
+	.release = pci_vpd_pci22_release,
+};
+
+static int pci_vpd_f0_dev_check(struct pci_dev *dev)
+{
+	struct pci_dev *tdev = pci_get_slot(dev->bus, PCI_SLOT(dev->devfn));
+	int ret = 0;
+
+	if (!tdev)
+		return -ENODEV;
+	if (!tdev->vpd || !tdev->multifunction ||
+	    dev->class != tdev->class || dev->vendor != tdev->vendor ||
+	    dev->device != tdev->device)
+		ret = -ENODEV;
+
+	pci_dev_put(tdev);
+	return ret;
+}
+
 int pci_vpd_pci22_init(struct pci_dev *dev)
 {
 	struct pci_vpd_pci22 *vpd;
@@ -367,12 +417,21 @@ int pci_vpd_pci22_init(struct pci_dev *dev)
 	cap = pci_find_capability(dev, PCI_CAP_ID_VPD);
 	if (!cap)
 		return -ENODEV;
+	if (dev->dev_flags & PCI_DEV_FLAGS_VPD_REF_F0) {
+		int ret = pci_vpd_f0_dev_check(dev);
+
+		if (ret)
+			return ret;
+	}
 	vpd = kzalloc(sizeof(*vpd), GFP_ATOMIC);
 	if (!vpd)
 		return -ENOMEM;
 
 	vpd->base.len = PCI_VPD_PCI22_SIZE;
-	vpd->base.ops = &pci_vpd_pci22_ops;
+	if (dev->dev_flags & PCI_DEV_FLAGS_VPD_REF_F0)
+		vpd->base.ops = &pci_vpd_f0_ops;
+	else
+		vpd->base.ops = &pci_vpd_pci22_ops;
 	mutex_init(&vpd->lock);
 	vpd->cap = cap;
 	vpd->busy = false;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 573c04929bd1..b11e6e280f15 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -170,6 +170,8 @@ enum pci_dev_flags {
 	PCI_DEV_FLAGS_NO_D3 = (__force pci_dev_flags_t) 2,
 	/* Provide indication device is assigned by a Virtual Machine Manager */
 	PCI_DEV_FLAGS_ASSIGNED = (__force pci_dev_flags_t) 4,
+	/* Get VPD from function 0 VPD */
+	PCI_DEV_FLAGS_VPD_REF_F0 = (__force pci_dev_flags_t) (1 << 8),
 };
 
 enum pci_irq_reroute_variant {
-- 
2.5.2

[PATCH 3.12 33/33] PCI: Add VPD function 0 quirk for Intel Ethernet devices

[Jiri Slaby]

From: Mark Rustad <mark.d.rustad@intel.com>

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

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

commit 7aa6ca4d39edf01f997b9e02cf6d2fdeb224f351 upstream.

Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device
functions other than function 0, so that on multi-function devices, we will
always read VPD from function 0 instead of from the other functions.

[bhelgaas: changelog]
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
 drivers/pci/quirks.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index a7b7eeaf35e8..877bfbb4e55c 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1849,6 +1849,15 @@ static void quirk_netmos(struct pci_dev *dev)
 DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_NETMOS, PCI_ANY_ID,
 			 PCI_CLASS_COMMUNICATION_SERIAL, 8, quirk_netmos);
 
+static void quirk_f0_vpd_link(struct pci_dev *dev)
+{
+	if (!dev->multifunction || !PCI_FUNC(dev->devfn))
+		return;
+	dev->dev_flags |= PCI_DEV_FLAGS_VPD_REF_F0;
+}
+DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
+			      PCI_CLASS_NETWORK_ETHERNET, 8, quirk_f0_vpd_link);
+
 static void quirk_e100_interrupt(struct pci_dev *dev)
 {
 	u16 command, pmcsr;
-- 
2.5.2

Re: [PATCH 3.12 00/33] 3.12.48-stable review

[Nikolay Borisov]

Hi Jiry,


Maybe you would want to consider this:
https://patchwork.ozlabs.org/patch/459088/

It has already found its ways in other stable kernels, despite not being
cc'ed to stable.

Regards,
Nikolay

On 09/15/2015 05:22 PM, Jiri Slaby wrote:
> This is the start of the stable review cycle for the 3.12.48 release.
> There are 33 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Sep 17 16:20:25 CEST 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.48-rc1.xz
> and the diffstat can be found below.
> 
> thanks,
> js
> 
> ===============
> 
> 
> Akinobu Mita (1):
>   bio: fix argument of __bio_add_page() for max_sectors > 0xffff
> 
> Andrey Vagin (1):
>   netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get
> 
> Angga (1):
>   ipv6: Make MLD packets to only be processed locally
> 
> Benjamin LaHaise (1):
>   aio: fix reqs_available handling
> 
> Dan Carpenter (1):
>   rds: fix an integer overflow test in rds_info_getsockopt()
> 
> Daniel Borkmann (1):
>   rtnetlink: verify IFLA_VF_INFO attributes before passing them to
>     driver
> 
> Dave Airlie (1):
>   drm/radeon: fix hotplug race at startup
> 
> David Milburn (1):
>   mtip32xx: dynamically allocate buffer in debugfs functions
> 
> Edward Hyunkoo Jee (1):
>   inet: frags: fix defragmented packet's IP header for af_packet
> 
> Eric Dumazet (2):
>   net: graceful exit from netif_alloc_netdev_queues()
>   ipv6: lock socket in ip6_datagram_connect()
> 
> Florian Westphal (1):
>   netlink: don't hold mutex in rcu callback when releasing mmapd ring
> 
> Heinz Mauelshagen (1):
>   dm cache mq: fix memory allocation failure for large cache devices
> 
> Herbert Xu (3):
>   net: Clone skb before setting peeked flag
>   net: Fix skb csum races when peeking
>   net: Fix skb_set_peeked use-after-free bug
> 
> Jack Morgenstein (1):
>   net/mlx4_core: Fix wrong index in propagating port change event to VFs
> 
> James Smart (1):
>   lpfc: Fix scsi prep dma buf error.
> 
> Julian Anastasov (2):
>   net: do not process device backlog during unregistration
>   net: call rcu_read_lock early in process_backlog
> 
> Mark Rustad (2):
>   PCI: Add dev_flags bit to access VPD through function 0
>   PCI: Add VPD function 0 quirk for Intel Ethernet devices
> 
> Mika Westerberg (1):
>   mfd: lpc_ich: Assign subdevice ids automatically
> 
> Nikolay Aleksandrov (3):
>   bridge: mdb: zero out the local br_ip variable before use
>   bridge: mdb: fix double add notification
>   bonding: fix destruction of bond with devices different from
>     arphrd_ether
> 
> Oleg Nesterov (1):
>   net: pktgen: fix race between pktgen_thread_worker() and
>     kthread_stop()
> 
> Pablo Neira Ayuso (1):
>   netfilter: nf_conntrack: don't release a conntrack with non-zero
>     refcnt
> 
> Shirish Pargaonkar (1):
>   cifs: Send a logoff request before removing a smb session
> 
> Stephen Smalley (1):
>   net/tipc: initialize security state for new connection socket
> 
> Tilman Schmidt (1):
>   isdn/gigaset: reset tty->receive_room when attaching ser_gigaset
> 
> Timo Teräs (1):
>   ip_tunnel: fix ipv4 pmtu check to honor inner ip header df
> 
> dingtianhong (1):
>   bonding: correct the MAC address for "follow" fail_over_mac policy
> 
>  drivers/block/mtip32xx/mtip32xx.c       |  47 +++++++++---
>  drivers/gpu/drm/radeon/radeon_irq_kms.c |   5 ++
>  drivers/isdn/gigaset/ser-gigaset.c      |  11 ++-
>  drivers/md/dm-cache-policy-mq.c         |   4 +-
>  drivers/mfd/lpc_ich.c                   |   8 +-
>  drivers/net/bonding/bond_main.c         |  20 +++++
>  drivers/net/ethernet/mellanox/mlx4/eq.c |   4 +-
>  drivers/pci/access.c                    |  61 ++++++++++++++-
>  drivers/pci/quirks.c                    |   9 +++
>  drivers/scsi/lpfc/lpfc_scsi.c           |   2 +-
>  fs/aio.c                                |  77 ++++++++++++++++++-
>  fs/bio.c                                |   2 +-
>  fs/cifs/connect.c                       |  25 +++++--
>  fs/cifs/smb2transport.c                 |  10 ++-
>  fs/cifs/transport.c                     |  11 ++-
>  include/linux/pci.h                     |   2 +
>  include/net/ip.h                        |   1 +
>  include/net/netfilter/nf_conntrack.h    |   2 +
>  net/bridge/br_mdb.c                     |   3 +-
>  net/core/datagram.c                     |  45 ++++++++++-
>  net/core/dev.c                          |  38 +++++-----
>  net/core/pktgen.c                       |   4 +-
>  net/core/rtnetlink.c                    | 128 ++++++++++++++++----------------
>  net/ipv4/datagram.c                     |  16 +++-
>  net/ipv4/ip_fragment.c                  |   7 +-
>  net/ipv4/ip_tunnel.c                    |   8 +-
>  net/ipv6/datagram.c                     |  20 +++--
>  net/ipv6/ip6_input.c                    |   6 +-
>  net/netfilter/nf_conntrack_core.c       |  55 +++++++++++---
>  net/netfilter/nf_synproxy_core.c        |   5 +-
>  net/netfilter/xt_CT.c                   |   7 +-
>  net/netlink/af_netlink.c                |  79 ++++++++++++--------
>  net/rds/info.c                          |   2 +-
>  net/tipc/socket.c                       |   1 +
>  34 files changed, 535 insertions(+), 190 deletions(-)
> 

Re: [PATCH 3.12 00/33] 3.12.48-stable review

[Shuah Khan]

On 09/15/2015 08:22 AM, Jiri Slaby wrote:
> This is the start of the stable review cycle for the 3.12.48 release.
> There are 33 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Sep 17 16:20:25 CEST 2015.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.48-rc1.xz
> and the diffstat can be found below.
> 
> thanks,
> js

Jiri,

I am seeing problems during PCI scans with this patch. I had
to boot it in recovery mode once and it is booting fine after
that, however, this is a concern

Could these be the reason?

Mark Rustad (2):
  PCI: Add dev_flags bit to access VPD through function 0
  PCI: Add VPD function 0 quirk for Intel Ethernet devices


PCI-DMA: Intel(R) Virtualization Technology for Directed I/O
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/pci/search.c:46
pci_find_upstream_pcie_bridge+
0x65/0x90()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.48+ #29
Hardware name: System76, Inc. Wild Dog Performance/H87-PLUS, BIOS 0705
12/05/201
3
 0000000000000009 ffff88040952bd28 ffffffff81718bd7 0000000000000000
 ffff88040952bd60 ffffffff8106497d ffff88040801c098 ffff88040801c000
 ffff88040801c098 0000000000000000 ffff88040f0058a0 ffff88040952bd70
Call Trace:
 [<ffffffff81718bd7>] dump_stack+0x45/0x56
 [<ffffffff8106497d>] warn_slowpath_common+0x7d/0xa0
 [<ffffffff81064a5a>] warn_slowpath_null+0x1a/0x20
 [<ffffffff813b75d5>] pci_find_upstream_pcie_bridge+0x65/0x90
 [<ffffffff815fb10d>] intel_iommu_add_device+0x4d/0x220
 [<ffffffff815f2000>] ? bus_set_iommu+0x50/0x50
 [<ffffffff815f202a>] add_iommu_group+0x2a/0x60
 [<ffffffff81497aab>] bus_for_each_dev+0x6b/0xb0
 [<ffffffff815f1ff8>] bus_set_iommu+0x48/0x50
 [<ffffffff81d93ef3>] intel_iommu_init+0xa9d/0xb9c
 [<ffffffff81d4a730>] ? memblock_find_dma_reserve+0x124/0x124
 [<ffffffff81d4a742>] pci_iommu_init+0x12/0x3c
 [<ffffffff810020d2>] do_one_initcall+0xd2/0x1a0
 [<ffffffff81087700>] ? parse_args+0x160/0x490
 [<ffffffff81d40ef6>] kernel_init_freeable+0x144/0x1cc
 [<ffffffff8170cfe0>] ? rest_init+0x80/0x80
 [<ffffffff8170cfee>] kernel_init+0xe/0x190
 [<ffffffff81728fd8>] ret_from_fork+0x58/0x90
 [<ffffffff8170cfe0>] ? rest_init+0x80/0x80
---[ end trace 6540c4180167ec85 ]---
Scanning for low memory corruption every 60 seconds
Initialise module verification
audit: initializing netlink socket (disabled)
type=2000 audit(1442332755.772:1): initialized
bounce pool size: 64 pages
HugeTLB registered 2 MB page size, pre-allocated 0 pages
zbud: loaded



-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978

Re: [PATCH 3.12 00/33] 3.12.48-stable review

[Guenter Roeck]

On 09/15/2015 07:22 AM, Jiri Slaby wrote:
> This is the start of the stable review cycle for the 3.12.48 release.
> There are 33 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu Sep 17 16:20:25 CEST 2015.
> Anything received after that time might be too late.
>

Build results:
	total: 123 pass: 123 fail: 0
Qemu test results:
	total: 76 pass: 76 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

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

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]

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)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[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
>> <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

Re: [PATCH 3.12 00/33] 3.12.48-stable review

[Jiri Slaby]

On 09/15/2015, 06:12 PM, Shuah Khan wrote:
> On 09/15/2015 08:22 AM, Jiri Slaby wrote:
>> This is the start of the stable review cycle for the 3.12.48 release.
>> There are 33 patches in this series, all will be posted as a response
>> to this one.  If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Thu Sep 17 16:20:25 CEST 2015.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>> 	http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.48-rc1.xz
>> and the diffstat can be found below.
>>
>> thanks,
>> js
> 
> Jiri,
> 
> I am seeing problems during PCI scans with this patch. I had
> to boot it in recovery mode once and it is booting fine after
> that, however, this is a concern
> 
> Could these be the reason?
> 
> Mark Rustad (2):
>   PCI: Add dev_flags bit to access VPD through function 0
>   PCI: Add VPD function 0 quirk for Intel Ethernet devices

Hi, maybe. Could you either revert those patches or test commit
a7775d15b11a277f8af from this tree:
git://git.kernel.org/pub/scm/linux/kernel/git/jirislaby/linux-stable.git
to verify?

thanks,
-- 
js
suse labs

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

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]

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)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 3.12 00/33] 3.12.48-stable review

[Jiri Slaby]

On 09/15/2015, 04:53 PM, Nikolay Borisov wrote:
> Maybe you would want to consider this:
> https://patchwork.ozlabs.org/patch/459088/
> 
> It has already found its ways in other stable kernels, despite not being
> cc'ed to stable.

Hi, it does not apply to 3.12 and is not in 3.14 where I source patches
from too. So you would have to provide a backport...

thanks,
-- 
js
suse labs

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

[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?
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

Re: [PATCH 3.12 00/33] 3.12.48-stable review

[Jiri Slaby]

On 09/15/2015, 06:12 PM, Shuah Khan wrote:
> On 09/15/2015 08:22 AM, Jiri Slaby wrote:
>> This is the start of the stable review cycle for the 3.12.48 release.
>> There are 33 patches in this series, all will be posted as a response
>> to this one.  If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Thu Sep 17 16:20:25 CEST 2015.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>> 	http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.48-rc1.xz
>> and the diffstat can be found below.
>>
>> thanks,
>> js
> 
> Jiri,
> 
> I am seeing problems during PCI scans with this patch. I had
> to boot it in recovery mode once and it is booting fine after
> that, however, this is a concern
> 
> Could these be the reason?
> 
> Mark Rustad (2):
>   PCI: Add dev_flags bit to access VPD through function 0
>   PCI: Add VPD function 0 quirk for Intel Ethernet devices

Ok, so I released 3.12.48 without these two, but left them in the queue
for the next release as they don't look as they caused the issue. If you
can confirm whether they introduce the problem or not, it would be great.

thanks,
-- 
js
suse labs

Re: [PATCH 3.12 00/33] 3.12.48-stable review

[Jiri Slaby]

On 09/15/2015, 06:27 PM, Guenter Roeck wrote:
> Build results:
>     total: 123 pass: 123 fail: 0
> Qemu test results:
>     total: 76 pass: 76 fail: 0
> 
> Details are available at http://server.roeck-us.net:8010/builders.

Thanks.

-- 
js
suse labs

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

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 3896 bytes --]

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)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 3.12 00/33] 3.12.48-stable review

[Rustad, Mark D]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

> On Sep 18, 2015, at 1:11 AM, Jiri Slaby <jslaby@suse.cz> wrote:
> 
> On 09/15/2015, 06:12 PM, Shuah Khan wrote:
>> 
>> 
>> Jiri,
>> 
>> I am seeing problems during PCI scans with this patch. I had
>> to boot it in recovery mode once and it is booting fine after
>> that, however, this is a concern
>> 
>> Could these be the reason?
>> 
>> Mark Rustad (2):
>>  PCI: Add dev_flags bit to access VPD through function 0
>>  PCI: Add VPD function 0 quirk for Intel Ethernet devices
> 
> Ok, so I released 3.12.48 without these two, but left them in the queue
> for the next release as they don't look as they caused the issue. If you
> can confirm whether they introduce the problem or not, it would be great.

I haven't been able to see a way for the patches to be involved, but I have no objection to deferring these. My only concern is what the cause actually was.

--
Mark Rustad, Networking Division, Intel Corporation


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 841 bytes --]

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

[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:
>>> 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 

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

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

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)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 2976 bytes --]



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:

[...]

>>> 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.

Indeed it does. I stand corrected. The possibility of running ldattach a
second time without terminating the first instance didn't occur to me.

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

I don't do regression tests for the driver anymore since I stepped down
as a maintainer, so that would be up to the present maintainer of
ser_gigaset. But I see no reason for that. As I already explained, N_TTY
is the only problematic case.

>>> 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.

If you'd care to look at the actual code you'd notice that it truly
won't make any difference. The receive_buf() method of ser_gigaset is
prepared to drop data and log an error when its receive buffer
overflows, no matter how big the block of data passed from tty core is.
The only difference a smaller ->receive_room value might possibly make
is to distribute the overflowing data to more receive_buf() calls.

(Note that the Gigaset M101 device operates at 115200 bits/sec max. so
it takes at least 700 msecs to transmit 8k bytes. If we ever get into a
situation where tty core actually accumulates more than that amount of
data before forwarding it to GIGASET_M101 then we have a more serious
problem anyway.)

Again, I won't oppose applying this patch to stable releases before
3.10. I just don't see the need, so it would be up to you to advocate
such a request.

-- 
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)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[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

Regards,
Peter Hurley

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

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

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)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Paul Bolle]

On ma, 2015-09-21 at 18:07 +0200, Tilman Schmidt wrote:
> Am 21.09.2015 um 15:13 schrieb Peter Hurley:
> > ???
> > 
> > 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.
> 
> Indeed it does. I stand corrected. The possibility of running ldattach a
> second time without terminating the first instance didn't occur to me.

Naive question: when would running ldattach a second time make sense?

> > Please add switching from line disciplines other than N_TTY to your
> > regression testing.
> 
> I don't do regression tests for the driver anymore since I stepped down
> as a maintainer, so that would be up to the present maintainer of
> ser_gigaset. But I see no reason for that. As I already explained, N_TTY
> is the only problematic case.

I'm the current maintainer. (By virtue of having a stash of gigaset
hardware _and_ an ISDN capable line _and_ an ISP that still answers when
I do ISDN dial up. That ISP also does ADSL, which I actually use on a
day to day basis.) I try to test whether ISDN still has a pulse, every
RC, but I can't promise much.

(Off topic: does anyone actually _care_ about ISDN? It seems the other
two ISDN maintainers all have effectively left mainline. Now I'm happy
to (lightly!) test mainline ISDN support as long as that's feasible, but
I'd _really_ like to hear from people using ISDN on machines running
currently supported kernels. Are there any left?)

> Again, I won't oppose applying this patch to stable releases before
> 3.10. I just don't see the need, so it would be up to you to advocate
> such a request.

That would be fixing a theoretical problem, as apparently no one managed
to hit this problem before v3.10 _in practice_, so that's not something
I see a need for either.

Thanks,


Paul Bolle

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

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

Paul,

Am 06.10.2015 um 23:00 schrieb Paul Bolle:
> On ma, 2015-09-21 at 18:07 +0200, Tilman Schmidt wrote:
>> Am 21.09.2015 um 15:13 schrieb Peter Hurley:
>>> ???
>>>
>>> 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.
>>
>> Indeed it does. I stand corrected. The possibility of running ldattach a
>> second time without terminating the first instance didn't occur to me.
> 
> Naive question: when would running ldattach a second time make sense?

Peter's argument wasn't about making sense, but about operator error.
While it doesn't make any sense indeed to run two instances of ldattach
in parallel on one and the same serial port, it is entirely conceivable
that someone might do so inadvertently, by not being aware that one is
running already.

Best 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)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

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

[Paul Bolle]

[Dropped stable from Cc:. I can't see how this is still relevant for
that list.]

Hi Tilman,

On ma, 2015-10-12 at 11:18 +0200, Tilman Schmidt wrote:
> While it doesn't make any sense indeed to run two instances of
> ldattach
> in parallel on one and the same serial port, it is entirely conceivable
> that someone might do so inadvertently, by not being aware that one is
> running already.

I'm wandering off topic a bit, but doesn't that imply that ldattach
should bail out with an error if someone tries to do that?


Paul Bolle

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

[Tilman Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

Hi Paul,

Am 19.10.2015 um 11:09 schrieb Paul Bolle:
> On ma, 2015-10-12 at 11:18 +0200, Tilman Schmidt wrote:
>> While it doesn't make any sense indeed to run two instances of
>> ldattach
>> in parallel on one and the same serial port, it is entirely conceivable
>> that someone might do so inadvertently, by not being aware that one is
>> running already.
> 
> I'm wandering off topic a bit, but doesn't that imply that ldattach
> should bail out with an error if someone tries to do that?

I'm of two minds about this. On the pro side, it might prevent some
surprises. But on the other hand, nothing actually breaks if someone
does, and I'm not 100% sure there are really no legitimate scenarios.
Add to this that I don't have a clear idea how to actually implement
such a bailout, and that I'm really short of time. So I'm reluctant to
tackle this topic.

Perhaps the best way forward would be someone (not me) submitting a
patch to ldattach, thereby triggering a discussion of the pros and cons
that would ideally include all (or most) ldattach users and consider all
line disciplines it is used with.

-- 
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)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]