This is a note to let you know that I've just added the patch titled
scsi: scsi_debug: write_same: fix error report
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-scsi_debug-write_same-fix-error-report.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Douglas Gilbert <dgilbert(a)interlog.com>
Date: Sun, 29 Oct 2017 10:47:19 -0400
Subject: scsi: scsi_debug: write_same: fix error report
From: Douglas Gilbert <dgilbert(a)interlog.com>
[ Upstream commit e33d7c56450b0a5c7290cbf9e1581fab5174f552 ]
The scsi_debug driver incorrectly suggests there is an error with the
SCSI WRITE SAME command when the number_of_logical_blocks is greater
than 1. It will also suggest there is an error when NDOB
(no data-out buffer) is set and the number_of_logical_blocks is
greater than 0. Both are valid, fix.
Signed-off-by: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/scsi_debug.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -3001,11 +3001,11 @@ static int resp_write_same(struct scsi_c
if (-1 == ret) {
write_unlock_irqrestore(&atomic_rw, iflags);
return DID_ERROR << 16;
- } else if (sdebug_verbose && (ret < (num * sdebug_sector_size)))
+ } else if (sdebug_verbose && !ndob && (ret < sdebug_sector_size))
sdev_printk(KERN_INFO, scp->device,
- "%s: %s: cdb indicated=%u, IO sent=%d bytes\n",
+ "%s: %s: lb size=%u, IO sent=%d bytes\n",
my_name, "write same",
- num * sdebug_sector_size, ret);
+ sdebug_sector_size, ret);
/* Copy first sector to remaining blocks */
for (i = 1 ; i < num ; i++)
Patches currently in stable-queue which might be from dgilbert(a)interlog.com are
queue-4.14/scsi-scsi_debug-write_same-fix-error-report.patch
This is a note to let you know that I've just added the patch titled
scsi: hpsa: destroy sas transport properties before scsi_host
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-hpsa-destroy-sas-transport-properties-before-scsi_host.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Martin Wilck <mwilck(a)suse.de>
Date: Fri, 20 Oct 2017 16:51:08 -0500
Subject: scsi: hpsa: destroy sas transport properties before scsi_host
From: Martin Wilck <mwilck(a)suse.de>
[ Upstream commit dfb2e6f46b3074eb85203d8f0888b71ec1c2e37a ]
This patch cleans up a lot of warnings when unloading the driver.
A current example of the stack trace starts with:
[ 142.570715] sysfs group 'power' not found for kobject 'port-5:0'
There can be hundreds of these messages during a driver unload.
I am resubmitting this patch on behalf of Martin Wilck with his
permission.
His original patch can be found here:
https://www.spinics.net/lists/linux-scsi/msg102085.html
This patch did not help until Hannes's
commit 9441284fbc39 ("scsi-fixup-kernel-warning-during-rmmod")
was applied to the kernel.
---------------------------
Original patch description:
---------------------------
Unloading the hpsa driver causes warnings
[ 1063.793652] WARNING: CPU: 1 PID: 4850 at ../fs/sysfs/group.c:237 device_del+0x54/0x240()
[ 1063.793659] sysfs group ffffffff81cf21a0 not found for kobject 'port-2:0'
with two different stacks:
1)
[ 1063.793774] [<ffffffff81448af4>] device_del+0x54/0x240
[ 1063.793780] [<ffffffff8145178a>] transport_remove_classdev+0x4a/0x60
[ 1063.793784] [<ffffffff81451216>] attribute_container_device_trigger+0xa6/0xb0
[ 1063.793802] [<ffffffffa0105d46>] sas_port_delete+0x126/0x160 [scsi_transport_sas]
[ 1063.793819] [<ffffffffa036ebcc>] hpsa_free_sas_port+0x3c/0x70 [hpsa]
2)
[ 1063.797103] [<ffffffff81448af4>] device_del+0x54/0x240
[ 1063.797118] [<ffffffffa0105d4e>] sas_port_delete+0x12e/0x160 [scsi_transport_sas]
[ 1063.797134] [<ffffffffa036ebcc>] hpsa_free_sas_port+0x3c/0x70 [hpsa]
This is caused by the fact that host device hostX is deleted before the
SAS transport devices hostX/port-a:b.
This patch fixes this by reverting the order of device deletions.
Tested-by: Don Brace <don.brace(a)microsemi.com>
Reviewed-by: Don Brace <don.brace(a)microsemi.com>
Signed-off-by: Martin Wilck <mwilck(a)suse.de>
Signed-off-by: Don Brace <don.brace(a)microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/hpsa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -8684,6 +8684,8 @@ static void hpsa_remove_one(struct pci_d
destroy_workqueue(h->rescan_ctlr_wq);
destroy_workqueue(h->resubmit_wq);
+ hpsa_delete_sas_host(h);
+
/*
* Call before disabling interrupts.
* scsi_remove_host can trigger I/O operations especially
@@ -8718,8 +8720,6 @@ static void hpsa_remove_one(struct pci_d
h->lockup_detected = NULL; /* init_one 2 */
/* (void) pci_disable_pcie_error_reporting(pdev); */ /* init_one 1 */
- hpsa_delete_sas_host(h);
-
kfree(h); /* init_one 1 */
}
Patches currently in stable-queue which might be from mwilck(a)suse.de are
queue-4.14/scsi-hpsa-cleanup-sas_phy-structures-in-sysfs-when-unloading.patch
queue-4.14/scsi-hpsa-destroy-sas-transport-properties-before-scsi_host.patch
This is a note to let you know that I've just added the patch titled
scsi: hpsa: cleanup sas_phy structures in sysfs when unloading
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-hpsa-cleanup-sas_phy-structures-in-sysfs-when-unloading.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Martin Wilck <mwilck(a)suse.de>
Date: Fri, 20 Oct 2017 16:51:14 -0500
Subject: scsi: hpsa: cleanup sas_phy structures in sysfs when unloading
From: Martin Wilck <mwilck(a)suse.de>
[ Upstream commit 55ca38b4255bb336c2d35990bdb2b368e19b435a ]
I am resubmitting this patch on behalf of Martin Wilck with his
permission.
The original patch can be found here:
https://www.spinics.net/lists/linux-scsi/msg102083.html
This patch did not help until Hannes's
commit 9441284fbc39 ("scsi-fixup-kernel-warning-during-rmmod")
was applied to the kernel.
--------------------------------------
Original patch description from Martin:
--------------------------------------
When the hpsa module is unloaded using rmmod, dangling
symlinks remain under /sys/class/sas_phy. Fix this by
calling sas_phy_delete() rather than sas_phy_free (which,
according to comments, should not be called for PHYs that
have been set up successfully, anyway).
Tested-by: Don Brace <don.brace(a)microsemi.com>
Reviewed-by: Don Brace <don.brace(a)microsemi.com>
Signed-off-by: Martin Wilck <mwilck(a)suse.de>
Signed-off-by: Don Brace <don.brace(a)microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/hpsa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -9207,9 +9207,9 @@ static void hpsa_free_sas_phy(struct hps
struct sas_phy *phy = hpsa_sas_phy->phy;
sas_port_delete_phy(hpsa_sas_phy->parent_port->port, phy);
- sas_phy_free(phy);
if (hpsa_sas_phy->added_to_port)
list_del(&hpsa_sas_phy->phy_list_entry);
+ sas_phy_delete(phy);
kfree(hpsa_sas_phy);
}
Patches currently in stable-queue which might be from mwilck(a)suse.de are
queue-4.14/scsi-hpsa-cleanup-sas_phy-structures-in-sysfs-when-unloading.patch
queue-4.14/scsi-hpsa-destroy-sas-transport-properties-before-scsi_host.patch
This is a note to let you know that I've just added the patch titled
scsi: hisi_sas: fix the risk of freeing slot twice
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-hisi_sas-fix-the-risk-of-freeing-slot-twice.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Xiaofei Tan <tanxiaofei(a)huawei.com>
Date: Tue, 24 Oct 2017 23:51:38 +0800
Subject: scsi: hisi_sas: fix the risk of freeing slot twice
From: Xiaofei Tan <tanxiaofei(a)huawei.com>
[ Upstream commit 6ba0fbc35aa9f3bc8c12be3b4047055c9ce2ac92 ]
The function hisi_sas_slot_task_free() is used to free the slot and do
tidy-up of LLDD resources. The LLDD generally should know the state of
a slot and decide when to free it, and it should only be done once.
For some scenarios, we really don't know the state, like when TMF
timeout. In this case, we check task->lldd_task before calling
hisi_sas_slot_task_free().
However, we may miss some scenarios when we should also check
task->lldd_task, and it is not SMP safe to check task->lldd_task as we
don't protect it within spin lock.
This patch is to fix this risk of freeing slot twice, as follows:
1. Check task->lldd_task in the hisi_sas_slot_task_free(), and give
up freeing of this time if task->lldd_task is NULL.
2. Set slot->buf to NULL after it is freed.
Signed-off-by: Xiaofei Tan <tanxiaofei(a)huawei.com>
Signed-off-by: John Garry <john.garry(a)huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/hisi_sas/hisi_sas_main.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -185,13 +185,16 @@ void hisi_sas_slot_task_free(struct hisi
struct domain_device *device = task->dev;
struct hisi_sas_device *sas_dev = device->lldd_dev;
+ if (!task->lldd_task)
+ return;
+
+ task->lldd_task = NULL;
+
if (!sas_protocol_ata(task->task_proto))
if (slot->n_elem)
dma_unmap_sg(dev, task->scatter, slot->n_elem,
task->data_dir);
- task->lldd_task = NULL;
-
if (sas_dev)
atomic64_dec(&sas_dev->running_req);
}
@@ -199,8 +202,8 @@ void hisi_sas_slot_task_free(struct hisi
if (slot->buf)
dma_pool_free(hisi_hba->buffer_pool, slot->buf, slot->buf_dma);
-
list_del_init(&slot->entry);
+ slot->buf = NULL;
slot->task = NULL;
slot->port = NULL;
hisi_sas_slot_index_free(hisi_hba, slot->idx);
Patches currently in stable-queue which might be from tanxiaofei(a)huawei.com are
queue-4.14/scsi-hisi_sas-fix-the-risk-of-freeing-slot-twice.patch
This is a note to let you know that I've just added the patch titled
scsi: bfa: integer overflow in debugfs
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-bfa-integer-overflow-in-debugfs.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:29:00 CET 2017
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Wed, 4 Oct 2017 10:50:37 +0300
Subject: scsi: bfa: integer overflow in debugfs
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 3e351275655d3c84dc28abf170def9786db5176d ]
We could allocate less memory than intended because we do:
bfad->regdata = kzalloc(len << 2, GFP_KERNEL);
The shift can overflow leading to a crash. This is debugfs code so the
impact is very small. I fixed the network version of this in March with
commit 13e2d5187f6b ("bna: integer overflow bug in debugfs").
Fixes: ab2a9ba189e8 ("[SCSI] bfa: add debugfs support")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/bfa/bfad_debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/scsi/bfa/bfad_debugfs.c
+++ b/drivers/scsi/bfa/bfad_debugfs.c
@@ -255,7 +255,8 @@ bfad_debugfs_write_regrd(struct file *fi
struct bfad_s *bfad = port->bfad;
struct bfa_s *bfa = &bfad->bfa;
struct bfa_ioc_s *ioc = &bfa->ioc;
- int addr, len, rc, i;
+ int addr, rc, i;
+ u32 len;
u32 *regbuf;
void __iomem *rb, *reg_addr;
unsigned long flags;
@@ -266,7 +267,7 @@ bfad_debugfs_write_regrd(struct file *fi
return PTR_ERR(kern_buf);
rc = sscanf(kern_buf, "%x:%x", &addr, &len);
- if (rc < 2) {
+ if (rc < 2 || len > (UINT_MAX >> 2)) {
printk(KERN_INFO
"bfad[%d]: %s failed to read user buf\n",
bfad->inst_no, __func__);
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.14/scsi-bfa-integer-overflow-in-debugfs.patch
queue-4.14/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch
queue-4.14/misc-pci_endpoint_test-avoid-triggering-a-bug.patch
This is a note to let you know that I've just added the patch titled
scsi: aacraid: use timespec64 instead of timeval
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-aacraid-use-timespec64-instead-of-timeval.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Arnd Bergmann <arnd(a)arndb.de>
Date: Tue, 7 Nov 2017 11:46:05 +0100
Subject: scsi: aacraid: use timespec64 instead of timeval
From: Arnd Bergmann <arnd(a)arndb.de>
[ Upstream commit 820f188659122602ab217dd80cfa32b3ac0c55c0 ]
aacraid passes the current time to the firmware in one of two ways,
either as year/month/day/... or as 32-bit unsigned seconds.
The first one is broken on 32-bit architectures as it cannot go past
year 2038. Using timespec64 here makes it behave properly on both 32-bit
and 64-bit architectures, and avoids relying on signed integer overflow
to pass times into the second interface.
The interface used in aac_send_hosttime() however is still problematic
in year 2106 when 32-bit seconds overflow. Hopefully we don't have to
worry about aacraid by that time.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Reviewed-by: Dave Carroll <david.carroll(a)microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/aacraid/commsup.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
--- a/drivers/scsi/aacraid/commsup.c
+++ b/drivers/scsi/aacraid/commsup.c
@@ -2383,19 +2383,19 @@ fib_free_out:
goto out;
}
-int aac_send_safw_hostttime(struct aac_dev *dev, struct timeval *now)
+int aac_send_safw_hostttime(struct aac_dev *dev, struct timespec64 *now)
{
struct tm cur_tm;
char wellness_str[] = "<HW>TD\010\0\0\0\0\0\0\0\0\0DW\0\0ZZ";
u32 datasize = sizeof(wellness_str);
- unsigned long local_time;
+ time64_t local_time;
int ret = -ENODEV;
if (!dev->sa_firmware)
goto out;
- local_time = (u32)(now->tv_sec - (sys_tz.tz_minuteswest * 60));
- time_to_tm(local_time, 0, &cur_tm);
+ local_time = (now->tv_sec - (sys_tz.tz_minuteswest * 60));
+ time64_to_tm(local_time, 0, &cur_tm);
cur_tm.tm_mon += 1;
cur_tm.tm_year += 1900;
wellness_str[8] = bin2bcd(cur_tm.tm_hour);
@@ -2412,7 +2412,7 @@ out:
return ret;
}
-int aac_send_hosttime(struct aac_dev *dev, struct timeval *now)
+int aac_send_hosttime(struct aac_dev *dev, struct timespec64 *now)
{
int ret = -ENOMEM;
struct fib *fibptr;
@@ -2424,7 +2424,7 @@ int aac_send_hosttime(struct aac_dev *de
aac_fib_init(fibptr);
info = (__le32 *)fib_data(fibptr);
- *info = cpu_to_le32(now->tv_sec);
+ *info = cpu_to_le32(now->tv_sec); /* overflow in y2106 */
ret = aac_fib_send(SendHostTime, fibptr, sizeof(*info), FsaNormal,
1, 1, NULL, NULL);
@@ -2496,7 +2496,7 @@ int aac_command_thread(void *data)
}
if (!time_before(next_check_jiffies,next_jiffies)
&& ((difference = next_jiffies - jiffies) <= 0)) {
- struct timeval now;
+ struct timespec64 now;
int ret;
/* Don't even try to talk to adapter if its sick */
@@ -2506,15 +2506,15 @@ int aac_command_thread(void *data)
next_check_jiffies = jiffies
+ ((long)(unsigned)check_interval)
* HZ;
- do_gettimeofday(&now);
+ ktime_get_real_ts64(&now);
/* Synchronize our watches */
- if (((1000000 - (1000000 / HZ)) > now.tv_usec)
- && (now.tv_usec > (1000000 / HZ)))
- difference = (((1000000 - now.tv_usec) * HZ)
- + 500000) / 1000000;
+ if (((NSEC_PER_SEC - (NSEC_PER_SEC / HZ)) > now.tv_nsec)
+ && (now.tv_nsec > (NSEC_PER_SEC / HZ)))
+ difference = (((NSEC_PER_SEC - now.tv_nsec) * HZ)
+ + NSEC_PER_SEC / 2) / NSEC_PER_SEC;
else {
- if (now.tv_usec > 500000)
+ if (now.tv_nsec > NSEC_PER_SEC / 2)
++now.tv_sec;
if (dev->sa_firmware)
Patches currently in stable-queue which might be from arnd(a)arndb.de are
queue-4.14/scsi-aacraid-use-timespec64-instead-of-timeval.patch
queue-4.14/string.h-workaround-for-increased-stack-usage.patch
This is a note to let you know that I've just added the patch titled
samples/bpf: adjust rlimit RLIMIT_MEMLOCK for xdp1
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
samples-bpf-adjust-rlimit-rlimit_memlock-for-xdp1.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Tushar Dave <tushar.n.dave(a)oracle.com>
Date: Fri, 27 Oct 2017 16:12:30 -0700
Subject: samples/bpf: adjust rlimit RLIMIT_MEMLOCK for xdp1
From: Tushar Dave <tushar.n.dave(a)oracle.com>
[ Upstream commit 6dfca831c03ef654b1f7bff1b8d487d330e9f76b ]
Default rlimit RLIMIT_MEMLOCK is 64KB, causes bpf map failure.
e.g.
[root@lab bpf]#./xdp1 -N $(</sys/class/net/eth2/ifindex)
failed to create a map: 1 Operation not permitted
Fix it.
Signed-off-by: Tushar Dave <tushar.n.dave(a)oracle.com>
Acked-by: Alexei Starovoitov <ast(a)kernel.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
samples/bpf/xdp1_user.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/samples/bpf/xdp1_user.c
+++ b/samples/bpf/xdp1_user.c
@@ -14,6 +14,7 @@
#include <string.h>
#include <unistd.h>
#include <libgen.h>
+#include <sys/resource.h>
#include "bpf_load.h"
#include "bpf_util.h"
@@ -69,6 +70,7 @@ static void usage(const char *prog)
int main(int argc, char **argv)
{
+ struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
const char *optstr = "SN";
char filename[256];
int opt;
@@ -91,6 +93,12 @@ int main(int argc, char **argv)
usage(basename(argv[0]));
return 1;
}
+
+ if (setrlimit(RLIMIT_MEMLOCK, &r)) {
+ perror("setrlimit(RLIMIT_MEMLOCK)");
+ return 1;
+ }
+
ifindex = strtoul(argv[optind], NULL, 0);
snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
Patches currently in stable-queue which might be from tushar.n.dave(a)oracle.com are
queue-4.14/samples-bpf-adjust-rlimit-rlimit_memlock-for-xdp1.patch
This is a note to let you know that I've just added the patch titled
rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_disassoc_cmd
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rtl8188eu-fix-a-possible-sleep-in-atomic-bug-in-rtw_disassoc_cmd.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:29:00 CET 2017
From: Jia-Ju Bai <baijiaju1990(a)163.com>
Date: Sun, 8 Oct 2017 19:54:07 +0800
Subject: rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_disassoc_cmd
From: Jia-Ju Bai <baijiaju1990(a)163.com>
[ Upstream commit 08880f8e08cbd814e870e9d3ab9530abc1bce226 ]
The driver may sleep under a spinlock, and the function call path is:
rtw_set_802_11_bssid(acquire the spinlock)
rtw_disassoc_cmd
kzalloc(GFP_KERNEL) --> may sleep
To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai <baijiaju1990(a)163.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/rtl8188eu/core/rtw_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -508,7 +508,7 @@ u8 rtw_disassoc_cmd(struct adapter *pada
if (enqueue) {
/* need enqueue, prepare cmd_obj and enqueue */
- cmdobj = kzalloc(sizeof(*cmdobj), GFP_KERNEL);
+ cmdobj = kzalloc(sizeof(*cmdobj), GFP_ATOMIC);
if (!cmdobj) {
res = _FAIL;
kfree(param);
Patches currently in stable-queue which might be from baijiaju1990(a)163.com are
queue-4.14/rtl8188eu-fix-a-possible-sleep-in-atomic-bug-in-rtw_createbss_cmd.patch
queue-4.14/rtl8188eu-fix-a-possible-sleep-in-atomic-bug-in-rtw_disassoc_cmd.patch
queue-4.14/vt6655-fix-a-possible-sleep-in-atomic-bug-in-vt6655_suspend.patch
This is a note to let you know that I've just added the patch titled
rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_createbss_cmd
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rtl8188eu-fix-a-possible-sleep-in-atomic-bug-in-rtw_createbss_cmd.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:29:00 CET 2017
From: Jia-Ju Bai <baijiaju1990(a)163.com>
Date: Sun, 8 Oct 2017 19:54:45 +0800
Subject: rtl8188eu: Fix a possible sleep-in-atomic bug in rtw_createbss_cmd
From: Jia-Ju Bai <baijiaju1990(a)163.com>
[ Upstream commit 2bf9806d4228f7a6195f8e03eda0479d2a93b411 ]
The driver may sleep under a spinlock, and the function call path is:
rtw_surveydone_event_callback(acquire the spinlock)
rtw_createbss_cmd
kzalloc(GFP_KERNEL) --> may sleep
To fix it, GFP_KERNEL is replaced with GFP_ATOMIC.
This bug is found by my static analysis tool and my code review.
Signed-off-by: Jia-Ju Bai <baijiaju1990(a)163.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/staging/rtl8188eu/core/rtw_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/rtl8188eu/core/rtw_cmd.c
+++ b/drivers/staging/rtl8188eu/core/rtw_cmd.c
@@ -333,7 +333,7 @@ u8 rtw_createbss_cmd(struct adapter *pa
else
RT_TRACE(_module_rtl871x_cmd_c_, _drv_info_, (" createbss for SSid:%s\n", pmlmepriv->assoc_ssid.Ssid));
- pcmd = kzalloc(sizeof(struct cmd_obj), GFP_KERNEL);
+ pcmd = kzalloc(sizeof(struct cmd_obj), GFP_ATOMIC);
if (!pcmd) {
res = _FAIL;
goto exit;
Patches currently in stable-queue which might be from baijiaju1990(a)163.com are
queue-4.14/rtl8188eu-fix-a-possible-sleep-in-atomic-bug-in-rtw_createbss_cmd.patch
queue-4.14/rtl8188eu-fix-a-possible-sleep-in-atomic-bug-in-rtw_disassoc_cmd.patch
queue-4.14/vt6655-fix-a-possible-sleep-in-atomic-bug-in-vt6655_suspend.patch
This is a note to let you know that I've just added the patch titled
rtc: pcf8563: fix output clock rate
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
rtc-pcf8563-fix-output-clock-rate.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Philipp Zabel <p.zabel(a)pengutronix.de>
Date: Tue, 7 Nov 2017 13:12:17 +0100
Subject: rtc: pcf8563: fix output clock rate
From: Philipp Zabel <p.zabel(a)pengutronix.de>
[ Upstream commit a3350f9c57ffad569c40f7320b89da1f3061c5bb ]
The pcf8563_clkout_recalc_rate function erroneously ignores the
frequency index read from the CLKO register and always returns
32768 Hz.
Fixes: a39a6405d5f9 ("rtc: pcf8563: add CLKOUT to common clock framework")
Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni(a)free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/rtc/rtc-pcf8563.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -422,7 +422,7 @@ static unsigned long pcf8563_clkout_reca
return 0;
buf &= PCF8563_REG_CLKO_F_MASK;
- return clkout_rates[ret];
+ return clkout_rates[buf];
}
static long pcf8563_clkout_round_rate(struct clk_hw *hw, unsigned long rate,
Patches currently in stable-queue which might be from p.zabel(a)pengutronix.de are
queue-4.14/rtc-pcf8563-fix-output-clock-rate.patch