<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers, branch v4.7.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>phy: rcar-gen3-usb2: fix mutex_lock calling in interrupt</title>
<updated>2016-08-20T16:11:04+00:00</updated>
<author>
<name>Yoshihiro Shimoda</name>
<email>yoshihiro.shimoda.uh@renesas.com</email>
</author>
<published>2016-06-27T06:36:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=300a15d778eb0c1793824c2f682c705fd18a158d'/>
<id>300a15d778eb0c1793824c2f682c705fd18a158d</id>
<content type='text'>
commit c14f8a4032efa73d9c4e155add47c19252b3bdf4 upstream.

This patch fixes an issue that the extcon_set_cable_state_() is possible
to cause "BUG: scheduling while atomic" because this driver calls
extcon_set_cable_state_() in the interrupt handler and mutex_lock()
is possible to be called by like the following call trace.
So, this patch adds a workqueue function to resolve this issue.

[    9.706504] BUG: scheduling while atomic: systemd-journal/25893/0x00010303
[    9.714569] Modules linked in:
[    9.717629] CPU: 0 PID: 25893 Comm: systemd-journal Not tainted 4.7.0-rc4+ #86
[    9.724844] Hardware name: Renesas Salvator-X board based on r8a7795 (DT)
[    9.731624] Call trace:
[    9.734077] [&lt;ffff0000080889f0&gt;] dump_backtrace+0x0/0x1a8
[    9.739470] [&lt;ffff000008088bac&gt;] show_stack+0x14/0x20
[    9.744520] [&lt;ffff000008348ab4&gt;] dump_stack+0x94/0xb8
[    9.749568] [&lt;ffff0000080da18c&gt;] __schedule_bug+0x44/0x58
[    9.754966] [&lt;ffff0000087c6394&gt;] __schedule+0x4e4/0x598
[    9.760185] [&lt;ffff0000087c6484&gt;] schedule+0x3c/0xa8
[    9.765057] [&lt;ffff0000087c6928&gt;] schedule_preempt_disabled+0x20/0x38
[    9.771408] [&lt;ffff0000080f20dc&gt;] mutex_optimistic_spin+0x18c/0x1d0
[    9.777583] [&lt;ffff0000087c7ef0&gt;] __mutex_lock_slowpath+0x38/0x140
[    9.783669] [&lt;ffff0000087c803c&gt;] mutex_lock+0x44/0x60
[    9.788717] [&lt;ffff00000834ca48&gt;] kobject_uevent_env+0x250/0x500
[    9.794634] [&lt;ffff0000086ae8c0&gt;] extcon_update_state+0x220/0x298
[    9.800634] [&lt;ffff0000086ae9d8&gt;] extcon_set_cable_state_+0x78/0x88
[    9.806812] [&lt;ffff000008376004&gt;] rcar_gen3_device_recognition+0x5c/0xe0
[    9.813420] [&lt;ffff0000083761bc&gt;] rcar_gen3_phy_usb2_irq+0x3c/0x48
[    9.819509] [&lt;ffff0000080fae94&gt;] handle_irq_event_percpu+0x94/0x140
[    9.825769] [&lt;ffff0000080faf88&gt;] handle_irq_event+0x48/0x78
[    9.831334] [&lt;ffff0000080fe620&gt;] handle_fasteoi_irq+0xb8/0x1b0
[    9.837162] [&lt;ffff0000080fa3c4&gt;] generic_handle_irq+0x24/0x38
[    9.842900] [&lt;ffff0000080fa6fc&gt;] __handle_domain_irq+0x5c/0xb8
[    9.848727] [&lt;ffff000008081520&gt;] gic_handle_irq+0x58/0xb0

Reported-by: Simon Horman &lt;horms@verge.net.au&gt;
Fixes: 2b38543c8db1 ("phy: rcar-gen3-usb2: add extcon support")
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c14f8a4032efa73d9c4e155add47c19252b3bdf4 upstream.

This patch fixes an issue that the extcon_set_cable_state_() is possible
to cause "BUG: scheduling while atomic" because this driver calls
extcon_set_cable_state_() in the interrupt handler and mutex_lock()
is possible to be called by like the following call trace.
So, this patch adds a workqueue function to resolve this issue.

[    9.706504] BUG: scheduling while atomic: systemd-journal/25893/0x00010303
[    9.714569] Modules linked in:
[    9.717629] CPU: 0 PID: 25893 Comm: systemd-journal Not tainted 4.7.0-rc4+ #86
[    9.724844] Hardware name: Renesas Salvator-X board based on r8a7795 (DT)
[    9.731624] Call trace:
[    9.734077] [&lt;ffff0000080889f0&gt;] dump_backtrace+0x0/0x1a8
[    9.739470] [&lt;ffff000008088bac&gt;] show_stack+0x14/0x20
[    9.744520] [&lt;ffff000008348ab4&gt;] dump_stack+0x94/0xb8
[    9.749568] [&lt;ffff0000080da18c&gt;] __schedule_bug+0x44/0x58
[    9.754966] [&lt;ffff0000087c6394&gt;] __schedule+0x4e4/0x598
[    9.760185] [&lt;ffff0000087c6484&gt;] schedule+0x3c/0xa8
[    9.765057] [&lt;ffff0000087c6928&gt;] schedule_preempt_disabled+0x20/0x38
[    9.771408] [&lt;ffff0000080f20dc&gt;] mutex_optimistic_spin+0x18c/0x1d0
[    9.777583] [&lt;ffff0000087c7ef0&gt;] __mutex_lock_slowpath+0x38/0x140
[    9.783669] [&lt;ffff0000087c803c&gt;] mutex_lock+0x44/0x60
[    9.788717] [&lt;ffff00000834ca48&gt;] kobject_uevent_env+0x250/0x500
[    9.794634] [&lt;ffff0000086ae8c0&gt;] extcon_update_state+0x220/0x298
[    9.800634] [&lt;ffff0000086ae9d8&gt;] extcon_set_cable_state_+0x78/0x88
[    9.806812] [&lt;ffff000008376004&gt;] rcar_gen3_device_recognition+0x5c/0xe0
[    9.813420] [&lt;ffff0000083761bc&gt;] rcar_gen3_phy_usb2_irq+0x3c/0x48
[    9.819509] [&lt;ffff0000080fae94&gt;] handle_irq_event_percpu+0x94/0x140
[    9.825769] [&lt;ffff0000080faf88&gt;] handle_irq_event+0x48/0x78
[    9.831334] [&lt;ffff0000080fe620&gt;] handle_fasteoi_irq+0xb8/0x1b0
[    9.837162] [&lt;ffff0000080fa3c4&gt;] generic_handle_irq+0x24/0x38
[    9.842900] [&lt;ffff0000080fa6fc&gt;] __handle_domain_irq+0x5c/0xb8
[    9.848727] [&lt;ffff000008081520&gt;] gic_handle_irq+0x58/0xb0

Reported-by: Simon Horman &lt;horms@verge.net.au&gt;
Fixes: 2b38543c8db1 ("phy: rcar-gen3-usb2: add extcon support")
Signed-off-by: Yoshihiro Shimoda &lt;yoshihiro.shimoda.uh@renesas.com&gt;
Signed-off-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>dm flakey: error READ bios during the down_interval</title>
<updated>2016-08-20T16:11:04+00:00</updated>
<author>
<name>Mike Snitzer</name>
<email>snitzer@redhat.com</email>
</author>
<published>2016-07-29T17:19:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dbf8fc37852729c8e1022548e2a98944aec4214f'/>
<id>dbf8fc37852729c8e1022548e2a98944aec4214f</id>
<content type='text'>
commit 99f3c90d0d85708e7401a81ce3314e50bf7f2819 upstream.

When the corrupt_bio_byte feature was introduced it caused READ bios to
no longer be errored with -EIO during the down_interval.  This had to do
with the complexity of needing to submit READs if the corrupt_bio_byte
feature was used.

Fix it so READ bios are properly errored with -EIO; doing so early in
flakey_map() as long as there isn't a match for the corrupt_bio_byte
feature.

Fixes: a3998799fb4df ("dm flakey: add corrupt_bio_byte feature")
Reported-by: Akira Hayakawa &lt;ruby.wktk@gmail.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 99f3c90d0d85708e7401a81ce3314e50bf7f2819 upstream.

When the corrupt_bio_byte feature was introduced it caused READ bios to
no longer be errored with -EIO during the down_interval.  This had to do
with the complexity of needing to submit READs if the corrupt_bio_byte
feature was used.

Fix it so READ bios are properly errored with -EIO; doing so early in
flakey_map() as long as there isn't a match for the corrupt_bio_byte
feature.

Fixes: a3998799fb4df ("dm flakey: add corrupt_bio_byte feature")
Reported-by: Akira Hayakawa &lt;ruby.wktk@gmail.com&gt;
Signed-off-by: Mike Snitzer &lt;snitzer@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>rtc: s3c: Add s3c_rtc_{enable/disable}_clk in s3c_rtc_setfreq()</title>
<updated>2016-08-20T16:11:04+00:00</updated>
<author>
<name>Alim Akhtar</name>
<email>alim.akhtar@samsung.com</email>
</author>
<published>2016-07-05T09:58:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5dac5e403c590fbfb6bdee297e1d57ae0d9b7054'/>
<id>5dac5e403c590fbfb6bdee297e1d57ae0d9b7054</id>
<content type='text'>
commit 70c96dfac0e231424e17743bd52f6cd2ff1f2439 upstream.

As per code flow s3c_rtc_setfreq() will get called with rtc clock disabled
and in set_freq we perform h/w registers read/write, which results in a
kernel crash on exynos7 platform while probing rtc driver.
Below is code flow:
s3c_rtc_probe()
    clk_prepare_enable(info-&gt;rtc_clk) // rtc clock enabled
    s3c_rtc_gettime() // will enable clk if not done, and disable it upon exit
    s3c_rtc_setfreq() //then this will be called with clk disabled

This patch take cares of such issue by adding s3c_rtc_{enable/disable}_clk in
s3c_rtc_setfreq().

Fixes: 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock control")
Signed-off-by: Alim Akhtar &lt;alim.akhtar@samsung.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Reviewed-by: Pankaj Dubey &lt;pankaj.dubey@samsung.com&gt;
Tested-by: Pankaj Dubey &lt;pankaj.dubey@samsung.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@free-electrons.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 70c96dfac0e231424e17743bd52f6cd2ff1f2439 upstream.

As per code flow s3c_rtc_setfreq() will get called with rtc clock disabled
and in set_freq we perform h/w registers read/write, which results in a
kernel crash on exynos7 platform while probing rtc driver.
Below is code flow:
s3c_rtc_probe()
    clk_prepare_enable(info-&gt;rtc_clk) // rtc clock enabled
    s3c_rtc_gettime() // will enable clk if not done, and disable it upon exit
    s3c_rtc_setfreq() //then this will be called with clk disabled

This patch take cares of such issue by adding s3c_rtc_{enable/disable}_clk in
s3c_rtc_setfreq().

Fixes: 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock control")
Signed-off-by: Alim Akhtar &lt;alim.akhtar@samsung.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Reviewed-by: Pankaj Dubey &lt;pankaj.dubey@samsung.com&gt;
Tested-by: Pankaj Dubey &lt;pankaj.dubey@samsung.com&gt;
Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@free-electrons.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>lpfc: fix oops in lpfc_sli4_scmd_to_wqidx_distr() from lpfc_send_taskmgmt()</title>
<updated>2016-08-20T16:11:04+00:00</updated>
<author>
<name>Mauricio Faria de Oliveira</name>
<email>mauricfo@linux.vnet.ibm.com</email>
</author>
<published>2016-06-07T23:13:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e055ad0f7b400b87e22caf4a0947179e37b74217'/>
<id>e055ad0f7b400b87e22caf4a0947179e37b74217</id>
<content type='text'>
commit 05a05872c8d4b4357c9d913e6d73ae64882bddf5 upstream.

The lpfc_sli4_scmd_to_wqidx_distr() function expects the scsi_cmnd
'lpfc_cmd-&gt;pCmd' not to be null, and point to the midlayer command.

That's not true in the .eh_(device|target|bus)_reset_handler path,
because lpfc_send_taskmgmt() sends commands not from the midlayer, so
does not set 'lpfc_cmd-&gt;pCmd'.

That is true in the .queuecommand path because lpfc_queuecommand()
stores the scsi_cmnd from midlayer in lpfc_cmd-&gt;pCmd; and lpfc_cmd is
stored by lpfc_scsi_prep_cmnd() in piocbq-&gt;context1 -- which is passed
to lpfc_sli4_scmd_to_wqidx_distr() as lpfc_cmd parameter.

This problem can be hit on SCSI EH, and immediately with sg_reset.
These 2 test-cases demonstrate the problem/fix with next-20160601.

Test-case 1) sg_reset

    # strace sg_reset --device /dev/sdm
    &lt;...&gt;
    open("/dev/sdm", O_RDWR|O_NONBLOCK)     = 3
    ioctl(3, SG_SCSI_RESET, 0x3fffde6d0994 &lt;unfinished ...&gt;
    +++ killed by SIGSEGV +++
    Segmentation fault

    # dmesg
    Unable to handle kernel paging request for data at address 0x00000000
    Faulting instruction address: 0xd00000001c88442c
    Oops: Kernel access of bad area, sig: 11 [#1]
    &lt;...&gt;
    CPU: 104 PID: 16333 Comm: sg_reset Tainted: G        W       4.7.0-rc1-next-20160601-00004-g95b89dc #6
    &lt;...&gt;
    NIP [d00000001c88442c] lpfc_sli4_scmd_to_wqidx_distr+0xc/0xd0 [lpfc]
    LR [d00000001c826fe8] lpfc_sli_calc_ring.part.27+0x98/0xd0 [lpfc]
    Call Trace:
    [c000003c9ec876f0] [c000003c9ec87770] 0xc000003c9ec87770 (unreliable)
    [c000003c9ec87720] [d00000001c82e004] lpfc_sli_issue_iocb+0xd4/0x260 [lpfc]
    [c000003c9ec87780] [d00000001c831a3c] lpfc_sli_issue_iocb_wait+0x15c/0x5b0 [lpfc]
    [c000003c9ec87880] [d00000001c87f27c] lpfc_send_taskmgmt+0x24c/0x650 [lpfc]
    [c000003c9ec87950] [d00000001c87fd7c] lpfc_device_reset_handler+0x10c/0x200 [lpfc]
    [c000003c9ec87a10] [c000000000610694] scsi_try_bus_device_reset+0x44/0xc0
    [c000003c9ec87a40] [c0000000006113e8] scsi_ioctl_reset+0x198/0x2c0
    [c000003c9ec87bf0] [c00000000060fe5c] scsi_ioctl+0x13c/0x4b0
    [c000003c9ec87c80] [c0000000006629b0] sd_ioctl+0xf0/0x120
    [c000003c9ec87cd0] [c00000000046e4f8] blkdev_ioctl+0x248/0xb70
    [c000003c9ec87d30] [c0000000002a1f60] block_ioctl+0x70/0x90
    [c000003c9ec87d50] [c00000000026d334] do_vfs_ioctl+0xc4/0x890
    [c000003c9ec87de0] [c00000000026db60] SyS_ioctl+0x60/0xc0
    [c000003c9ec87e30] [c000000000009120] system_call+0x38/0x108
    Instruction dump:
    &lt;...&gt;

    With fix:

    # strace sg_reset --device /dev/sdm
    &lt;...&gt;
    open("/dev/sdm", O_RDWR|O_NONBLOCK)     = 3
    ioctl(3, SG_SCSI_RESET, 0x3fffe103c554) = 0
    close(3)                                = 0
    exit_group(0)                           = ?
    +++ exited with 0 +++

    # dmesg
    [  424.658649] lpfc 0006:01:00.4: 4:(0):0713 SCSI layer issued Device Reset (1, 0) return x2002

Test-case 2) SCSI EH

    Using this debug patch to wire an SCSI EH trigger, for lpfc_scsi_cmd_iocb_cmpl():
    -       cmd-&gt;scsi_done(cmd);
    +       if ((phba-&gt;pport ? phba-&gt;pport-&gt;cfg_log_verbose : phba-&gt;cfg_log_verbose) == 0x32100000)
    +               printk(KERN_ALERT "lpfc: skip scsi_done()\n");
    +       else
    +               cmd-&gt;scsi_done(cmd);

    # echo 0x32100000 &gt; /sys/class/scsi_host/host11/lpfc_log_verbose

    # dd if=/dev/sdm of=/dev/null iflag=direct &amp;
    &lt;...&gt;

    After a while:

    # dmesg
    lpfc 0006:01:00.4: 4:(0):3053 lpfc_log_verbose changed from 0 (x0) to 839909376 (x32100000)
    lpfc: skip scsi_done()
    &lt;...&gt;
    Unable to handle kernel paging request for data at address 0x00000000
    Faulting instruction address: 0xd0000000199e448c
    Oops: Kernel access of bad area, sig: 11 [#1]
    &lt;...&gt;
    CPU: 96 PID: 28556 Comm: scsi_eh_11 Tainted: G        W       4.7.0-rc1-next-20160601-00004-g95b89dc #6
    &lt;...&gt;
    NIP [d0000000199e448c] lpfc_sli4_scmd_to_wqidx_distr+0xc/0xd0 [lpfc]
    LR [d000000019986fe8] lpfc_sli_calc_ring.part.27+0x98/0xd0 [lpfc]
    Call Trace:
    [c000000ff0d0b890] [c000000ff0d0b900] 0xc000000ff0d0b900 (unreliable)
    [c000000ff0d0b8c0] [d00000001998e004] lpfc_sli_issue_iocb+0xd4/0x260 [lpfc]
    [c000000ff0d0b920] [d000000019991a3c] lpfc_sli_issue_iocb_wait+0x15c/0x5b0 [lpfc]
    [c000000ff0d0ba20] [d0000000199df27c] lpfc_send_taskmgmt+0x24c/0x650 [lpfc]
    [c000000ff0d0baf0] [d0000000199dfd7c] lpfc_device_reset_handler+0x10c/0x200 [lpfc]
    [c000000ff0d0bbb0] [c000000000610694] scsi_try_bus_device_reset+0x44/0xc0
    [c000000ff0d0bbe0] [c0000000006126cc] scsi_eh_ready_devs+0x49c/0x9c0
    [c000000ff0d0bcb0] [c000000000614160] scsi_error_handler+0x580/0x680
    [c000000ff0d0bd80] [c0000000000ae848] kthread+0x108/0x130
    [c000000ff0d0be30] [c0000000000094a8] ret_from_kernel_thread+0x5c/0xb4
    Instruction dump:
    &lt;...&gt;

    With fix:

    # dmesg
    lpfc 0006:01:00.4: 4:(0):3053 lpfc_log_verbose changed from 0 (x0) to 839909376 (x32100000)
    lpfc: skip scsi_done()
    &lt;...&gt;
    lpfc 0006:01:00.4: 4:(0):0713 SCSI layer issued Device Reset (0, 0) return x2002
    &lt;...&gt;
    lpfc 0006:01:00.4: 4:(0):0723 SCSI layer issued Target Reset (1, 0) return x2002
    &lt;...&gt;
    lpfc 0006:01:00.4: 4:(0):0714 SCSI layer issued Bus Reset Data: x2002
    &lt;...&gt;
    lpfc 0006:01:00.4: 4:(0):3172 SCSI layer issued Host Reset Data:
    &lt;...&gt;

Fixes: 8b0dff14164d ("lpfc: Add support for using block multi-queue")
Signed-off-by: Mauricio Faria de Oliveira &lt;mauricfo@linux.vnet.ibm.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Acked-by: James Smart &lt;james.smart@broadcom.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 05a05872c8d4b4357c9d913e6d73ae64882bddf5 upstream.

The lpfc_sli4_scmd_to_wqidx_distr() function expects the scsi_cmnd
'lpfc_cmd-&gt;pCmd' not to be null, and point to the midlayer command.

That's not true in the .eh_(device|target|bus)_reset_handler path,
because lpfc_send_taskmgmt() sends commands not from the midlayer, so
does not set 'lpfc_cmd-&gt;pCmd'.

That is true in the .queuecommand path because lpfc_queuecommand()
stores the scsi_cmnd from midlayer in lpfc_cmd-&gt;pCmd; and lpfc_cmd is
stored by lpfc_scsi_prep_cmnd() in piocbq-&gt;context1 -- which is passed
to lpfc_sli4_scmd_to_wqidx_distr() as lpfc_cmd parameter.

This problem can be hit on SCSI EH, and immediately with sg_reset.
These 2 test-cases demonstrate the problem/fix with next-20160601.

Test-case 1) sg_reset

    # strace sg_reset --device /dev/sdm
    &lt;...&gt;
    open("/dev/sdm", O_RDWR|O_NONBLOCK)     = 3
    ioctl(3, SG_SCSI_RESET, 0x3fffde6d0994 &lt;unfinished ...&gt;
    +++ killed by SIGSEGV +++
    Segmentation fault

    # dmesg
    Unable to handle kernel paging request for data at address 0x00000000
    Faulting instruction address: 0xd00000001c88442c
    Oops: Kernel access of bad area, sig: 11 [#1]
    &lt;...&gt;
    CPU: 104 PID: 16333 Comm: sg_reset Tainted: G        W       4.7.0-rc1-next-20160601-00004-g95b89dc #6
    &lt;...&gt;
    NIP [d00000001c88442c] lpfc_sli4_scmd_to_wqidx_distr+0xc/0xd0 [lpfc]
    LR [d00000001c826fe8] lpfc_sli_calc_ring.part.27+0x98/0xd0 [lpfc]
    Call Trace:
    [c000003c9ec876f0] [c000003c9ec87770] 0xc000003c9ec87770 (unreliable)
    [c000003c9ec87720] [d00000001c82e004] lpfc_sli_issue_iocb+0xd4/0x260 [lpfc]
    [c000003c9ec87780] [d00000001c831a3c] lpfc_sli_issue_iocb_wait+0x15c/0x5b0 [lpfc]
    [c000003c9ec87880] [d00000001c87f27c] lpfc_send_taskmgmt+0x24c/0x650 [lpfc]
    [c000003c9ec87950] [d00000001c87fd7c] lpfc_device_reset_handler+0x10c/0x200 [lpfc]
    [c000003c9ec87a10] [c000000000610694] scsi_try_bus_device_reset+0x44/0xc0
    [c000003c9ec87a40] [c0000000006113e8] scsi_ioctl_reset+0x198/0x2c0
    [c000003c9ec87bf0] [c00000000060fe5c] scsi_ioctl+0x13c/0x4b0
    [c000003c9ec87c80] [c0000000006629b0] sd_ioctl+0xf0/0x120
    [c000003c9ec87cd0] [c00000000046e4f8] blkdev_ioctl+0x248/0xb70
    [c000003c9ec87d30] [c0000000002a1f60] block_ioctl+0x70/0x90
    [c000003c9ec87d50] [c00000000026d334] do_vfs_ioctl+0xc4/0x890
    [c000003c9ec87de0] [c00000000026db60] SyS_ioctl+0x60/0xc0
    [c000003c9ec87e30] [c000000000009120] system_call+0x38/0x108
    Instruction dump:
    &lt;...&gt;

    With fix:

    # strace sg_reset --device /dev/sdm
    &lt;...&gt;
    open("/dev/sdm", O_RDWR|O_NONBLOCK)     = 3
    ioctl(3, SG_SCSI_RESET, 0x3fffe103c554) = 0
    close(3)                                = 0
    exit_group(0)                           = ?
    +++ exited with 0 +++

    # dmesg
    [  424.658649] lpfc 0006:01:00.4: 4:(0):0713 SCSI layer issued Device Reset (1, 0) return x2002

Test-case 2) SCSI EH

    Using this debug patch to wire an SCSI EH trigger, for lpfc_scsi_cmd_iocb_cmpl():
    -       cmd-&gt;scsi_done(cmd);
    +       if ((phba-&gt;pport ? phba-&gt;pport-&gt;cfg_log_verbose : phba-&gt;cfg_log_verbose) == 0x32100000)
    +               printk(KERN_ALERT "lpfc: skip scsi_done()\n");
    +       else
    +               cmd-&gt;scsi_done(cmd);

    # echo 0x32100000 &gt; /sys/class/scsi_host/host11/lpfc_log_verbose

    # dd if=/dev/sdm of=/dev/null iflag=direct &amp;
    &lt;...&gt;

    After a while:

    # dmesg
    lpfc 0006:01:00.4: 4:(0):3053 lpfc_log_verbose changed from 0 (x0) to 839909376 (x32100000)
    lpfc: skip scsi_done()
    &lt;...&gt;
    Unable to handle kernel paging request for data at address 0x00000000
    Faulting instruction address: 0xd0000000199e448c
    Oops: Kernel access of bad area, sig: 11 [#1]
    &lt;...&gt;
    CPU: 96 PID: 28556 Comm: scsi_eh_11 Tainted: G        W       4.7.0-rc1-next-20160601-00004-g95b89dc #6
    &lt;...&gt;
    NIP [d0000000199e448c] lpfc_sli4_scmd_to_wqidx_distr+0xc/0xd0 [lpfc]
    LR [d000000019986fe8] lpfc_sli_calc_ring.part.27+0x98/0xd0 [lpfc]
    Call Trace:
    [c000000ff0d0b890] [c000000ff0d0b900] 0xc000000ff0d0b900 (unreliable)
    [c000000ff0d0b8c0] [d00000001998e004] lpfc_sli_issue_iocb+0xd4/0x260 [lpfc]
    [c000000ff0d0b920] [d000000019991a3c] lpfc_sli_issue_iocb_wait+0x15c/0x5b0 [lpfc]
    [c000000ff0d0ba20] [d0000000199df27c] lpfc_send_taskmgmt+0x24c/0x650 [lpfc]
    [c000000ff0d0baf0] [d0000000199dfd7c] lpfc_device_reset_handler+0x10c/0x200 [lpfc]
    [c000000ff0d0bbb0] [c000000000610694] scsi_try_bus_device_reset+0x44/0xc0
    [c000000ff0d0bbe0] [c0000000006126cc] scsi_eh_ready_devs+0x49c/0x9c0
    [c000000ff0d0bcb0] [c000000000614160] scsi_error_handler+0x580/0x680
    [c000000ff0d0bd80] [c0000000000ae848] kthread+0x108/0x130
    [c000000ff0d0be30] [c0000000000094a8] ret_from_kernel_thread+0x5c/0xb4
    Instruction dump:
    &lt;...&gt;

    With fix:

    # dmesg
    lpfc 0006:01:00.4: 4:(0):3053 lpfc_log_verbose changed from 0 (x0) to 839909376 (x32100000)
    lpfc: skip scsi_done()
    &lt;...&gt;
    lpfc 0006:01:00.4: 4:(0):0713 SCSI layer issued Device Reset (0, 0) return x2002
    &lt;...&gt;
    lpfc 0006:01:00.4: 4:(0):0723 SCSI layer issued Target Reset (1, 0) return x2002
    &lt;...&gt;
    lpfc 0006:01:00.4: 4:(0):0714 SCSI layer issued Bus Reset Data: x2002
    &lt;...&gt;
    lpfc 0006:01:00.4: 4:(0):3172 SCSI layer issued Host Reset Data:
    &lt;...&gt;

Fixes: 8b0dff14164d ("lpfc: Add support for using block multi-queue")
Signed-off-by: Mauricio Faria de Oliveira &lt;mauricfo@linux.vnet.ibm.com&gt;
Reviewed-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Acked-by: James Smart &lt;james.smart@broadcom.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / EC: Work around method reentrancy limit in ACPICA for _Qxx</title>
<updated>2016-08-20T16:11:04+00:00</updated>
<author>
<name>Lv Zheng</name>
<email>lv.zheng@intel.com</email>
</author>
<published>2016-08-03T01:00:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=eba117fe1c4fa000fdda0199b93010dc01bc294b'/>
<id>eba117fe1c4fa000fdda0199b93010dc01bc294b</id>
<content type='text'>
commit e1191bd4f62d9086a1a47adc286e7fcffc1fa55c upstream.

A regression is caused by the following commit:

  Commit: 02b771b64b73226052d6e731a0987db3b47281e9
  Subject: ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations

In this commit, using system workqueue causes that the maximum parallel
executions of _Qxx can exceed 255. This violates the method reentrancy
limit in ACPICA and generates the following error log:

  ACPI Error: Method reached maximum reentrancy limit (255) (20150818/dsmethod-341)

This patch creates a seperate workqueue and limits the number of parallel
_Qxx evaluations down to a configurable value (can be tuned against number
of online CPUs).

Since EC events are handled after driver probe, we can create the workqueue
in acpi_ec_init().

Fixes: 02b771b64b73 (ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=135691
Reported-and-tested-by: Helen Buus &lt;ubuntu@hbuus.com&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e1191bd4f62d9086a1a47adc286e7fcffc1fa55c upstream.

A regression is caused by the following commit:

  Commit: 02b771b64b73226052d6e731a0987db3b47281e9
  Subject: ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations

In this commit, using system workqueue causes that the maximum parallel
executions of _Qxx can exceed 255. This violates the method reentrancy
limit in ACPICA and generates the following error log:

  ACPI Error: Method reached maximum reentrancy limit (255) (20150818/dsmethod-341)

This patch creates a seperate workqueue and limits the number of parallel
_Qxx evaluations down to a configurable value (can be tuned against number
of online CPUs).

Since EC events are handled after driver probe, we can create the workqueue
in acpi_ec_init().

Fixes: 02b771b64b73 (ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=135691
Reported-and-tested-by: Helen Buus &lt;ubuntu@hbuus.com&gt;
Signed-off-by: Lv Zheng &lt;lv.zheng@intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Mark Atheros AR9485 and QCA9882 to avoid bus reset</title>
<updated>2016-08-20T16:11:04+00:00</updated>
<author>
<name>Chris Blake</name>
<email>chrisrblake93@gmail.com</email>
</author>
<published>2016-05-30T12:26:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=82c712260288cb3f6b9e15eab8203924f67e5c27'/>
<id>82c712260288cb3f6b9e15eab8203924f67e5c27</id>
<content type='text'>
commit 9ac0108c2bac3f1d0255f64fb89fc27e71131b24 upstream.

Similar to the AR93xx series, the AR94xx and the Qualcomm QCA988x also have
the same quirk for the Bus Reset.

Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
Signed-off-by: Chris Blake &lt;chrisrblake93@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9ac0108c2bac3f1d0255f64fb89fc27e71131b24 upstream.

Similar to the AR93xx series, the AR94xx and the Qualcomm QCA988x also have
the same quirk for the Bus Reset.

Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
Signed-off-by: Chris Blake &lt;chrisrblake93@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Input: elan_i2c - properly wake up touchpad on ASUS laptops</title>
<updated>2016-08-20T16:11:03+00:00</updated>
<author>
<name>KT Liao</name>
<email>kt.liao@emc.com.tw</email>
</author>
<published>2016-07-13T18:12:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=add87fa4f7dc5ab7c8f20b7680f2fdb8f5057330'/>
<id>add87fa4f7dc5ab7c8f20b7680f2fdb8f5057330</id>
<content type='text'>
commit 2de4fcc64685def3e586856a2dc636df44532395 upstream.

Some ASUS laptops were shipped with touchpads that require to be woken up
first, before trying to switch them into absolute reporting mode, otherwise
touchpad would fail to work while flooding the logs with:

	elan_i2c i2c-ELAN1000:00: invalid report id data (1)

Among affected devices are Asus E202SA, N552VW, X456UF, UX305CA, and
others. We detect such devices by checking the IC type and product ID
numbers and adjusting order of operations accordingly.

Signed-off-by: KT Liao &lt;kt.liao@emc.com.tw&gt;
Reported-by: Chris Chiu &lt;chiu@endlessm.com&gt;
Reported-by: Vlad Glagolev &lt;stealth@vaygr.net&gt;
Tested-by: Vlad Glagolev &lt;stealth@vaygr.net&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2de4fcc64685def3e586856a2dc636df44532395 upstream.

Some ASUS laptops were shipped with touchpads that require to be woken up
first, before trying to switch them into absolute reporting mode, otherwise
touchpad would fail to work while flooding the logs with:

	elan_i2c i2c-ELAN1000:00: invalid report id data (1)

Among affected devices are Asus E202SA, N552VW, X456UF, UX305CA, and
others. We detect such devices by checking the IC type and product ID
numbers and adjusting order of operations accordingly.

Signed-off-by: KT Liao &lt;kt.liao@emc.com.tw&gt;
Reported-by: Chris Chiu &lt;chiu@endlessm.com&gt;
Reported-by: Vlad Glagolev &lt;stealth@vaygr.net&gt;
Tested-by: Vlad Glagolev &lt;stealth@vaygr.net&gt;
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>target: Fix ordered task CHECK_CONDITION early exception handling</title>
<updated>2016-08-20T16:11:03+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2016-06-14T05:58:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4f924930c8f899ba5c1ed64b59b55ca950768688'/>
<id>4f924930c8f899ba5c1ed64b59b55ca950768688</id>
<content type='text'>
commit 410c29dfbfdf73d0d0b5d14a21868ab038eca703 upstream.

If a Simple command is sent with a failure, target_setup_cmd_from_cdb
returns with TCM_UNSUPPORTED_SCSI_OPCODE or TCM_INVALID_CDB_FIELD.

So in the cases where target_setup_cmd_from_cdb returns an error, we
never get far enough to call target_execute_cmd to increment simple_cmds.
Since simple_cmds isn't incremented, the result of the failure from
target_setup_cmd_from_cdb causes transport_generic_request_failure to
decrement simple_cmds, due to call to transport_complete_task_attr.

With this dev-&gt;simple_cmds or dev-&gt;dev_ordered_sync is now -1, not 0.
So when a subsequent command with an Ordered Task is sent, it causes
a hang, since dev-&gt;simple_cmds is at -1.

Tested-by: Bryant G. Ly &lt;bryantly@linux.vnet.ibm.com&gt;
Signed-off-by: Bryant G. Ly &lt;bryantly@linux.vnet.ibm.com&gt;
Tested-by: Michael Cyr &lt;mikecyr@linux.vnet.ibm.com&gt;
Signed-off-by: Michael Cyr &lt;mikecyr@linux.vnet.ibm.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 410c29dfbfdf73d0d0b5d14a21868ab038eca703 upstream.

If a Simple command is sent with a failure, target_setup_cmd_from_cdb
returns with TCM_UNSUPPORTED_SCSI_OPCODE or TCM_INVALID_CDB_FIELD.

So in the cases where target_setup_cmd_from_cdb returns an error, we
never get far enough to call target_execute_cmd to increment simple_cmds.
Since simple_cmds isn't incremented, the result of the failure from
target_setup_cmd_from_cdb causes transport_generic_request_failure to
decrement simple_cmds, due to call to transport_complete_task_attr.

With this dev-&gt;simple_cmds or dev-&gt;dev_ordered_sync is now -1, not 0.
So when a subsequent command with an Ordered Task is sent, it causes
a hang, since dev-&gt;simple_cmds is at -1.

Tested-by: Bryant G. Ly &lt;bryantly@linux.vnet.ibm.com&gt;
Signed-off-by: Bryant G. Ly &lt;bryantly@linux.vnet.ibm.com&gt;
Tested-by: Michael Cyr &lt;mikecyr@linux.vnet.ibm.com&gt;
Signed-off-by: Michael Cyr &lt;mikecyr@linux.vnet.ibm.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>target: Fix max_unmap_lba_count calc overflow</title>
<updated>2016-08-20T16:11:03+00:00</updated>
<author>
<name>Mike Christie</name>
<email>mchristi@redhat.com</email>
</author>
<published>2016-06-03T01:12:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6bcdc94d697ea1ffe7497bd042feec29d3199c47'/>
<id>6bcdc94d697ea1ffe7497bd042feec29d3199c47</id>
<content type='text'>
commit ea263c7fada4af8ec7fe5fcfd6e7d7705a89351b upstream.

max_discard_sectors only 32bits, and some non scsi backend
devices will set this to the max 0xffffffff, so we can end up
overflowing during the max_unmap_lba_count calculation.

This fixes a regression caused by my patch:

commit 8a9ebe717a133ba7bc90b06047f43cc6b8bcb8b3
Author: Mike Christie &lt;mchristi@redhat.com&gt;
Date:   Mon Jan 18 14:09:27 2016 -0600

    target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectors

which can result in extra discards being sent to due the overflow
causing max_unmap_lba_count to be smaller than what the backing
device can actually support.

Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Reviewed-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ea263c7fada4af8ec7fe5fcfd6e7d7705a89351b upstream.

max_discard_sectors only 32bits, and some non scsi backend
devices will set this to the max 0xffffffff, so we can end up
overflowing during the max_unmap_lba_count calculation.

This fixes a regression caused by my patch:

commit 8a9ebe717a133ba7bc90b06047f43cc6b8bcb8b3
Author: Mike Christie &lt;mchristi@redhat.com&gt;
Date:   Mon Jan 18 14:09:27 2016 -0600

    target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectors

which can result in extra discards being sent to due the overflow
causing max_unmap_lba_count to be smaller than what the backing
device can actually support.

Signed-off-by: Mike Christie &lt;mchristi@redhat.com&gt;
Reviewed-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>target: Fix race between iscsi-target connection shutdown + ABORT_TASK</title>
<updated>2016-08-20T16:11:03+00:00</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2016-06-02T21:56:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6816be83ff4637a6c6912fb720b578e0c9a10f10'/>
<id>6816be83ff4637a6c6912fb720b578e0c9a10f10</id>
<content type='text'>
commit 064cdd2d91c2805d788876082f31cc63506f22c3 upstream.

This patch fixes a race in iscsit_release_commands_from_conn() -&gt;
iscsit_free_cmd() -&gt; transport_generic_free_cmd() + wait_for_tasks=1,
where CMD_T_FABRIC_STOP could end up being set after the final
kref_put() is called from core_tmr_abort_task() context.

This results in transport_generic_free_cmd() blocking indefinately
on se_cmd-&gt;cmd_wait_comp, because the target_release_cmd_kref()
check for CMD_T_FABRIC_STOP returns false.

To address this bug, make iscsit_release_commands_from_conn()
do list_splice and set CMD_T_FABRIC_STOP early while holding
iscsi_conn-&gt;cmd_lock.  Also make iscsit_aborted_task() only
remove iscsi_cmd_t if CMD_T_FABRIC_STOP has not already been
set.

Finally in target_release_cmd_kref(), only honor fabric_stop
if CMD_T_ABORTED has been set.

Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Quinn Tran &lt;quinn.tran@qlogic.com&gt;
Cc: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Tested-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 064cdd2d91c2805d788876082f31cc63506f22c3 upstream.

This patch fixes a race in iscsit_release_commands_from_conn() -&gt;
iscsit_free_cmd() -&gt; transport_generic_free_cmd() + wait_for_tasks=1,
where CMD_T_FABRIC_STOP could end up being set after the final
kref_put() is called from core_tmr_abort_task() context.

This results in transport_generic_free_cmd() blocking indefinately
on se_cmd-&gt;cmd_wait_comp, because the target_release_cmd_kref()
check for CMD_T_FABRIC_STOP returns false.

To address this bug, make iscsit_release_commands_from_conn()
do list_splice and set CMD_T_FABRIC_STOP early while holding
iscsi_conn-&gt;cmd_lock.  Also make iscsit_aborted_task() only
remove iscsi_cmd_t if CMD_T_FABRIC_STOP has not already been
set.

Finally in target_release_cmd_kref(), only honor fabric_stop
if CMD_T_ABORTED has been set.

Cc: Mike Christie &lt;mchristi@redhat.com&gt;
Cc: Quinn Tran &lt;quinn.tran@qlogic.com&gt;
Cc: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Hannes Reinecke &lt;hare@suse.de&gt;
Tested-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
