Skip to content

K
Kernel

openeuler / Kernel
接近 3 年 前同步成功

通知 11
Star 0
Fork 0
K
Kernel
You need to sign in or sign up before continuing.
切换分支/标签
  1. 12 4月, 2017 1 次提交
  3. 11 4月, 2017 5 次提交
  5. 08 4月, 2017 3 次提交
    • S
      staging: android: ashmem: lseek failed due to no FMODE_LSEEK. · 97fbfef6
      由 Shuxiao Zhang 提交于 
      vfs_llseek will check whether the file mode has
FMODE_LSEEK, no return failure. But ashmem can be
lseek, so add FMODE_LSEEK to ashmem file.

Comment From Greg Hackmann:
	ashmem_llseek() passes the llseek() call through to the backing
	shmem file.  91360b02 ("ashmem: use vfs_llseek()") changed
	this from directly calling the file's llseek() op into a VFS
	layer call.  This also adds a check for the FMODE_LSEEK bit, so
	without that bit ashmem_llseek() now always fails with -ESPIPE.

Fixes: 91360b02 ("ashmem: use vfs_llseek()")
Signed-off-by: NShuxiao Zhang <zhangshuxiao@xiaomi.com>
Tested-by: NGreg Hackmann <ghackmann@google.com>
Cc: stable <stable@vger.kernel.org> # 3.18+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97fbfef6
    • B
      dm rq: Avoid that request processing stalls sporadically · 6077c2d7
      由 Bart Van Assche 提交于 
      While running the srp-test software I noticed that request
processing stalls sporadically at the beginning of a test, namely
when mkfs is run against a dm-mpath device. Every time when that
happened the following command was sufficient to resume request
processing:

    echo run >/sys/kernel/debug/block/dm-0/state

This patch avoids that such request processing stalls occur. The
test I ran is as follows:

    while srp-test/run_tests -d -r 30 -t 02-mq; do :; done
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Cc: Mike Snitzer <snitzer@redhat.com>
Cc: dm-devel@redhat.com
Signed-off-by: NJens Axboe <axboe@fb.com>
      6077c2d7
    • B
      scsi: Avoid that SCSI queues get stuck · 36e3cf27
      由 Bart Van Assche 提交于 
      If a .queue_rq() function returns BLK_MQ_RQ_QUEUE_BUSY then the block
driver that implements that function is responsible for rerunning the
hardware queue once requests can be queued again successfully.

commit 52d7f1b5 ("blk-mq: Avoid that requeueing starts stopped
queues") removed the blk_mq_stop_hw_queue() call from scsi_queue_rq()
for the BLK_MQ_RQ_QUEUE_BUSY case. Hence change all calls to functions
that are intended to rerun a busy queue such that these examine all
hardware queues instead of only stopped queues.

Since no other functions than scsi_internal_device_block() and
scsi_internal_device_unblock() should ever stop or restart a SCSI
queue, change the blk_mq_delay_queue() call into a
blk_mq_delay_run_hw_queue() call.

Fixes: commit 52d7f1b5 ("blk-mq: Avoid that requeueing starts stopped queues")
Fixes: commit 7e79dadc ("blk-mq: stop hardware queue in blk_mq_delay_queue()")
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Sagi Grimberg <sagi@grimberg.me>
Cc: Long Li <longli@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NJens Axboe <axboe@fb.com>
      36e3cf27
  7. 07 4月, 2017 1 次提交
    • T
      pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable() · 61187142
      由 Tony Lindgren 提交于 
      Recent pinctrl changes to allow dynamic allocation of pins exposed one
more issue with the pinctrl pins claimed early by the controller itself.
This caused a regression for IMX6 pinctrl hogs.

Before enabling the pin controller driver we need to wait until it has
been properly initialized, then claim the hogs, and only then enable it.

To fix the regression, split the code into pinctrl_claim_hogs() and
pinctrl_enable(). And then let's require that pinctrl_enable() is always
called by the pin controller driver when ready after calling
pinctrl_register_and_init().

Depends-on: 950b0d91 ("pinctrl: core: Fix regression caused by delayed
work for hogs")
Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
Fixes: e566fc11 ("pinctrl: imx: use generic pinctrl helpers for
managing groups")
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Mika Penttilä <mika.penttila@nextfour.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Stefan Agner <stefan@agner.ch>
Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Tested-by: NGary Bisson <gary.bisson@boundarydevices.com>
Tested-by: NFabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      61187142
  9. 06 4月, 2017 11 次提交
  11. 05 4月, 2017 5 次提交
  13. 04 4月, 2017 11 次提交
  15. 03 4月, 2017 3 次提交
    • G
      net: ethernet: ti: cpsw: wake tx queues on ndo_tx_timeout · 75514b66
      由 Grygorii Strashko 提交于 
      In case, if TX watchdog is fired some or all netdev TX queues will be
stopped and as part of recovery it is required not only to drain and
reinitailize CPSW TX channeles, but also wake up stoppted TX queues what
doesn't happen now and netdevice will stop transmiting data until
reopenned.

Hence, add netif_tx_wake_all_queues() call in .ndo_tx_timeout() to complete
recovery and restore TX path.
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      75514b66
    • X
      tcmu: Skip Data-Out blocks before gathering Data-In buffer for BIDI case · a5d68ba8
      由 Xiubo Li 提交于 
      For the bidirectional case, the Data-Out buffer blocks will always at
the head of the tcmu_cmd's bitmap, and before gathering the Data-In
buffer, first of all it should skip the Data-Out ones, or the device
supporting BIDI commands won't work.

Fixed: 26418649 ("target/user: Introduce data_bitmap, replace
		data_length/data_head/data_tail")
Reported-by: NIlias Tsitsimpis <iliastsi@arrikto.com>
Tested-by: NIlias Tsitsimpis <iliastsi@arrikto.com>
Signed-off-by: NXiubo Li <lixiubo@cmss.chinamobile.com>
Cc: stable@vger.kernel.org # 4.6+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      a5d68ba8
    • N
      iscsi-target: Drop work-around for legacy GlobalSAN initiator · 1c99de98
      由 Nicholas Bellinger 提交于 
      Once upon a time back in 2009, a work-around was added to support
the GlobalSAN iSCSI initiator v3.3 for MacOSX, which during login
did not propose nor respond to MaxBurstLength, FirstBurstLength,
DefaultTime2Wait and DefaultTime2Retain keys.

The work-around in iscsi_check_proposer_for_optional_reply()
allowed the missing keys to be proposed, but did not require
waiting for a response before moving to full feature phase
operation.  This allowed GlobalSAN v3.3 to work out-of-the
box, and for many years we didn't run into login interopt
issues with any other initiators..

Until recently, when Martin tried a QLogic 57840S iSCSI Offload
HBA on Windows 2016 which completed login, but subsequently
failed with:

    Got unknown iSCSI OpCode: 0x43

The issue was QLogic MSFT side did not propose DefaultTime2Wait +
DefaultTime2Retain, so LIO proposes them itself, and immediately
transitions to full feature phase because of the GlobalSAN hack.
However, the QLogic MSFT side still attempts to respond to
DefaultTime2Retain + DefaultTime2Wait, even though LIO has set
ISCSI_FLAG_LOGIN_NEXT_STAGE3 + ISCSI_FLAG_LOGIN_TRANSIT
in last login response.

So while the QLogic MSFT side should have been proposing these
two keys to start, it was doing the correct thing per RFC-3720
attempting to respond to proposed keys before transitioning to
full feature phase.

All that said, recent versions of GlobalSAN iSCSI (v5.3.0.541)
does correctly propose the four keys during login, making the
original work-around moot.

So in order to allow QLogic MSFT to run unmodified as-is, go
ahead and drop this long standing work-around.
Reported-by: NMartin Svec <martin.svec@zoner.cz>
Cc: Martin Svec <martin.svec@zoner.cz>
Cc: Himanshu Madhani <Himanshu.Madhani@cavium.com>
Cc: Arun Easi <arun.easi@cavium.com>
Cc: stable@vger.kernel.org # 3.1+
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      1c99de98