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

Groups > linux.kernel > #1675907 > unrolled thread

Re: [next-20170609] Oops while running CPU off-on (cpuset.c/cpuset_can_attach)

Back to article view | Back to linux.kernel

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

Contents

  Re: [next-20170609] Oops while running CPU off-on  (cpuset.c/cpuset_can_attach) Tejun Heo <tj@kernel.org> - 2017-06-27 17:40 +0200
    Re: [next-20170609] Oops while running CPU off-on  (cpuset.c/cpuset_can_attach) Abdul Haleem <abdhalee@linux.vnet.ibm.com> - 2017-07-03 16:40 +0200
      Re: [next-20170609] Oops while running CPU off-on  (cpuset.c/cpuset_can_attach) Tejun Heo <tj@kernel.org> - 2017-07-05 17:30 +0200
        Re: [next-20170609] Oops while running CPU off-on  (cpuset.c/cpuset_can_attach) Abdul Haleem <abdhalee@linux.vnet.ibm.com> - 2017-07-07 08:50 +0200
          [PATCH cgroup/for-4.13-fixes] cgroup: don't call migration methods  if there are no tasks to migrate Tejun Heo <tj@kernel.org> - 2017-07-08 13:50 +0200

#1675907 — Re: [next-20170609] Oops while running CPU off-on (cpuset.c/cpuset_can_attach)

Hello, Abdul.

Sorry about the long delay.

On Mon, Jun 12, 2017 at 04:53:42PM +0530, Abdul Haleem wrote:
> linux-next kernel crashed while running CPU offline and online.
> 
> Machine: Power 8 LPAR
> Kernel : 4.12.0-rc4-next-20170609
> gcc : version 5.2.1
> config: attached
> testcase: CPU off/on
> 
> for i in $(seq 100);do 
>     for j in $(seq 0 15);do 
>         echo 0 >  /sys/devices/system/cpu/cpu$j/online
>         sleep 5
>         echo 1 > /sys/devices/system/cpu/cpu$j/online
>     done
> done
> 
...
> NIP [c0000000001d6868] cpuset_can_attach+0x58/0x1b0

Can you please map this to the source line?

> LR [c0000000001d6858] cpuset_can_attach+0x48/0x1b0
> Call Trace:
> [c00000000c72b9a0] [c0000000001d6858] cpuset_can_attach+0x48/0x1b0
> (unreliable)
> [c00000000c72ba00] [c0000000001cbe80] cgroup_migrate_execute+0xb0/0x450
> [c00000000c72ba80] [c0000000001d3754] cgroup_transfer_tasks+0x1c4/0x360
> [c00000000c72bba0] [c0000000001d923c] cpuset_hotplug_workfn+0x86c/0xa20
> [c00000000c72bca0] [c00000000011aa44] process_one_work+0x1e4/0x580
> [c00000000c72bd30] [c00000000011ae78] worker_thread+0x98/0x5c0
> [c00000000c72bdc0] [c000000000124058] kthread+0x168/0x1b0
> [c00000000c72be30] [c00000000000b2e8] ret_from_kernel_thread+0x5c/0x74
> Instruction dump:
> f821ffa1 7c7d1b78 60000000 60000000 38810020 7fa3eb78 3f42ffed 4bff4c25 
> 60000000 3b5a0448 3d420020 eb610020 <e9230960> 7f43d378 e9290000
> f92af200 

Thanks.

-- 
tejun

[toc] | [next] | [standalone]

#1680315

On Tue, 2017-06-27 at 11:36 -0400, Tejun Heo wrote:
> Hello, Abdul.
> 
> Sorry about the long delay.
> 
> On Mon, Jun 12, 2017 at 04:53:42PM +0530, Abdul Haleem wrote:
> > linux-next kernel crashed while running CPU offline and online.
> > 
> > Machine: Power 8 LPAR
> > Kernel : 4.12.0-rc4-next-20170609
> > gcc : version 5.2.1
> > config: attached
> > testcase: CPU off/on
> > 
> > for i in $(seq 100);do 
> >     for j in $(seq 0 15);do 
> >         echo 0 >  /sys/devices/system/cpu/cpu$j/online
> >         sleep 5
> >         echo 1 > /sys/devices/system/cpu/cpu$j/online
> >     done
> > done
> > 
> ...
> > NIP [c0000000001d6868] cpuset_can_attach+0x58/0x1b0
> 
> Can you please map this to the source line?

Hi Tejun,

Was able to recreate on latest next kernel, from the new trace.

Unable to handle kernel paging request for data at address 0x000009e0
Faulting instruction address: 0xc0000000001dd688

which is:
c0000000001dd688 <cpuset_can_attach+0x58> e0 09 23 e9 ld  r9,2528(r3)

r9 = c000000775cd7950, 2528(0000000000000000) = 0x000009e0


Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=2048 
NUMA 
pSeries
Modules linked in: xt_addrtype xt_conntrack ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 iptable_filter ip_tables x_tables nf_nat nf_conntrack bridge
stp llc dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c
vmx_crypto rtc_generic pseries_rng autofs4
CPU: 15 PID: 120 Comm: kworker/15:1 Tainted: G        W
4.12.0-rc7-next-20170630-autotest #1
Workqueue: events cpuset_hotplug_workfn
task: c000000775c5e300 task.stack: c000000775cd4000
NIP: c0000000001dd688 LR: c0000000001dd678 CTR: c0000000001dd630
REGS: c000000775cd7730 TRAP: 0300   Tainted: G        W
(4.12.0-rc7-next-20170630-autotest)
MSR: 800000010280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]>
  CR: 44a32222  XER: 20000000
CFAR: c000000000008718 DAR: 00000000000009e0 DSISR: 40000000 SOFTE: 1
GPR00: c0000000001dd678 c000000775cd79b0 c00000000154a400
0000000000000000 
GPR04: c000000775cd79d0 0000000000000000 c000000775cd7ad0
c0000000fb1de480
GPR08: c0000000fb1dda98 c000000775cd7950 c00000000174a400
0000000000000000  
GPR12: c0000000001dd630 c00000000e789600 c000000000128dc8
c000000776bb0080 
GPR16: 0000000000000000 0000000000000000 c00000000bcc91c0
c00000000bcc91e0 
GPR20: c00000000bcc90c0 0000000000000000 0000000000000000
0000000000000000 
GPR24: 0000000000000000 c000000775cd7a30 c000000001428020
c000000001745cdc 
GPR28: c000000001427130 c000000775cd7ac0 c00000000b41b588
0000000000000000 
NIP [c0000000001dd688] cpuset_can_attach+0x58/0x1b0

> gdb -batch vmlinux -ex 'list *(0xc0000000001dd688)'

0xc0000000001dd688 is in cpuset_can_attach (./include/linux/compiler.h:250).
245	})
246	
247	static __always_inline
248	void __read_once_size(const volatile void *p, void *res, int size)
249	{
250		__READ_ONCE_SIZE;
251	}
252	
253	#ifdef CONFIG_KASAN
254	/*

Does this helps, please let me know if you need more debugging. Thanks

-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre

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

#1681584

Hello, Abdul.

Thanks for the debug info.  Can you please see whether the following
patch fixes the issue?  If the problem is too difficult to reproduce
to confirm the fix by seeing whether it no longer triggers, please let
me know.  We can instead apply a patch which triggers WARN on the
failing condition to confirm the diagnosis.

Thanks.

diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
index 793565c05742..8b4c3c2f2509 100644
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -33,6 +33,9 @@ struct cgroup_taskset {
 	struct list_head	src_csets;
 	struct list_head	dst_csets;
 
+	/* the number of tasks in the set */
+	int			nr_tasks;
+
 	/* the subsys currently being processed */
 	int			ssid;
 
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index dbfd7028b1c6..e3c4152741a3 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -1954,6 +1954,8 @@ static void cgroup_migrate_add_task(struct task_struct *task,
 	if (!cset->mg_src_cgrp)
 		return;
 
+	mgctx->tset.nr_tasks++;
+
 	list_move_tail(&task->cg_list, &cset->mg_tasks);
 	if (list_empty(&cset->mg_node))
 		list_add_tail(&cset->mg_node,
@@ -2047,16 +2049,18 @@ static int cgroup_migrate_execute(struct cgroup_mgctx *mgctx)
 		return 0;
 
 	/* check that we can legitimately attach to the cgroup */
-	do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
-		if (ss->can_attach) {
-			tset->ssid = ssid;
-			ret = ss->can_attach(tset);
-			if (ret) {
-				failed_ssid = ssid;
-				goto out_cancel_attach;
+	if (tset->nr_tasks) {
+		do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
+			if (ss->can_attach) {
+				tset->ssid = ssid;
+				ret = ss->can_attach(tset);
+				if (ret) {
+					failed_ssid = ssid;
+					goto out_cancel_attach;
+				}
 			}
-		}
-	} while_each_subsys_mask();
+		} while_each_subsys_mask();
+	}
 
 	/*
 	 * Now that we're guaranteed success, proceed to move all tasks to
@@ -2085,25 +2089,29 @@ static int cgroup_migrate_execute(struct cgroup_mgctx *mgctx)
 	 */
 	tset->csets = &tset->dst_csets;
 
-	do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
-		if (ss->attach) {
-			tset->ssid = ssid;
-			ss->attach(tset);
-		}
-	} while_each_subsys_mask();
+	if (tset->nr_tasks) {
+		do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
+			if (ss->attach) {
+				tset->ssid = ssid;
+				ss->attach(tset);
+			}
+		} while_each_subsys_mask();
+	}
 
 	ret = 0;
 	goto out_release_tset;
 
 out_cancel_attach:
-	do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
-		if (ssid == failed_ssid)
-			break;
-		if (ss->cancel_attach) {
-			tset->ssid = ssid;
-			ss->cancel_attach(tset);
-		}
-	} while_each_subsys_mask();
+	if (tset->nr_tasks) {
+		do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
+			if (ssid == failed_ssid)
+				break;
+			if (ss->cancel_attach) {
+				tset->ssid = ssid;
+				ss->cancel_attach(tset);
+			}
+		} while_each_subsys_mask();
+	}
 out_release_tset:
 	spin_lock_irq(&css_set_lock);
 	list_splice_init(&tset->dst_csets, &tset->src_csets);

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

#1682960

On Wed, 2017-07-05 at 11:28 -0400, Tejun Heo wrote:
> Hello, Abdul.
> 
> Thanks for the debug info.  Can you please see whether the following
> patch fixes the issue?  

It is my pleasure and yes the patch fixes the problem.

> If the problem is too difficult to reproduce

The problem was reproducible all the time. 

With the patch fix, I tried multiple times and long runs of cpu off-on
cycles but no Oops is seen.

Thank you for spending your valuable time on fixing this issue.

Reported-and-tested-by : Abdul Haleem <abdhalee@linux.vnet.ibm.com>

> to confirm the fix by seeing whether it no longer triggers, please let
> me know.  We can instead apply a patch which triggers WARN on the
> failing condition to confirm the diagnosis.
> 
> Thanks.
> 
> diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
> index 793565c05742..8b4c3c2f2509 100644
> --- a/kernel/cgroup/cgroup-internal.h
> +++ b/kernel/cgroup/cgroup-internal.h
> @@ -33,6 +33,9 @@ struct cgroup_taskset {
>  	struct list_head	src_csets;
>  	struct list_head	dst_csets;
> 
> +	/* the number of tasks in the set */
> +	int			nr_tasks;
> +
>  	/* the subsys currently being processed */
>  	int			ssid;
> 
> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
> index dbfd7028b1c6..e3c4152741a3 100644
> --- a/kernel/cgroup/cgroup.c
> +++ b/kernel/cgroup/cgroup.c
> @@ -1954,6 +1954,8 @@ static void cgroup_migrate_add_task(struct task_struct *task,
>  	if (!cset->mg_src_cgrp)
>  		return;
> 
> +	mgctx->tset.nr_tasks++;
> +
>  	list_move_tail(&task->cg_list, &cset->mg_tasks);
>  	if (list_empty(&cset->mg_node))
>  		list_add_tail(&cset->mg_node,
> @@ -2047,16 +2049,18 @@ static int cgroup_migrate_execute(struct cgroup_mgctx *mgctx)
>  		return 0;
> 
>  	/* check that we can legitimately attach to the cgroup */
> -	do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
> -		if (ss->can_attach) {
> -			tset->ssid = ssid;
> -			ret = ss->can_attach(tset);
> -			if (ret) {
> -				failed_ssid = ssid;
> -				goto out_cancel_attach;
> +	if (tset->nr_tasks) {
> +		do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
> +			if (ss->can_attach) {
> +				tset->ssid = ssid;
> +				ret = ss->can_attach(tset);
> +				if (ret) {
> +					failed_ssid = ssid;
> +					goto out_cancel_attach;
> +				}
>  			}
> -		}
> -	} while_each_subsys_mask();
> +		} while_each_subsys_mask();
> +	}
> 
>  	/*
>  	 * Now that we're guaranteed success, proceed to move all tasks to
> @@ -2085,25 +2089,29 @@ static int cgroup_migrate_execute(struct cgroup_mgctx *mgctx)
>  	 */
>  	tset->csets = &tset->dst_csets;
> 
> -	do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
> -		if (ss->attach) {
> -			tset->ssid = ssid;
> -			ss->attach(tset);
> -		}
> -	} while_each_subsys_mask();
> +	if (tset->nr_tasks) {
> +		do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
> +			if (ss->attach) {
> +				tset->ssid = ssid;
> +				ss->attach(tset);
> +			}
> +		} while_each_subsys_mask();
> +	}
> 
>  	ret = 0;
>  	goto out_release_tset;
> 
>  out_cancel_attach:
> -	do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
> -		if (ssid == failed_ssid)
> -			break;
> -		if (ss->cancel_attach) {
> -			tset->ssid = ssid;
> -			ss->cancel_attach(tset);
> -		}
> -	} while_each_subsys_mask();
> +	if (tset->nr_tasks) {
> +		do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
> +			if (ssid == failed_ssid)
> +				break;
> +			if (ss->cancel_attach) {
> +				tset->ssid = ssid;
> +				ss->cancel_attach(tset);
> +			}
> +		} while_each_subsys_mask();
> +	}
>  out_release_tset:
>  	spin_lock_irq(&css_set_lock);
>  	list_splice_init(&tset->dst_csets, &tset->src_csets);
> 


-- 
Regard's

Abdul Haleem
IBM Linux Technology Centre

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

#1683589 — [PATCH cgroup/for-4.13-fixes] cgroup: don't call migration methods if there are no tasks to migrate

From 610467270fb368584b74567edd21c8cc5104490f Mon Sep 17 00:00:00 2001
From: Tejun Heo <tj@kernel.org>
Date: Sat, 8 Jul 2017 07:17:02 -0400

Subsystem migration methods shouldn't be called for empty migrations.
cgroup_migrate_execute() implements this guarantee by bailing early if
there are no source css_sets.  This used to be correct before
a79a908fd2b0 ("cgroup: introduce cgroup namespaces"), but no longer
since the commit because css_sets can stay pinned without tasks in
them.

This caused cgroup_migrate_execute() call into cpuset migration
methods with an empty cgroup_taskset.  cpuset migration methods
correctly assume that cgroup_taskset_first() never returns NULL;
however, due to the bug, it can, leading to the following oops.

  Unable to handle kernel paging request for data at address 0x00000960
  Faulting instruction address: 0xc0000000001d6868
  Oops: Kernel access of bad area, sig: 11 [#1]
  ...
  CPU: 14 PID: 16947 Comm: kworker/14:0 Tainted: G        W
  4.12.0-rc4-next-20170609 #2
  Workqueue: events cpuset_hotplug_workfn
  task: c00000000ca60580 task.stack: c00000000c728000
  NIP: c0000000001d6868 LR: c0000000001d6858 CTR: c0000000001d6810
  REGS: c00000000c72b720 TRAP: 0300   Tainted: GW (4.12.0-rc4-next-20170609)
  MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 44722422  XER: 20000000
  CFAR: c000000000008710 DAR: 0000000000000960 DSISR: 40000000 SOFTE: 1
  GPR00: c0000000001d6858 c00000000c72b9a0 c000000001536e00 0000000000000000
  GPR04: c00000000c72b9c0 0000000000000000 c00000000c72bad0 c000000766367678
  GPR08: c000000766366d10 c00000000c72b958 c000000001736e00 0000000000000000
  GPR12: c0000000001d6810 c00000000e749300 c000000000123ef8 c000000775af4180
  GPR16: 0000000000000000 0000000000000000 c00000075480e9c0 c00000075480e9e0
  GPR20: c00000075480e8c0 0000000000000001 0000000000000000 c00000000c72ba20
  GPR24: c00000000c72baa0 c00000000c72bac0 c000000001407248 c00000000c72ba20
  GPR28: c00000000141fc80 c00000000c72bac0 c00000000c6bc790 0000000000000000
  NIP [c0000000001d6868] cpuset_can_attach+0x58/0x1b0
  LR [c0000000001d6858] cpuset_can_attach+0x48/0x1b0
  Call Trace:
  [c00000000c72b9a0] [c0000000001d6858] cpuset_can_attach+0x48/0x1b0 (unreliable)
  [c00000000c72ba00] [c0000000001cbe80] cgroup_migrate_execute+0xb0/0x450
  [c00000000c72ba80] [c0000000001d3754] cgroup_transfer_tasks+0x1c4/0x360
  [c00000000c72bba0] [c0000000001d923c] cpuset_hotplug_workfn+0x86c/0xa20
  [c00000000c72bca0] [c00000000011aa44] process_one_work+0x1e4/0x580
  [c00000000c72bd30] [c00000000011ae78] worker_thread+0x98/0x5c0
  [c00000000c72bdc0] [c000000000124058] kthread+0x168/0x1b0
  [c00000000c72be30] [c00000000000b2e8] ret_from_kernel_thread+0x5c/0x74
  Instruction dump:
  f821ffa1 7c7d1b78 60000000 60000000 38810020 7fa3eb78 3f42ffed 4bff4c25
  60000000 3b5a0448 3d420020 eb610020 <e9230960> 7f43d378 e9290000 f92af200
  ---[ end trace dcaaf98fb36d9e64 ]---

This patch fixes the bug by adding an explicit nr_tasks counter to
cgroup_taskset and skipping calling the migration methods if the
counter is zero.  While at it, remove the now spurious check on no
source css_sets.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Cc: Roman Gushchin <guro@fb.com>
Cc: stable@vger.kernel.org # v4.6+
Fixes: a79a908fd2b0 ("cgroup: introduce cgroup namespaces")
Link: http://lkml.kernel.org/r/1497266622.15415.39.camel@abdul.in.ibm.com
---
Applied to cgroup/for-4.13-fixes.  Thanks.

 kernel/cgroup/cgroup-internal.h |  3 +++
 kernel/cgroup/cgroup.c          | 58 ++++++++++++++++++++++-------------------
 2 files changed, 34 insertions(+), 27 deletions(-)

diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h
index 793565c..8b4c3c2 100644
--- a/kernel/cgroup/cgroup-internal.h
+++ b/kernel/cgroup/cgroup-internal.h
@@ -33,6 +33,9 @@ struct cgroup_taskset {
 	struct list_head	src_csets;
 	struct list_head	dst_csets;
 
+	/* the number of tasks in the set */
+	int			nr_tasks;
+
 	/* the subsys currently being processed */
 	int			ssid;
 
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 620794a..cc53111 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -2006,6 +2006,8 @@ static void cgroup_migrate_add_task(struct task_struct *task,
 	if (!cset->mg_src_cgrp)
 		return;
 
+	mgctx->tset.nr_tasks++;
+
 	list_move_tail(&task->cg_list, &cset->mg_tasks);
 	if (list_empty(&cset->mg_node))
 		list_add_tail(&cset->mg_node,
@@ -2094,21 +2096,19 @@ static int cgroup_migrate_execute(struct cgroup_mgctx *mgctx)
 	struct css_set *cset, *tmp_cset;
 	int ssid, failed_ssid, ret;
 
-	/* methods shouldn't be called if no task is actually migrating */
-	if (list_empty(&tset->src_csets))
-		return 0;
-
 	/* check that we can legitimately attach to the cgroup */
-	do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
-		if (ss->can_attach) {
-			tset->ssid = ssid;
-			ret = ss->can_attach(tset);
-			if (ret) {
-				failed_ssid = ssid;
-				goto out_cancel_attach;
+	if (tset->nr_tasks) {
+		do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
+			if (ss->can_attach) {
+				tset->ssid = ssid;
+				ret = ss->can_attach(tset);
+				if (ret) {
+					failed_ssid = ssid;
+					goto out_cancel_attach;
+				}
 			}
-		}
-	} while_each_subsys_mask();
+		} while_each_subsys_mask();
+	}
 
 	/*
 	 * Now that we're guaranteed success, proceed to move all tasks to
@@ -2137,25 +2137,29 @@ static int cgroup_migrate_execute(struct cgroup_mgctx *mgctx)
 	 */
 	tset->csets = &tset->dst_csets;
 
-	do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
-		if (ss->attach) {
-			tset->ssid = ssid;
-			ss->attach(tset);
-		}
-	} while_each_subsys_mask();
+	if (tset->nr_tasks) {
+		do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
+			if (ss->attach) {
+				tset->ssid = ssid;
+				ss->attach(tset);
+			}
+		} while_each_subsys_mask();
+	}
 
 	ret = 0;
 	goto out_release_tset;
 
 out_cancel_attach:
-	do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
-		if (ssid == failed_ssid)
-			break;
-		if (ss->cancel_attach) {
-			tset->ssid = ssid;
-			ss->cancel_attach(tset);
-		}
-	} while_each_subsys_mask();
+	if (tset->nr_tasks) {
+		do_each_subsys_mask(ss, ssid, mgctx->ss_mask) {
+			if (ssid == failed_ssid)
+				break;
+			if (ss->cancel_attach) {
+				tset->ssid = ssid;
+				ss->cancel_attach(tset);
+			}
+		} while_each_subsys_mask();
+	}
 out_release_tset:
 	spin_lock_irq(&css_set_lock);
 	list_splice_init(&tset->dst_csets, &tset->src_csets);
-- 
2.9.3

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web