Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Merge pull request #1 from mitwo-dev/android-5.1.1 #2

Closed
wants to merge 1 commit into from
Closed

Merge pull request #1 from mitwo-dev/android-5.1.1 #2

wants to merge 1 commit into from

Conversation

3EleVen
Copy link

@3EleVen 3EleVen commented May 31, 2015

update

@3EleVen
Copy link
Author

3EleVen commented May 31, 2015

update

@M1cha
Copy link
Member

M1cha commented May 31, 2015

you didn't change anything

@M1cha M1cha closed this May 31, 2015
M1cha pushed a commit that referenced this pull request Jul 27, 2015
@lizf-os
iscsi-target: Drop problematic active_ts_list usage
0484ec0 
commit 3fd7b60f2c7418239d586e359e0c6d8503e10646 upstream.

This patch drops legacy active_ts_list usage within iscsi_target_tq.c
code.  It was originally used to track the active thread sets during
iscsi-target shutdown, and is no longer used by modern upstream code.

Two people have reported list corruption using traditional iscsi-target
and iser-target with the following backtrace, that appears to be related
to iscsi_thread_set->ts_list being used across both active_ts_list and
inactive_ts_list.

[   60.782534] ------------[ cut here ]------------
[   60.782543] WARNING: CPU: 0 PID: 9430 at lib/list_debug.c:53 __list_del_entry+0x63/0xd0()
[   60.782545] list_del corruption, ffff88045b00d180->next is LIST_POISON1 (dead000000100100)
[   60.782546] Modules linked in: ib_srpt tcm_qla2xxx qla2xxx tcm_loop tcm_fc libfc scsi_transport_fc scsi_tgt ib_isert rdma_cm iw_cm ib_addr iscsi_target_mod target_core_pscsi target_core_file target_core_iblock target_core_mod configfs ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc autofs4 sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ib_ipoib ib_cm ib_uverbs ib_umad mlx4_en mlx4_ib ib_sa ib_mad ib_core mlx4_core dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support microcode serio_raw pcspkr sb_edac edac_core sg i2c_i801 lpc_ich mfd_core mtip32xx igb i2c_algo_bit i2c_core ptp pps_core ioatdma dca wmi ext3(F) jbd(F) mbcache(F) sd_mod(F) crc_t10dif(F) crct10dif_common(F) ahci(F) libahci(F) isci(F) libsas(F) scsi_transport_sas(F) [last unloaded: speedstep_lib]
[   60.782597] CPU: 0 PID: 9430 Comm: iscsi_ttx Tainted: GF 3.12.19+ #2
[   60.782598] Hardware name: Supermicro X9DRX+-F/X9DRX+-F, BIOS 3.00 07/09/2013
[   60.782599]  0000000000000035 ffff88044de31d08 ffffffff81553ae7 0000000000000035
[   60.782602]  ffff88044de31d58 ffff88044de31d48 ffffffff8104d1cc 0000000000000002
[   60.782605]  ffff88045b00d180 ffff88045b00d0c0 ffff88045b00d0c0 ffff88044de31e58
[   60.782607] Call Trace:
[   60.782611]  [<ffffffff81553ae7>] dump_stack+0x49/0x62
[   60.782615]  [<ffffffff8104d1cc>] warn_slowpath_common+0x8c/0xc0
[   60.782618]  [<ffffffff8104d2b6>] warn_slowpath_fmt+0x46/0x50
[   60.782620]  [<ffffffff81280933>] __list_del_entry+0x63/0xd0
[   60.782622]  [<ffffffff812809b1>] list_del+0x11/0x40
[   60.782630]  [<ffffffffa06e7cf9>] iscsi_del_ts_from_active_list+0x29/0x50 [iscsi_target_mod]
[   60.782635]  [<ffffffffa06e87b1>] iscsi_tx_thread_pre_handler+0xa1/0x180 [iscsi_target_mod]
[   60.782642]  [<ffffffffa06fb9ae>] iscsi_target_tx_thread+0x4e/0x220 [iscsi_target_mod]
[   60.782647]  [<ffffffffa06fb960>] ? iscsit_handle_snack+0x190/0x190 [iscsi_target_mod]
[   60.782652]  [<ffffffffa06fb960>] ? iscsit_handle_snack+0x190/0x190 [iscsi_target_mod]
[   60.782655]  [<ffffffff8106f99e>] kthread+0xce/0xe0
[   60.782657]  [<ffffffff8106f8d0>] ? kthread_freezable_should_stop+0x70/0x70
[   60.782660]  [<ffffffff8156026c>] ret_from_fork+0x7c/0xb0
[   60.782662]  [<ffffffff8106f8d0>] ? kthread_freezable_should_stop+0x70/0x70
[   60.782663] ---[ end trace 9662f4a661d33965 ]---

Since this code is no longer used, go ahead and drop the problematic usage
all-together.

Reported-by: Gavin Guo <gavin.guo@canonical.com>
Reported-by: Moussa Ba <moussaba@micron.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
ivan19871002 pushed a commit that referenced this pull request Nov 26, 2015
@lizf-os
libata: prevent HSM state change race between ISR and PIO
dc3aaee 
commit ce7514526742c0898b837d4395f515b79dfb5a12 upstream.

It is possible for ata_sff_flush_pio_task() to set ap->hsm_task_state to
HSM_ST_IDLE in between the time __ata_sff_port_intr() checks for HSM_ST_IDLE
and before it calls ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG().

This problem is hard to reproduce making this patch hard to verify, but this
fix will prevent the race.

I have not been able to reproduce the problem, but here is a crash dump from
a 2.6.32 kernel.

On examining the ata port's state, its hsm_task_state field has a value of HSM_ST_IDLE:

crash> struct ata_port.hsm_task_state ffff881c1121c000
  hsm_task_state = 0

Normally, this should not be possible as ata_sff_hsm_move() was called from ata_sff_host_intr(),
which checks hsm_task_state and won't call ata_sff_hsm_move() if it has a HSM_ST_IDLE value.

PID: 11053  TASK: ffff8816e846cae0  CPU: 0   COMMAND: "sshd"
 #0 [ffff88008ba03960] machine_kexec at ffffffff81038f3b
 #1 [ffff88008ba039c0] crash_kexec at ffffffff810c5d92
 #2 [ffff88008ba03a90] oops_end at ffffffff8152b510
 MiCode#3 [ffff88008ba03ac0] die at ffffffff81010e0b
 MiCode#4 [ffff88008ba03af0] do_trap at ffffffff8152ad74
 MiCode#5 [ffff88008ba03b50] do_invalid_op at ffffffff8100cf95
 MiCode#6 [ffff88008ba03bf0] invalid_op at ffffffff8100bf9b
    [exception RIP: ata_sff_hsm_move+317]
    RIP: ffffffff813a77ad  RSP: ffff88008ba03ca0  RFLAGS: 00010097
    RAX: 0000000000000000  RBX: ffff881c1121dc60  RCX: 0000000000000000
    RDX: ffff881c1121dd10  RSI: ffff881c1121dc60  RDI: ffff881c1121c000
    RBP: ffff88008ba03d00   R8: 0000000000000000   R9: 000000000000002e
    R10: 000000000001003f  R11: 000000000000009b  R12: ffff881c1121c000
    R13: 0000000000000000  R14: 0000000000000050  R15: ffff881c1121dd78
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
 MiCode#7 [ffff88008ba03d08] ata_sff_host_intr at ffffffff813a7fbd
 MiCode#8 [ffff88008ba03d38] ata_sff_interrupt at ffffffff813a821e
 MiCode#9 [ffff88008ba03d78] handle_IRQ_event at ffffffff810e6ec0
ivan19871002 pushed a commit that referenced this pull request Nov 26, 2015
timer: Don't reinitialize the cpu base lock during CPU_UP_PREPARE
ca8077e 
An inactive timer's base can refer to a offline cpu's base.

In the current code, cpu_base's lock is blindly reinitialized
each time a CPU is brought up. If a CPU is brought online
during the period that another thread is trying to modify an
inactive timer on that CPU with holding its timer base lock,
then the lock will be reinitialized under its feet. This leads
to following SPIN_BUG().

<0> BUG: spinlock already unlocked on CPU#3, kworker/u:3/1466
<0> lock: 0xe3ebe000, .magic: dead4ead, .owner: kworker/u:3/1466,
 .owner_cpu: 1
<4> [<c0013dc4>] (unwind_backtrace+0x0/0x11c) from [<c026e794>]
(do_raw_spin_unlock+0x40/0xcc)
<4> [<c026e794>] (do_raw_spin_unlock+0x40/0xcc) from [<c076c160>]
(_raw_spin_unlock+0x8/0x30)
<4> [<c076c160>] (_raw_spin_unlock+0x8/0x30) from [<c009b858>]
(mod_timer+0x294/0x310)
<4> [<c009b858>] (mod_timer+0x294/0x310) from [<c00a5e04>]
(queue_delayed_work_on+0x104/0x120)
<4> [<c00a5e04>] (queue_delayed_work_on+0x104/0x120) from [<c04eae00>]
(sdhci_msm_bus_voting+0x88/0x9c)
<4> [<c04eae00>] (sdhci_msm_bus_voting+0x88/0x9c) from [<c04d8780>]
(sdhci_disable+0x40/0x48)
<4> [<c04d8780>] (sdhci_disable+0x40/0x48) from [<c04bf300>]
(mmc_release_host+0x4c/0xb0)
<4> [<c04bf300>] (mmc_release_host+0x4c/0xb0) from [<c04c7aac>]
(mmc_sd_detect+0x90/0xfc)
<4> [<c04c7aac>] (mmc_sd_detect+0x90/0xfc) from [<c04c2504>]
(mmc_rescan+0x7c/0x2c4)
<4> [<c04c2504>] (mmc_rescan+0x7c/0x2c4) from [<c00a6a7c>]
(process_one_work+0x27c/0x484)
<4> [<c00a6a7c>] (process_one_work+0x27c/0x484) from [<c00a6e94>]
(worker_thread+0x210/0x3b0)
<4> [<c00a6e94>] (worker_thread+0x210/0x3b0) from [<c00aad9c>]
(kthread+0x80/0x8c)
<4> [<c00aad9c>] (kthread+0x80/0x8c) from [<c000ea80>]
(kernel_thread_exit+0x0/0x8)

As an example, this particular crash occurred when CPU MiCode#3 is executing
mod_timer() on an inactive timer whose base is refered to offlined CPU #2.
The code locked the timer_base corresponding to CPU #2. Before it could
proceed, CPU #2 came online and reinitialized the spinlock corresponding
to its base. Thus now CPU MiCode#3 held a lock which was reinitialized. When
CPU MiCode#3 finally ended up unlocking the old cpu_base corresponding to CPU #2,
we hit the above SPIN_BUG().

CPU #0			CPU MiCode#3				       CPU #2
------			-------				       -------
.....			 ......				      <Offline>
			mod_timer()
			 lock_timer_base
			  spin_lock_irqsave(&base->lock)

cpu_up(2)		 .....				        ......
							 init_timers_cpu()
.....		 	 spin_unlock_irqrestore(&base->lock)     ......
			   <spin_bug>

Allocation of per_cpu timer vector bases is done only once under
"tvec_base_done[]" check. In the current code, spinlock_initialization
of base->lock isn't under this check. When a CPU is up each time the base
lock is reinitialized. Move base spinlock initialization under the check.

CRs-Fixed: 471127
Change-Id: I73b48440fffb227a60af9180e318c851048530dd
Signed-off-by: Tirupathi Reddy <tirupath@codeaurora.org>
Signed-off-by: Ed Tam <etam@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@3EleVen @M1cha @ghbhaha