The following situation leads to deadlock:
[task 1] [task 2] [task 3]
kill_fasync() mm_update_next_owner() copy_process()
spin_lock_irqsave(&fa->fa_lock) read_lock(&tasklist_lock) write_lock_irq(&tasklist_lock)
send_sigio() <IRQ> ...
read_lock(&fown->lock) kill_fasync() ...
read_lock(&tasklist_lock) spin_lock_irqsave(&fa->fa_lock) ...
Task 1 can't acquire read locked tasklist_lock, since there is
already task 3 expressed its wish to take the lock exclusive.
Task 2 holds the read locked lock, but it can't take the spin lock.
The patch makes queued_read_lock_slowpath() to give task 1 the same
priority as it was an interrupt handler, and to take the lock
dispite of task 3 is waiting it, and this prevents the deadlock.
It seems there is no better way to detect such the situations,
also in general it's not good to wait so long for readers with
interrupts disabled, since read_lock may nest with another locks
and delay the system.
Signed-off-by: Kirill Tkhai <ktkhai(a)virtuozzo.com>
---
kernel/locking/qrwlock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/locking/qrwlock.c b/kernel/locking/qrwlock.c
index c7471c3fb798..d15df85de8f5 100644
--- a/kernel/locking/qrwlock.c
+++ b/kernel/locking/qrwlock.c
@@ -32,7 +32,7 @@ void queued_read_lock_slowpath(struct qrwlock *lock)
/*
* Readers come here when they cannot get the lock without waiting
*/
- if (unlikely(in_interrupt())) {
+ if (unlikely(irqs_disabled())) {
/*
* Readers in interrupt context will get the lock immediately
* if the writer is just waiting (not holding the lock yet),
Commit e39a97353e53 modified __scsi_error_from_host_byte() such
that that function translates DID_OK into BLK_STS_OK. However,
the description of that commit is wrong: it mentions that commit
2a842acab109 introduced a bug in __scsi_error_from_host_byte()
although that commit did not change the behavior of that function.
Additionally, commit e39a97353e53 introduced a severe bug: it causes
commands that fail with hostbyte=DID_OK and driverbyte=DRIVER_SENSE
to be completed with BLK_STS_OK. Fix __scsi_error_from_host_byte()
by only translating good status values into BLK_STS_OK.
Fixes: e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()")
Reported-by: Damien Le Moal <damien.lemoal(a)wdc.com>
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Hannes Reinecke <hare(a)suse.com>
Cc: Douglas Gilbert <dgilbert(a)interlog.com>
Cc: Damien Le Moal <damien.lemoal(a)wdc.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: stable(a)vger.kernel.org
---
Changes compared to v1:
- Modified __scsi_error_from_host_byte() such that it again returns
BLK_STS_OK for CONDITION MET and other result codes that represent
success.
drivers/scsi/scsi_lib.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 74a39db57d49..1496b34af409 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -736,7 +736,13 @@ static blk_status_t __scsi_error_from_host_byte(struct scsi_cmnd *cmd,
{
switch (host_byte(result)) {
case DID_OK:
- return BLK_STS_OK;
+ /*
+ * Also check the other bytes than the status byte in result
+ * to handle the case when a SCSI LLD sets result to
+ * DRIVER_SENSE << 24 without setting SAM_STAT_CHECK_CONDITION.
+ */
+ return scsi_status_is_good(result) && (result & ~0xff) == 0 ?
+ BLK_STS_OK : BLK_STS_IOERR;
case DID_TRANSPORT_FAILFAST:
return BLK_STS_TRANSPORT;
case DID_TARGET_FAILURE:
--
2.16.2
Enabling virtual mapped kernel stacks breaks the thunderx_zip
driver. On compression or decompression the executing CPU hangs
in an endless loop. The reason for this is the usage of __pa
by the driver which does no longer work for an address that is
not part of the 1:1 mapping.
The zip driver allocates a result struct on the stack and needs
to tell the hardware the physical address within this struct
that is used to signal the completion of the request.
As the hardware gets the wrong address after the broken __pa
conversion it writes to an arbitrary address. The zip driver then
waits forever for the completion byte to contain a non-zero value.
Allocating the result struct from 1:1 mapped memory resolves this
bug.
Signed-off-by: Jan Glauber <jglauber(a)cavium.com>
Reviewed-by: Robert Richter <rrichter(a)cavium.com>
Cc: stable <stable(a)vger.kernel.org> # 4.14
---
drivers/crypto/cavium/zip/zip_crypto.c | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/cavium/zip/zip_crypto.c b/drivers/crypto/cavium/zip/zip_crypto.c
index 8df4d26..2fc9b03 100644
--- a/drivers/crypto/cavium/zip/zip_crypto.c
+++ b/drivers/crypto/cavium/zip/zip_crypto.c
@@ -124,7 +124,7 @@ int zip_compress(const u8 *src, unsigned int slen,
struct zip_kernel_ctx *zip_ctx)
{
struct zip_operation *zip_ops = NULL;
- struct zip_state zip_state;
+ struct zip_state *zip_state;
struct zip_device *zip = NULL;
int ret;
@@ -135,20 +135,23 @@ int zip_compress(const u8 *src, unsigned int slen,
if (!zip)
return -ENODEV;
- memset(&zip_state, 0, sizeof(struct zip_state));
+ zip_state = kzalloc(sizeof(*zip_state), GFP_KERNEL);
+ if (!zip_state)
+ return -ENOMEM;
+
zip_ops = &zip_ctx->zip_comp;
zip_ops->input_len = slen;
zip_ops->output_len = *dlen;
memcpy(zip_ops->input, src, slen);
- ret = zip_deflate(zip_ops, &zip_state, zip);
+ ret = zip_deflate(zip_ops, zip_state, zip);
if (!ret) {
*dlen = zip_ops->output_len;
memcpy(dst, zip_ops->output, *dlen);
}
-
+ kfree(zip_state);
return ret;
}
@@ -157,7 +160,7 @@ int zip_decompress(const u8 *src, unsigned int slen,
struct zip_kernel_ctx *zip_ctx)
{
struct zip_operation *zip_ops = NULL;
- struct zip_state zip_state;
+ struct zip_state *zip_state;
struct zip_device *zip = NULL;
int ret;
@@ -168,7 +171,10 @@ int zip_decompress(const u8 *src, unsigned int slen,
if (!zip)
return -ENODEV;
- memset(&zip_state, 0, sizeof(struct zip_state));
+ zip_state = kzalloc(sizeof(*zip_state), GFP_KERNEL);
+ if (!zip_state)
+ return -ENOMEM;
+
zip_ops = &zip_ctx->zip_decomp;
memcpy(zip_ops->input, src, slen);
@@ -179,13 +185,13 @@ int zip_decompress(const u8 *src, unsigned int slen,
zip_ops->input_len = slen;
zip_ops->output_len = *dlen;
- ret = zip_inflate(zip_ops, &zip_state, zip);
+ ret = zip_inflate(zip_ops, zip_state, zip);
if (!ret) {
*dlen = zip_ops->output_len;
memcpy(dst, zip_ops->output, *dlen);
}
-
+ kfree(zip_state);
return ret;
}
--
2.7.4
On 5 April 2018 12:32:38 PM IST, Harsh Shandilya <msfjarvis(a)gmail.com> wrote:
>
>
>On 5 April 2018 11:54:28 AM IST, Sasha Levin
><Alexander.Levin(a)microsoft.com> wrote:
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA512
>>
>>Hi Greg,
>>
>>Pleae pull commits for Linux 3.18 .
>>
>>I've sent a review request for all commits over a week ago and all
>>comments were addressed.
>>
>>
>>Thanks,
>>Sasha
>>
>>=====
>>
>>
>>The following changes since commit
>>89dad4ea47357950b8ba09886e02ff4fd0793f9e:
>>
>> Linux 3.18.99 (2018-03-11 16:12:20 +0100)
>>
>>are available in the Git repository at:
>>
>>git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git
>>tags/for-greg-3.18-04052018
>>
>>for you to fetch changes up to
>>5ea952bd1f538212d63bbd34b42e2cc769074259:
>>
>>signal/arm: Document conflicts with SI_USER and SIGFPE (2018-04-05
>>00:51:03 -0400)
>>
>>- ----------------------------------------------------------------
>>for-greg-3.18-04052018
>>
>>- ----------------------------------------------------------------
>>Jason A. Donenfeld (1):
>> skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
>>
>This patch introduces build warnings[1] with GCC 7.3.1 that were fixed
>upstream by commit 3f29770723fe498a5c5f57c3a31a996ebdde03e1 ("ipsec:
>check return value of skb_to_sgvec always").
FWIW, this was an arm64 build in the CAF msm-3.18 tree with the attached config, but the warning exists on x86_64 with a clean -stable tree as well.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi "Rodrigo R. Galvao".
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 6.9916)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Failed to apply! Possible dependencies:
d262920998c8: ("nvmet: add support for the Write Zeroes command")
78ce3daa7d70: ("nvmet: fix byte swap in nvmet_execute_write_zeroes")
d262920998c8: ("nvmet: add support for the Write Zeroes command")
v4.4.126: Failed to apply! Possible dependencies:
d262920998c8: ("nvmet: add support for the Write Zeroes command")
a07b4970f464: ("nvmet: add a generic NVMe target")
78ce3daa7d70: ("nvmet: fix byte swap in nvmet_execute_write_zeroes")
d262920998c8: ("nvmet: add support for the Write Zeroes command")
a07b4970f464: ("nvmet: add a generic NVMe target")
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
Hi Christophe JAILLET.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 7.5278)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Build OK!
v4.4.126: Failed to apply! Possible dependencies:
8d99758dee31: ("Input: synaptics-rmi4 - add SPI transport driver")
ff8f83708b3e: ("Input: synaptics-rmi4 - add support for 2D sensors and F11")
fdf51604f104: ("Input: synaptics-rmi4 - add I2C transport driver")
2b6a321da9a2: ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices")
2b6a321da9a2: ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices")
fdf51604f104: ("Input: synaptics-rmi4 - add I2C transport driver")
2b6a321da9a2: ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices")
2b6a321da9a2: ("Input: synaptics-rmi4 - add support for Synaptics RMI4 devices")
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha
Hi Alexey Kodanev.
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag.
fixing commit: 33c162a980fe ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update.
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92,
v4.15.15: Failed to apply! Possible dependencies:
22b12d2bf404: ("ipv6: allow to cache dst for a connected sk in ip6_sk_dst_lookup_flow()")
v4.14.32: Failed to apply! Possible dependencies:
22b12d2bf404: ("ipv6: allow to cache dst for a connected sk in ip6_sk_dst_lookup_flow()")
v4.9.92: Failed to apply! Possible dependencies:
22b12d2bf404: ("ipv6: allow to cache dst for a connected sk in ip6_sk_dst_lookup_flow()")
--
Thanks.
Sasha
Hi Chao Yu.
[This is an automated email]
This commit has been processed by the -stable helper bot and determined
to be a high probability candidate for -stable trees. (score: 11.4088)
The bot has tested the following trees: v4.15.15, v4.14.32, v4.9.92, v4.4.126,
v4.15.15: Build OK!
v4.14.32: Build OK!
v4.9.92: Failed to apply! Possible dependencies:
2c1d03056991: ("f2fs: support F2FS_IOC_FS{GET,SET}XATTR")
34dc77ad7436: ("f2fs: add ioctl to do gc with target block address")
e066b83c9b40: ("f2fs: add ioctl to flush data from faster device to cold area")
cac5a3d8f517: ("f2fs: fix 446 coding style warnings in f2fs.h")
7c45729a4d6d: ("f2fs: keep dirty inodes selectively for checkpoint")
15d04354555f: ("f2fs: call f2fs_balance_fs for setattr")
v4.4.126: Failed to apply! Possible dependencies:
2c1d03056991: ("f2fs: support F2FS_IOC_FS{GET,SET}XATTR")
34dc77ad7436: ("f2fs: add ioctl to do gc with target block address")
e066b83c9b40: ("f2fs: add ioctl to flush data from faster device to cold area")
4dd6f977fc77: ("f2fs: support an ioctl to move a range of data blocks")
d323d005ac4a: ("f2fs: support file defragment")
8da4b8c48e7b: ("lib/uuid.c: move generate_random_uuid() to uuid.c")
9b7365fc1c82: ("ext4: add FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface support")
Please let us know if you'd like to have this patch included in a stable tree.
--
Thanks.
Sasha